การ Migrate ฐานข้อมูลจาก Microsoft SQL Server Database Engine ไปยัง Azure SQL Database ในหลายรูปแบบ

การ Migrate ฐานข้อมูลจาก Microsoft SQL Server Database Engine ไปยัง Azure SQL DB ในหลายรูปแบบ
ผู้เขียนได้รับการสอบถามเกี่ยวกับการ Migrate ฐานข้อมูลจากที่ใช้อยู่ ใน Microsoft SQL Server (On-premise) ขึ้นไปไว้บน Azure SQL DB ยากไหม ทำได้อย่างไร และมีข้อควรคำนึงอะไรไหม
เริ่มต้นจาก George Huey และ Wade Wegner ได้โพสต์ SQL Azure Migration Wizard ลงใน CodePlex ในปี ค.ศ. 2009 ซึ่งเป็นแหล่งรวมโปรเจค Open Source ของ Microsoft (ปัจจุบัน CodePlex ถูกยุบไปรวมไว้ใน github แล้ว) และไม่พัฒนาต่อตั้งแต่ปี 2014 ซึ่งเครื่องมือตัวนี้สามารถ Migrate ได้ทั้งโครงสร้างฐานข้อมูล (Schema) และข้อมูล (Data)
เครื่องมือ | Schema | Data |
SQL Azure Migration Wizard
|
Yes | Yes |
Data Migration Assistant
|
Yes | Yes |
Data-Tier Application
|
Yes | Yes |
SQL Azure Data Sync Service
|
Yes | Yes |
Azure Database Migration Service
|
Yes | Yes |
SSMS Generate Script Wizard
|
Yes | Yes |
BCP
|
No | Yes |
SSDT
|
No | Yes |
ในเวลาถัดมา Microsoft เร่งพัฒนาเครื่องมือออกมาอย่างต่อเนื่อง และดูเหมือนจะต้องใช้งานได้ง่ายขึ้นเรื่อย ๆ เพื่อจูงใจให้ผู้คนหันมาใช้ Cloud กันมากขึ้น อาทิ เครื่องมือชื่อว่า Data Migration Assistant (DMA) ที่พัฒนาโดย Microsoft เอง เป็นเครื่องมือแจกฟรี สามารถ Migrate ได้ทั้งโครงสร้างฐานข้อมูล และข้อมูล เช่นกัน อีกทั้งยังสามารถวิเคราะห์หา
- อุปสรรคที่ขวางไม่ให้ Migrate (Migration blocking issues) ไปยังระบบเป้าหมาย
- คุณสมบัติที่ไม่ได้รับการสนับสนุน (Unsupported features) ในระบบเป้าหมาย
- คุณสมบัติที่ได้รับการสนับสนุนเพียงบางส่วน (Partially-supported Features) ในระบบเป้าหมาย
ผู้อ่านสามารถดาวน์โหลดจาก Download Center ตามลิ้งก์นี้ https://www.microsoft.com/en-us/download/details.aspx?id=53595
นอกเหนือจากนั้นยังมีเครื่องมืออีกตัวหนึ่งอยู่ในรูปแบบบริการบน Azure ชื่อว่า Azure Database Migration Service ซึ่งเป็นบริการที่มีค่าใช้จ่ายเกิดขึ้นตามปริมาณการใช้
ผู้เขียนจึงข้อยกเว้นไม่นำเสนอกับเครื่องมือฟรีที่จะพูดในบทความนี้ แต่ทาง Microsoft แจ้งไว้ว่าเครื่องมือนี้ใช้ Migrate ทั้งฐานข้อมูล และ Instance Objects อาทิ User accounts, Agent Jobs และ packages ของ SQL Server Integration Services (SSIS) โดยแทบไม่มี Downtime เกิดขึ้นเลย
สำหรับบทความนี้ผู้เขียนต้องการนำเสนอการใช้ Data-Tier Application (DAC) เพื่อดำเนินการ Migrate
โดย DAC นั้นถูกบรรจุมากับ Microsoft SQL Server 2008 R2 มีความสามารถในการบรรจุ Database Objects ของฐานข้อมูลเป้าหมาย
และรวมไปถึง Instance Objects บางอย่างที่เกี่ยวข้องกับฐานข้อมูลเป้าหมาย ลงในไฟล์เดียว เพื่อสามารถนำไป Deploy ลงระบบเป้าหมายได้ง่าย ๆ จะมีไฟล์สำคัญอยู่ 2 ชนิดดังนี้
นามสกุลไฟล์ | ต้นทาง | ปลายทาง |
.dacpac |
Extract โครงสร้าง
|
Deploy โครงสร้าง
|
.bacpac |
Export โครงสร้างและข้อมูล
|
Import โครงสร้างและข้อมูล
|
ผู้อ่านสามารถทดลองผ่าน SSMS โดยไปที่เมนู Task ของฐานข้อมูลใด ๆ ได้ดังแสดง
หากต้องการ Migrate เฉพาะโครงสร้างให้เลือก Extract Data-Tier Application ไฟล์ที่ได้จะมีนามสกุล .dacpac
แต่หากต้องการ Migrate ทั้งโครงสร้างและข้อมูลให้เลือก Export Data-Tier Application ไฟล์ที่ได้จะมีนามสกุล .bacpac
แต่หากต้องการนำขึ้นทั้งโครงสร้างและข้อมูลในครั้งเดียวจบไม่ต้องส่งออกเป็นไฟล์แล้วไปนำขึ้นเอง
ก็จะมีเมนู Deploy Database to Microsoft Azure SQL Database ให้เลือกใช้เบื้องหลังการทำงานคือ ไฟล์นามสกุล .bacpac เช่นกัน


