SQL Server

سلام خدمت دوستان عزیزم
امیدوارم حالتون عالی عالی باشه.
در خصوص سوالی که مطرح کردم برای ارائه راهکار.

نکته اول این هست که باید ببینیم آیا امکان ارتقای دیتابیس ها به یک نسخه مشترک هست یا خیر.
نکته دوم این هست که میزان RTO ,RPO برای دیتابیس های مختلف به چه صورت است؟
منظور از RTO همان Recovery Time Objective هست. یعنی زمانی که یک Disaster رخ می دهد ، چقدر میتوان Downtime داشت که آسیبی به کسب و کار نخورد. ممکن است برای بعضی از دیتابیس ها این عدد خیلی بالا باشه ممکنه برای بعضی از دیتابیس ها بسیار کم باشه. مثلا ممکنه برای بعضی در هفته ۵ ساعت باشه. ولی برای بعضی در سال ۲ ساعت باشه.
براساس اینها شما تصمیم میگیرید که برای دیتابیس فوق چه استراتژی تهیه کنید و در چه دسته ای قرار بدین.
منظور از RPO همان Recovery Point Objective هست.
یعنی اینکه در زمانی که یک Disaster رخ داد. چه مقداری از داده های دیتابیس مورد نظر از بین برود، آسیب جدی به کسب و کار نمیخورد و میتواند به کار خود ادامه دهد و آنرا دچار مشکل نمی کند.
ممکن است بعضی از دیتابیس ها تا یک هفته داده های آن از بین بروند اهمیتی نداشته باشند ولی ممکن است یک دیتابیس مثل سیستمهای بانکی حتی یک رکورد هم امکان از بین رفتن ندارد.

نکته سوم اندازه گیری وضعیت فعلی سرورها و میزان استفاده از منابع توسط هر دیتابیس و در هر سرور هست.

خوب حالا که این موارد مشخص شد. میتوانید راهکار ارائه بدین.
براساس اینها متوجه خواهید شد چند تا سرور نیاز دارید.
چند تا Instance نیاز دارید
بر روی هر Instance چند تا دیتابیس می تونید قرار بدین.
درسته که در هر Instance شما میتونید ۳۲۷۶۶ دیتابیس ایجاد کنید. زیرا Database_ID نوعش از نوع Smallint هست و چون یک دیتابیس مخفی به نام MSSQLResource نیز وجود دارد پس ۳۲۷۶۶ دیتابیس بیشتر نمیتونید بر روی یک Instance داشته باشین.
ولی بهتره بیش از ۱۰ ٪ حداکثر مقادیری که مایکروسافت برای هرچیزی تعیین کرده تعدی نکنید. مثلا برای دیتابیس ها اگر از ۳۲۷۶ عدد بر روی یک Instance فراتر رفتید ، این ممکنه یک نشونه طراحی بد دیتابیس ها باشه. ( البته این یک قانون همیشگی نیست و میتونه نقض هم بشه)

ادامش رو در پست های بعدی بهش اشاره می کنم.

شاد باشین و شکرگزار. ☺️☺️

ارادتمند شما
حمیدرضا صادقیان
@Hamidreza_Sadeghian

#HA
#DR
#Availability_Group
#AlwaysON

👍37❤2🔥1

www.tgoop.com/sql_server/702

12.4K viewsHamidreza, edited  Sep 30, 2022 at 19:16

سلام خدمت دوستان عزیزم
امیدوارم حالتون عالی عالی باشه.
در خصوص سوالی که مطرح کردم برای ارائه راهکار.

نکته اول این هست که باید ببینیم آیا امکان ارتقای دیتابیس ها به یک نسخه مشترک هست یا خیر.
نکته دوم این هست که میزان RTO ,RPO برای دیتابیس های مختلف به چه صورت است؟
منظور از RTO همان Recovery Time Objective هست. یعنی زمانی که یک Disaster رخ می دهد ، چقدر میتوان Downtime داشت که آسیبی به کسب و کار نخورد. ممکن است برای بعضی از دیتابیس ها این عدد خیلی بالا باشه ممکنه برای بعضی از دیتابیس ها بسیار کم باشه. مثلا ممکنه برای بعضی در هفته ۵ ساعت باشه. ولی برای بعضی در سال ۲ ساعت باشه.
براساس اینها شما تصمیم میگیرید که برای دیتابیس فوق چه استراتژی تهیه کنید و در چه دسته ای قرار بدین.
منظور از RPO همان Recovery Point Objective هست.
یعنی اینکه در زمانی که یک Disaster رخ داد. چه مقداری از داده های دیتابیس مورد نظر از بین برود، آسیب جدی به کسب و کار نمیخورد و میتواند به کار خود ادامه دهد و آنرا دچار مشکل نمی کند.
ممکن است بعضی از دیتابیس ها تا یک هفته داده های آن از بین بروند اهمیتی نداشته باشند ولی ممکن است یک دیتابیس مثل سیستمهای بانکی حتی یک رکورد هم امکان از بین رفتن ندارد.

نکته سوم اندازه گیری وضعیت فعلی سرورها و میزان استفاده از منابع توسط هر دیتابیس و در هر سرور هست.

خوب حالا که این موارد مشخص شد. میتوانید راهکار ارائه بدین.
براساس اینها متوجه خواهید شد چند تا سرور نیاز دارید.
چند تا Instance نیاز دارید
بر روی هر Instance چند تا دیتابیس می تونید قرار بدین.
درسته که در هر Instance شما میتونید ۳۲۷۶۶ دیتابیس ایجاد کنید. زیرا Database_ID نوعش از نوع Smallint هست و چون یک دیتابیس مخفی به نام MSSQLResource نیز وجود دارد پس ۳۲۷۶۶ دیتابیس بیشتر نمیتونید بر روی یک Instance داشته باشین.
ولی بهتره بیش از ۱۰ ٪ حداکثر مقادیری که مایکروسافت برای هرچیزی تعیین کرده تعدی نکنید. مثلا برای دیتابیس ها اگر از ۳۲۷۶ عدد بر روی یک Instance فراتر رفتید ، این ممکنه یک نشونه طراحی بد دیتابیس ها باشه. ( البته این یک قانون همیشگی نیست و میتونه نقض هم بشه)

ادامش رو در پست های بعدی بهش اشاره می کنم.

شاد باشین و شکرگزار. ☺️☺️

ارادتمند شما
حمیدرضا صادقیان
@Hamidreza_Sadeghian

#HA
#DR
#Availability_Group
#AlwaysON

BY SQL Server