كيف يمكنك مسح SQL Server سجل المعاملات?

StackOverflow https://stackoverflow.com/questions/56628

  •  09-06-2019
  •  | 
  •  

سؤال

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

هل كانت مفيدة؟

المحلول

صنع ملف سجل أصغر حقا ينبغي أن تكون محفوظة ل السيناريوهات التي واجهت نمو غير متوقع الذي لا تتوقع أن يحدث مرة أخرى.إذا كان ملف السجل سوف تنمو إلى نفس الحجم مرة أخرى ، ليس كثيرا هو إنجاز تقلص مؤقتا.الآن اعتمادا على أهداف الانتعاش من قاعدة البيانات الخاصة بك, هذه هي الإجراءات التي يجب اتخاذها.

أول من أخذ نسخة احتياطية كاملة

لا تجعل أي تغييرات على قاعدة البيانات الخاصة بك دون ضمان يمكنك استعادته على ما يرام.

إذا كنت الرعاية حول النقطة في الوقت الانتعاش

(و نقطة في الوقت الانتعاش ، أعني يهمك كونها قادرة على استعادة أي شيء آخر غير كاملة أو النسخ الاحتياطي التفاضلي.)

ويفترض قاعدة البيانات الخاصة بك هو في FULL وضع الاسترداد.إن لم يكن, ثم تأكد من أنها:

ALTER DATABASE testdb SET RECOVERY FULL;

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

DECLARE @path NVARCHAR(255) = N'\\backup_share\log\testdb_' 
  + CONVERT(CHAR(8), GETDATE(), 112) + '_'
  + REPLACE(CONVERT(CHAR(8), GETDATE(), 108),':','')
  + '.trn';

BACKUP LOG foo TO DISK = @path WITH INIT, COMPRESSION;

علما بأن \\backup_share\ ينبغي على آلة مختلفة تمثل مختلف الأساسية جهاز التخزين.دعم هذه تصل إلى نفس الجهاز (أو إلى جهاز آخر يستخدم نفس الأقراص الأساسية ، أو مختلفة VM على نفس البدنية المضيف) لا تساعد حقا لكم ، لأن إذا كان الجهاز ينفجر ، كنت قد فقدت قاعدة البيانات الخاصة بك و الاحتياطي لها.اعتمادا على البنية التحتية للشبكة قد يكون من المنطقي أكثر أن النسخ الاحتياطي محليا ومن ثم نقلها إلى موقع آخر وراء الكواليس ؛ في كلتا الحالتين كنت تريد الحصول عليها من قاعدة البيانات الأساسية الجهاز بأسرع وقت ممكن.

الآن, مرة واحدة كنت قد العادية النسخ الاحتياطية سجل قيد التشغيل ، يجب أن تكون معقولة إلى تقليص ملف سجل إلى شيء أكثر عقلانية من كل ما هو في مهب حتى الآن.هذا لا لا يعني تشغيل SHRINKFILE مرارا وتكرارا حتى سجل الملف 1 MB - حتى إذا كنت تجري النسخ الاحتياطي سجل في كثير من الأحيان, فإنه لا يزال يحتاج إلى استيعاب مجموع المعاملات المتزامنة التي يمكن أن تحدث.ملف سجل autogrow الأحداث غالية الثمن ، منذ SQL Server إلى الصفر من الملفات (على عكس ملفات البيانات عند تهيئة ملف الفورية تمكين) ، و المعاملات المستخدم إلى الانتظار في حين أن هذا يحدث.كنت تريد أن تفعل هذا النمو-النفسي-النمو-تقليص الروتين قدر ممكن ، وأنت بالتأكيد لا تريد أن تجعل المستخدمين دفع ثمنها.

ملاحظة قد تحتاج إلى نسخة احتياطية من سجل مرتين من قبل طبيب نفسي هو ممكن (بفضل روبرت).

