معرفی کتاب Oracle Data Guard 11gR2 Administration Beginner's Guide

از بهترین کتابهای موجود برای یادگیری نحوه پیکربندی ویژگی Oracle Data Guard پایگاه داده اوراکل - نسخه 11g کتاب Oracle Data Guard 11gR2 Administration Beginner's Guide نوشته Emre Baransel, Nassyam Basha، انتشار یافته توسط انتشارات packt است.

سناریو نصب و راه‌اندازی اوراکل دیتاگارد 11g همراه با ASM - مرحله به مرحله - قسمت چهارم

ما ۴ تا name در دیتابیس داریم که از اول هر ۴ تای این اسامی در دیتابیس اوراکل نبوده‌اند و به مرور نسخه‌های مختلف و زمان ایجاد شده‌اند.

ORACLE_SID (در سطح OS) = این پارامتر در سطح OS ما است. اگر پارامتر db_name مقداردهی نگردند مقدار این پارامتر را می‌گیرد.

DB_NAME (اجباری، یکسان باشد*) = اسم دیتابیس و به معنای کلمه جایی که دیتاها ذخیره می‌شوند. عمیقاً کلمه دیتابیس به ۳ دسته از فایل‌ها گفته می‌شود:

۱) دیتافایل‌ها ۲) فایلهای ORL, CTL, SPFILE منظور DB_NAME فایلهای دیتابیس است که مجزا از Instance هستند.

ORACLE DB_NAME PARAMETER V11.2 - LINK

سناریو نصب و راه‌اندازی اوراکل دیتاگارد 11g همراه با ASM - مرحله به مرحله - قسمت سوم

به قسمت سوم از راه‌اندازی سناریو Active DataGuard پایگاه داده اوراکل خوش آمدید

پیکربندی rlwrap

تو مرحله اول از این سری نصب و راه‌اندازی پکیج rlwrap رو معرفی و نصب کردیم. حالا نوبت به این رسیده که پیکربندی مورد نیاز رو انجام بدیم

[oracle@shafaq ~]$ vim ~/.bash_profile

# rlwrap configuration
alias condb='rlwrap sqlplus / as sysdba'
alias conrm='rlwrap rman target /'
alias condg='rlwrap dgmgrl /'

از این به بعد از aliasها برای اتصال به دیتابیس، rman و گلدن گیت استفاده می‌کنیم.

چک کردن وضعیت grid و database

از طریق کاربر grid به سیستم‌عامل login کرده و با دستور crsctl نسبت به بررسی وضعیت منابع grid و database به شکل زیر اقدام می‌کنیم

از آپشن help می‌توانید برای کمک بیشتر استفاده کنید

crsctl = cluster control
----
stat = status
res = resurces
option t = Tabular display

چک کردن سایت شفق (primary)

[grid@shafaq ~]$ crsctl stat res -t
--------------------------------------------------------------------------------
NAME           TARGET  STATE        SERVER                   STATE_DETAILS
--------------------------------------------------------------------------------
Local Resources
--------------------------------------------------------------------------------
ora.DATA.dg
               ONLINE  ONLINE       shafaq
ora.FRA.dg
               ONLINE  ONLINE       shafaq
ora.LISTENER.lsnr
               ONLINE  ONLINE       shafaq
ora.asm
               ONLINE  ONLINE       shafaq                   Started
ora.ons
               OFFLINE OFFLINE      shafaq
--------------------------------------------------------------------------------
Cluster Resources
--------------------------------------------------------------------------------
ora.cssd
      1        ONLINE  ONLINE       shafaq
ora.diskmon
      1        OFFLINE OFFLINE
ora.evmd
      1        ONLINE  ONLINE       shafaq
ora.orcl.db
      1        ONLINE  ONLINE       shafaq                   Open

سناریو نصب و راه‌اندازی اوراکل دیتاگارد 11g همراه با ASM - مرحله به مرحله - قسمت دوم

به قسمت دوم از راه‌اندازی سناریو Active DataGuard پایگاه داده اوراکل خوش آمدید

پیش‌فرض‌ها:

• سایت شفق = سایت primary
• سایت تابان = سایت standby

ایجاد دیتابیس با ابزار DBCA

به DBCA خوش آمدید

بر روی سایت primary از طریق کاربر oracle به سیستم‌عامل login کرده و ابزار Database Configuration Assistant را با دستور dbca اجرا میکنیم

