ساخت سرویس جدید در سناریو دیتاگارد بدون زیرساخت Grid

تو سناریوی اوراکل دیتاگارد ما یک مدار دیتابیسی تشکیل میدیم که هر وقت سرور اصلی در سایت A از دسترس خارج شد اپلیکیشن با وقفه کوتاهی بتونه به سرور دوم در سایت B متصل بشه (تو سناریو حداکثر پایداری بهتره اپلیکیشن های ریپورت به دیتاگارد متصل نشن و برای سناریو اکتیو دیتاگارد یک دیتاگارد مجزا و مختص به ریپورت به صورت آبشاری راه اندازی بشه که بار روی سرور اصلی هم نباشه)

جهت انجام خودکار این سناریو به طوری که اپلیکیشن به یک سرویس جدا وصل بشه و وابسته به سرویس و IP در هر Instance در مواقع Failover و Switchover نباشه میتونید به شیوه زیر عمل کنید:

تعویض پسورد SYS در محیط DataGuard

خب اگه شما پسورد کاربر SYS رو با دستور ALTER USER SYS IDENTIFIED BY NEWPASSWORD در دیتابیسprimary عوض کنید SYNC از طرف سرور Primary متوقف می‌شود و آرشیولاگهای جدید به سمت دیتابیس Standby فرستاده نمی‌شودند. در این حالت شما خطای زیر رو در فایل alertlog می‌بینید:

------------------------------------------------------------------
Check that the primary and standby are using a password file
and remote_login_passwordfile is set to SHARED or EXCLUSIVE,
and that the SYS password is same in the password files.
returning error ORA-16191
------------------------------------------------------------------

این به این دلیله که شما از دستور ALTER USER برای تعویض پسورد کاربر SYS استفاده کرده‌اید و پسورد شما هم در فایل پسورد و هم در دیتادیکشنری به درستی در سرور Primary آپدیت شده ولی در سرور Standby تغییرات اعمال نشده‌اند.

شما با دستور زیر می‌تونید پسورد SYS رو در سرور Standby آپدیت کنید:

orapwd file=$ORACLE_HOME/dbs/orapwSID password=newpassword;

فراموش نکنید که فایل قبلی رو حذف کنید (توصیه میشه فقط اسم فایل رو عوض کنید تا اگه به مشکلی خوردید بتونید از فایل قبلی استفاده کنید، من خودم آخر فایلها یه پسوند old اضافه میکنم.)

نکته: حواستون باشه اصلاً مهم نیست پسورد SYS سمت Primary رو عوض کردید یا 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 Active DataGuard

در مطالب قیل توضیح دادیم که تکنولوژی Oracle Active Data Guard یکی از روش‌هایی که ما می‌تونیم با استفاده ازش سریعاً از قطعی جلوگیری کنیم. خب قبل از اینکه معماری Active Data Guard رو توضیح بدیم باید یکسری تعاریف رو باهم مرور کنیم:

• RMAN = یکی از راه‌های بازیابی‌اطلاعات در بحث high availability استفاده از RMAN است. RMAN ابزار Recovery Manager اوراکل است که استفاده‌های بسیاری دارد. با استفاده از این ابزار شما می‌توانید اطلاعات را بک‌آپ‌گیری و بازیابی کنید، حتی می‌تونید یک TableSpace خاص رو یا یک DataFile خاص رو ازش بک‌آپ بگیرید. اگر خرابی در دیتا به وجود اومده باشه شما با این ابزار می‌تونید خرابی دیتا رو بازیابی کنید.
  RMAN از بک‌آپ دیسک‌ها و Archive Logها برای ریستور و ریکاوری استفاده می‌کنه. همچنین شما با استفاده از ابزار RMAN می‌تونید سرور standby بسازید که بحث اصلی ما در Active Data Guard همین standby است.
