วิทยาศาสตร์ข้อมูลและฐานข้อมูล

คู่มือ Oracle เป็น SQL Server และ SQL Server ไปยัง Oracle Migration - Pt. 3

ครั้งแรก และ ที่สอง บางส่วนของชุดนี้กล่าวถึงความแตกต่างระหว่าง Oracle Database และ Microsoft SQL Server ในการนำธุรกรรมไปใช้และข้อผิดพลาดในการแปลงที่เกิดขึ้นรวมถึงองค์ประกอบไวยากรณ์ที่ใช้กันทั่วไป

งวดสุดท้ายนี้จะกล่าวถึงแนวคิดของ Oracle อ่านความสอดคล้องและวิธีการแปลงสถาปัตยกรรมตามแนวคิดนี้เป็นไฟล์ Microsoft SQL Server รุ่น. นอกจากนี้ยังกล่าวถึงการใช้คำพ้องความหมาย (และวิธีไม่ใช้) และบทบาทของกระบวนการควบคุมการเปลี่ยนแปลงในการจัดการสภาพแวดล้อมฐานข้อมูลของคุณ

Oracle Read Consistency และเทียบเท่าใน SQL Server

ความสอดคล้องในการอ่านของ Oracle เป็นการรับประกันว่าข้อมูลทั้งหมดที่ส่งคืนโดยคำสั่ง SQL เดียวมาจากจุดเอกพจน์เดียวกันในเวลา

หมายความว่าถ้าคุณออก SELECT คำสั่งที่ 12: 01: 02.345 และรันเป็นเวลา 5 นาทีก่อนที่จะส่งคืนชุดผลลัพธ์ข้อมูลทั้งหมด (และข้อมูลเดียว) ที่ถูกคอมมิตในฐานข้อมูล ณ เวลา 12: 01: 02.345 จะทำให้เป็นชุดส่งคืนของคุณ ชุดการส่งคืนของคุณจะไม่มีการเพิ่มข้อมูลใหม่ในช่วง 5 นาทีที่ใช้ฐานข้อมูลในการประมวลผลคำสั่งของคุณหรือการอัปเดตใด ๆ และจะไม่มีการลบให้เห็น

สถาปัตยกรรม Oracle บรรลุความสอดคล้องในการอ่านโดยการประทับเวลาภายในทุกการเปลี่ยนแปลงข้อมูลและสร้างชุดผลลัพธ์จากแหล่งข้อมูลสองแหล่ง ได้แก่ ไฟล์ข้อมูลถาวรและกลุ่มเลิกทำ (หรือ 'ส่วนย้อนกลับ' เป็นที่รู้จักจนถึงเวอร์ชัน 10g ).

เพื่อสนับสนุนข้อมูลยกเลิกการทำ ควรได้รับการอนุรักษ์ไว้ . หากมีการเขียนทับจะส่งผลให้ ORA-01555: snapshot too old เสียชื่อเสียง ข้อผิดพลาด

ออกจากการยกเลิกการจัดการกลุ่มและวิธีนำทาง ORA-01555: snapshot too old ข้อผิดพลาด - มาดูผลกระทบของความสม่ำเสมอในการอ่านต่อการนำไปใช้งานจริงใน Oracle นอกจากนี้ควรทำมิเรอร์อย่างไรใน SQL Server ซึ่งเช่นเดียวกับการใช้งาน RDBMS อื่น ๆ โดยมีข้อยกเว้นที่เป็นไปได้และมีคุณสมบัติเหมาะสมของ PostgreSQL - ไม่สนับสนุน?

ที่สำคัญคือ Oracle อ่านและเขียนไม่ปิดกั้นซึ่งกันและกัน นอกจากนี้ยังหมายความว่าชุดการส่งคืนแบบสอบถามที่ใช้งานมายาวนานของคุณอาจไม่มีข้อมูลล่าสุด

การอ่านและเขียนแบบไม่ปิดกั้นเป็นข้อได้เปรียบที่ Oracle มีและมัน มีผลต่อการกำหนดขอบเขตธุรกรรม .

แต่ความสม่ำเสมอในการอ่านยังหมายความว่าคุณไม่มีสถานะล่าสุดของข้อมูล เมื่ออยู่ในสถานการณ์ที่ดีอย่างสมบูรณ์ (เช่นการจัดทำรายงานในช่วงเวลาหนึ่ง ๆ ) อาจทำให้เกิดปัญหาสำคัญในกรณีอื่น ๆ

การไม่มีข้อมูลล่าสุดแม้แต่“ สกปรก” หรือไม่มีข้อผูกมัดข้อมูลอาจมีความสำคัญ: สถานการณ์แบบคลาสสิกคือระบบการจองห้องพักในโรงแรม

พิจารณากรณีการใช้งานต่อไปนี้: คุณมีตัวแทนบริการลูกค้าสองรายที่รับคำสั่งจองห้องพร้อมกัน คุณจะมั่นใจได้อย่างไรว่าห้องจะไม่ถูกจองมากเกินไป?

ใน SQL Server คุณสามารถเริ่มต้นธุรกรรมที่ชัดเจนและ SELECT บันทึกจากรายการ (ซึ่งอาจเป็นตารางหรือมุมมอง) ของห้องว่าง ตราบใดที่ธุรกรรมนี้ยังไม่ปิด (โดย COMMIT หรือ ROLLBACK) จะไม่มีใครได้รับบันทึกห้องเดียวกับที่คุณเลือก วิธีนี้จะป้องกันการจองซ้ำซ้อน แต่ยังทำให้ตัวแทนรายอื่น ๆ รอกันเพื่อดำเนินการตามคำขอจองทีละรายการตามลำดับ

