Oracle ไปยัง SQL Server และ SQL Server ไปยัง Oracle Migration Guide

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

สองแพลตฟอร์ม RDBMS ระดับองค์กรที่แพร่หลายมากที่สุดคือ Oracle Database และ Microsoft SQL Server (เพื่อให้กระชับ สำหรับส่วนที่เหลือของบทความนี้ ฉันจะเรียกพวกเขาว่า "Oracle" และ "SQL Server" ตามลำดับ) แน่นอนว่า IBM Db2 แข่งขันกับ Oracle ในแพลตฟอร์มเมนเฟรมที่ลดขนาดลงแต่ยังคงมีความสำคัญในหลายพื้นที่ และทางเลือกโอเพนซอร์ซที่ก้าวหน้าอย่างรวดเร็ว เช่น PostgreSQL กำลังได้รับสถานะที่มั่นคงในสภาพแวดล้อมแบบไดนามิกบนฮาร์ดแวร์สินค้าโภคภัณฑ์ระดับต่ำถึงกลางและบนเว็บ

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

ทั้ง Oracle และ SQL Server เป็นการใช้งาน RDBMS แบบ "โรงเรียนเก่า" บางส่วนที่สอดคล้องกับ ANSI เมื่อละเว้นส่วนขยายขั้นตอน—PL/SQL และ Transact-SQL มีไวยากรณ์ต่างกัน แต่โดยทั่วไปแล้วจะง่ายต่อการแปลระหว่าง—และฟิวเจอร์สเชิงวัตถุที่ใหม่กว่า โค้ด SQL อาจดูคล้ายกันอย่างหลอกลวง และนี่คือกับดักน้ำผึ้งที่อันตราย

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

การทำความเข้าใจโครงสร้างธุรกรรม: การสังเกต Oracle กับ SQL Server จากหมื่นฟุต

ธุรกรรมของ Oracle เป็นไปโดยปริยาย หมายความว่าคุณไม่จำเป็นต้องเริ่มทำธุรกรรม—คุณอยู่ในธุรกรรมเสมอ และธุรกรรมนี้เปิดอยู่จนกว่าคุณจะออกคำสั่งยืนยันหรือย้อนกลับ ได้ คุณสามารถเริ่มต้นธุรกรรมอย่างชัดเจน กำหนดจุดปลอดภัยในการย้อนกลับ และตั้งค่าธุรกรรมภายใน/ที่ซ้อนกัน แต่สิ่งที่สำคัญคือคุณไม่เคย "ไม่อยู่ในธุรกรรม" และคุณต้องออกคำสั่งหรือย้อนกลับเสมอ นอกจากนี้ โปรดทราบด้วยว่าการออกคำสั่ง data definition language (DDL) ( CREATE , ALTER ฯลฯ ; ในทรานแซกชันสามารถทำได้ผ่านไดนามิก SQL) จะทำธุรกรรมที่ออก

ต่างจาก Oracle ตรงที่ SQL Server มีทรานแซกชันที่ชัดเจน ซึ่งหมายความว่าหากคุณไม่ได้เริ่มต้นธุรกรรมอย่างชัดเจน การเปลี่ยนแปลงทั้งหมดของคุณจะถูกคอมมิต "โดยอัตโนมัติ"—ทันทีที่คำสั่งของคุณได้รับการประมวลผล เนื่องจากทุกคำสั่ง DML ( INSERT , UPDATE , DELETE ) จะสร้างธุรกรรมขึ้นมาเองและดำเนินการเว้นแต่จะเกิดข้อผิดพลาด ออก.

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

ใน Oracle คำสั่ง DML จะเปลี่ยนระเบียนในไฟล์ข้อมูลโดยตรง สำเนาเก่าของเร็กคอร์ด (หรือการแทนที่เร็กคอร์ดที่ว่างเปล่า ในกรณีของ INSERT ) ถูกเขียนไปยังไฟล์ย้อนกลับปัจจุบัน และเวลาที่แน่นอนของการเปลี่ยนแปลงจะถูกทำเครื่องหมายบนเร็กคอร์ด

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