Data Migration Assistant (DMA)
DMA สามารถนำไปใช้งานเพื่อทำการประเมิน (Assessment) ก่อนการ Migrate หรือจะใช้เพื่อการ Migrate เลยก็ได้
ในบทความนี้ผู้เขียนขอแสดงตัวอย่างหน้าจอ Wizard บางหน้าเพื่อให้เห็นเบื้องหลังการทำงาน พอสังเขป

แสดงให้เห็นว่า DMA ไม่ได้ใช้ DAC เป็นตัวดำเนินการ เป็นเพียงการใช้ TSQL Script ธรรมดา

การสร้างเป็น Script แล้วนำไปรันนั้น ผู้เขียนไม่ค่อยอยากแนะนำเท่าไหร เพราะหาก Script ไม่ได้ประกาศเป็น Transaction ก็ยากที่จะควบคุมความถูกต้องสอดคล้อง (Data Integrity and Data Consistency)
หากถูกขัดจังหวะกลางคัน ทำให้ไม่ทราบว่าดำเนินการไปถึงบรรทัดไหนแล้ว หากรันใหม่ข้อมูลก็จะซ้ำซ้อนถ้าไม่มี Constraint บังคับ
แต่หากมี Constraint บังคับก็จะรันซ้ำไม่ได้ ทางที่ดีที่สุดคือนับหนึ่งใหม่ โดยลบปลายทางทิ้งเริ่มกันใหม่ หากทำกี่ครั้งไม่สำเร็จสักที ก็น่าจะท้อได้
ดังนั้นหากจะใช้ DMA เพื่อการ Migrate อาจพิจารณาใช้กับฐานข้อมูลที่มีขนาดเล็ก
การนำไฟล์นามสกุล .bacpac ขึ้น Azure blob storage ก่อน Migrate
ในบรรดาแนวทางการใช้งานแบบประหยัดยังไม่พึ่ง Azure Database Migration Service นั้น ผู้เขียนชอบดำเนินการตามขึ้นตอนดังนี้- Export Data-Tier Application ออกไปเป็นไฟล์นามสกุล .bacpac เสียก่อน
- จากนั้นสร้าง Azure blob storage บน Resource Group เดียวกันกับ Azure SQL Database Server ซึ่งมีค่าใช้จ่ายถูกกว่า Azure Database Migration Service
- นำไฟล์นามสกุล .bacpac ขึ้นไปไว้บน Azure blob storage
- ใช้เมนู Import ในหน้า Azure SQL Database Server บน Azure Portal
เนื่องจากไฟล์นามสกุล .bacpac เป็น Package ที่ห่อหุ้มทั้ง Database Objects และ Instance Objects บางอย่างที่จำเป็นเอาไว้
และเอาไปนำเข้าที่ระบบเป้าหมาย ดังนั้นหมดกังวลเรื่องการควบคุมความถูกต้องสอดคล้อง (Data Integrity and Data Consistency) ไปได้เลย
และการนำขึ้นไว้ Azure blob storage บน Resource Group เดียวกัน หากนำขึ้นไฟล์สำเร็จ ก็แน่ใจได้ว่าการดำเนินการ Migrate ทำใน Local (หากมองว่า Resource Group คล้ายกับการอยู่ในวงLAN เดียวกัน)
สังเกตเมนู Import Database บนหน้าจอในการจัดการ Azure SQL Database Server