ใน Oracle คุณสามารถบรรลุผลลัพธ์เดียวกันได้โดยการออก SELECT ... FOR UPDATE คำสั่งกับบันทึกที่ตรงกับเกณฑ์การค้นหาของคุณ

หมายเหตุ: มีวิธีแก้ไขที่ดีกว่าเช่นการตั้งค่าสถานะชั่วคราวเพื่อทำเครื่องหมายห้อง 'อยู่ระหว่างการพิจารณา' แทนที่จะล็อกการเข้าถึงแบบสุ่มสี่สุ่มห้า แต่นั่นคือโซลูชันทางสถาปัตยกรรมไม่ใช่ตัวเลือกภาษา

วิธีการเรียนรู้ c และ c ++

สรุป : ความสม่ำเสมอในการอ่านของ Oracle ไม่ใช่“ ดีทั้งหมด” หรือ“ ไม่ดีทั้งหมด” แต่เป็นคุณสมบัติที่สำคัญของแพลตฟอร์มที่ต้องทำความเข้าใจให้ดีและมีความสำคัญอย่างยิ่งต่อการย้ายรหัสข้ามแพลตฟอร์ม

คำพ้องความหมายสาธารณะ (และส่วนตัว) ใน Oracle และ Microsoft SQL Server

“ คำพ้องความหมายสาธารณะเป็นสิ่งชั่วร้าย” มันคือ ไม่ใช่การค้นพบส่วนตัวของฉัน แต่ฉันยอมรับว่าเป็นพระกิตติคุณจนกระทั่งวันสัปดาห์และปีของฉันได้รับการบันทึกด้วยคำพ้องความหมายสาธารณะ

ในสภาพแวดล้อมฐานข้อมูลจำนวนมากฉันจะบอกว่าสภาพแวดล้อม Oracle ทั้งหมดที่ฉันเคยมีโอกาสทำงานด้วย แต่ไม่มีที่ฉันออกแบบ - โดยใช้ CREATE PUBLIC SYNONYM สำหรับทุกวัตถุ เป็นกิจวัตรเพราะ“ เราทำแบบนั้นมาตลอด”

ในสภาพแวดล้อมเหล่านี้คำพ้องความหมายสาธารณะมีฟังก์ชันเดียวเท่านั้นคืออนุญาตให้อ้างอิงไปยังวัตถุโดยไม่ต้องระบุเจ้าของ และนี่คือหนึ่ง เหตุผลที่คิดไม่ดี เพื่อสร้างคำพ้องความหมายสาธารณะ

ac corp กับ s corp ต่างกันอย่างไร

อย่างไรก็ตามคำพ้องความหมายสาธารณะของ Oracle มีประโยชน์อย่างมากและให้ผลประโยชน์ด้านการผลิตของทีมซึ่งมีมากกว่าข้อเสียทั้งหมดอย่างมากหากนำไปใช้และจัดการอย่างถูกต้องและมีเหตุผล ใช่ฉันพูดว่า 'ประสิทธิภาพของทีม' แต่อย่างไร? สำหรับสิ่งนี้เราต้องเข้าใจว่าการแก้ปัญหาชื่อทำงานอย่างไรใน Oracle

เมื่อตัวแยกวิเคราะห์ Oracle ค้นหาชื่อ (คีย์เวิร์ดที่ไม่ได้สงวนไว้) จะพยายามจับคู่กับอ็อบเจ็กต์ฐานข้อมูลที่มีอยู่ตามลำดับต่อไปนี้:

ผังงานที่ขึ้นต้นด้วย my_object เป็นอินพุต สคีมาปัจจุบันของเซสชันการออกมีอ็อบเจ็กต์ชื่อ my_object หรือไม่ ถ้าเป็นเช่นนั้นเรา

หมายเหตุ: ข้อผิดพลาดที่เกิดขึ้นจะเป็น ORA-00942: table or view does not exist สำหรับคำสั่ง DML หรือ PLS-00201: identifier 'my_object' must be declared สำหรับกระบวนงานที่เก็บไว้หรือการเรียกใช้ฟังก์ชัน

ในลำดับการแก้ไขชื่อนี้เป็นเรื่องง่ายที่จะเห็นว่าเมื่อนักพัฒนาทำงานในสคีมาของตนเองออบเจ็กต์ในเครื่องใด ๆ ที่มีชื่อเดียวกับคำพ้องความหมายสาธารณะจะ ซ่อน คำพ้องความหมายสาธารณะนี้ (หมายเหตุ: Oracle 18c ใช้สคีมาประเภท“ ล็อกอินเท่านั้น” และการสนทนานี้ใช้ไม่ได้กับมัน)

คำพ้องความหมายสาธารณะสำหรับ Scaling Teams: Oracle Change Control

