تقليص حجم قاعدة البيانات

السلام عليكم ...

اقتباس

 

كيف يمكن ان استفيد من ملف الـ log اذا كان الـ Recovery model هو Full

وفى نفس الوقت لا اقوم انا كمسئول عن السيستم بعمل باك اب لملف اللوج

مدير قواعد البيانات يستفيد من اللوغ فقط في عملية الباك آب (حسب معلوماتي)..و سيكوال سيرفر طبعا يستخدم اللوغ لتشغيل القاعدة بشكل صحيح (مثلا يستخدمه للتراجع عندما يحصل خطأ في تنفيذ الاستعلامات .. مثال : افرض انك كتبت استعلام تحديث البيانات بعبارة update  لتقوم بتحديث 500 سجل و حصل خطأ داخلي أو مشكلة ما , بعد تحديث 200 سجل فقط .. فإن سيكوال سيرفر يتراجع عن هذه الــ 200 سجل باستخدام اللوغ .. أي إن عبارة الــ update أما تنفذ كاملة أو لا تنفذ منها شي , و لا يمكن تنفيذ جزء منها فقط (هذا المبدأ يسمى Atomicity).. يتم ذلك باستخدام الــ log  ) .

أي أن استرجاع البيانات من الـــ log  دون باك اب , يقوم بها سيكوال سيرفر بشكل تلقائي ...

لتوضيح الأمور اكثر, إليك المعلومات التالية (على فرض أن الــ recovery model  المستخدم للقاعدة هو full ) :

1. في الصورة السابقة في مشاركتك , الخيار المحدد هو backup type  .. ويوجد ثلاثة خيارات :  Full : يعمل باك أب  لبيانات القاعدة (نقصد mdf)  + باك أب لسجلات اللوغ التي تم إنشاؤها بعد آخر عمليه full backup   (الموضوع دقيق , ركز على الكلمات بالضبط ).
2. Differential Backups : يعمل باك أب لبيانات القاعدة التي تم إدخالها بعد آخر عملية full backup  + باك أب لسجلات الـلوغ التي تم إنشاؤها منذ آخر عملية full backup  .إذا و بمحاكمة منطقية , نستنج انه فقط نحتاج للــ full backup  واحدة و آخر Differential Backup لاستعادة القاعدة , أما الـــ Differential Backups التي في الوسط فيمكن الاستغناء عنها ...
3. log backup  : يعمل باك أب لسجلات اللوغ التي تم إنشاؤها بعد آخر عملية backup  (مهما كان نوعها سواء أكانت full backup  او log backup) . (لاحظ أنه لا يعمل باك أب لبيانات في القاعدة) ... نستنج أيضا ان الــ log backup  صغيرة الحجم على حسب العمليات التي تمت على القاعدة .. و هذا مفيد جدا لنا كما ستوضح في البنود التالية ...
4. لاحظ ان كل log backup  يعتمد على ما قبله ... لذلك تسمى نسخ الباك أب للوغ  المتتالية بــالسلسلة  (log chain) (لمن يقرأ في مراجع اجنبية) ...
5. أفضل خطة لعمل نسخ احتياطية backup تتحدث عنها المراجع و المنتديات تقوم على مايلي :
   1. نقوم بــ full backup  في بداية يوم العمل ...
   2. كل (ربع أو نصف أو ساعة) نقوم بـــ log backup  (لا تقلق , الحجم سيكون صغيرا , لأنه فقط يشمل السجلات منذ آخر عملية back up  كما ذكرنا) .
   3. لو حصل مشكلة , يمكننا استعادة القاعدة إلى أي لحظة زمنية , ولكن الاستعادة تبدأ حصرا من عند full backup  ..
   4. يمكن حذف الــ full backups  القديمة , كي لا تشغل حجما .إذا كنا لسنا بحاجة إليها .
6. 
7. لاحظ في الصورة المرفقة ...فقمت بعدة عمليات backup  على القاعدة (و في نفس الملف)  و عند اختيار restore  تظهر هذه العمليات ..
8. لاحظ عمود النوع (Type)  أول باك أب هو full و الباقي هم log  .
9. لاحظ عمود الحجم (size)  و هو بالبايت ..لاحظ حجم الــ full  تقريبا هو 18 ميغا .. أما حجم الــ Log  فهي بضع كيلو بايتات .. لاحظ توفير الحجم ..مقارنة لو كنا سنعمل full  كل مرة
10. لاحظ عمود (restore)  ان أول سجل (full)  لا يمكن إلغاء تحديده , و بمجرد تحديد أي سطر , سيتم تحديده بشكل تلقائي ...
11. كيف يعمل الــ restore : يبدأ من الــ full backup  و ينقل محتواها للقاعدة , ثم ينتقل على الــ Log  واحدة تلو الأخرى و يعدل البيانات حسب محتوى الــ Log  ...
12. لاحظ الحقل (to point int time)   هنا يمكن تحديد  الزمن المطلوب استعادة القاعدة إليه , حتى لو لم تكن لحظة أخذ الــ backup  كما شرحنا .
13. إذا ظهرت رسالة خطأ عند الاستعادة (The Tail of the log for database DB02 has not been backed up) , فهذا سببها أن هناك سجلات في اللوغ لم يتم عمل باك أب لها ,  الحل : نذهب للتبويب Options ونحدد الخيار  (Overwrite the existing database) لاستبدال كامل القاعدة , أو تلتف على الموضوع بتفيذ عملية باك أب وهمية مع الخيار NORECOVERY  كالتالي :

    use masterBACKUP LOG DB02 TO DISK = 'NULL' WITH NORECOVERY

    مع ضمان أن القاعدة غير مستخدمة حاليا من قبل مستخدمين آخرين .