لذا تحتاج إلى الخروج مع العملي لحجم ملف السجل.لا أحد هنا يمكن أن أقول لكم ما هو دون معرفة الكثير عن النظام الخاص بك, ولكن إذا كنت في كثير من الأحيان تقليص ملف سجل و قد كانت تنمو مرة أخرى ، جيد مائية ربما 10-50 ٪ أعلى من أكبر كان.دعنا نقول أن يأتي إلى 200 ميجا بايت, و تريد أي اللاحقة autogrowth الأحداث إلى 50 ميجا بايت, ثم يمكنك ضبط حجم ملف السجل هذا النحو:

USE [master];
GO
ALTER DATABASE Test1 
  MODIFY FILE
  (NAME = yourdb_log, SIZE = 200MB, FILEGROWTH = 50MB);
GO

لاحظ أنه إذا كان ملف السجل حاليا > 200 MB, قد تحتاج إلى تشغيل هذا أولا:

USE yourdb;
GO
DBCC SHRINKFILE(yourdb_log, 200);
GO

إذا كنت لا تهتم حول النقطة في الوقت الانتعاش

إذا كان هذا هو اختبار قاعدة البيانات و لا يهتمون نقطة في الوقت الانتعاش, ثم يجب عليك التأكد من أن قاعدة البيانات الخاصة بك هو في SIMPLE وضع الاسترداد.

ALTER DATABASE testdb SET RECOVERY SIMPLE;

وضع قاعدة البيانات في SIMPLE وضع الاسترداد سوف تأكد من أن SQL Server إعادة يستخدم أجزاء من ملف السجل (أساسا التدريجي نشط المعاملات) بدلا من أن ينمو إلى الاحتفاظ بسجل كل المعاملات (مثل FULL الانتعاش لا حتى نسخة احتياطية من السجل). CHECKPOINT الأحداث سوف تساعد في السيطرة على الدخول والتأكد من أنها لا تحتاج إلى أن تنمو إلا إذا تولد الكثير من t-سجل النشاط بين CHECKPOINTs.

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

USE yourdb;
GO
CHECKPOINT;
GO
CHECKPOINT; -- run twice to ensure file wrap-around
GO
DBCC SHRINKFILE(yourdb_log, 200); -- unit is set in MBs
GO

وإلا تعيين مناسب الحجم ومعدل النمو.كما في المثال في هذه النقطة في الوقت الانتعاش الحالة ، يمكنك استخدام نفس رمز والمنطق لتحديد حجم الملف هو مناسبة و معقولة autogrowth المعلمات.

بعض الأشياء التي كنت لا تريد أن تفعل

  • نسخة احتياطية من سجل مع TRUNCATE_ONLY الخيار ثم SHRINKFILE.واحد ، TRUNCATE_ONLY الخيار تم إهمالها ، لم تعد متوفرة في الإصدارات الحالية من SQL Server.ثانيا ، إذا كنت في FULL نموذج استرداد هذا سوف يدمر السجل الخاص بك سلسلة تتطلب جديد احتياطية كاملة.

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

  • استخدام "تقليص قاعدة البيانات" الخيار. DBCC SHRINKDATABASE و خطة الصيانة الخيار أن تفعل نفس الأفكار السيئة ، وخاصة إذا كنت حقا بحاجة فقط لحل سجل مشكلة المسألة.الهدف الملف الذي تريد ضبط وتعديله بشكل مستقل ، وذلك باستخدام DBCC SHRINKFILE أو ALTER DATABASE ... MODIFY FILE (الأمثلة أعلاه).

  • تقليص ملف سجل 1 MB.هذا يبدو مغريا لأنه مرحبا SQL Server سوف اسمحوا لي أن تفعل ذلك في بعض السيناريوهات ، وننظر في كل الفضاء يحرر!ما لم تكن قاعدة البيانات الخاصة بك هو قراءة فقط (وهذا هو, يجب وضع علامة على هذا النحو باستخدام ALTER DATABASE) ، وهذا قطعا يؤدي فقط إلى العديد من لزوم الأحداث ، كما سجل أن تستوعب المعاملات الجارية بغض النظر عن نموذج استرداد.ما هو الهدف من تحرير هذا الفضاء مؤقتا فقط حتى SQL Server يمكن أن أعتبر مرة أخرى ببطء مؤلم?

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

