Artarad_oracle_convert_rac

تبدیل پایگاه‌داده اوراکل غیر کلاستر به کلاستر

مقدمه
اوراکل از روش‌های مختلفی برای تبدیل یک پایگاه‌داده غیر کلاستر به کلاستر پشتیبانی می‌کند. نکته قابل‌ملاحظه در این تبدیل یکسان بودن سیستم‌عامل‌ها و نگارش پایگاه‌داده می‌باشد. فهرست روش‌های پشتیبانی‌شده به شرح زیر است.
۱٫ DBCA
۲٫ Oracle Enterprise Manager (Grid Control)
۳٫ RCONFIG
۴٫ Manual Method

تبدیل پایگاه‌داده اوراکل غیر کلاستر به کلاستر
در این مستند به روش RCONFIG که از ابزار خط فرمانی استفاده می‌کند پرداخته می‌شود. مراحل کلی RCONFIG عبارت است از :
• مهاجرت به ASM
• ایجاد Inctance های کلاستر بر روی کلیه نودها
• اصلاح تنظیمات Listener و NetService
• رجیستر کردن سرویس‌ها در CRS
• راه‌اندازی Listener ها و Instance ها بر روی کلیه نودها
در نگارش ۱۱gR2 امکان تبدیل‌شدن به Admin-Managed و Policy-Managed کلاستر وجود دارد. دو فایل XML برای تبدیل پایگاه‌داده غیر کلاستر به کلاستر با نام‌های ConvertToRAC_AdminManaged.xml و ConvertToRAC_PolicyManaged.xml در مسیر $ORACLE_HOME/assistants/rconfig/sampleXMLS وجود دارد. در روش RCONFIG اگر که یک پایگاه‌داده غیر کلاستر مبتنی بر فایل‌سیستم به کلاستر تبدیل شود، به‌صورت غیر مشهود با استفاده از ابزار rman یک پشتیبان از پایگاه‌داده تهیه می‌شود. این پشتیبان در فرآیند تبدیل به ASM مورداستفاده قرار می‌گیرد. درصورتی‌که پارامتر parallelism ابزار rman پایگاه‌داده غیر کلاستر با توجه به شرایط سخت‌افزاری افزایش یابد، فرآیند تبدیل با سرعت بیشتر انجام خواهد شد. دستور زیر مقدار این پارامتر را به ۶ افزایش می‌دهد.

RMAN> CONFIGURE DEVICE TYPE DISK PARALLELISM 6;

فرآیند تبدیل
سناریو
مفروضات این مقاله به شرح زیر می‌باشد.
• راه‌اندازی یک کلاستر ۳ نود
• نام‌گذاری نودها به‌صورت Host01, Host02, Host03
• پایگاه‌داده غیر کلاستر مبتنی بر فایل‌سیستم با نام orcl
• پوشه ORACLE_HOME مبدأ به آدرس /u01/app/oracle/product/11.2.0/dbhome_1/
• پوشه ORACLE_HOME مقصد به آدرس /u01/app/oracle/product/11.2.0/dbhome_1/

اهداف
در سناریو مفروض این مقاله دو هدف دنبال می‌شود. نخست تبدیل پایگاه‌داده غیر کلاستر به یک پایگاه‌داده کلاستر Admin-Managed بر روی نودهای Host01 و Host02 . همچنین هدف دوم مهاجرت پایگاه‌داده مبتنی بر فایل‌سیستم به ASM .
فایل‌های داده به گروه دیسک +DATA و فایل‌های Fast Recovery Area به گروه دیسک +FRA منتقل می‌شوند.

پیاده‌سازی
ابتدا یک نسخه از فایل ConvertToRAC_AdminManaged.xml در مسیر دیگری ایجاد می‌شود. بدین ترتیب نسخه اصلی فایل سالم باقی می‌ماند. سپس تغییرات زیر درون فایل جدید اعمال می‌شود.

اصلاح مقدار تگ SourceDBHome
این پارامتر محل پوشه ORACLE_HOME در پایگاه‌داده غیر کلاستر مبدأ را مشخص می‌کند.

اصلاح مقدار تگ TargetDBHome
این پارامتر محل پوشه ORACLE_HOME در پایگاه‌داده کلاستر را مشخص می‌کند. شایان‌ذکر است مقدار TargetDBHome و SourceDBHome می‌توان یکسان باشد.

اصلاح مقادیر تگ SourceDBInfo
این تگ خود شامل چند تگ دیگر در مورد اطلاعات پایگاه‌داده مبدأ است. مقدار SID ، نام کاربری و رمز عبور در این تگ مقداردهی می‌شود. لازم است کاربری تنظیم‌شده برای تبدیل، دسترسی sysdba داشته باشد.

اصلاح مقدار تگ NodeList
این پارامتر فهرست نودهایی است که در پایگاه‌داده Admin-Managed مورداستفاده قرار می‌گیرد. لازم است نام نود غیر کلاستر جاری در ابتدا فهرست قرار داده شود.

اصلاح مقدار تگ InstancePrefix
مقداردهی این پارامتر اختیاری بوده و از نگارش ۱۱.۲ افزوده شده است. درصورتی‌که این پارامتر مقداردهی نشود، مقدار db_unique_name برای آن در نظر گرفته می‌شود.

اصلاح مقدار تگ SharedStorage
این پارامتر وضعیت مدیریت ذخیره‌سازی را تعیین می‌کند. این پارامتر مقادیر ASM و CFS را پشتیبانی می‌کند.

اصلاح مقدار تگ TargetDatabaseArea
این پارامتر محل ذخیره‌سازی فایل‌های داده را مشخص می‌کند. برای این پارامتر مقدار +DATA در نظر گرفته می‌شود.

اصلاح مقدار تگ TargetFlashRecoveryArea
این پارامتر محل ذخیره‌سازی فایل‌های FRA را مشخص می‌کند. برای این پارامتر گروه دیسک +FRA در نظر گرفته شده است.
پس از انجام اصلاحات فوق، دستور rconfig اجرا و فایل ConvertToRAC_AdminManaged.xml به آن ارجاع داده می‌شود.

rconfig /tmp/ConvertToRAC_AdminManaged.xml

فایل‌های لاگ در مسیر $ORACLE_BASE/cfgtoollogs/rconfig/ برای بررسی وضعیت فرآیند تبدیل در حین اجرای دستور rconfig استفاده می‌شود. پس از اتمام فرآیند تبدیل، با استفاده از دستور زیر وضعیت پایگاه‌داده کلاستر بررسی می‌شود.

srvctl status database -d orcl

فایل پسوردها به‌صورت خودکار در کلی نودها نوشته می‌شود؛ اما فایل tnsnames.ora باید به‌صورت دستی در کلیه نودها ایجاد شود. برای این کار می‌توان فایل tnsnames.ora را با استفاده از ابزار netmgr در سرور مبدأ ایجاد و سپس در سایر سرورها کپی نمود.
پس از ایجاد فایل tnsnames.ora با استفاده از نام مستعار سرویس ارتباط کلاینت‌ها با سرویس آزمایش می‌شود. در انتها با استفاده از دستور زیر می‌توان صحت مدیریت فایل‌های داده توسط ASM را بررسی کرد.

select name from v$datafile;

0 پاسخ

دیدگاه خود را ثبت کنید

تمایل دارید در گفتگوها شرکت کنید؟
در گفتگو ها شرکت کنید.

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *