artarad_rman_backup

جابجا کردن دیتافایل های پایگاه داده با حجم ۳TB با قطعی کمتر از ۲ دقیقه

جابجا کردن دیتافایل های پایگاه داده با حجم ۳TB با قطعی کمتر از ۲ دقیقه

این مسئله در واقع سوال بسیاری از افراد است که چگونه میتوان در حداقل زمان ممکن برای Downtime داده ها را بین دیسک های ذخیره سازی جابجا نماییم؟


البته این پرسش بسیار جالب است. در زمانی که قصد جابجایی یک پایگاه داده را داریم به منظور حفظ ثبات داده ها نیاز است تا عملیات جابجایی را در زمانی انجام دهیم که تمامی فایل ها بسته و پایگاه داده در وضعیت Down قرار گرفته باشد. این فرآیند می تواند به صورت Tablespace به Tablespace انجام شود یا به صورت کلی با تمام پایگاه داده که البته بستگی به میزان حجم داده های پایگاه داده ای دارد که باید منتقل شوند. در هر صورت این مسئله در اوراکل نسخه ۱۲C به دلیل پیش بینی انتقال Online برطرف شده است.
در مثالی که مورد بحث قرار خواهد گرفت یک پایگاه داده به حجم ۳TB در نظر گرفته شده است که اکثر حجم آن در یک Tablespace قرار دارد و مدت زمان Downtime اعلام شده بین ۵ الی ۷ دقیقه است پس واضح است که امکان Down نمودن پایگاه داده و یا Offline بودن Tablespace ها وجود نخواهد داشت و به راهکار دیگری نیاز است.

استفاده از Data Guard
اولین راهکاری که به ذهن می رسد ایجاد یک پایگاه داده ثانویه در Data Guard است. اضافه نمودن یک Physical Standby و انتقال پایگاه داده به آن است بدین ترتیب امکان ادامه کار Application در ضمن عملیات جابجایی وجود دارد.
از آنجایی که این پایگاه داده تا حدودی حجیم است ایجاد Data Guard نیاز به یک فضای ۳TB دیگر علاوه بر ۳TB که هم اکنون استفاده شده و ۳TB که داده ها باید به آنجا منتقل شوند دارد و مسئله دیگر آنکه در این روش نیاز به یک Server ثانویه با منابع کافی (RAM و CPU) و همچنین یک Application به منظور برقراری اتصال و مدیریت آن در این Server موقتی وجود دارد.
راهکار دیگر در بحث Data Guard راه اندازی یک پایگاه داده ثانویه در همان Server سابق برابر همان پایگاه داده اولیه و Switch نمودن به آن است. البته این امر نیازمند تعویض Database Name است که البته در اکثر مواقع مشکل خاصی به وجود نمی آورد.
جلسه ای در خصوص این راهکار و نحوه راه اندازی آن و پارامترهای مورد نیاز با کارفرما انجام می شود ولی درخواست ارائه راهکاری با همین میزان Downtime ولی با تغییرات پیکربندی به مراتب کمتر از جانب کارفرما مطرح می شود.
• باید به این نکته اشاره کرد که راهکار گلدن گیت در این زمینه هم بسیار کارا می باشد.

استفاده از RMAN Backup
باید مسئله را به بخش های کوچکتری تقسیم نماییم. کاری که باید انجام شود انتقال فایل ها به محل ذخیره سازی جدید و شناسایی Disk جدید به عنوان جایگزین Disk قدیمی است. به منظور انجام این عملیات باید از Data File ها نسخه ثانویه تهیه شود و در عین حال نمی توان به منظور انتقال فایل ها پایگاه داده را متوقف نمود و این عملیات انتقال می تواند تا حدود ۲۰ ساعت به طول انجامد که در این مدت Application داده های بیشتری را تولید نموده است.
راهکار این مسئله بسیار ساده است به این صورت که می توان یک Image Copy Full Backup در مسیر جدید قرار داد و در زمان Downtime به آن Switch نمود. البته اگر مسئله نیاز به اعمال تغییرات صورت گرفته در حین عملیات انتقال پایگاه داده به معادله اضافه شود به نظر می آید بهترین راهکار استفاده از Merge Incremental Backup است.