تكون سباقة

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

أسوأ الإعدادات الممكنة هنا هي 1 ميجا بايت النمو أو 10% النمو.مضحك بما فيه الكفاية ، هذه هي الإعدادات الافتراضية لـ SQL Server (أنا الذي اشتكى ، طلب التغييرات دون جدوى) - 1 ميغابايت من البيانات والملفات 10% ملفات السجل.السابق صغير جدا في هذا اليوم وهذا العصر ، وهذا الأخير يؤدي إلى أطول وأطول الأحداث في كل مرة (أقول السجل الخاص بك ملف 500 ميجا بايت, النمو الأولى هي 50 ميجا بايت بجانب النمو 55 MB بجانب النمو 60.5 MB, الخ.الخ.- و على بطء I/O صدقني ستلاحظ حقا هذا المنحنى).

مزيد من القراءة

من فضلك لا تتوقف هنا ؛ في حين أن الكثير من المشورة ترى هناك عن تقلص ملفات السجل سيئة بطبيعتها وحتى كارثية, هناك بعض الناس الذين يهتمون أكثر سلامة البيانات من تحرير مساحة القرص.

بلوق وظيفة كتبت في عام 2009, عندما رأيت عدد قليل من "هنا كيفية تقليص ملف سجل" وظائف الربيع.

بلوق وظيفة برنت Ozar كتبت قبل أربع سنوات ، لافتا إلى موارد متعددة ، ردا على SQL Server مجلة المادة التي ينبغي أن لا وقد نشرت.

بلوق وظيفة من قبل بول راندال شرح لماذا t-سجل الصيانة المهم و لماذا يجب أن لا يتقلص ملفات البيانات الخاصة بك ، إما.

مايك والش لديه إجابة رائعة تغطي بعض هذه الجوانب أيضا ، بما في ذلك الأسباب لماذا قد لا تكون قادرة على تقليص ملف سجل فورا.

نصائح أخرى

تنويه: يرجى قراءة التعليقات أدناه بعناية, و أفترض أنك قد قرأت بالفعل الجواب المقبول.كما قلت ما يقرب من 5 سنوات:

إذا كان أي شخص لديه أي تعليقات إضافة لحالات عند هذه ليست كافية أو الحل الأمثل ثم يرجى التعليق أدناه

  • انقر بزر الماوس الأيمن فوق اسم قاعدة البيانات.

  • حدد المهام → يتقلص → قاعدة البيانات

  • ثم انقر فوق طيب!

وعادة ما فتح مستكشف Windows الدليل الذي يحتوي على ملفات قاعدة البيانات ، لذلك أنا يمكن أن نرى على الفور تأثير.

في الحقيقة كنت مندهشا حقا هذا عمل!عادة كنت تستخدم DBCC قبل, ولكن أنا فقط حاولت ذلك وأنه لم يتقلص أي شيء ، لذلك حاولت واجهة المستخدم الرسومية (2005) وعملت كبيرة - تحرير 17 GB في 10 ثوان

في وضع الاسترداد الكامل هذا قد لا تعمل لذا يجب أن إما نسخة احتياطية من السجل الأول أو تغيير الاسترداد بسيطة ، ثم يتقلص الملف.[شكرا @onupdatecascade لهذا]

--

PS:أقدر لك بعض ما قد علق بشأن مخاطر هذا في بيئة لم يكن لدي أي مشاكل أفعل هذا بنفسي خصوصا أفعل دائما نسخة احتياطية كاملة الأولى.لذا يرجى أخذ في الاعتبار ما البيئة الخاصة بك ، وكيف يؤثر هذا على استراتيجية النسخ الاحتياطي والأمن الوظيفي قبل المتابعة.كل ما فعلته هو توجيه الناس إلى الميزة التي تقدمها مايكروسوفت!

