ฉันควรโอนย้ายข้อมูลโดยใช้ detach / copy / attach หรือผ่าน backup-restore-replay หรือไม่

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

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

ฉันเดาคำถามของฉันหรือไม่ว่าฉันมีเหตุผลในความสงสัยของตัวเลือก BACKUP-RESTORE-Replay และข้อดีหรือความเสี่ยงอื่นของตัวเลือกนั้นคืออะไร

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

ด้วยการสำรองข้อมูล / กู้คืนคุณจะไม่เสี่ยงที่จะไปที่แผน B หากการสำรองข้อมูลล้มเหลวฐานข้อมูลของคุณจะยังคงอยู่ หากการกู้คืนล้มเหลวฐานข้อมูลเก่าของคุณยังคงอยู่ ในทั้งสองกรณีคุณสามารถกู้คืนการดำเนินการของฐานข้อมูลต้นฉบับและกลับมาทบทวนแผนในภายหลัง นอกเหนือจากการรักษาความปลอดภัยเพิ่มเติมที่นี่ในการหยุด SQL Server และ / หรือการถอดออกซึ่งหมายความว่าคุณสามารถทดสอบวิธีการสำรองข้อมูล / เรียกคืน hoo-out (สมมติว่าคุณมีพื้นที่ในการสำรองข้อมูลและอินสแตนซ์อื่นเพื่อทดสอบ เรียกคืน) คุณไม่สามารถทดสอบวิธีการแยกออกได้โดยไม่ต้องถอดฐานข้อมูลหรือหยุด SQL Server และยากที่จะทำนอกหน้าต่างการบำรุงรักษาที่เหมาะสม และสุดท้ายด้วยวิธีการอื่นคุณไม่สามารถแม้แต่จะเริ่มคัดลอกไฟล์ได้จนกว่าคุณจะแยกหรือทำให้ SQL Server ล่ม

ข้อดีอีกประการหนึ่งของวิธีการดึงออกจากไดรฟ์ภายใต้ SQL-Server: ด้วยการสำรองข้อมูล / คืนค่าคุณสามารถย้ายไฟล์ต่าง ๆ ไปยังตัวอักษรไดรฟ์ที่แตกต่างจากที่เคยมีมา ตัวอย่างเช่นเมื่อเราย้ายไปยัง SAN ใหม่เราสามารถมีปริมาณเพิ่มขึ้นดังนั้นเราจึงสามารถย้าย tempdb ไปที่ T: \ (ซึ่งไม่เคยมีมาก่อน) ข้อมูลและไฟล์บันทึกบางส่วนไปยังตัวอักษรไดรฟ์ใหม่ ฯลฯ เพื่อใช้ประโยชน์จากความสามารถ I / O ใหม่ทั้งหมดที่เรามี ถ้าคุณเพียงแค่ปิดระบบเซิร์ฟเวอร์ SQL จากนั้นสลับดิสก์คุณจะต้องมีตัวอักษรไดรฟ์ที่เหมือนกันและมีปริมาณเท่ากัน

ฉันใช้เพื่อย้ายฐานข้อมูลเกือบตลอดเวลาเนื่องจากการกำหนดค่า SAN ใหม่และการย้ายข้อมูล

สมมติว่าคุณกำลังย้ายเซิร์ฟเวอร์ทั้งหมดในเวลาเดียวกันฉันจะไปกับเส้นทางของคุณ # 2 (ถ้าคุณย้ายฐานข้อมูลทีละหนึ่งและในที่สุดก็ทำทุกฐานข้อมูลบนเซิร์ฟเวอร์นั่นจะเป็นปัญหามากกว่าเพราะคุณจะต้องเปลี่ยนพา ธ ไปยังไฟล์)

โปรดทราบว่า "single_user" ไม่ได้แปลว่าคุณ คุณสามารถไปที่ DBCC CHECKDB ฐานข้อมูลและไม่สามารถเข้าไปได้เพราะมีบางคนอยู่ในนั้น เตรียมสคริปต์ที่คุณสามารถเรียกใช้เพื่อบูต "ทุกคน แต่คุณ" ออกจากฐานข้อมูลและเก็บไว้ในที่ที่สะดวก โปรดทราบว่า SQL 2000 ไม่มีคุณลักษณะ "กันทุกคน" เหมือนกับรุ่นที่ทันสมัยกว่า

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