ตอนนี้เรามาดูทีมสมมุติที่มีนักพัฒนา 100 คนที่ทำงานบนฐานข้อมูลเดียวกัน (ซึ่งเป็นสิ่งที่ฉันเคยพบ) นอกจากนี้สมมติว่าพวกเขาทั้งหมดทำงานในพื้นที่บนเวิร์กสเตชันส่วนบุคคลและสร้างฐานข้อมูลที่ไม่ใช่ฐานข้อมูลแยกกันทั้งหมดเชื่อมโยงกับสภาพแวดล้อมการพัฒนาฐานข้อมูลเดียวกัน ความละเอียดของการรวมโค้ดในโค้ดที่ไม่ใช่ฐานข้อมูล (ไม่ว่าจะเป็น C #, Java, C ++, Python หรืออย่างอื่น) จะดำเนินการในเวลาเช็คอินการควบคุมการเปลี่ยนแปลงและจะมีผลกับการสร้างโค้ดถัดไป แต่ตารางฐานข้อมูลรหัสและข้อมูลจำเป็นต้องเปลี่ยนแปลงไปมาหลายครั้งในระหว่างการพัฒนาอย่างต่อเนื่อง นักพัฒนาแต่ละคนทำสิ่งนี้โดยอิสระและจะมีผลทันที

สำหรับสิ่งนี้อ็อบเจ็กต์ฐานข้อมูลทั้งหมดจะถูกสร้างขึ้นในสกีมาแอ็พพลิเคชันทั่วไป นี่คือ ที่ สคีมาที่แอปพลิเคชันอ้างอิง นักพัฒนาแต่ละคน:

เชื่อมต่อกับฐานข้อมูลด้วยบัญชีผู้ใช้ส่วนบุคคล / สคีมา
เริ่มต้นด้วยสคีมาส่วนบุคคลที่ว่างเปล่าเสมอ
อ้างอิงสคีมาทั่วไปผ่านการแก้ชื่อเป็นคำพ้องความหมายสาธารณะตามที่อธิบายไว้ข้างต้นเท่านั้น

เมื่อนักพัฒนาจำเป็นต้องสร้าง ใด ๆ การเปลี่ยนแปลงฐานข้อมูล - สร้างหรือแก้ไขตารางเปลี่ยนรหัสขั้นตอนหรือแม้กระทั่งแก้ไขชุดข้อมูลเพื่อรองรับสถานการณ์ทดสอบบางอย่างโดยสร้างสำเนาของวัตถุในสคีมาส่วนบุคคล พวกเขาทำได้โดยรับรหัส DDL โดยใช้ DESCRIBE คำสั่งและเรียกใช้ในเครื่อง

จากช่วงเวลานี้โค้ดของนักพัฒนาซอฟต์แวร์รายนี้จะเห็นออบเจ็กต์และข้อมูลเวอร์ชันท้องถิ่นซึ่งจะไม่ปรากฏให้ใครเห็น (และไม่มีผลกระทบต่อ) คนอื่น หลังจากการพัฒนาเสร็จสิ้นรหัสฐานข้อมูลที่แก้ไขจะถูกตรวจสอบในการควบคุมแหล่งที่มาและข้อขัดแย้งจะได้รับการแก้ไข จากนั้นโค้ดสุดท้าย (และข้อมูลหากจำเป็น) จะถูกนำไปใช้ในสคีมาทั่วไป

หลังจากนี้ทีมพัฒนาทั้งหมดสามารถดูฐานข้อมูลเดียวกันได้อีกครั้ง นักพัฒนาซอฟต์แวร์ที่เพิ่งส่งรหัสจะทิ้งออบเจ็กต์ทั้งหมดจากสคีมาส่วนตัวและพร้อมสำหรับการมอบหมายงานใหม่

ความสามารถในการอำนวยความสะดวกในการทำงานคู่ขนานอย่างอิสระสำหรับนักพัฒนาหลายคนเป็นประโยชน์หลักของคำพ้องความหมายสาธารณะซึ่งเป็นความสำคัญที่ยากที่จะพูดเกินจริง อย่างไรก็ตามในทางปฏิบัติฉันยังคงเห็นทีมสร้างคำพ้องความหมายสาธารณะในการใช้งาน Oracle“ เพียงเพราะเราทำอยู่เสมอ” ในทางตรงกันข้ามในทีมที่ใช้ SQL Server ฉันไม่เห็นการสร้างคำพ้องความหมายสาธารณะที่สร้างขึ้นเป็นแนวทางปฏิบัติทั่วไป ฟังก์ชันนี้มีอยู่ แต่ไม่ได้ใช้บ่อย

ใน SQL Server สคีมาเริ่มต้นปัจจุบันสำหรับผู้ใช้ถูกกำหนดไว้ในคอนฟิกูเรชันของผู้ใช้และสามารถเปลี่ยนแปลงได้ตลอดเวลาหากคุณมีสิทธิ์ 'แก้ไขผู้ใช้' สามารถใช้วิธีการเดียวกันกับที่อธิบายไว้ข้างต้นสำหรับ Oracle ได้ อย่างไรก็ตามหากไม่ใช้วิธีนี้ไม่ควรคัดลอกคำพ้องความหมายสาธารณะ

เนื่องจาก Microsoft SQL Server ไม่ได้เชื่อมโยงบัญชีผู้ใช้ใหม่กับสคีมาของตนเองโดยค่าเริ่มต้น (เช่นเดียวกับ Oracle) การเชื่อมโยงควรเป็นส่วนหนึ่งของสคริปต์ 'สร้างผู้ใช้' มาตรฐานของคุณ

ด้านล่างนี้เป็นตัวอย่างของสคริปต์ที่สร้างสคีมาสำหรับผู้ใช้โดยเฉพาะและกำหนดหนึ่งให้กับผู้ใช้

ขั้นแรกให้สร้างสคีมาสำหรับผู้ใช้ใหม่ที่ต้องเข้าสู่ฐานข้อมูลที่ชื่อ DevelopmentDatabase (ต้องสร้างสคีมาแต่ละชุดในชุดของตัวเอง):

use DevelopmentDatabase; GO CREATE SCHEMA Dev1; GO CREATE SCHEMA Dev2; GO

ประการที่สองสร้างผู้ใช้รายแรกด้วยสคีมาเริ่มต้นที่กำหนด:

CREATE LOGIN DevLogin123 WITH PASSWORD = 'first_pass123'; CREATE USER Dev1 FOR LOGIN DevLogin123 WITH DEFAULT_SCHEMA = Dev1; GO

ณ จุดนี้สคีมาเริ่มต้นสำหรับผู้ใช้ Dev1 จะเป็น Dev1.

จากนั้นสร้างผู้ใช้รายอื่นโดยไม่มีสคีมาเริ่มต้น:

CREATE LOGIN DevLogin321 WITH PASSWORD = 'second_pass321'; CREATE USER Dev2 FOR LOGIN DevLogin321; GO

สคีมาเริ่มต้นสำหรับผู้ใช้ Dev2 คือ dbo.

ตอนนี้เปลี่ยนผู้ใช้ Dev2 เพื่อเปลี่ยนสคีมาเริ่มต้นเป็น Dev2:

ALTER USER Dev2 WITH DEFAULT_SCHEMA = Dev2; GO

ตอนนี้สคีมาเริ่มต้นสำหรับผู้ใช้ Dev2 คือ Dev2.

สคริปต์นี้แสดงให้เห็นสองวิธีในการกำหนดและเปลี่ยน schema เริ่มต้นสำหรับผู้ใช้ในฐานข้อมูล Microsoft SQL Server เนื่องจาก SQL Server สนับสนุนวิธีการตรวจสอบผู้ใช้หลายวิธี (วิธีที่พบมากที่สุดคือการรับรองความถูกต้องของ Windows) และการเริ่มต้นใช้งานของผู้ใช้อาจได้รับการจัดการโดยผู้ดูแลระบบแทนที่จะเป็น DBAs จึงทำให้ ALTER USER วิธีการกำหนด / เปลี่ยนสคีมาเริ่มต้นจะใช้งานได้มากขึ้น

หมายเหตุ: ฉันตั้งชื่อสคีมาเหมือนกับชื่อของผู้ใช้ ไม่จำเป็นต้องเป็นแบบนี้ใน SQL Server แต่เป็นความชอบของฉันเพราะ (1) ตรงกับวิธีการทำใน Oracle และ (2) ทำให้การจัดการผู้ใช้ง่ายขึ้น (จัดการกับการคัดค้านที่ใหญ่ที่สุดในส่วนของ DBA เพื่อทำสิ่งที่ถูกต้อง ตั้งแต่แรก) - คุณรู้ชื่อผู้ใช้และคุณจะทราบสคีมาเริ่มต้นของผู้ใช้โดยอัตโนมัติ

สรุป : คำพ้องความหมายสาธารณะเป็นเครื่องมือสำคัญในการสร้างสภาพแวดล้อมการพัฒนาผู้ใช้หลายคนที่มีเสถียรภาพและมีการป้องกันอย่างดี น่าเสียดายที่ในการสังเกตของฉันในอุตสาหกรรมมักใช้เหตุผลที่ไม่ถูกต้องทำให้ทีมต้องทนทุกข์กับความสับสนและข้อเสียอื่น ๆ ของคำพ้องความหมายสาธารณะโดยไม่ตระหนักถึงประโยชน์ของพวกเขา การเปลี่ยนแนวปฏิบัตินี้เพื่อให้ได้มาซึ่งประโยชน์ที่แท้จริงจากคำพ้องความหมายสาธารณะสามารถนำประโยชน์ที่แท้จริงมาสู่ขั้นตอนการพัฒนาของทีม

การจัดการการเข้าถึงฐานข้อมูลและกระบวนการจัดการการเปลี่ยนแปลง

ในขณะที่เราเพิ่งพูดคุยเกี่ยวกับการสนับสนุนสำหรับการพัฒนาแบบคู่ขนานโดยทีมขนาดใหญ่มันคุ้มค่าที่จะพูดถึงหัวข้อที่แยกจากกันและมักเข้าใจผิดนั่นคือกระบวนการควบคุมการเปลี่ยนแปลง

การจัดการการเปลี่ยนแปลงมักจะกลายเป็นเทปสีแดงที่ควบคุมโดยหัวหน้าทีมและ DBA ซึ่งถูกดูหมิ่นโดยนักพัฒนาที่ดื้อรั้นที่ต้องการส่งมอบทุกสิ่งหากไม่ใช่“ เมื่อวาน” แล้วก็“ ตอนนี้”

ในฐานะ DBA ฉันมักจะวางกำแพงป้องกันไว้ในฐานข้อมูล 'ของฉัน' และฉันมีเหตุผลที่ดีมากสำหรับสิ่งนี้: ฐานข้อมูลเป็นทรัพยากรที่ใช้ร่วมกัน
ทวีต

ในบริบทการควบคุมแหล่งที่มาการจัดการการเปลี่ยนแปลงเป็นที่ยอมรับโดยทั่วไปเนื่องจากช่วยให้ทีมสามารถเปลี่ยนจากรหัสใหม่ แต่ใช้งานไม่ได้เป็นรหัสเก่า แต่ใช้งานได้ แต่ในบริบทฐานข้อมูลการจัดการการเปลี่ยนแปลงอาจดูเหมือนชุดของอุปสรรคและข้อ จำกัด ที่ไม่มีเหตุผลที่ DBA วางไว้นั่นคือความบ้าคลั่งที่ทำให้การพัฒนาช้าลงโดยไม่จำเป็น!

กฎเกสตัลต์ของ ________ บอกว่าเรามักจะจัดกลุ่มวัตถุที่อยู่ใกล้กัน

เรามาคุยโวกันดีกว่าว่าฉันเป็น DBA และจะไม่โยนหินใส่ตัวเอง! ในฐานะ DBA ฉันมักจะวางกำแพงป้องกันไว้ในฐานข้อมูล 'ของฉัน' และฉันมีเหตุผลที่ดีมากสำหรับสิ่งนี้: ฐานข้อมูลเป็นทรัพยากรที่ใช้ร่วมกัน

ทีมพัฒนาทุกคนและนักพัฒนาแต่ละคนมีวัตถุประสงค์ที่กำหนดไว้เป็นพิเศษและสามารถส่งมอบได้เฉพาะเจาะจงมาก วัตถุประสงค์เดียวที่อยู่บนโต๊ะทำงานของ DBA ทุกวันคือความเสถียรของฐานข้อมูลในฐานะทรัพยากรที่ใช้ร่วมกัน DBA มีบทบาทพิเศษในองค์กรเพื่อดูแลความพยายามในการพัฒนาทั้งหมดในทุกทีมและควบคุมฐานข้อมูลที่นักพัฒนาทุกคนเข้าถึง DBA เป็นผู้ดูแลให้แน่ใจว่าโครงการทั้งหมดและกระบวนการทั้งหมดกำลังดำเนินการโดยไม่รบกวนซึ่งกันและกันและแต่ละโครงการมีทรัพยากรที่จำเป็นในการทำงาน

ปัญหาคือเมื่อทั้งทีมพัฒนาและ DBA นั่งขังอยู่ในหอคอยงาช้างตามลำดับ

นักพัฒนาไม่ทราบไม่มีสิทธิ์เข้าถึงและไม่สนใจว่าจะเกิดอะไรขึ้นในฐานข้อมูลตราบใดที่มันทำงานได้ดีสำหรับพวกเขา (ไม่ใช่สิ่งที่ส่งมอบได้และจะไม่มีผลต่อการประเมินผลงาน)

ทีม DBA เก็บฐานข้อมูลไว้ใกล้หน้าอกปกป้องฐานข้อมูลจากนักพัฒนาที่ 'ไม่รู้อะไรเลย' เกี่ยวกับเรื่องนี้เนื่องจากวัตถุประสงค์ของทีมคือความเสถียรของฐานข้อมูล และวิธีที่ดีที่สุดในการสร้างเสถียรภาพคือการป้องกันการเปลี่ยนแปลงที่ทำลายล้างซึ่งมักส่งผลให้เกิดทัศนคติในการปกป้องฐานข้อมูลจากการเปลี่ยนแปลงใด ๆ ให้มากที่สุด

เหล่านี้ ทัศนคติที่ขัดแย้งกันต่อฐานข้อมูล อย่างที่ฉันเคยเห็นนำไปสู่ความเกลียดชังระหว่างทีมพัฒนาและ DBA และส่งผลให้เกิดสภาพแวดล้อมที่ไม่สามารถใช้งานได้ แต่ DBA และทีมพัฒนาต้องทำงานร่วมกันเพื่อบรรลุวัตถุประสงค์ร่วมกันนั่นคือการนำเสนอโซลูชันทางธุรกิจซึ่งเป็นสิ่งที่นำพวกเขามารวมกันตั้งแต่แรก

จากการแบ่งผู้พัฒนา -DBA ทั้งสองด้านฉันรู้ว่าปัญหานั้นแก้ได้ง่ายเมื่อ DBA เข้าใจงานทั่วไปและวัตถุประสงค์ของทีมพัฒนาได้ดีขึ้น ในด้านของพวกเขานักพัฒนาจำเป็นต้องเห็นฐานข้อมูลไม่ใช่เป็นแนวคิดเชิงนามธรรม แต่เป็นทรัพยากรที่ใช้ร่วมกันและที่นั่น DBA ควรรับหน้าที่เป็นนักการศึกษา

แนวปฏิบัติที่ดีที่สุดในการทดสอบหน่วย java

ข้อผิดพลาดที่พบบ่อยที่สุดที่ DBA ที่ไม่ใช่นักพัฒนาทำคือการ จำกัด การเข้าถึงของนักพัฒนาในพจนานุกรมข้อมูลและเครื่องมือปรับแต่งโค้ด เข้าถึง Oracle DBA_ มุมมองแค็ตตาล็อกไดนามิก V$ มุมมองและ SYS ตารางดูเหมือนว่า DBA จำนวนมากจะเป็น“ DBA อภิสิทธิ์” ในความเป็นจริงเมื่อสิ่งเหล่านี้เป็นเครื่องมือในการพัฒนาที่สำคัญ

สิ่งเดียวกันนี้ถือเป็นจริงสำหรับ SQL Server โดยมีข้อแทรกซ้อนอย่างหนึ่ง: ไม่สามารถให้สิทธิ์การเข้าถึงมุมมองระบบบางอย่างโดยตรง แต่เป็นเพียงส่วนหนึ่งของ SYSADMIN บทบาทฐานข้อมูลและไม่ควรให้บทบาทนี้นอกทีม DBA สิ่งนี้สามารถแก้ไขได้ (และควรแก้ไขในกรณีของการย้ายโปรเจ็กต์จาก Oracle ไปยัง SQL Server) โดยการสร้างมุมมองและโพรซีเดอร์ที่จัดเก็บไว้ซึ่งดำเนินการภายใต้ SYSADMIN สิทธิพิเศษ แต่สามารถเข้าถึงได้โดยผู้ใช้ที่ไม่ใช่ DBA นี่คือ การพัฒนา DBA งานที่ต้องทำเนื่องจากมีการกำหนดค่าสภาพแวดล้อมการพัฒนา SQL Server ใหม่

การปกป้องข้อมูลถือเป็นความรับผิดชอบหลักประการหนึ่งของ DBA อย่างไรก็ตามเรื่องนี้เป็นเรื่องปกติที่ทีมพัฒนาจะสามารถเข้าถึงข้อมูลการผลิตที่ไม่มีการกรองได้อย่างเต็มที่เพื่อให้สามารถแก้ไขปัญหาตั๋วที่เกี่ยวข้องกับข้อมูลได้ เหล่านี้เป็นนักพัฒนารายเดียวกันที่มีสิทธิ์เข้าถึงโครงสร้างข้อมูลอย่าง จำกัด - โครงสร้างที่สร้างขึ้นโดยพวกเขาหรือสำหรับพวกเขาตั้งแต่แรก

เมื่อมีการสร้างความสัมพันธ์ในการทำงานที่เหมาะสมระหว่างการพัฒนาและทีม DBA การสร้างกระบวนการควบคุมการเปลี่ยนแปลงที่ดีจะกลายเป็นเรื่องง่าย ข้อมูลจำเพาะและความท้าทายของการจัดการการเปลี่ยนแปลงด้านฐานข้อมูลคือความแข็งแกร่งและความลื่นไหลของฐานข้อมูลในเวลาเดียวกัน - โครงสร้างมีความแข็งแกร่งข้อมูลเป็นของเหลว

บ่อยครั้งที่การจัดการการเปลี่ยนแปลงในการปรับเปลี่ยนโครงสร้างเช่นในภาษานิยามข้อมูลหรือ DDL เป็นที่ยอมรับอย่างดีในขณะที่การเปลี่ยนแปลงข้อมูลแทบไม่มีเลยในวิธีการจัดการการเปลี่ยนแปลง เหตุผลนั้นง่ายมาก - ข้อมูลเปลี่ยนแปลงตลอดเวลา

แต่ถ้าเราพิจารณาอย่างละเอียดมากขึ้นเราจะเห็นว่าในระบบใด ๆ ข้อมูลทั้งหมดอยู่ในหมวดหมู่หนึ่งในสองประเภท ได้แก่ ข้อมูลแอปพลิเคชันและข้อมูลผู้ใช้

ข้อมูลแอปพลิเคชัน เป็นพจนานุกรมข้อมูลที่กำหนดลักษณะการทำงานของแอปพลิเคชันและมีความสำคัญอย่างยิ่งต่อกระบวนการต่างๆเช่นเดียวกับรหัสแอปพลิเคชัน การเปลี่ยนแปลงข้อมูลนี้ควรอยู่ภายใต้กระบวนการควบคุมการเปลี่ยนแปลงที่เข้มงวดเช่นเดียวกับการเปลี่ยนแปลงแอปพลิเคชันอื่น ๆ เพื่อสร้างความโปร่งใสในกระบวนการควบคุมการเปลี่ยนแปลงสำหรับการเปลี่ยนแปลงข้อมูลแอปพลิเคชันข้อมูลแอปพลิเคชันและข้อมูลผู้ใช้ควรแยกออกจากกันอย่างชัดเจน

ใน Oracle ควรดำเนินการโดยการวางแอปพลิเคชันและข้อมูลผู้ใช้แต่ละรายการในสคีมาของตนเอง ใน Microsoft SQL Server ควรทำโดยการวางแต่ละสคีมาแยกกันหรือ - ดีกว่ามาก - ลงในฐานข้อมูลแยกต่างหาก การเลือกตัวเลือกเหล่านี้ควรเป็นส่วนหนึ่งของการวางแผนการโอนย้าย: Oracle มีการแก้ปัญหาชื่อสองระดับ (สคีมา / เจ้าของ - ชื่ออ็อบเจ็กต์) ในขณะที่ SQL Server มีการแก้ไขชื่อสามระดับ (ฐานข้อมูล - สคีมา / เจ้าของ - ชื่ออ็อบเจ็กต์)

แหล่งที่มาของความสับสนระหว่างโลกของ Oracle และ SQL Server อาจเป็นเรื่องที่น่าประหลาดใจ ฐานข้อมูล และ เซิร์ฟเวอร์ :

ข้อกำหนดของเซิร์ฟเวอร์ SQL	ข้อกำหนดของ Oracle	คำจำกัดความ
เซิร์ฟเวอร์	ฐานข้อมูล (ใช้แทนกันได้กับ เซิร์ฟเวอร์ ในสำนวนทั่วไปเว้นแต่จะกล่าวถึงฮาร์ดแวร์เซิร์ฟเวอร์ระบบปฏิบัติการหรือองค์ประกอบเครือข่ายโดยเฉพาะ อาจมีฐานข้อมูลอย่างน้อยหนึ่งฐานข้อมูลบนเซิร์ฟเวอร์จริง / เสมือน)	อินสแตนซ์ที่ทำงานอยู่ซึ่งสามารถ 'พูดคุย' กับอินสแตนซ์อื่น ๆ ผ่านพอร์ตเครือข่าย
ฐานข้อมูล (ส่วนหนึ่งของเซิร์ฟเวอร์มีสคีมา / เจ้าของหลายตัว)	สคีมา / เจ้าของ	การจัดกลุ่มระดับบนสุด

การผสมผสานคำศัพท์นี้ควรเข้าใจอย่างชัดเจนในโครงการการย้ายข้อมูลข้ามแพลตฟอร์มเนื่องจากการตีความคำผิดอาจส่งผลให้มีการตัดสินใจเกี่ยวกับการกำหนดค่าที่ไม่ถูกต้องซึ่งยากที่จะแก้ไขย้อนหลังได้

การแยกแอปพลิเคชันและข้อมูลผู้ใช้ที่ถูกต้องช่วยให้ทีม DBA สามารถจัดการกับข้อกังวลที่สำคัญอันดับสอง ได้แก่ ความปลอดภัยของข้อมูลผู้ใช้ เนื่องจากข้อมูลผู้ใช้อยู่แยกกันการใช้งานไฟล์ ขั้นตอนการทำลายกระจก สำหรับการเข้าถึงข้อมูลของผู้ใช้ตามความจำเป็น

สรุป : กระบวนการควบคุมการเปลี่ยนแปลงมีความสำคัญอย่างยิ่งในทุกโครงการ ในด้านวิศวกรรมซอฟต์แวร์การจัดการการเปลี่ยนแปลงในฝั่งฐานข้อมูลมักถูกละเลยเนื่องจากข้อมูลถูกมองว่า“ ลื่นไหลเกินไป” แต่นั่นเป็นเพราะข้อมูลนั้น“ ลื่นไหล” และ“ คงอยู่” ในขณะเดียวกันกระบวนการควบคุมการเปลี่ยนแปลงที่ออกแบบมาอย่างดีควรเป็นรากฐานที่สำคัญของสถาปัตยกรรมสภาพแวดล้อมฐานข้อมูลที่เหมาะสม

เกี่ยวกับการใช้เครื่องมือการย้ายรหัส

เครื่องมือมาตรฐานของบุคคลที่หนึ่ง Oracle Migration Workbench และ ผู้ช่วยการโยกย้ายเซิร์ฟเวอร์ SQL สามารถเป็นประโยชน์ในการย้ายรหัส แต่สิ่งที่ต้องคำนึงถึงคือ กฎ 80/20 : เมื่อจะย้ายรหัสอย่างถูกต้อง 80% การแก้ไขอีก 20% ที่เหลือจะใช้เวลา 80% ของความพยายามในการย้ายข้อมูล

ความเสี่ยงที่ยิ่งใหญ่ที่สุดในการใช้เครื่องมือการย้ายถิ่นคือการรับรู้ของ 'กระสุนเงิน' อาจมีคนคิดว่า“ มันจะได้ผลและฉันก็แค่ต้องทำความสะอาดและจัดระเบียบนิดหน่อย” ฉันสังเกตเห็นโครงการที่ล้มเหลวเนื่องจากทัศนคติดังกล่าวจากทีม Conversion และความเป็นผู้นำด้านเทคนิค

ในทางกลับกันฉันใช้เวลาสี่วันทำการในการแปลงพื้นฐานของระบบ Microsoft SQL Server 2008 ขนาดกลาง (ประมาณ 200 วัตถุ) โดยใช้ฟังก์ชันแทนที่จำนวนมากของ Notepad ++ เป็นเครื่องมือแก้ไขหลัก

ไม่มีองค์ประกอบการย้ายข้อมูลที่สำคัญใด ๆ ที่ฉันได้กล่าวถึงไปแล้วที่สามารถแก้ไขได้ด้วยเครื่องมือการย้ายข้อมูล

แน่นอนว่าใช้เครื่องมือช่วยเหลือในการย้ายข้อมูล แต่อย่าลืมว่าสิ่งเหล่านี้ให้ความช่วยเหลือในการแก้ไขเท่านั้น ข้อความผลลัพธ์ที่ได้จะต้องมีการตรวจสอบแก้ไขและในบางกรณี - เขียนใหม่เพื่อให้กลายเป็นรหัสที่คุ้มค่าในการผลิต

การพัฒนาเครื่องมือปัญญาประดิษฐ์อาจแก้ไขข้อบกพร่องของเครื่องมือการย้ายข้อมูลเหล่านี้ได้ในอนาคต แต่ฉันคาดหวังว่าความแตกต่างระหว่างฐานข้อมูลจะพร่าเลือนไปก่อนหน้านั้นและกระบวนการโยกย้ายใด ๆ จะไม่จำเป็น ดังนั้นตราบเท่าที่จำเป็นต้องมีโครงการประเภทนี้เราจะต้องทำแบบเก่าโดยใช้สติปัญญาของมนุษย์สมัยเก่า

สรุป : การใช้เครื่องมือช่วยเหลือในการย้ายข้อมูลมีประโยชน์ แต่ไม่ใช่ 'กระสุนเงิน' และโครงการแปลงใด ๆ ยังต้องมีการตรวจสอบประเด็นข้างต้นโดยละเอียด

Oracle / SQL Server Migrations: มองอย่างใกล้ชิดเสมอ

Oracle และ Microsoft SQL Server เป็นสองแพลตฟอร์ม RDBMS ที่แพร่หลายมากที่สุดในสภาพแวดล้อมขององค์กร ทั้งสองมีความสอดคล้องพื้นฐานกับมาตรฐาน ANSI SQL และส่วนเล็ก ๆ ของโค้ดสามารถย้ายข้ามไปมาได้โดยมีการปรับเปลี่ยนน้อยมากหรือแม้กระทั่งตามที่เป็นอยู่

ความคล้ายคลึงกันนี้สร้างความประทับใจที่หลอกลวงว่าการโยกย้ายข้ามทั้งสองแพลตฟอร์มเป็นงานที่เรียบง่ายตรงไปตรงมาและสามารถนำแอปพลิเคชันเดียวกันนี้มาใช้ได้อย่างง่ายดายจากการใช้แบ็คเอนด์ RDBMS หนึ่งไปยังอีก

ในทางปฏิบัติการโยกย้ายแพลตฟอร์มดังกล่าวไม่ได้เป็นเรื่องเล็กน้อยและต้องคำนึงถึงองค์ประกอบที่ดีของการทำงานภายในของแต่ละแพลตฟอร์มและเหนือสิ่งอื่นใดวิธีที่พวกเขาใช้การสนับสนุนสำหรับองค์ประกอบที่สำคัญที่สุดของการจัดการข้อมูลนั่นคือธุรกรรม

แม้ว่าฉันจะพูดถึงแพลตฟอร์ม RDBMS สองแพลตฟอร์มที่เป็นหัวใจหลักของความเชี่ยวชาญ แต่คำเตือนเดียวกัน -“ ดูเหมือนไม่ได้หมายความว่าทำงานเหมือนกัน” - ควรใช้กับการย้ายโค้ดระหว่างระบบการจัดการฐานข้อมูลที่รองรับ SQL อื่น ๆ และในทุกกรณีจุดสนใจแรกควรอยู่ที่การดำเนินการจัดการธุรกรรมแตกต่างกันอย่างไรระหว่างแพลตฟอร์มต้นทางและแพลตฟอร์มเป้าหมาย

ทำความเข้าใจพื้นฐาน

ความสอดคล้องของข้อมูลใน Oracle คืออะไร?

ใน Oracle ความสอดคล้องของข้อมูลขึ้นอยู่กับการกำหนดเวอร์ชันหลายเวอร์ชัน: ข้อมูลเวอร์ชันใด ๆ ที่อ้างถึงจุดเดียวในเวลาควรอยู่ในสถานะที่ไม่มีการละเมิดข้อ จำกัด ของฐานข้อมูลที่ใช้งานอยู่

ความสม่ำเสมอในการอ่านใน Oracle คืออะไร?

ความสอดคล้องในการอ่านของ Oracle คือการรับประกันระดับคำสั่ง SQL ว่าข้อมูลทั้งหมดจะถูกส่งคืนในสถานะที่สอดคล้องกันตามที่เป็นอยู่ ณ เวลาที่ส่งคำสั่งเพื่อดำเนินการ เพื่อสนับสนุนสิ่งนี้ Oracle จัดการข้อมูลหลายเวอร์ชันที่สอดคล้องกับหลายจุดในเวลา

การตรวจสอบความสอดคล้องของฐานข้อมูลคืออะไร?

การตรวจสอบความสอดคล้องของฐานข้อมูลเป็นกระบวนการตรวจสอบว่าฐานข้อมูลอยู่ในสถานะที่สอดคล้องกันและไม่มีบล็อกข้อมูลที่ขาดหายไปหรือเสียหาย ควรดำเนินการในการสำรองข้อมูลและบนฐานข้อมูลที่มีการเรียกคืนฟังก์ชันการทำงานหลังจากฮาร์ดแวร์ล้มเหลว

ขนาดหน้าจอแบบสอบถามสื่อ css

ความสอดคล้องของข้อมูลใน SQL คืออะไร?

ในฐานข้อมูลที่เข้ากันได้กับ SQL ความสอดคล้องของข้อมูลหมายถึงสถานะของข้อมูลที่ไม่มีการละเมิดข้อ จำกัด ของฐานข้อมูลที่ใช้งานอยู่ นี่คือข้อกำหนดพื้นฐานที่ต้องปฏิบัติตามเมื่อสิ้นสุดการทำธุรกรรมใด ๆ

คำพ้องความหมายส่วนตัวและคำพ้องความหมายสาธารณะใน Oracle คืออะไร

คำพ้องความหมายส่วนตัวของ Oracle ถูกสร้างขึ้นในสคีมาเฉพาะและสามารถเข้าถึงได้ผ่านการอ้างอิงสคีมาในลักษณะเดียวกับออบเจ็กต์สคีมาอื่น ๆ ในทางกลับกันคำพ้องความหมายสาธารณะถูกสร้างขึ้นในกลุ่ม PUBLIC และสามารถเข้าถึงได้โดยไม่ต้องอ้างอิงสคีมา