عملکرد 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 برای مفهومی بهتر در شکل زیر این ۲ مفهوم را در این سناریو مشخص کرده‌ام:

سرویس‌های DataGuard

خب همانطور که در مطالب قیل گفتیم DataGuard مدیریت سرورهای Primary و Standby و روابط بین این ۲ رو داره و خب می‌تونه دارای چند سرویس باشه:

• LogTransportServices = این سرویس وظیفه انتقال تغییرات از سرور primary به سرورهای Standby رو داره

• ApplyServices = این سرویس وظیفه apply کردن تغییرات رو با استفاده از پروسسی به نام RFS بر روی StandbyLogFile ها داره

• RoleManagementServices = این سرویس نقش سرویس‌ها رو مشخص می‌کنه در حالت عادی شما یک سرور primary دارید و یک سرور standby ولی زمانی که switchover اتفاق می‌افته نقش این ۲ سرور باهم عوض میشه یعنی سرور primary میشه سرور standby و سرور stanby میشه primary

نکته: اگر سروها failure باشند سرور primary دیگه وجود نداره و سرور standby نقش سرور اصلی رو بازی میکنه.

LogTranport به روش Sync

خب همانطور که گفتیم اولین سرویس ما Log TransportServices هست. LogTransportServices میتونه به ۲ روش دیتا رو منتقل کنه به سرور standby (بستگی به سناریو شما برای active dataguard)

• روش Sync = یعنی سرور standby شما هیچ تفاوتی با سرور اصلیتون نداره

مثال: کاربرهای شما وقتی تغییراتی روی tableهای دیتابیستون میدن تا زمانی که اطلاعات commit نشه توسط باقی کاربران این تغییرات قابل مشاهده نیست پس هر تغییری نیازمند commit است. این قضیه رو بذارید کنار مفهوم redo log buffer یعنی نغییراتی که توی دیتا به وجود اومده و هنوز روی دیسک نوشته نشده و اطلاعات هنوز داخل بافر SGA است.

خب این تغییرات باید به سرور standby‌ منقل بشه پس یه پروسسی به اسم LNS (Log Network Services میاد و تغییرات رو به سمت سرور standby منتقل می‌کنه. یه پروسس دیگه به اسم RFS (Remote File Server میاد این تغییرات رو از LNS دریافت می‌کنه و روی standby redo log file ها تغییرات رو می‌نویسه و همزان بعد این موضوع این تغییرات بر روی سرور standby میاد و apply میشه.

خب زمانی که apply شد RFS به LNS میگه من تغییرات رو apply‌ کردم و میره سراغ log writer روی سرور اصلی

log writer میاد و یه ack به سمت primary میفرسته و میگه من تغییرات رو روی سرور standby به صورت apply درآوردم شما می‌تونید commit جدید کنید پس هزمان با commit‌تغییرات روی online redo log فیالهای سرور اصلی نوشته میشه. پس نتیجه می‌گیریم که تا زمانی که سرور primary اطمینان از apply شدن تغییرات روی سرور standby یا حداقل نوشته شدن روی یکی از standby log file ها دستورات جدید کاربران commit نمی‌شوند.

به همین علته که سرور standbyاتون هیچ تغییری با سرور primaryاتون نداره یعنی در اصطلاح apply back شما 0 ثانیه است. به همین دلیل شما تو سناریوی sync شما هیچ دیتایی رو از دست نمی‌دید. 

• روش Async = توضیحات این روش همانند روش sync است فقط تفاوتش در اینه که Redo Buffer شما اول سراغ Log Writer می‌رود Log Writer اطلاعات را روی Online Redo Log File ها می‌نویسه و از روی اون LNS دیتا رو میخونه

در حقیقت تفاوت روش Async با sync در این است که در این روش Commit Act Knowledge منتظر Apply شدن روی سرور Standby نمی‌مونه و دستورات (در حقیقت همون تغییرات) هر چه که هست commit میشه و همزمان هم LNS اطلاعات رو از Online Log File ها میخونه و روی (RFS (remote file server می‌نویسه و RFS هم منتقل می‌کنه به یکی از Standby Log Fileها

اگر بخواهیم به زبانی ساده‌تر این قضیه را روش کنیم به این صورت است که شما در sync اطلاعات رو از روی buffer می‌خونید و توی Async شما اطلاعات رو از online redo log file ها می‌خونید.

به شکل زیر دقت کنید:

مقدمه‌ای بر Oracle Streams

همانطور که گفتم در نسخه‌های اخیر Oracle GoldenGate جایگزین Oracle Streams شده

در بحث Oracle DataGuard قضیه sync بین primaryها و standbyها یکطرفه است. ولی در سناریو Streaming شما می‌تونید sync دوطرفه داشته باشید. یعنی ۲ تا پایگاه داده داشته باشید که در هر ۲ وقتی کاربران اطلاعات وارد و یا آپدیت می‌کنن اطلاعات نوشته میشه و در نهایت این ۲ سرور اط نظر اطلاعات یکی هستند.

همچنین شما می‌تونید کاربرد خاص‌تری از streaming بگیرید و فقط یکسری از جداول و schema های خاص رو در هر ۲ باهم sync کنید.(از سرور مبدا به سرور مقصد)

Oracle Streams یا Oracle GoldenGate قابلیت انعطاف‌پذیری بسیار بالایی داره، شما می‌تونید حتی دیتابیس اوراکل رو با پایگاه‌‌داده‌های دیگه‌ای غیر از اوراکل (مثل DB2, SQL Server, ...) بیاین و sync کنید.