การมีวิธีที่จะป้องกันไม่ให้ผู้ใช้แอปทั้งหมดอยู่ในเซิร์ฟเวอร์จนกว่าคุณจะทำงานเสร็จ มิฉะนั้นการเชื่อมต่ออาจเริ่มต้นขึ้นมาในขณะที่คุณพยายามทำสิ่งต่าง ๆ ที่อาจนำไปสู่การช่วงชิงทรัพยากรและ / หรือความเชื่องช้า ฉันใช้วิธีต่อไปนี้ในอดีตโดยขึ้นอยู่กับสถานการณ์ที่แน่นอน: ปิดเซิร์ฟเวอร์แอปการใช้ฐานข้อมูล ALTER .. SET RESTRICTED_USER (หากบัญชีแอปเป็นสมาชิกของบทบาท db_owner, sysadmin หรือ dbcreator นั่นเป็นปัญหา ) บอกผู้ใช้ว่าระบบจะออฟไลน์ในเวลาที่กำหนดเช่นเช้าวันอาทิตย์ (สิ่งนี้จะไม่ทำงานในสภาพแวดล้อม 24x7 แบบ "ของจริง") ถอดปลั๊ก NIC ที่หันหน้าไปทางแอปเซิร์ฟเวอร์หรือผู้ใช้ (ในกรณีนี้ฉันสามารถเชื่อมต่อผ่าน NIC อื่นที่เชื่อมต่อกับเครือข่ายผู้ดูแลระบบเท่านั้นหรือผ่าน ILO)

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

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

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

โดยทั่วไปฉันใช้ ROBOCOPY เพื่อทำงานประเภทนี้ มีสวิตช์บรรทัดคำสั่งเพื่อรักษา ACLs

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

หลังจากที่ฉันคัดลอกไฟล์ แต่ก่อนที่ฉันจะรีสตาร์ทอินสแตนซ์ฉันจะไปและเปลี่ยน filepath ของโฟลเดอร์ OLD โดยการเปลี่ยนชื่อหนึ่งในโฟลเดอร์ นี่คือการตรวจสอบเพิ่มเติมกับ "อุ๊ปส์เซิร์ฟเวอร์ยังคงชี้ไปที่ไฟล์เก่า" ปัญหา

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

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

ปัญหาที่น่าสนุกอีกอย่างคือ SAN กำลังช้าโดยไม่มีเหตุผลที่ชัดเจน หากคุณคิดว่าจะใช้เวลา 10 ชั่วโมงในการคัดลอกข้อมูลของคุณและคุณถูกคัดลอก 30% ที่หมายเลขชั่วโมงที่ 9 แสดงว่าคุณมีปัญหา ดูเวลาถ่ายโอน (robocopy แสดง% คัดลอกและให้เวลาโดยประมาณหรือคุณสามารถใช้ Perfmon) และมีแผนสำรองหากมีบางอย่างผิดปกติ

นอกจากนี้ฉันไม่แน่ใจว่าไดรฟ์ข้อมูลของคุณจะได้รับการแบ่งพาร์ติชันให้คุณหรือไม่ แต่คุณอาจต้องการตรวจสอบให้แน่ใจว่ามีการใช้ออฟเซ็ต 1 MB สำหรับ Windows Server 2008 และที่ดีกว่านี้ไม่น่าจะมีปัญหา สำหรับ OS ที่เก่ากว่าก็คือ มีสิ่งที่เป็น googlable มากมายในที่นี้และที่เก็บข้อมูลของคุณควรรู้เกี่ยวกับมัน แต่ฉันถาม

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

จากนั้นฉันก็แค่ใช้ขั้นตอนต่อไปนี้

1. นำเสนอที่เก็บข้อมูลใหม่ไปยัง SQL Server
2. หยุดบริการ SQL
3. คัดลอกข้อมูลทั้งหมดจากไดรฟ์เก่าไปยังไดรฟ์ใหม่ (อย่าลืมรวมสิทธิ์หากใช้ robocopy)
4. ถอดอักษรกำกับไดรฟ์ออกจากไดรฟ์เก่า
5. เปลี่ยนอักษรชื่อไดรฟ์บนไดรฟ์ใหม่เพื่อให้ตรงกับอักษรชื่อไดรฟ์เก่า
6. เริ่มบริการ SQL

แค่นั้นแหละ.

ไม่จำเป็นต้องถอด / แนบเท่าที่ SQL Server รู้ว่าไม่มีอะไรเปลี่ยนแปลง และถ้ามีอะไรผิดพลาดเกิดขึ้นคุณมีสำเนาของฐานข้อมูลเก่าที่วางอยู่บน LUN เก่าในอาร์เรย์เก็บข้อมูลเก่า การย้อนกลับเป็นเพียงเรื่องของการเปลี่ยนอักษรระบุไดรฟ์