นี่คือวิธีที่ Oracle ใช้ความสอดคล้องในการอ่านและการไม่บล็อกการอ่าน/เขียน นอกจากนี้ยังเป็นสาเหตุที่การสืบค้นที่ใช้เวลานานในฐานข้อมูลธุรกรรมที่ใช้งานมากในบางครั้งอาจพบข้อผิดพลาดที่น่าอับอาย ORA-01555 ส snapshot too old: rollback segment ... too small (ซึ่งหมายความว่าไฟล์ย้อนกลับที่จำเป็นสำหรับการสืบค้นสำหรับเรกคอร์ดรุ่นเก่านั้นถูกใช้ซ้ำแล้ว) นี่คือสาเหตุที่คำตอบที่ถูกต้องสำหรับคำถาม "ธุรกรรม Oracle ของฉันควรใช้เวลานานเท่าใด" คือ “นานเท่าที่จำเป็นและไม่อีกต่อไป”

การใช้งาน SQL Server แตกต่างกัน: กลไกจัดการฐานข้อมูลจะเขียนและอ่านโดยตรงไปยัง/จากไฟล์ข้อมูลเท่านั้น ทุกคำสั่ง SQL ( SELECT / INSERT / UPDATE / DELETE ) เป็นธุรกรรม เว้นแต่จะเป็นส่วนหนึ่งของธุรกรรมที่ชัดเจนซึ่งจัดกลุ่มคำสั่งหลายรายการไว้ด้วยกัน ทำให้สามารถย้อนกลับการเปลี่ยนแปลงได้

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

และโครงสร้าง SQL ใดใน Oracle และ SQL Server ที่ได้รับผลกระทบจากความแตกต่างในการใช้งานธุรกรรมของพวกเขา ตารางอุณหภูมิ

ตารางชั่วคราวใน Oracle และ SQL Server

เมื่อมาตรฐาน ANSI SQL กำหนดตารางชั่วคราวในเครื่องและทั่วโลก จะไม่ระบุชัดเจนว่าควรใช้งานอย่างไร ทั้ง Oracle และ SQL Server ใช้ตารางชั่วคราวทั่วโลก SQL Server ยังใช้ตารางชั่วคราวในเครื่อง Oracle 18c ยังใช้ตารางชั่วคราวในเครื่องที่ "จริง" (ซึ่งเรียกว่า "ตารางชั่วคราวส่วนตัว") ซึ่งทำให้การแปลโค้ด SQL Server เป็น Oracle 18c ง่ายกว่าเวอร์ชันเก่าอย่างเห็นได้ชัด โดยเพิ่มส่วนที่เกี่ยวข้องบางส่วนก่อนหน้านี้ของ Oracle คุณลักษณะต่างๆ เช่น คอลัมน์ข้อมูลประจำตัวที่เพิ่มค่าอัตโนมัติ

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

กล่าวโดยย่อ ฉันไม่เห็นกรณีการใช้งานสำหรับตารางชั่วคราวส่วนตัวใน Oracle ที่ไม่สามารถใช้งานได้โดยใช้ตารางชั่วคราวทั่วโลกเหมือนกันหรือดีกว่า ดังนั้นสำหรับการแปลงที่ร้ายแรง เราจำเป็นต้องเข้าใจความแตกต่างระหว่างตารางชั่วคราวทั่วโลกของ Oracle และ SQL Server

ตารางชั่วคราวทั่วโลกใน Oracle และ SQL Server

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

ใน SQL Server ตารางชั่วคราวส่วนกลางคืออ็อบเจ็กต์ชั่วคราวที่สร้างขึ้นในบล็อกของรหัส Transact-SQL มีอยู่ตราบใดที่เซสชันการสร้างเปิดอยู่ และเซสชันอื่นๆ ในฐานข้อมูลสามารถมองเห็นได้ ทั้งในโครงสร้างและข้อมูล ดังนั้นจึงเป็นออบเจ็กต์ชั่วคราวส่วนกลางสำหรับการแชร์ข้อมูลข้ามเซสชัน

