مدیریت دیتابیس بزرگ [بایگانی]

alimooghashang

سه شنبه 31 اردیبهشت 1392, 22:34 عصر

سلام
من دیتابیسم الان شده 5 گیگ و فایل لاگش شده 7 گیگ
یه سوال دارم
برای مدیریتش باید چیکار کنم؟
یه پیشنهادی بدید
مثلا ماهانه بک آپ بگیریم بعد چطوری میشه ازشون استفاده کرد؟
میشه یه کاری کنیم ماه به ماه یا هفته به هفته خودش شرینک کنه و جاهای مختلف ذخیره کنه؟
اینطوری کوئری زدن توی رکوردها خیلی سخت میشه وقتی رکورد های مثلا پارسال داخل دیتابیس هم باشه بیشتر طول میکشه
کلا در مورد مدیریتش یکم راهنمایی کنید
مخصوصا بک آپ گرفتن خیلی سخت و زمانگیر میشه
ممنون

مبین رنجبر

سه شنبه 31 اردیبهشت 1392, 22:39 عصر

alimooghashang

چهارشنبه 01 خرداد 1392, 11:13 صبح

یعنی چی جوابگو نیست؟
پس چیکار باید کرد؟
پس این شرکتای بزرگ که برنامه های بزرگ مینویسن از چه پایگاه داده ای استفاده میکنن؟
برای نگهداری اطلاعاتشون چیکار میکنن؟

maktoom

پنج شنبه 02 خرداد 1392, 12:29 عصر

سلام

به طور کل پایگاه های داده ای رابطه ای دیگر جوابگوی این چنین چالش ها نیستند
این جمله رو نشنیده بگیر.
خب... اما سوال شما:

پس چیکار باید کرد؟
اولا از یه دیتابیس باید استفاده کنید که کارای بزرگ رو خوب هندل کنه.
بعد هم باید سیاست ذخیره و بازیابی استانداردی رو اجرا کنید. متوجه شدید قضیه رو: استاندارد رو رعایت کنید.
معمولا از هر دیتابیس یا هر تکنولوژی که استفاده کنید شرکتای بزرگ براش یه استاندارد ذخیرهو بازیابی مدون تدوین کردن که بشه ازش مثه یه فرمول استفاده کرد.
توی شرکت من از pgAdmin به عنوان دیتابیس استفاده میشه که خیلی دست رو باز می ذاره. ضمنا ما یه اسکریپت استفاده می کنیم که روی سرور به صورت خودکار از لاگ سیستم(وب اپلیکیشنی که استفاده می کنیم مثل جی باس و تام کت) و دیتابیس به صورت روزانه و در موارد حیاتی تر هر چند ساعت یکبار بکاپ میگیره. این بکاپ تا هفت روز ذخیره میمونه و بعدش خود به خود پاک میشه. بطور کلی لاگ سیستم بطرز باور نکردنی مهمه. خطایی که رخ بده میتونید بفهمید چرا بروز کرده و البته حجم بالایی هم اشغال می کنه.
اما همین کفایت نمی کنه. باید روی سورستون هم نظارت خوبی داشته باشید. یه نرم افزار مدیریت سورس مثل svn باید داشته باشید تا اگر روی سورس کار می کنید و تغییراتی میدید همه چیز قابل بازیابی و نظارت باشه.
توی فیلد خودتون دنبال تعقیب استانداردهای متداول و از پیش تعریف شده بگردید. به سراغ شرکتهایی برید که تجربه خوبی توی این زمینه دارن.

alimooghashang

پنج شنبه 02 خرداد 1392, 14:14 عصر

الان ما از دیتابیس sql server 2008 r2 استفاده کردیم
و فکر میکنم تمامی رقبای ما تو این زمینه از همین دیتابیس استفاده میکنن
من میخوام بدونم چیکار کنیم که انقدر حجم دیتابیس زیاد نشه
یه سیاستی رو پیشنهاد بدید که هم دیتا رو داشته باشیم و هم از نره اطلاعات
ممنون

maktoom

پنج شنبه 02 خرداد 1392, 18:27 عصر

