اوراکل 21.7 – راه اندازی دیتاگارد در سطح PDB(قابلیت DGPDB)

DGPDB(یا همان Data Guard per Pluggable Database) قابلیت جدیدی است که در نسخه 21.7 اوراکل ارائه شده و قرار است با کمک این قابلیت، در سطح PDB، دیتاگارد راه اندازی کنیم.

 در معماری قدیمی(قبل از ارائه DGPDB)، یکی از CDBها(به انضمام همه PDBها) در نقش primary قرار داشت و CDB دیگر نقش standby را ایفا می کرد و راه اندازی دیتاگارد برای یک PDB منوط به راه اندازی دیتاگارد برای CDB$ROOT بود و دیتاگارد هم نمی توانست container اضافه ای را داشته باشد به عبارتی دیگر، Guard عینا مشابه primary و یا در صورت مستثنا کردن بعضی از PDBها(enabled_PDBs_on_standby)، دیتاگارد زیر مجموعه ای از primary بود.

اما DGPDB این محدودیتها را برداشت معماری این قابلیت که شباهتهایی هم با قابلیت PDB switchover دارد(قابلیت switchover  در نسخه 18c ارائه شده بود)، به این صورت است که:

1.هر دو CDB در نقش primary و در حالت read write قرار دارند و برخلاف معماری سنتی، CDB$ROOT بین این دو دیتابیس یکسان نیست و هر CDBء PDBهای مختص به خود را دارند.

2.نقش standby و primary در سطح PDB قابل تنظیم است مثلا برای PDB حاضر در CDB1 می توانیم در CDB2 گارد ایجاد کنیم و به همین شکل می توانیم در CDB1 برای PDBهای حاضر در CDB2 دیتاگارد راه اندازی کنیم.

3.تغییر چندانی در پروسه ارسال و دریافت redoها در طرفین ایجاد نشده و پروسه TTnn در معماری DGPDB نقش کلیدی را ایفا می کند.

(بیشتر…)

اوراکل 21c- استفاده از Result Cache در استندبای

یکی دیگر از قابلیتهای جدید اوراکل در نسخه 21c، امکان استفاده از هینت RESULT_CACHE در محیط Physical Standby است که در ادامه نحوه استفاده از ان توضیح داده شده است.

***مدت زمان اجرای پرس و جوی زیر، در دیتابیس primary حدودا یک دقیقه است:

–primary:

SQL> select count(*) from usef.tbl1;

  COUNT(*)

———-

  62775296

Elapsed: 00:01:06.45

SQL> /

  COUNT(*)

———-

  62775296

Elapsed: 00:01:03.61

با استفاده از هینت result_cache این زمان به زیر یک ثانیه کاهش پیدا می کند!

–primary:

SQL> select /*+ result_cache */  count(*) from usef.tbl1;

  COUNT(*)

———-

  62775296

Elapsed: 00:01:20.74

SQL> select /*+ result_cache */  count(*) from usef.tbl1;

  COUNT(*)

———-

  62775296

Elapsed: 00:00:00.00

(بیشتر…)

انتقال خودکار 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.

(بیشتر…)

تاثیر عملیات 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 هم فراهم شده است.

(بیشتر…)