คู่มือการย้าย Oracle ไปยัง SQL Server และ SQL Server ไปยัง Oracle - Pt. 3

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

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

ความสอดคล้องในการอ่านของ Oracle และเทียบเท่าใน 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 กับเร็กคอร์ดที่ตรงกับเกณฑ์การค้นหาของคุณ

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

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

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

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

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

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

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

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

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

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

คำพ้องความหมายสาธารณะสำหรับทีมการปรับขนาด: 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

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

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

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

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

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

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

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

ทวีต

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

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

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

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

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

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

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

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

ข้อผิดพลาดที่พบบ่อยที่สุดที่ 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 มีการจำแนกชื่อสามระดับ (ฐานข้อมูล – สคีมา/เจ้าของ – ชื่ออ็อบเจ็กต์)

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

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

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

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

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

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

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

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

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

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

การโยกย้ายเซิร์ฟเวอร์ Oracle/SQL: มองให้ใกล้ขึ้นเสมอ

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

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

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

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