ویژگی Multi Instance Redo Apply

در اوراکل 11g با پیاده سازی دیتاگارد به صورت کلاستر، تنها نودی که دستور alter database manage recover بر روی ان اجرا شده(برای اولین بار!)، مسئولیت اعمال کردن redoها را برعهده خواهد داشت و مابقی نودها می توانند برای گزارش گیری، تهیه بکاپ و یا دریافت redo (یا آرشیو) و… مورد استفاده قرار بگیرند.

در اوراکل 12cR2، بهبودی در این زمینه رخ داد که می توان با کمک آن، همه نودها را در recovery سهیم کرد. این قابلیت که (Multi Instance Redo Apply (MIRA نام دارد، امکان اعمال redoها را با کمک چند instance ممکن می سازد.

(بیشتر…)

ریکاوری استندبای تا یک تاریخ یا scn مشخص

برای ریکاوری استندبای(با این فرض که استندبای عقب یا در حالت delay قرار دارد) تا یک تاریخ یا scn، مشخص می توان از دستور زیر استفاده کرد:

SQL> ALTER DATABASE RECOVER automatic standby database until time ‘2017-05-15 06:15:47’;

Database altered.

در این صورت با رسیدن ریکاوری به زمان تعیین شده، پیامی مشابه با پیام زیر، در alert log قابل مشاهده خواهد بود:

Incomplete Recovery applied until change 41254778 time 05/15/2017 06:15:47

Media Recovery Complete (DBSTEST)

Completed: ALTER DATABASE RECOVER automatic standby database until time ‘2017-05-15 06:15:47’

چالشهای دیتاگارد در محیط Multitenant

پرسش: در محیط Multitenant، با ایجاد یک pdb جدید، چه اتفاقی برای دیتاگارد رخ خواهد داد؟ آیا دیتاگارد از حالت ریکاور خارج خواهد شد؟ چگونه میتوان در زمان انجام عملیات pdb cloning  و یا remote hot clone ، دیتاگارد را در حالت همسان با بانک اصلی نگه داشت؟ و …

در این متن قصد داریم تا به این دسته از سوالات پاسخ دهیم و شیوه های مختلف ایجاد یک pdb و همچنین نحوه اثر گذاری ان را بر روی دیتاگارد، مورد بررسی قرار دهیم.

(بیشتر…)

رفع گپ استندبای در اوراکل 18c

برطرف کردن گپ استندبای از اوراکل 10g با کمک incremental backup قابل انجام است البته به صورت کاملا دستی! انجام این کار نیازمند تعیین شماره scn، تهیه بکاپ از بانک اصلی(بصورت incremental)، ارسال فایل به سرور استندبای و …. بود از اوراکل 12cR1، بهبودهایی در این زمینه صورت پذیرفت و قسمتی از این عملیات به صورت خودکار قابل انجام است ولی کماکان نیاز بود با طی چند مرحله این کار انجام شود:

(بیشتر…)

اجرای exp/expdp در محیط data guard

برای تهیه دامپ در محیط data guard، می توان از ابزار Exp بصورت مستقیم و از ابزار Expdp به صورت غیرمستقیم(با کمک database link) استفاده کرد همچنین با تبدیل data guard به snapshot standby، هم می توان مجددا از ابزار Expdp به صورت مستقیم بهره گرفت.

در ادامه به بررسی این سه روش خواهیم پرداخت.

(بیشتر…)

افزودن دیتافایل UNNAMED00nnn به data guard

در صورتی که پارامتر standby_file_management در محیط data guard به مقدار manual تنظیم شده باشد، با افزودن دیتافایل جدید در بانک اصلی(primary)، data guard با خطای ORA-01110 متوقف خواهد شد. برای رفع این خطا، می توان این دیتافایل را به صورت دستی در data guard ایجاد کرد. مثال زیر ببینید.

(بیشتر…)

پارامتر redo_transport_user

در اوراکل 11g با تغییر پسورد sys باید مجددا پسوردفایل به محیط data guard منتقل شود(برخلاف نسخه 12c). حال اگر یکی از برنامه های دوره ای تیم امنیت، تغییر پسورد کاربر sys باشد، این مسئله می تواند برای پشتیبان بانک ایجاد مزاحمت کند همچنین در صورت انتقال اطلاعات با دسترسی sysdba، به لحاظ امنیتی هم شاید بستر نفوذی بین این دو سرور ایجاد باشد.

(بیشتر…)

بازیابی دیتافایل بانک اصلی از استندبای

در صورت از دست دادن سیستم عاملی یک دیتافایل در محیط بانک اصلی، با دیتافایل موجود در سرور دیتاگارد، این فقدان قابل جبران است(البته بشرط سازگاری).

برای انجام این کار در نسخه های ماقبل 12c، نیاز بود تا dba به صورت دستی و در سطح سیستم عامل این دیتافایل را از محیط دیتاگارد به بانک اصلی انتقال دهد.

این کار در نسخه 12c، تنها با استفاده از یک دستور در محیط RMAN، قابل انجام می باشد:

(بیشتر…)