ตารางชั่วคราวภายในเครื่องใน SQL Server แตกต่างจากตารางส่วนกลางโดยสามารถเข้าถึงได้เฉพาะในเซสชันที่สร้างตารางดังกล่าว และการใช้ตารางชั่วคราวในเครื่องใน SQL Server นั้นแพร่หลายมากขึ้น (และฉันจะพูดได้ว่ามีความสำคัญต่อประสิทธิภาพของฐานข้อมูลมากกว่า) มากกว่าการใช้ตารางชั่วคราวทั่วโลก

ดังนั้นตารางชั่วคราวในเครื่องใช้ใน SQL Server อย่างไรและควรแปลเป็น Oracle อย่างไร

การใช้ตารางชั่วคราวในเครื่อง (และถูกต้อง) ที่สำคัญใน SQL Server คือการย่อหรือลบการล็อกทรัพยากรธุรกรรม โดยเฉพาะ:

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

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

เป็นที่น่าสังเกตว่านิพจน์ตารางทั่วไป (CTEs เช่นคำสั่ง WITH <alias> AS (SELECT...) ) ใน SQL Server เป็นเพียง "syntax sugar" พวกมันจะถูกแปลงเป็นแบบสอบถามย่อยแบบอินไลน์ก่อนดำเนินการ SQL Oracle CTE (ที่มี /*+ materialize */ คำใบ้) ได้รับการเพิ่มประสิทธิภาพและสร้างเวอร์ชันชั่วคราวของมุมมองที่เป็นรูปธรรม ในเส้นทางการดำเนินการของ Oracle CTE เข้าถึงข้อมูลต้นทางเพียงครั้งเดียว จากความแตกต่างนี้ SQL Server อาจทำงานได้ดีขึ้นโดยใช้ตารางชั่วคราวในเครื่องแทนการอ้างอิงหลายรายการไปยัง CTE เดียวกัน ซึ่งสามารถทำได้ในการสืบค้นของ Oracle

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

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

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

ป้อนตัวแปรตาราง

นักพัฒนาอาจสงสัยว่า: แล้วตัวแปรตารางล่ะ? เราจำเป็นต้องทำการเปลี่ยนแปลงใดๆ หรือเราสามารถย้ายตัวแปรตาราง "ตามที่เป็น" ในขั้นตอนการย้าย Oracle-to-SQL-Server ได้หรือไม่ ขึ้นอยู่กับสาเหตุและวิธีการใช้ในโค้ด

มาดูกันว่าทั้งตารางชั่วคราวและตัวแปรตารางสามารถใช้ได้อย่างไร ฉันจะเริ่มต้นด้วย Microsoft SQL Server

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

นี่เป็นทฤษฎี แต่ข้อควรพิจารณาในการใช้งานจริงนั้นเกี่ยวข้องมากกว่าเล็กน้อย

งานแรกกับการปรับให้เหมาะสม Transact-SQL อย่างจริงจังเมื่อฉันมาจากพื้นหลัง Oracle ที่ฝังรากลึก ฉันคาดว่ามันจะเป็นแบบนี้: ตัวแปรตาราง อยู่ในหน่วยความจำในขณะที่ ตารางชั่วคราว อยู่บนดิสก์ แต่ฉันพบว่า Microsoft SQL Server เวอร์ชันจนถึงปี 2014 ไม่ได้เก็บตัวแปรตารางไว้ในหน่วยความจำ ดังนั้นการสแกนตารางแบบเต็มบนตัวแปรชั่วคราวจึงเป็นการสแกนตารางแบบเต็มบนดิสก์ โชคดีที่ SQL Server 2017 และเวอร์ชันที่ใหม่กว่าสนับสนุนการปรับหน่วยความจำที่ประกาศให้เหมาะสมสำหรับทั้งตารางชั่วคราวและตัวแปรตาราง

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

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

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

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

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

ธุรกรรมภายใน (“ธุรกรรมที่ซ้อนกัน”)

