سؤال

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

enter image description here

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

enter image description here

enter image description here

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

ومع ذلك، هل يمكن القيام بذلك في بيئة الإنتاج أيضًا؟أدرك أن جميع سجلاتي قد اختفت، ولكن ما هي مخاطر الاستمرار بالطريقة التي أتبعها في الإنتاج؟ ما هي مخاطر تغيير نموذج استرداد SharePoint_Config db إلى بسيط؟

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

المحلول

هناك بطريقتين للنظر في هذا القلق.

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

قل ذلك، إذا اتبعت الإرشادات المذكورة هنا
http://technet.microsoft.com/en-us/library/cc678868(v=office.14).aspx

انها تقول

ملاحظات إضافية ملفات سجل المعاملات.نوصي بإجراء نسخ احتياطي لسجل المعاملات لقاعدة بيانات التكوين بانتظام لفرض الاقتطاع، أو - إذا كنت لا تقوم بنسخ نظامك - قم بتغيير قاعدة البيانات لتشغيلها في وضع الاسترداد البسيط.لمزيد من المعلومات، راجع اقتطاع سجل المعاملات (http://go.microsoft.com/fwlink/p/?LinkId=186687).

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

الطريقة الثانية هي النظر في كيفية تحديد إستراتيجيات النسخ الاحتياطي والاسترداد.ما هو نهج الترميم الخاص بك؟

النسخ الاحتياطي الكامل للمزرعة المستند إلى Powershell واستعادة المزرعة المستندة إلى الإدارة المركزية أو الاستعادة المستندة إلى SQL من خلال إرفاق قاعدة البيانات عبر نفس الأسماء المستعارة للخادم والأجهزة.سيكون الاسترداد البسيط هو الوضع المفضل للحالة الأولى، وبالنسبة للحالة الثانية، فمن الأفضل الاحتفاظ بقاعدة بيانات SharePoint Config في وضع الاسترداد الكامل فقط لضمان نسخة متماثلة "كما هي" من الحالة السابقة من نقطة فشل المزرعة.

يوضح MS هذا كما هو مذكور أدناه

يتم نسخ قاعدة بيانات التكوين احتياطيًا عند تنفيذ تكوين مزرعة SharePoint ونسخة احتياطية للمحتوى ، ويتم تصدير وتخزين بعض إعدادات التكوين من قاعدة البيانات كملفات XML.عند استعادة المزرعة ، لا تتم استعادة قاعدة بيانات التكوين.بدلاً من ذلك ، يتم استيراد إعدادات التكوين المحفوظة.يمكن نسخ قاعدة بيانات التكوين بنجاح واستعادتها باستخدام SQL Server أو أدوات أخرى إذا تم نقل مزرعة SharePoint أولاً.

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

نصائح أخرى

بشكل افتراضي، يتم تعيين قاعدة بيانات SharePoint_config لطراز الاسترداد الكامل. ولكن، توصية Microsoft هي ضبط نموذج الاسترداد لقاعدة بيانات SharePoint_config الخاصة بك بسيطة في الإنتاج (المرجع: http://technet.microsoft.com/en-us/library/cc678868.aspx ). يمكنك تغيير نموذج الاسترداد ل SharePoint_Config بعد إنشاء SharePoint_Config DB.

لا تقلص أبدا قواعد البيانات الخاصة بك تكون تطوير تكنولوجيا المعلومات أو الإنتاج أو أينما. لأنه عندما تقليص DBS، فإنه يزيد من التجزئة التي تقلل من الأداء. لا يستحق مبلغ التخزين الذي تحرره (المرجع: http://www.microsoftvirtualacademy.com/training-courses/tuning-sql-server-201-sharepoint-2012-jump-start#fbid=onaemo8b3b7 في واحدة من تلك الفيديوهات التي ذكروها هذا، لا أتذكر أي واحد) و http://blog.sqlauthority.com/2011/01/19/sql-server-shrinking-database-is-bad-incriases-fragentation- الأداء / ).

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى sharepoint.stackexchange
scroll top