USE AdventureWorks2008R2;
GO
-- Truncate the log by changing the database recovery model to SIMPLE.
ALTER DATABASE AdventureWorks2008R2
SET RECOVERY SIMPLE;
GO
-- Shrink the truncated log file to 1 MB.
DBCC SHRINKFILE (AdventureWorks2008R2_Log, 1);
GO
-- Reset the database recovery model.
ALTER DATABASE AdventureWorks2008R2
SET RECOVERY FULL;
GO

من: SHRINKFILE DBCC (Transact-SQL)

قد ترغب في النسخ الاحتياطي الأولى.

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

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

سجل المعاملات أيضا يجب أن يكون عندما يتعلق الأمر إلى نقطة في الوقت الانتعاش لذا لا مجرد رمي بعيدا ، ولكن تأكد مرة أخرى عنه مسبقا.

وهنا عدة وظائف حيث اعتاد الناس على البيانات المخزنة في سجل المعاملات لتحقيق الانتعاش:

 

USE DATABASE_NAME;
GO

ALTER DATABASE DATABASE_NAME
SET RECOVERY SIMPLE;
GO
--First parameter is log file name and second is size in MB
DBCC SHRINKFILE (DATABASE_NAME_Log, 1);

ALTER DATABASE DATABASE_NAME
SET RECOVERY FULL;
GO

قد تحصل على خطأ يشبه هذا عند تنفيذ الأوامر أعلاه

"لا يمكن تقليص ملف سجل (سجل اسم الملف) لأن المنطقي ملف السجل الموجود في نهاية الملف قيد الاستخدام"

وهذا يعني أن TLOG في الاستخدام.في هذه الحالة حاول تنفيذ هذا عدة مرات في صف واحد أو إيجاد وسيلة للحد من قاعدة بيانات الأنشطة.

إذا كنت لا تستخدم سجلات المعاملات بالنسبة يعيد (أيأنت فقط من أي وقت مضى القيام النسخ الاحتياطي الكامل), يمكنك تعيين وضع الاسترداد إلى "بسيط", و سجل المعاملات قريبا جدا يتقلص و لم تملأ مرة أخرى.

إذا كنت تستخدم SQL 7 أو 2000, يمكنك تمكين "اقتطاع سجل على حاجز" في قاعدة البيانات علامة التبويب خيارات.هذا له نفس التأثير.

هذا ليس أوصت في بيئات الإنتاج من الواضح منذ كنت سوف لا تكون قادرة على استعادة إلى نقطة في الوقت المناسب.

هنا هو بسيط ، جدا غير لائق & يحتمل أن تكون خطرة الطريقة.

  1. النسخ الاحتياطي DB
  2. فصل DB
  3. إعادة تسمية ملف السجل
  4. إرفاق DB
  5. ملف سجل جديد سوف يعاد
  6. حذف تسمية ملف السجل.

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

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

القضاء على log (من خلال اقتطاع, رميه, محو, الخ) سوف كسر سلسلة النسخ الاحتياطي و سوف تمنعك من استعادة أي نقطة في الوقت منذ آخر كامل ، تفاضلي أو النسخ الاحتياطي سجل المعاملة حتى نسخ احتياطي كامل أو جزئي ؟

من Microsoft المادة علىBACKUP

ونحن ننصح أبدا استخدام NO_LOG أو TRUNCATE_ONLY يدويا اقتطاع سجل المعاملات ، لأن هذا يكسر سلسلة السجل.حتى القادم كامل أو جزئي قاعدة بيانات النسخ الاحتياطي قاعدة البيانات ليست محمية من فشل وسائل الإعلام.استخدام دليل اقتطاع السجل فقط جدا ظروف خاصة ، و إنشاء نسخ احتياطية من البيانات على الفور.