ในที่นี้ผู้เขียนแสดงเพียงไฟล์ที่ถูกเลือกมาแล้ว เพื่อนำเข้า

เมื่อกดปุ่ม OK ก็จะเริ่มนำเข้าจนเสร็จสมบูรณ์ ผู้อ่านสามารถติดตามสถานะงานได้ผ่าน Notifications ดังแสดง

เป็นอีกวิธีที่ผู้เขียนไม่แนะนำ เพราะเป็นการสร้าง TSQL Script ของโครงสร้างฐานข้อมูลขึ้นมาให้เหมาะสมกับระบบเป้าหมายที่เลือกไว้ก่อนหน้า
จากนั้นสร้าง TSQL Script เพื่อนำเข้าข้อมูลผ่านคำสั่ง INSERT INTO โดยแบ่งเป็น Batch ละ 100 แถวข้อมูลจนกว่าจะเสร็จ ซึ่งแน่นอนว่าหาก Script ไม่ได้ประกาศเป็น Transaction
ก็ยากที่จะควบคุมความถูกต้องสอดคล้อง (Data Integrity and Data Consistency) หากถูกขัดจังหวะกลางคัน
สามารถเรียกใช้ผ่านเมนู Task บนานข้อมูลใด ๆ แล้วเลือก Generate Script จะปรากฏ Wizard พาไปดำเนินการตามขั้นตอน
สรุป
ไม่ว่าจะเลือกใช้เครื่องมือใด สิ่งที่สำคัญที่สุด คือ ความครบถ้วนของข้อมูลและความต่อเนื่องในการทำงานโดยปกติแล้วจะมีการตกลงกันกับเจ้าของระบบว่าระบบใหม่จะขึ้นเมื่อไหร่ และวิธีการวัดว่าข้อมูลมาครบถ้วนไหม ในเรื่องนี้ต่างหากที่ผู้อ่านควรคำนึงถึง
โดยการ Migrate ไม่ว่าจะใช้เครื่องมือใดต้องซ้อมก่อนบนเครื่องทดสอบจนแน่ใจว่าวิธีการที่เลือกใช้ถูกต้องวัดผลได้
และระยะเวลาดำเนินการที่อาจก่อให้เกิด Downtime นั้นอยู่ในเงื่อนไขที่รับได้ อาจจะเป็นการนำขึ้นข้อมูลเก่าก่อน
และวันสุดท้ายก่อน Cut-off ค่อยนำที่เหลือขึ้น เพราะก่อให้เกิด Downtime ต่ำที่สุด ทำนองนี้ ซึ่งต้องไปหาเครื่องมือที่เหมาะสม และแนวทางจัดการที่เหมาะสมกันเอาเอง
ท้ายที่สุดสำหรับ Azure Database Migration Service ผู้เขียนจะนำเสนอให้บทความถัดไป
และผู้เขียนกำลังออกแบบหลักสูตรอบรมเกี่ยวกับการจัดหา การเตรียมทรัพยากร เพื่อการติดตั้งใหม่ การอัพเกรด และการ Migrate เป็นหลักสูตรที่จะเปิดใหม่ให้กับสถาบัน 9Expert สามารถติดตามกันได้ครับ