صرفا تجربیاتم رو که در تموم این مدت کسب کردم در اختیار دوستان گذاشتم.
نمی دونم چه چیزی خاطر شما مدیر گرامی رو مکدر کرد که باعث شد گزارش ارسال مطلب بدون محتوا برام ارسال کنید.
در هر حال سوال ایشون در مورد روش هایی که شرکتهای بزرگ انجام میدن بود.
شما یک نرم افزار دارید با سابقه چندین ساله که دیتابیس اون واقعا رشد کرده. چقدر هزینه میبره تا این روشی که گفتید رو جایگزین اون کنید؟؟؟ آیا در این مدت نباید کاری بکنید؟ د راین مدت که برفرض که بخواید ریسک کنید و هزینه رو بالا ببرید و این انتقال رو انجام بدید، در این مئدت نمی خواید یه روش درست برای دوره بکاپ گیزی داشته باشید؟ نمی خواید برای پایین اومدن ریسک بخاطر بی نظمی در رفتار با آپدیت سورس یا مسائل دیگه یک روش درست رو انجام بدید؟
کمی فکر کنید و فقط به محفوظاتتون اتکا نکنید. محفوظات شما برای این مناسبه که یک پروژه رو با مناسب بودن شرایط خاصی که لازمه اون هست، پیش ببرید. همیشه این شرایط جور نیست.
مثله اینه که بگی چطور پرایدم رو تعمیر کنم یکی بگه بنز بخر از شرش راحت شی. همه می دونیم بنز بهتره اما شدنیه؟
موفق باشید./

alimooghashang

پنج شنبه 02 خرداد 1392, 21:57 عصر

ممنون
ولی جایی که ما کار میکنیم باید sql server 2008 کار کنیم و نمیتونیم فعلا پروژه رو تغییر بدیم
الان من فقط منتظر راهکارم که این دیتابیس رو چیکار کنم و بتونم سریع این کار رو بکنم
ممنون میشم تو این زمینه راهنمایی کنید

حمیدرضاصادقیان

جمعه 03 خرداد 1392, 01:46 صبح

سلام

SQL Server و به طور کل پایگاه های داده ای رابطه ای دیگر جوابگوی این چنین چالش ها نیستند.چالش های نو نیازمند روش های نو هست.با جنبش NoSQL آشنا شوید :

این حرفی که شما گفتید اصلا صحت نداره و میتونید برای کسب اطلاعات بیشتر به سایت tpc.org مراجعه کنید تا مقداری دیدتون تغییر کنه.

من دیتابیسم الان شده 5 گیگ و فایل لاگش شده 7 گیگ
این دیتابیس اصلا بزرگ نیست و یک دیتابیس کوچک به حساب میاد.

شما اگر فایل LOG و Backup های اون براتون اهمیتی نداره میتونید کلا Recovery Model رو روی Simple بذاری تا حجم Log کاهش پیداکنه.
اگر براتون اهمیت داره میتونید مثلا ابتدای روز یک Full Backup بگیرید در طی روز هر 5 دقیقه یکبار(بستگی به حجم Transaction ها دارد) یک Log Backup بگیرید و بعد دیتایبس رو Shrink کنید که حجم فایل log اینقدر زیاد نشه.
بعد برای کاهش مقدار فایل MDF نیز میتونید از یک دیتابیس Archive استفاده کنید و داده های مثلا برای دوسال قبل رو اونجا منتقل کنید و داده های سال جاری در دیتابیس مورد نظرتون باشه.
یا اینکه یک فیلد مثلا سال داشته باشید و داده ها رو براساس اون تفکیک کنید و گزارشات رو نیز با فیلتر کردن سال مالی بگیرید که کندی در گزارشات شما رخ نخواهد داد.

موفق باشید.

alimooghashang

جمعه 03 خرداد 1392, 10:04 صبح

ممنون
یعنی شما میگید با بک آپ گرفتن اونم به صورت سالیانه میشه از این مشکل خلاص شد؟
5 دقیقه یک بار؟ اینطوری که همه ش باید دیتابیس بسته بشه و بک آپ گرفته بشه!
یه راهکاری باید باشه که خود کارمندان بتونن این کار رو بکنن یا اینکه توی برنامه بصورت اتوماتیک انجام بشه، من که حضور ندارم که بک آپ بگیرم و شرینک کنمش!
بازم ممنون که راهنمایی میکنید

حمیدرضاصادقیان

جمعه 03 خرداد 1392, 12:36 عصر