لتجنب ذلك, النسخ الاحتياطي السجل الخاص بك الملف إلى القرص قبل أن تقلص.جملة سوف ننظر بشيء من هذا القبيل:

BACKUP LOG MyDatabaseName 
TO DISK='C:\DatabaseBackups\MyDatabaseName_backup_2013_01_31_095212_8797154.trn'

DBCC SHRINKFILE (N'MyDatabaseName_Log', 200)

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

بالإضافة إلى إجابات عن هذا السؤال أنصح بقراءة وفهم سجل المعاملات الخرافات الشائعة.هذه القراءات قد تساعد في فهم سجل المعاملات والبت ما التقنيات لاستخدام "واضحة" في ذلك:

من 10 أهم SQL Server سجل المعاملات الأساطير:

الأسطورة:My SQL الملقم مشغول جدا.أنا لا تريد أن تجعل SQL Server النسخ الاحتياطية سجل المعاملة

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

من سجل المعاملات الأساطير:

الأسطورة:العادية سجل تقلص هو صيانة جيدة الممارسة

كاذبة.سجل النمو مكلفة جدا لأن قطعة جديدة يجب أن نجد بها.كل نشاط الكتابة يتوقف على قاعدة البيانات حتى التصفير الانتهاء, و إذا كان القرص الخاص بك كتابة بطيئة أو autogrowth حجم كبير, أن وقفة يمكن أن تكون ضخمة و سوف تلاحظ المستخدمين.هذا هو أحد الأسباب لماذا كنت ترغب في تجنب النمو.إذا كنت تقليص سجل انها سوف تنمو مرة أخرى و كنت مجرد إضاعة القرص العملية على وغني عن يتقلص و تنمو مرة أخرى لعبة

هذه التقنية أن جون توصي لا ينصح ليس هناك ما يضمن أن قاعدة البيانات سوف نعلق بدون ملف السجل.تغيير قاعدة البيانات من الكامل بسيطة قوة نقطة التفتيش والانتظار بضع دقائق.SQL Server سيتم مسح السجل, الذي يمكنك ثم يتقلص باستخدام SHRINKFILE DBCC.

أولا التحقق من قاعدة بيانات نموذج استرداد.بشكل افتراضي, SQL Server Express Edition يخلق قاعدة بيانات الاسترداد بسيطة نموذج (إذا لم أكن مخطئا).

سجل النسخ الاحتياطي DatabaseName مع Truncate_Only:

DBCC ShrinkFile(yourLogical_LogFileName, 50)

SP_helpfile سوف تعطيك منطقية اسم ملف السجل.

الرجوع إلى:

التعافي من كامل سجل المعاملة في SQL Server قاعدة البيانات

إذا كانت قاعدة البيانات في طراز الاسترداد الكامل و إذا كنت لا تأخذ TL النسخ الاحتياطي, ثم تغييره إلى بسيطة.

استخدام DBCC ShrinkFile ({logicalLogName}, TRUNCATEONLY) الأوامر.إذا كان هذا هو اختبار قاعدة البيانات الذي تحاول حفظ/استعادة الفضاء, هذا سوف يساعد.

تذكر على الرغم من أن TX سجلات لديهم نوعا من الحد الأدنى/ثابت حجم الدولة التي سوف تنمو لتصل إلى.اعتمادا على نموذج استرداد أنك قد لا تكون قادرا على تقليص السجل - إذا كان في كامل ولم تكن إصدار تكساس سجل النسخ الاحتياطي السجل لا يمكن أن يكون تقلصت - انها سوف تنمو إلى الأبد.إذا كنت لا تحتاج إلى تكساس سجل النسخ الاحتياطي مفتاح الانتعاش الخاص بك نموذج بسيطة.

و تذكر أبدا تحت أي ظرف من الظروف حذف سجل (LDF) الملف!هل سيكون الفورية قاعدة البيانات الفساد.المطبوخ!فعلت!البيانات المفقودة!إذا تركت "سوائلها" الرئيسية ملف MDF يمكن أن تصبح فاسدة بشكل دائم.