14. عمليات الــ backup  تؤدي بشكل تلقائي إلى حذف سجلات الللوغ , و بالتالي اللوغ لن يزداد حجمه مع الوقت و لن تحتاج لعمل shrink  .. :)
15. غاليا مدير قاعدة البيانات يقوم بجدولة عملية الباك أب , بشكل تلقائي , (عن طريق جدولة المهام في ويندوزمثلا أو برامج خارجية كثيرة تقوم بذلك) عن طريق باتش فايل , يقوم بتنفذ اوامر الباك أب , مشروحة في (How can I schedule a daily backup) رابط .

اقتباس

 

هل تنحصر اهميه وجود ملف اللوج فى عمل الباك اب

ام انه يوجد طريقه اخرى يمكن ان استرجع بها البيانات من اللوج ان لم اكن اعمل له باك اب

لوكان استعادة البيانات ممكنة من اللوغ مباشرة , فإن سيكوال سيرفر سيقوم بذلك مباشرة و بشكل تلقائي  دون تدخل المستخدم (تذكر مثال الــ update  لــ 500 سجل) ..المشاكل العملية تحصل ان جزء من القاعدة أو ربما جدول بكامله يصبح معطوب , فلا يتمكن سيكوال سيرفر من استعادته من اللوغ .. لان اللوغ يحوي فقط نسخة من البيانات  (تسمى تحديدا pages) التي تم إجراء التعديل عليها , و لا يحوي نسخة كاملة من الجدول  .. فلا يستطيع أستعادة جدول بكامله من اللوغ ... و بالتالي يجب أخذ باك أب .. إضافة أن نسبة حصول عطب في اللوغ نفسه كبيرة log corrupted ...

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

بالتوفيق .

افهم من كلامك ا- حسام انه اذا كان الـ Recovery model هو Simple

وقمت بعمل عمليه update لاحد الجداول اللذى به 500 سجل واثناء تنفيذ عمليه الـ update انقطع التيار

فهل فى هذه الحاله وبعد عودة التيار سأجد 200 سجل مثلا قد تم تعديلهم و 300 سجل لم يتم تعديلهم

بأعتبار ان ملف الـ log معطل لان Recovery model هو Simple وليس Full

تيجر 2000 كتب:

 

افهم من كلامك ا- حسام انه اذا كان الـ Recovery model هو Simple

 

وقمت بعمل عمليه update لاحد الجداول اللذى به 500 سجل واثناء تنفيذ عمليه الـ update انقطع التيار

فهل فى هذه الحاله وبعد عودة التيار سأجد 200 سجل مثلا قد تم تعديلهم و 300 سجل لم يتم تعديلهم

بأعتبار ان ملف الـ log معطل لان Recovery model هو Simple وليس Full

 

لا لا .. أبدا ... ملف اللوغ يتم استخدامه في حالة كان الــ recovery  هو simple  أو full  ...و بالتالي بالحالتين إما يتم تعديل 500 أو لا شئ ... أنا ضربت هذا كمثال على استخدام اللوغ و وظيفته ..

الفارق أنه في حالة الـــ simple  فقط يخزن آخر عدة  سجلات في الــ Log  و يحذف السجلات القديمة من اللوغ .. و بالتالي يبقى حجم اللوغ صغيرا , و لكن بالمقابل لن نتمكن من استعادة القاعدة إلى ما قبل عشرة أيام مثلا .. لماذا ؟؟ لأن سجلات اللوغ القديمة قد تم حذفها من قبل سيكوال سيرفر ... لانه في وضع  simple  ...(فقط يمكن الاستعادة إلى لحظة أخذ full backup ) .

بارك الله لك ا- حسام

والله انا تعبتك بس بصراحه موضوع رائع وشرح اروع

بارك الله بك أخي ..

السلام عليكم ا-حسام

هل عمل الشرنك من شانه تحسين العمل على قاعده البيانات وتحسين الاستعلام منها

ام هو تقليل مساحه على الهارد فقط ؟

-----------------

وهل يفضل عمل الشرنك فى وقت لا يكون احد متصل بقاعده البيانات (عند منتصف الليل مثلا)

ام انه يمكن عمل الشرنك فى وسط يوم العمل

وقاعده البيانات لم تتاثر او تهنج ؟

السلام عليكم ...

بالعكس ... الشرنك يؤدي لبطء العمل .....  علما انه يقلص المساحة ... و كما ذكرت سابقا :

اقتباس

 

يتم إجراء عمليات الــ Shrink  في حالات محدودة جدا .. مثلا شركة تقوم بإنشاء قاعدة بيانات بشكل سنوي ... مثلا مبيعات2012 - مبيعات2013 .. فعندما ننتقل لسنة جديدة , لن يتم إدخال البيانات في قواعد البيانات السابقة , لذلك نعمل shrink  لها كي نستفيد من المساحة الفارغة داخل القاعدة طالما أن القاعدة تستخدم فقط للقراءة منها ..

أو مثلا لدينا قاعدة بيانات و نريد نقلها لمكان جديد و تم مسح بعض البيانات منها و لكن بقي الحجم كبيرا مثلا (500 جيغا).. فنعمل لها shrink  كي يكون نقلها سهلا ... نقلص حجمها لــ 20 جيغا مثلا ..

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

use masterBACKUP LOG DB02 TO DISK = 'NULL' WITH NORECOVERY

يمكن عمل shrink  في أي وقت ... لا مشكلة ... سواء أكانت القاعدة قيد الاستخدام أم لا ..

شكرا

وجزاك الله خير

:rolleyes: :rolleyes: :rolleyes: :rolleyes:

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

بارك الله بك أخي كريم ....و لك المثل ولجميع المسلمين إن شاء الله ..