دوست عزیز پس بهتره در مورد شیوه های Backup گیری مطالعه بفرمائید.
برای تهیه Transaction Log Backup نیازی نیست دیتابیس بسته بشه.
این Backup حجمش فوق العاده کمه شاید در حد چند KB و معمولا براش یک Job ایجاد میکنند که بعد از اینکار دیتابیس نیز shrink بشه و اصلا شما نباید در این امور دخالت کنید و باید به صورت خودکار انجام بشه.
پیشنهاد میکنم درمورد Backup اینجا (http://msdn.microsoft.com/en-us/library/ms175477.aspx) و در مورد Maintenance Plan اینجا (http://msdn.microsoft.com/en-us/library/ms187658.aspx)رو مطالعه کنید.

alimooghashang

جمعه 03 خرداد 1392, 12:52 عصر

log backup
A backup of transaction logs that includes all log records that were not backed up in a previous log backup. (full recovery model)

ایول چه باحال
به نظر میرسه مفید و کاربردی باشه
خب یه سوال
آیا برای این مدل بک آپ گیری نیازی هست که از transaction استفاده بشه یا نه؟
و اینکه اگه این مدلی بک آپ گرفته بشه، بعد برای دسترسی به اطلاعات بک آپ گرفته شده چه مدلی میشه بهشون دسترسی داشته باشیم؟
مدیریتش با خود sql server هست؟ یا باید اونا رو باهم مرج کرد؟
ممنون

مبین رنجبر

جمعه 03 خرداد 1392, 14:45 عصر

این حرفی که شما گفتید اصلا صحت نداره و میتونید برای کسب اطلاعات بیشتر به سایت tpc.org مراجعه کنید تا مقداری دیدتون تغییر کنه.

کدوم حرف من صحبت نداره ؟ اینکه SQL Server برای داده های بزرگ ساخته نشده ؟ یا اینکه چالش های نو نیازمند روش های نو است ؟

حمیدرضاصادقیان

جمعه 03 خرداد 1392, 22:37 عصر

SQL Server و به طور کل پایگاه های داده ای رابطه ای دیگر جوابگوی این چنین چالش ها نیستند
منظورم این بخش از صحبتها بود.

آیا برای این مدل بک آپ گیری نیازی هست که از transaction استفاده بشه یا نه؟
و اینکه اگه این مدلی بک آپ گرفته بشه، بعد برای دسترسی به اطلاعات بک آپ گرفته شده چه مدلی میشه بهشون دسترسی داشته باشیم؟
مدیریتش با خود sql server هست؟ یا باید اونا رو باهم مرج کرد؟
بله مدیریتش با خود SQL Server هست و برای بازیابی آخرین ّfull Backup قبل از Log Backup مورد نظر رو Restore کرده و مابقی فایلهای مورد نظر رو Restore میکنید.
در اون لینک نیز کامل در این زمینه توضیح داده شده است.

مبین رنجبر

جمعه 03 خرداد 1392, 23:07 عصر

منظورم این بخش از صحبتها بود.

خوب بفرمایید چرا صحت ندارد ؟

alimooghashang

جمعه 01 آبان 1394, 11:43 صبح

میشه یه کاری کرد؟
مثلا دیتابیس بصورت ماهانه بک آپ گرفته بشه و اطلاعات هر ماه در یک دیتابیس ذخیره بشه با همون اسم مثلا MYDB_94_07
بعد توی برنامه وقتی از ماه 07 خواستیم گزارش بگیریم این دیتابیس رو باز کنیم!؟
من میخوام ببینم این کارا روش استانداردی داره یا باید خودم یه اسکریپت از خودم بنویسم و سر هر ماه اونرو اجرا کنم

در کل کاری که میخوام بکنم اینه
بک آپ ماهیانه گرفته بشه
بک آپ روزانه هم گرفته بشه (فقط تغیرات که حجمش زیاد نشه)

maintenance plan رو بررسی کردم کار جالبی بود! ولی جاییش ندیدم که دست آدم رو باز بذاره که بتونه اسکریپت خودشم اجرا کنه!
اسکریپت خودم اینه که بعد از اجرا تاریخ بعدی اجرای اسکریپت رو آپدیت کنه (اول ماه بعد) ، ریکاور کردن بک آپ گرفته شده به دیتابیس ماه خودش مثلا بک آپ ماه 7 ریکاور بشه به دیتابیس ماه هفت با نام MYDB_94_07 که قابل دسترس هم باشه!
ممنون از راهنمایی هاتون