آشنایی با Merge Incremental Backup
Merge Incremental Backup یکی از بهترین راهکارهای پشتیبان گیری از پایگاه داده های Very Large Databases است و بسیار سریع می تواند آن را Recovery نماید. (بدون استفاده از Backup های خارجی)
این فرآیند دارای ایده ساده ای است: یک مجموعه ثانویه از DataFile ها همیشه برای استفاده Instance آماده باشد و به طور روزانه یا هر بازه زمانی که در نظر دارید با تهیه Incremental Backup از تغییرات ایجاد شده آن ها را به مجموعه خود اعمال نمایید.
در صورت بروز مشکل در مجموعه اول DataFile ها می توان تنها با قرار دادن Instance بر روی مجموعه دوم و اعمال آخرین تغییرات پایگاه داده را برای استفاده کاربران مهیا نمود.
اجرای این فرآیند در صورت درک منطق حاکم و شیوه بازیابی آن بسیار آسان خواهد بود.

استفاده از Merge Incremental به منظور جابجایی فایل ها
در این شرایط می خواهیم ساختار دایرکتوری اصلی و همچنین DB Filename ثابت نگاه داشته شوند و در مسیر دیگری نیز بازسازی گردد.
با استفاده از محل ذخیره سازی جدید ساختار دایرکتوری ایجاد می شود و ادامه عملیات در مرحله بعدی انتقال DataFile ها خواهد بود. در حالی که در شیوه اصلی پیاده سازی این راهکار بر چگونگی تهیه اولین مجموعه Image Copy ها کنترلی وجود ندارد در عملیات جاری به وسیله دستور BACKUP INCREMENTAL LEVEL 1 موجود در اسکریپت فرآیند این عمل صورت می گیرد.

۱ Run {

۲ ALLOCATE CHANNEL T1 DEVICE TYPE DISK;

۳ ALLOCATE CHANNEL T2 DEVICE TYPE DISK;

۴ ALLOCATE CHANNEL T3 DEVICE TYPE DISK;

۵ ALLOCATE CHANNEL T4 DEVICE TYPE DISK;

۶ BACKUP incremental level 0 AS COPY

۷ tag=’incr_update’

۸ DB_FILE_NAME_CONVERT = (‘oranfs’,’oranfs_new’)

۹ database;

۱۰ }

در کدهای فوق برای تهیه یکLevel 0 Incremental Backup as Copy Images تعداد ۴ کانال به منظور انتقال فایل ها در نظر گرفته شده است (البته تنها در نسخه Enterprise قابل اجرا خواهد بود) همچنین از DB_FILE_NAME_CONVER برای انتقال داده ها از مسیر /oranfs/ به /oranfs_new/ به همراه نام فایل اصلی استفاده می شود. به دلیل وجود تمام فایل ها در یک مسیر مشخص این راهکار ساده ترین روش ممکن خواهد بود. آخرین مرحله نیز الحاق یک برچسب به ‍پشتیبان تهیه شده است که در اینجا برابر “incr_update” قرار می گیرد.
مرحله دوم پس از اتمام Online Copy مقدماتی شروع می شود. در این مرحله نیاز به اخذ تمامی تغییرات انجام شده از زمان شروع فرآیند انتقال و ادغام آن ها در Image Copy است.

۱ RUN {

۲ ALLOCATE CHANNEL T1 DEVICE TYPE DISK;

۳ ALLOCATE CHANNEL T2 DEVICE TYPE DISK;

۴ ALLOCATE CHANNEL T3 DEVICE TYPE DISK;

۵ ALLOCATE CHANNEL T4 DEVICE TYPE DISK;

۶ BACKUP INCREMENTAL LEVEL 1 FOR RECOVER OF COPY WITH TAG ‘incr_update’ DATABASE;

۷ RECOVER COPY OF DATABASE WITH TAG ‘incr_update’;

۸ sql “ALTER SYSTEM ARCHIVE LOG CURRENT”;

۹ DELETE NOPROMPT OBSOLETE;

۱۰ BACKUP CURRENT CONTROLFILE;

۱۱ }