أبدا من أي وقت مضى حذف سجل المعاملات - سوف تفقد البيانات!جزء من البيانات الخاصة بك في تكساس سجل (بغض النظر عن نموذج استرداد)...إذا كنت فصل و "إعادة تسمية" TX ملف السجل هذا على نحو فعال حذف جزء من قاعدة البيانات الخاصة بك.

لتلك التي لديها حذف تكساس سجل قد تحتاج إلى تشغيل عدد قليل من checkdb الأوامر وإصلاح الفساد قبل أن تخسر المزيد من البيانات.

تحقق من بول راندال بلوق وظيفة حول هذا الموضوع ، نصيحة سيئة.

أيضا في العام لا تستخدم shrinkfile على MDF الملفات كما يمكن بشدة جزء البيانات الخاصة بك.تحقق له نصيحة سيئة القسم لمزيد من المعلومات ("لماذا يجب أن لا يتقلص ملفات البيانات الخاصة بك")

تحقق من بول الموقع - انه يغطي هذه الأسئلة.في الشهر الماضي كان يسير من خلال العديد من هذه القضايا في أسطورة يوميا السلسلة.

لاقتطاع ملف السجل:

  • النسخ الاحتياطي قاعدة البيانات
  • فصل قاعدة البيانات ، إما باستخدام إدارة المؤسسة أو من خلال تنفيذ : Sp_DetachDB [DBName]
  • حذف ملف سجل المعاملة.(أو إعادة تسمية الملف ، فقط في حالة)
  • إعادة إرفاق قاعدة البيانات مرة أخرى باستخدام: Sp_AttachDB [DBName]
  • عندما تكون قاعدة البيانات المرفقة ، معاملة جديدة يتم إنشاء ملف سجل.

لتقليص ملف سجل:

  • سجل النسخ الاحتياطي [DBName] مع No_Log

  • تقليص قاعدة البيانات إما عن طريق:

    باستخدام إدارة المؤسسة :- انقر بزر الماوس الأيمن فوق قاعدة البيانات كافة المهام تقليص قاعدة البيانات, ملفات, حدد ملف سجل موافق.

    باستخدام T-SQL :- Shrinkfile Dbcc ([Log_Logical_Name])

يمكنك أن تجد المنطقية اسم ملف السجل عن طريق تشغيل sp_helpdb أو من خلال النظر في خصائص قاعدة البيانات في "إدارة المؤسسة".

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

نسخة احتياطية من قاعدة البيانات "tempdb" لا معنى له ، وبالتالي فإن نموذج استرداد هذه db يجب أن تكون دائما "بسيطة".

  1. أخذ نسخة احتياطية من ملف MDB.
  2. توقف خدمات SQL
  3. إعادة تسمية ملف السجل
  4. بدء تشغيل الخدمة

(النظام سيتم إنشاء ملف سجل جديد.)

حذف أو نقل إعادة تسمية ملف السجل.

جرب هذا:

USE DatabaseName

GO

DBCC SHRINKFILE( TransactionLogName, 1)

BACKUP LOG DatabaseName WITH TRUNCATE_ONLY

DBCC SHRINKFILE( TransactionLogName, 1)

GO

قاعدة بيانات → انقر على الحق خصائص ← ملف ← إضافة سجل آخر الملف مع اسم مختلف و تعيين المسار نفس السجل القديم الملف باستخدام اسم ملف مختلف.

قاعدة البيانات تلقائيا تلتقط حديثا إنشاء ملف سجل.

  1. النسخ الاحتياطي DB
  2. فصل DB
  3. إعادة تسمية ملف السجل
  4. إرفاق DB (مع إرفاق إزالة إعادة تسميته .ldf (log).حدده ثم إزالة عن طريق الضغط على زر إزالة)
  5. ملف سجل جديد سوف يعاد
  6. حذف تسمية ملف السجل.

