یکی از مراحل پیکربندی دیتاگارد، قراردادن دیتابیس در حالت force logging می باشد این کار سبب خواهد شد تا کاربران امکان اجرای عملیات را به صورت Nologging نداشته باشند و در نتیجه، همه اطلاعاتی که در دیتابیس اصلی درج می شود، به دیتاگارد هم منتقل خواهد شد.

با در نظر داشتن این مسئله، اگر دیتابیس اصلی در حالت force logging قرار نگیرد، تکلیف عملیات Nologging در دیتاگارد چه خواهد شد و برای رفع بلاکهای خراب یا اصطلاحا nonlogged چه عملیاتی را باید در دیتاگارد انجام داد؟

پاسخ به این سوال، در نسخه های مختلف اوراکل، متفاوت خواهد بود که در ادامه، به بررسی این مسئله در نسخه های 11g، 12c و 18c خواهیم پرداخت.

تا قبل از اوراکل نسخه 18c، انجام عملیات DMLای در محیط (Active Data Guard(ADG، صرفا برای جداول از نوع global temporary table قابل انجام بود و هرگونه اجرای دستور DMLای بر روی جداول سیستمی و applicationای، جز در حالت snapshot standby، امکان پذیر نبود.

در اوراکل 18c، با ارائه دو پارامتر مخفی به نامهای enable_proxy_adg_redirect_ و ADG_REDIRECT_FLAGS_، امکان اجرای دستورات DMLای در محیط دیتاگارد فراهم شد. مثال زیر را ببینید.

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

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

(بیشتر…)

(بیشتر…)