การเรียกคืนหน้าเว็บออนไลน์ที่มีจำนวนการ จำกัด 1,000 ครั้ง


13

ฉันได้รับมอบหมายให้พยายามกู้คืนฐานข้อมูลที่ประสบจากความเสียหาย (เนื่องจากความล้มเหลวของ I / O ซึ่งได้รับการแก้ไขตั้งแต่) ฉันไม่คุ้นเคยกับฐานข้อมูลหรือสิ่งที่มีอยู่

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

ฉันยังได้รับสำเนาของฐานข้อมูลที่เสียหาย (ซึ่งสามารถเข้าถึงได้ แต่มีหลายหน้าเสียหาย / ขาดหายไป)

ฉันได้ลองDBCC CHECKDBคำสั่งทั่วไป(ยังไม่repair_allow_data_lossว่าจะเป็นทางเลือกสุดท้ายของฉันถ้าไม่มีอะไรทำงาน)

หลังจากหลายคนมาและไปที่ฐานข้อมูล (db ​​เป็นสัตว์ประหลาดตัวเล็ก ๆ 1.5 เทราไบต์และทุกอย่างที่ฉันทำช้าและใช้เวลาสักครู่) ฉันพยายามทำการกู้คืนหน้าออนไลน์จากการสำรองข้อมูลที่ดีที่รู้จักล่าสุดสำหรับเพจที่เสียหาย

ในการทำเช่นนั้นฉันได้ทำสคริปต์ที่สร้างRESTORE DATABASE <foo> PAGE='pages' FROM DISK='<bar.bak>'คำสั่งจำนวนมากจากDBCC CHECKDBผลลัพธ์ (โดยปกติ regex และแตกต่างกันไป) ... ดีมากจนถึงตอนนี้มันใช้งานได้จนถึงจุดที่บอกว่าฉันมีจำนวนหน้าถึง 1,000 หน้า ต่อไฟล์ (มี 8 ไฟล์ใน db นี้) ต่อคำสั่งกู้คืน

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

ฉันได้ลองแล้วRESTORE DATABASE <foo> WITH RECOVERYแต่มันก็ไม่ได้ผลเหมือนกันมันจะขอบันทึกที่ฉันไม่มี

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

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

การสูญเสียข้อมูลบางอย่างอาจเป็นที่ยอมรับ แต่อย่างน้อยก็ควรพยายามทำให้ฐานข้อมูลมีความสม่ำเสมอ

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

นี่คือ SQL Server 2014 Enterprise

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


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

คำตอบ:


16

ขั้นตอนมาตรฐานคือ:

  1. รับ ID เพจที่ต้องกู้คืน
  2. เริ่มต้นการกู้คืนหน้าด้วยฐานข้อมูลแบบเต็ม
  3. ใช้การสำรองข้อมูลส่วนต่างล่าสุด
  4. ใช้การสำรองข้อมูลบันทึกที่ตามมา
  5. สร้างการสำรองข้อมูลบันทึกใหม่
  6. คืนค่าการสำรองข้อมูล lob ใหม่

หลังจากใช้การสำรองข้อมูลบันทึกใหม่แล้วการคืนค่าหน้าจะเสร็จสมบูรณ์และหน้านั้นสามารถใช้งานได้

ตัวอย่างการคืนค่า

RESTORE DATABASE <database> PAGE='1:57, 1:202, 1:916, 1:1016'  
   FROM <file_backup_of_file_B>   
   WITH NORECOVERY;  
RESTORE LOG <database> FROM <log_backup>   
   WITH NORECOVERY;  
RESTORE LOG <database> FROM <log_backup>   
   WITH NORECOVERY;   
BACKUP LOG <database> TO <new_log_backup>;   
RESTORE LOG <database> FROM <new_log_backup> WITH RECOVERY;  
GO  

การอ้างอิง: กู้คืนหน้า (SQL Server) (Microsoft Docs) การอ้างอิง: คำสั่ง RESTORE (Transact-SQL) (Microsoft Docs)

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


คุณอยู่ในสถานการณ์ที่ซับซ้อน

  1. ฐานข้อมูลของคุณมีเพจที่เสียหายและ บริษัท ของคุณกำลังเพิ่มข้อมูลใหม่ลงในฐานข้อมูลที่มีปัญหาอยู่ตลอดเวลา ซึ่งอาจส่งผลให้เกิดการหยุดทำงานทั้งหมดของฐานข้อมูล ทำคุณต้องการที่จะเสี่ยงที่?

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

  3. คุณกำลังตกอยู่ในสถานการณ์ที่ยากลำบากด้วยการสวมบทบาทที่คุณไม่ได้รับการว่าจ้าง คุณกำลังพยายามที่จะบรรลุสิ่งที่ทั้ง DBA บริษัท และที่ปรึกษาภายนอกของคุณไม่สามารถทำได้ แม้ว่ามันอาจจะเป็นท่าทางที่สูงส่ง แต่คุณก็กำลังตกอยู่ในความเสี่ยง คุณอาจมี "สัญญาโดยนัย" ซึ่งเป็นสิ่งที่คุณจะไม่สามารถเติมเต็มได้ ทำคุณต้องการที่จะเสี่ยงที่?

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

  5. ขั้นตอนการสำรองข้อมูลของ บริษัท ของคุณดูเหมือนจะผิดพลาด (ไม่เช่นนั้นข้อมูลสำรอง TLOG จะหายไปอย่างไร) และคุณยังคงใช้ฐานข้อมูลการผลิตของคุณราวกับว่าไม่มีปัญหา ทำคุณต้องการที่จะเสี่ยงที่?

คำแนะนำที่ดีที่สุดที่ฉันสามารถให้คุณได้คือหยุดการผลิตและโทรหา Microsoft! หรืออย่างน้อยก็เรียก Microsoft และอาจหยุดการผลิต

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

อีกต่อไปที่คุณรอการกู้คืนที่แพงกว่าอาจกลายเป็น


สำหรับข้อ จำกัด ในการกู้คืนหน้าเอกสารอ้างอิงจากเอกสารราชการ:

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

( เน้นที่เหมือง)

การอ้างอิง: คำสั่ง RESTORE - อาร์กิวเมนต์ (Transact-SQL) (Microsoft Docs)


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


2
ข้อกังวลส่วนใหญ่ของคุณที่ฉันได้รับและดูแลอยู่แล้ว (แน่นอนว่าฉันจะไม่รับผิดชอบหากมีสิ่งใดผิดพลาดควรหยุดการผลิต ฯลฯ ) ฉันทำให้ตัวเองชัดเจนมากเกี่ยวกับความเคารพ แต่ฉันไม่มีอำนาจหรือการตัดสินใจที่นั่น ฉันไม่คิดว่ามันระมัดระวังหรือเกินจริง ... ฉันคิดว่าพวกเขาทำผิดและฉันแค่พยายามช่วยที่นี่ แต่ไม่มีการประนีประนอมตัวเอง ฉันเข้าใจขีด จำกัด 1,000 หน้า แต่ฉันหวังว่าจะเป็นคำสั่งกู้คืนเดียว (เนื่องจากฉันทำออนไลน์ฉันหวังว่าฉันไม่ได้อยู่ในลำดับ ... ฉันไม่สามารถแยกเอกสารได้) .
Jcl

1

ฉันเห็นว่าคุณได้ลองวิธีการต่าง ๆ รวมถึงการทำงานกับ "ผู้เชี่ยวชาญ" การกู้คืนข้อมูลเพื่อซ่อมแซมฐานข้อมูลที่เสียหายโดยเฉพาะอย่างยิ่งที่มีขนาดเกิน 1 TB ทำให้กระบวนการนี้ยากขึ้นมากและแข่งกับเวลา ในฐานะ DBA ที่มีประสบการณ์ฉันเจอสถานการณ์ที่คล้ายกันซึ่งส่วนใหญ่มีการสำรองข้อมูลที่ดีสำหรับการกู้คืน ในกรณีที่มีการสืบทอดการสำรองข้อมูลที่ไม่ดีและฐานข้อมูลเสียหายผมได้อาศัยเครื่องมือของบุคคลที่สามเรียกว่าเครื่องมือ Stellar Phoenix SQL ซ่อมแซมฐานข้อมูล เครื่องมือนี้มีชื่อเสียงในการซ่อมฐานข้อมูลที่เสียหาย (.mdf และ. ndf) ด้านล่างนี้เป็นฟังก์ชั่นบางอย่างของเครื่องมือ:

  • ซ่อมแซมไฟล์ฐานข้อมูล SQL (.mdf & .ndf) ที่เสียหาย
  • กู้คืนตารางทริกเกอร์ดัชนีคีย์กฎ & ขั้นตอนการจัดเก็บ
  • ทำการกู้คืนระเบียนที่ถูกลบจากฐานข้อมูล SQL

  • บันทึกผลการสแกนของฐานข้อมูลเพื่อทำการกู้คืนในภายหลัง

  • อนุญาตให้บันทึกไฟล์ที่ซ่อมแซมแล้วในรูปแบบ MSSQL, HTML, XLS & CSV
  • รองรับ MS SQL Server 2016, 2014, 2012,2008 และเวอร์ชั่นที่เก่ากว่า

เครื่องมือนี้ต้องการไฟล์. pdf และ. ndf เป็นแบบออฟไลน์ดังนั้นจึงใช้งานได้ดีว่าคุณมีสำเนาของฐานข้อมูล PROD ที่เสียหายและไม่ต้องหยุดบริการ SQL Server

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

ดาวน์โหลดและดูว่ามันช่วยได้หรือไม่ ดาวน์โหลดได้ที่นี่

ฉันยังเขียนบล็อกเกี่ยวกับวิธีการทำงานของเครื่องมือในเว็บไซต์นี้: บล็อก samosql

ขอบคุณและ HTH ที่จะทำให้คุณเป็น HERO ประจำวัน!

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

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.