it-swarm.asia

إعادة بناء سجل المعاملات

لدينا قاعدة بيانات كبيرة جدًا (~ 6 تيرابايت) ، تم حذف ملف سجل المعاملات الخاص بها (أثناء إيقاف تشغيل SQL Server. لقد حاولنا:

  1. فصل وإعادة ربط قاعدة البيانات ؛ و
  2. إلغاء حذف ملف سجل المعاملات

... ولكن لم ينجح شيء حتى الآن.

نعمل حاليًا:

ALTER DATABASE <dbname> REBUILD 
LOG ON (NAME=<dbname>,FILENAME='<logfilepath>')

... ولكن نظرًا لحجم قاعدة البيانات ، فمن المحتمل أن يستغرق ذلك بضعة أيام حتى يكتمل.

الأسئلة

  • هل هناك فرق بين الأمر أعلاه والأمر التالي؟

    DBCC CHECKDB ('<dbname>', REPAIR_ALLOW_DATA_LOSS)
    
  • هل يجب ان ننفذ REPAIR_ALLOW_DATA_LOSS في حين أن؟

تجدر الإشارة إلى أن البيانات مستمدة من مصادر أخرى حتى يمكن إعادة بناء قاعدة البيانات ، ولكننا نعتقد أن إصلاح قاعدة البيانات سيكون أسرع بكثير من إعادة إدخال جميع البيانات مرة أخرى.


تحديث

بالنسبة لأولئك الذين يحافظون على النتيجة: ALTER DATABASE/REBUILD LOG اكتمل الأمر بعد حوالي 36 ساعة وأفاد:

تحذير: تمت إعادة بناء سجل قاعدة البيانات 'dbname'. تم فقد اتساق المعاملات. تم كسر سلسلة RESTORE ، ولم يعد لدى الخادم سياق على ملفات السجل السابقة ، لذلك ستحتاج إلى معرفة ما كانت عليه.
يجب عليك تشغيل CHECKDB DBCC للتحقق من التناسق المادي. تم وضع قاعدة البيانات في وضع dbo-only. عندما تكون جاهزًا لجعل قاعدة البيانات متاحة للاستخدام ، ستحتاج إلى إعادة تعيين خيارات قاعدة البيانات وحذف أي ملفات سجل إضافية.

ثم قمنا بتشغيل DBCC CHECKDB (استغرق حوالي 13 ساعة) وهو ناجح. دعنا نقول فقط أننا تعلمنا جميعًا أهمية النسخ الاحتياطية لقاعدة البيانات (ومنح مديري المشاريع الوصول إلى الخادم ...).

20
Fuzzy Purple Monkey

لا تقم أبدًا بفصل قاعدة بيانات المشتبه بهم. على أي حال ، كيف أرفقت قاعدة البيانات بعد فصلها؟ استخدمت CREATE DATABASE مع خيار FOR ATTACH_REBUILD_LOG؟

يجب أن تكون هذه الأوامر قد خدعت:

ALTER DATABASE recovery_test_2 SET EMERGENCY;   
ALTER DATABASE recovery_test_2 SET SINGLE_USER;  

DBCC CHECKDB (recovery_test_2, REPAIR_ALLOW_DATA_LOSS) 
WITH NO_INFOMSGS, ALL_ERRORMSGS;

لقد كتبت منشورًا لهذا الموقف:

SQL 2005/2008 إجراء استرداد قاعدة البيانات - حذف ملف السجل (الجزء 3)

سألت عن الفرق بين:

  • DBCC CHECKDB ('<dbname>', REPAIR_ALLOW_DATA_LOSS) و
  • ALTER DATABASE <dbname> REBUILD LOG ON (NAME=<dbname>,FILENAME='<logfilepath>')

الشيء هو أنه يمكنك تشغيل كلاهما لإعادة بناء ملف السجل ، ولكن مع CHECKDB يمكنك إعادة بناء السجل والتحقق من أخطاء التكامل أيضًا.

كما لن تعمل الثانية (تغيير قاعدة البيانات) إذا كانت هناك معاملات نشطة (لم تتم كتابتها إلى القرص) عند فقد ملف السجل. عند بدء التشغيل أو الإرفاق ، سيرغب SQL Server في إجراء الاسترداد (الاستعادة والتراجع) من ملف السجل غير الموجود. يحدث ذلك عندما يتعطل القرص أو يحدث إيقاف تشغيل غير متوقع للخادم ولا يتم إيقاف تشغيل قاعدة البيانات بشكل نظيف. أعتقد أنها لم تكن قضيتك وكل شيء جيد بالنسبة لك.

  1. DBCC CHECKDB (DBNAME, REPAIR_ALLOW_DATA_LOSS) يعمل على قاعدة بيانات في حالة الطوارئ للتحقق من قاعدة البيانات بحثًا عن أخطاء عدم الاتساق ، ويحاول أولاً استخدام ملف السجل للتعافي من أي تناقضات. إذا كان هذا مفقودًا ، يتم إعادة إنشاء سجل المعاملات.

  2. ALTER DATABASE REBUILD LOG ON... إجراء غير موثق ويتطلب DBCC CHECKDB لاحق لإصلاح أية أخطاء.

20
yrushka

نعم ، هذان بيانان مختلفان ، كل منهما يقوم بأشياء مختلفة تمامًا.

بناءً على حالة قاعدة البيانات عندما تم حذف الملف ، يمكنك أن قد تكون قادرًا على بدء التشغيل عن طريق إرفاق قاعدة البيانات وإعادة بناء السجل باستخدام :

EXEC sp_attach_single_file_db 'dbname here', 'file path and name here'

راجع sp_attach_single_file_db (Transact-SQL) في وثائق المنتج.

انظر أيضًا إلى هذه المدونة بواسطة Paul S. Randal :

إصلاح وضع الطوارئ: الملاذ الأخير للغاية

12
SQLRockstar