به دستیار پیکربندی دیتابیس‌ها در پایگاه داده اوراکل خوش‌آمدید. این برنامه به شما در ایجاد دیتابیس، پیکربندی دیتابیس موجود، حذف یک دیتابیس و مدیریت تمپلیت‌های نصب دیتابیس کمک زیادی میکنه. بر روی Next کلیک می‌کنیم تا از صفحه Welcome گذر کرده باشیم:

بروزرسانی سرور دیتاگارد در حالتی که فایل‌های آرشیو وجود ندارند

خب اول روی سرور دیتا گارد دستور زیر را اجرا می کنیم تا آخرین SCN دیتاگارد را بدست می‌آوریم:

SQL> SELECT CURRENT_SCN FROM V$DATABASE;

CURRENT_SCN
-----------
 1752252019

عملیات ریکاوری را روی دیتاگارد با دستور زیر متوقف می کنیم:

ORA-03113: end-of-file on communication channel

بعد از تغییراتی روی زیرساخت ماشین‌های کلاستر rac با ۲ نود (دیتابیس 11.2.0.4.0) به مشکلی برخوردم که در نوع خودش برام جالب بود در حقیقت یکی از instanceهای کلاستر بدون مشکل startup می‌شد ولی instance دوم به هیچ عنوان open نمی‌شد و خطای زیر رو نشون میداد:

ORA-03113: end-of-file on communication channel
Process ID: 20194
Session ID: 1655 Serial number: 5

بعد از چک کردن فایل log دیتابیس مربوط

WARNING: The 'LOG_ARCHIVE_CONFIG' init.ora parameter settings
are inconsistent with another started instance. This may be
caused by the 'DB_UNIQUE_NAME' init.ora parameter being specified
differently on one or more of the other RAC instances; the
DB_UNIQUE_NAME parameter value MUST be identical for all 
instances of the database.

خب اینجا بود که فهمیدم باید یه سری به پارامتر log_archive_config بزنم بعد از بررسی این پارامتر فهمیدم که مقدار null برای اون set شده و همچنین db_unique_name یکسان داریم که از این بابت مشکلی نیست.

برای ریست کردن این پارامت از دستور زیر در وضعیت mount استفاده کنید

alter system set log_archive_config='dg_config=(nodg_config)' scope=both sid='*';

با دستور زیر می‌تونید پیکربندی دیتاگاردتون رو چک کنید:

SQL> Select * from v$dataguard_config;

DB_UNIQUE_NAME

------------------------------
dwh
dwh_stby

و اگه کانفیگ دیتاگاردتون هنوز موردنیازه دستور رو طبق نیاز خود سفارشی کنید:

alter system set log_archive_config='dg_config=(dwh,dwh_stby)' scope=both sid='*';

رفع مشکل Warning: ORA-16826: apply service state is inconsistent with the DelayMins property

امروز تو یکی از سایتهام به مشکل زیر در DGMGRL خوردم

DGMGRL for Linux: Version 11.2.0.4.0 - 64bit Production
Copyright (c) 2000, 2009, Oracle. All rights reserved.

Welcome to DGMGRL, type "help" for information.
Connected.
DGMGRL> show configuration;

Configuration - primary
Protection Mode: MaxAvailability
 Databases:
 orcl - Primary database
 orcldg - Physical standby database
 Warning: ORA-16826: apply service state is inconsistent with the DelayMins property

Fast-Start Failover: DISABLED
Configuration Status:

WARNING

نگاهی بر معماری Oracle Data Guard - قسمت اول

تو این مجموعه پست‌ها میخوایم نگاهی مقدماتی بر اوراکل دیتاگارد از روی اسلایدهای اوراکل داشته باشم:

 

بعد از کامل کردن این سری از اسلایدها شما قراره:

• کامپوننت‌ها و اجزای دیتاگارد رو بشناسید
• اختلاف بین physical standby و logical standby رو بدونید
• فواید پیاده‌سازی دیتاگارد رو بشناسید

نکته: کلاً وقتی دیتاگارد راه میندازیم یعنی ۲ تا سرور داریم یکی سرور اصلی primary و یکی سرور دیتاگارد که بهش standby می‌گیم (چون همیشه آماده به خدمته)

حالت‌های پیکربندی 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 میکنه