تشریح فرآیند:
۱. در ابتدا به منظور ایجاد کارایی بالاتر ۴ کانال در اختیار گرفته می شود.
۲. تهیه یک نسخه Incremental Backup (Level 1) جهت بازیابی کپی به همراه برچسب در نظر گرفته شده. کپی مورد نظر در اینجا بر مبنای خود Image Copy ها تهیه می شود.
۳. پس از اتمام پشتیبان گیری Image Copy به کمک Incremental Backup اخیر Recovery می شود.
۴. Log File برای پاک کردن Archive Log ها Switch می شود.
۵. آرشیو Backup ها و Archive Log های قدیمی پاک می شوند.
۶. از Control File ها پشتیبان تهیه می شود. (از آنجایی که برای Recovery مورد استفاده قرار می گیرد)
این بخش از فرآیند می تواند به منظور نزدیک شدن به فایل های حقیقی در زمان Switch به دفعات تکرار شود. البته به دلیل آنکه پایگاه داده بزرگی داریم این مرحله می تواند بسیار زمانبر باشد.

بهبود کارایی
به جهت بهبود سرعت Incremental Backup می توان Block Change Tracking را فعال نمود. این عمل با ایجاد یک فایل جدید در خارج از پایگاه داده که در آن بلاک های تغییر یافته از زمان آخرین عملیات پشتیبان گیری نگهداری می شود. در این صورت عملیات Incremental Backup بسیار آسان تر صورت می گیرد. به این منظور قابلیت زیر فعال می شود.

alter database enable block change tracking using file ?/dbs/prod_cbt.dbf

Switch نمودن فایل ها
هدف مرحله بعد اخذ کمترین میزان Downtime از پایگاه داده است. در این مرحله پایگاه داده متوقف شده و Mount Point با Switch به جایگاه جدید دوباره Mount می شود. از آنجایی که Control File هایمان در محل دیگری قرار دارد بنابراین Redo Log ها و Data File هایمان Switch شده اند. حال از آنجایی که SCN در Control File ها شماره بالاتری نسبت به فایل های Image Copy دارند بنابراین نیاز به Data File Recovery است و این فرآیند به دلیل وجود Archive Log ها و Redo Log های اصلی به سادگی انجام می شود.
در حالت Mount پایگاه داده Start می شود.

Recover database

هنگامی که عملیات Recovery انجام شود پایگاه داده قابل بهره برداری خواهد بود.

نکات قابل توجه:
۱. در این روش تنها Data File ها (شامل UNDO) منتقل می شوند و Temp File های از دست رفته به صورت خودکار ایجاد می شوند.
۲. قبل از Start پایگاه داده مطمئن شوید که تمام Control File ها در محل خود قرار دارند و در صورت نیاز آن ها را به آنجا منتقل کنید.
۳. اگر Redo Log ها همراه با Data File ها قرار دارند به دلیل آنکه دارای اطلاعات مورد نیاز جهت بازیابی آخرین SCN در Control File هستند باید به محل جدید منتقل شوند.
۴. تا زمانی که در خطر از دست دادن برخی از داده ها نیستید Reset Log پایگاه داده را باز نکنید.
۵. در زمان اجرای دستورات RMAN قبل از گرفتن زمان از RMAN از دستور Export زیر استفاده کنید.

“export NLS_DATE_FORMAT=”dd-mm-yyyy hh24:mi:ss

۶. از بین بردن فابل های قدیمی فراموش نشود.

جمع بندی
با این روش می توان یک پایگاه داده ۳TB را با صرف کمترین زمان Downtime و در کمتر از ۲ دقیقه جابجا نمود. (البته بیشتر این زمان صرف Shut Down نمودن پایگاه داده می شود.)
البته راهکارهای دیگری متناسب با محیط های عملیاتی متفاوت نیز وجود دارد.

0 پاسخ

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

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

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

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