هذا العمل ولكن يقترح أن تأخذ نسخة احتياطية من قاعدة البيانات الخاصة بك أولا.

على سبيل المثال:

DBCC SQLPERF(LOGSPACE)

BACKUP LOG Comapny WITH TRUNCATE_ONLY

DBCC SHRINKFILE (Company_log, 500)

DBCC SQLPERF(LOGSPACE)

حدث معي حيث سجل قاعدة البيانات الملف من 28 GBs.

ما يمكنك القيام به للحد من هذا ؟ في الواقع, ملفات السجل هذه الملفات البيانات SQL server تحافظ عندما تتم معاملة من المعاملات.بالنسبة الصفقة إلى عملية SQL server تخصيص صفحات على نفسه.ولكن بعد الانتهاء من الصفقة ، هذه ليست صدر فجأة على أمل أنه قد يكون هناك صفقة قادمة مثل نفس واحدة.هذا يحمل ما يصل الفضاء.

الخطوة 1:أول تشغيل هذا الأمر في قاعدة البيانات الاستعلام استكشاف نقطة تفتيش

الخطوة 2:انقر بزر الماوس الأيمن فوق قاعدة البيانات مهمة> نسخة احتياطية حدد نسخة احتياطية نوع سجل المعاملات إضافة عنوان الوجهة واسم الملف للحفاظ على نسخة احتياطية من البيانات (.bak)

كرر هذه الخطوة مرة أخرى في هذا الوقت تعطي اسم ملف آخر

enter image description here

الخطوة 3:الآن اذهب إلى قاعدة البيانات انقر بزر الماوس الأيمن فوق قاعدة البيانات

المهام> ينكمش> الملفات اختيار نوع الملف كما سجل تقليص إجراءات الإفراج عن مساحة غير مستخدمة

enter image description here

الخطوة 4:

التحقق من ملف سجل عادة في SQL 2014 هذا يمكن العثور عليها في

C:\Program Files\Microsoft SQL Server\MSSQL12.MSSQL2014EXPRESS\MSSQL\DATA

في حالتي ، انخفض من 28 جيجا الى 1 ميجا بايت

بعض إجابات أخرى لم يكن العمل بالنسبة لي:لم يكن من الممكن إنشاء نقطة تفتيش في حين db كان على الانترنت ، لأنه سجل المعاملات الكامل (يا للسخرية).ومع ذلك ، بعد تعيين قاعدة البيانات إلى وضع الطوارئ, وكنت قادرا على تقليص ملف سجل:

alter database <database_name> set emergency;
use <database_name>;
checkpoint;
checkpoint;
alter database <database_name> set online;
dbcc shrinkfile(<database_name>_log, 200);

DB سجل المعاملات يتقلص إلى حجم مين:

  1. النسخ الاحتياطي:سجل المعاملات
  2. تقليص الملفات:سجل المعاملات
  3. النسخ الاحتياطي:سجل المعاملات
  4. تقليص الملفات:سجل المعاملات

أنا جعلت اختبارات على عدة عدد DBs: هذا التسلسل يعمل.

وعادة ما ينكمش إلى 2MB.

أو من قبل البرنامج النصي:

DECLARE @DB_Name nvarchar(255);
DECLARE @DB_LogFileName nvarchar(255);
SET @DB_Name = '<Database Name>';               --Input Variable
SET @DB_LogFileName = '<LogFileEntryName>';         --Input Variable
EXEC 
(
'USE ['+@DB_Name+']; '+
'BACKUP LOG ['+@DB_Name+'] WITH TRUNCATE_ONLY ' +
'DBCC SHRINKFILE( '''+@DB_LogFileName+''', 2) ' +
'BACKUP LOG ['+@DB_Name+'] WITH TRUNCATE_ONLY ' +
'DBCC SHRINKFILE( '''+@DB_LogFileName+''', 2)'
)
GO
مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top