ในแง่ของความท้าทายในการโยกย้าย Oracle ไปยัง SQL Server ประเด็นหลักต่อไปที่ต้องพิจารณาคือธุรกรรมที่ซ้อนกัน

เช่นเดียวกับตารางชั่วคราว หากโค้ด Transact-SQL มีธุรกรรม ใดๆ ที่ซ้อนกันหรือไม่ก็ตาม หรือโค้ดของ Oracle มีธุรกรรมที่ซ้อนกัน เรากำลังพูดถึงไม่ใช่แค่การย้ายโค้ดธรรมดาเท่านั้น แต่ยังรวมถึงการปรับใช้งานฟังก์ชันอีกด้วย

อันดับแรก มาดูกันว่าธุรกรรมที่ซ้อนกันของ Oracle ทำงานอย่างไรและเรามีแนวโน้มที่จะใช้งานอย่างไร

ธุรกรรมที่ซ้อนกันใน Oracle

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

ดังนั้นธุรกรรมแบบซ้อนจะใช้ที่ไหน? ในโค้ด PL/SQL โดยเฉพาะอย่างยิ่งในกระบวนการอิสระ—ซึ่งประกาศด้วย PRAGMA AUTONOMOUS_TRANSACTION หมายความว่าเมื่อมีการเรียกรหัสนี้ (เป็นกระบวนงานที่เก็บไว้ที่มีชื่อหรือไม่ระบุชื่อ) ธุรกรรมจะถูกยืนยันหรือย้อนกลับโดยไม่ขึ้นกับธุรกรรมที่เรียกว่ารหัสนี้

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

ธุรกรรมที่ซ้อนกันในโค้ด SQL Server Transact-SQL นั้นแตกต่างอย่างสิ้นเชิง

ธุรกรรมที่ซ้อนกันใน SQL Server

ใน Transact-SQL การทำธุรกรรมภายในนั้นสมบูรณ์หรือไม่นั้นขึ้นอยู่กับธุรกรรมภายนอกสุด หากธุรกรรมภายในถูกย้อนกลับ ธุรกรรมนั้นก็แค่ย้อนกลับ แต่ถ้ามีการทำธุรกรรมภายในเกิดขึ้น ก็ยังคงไม่มีความมุ่งมั่น อย่างเต็มที่ เนื่องจากสามารถย้อนกลับได้หากมีการย้อนกลับธุรกรรมขอบเขตภายนอกในระดับใด

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

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

ปัจจัยอื่นๆ

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

1. คอลัมน์ข้อมูลประจำตัวใน SQL Server
2. ลำดับใน Oracle
3. คำพ้องความหมายใน Oracle
4. ดัชนีกรอง
5. ความสอดคล้องในการอ่าน (Oracle to SQL Server เท่านั้น)
6. การใช้เครื่องมือการโยกย้าย

ส่วนต่อไปของซีรีส์นี้ยังคงดำเนินต่อไปโดยการสำรวจสิ่งเหล่านี้ โดยเฉพาะสามส่วนแรก

ตารางชั่วคราว ตัวแปรตาราง/คอลเลคชัน และธุรกรรมที่ซ้อนกัน: จุดปวดเมื่อยในการย้ายข้อมูล 3 อันดับแรก

ฉันเริ่มต้นด้วยตารางชั่วคราว ตัวแปรตาราง/คอลเลกชั่น และธุรกรรมที่ซ้อนกัน เนื่องจากสิ่งเหล่านี้เป็นจุดที่พบบ่อยและชัดเจนที่สุดของความล้มเหลวในการแปลงโปรเจ็กต์ ระบบที่ไม่สำคัญใดๆ ใน Oracle Database หรือ Microsoft SQL Server จะใช้ระบบบางระบบอย่างไม่ต้องสงสัย และการใช้องค์ประกอบเหล่านี้มีความเกี่ยวข้องอย่างมากกับการออกแบบเฉพาะของการสนับสนุนธุรกรรมโดยการใช้งาน RDBMS ที่เกี่ยวข้อง

อ่านต่อในภาค 2!