• سرور Standby = سروری که در زمانهایی که سرور اصلی (primary) شما به مشکل می‌خوره و قطع میشه(مثل خرابی فایلهای اصلی دیتابیس، نفض فنی، به مشکل خوردن ارتباط کاربران با سرور اصلی به هر دلیل و یا یک قطعی برنامه‌ریزی شده) پس این سرور میتونه جایگزین سرور اصلی بشه
• DataGuard = به مجموعه سرور primary و standby و ارتباط بین این ۲ تکنولوژی Data Guard می‌گویند. که یک دیتابیس اصلی داره که تراکنش‌های کاربران مثل خواندن و نوشتن و ... در آن انجام میشه و یک یا چند دیتابیس standby که اطلاعات از سرور اصلی باهاشون sync میشه (البته sync هم انواع مختلفی داره که به موقع به هر کدوم می‌پردازیم)
• Active DataGuard = از نسخه ۱۱ به بعد این تکنولوژی معرفی شد. تفاوت Active DataGuard با DataGuard اینه که شما در تکنولوژی DataGuard اوراکل سرور standby تا زمانی که سرور primary در مدار باشه عملاً استفاده‌ای نداشت و فقط دیتا باهاش sync میشد و سرور standby در وضعیت mount به سر می‌برد. منتها در نسخه ۱۱ با ارائه Real Time Apply شما می‌تونید وضعیت دیتابیستون رو در حالت open قرار بدید و از سرور stanby استفاده کنید (گزارش بگیرید یا حتی با استفاده از RMAN بک‌آپ‌هاتون رو از این سرور بگیرید و یا این سرور standby اگه در وضعیت logical می‌تونید حتی روش Index تعریف کنید و ساختار فیزیکی متفاوتی از سرور اصلی در آن داشته باشید.
• DataGuard Broker = یک چارچوب مدیریتی توزیع شده است که ایجاد، نگهداری و نظارت بر تنظیمات DataGuard رو به عهده داره

مزیت سرور Standby یا RMAN

سرور standby در کمترین زمان ممکن می‌تونه جایگزین سرور اصلی بشه و به دلیل اینکه اطلاعات در عصر حاظر برای سازمانها بسیار مهم است و همچنین دسترسی سریع کاربران به اطلاعات بسیار حائز اهمیت است راهکار Oracle Active DataGuard برای سازمانها پیاده‌سازی میشه

انواع سرور Standby

همانطور که قبلاً گفتیم سرور Standby می‌تونه چند نوع باشه:

1. Physical
2. Logical

اگه از 11g به بعد بخوایم در نظر بگیریم سرور physical سروری است که ساختار فیزیکی آن کاملاً مشابه سرور اصلی است. منتها در حالت readonly است و شما فقط می‌تونید ازش select بگیرید و دیگه insert و یا تغییرات ساختاری در دیتابیس وجود نداره

اما سرور Logical سروری است که در وضعیت r/w قرار داره و حتی میتونه ساختار فیزیکی‌اش با سرور اصلی متفاوت باشه. یعنی می‌تونید روش index بسازید یا حتی جدول جدید بسازید و یا حتی schema های جدید بر روی آن بسازید و دیتا روش insert کنید منتها sync آن با سرور اصلی یکطرفه است یعنی تغییراتی که شما روی سرور Logical می‌دید روی سرور Primary اعمال نمی‌شود.

در شکل زیر یک سررو primary‌ داریم که با استفاده از Async یا Sync میاد Redo ها رو روی سرور Physical Standby می‌نویسه

و با استفاده از SQL میاد کپی داده‌ها را در Logical Standby می‌نویسه در حقیقت به همین خاطره که بهش می‌گن Logical Standby

نکته: کپی داده با استفاده از Redo یک مفهوم فیزیکی است و کپی با SQL یک مفهوم منطقی است. به همین خاطر بهش Logical Standby گفته می‌شود.

مقدمه‌ای بر معماری Oracle Data Guard

خب میخوایم یه ذره راجع به DataGuard و انواع اون صحبت کنیم.

پرکاربردترین نوع Oracle Data Guard نوع Physical Standby هست. توی Physical Standby دیتابیس شما در وضعیت readonly قرار می‌گیره و تضمین میکنه که داده‌های شما از بین نمیره در صورتی که دیتابیس‌ها باهم sync باشند.

نحوه کپی اطلاعات برای sync کردن توسط Archive Redo Logsها هستش. در حقیقت وقتی Archive Redo Log File ها در سمت دیتابیس primary ساخته میشه به سمت سرور standby فرستاده میشه و با استفاده از standby Redo Log File ها بر روی سرور standby قرار می‌گیرند (apply می‌شوند)

همچنین شما می‌تونید از سرور physical standby بک‌آپ هم بگیرید.

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

خب همانطور که گفتم physical standby به صورت readonly هستش، حالا اگر شما می‌خواهید تغییراتی در سرور standby داشته باشید باید این دیتابیس در وضعیت read/write قرار بگیره.

برای انجام اینکار باید سرور physical خود را به سرور logical تبدیل کنید. توی این حالت redo فایلها تبدیل به دستروات sql میشه و بعد بر روی سرور logical شما apply میشه.

کاربرد این حالت بیشتر روی سرورهای گزارش‌گیر هستش که شما می‌تونید indexهای متفاوت و یا materialized view های متفاوت تعریف کنید و یا برای تیم‌های دولوپ که فرضاً احتیاج به یسری بک‌آپ از سرور دارند می‌تونند از این سرور logical استفاده کنند و بک‌آپ‌ها رو روی این سرور import کنن و ازش استفاده کنند.

مثال

فرض کنید database primary شما در تهران است، می‌خواهیم ۲تا سایت داشته باشیم و به صورت ریموت از این ۲تا سایت استفاده کنیم که اگر زمانی مشکلی برای سرور تهران پیش اومد شما به physical standby که در تبریز هست سوییچ کنید بدون اینکه مشکلی توی سیستم به وجود بیاد همچنین می‌تونیم یک logical standby توی یک شهر دیگه فرضاً شیراز داشته باشیم و از این logical برای گزارش‌گیری استفاده کنیم و یا حتی از logical به عنوان یک سرور standby دیگه استفاده کنیم و روش سوییچ بزنیم.

قابلیت Far Sync - Road Map

این قابلیت در نسخه 12c معرفی شده که در این تکنولوژی دیگه instance اهمیتی نداره و پهنای باند شما هر چقدر باشه با استفاده از این تکنولوژی می‌تونید سرور stanby رو راه‌اندازی و مدیریت کنید.

در این قابلیت شما می‌تونید چندین دیتابیس stanby داشته باشید که سرور primary اونها رو سرویس میده.

در این حالت شما می‌تونید هم سرور Physiacl Standby داشته باشید و هم Logical Standby

معماری این حالت هم شبکه ۱ به n هست یعنی شما می‌تونید n تا سرور داشته باشید که از سمت primary به standby ها آرشیوها ارسال بشود.

همچنین در سرعت‌های پایین شبکه نیز این معماری قابل استفاده است.

به طور خلاصه:

• پشتیبانی از چند دیتابیس standby
• استفاده از Pgusical & Logical Standby
• معماری شبکه یک به چند
• پشتیبانی در سرعت‌های پایین شبکه