انتقال خودکار Restore Point از primary به standby

تا قبل از نسخه 19c، ایجاد restore point در محیط primary، منجر به ایجاد آن در محیط standby نمی شد. در سناریوی زیر که در اوراکل نسخه 18cR3 اجرا شده است این مسئله را می بینید:

Oracle Database 18c Enterprise Edition Release 18.0.0.0.0 – Production

Version 18.3.0.0.0

–Primary

SQL> select * from v$restore_point;

no rows selected

–Standby

SQL> select * from v$restore_point;

no rows selected

–Primary

SQL> create restore point before_upg;

Restore point created.

SQL>  select NAME,SCN from v$restore_point;

NAME                   SCN

———-                 —————

BEFORE_UPG    870272395791

SQL> alter system switch logfile;

System altered.

–Standby

SQL> select NAME,SCN from v$restore_point;

no rows selected

(بیشتر…)

مروری بر ویژگی های جدید DG Broker در اوراکل 19c

در این متن به ویژگی های جدید Data Guard Broker که در اوراکل نسخه 19c اضافه شده اند، خواهیم پرداخت.

Export و Import از پیکربندی DG Broker

در نسخه 19c می توان از فایل پیکربندی DG Broker دامپی را در قالب فایل متنی ایجاد کرد و در صورت نیاز، اقدام به بازسای فایل پیکربندی DG Broker کرد.

دستور زیر broker configuration را در فایل متنی mybrokerfile.txt قرار خواهد داد:

[oracle@RAC1 ~]$ dgmgrl sys/sys@tehran

DGMGRL for Linux: Release 19.0.0.0.0 – Production on Thu Oct 22 13:15:42 2020

Version 19.6.0.0.0

Copyright (c) 1982, 2019, Oracle and/or its affiliates.  All rights reserved.

Welcome to DGMGRL, type “help” for information.

Connected to “orcl”

Connected as SYSDBA.

DGMGRL>  EXPORT CONFIGURATION TO ‘mybrokerfile.txt’;

Succeeded.

(بیشتر…)

استفاده از Unified auditing در حالت read only و محیط دیتاگارد

همانطور که می دانید، زمانی که دیتابیس در حالت read only قرار دارد امکان ثبت اطلاعات در جداول دیتادیکشنری از بین خواهد رفت این قاعده برای جداول مربوط به auditing(نظیر aud$unified) هم صادق است از اینرو نمی توان عملیات انجام شده توسط کاربران را در دیتابیس ذخیره کرد.

در این شرایط، در صورت استفاده از قابلیت Unified auditing، اوراکل auditهای انجام شده را در محیط سیستم عامل ثبت خواهد کرد.

عملیات انجام شده توسط کاربران در قالب فایلهای باینری، با پسوند bin. و در مسیر ORACLE_BASE/audit/$ORACLE_SID$ ثبت خواهند شد و امکان مشاهده محتویات این فایلهای باینری از طریق ویوی unified_audit_trail فراهم می شود.

(بیشتر…)

تاثیر عملیات 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 ممکن می سازد.

(بیشتر…)