تاثیر عملیات NOLOGGING در دیتاگارد(اوراکل 11g و 12c و 18c)

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

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

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

(بیشتر…)

اجرای دستورات DMLای در محیط دیتاگارد(اوراکل 19c و 18c)

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

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

(بیشتر…)

نقش و اولویت پارامتر db_create_file_dest در دیتاگارد

با اجرای دستور زیر، دیتافایلی را در مسیر oracle/ ایجاد می کنیم:

 SQL> create tablespace mytbs datafile ‘/oracle/mytbs01.dbf’ size 1m;

Tablespace created.

در محیط دیتاگارد، خبری از مسیر oracle/ نیست! سرنوشت این دیتافایل در این محیط چه خواهد شد؟

(بیشتر…)

Auditing در محیط Active Data Guard

در زمان استفاده از Active Data Gaurd، ممکن است نیاز باشد تا نظارتی بر روی دسترسی کاربران به جداول صورت پذیرد. با توجه به read only بودن ADG، طبیعی است که امکان استفاده از $aud برای ثبت auditing امکان پذیر نخواهد بود و تنظیم پارامتر audit_trail به مقدار DB نمی تواند در این محیط موثر باشد.

(بیشتر…)

انجام duplicate با کمک Data Guard

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

(بیشتر…)

تهیه گزارش AWR در محیط ADG

همانطور که می دانید؛ ایجاد گزارش awr در محیط ADG به صورت روتین امکان پذیر نمی باشد این اتفاق به دلیل عدم امکان ایجاد snapshot بر روی بانکی که در حالت read only قرار دارد، کاملا منطقی بنظر می رسد. در اوراکل 12cR2، راهکاری برای این مسئله اندیشیده شد و امکان تهیه این گزارش برای ADG هم فراهم شده است.

(بیشتر…)

ویژگی 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 و همچنین نحوه اثر گذاری ان را بر روی دیتاگارد، مورد بررسی قرار دهیم.

(بیشتر…)