۳ مطلب با کلمه‌ی کلیدی «Active Data Guard» ثبت شده است

حالت‌های پیکربندی Protection Modes

در مطالب پیش گفتیم که در بحث Active Data Guard ما ۲ حالت Sync و Async برای سرویس Apply داریم.

حالا می‌خوایم ببینیم که ما Protection Mode مون رو یا حالت محافظت از دیتامون رو تو چند حالت می‌تونیم قرار بدیم؟

  • Maximum Performance

در این حالت شما براتون کارایی و Performance بیشتر براتون اهمیت داره حالا ممکنه براتون سوال پیش بیاد که Performance دقیقاً چه ارتباطی با Active Data Guard داره؟

در حقیقت ارتباطش تو قسمتی معنی پیدا میکنه که شما منتظر apply بودید یعنی تا زمانی که اطلاعات روی سرور standby به صورت apply شده نبود این تغییرات بر روی سرور اصلی commit نمی‌شد.

نکته: همین حالت ممکنه تو حجم Transaction های بالا باعث کندی بشه

خب اگه ما بخوایم این موضوع در نظر بگیریم که نخوایم سرور primaryمون بدون commit‌ باشه تو این حالت apply service امون رو Async در نظر می‌گیریم  و تو Maximum Performance می‌گیم که دیگه لازم نیست منتظر apply بمونی شما دیتا رو commit کنن و هر زمانی که RFS تغییرات رو دریافت کرد و روی standby log file ها نوشت بعد دیتا رو sync کن

پس تو این وضعیت برای ما فقط Performance اهمیت داره

  • Maximum Protection

این موضوع برعکس موضوع Maximum Performance هستش در این حالت برای ما دیتا اهمیت داره یعنی ما نمی‌خوایم هیچ دیتایی از دست بره خب تو مطالب قبل راجع به sync و async به اندازه کافی گفتیم. در حقیقت تو قسمتی که sync بود گفتیم که تا زمانی که apply service روی سرور standby تغییرات رو apply نکرده تغییرات در سرور اصلی commit نمی‌شود یعنی acknowledge که برای commit میره اونور منتظر apply می‌مونه.

خب ما توی پیکربندی protection mode یه حالتی هستش که وضعیت protectionمون یا از دست ندادن دیتامون برامون اهمیت داره که تو این حالت حتماً باید apply serviceمون تو وضعیت sync باشه

خب توی این حالت یه پارامتری داریم به اسم Timeout که اینو در نظر می‌گیره که شما یک مقدار زمانی رو صبر کن اگر دیدید سرور standbyتون نتونسته apply کنه سرور primary رو بیا shutdown کن

پس به علت اینکه ممکنه تغییرات روی سرور standby‌ انجام نشه و شما دیتا رو از دست بدید به همین دلیله که یک مدت کوتاهی رو صبر میکنه اگه ببینه رو سرور standby شما apply انجام نمیشه میاد دیتابیس اصلی شما رو shutdown میکنه

  • Maximum Availability

خب در برخی مواقع در حالت قبلی ما نمی‌خوایم سرورمون shutdown بشه یعنی اینکه ممکنه سرور اصلی ما دیسک‌های خودشو داشته باشه همچنین سوای اینکه کاربرها دارن کار می‌کنن و حالا ممکنه طول بکشه تا دیتاها روی standby اعمال بشه می‌گیم که این قضیه که سرور اصلی‌مون shutdown نشه برامون خیلی اهمیت داره 

در حقیقت solution اوراکل برای این قضیه Maximum Availability است.

Maximum Availability میاد میگه که من Maximum Protectio رو به طور کامل تو حالت عادی دارم یعنی Sync رو تو حالت عادی انجام میدم و دیتا رو تا زمانی که توی سرور standby من apply نکردم تغییرات رو commit رو روی سرور اصلی انجام نمیدم.

اما همچنین اگه اختلالی بین ارتباط primary و standby به وجود اومد دیگه منتظر apply نمی‌مونم دیتا رو commit میکنم و زمانی که این ۲ تا ارتباطشون باهم برقرار شد از طریق apply log که در مرحله قبل توضیح دادم دیتا رو میاد روی سرور standby با استفاده از Archive Redo Log فایل apply میکنه

۲۰ خرداد ۹۴ ، ۱۳:۳۹ ۰ نظر
مهدی غفاری

عملکرد Data Guard در صورت Gap

خب ممکنه برای شما این سوال پیش بیاد که اگه Data Guard شما روش gap بیوفته یا اینکه سرور primary شما با سرور standby شما ارتباطش دچار اختلال بشه و نتونن همدیگه رو ping کنن در این حالت چه اتفاقی برای دیتاهای شما رخ میده؟

در اصل می‌خوایم ببینیم که سناریوی Data Guard و Active Data Guard برای این حالت چه راه‌حلی ارائه میده؟

خب مفاهیم LNS و RFS رو در پست‌های قبل توضیح دادیم.

به تصویر بالا اگر دقت کنید در حقیقت یک حالت عادی رو در آن مشاهده می‌کنید که LNS‌ میاد و از Redo Buffer روی RFS می‌نویسه و اونم روی Standby Redo Logها می‌نویسه منتها اگر gap به وجود بیاد شما باید به حالت زیر دقت کنید:

در این حالت تا زمانی که sync در حالت عادی اتفاق نیافتاده است یعین LNS نتونه از روی Redo Buffer بخونه Active Data Guard در حقیقت میاد کنترل میکنه از روی کنترل فایلهای سرور standby میاد میبینه که در حقیقت ما چقدر لگ داریم اگر لگ ما به اندازه‌ای بود که اطلاعات روی redo ها یا روی redo buffer ها وجود نداشته باشه میاد سراغ Archive Redo Log فایلهای سرور اصلی و از روی این آرشیوها پروسس RFS میاد روی Archive Redo Logهای سرور standby شما اون دیتا رو می‌نویسه (به شکل بالا دقت کنید)

و به این ترتیب دیتاها apply میشه روی خود سرور standby

نکته: این اتفاق تا زمانی که اطلاعات شما دیگه توی Archiveهای سرور اصلی نباشه و روی redo buffer یا همون online redo Logها باشه و این دقیقاً بستگی داره به وضعیت Sync یا Async شما

اگر دقت کرده باشید زمانی که وضعیت standby را sync‌کنید یک tranport lag داریم و یک apply lag که Transport Lag مربوط به انتقال لاگ فایل هست و Apply Lag مربوط به apply شدن تغییرات روی سرور standby برای مفهومی بهتر در شکل زیر این ۲ مفهوم را در این سناریو مشخص کرده‌ام:

۱۷ خرداد ۹۴ ، ۱۸:۲۸
مهدی غفاری

پرسش و پاسخ

س: آیا ساختار کش ساختاری منسجم است؟

ج: بله - ولی به طور دستی قابلیت ویرایش توسط DBA را ندارد مگر با برنامه‌نویسی از طریق SQLJ

نکته: با SQLJ حتی می‌توان روش رمزنگاری اوراکل را هم عوض کرد.

س: وقتی تعداد داده‌های جدول در دیتابیس زیاد باشد آیا موقع کوئری گرفتن تمام این جدول به یکباره کش می‌شود؟

ج: اگر تعداد داده‌های جدول شما خیلی زیاد باشد که امکان کش بصورت یکباره وجود نداشته باشد اوراکل جدول را تکه تکه کش می‌کند. و در این صورت سیستم کش اوراکل از بیس رفته است. به طور مثال اگه حدول شما بسیار بزرگ باشد و رم کافی نداشته باشید اوراکل تکه تکه جدول رو درون فضای SGA می‌آورد و روی PGA پردازش را انجام می‌دهد و اگر به داده مورد نظر خود نرسد تکه فعلی را از فضای SGA بیرونن می‌برد و تکه بعدی را وارد فضای SGA می‌کند تا پردازش آن صورت گیرد.

س: زمانی که اوراکل چند جدول را کش کرده است و برای کش کردن جدول جدید دیگر فضای رمی نداریم چه اتفاقی می‌افتد؟

ج: اوراکل جدولی را که کمتر بهش ارجاع شده است را از کش بیرون می‌برد و جدول جدید را کش می‌کند.

س: اگر ما ۱۰ میلیون رکورد داشته باشیم و بخوایم روی این ۱۰ میلیون رکورد کوئری بزنیم اوراکل تا چه مقدار توانایی انجام سریع این کوئری رو داره؟

ج: اگر شما ۱۰ میلیون رکورد داشته باشید و بخواین روی این ۱۰ میلیون رکورد کوئری بزنید و RAM کافی نداشته باشیم نه تنها اوراکل خوب عمل نمی‌کنه بلکه ضعیف هم عمل نمی‌کنه (این مطلب در مورد تمام دیتابیس‌ها صادقه، چون شما باید محفظه کش‌ات حداقل اندازه result هات باشه)

به خاطر همین موضوع ما از SI به محیط RAC سوییچ می‌کنیم چون هرچه قدر هم سرور ما قوی باشه جوابگو SGA نیست چون وقتی دیتای ما که تو هارده نزدیک 20exabyte باشه شما هیچ رمی رو نمی‌تونید روی یک سرور بذارید که فضای SGA بتونه این حجم اطلاعات رو بالا بیاره و کش کنه(البته ۲۰ اگزابایت ما وقتی میاد رو RAM میشه نزدیک ۵ اگزابایت ولی باز ما همچین رمی رو نمی‌تونیم برای یک سرور در حالت SI پیدا کنیم) برای همین ما ورود پیدا می‌کنیم به محیط RAC که در این محیط ما دیگر یک فضای SGA نداریم و مجموعه‌ای از کلاسترها رو داریم که مثلاً هر کلاستر ۶۴ گیگ RAM داره(حالا وقتی ما صحبت از ۲۰ اگزابایت می‌کنیم حتماً نیاز به ۱۰۰۰ کلاستر ۶۴ گیگ RAM داریم که بتونیم از اون کش استفاده کنیم)

س: فضای SGA و PGA چقدر است؟

ج: این فضا موقع نصب توسط DBA از درصدی از مقدار رم شما مشخص می‌شود. همچنین بعد از نصب در صورت نیاز به تغییر قابل تغییر است.

ادامه مطلب...
۰۳ فروردين ۹۴ ، ۰۱:۲۲ ۰ نظر
مهدی غفاری