نکته ای در مورد بکاپ گیری از استندبای

نویسنده مطلب: وحید یوسف زاده Leave a comment

همانطور که می دانید، در زمان بکاپ گیری با ابزار RMAN، می توان از physical standby به جای دیتابیس primary استفاده کرد تا از این جهت بار اضافه ای به primary تحمیل نشود.

با توجه به آنکه ساختار این دو محیط(primary و physical standby) مشابه هم هستند، بکاپ گیری در این دو محیط تفاوت چندانی ندارد(دیتافایلها در این دومحیط بلاک به بلاک با هم مطابقت دارند البته به شرط sync بودن استندبای)

و اندک تفاوت ایجاد شده، به open mode این دو دیتابیس برمی گردد و این تفاوت، حداقل در زمان بکاپ گیری از archive log خودش را نشان می دهد چرا که اوراکل در زمان بکاپ گیری از آرشیولاگ، log switchی را اجرا خواهد کرد و بدیهی است که این log switch در محیط physical standby قابل اجرا نخواهد بود.

دستور زیر در محیط physical standby اجرا شده است پیام RMAN-06820 در خروجی این دستور، گواهی بر نکات ذکر شده، می باشد.

rman target /
RMAN>  backup archivelog all  format '/bkp/%U';
Starting backup at 12-AUG-21
using target database control file instead of recovery catalog
'RMAN-06820: warning: failed to archive current log at primary database'
cannot connect to remote database
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=1321 device type=DISK
channel ORA_DISK_1: starting archived log backup set
channel ORA_DISK_1: specifying archived log(s) in backup set
input archived log thread=1 sequence=179829 RECID=83713 STAMP=1080395727
input archived log thread=1 sequence=179830 RECID=83714 STAMP=1080395729
channel ORA_DISK_1: starting piece 1 at 12-AUG-21
channel ORA_DISK_1: finished piece 1 at 12-AUG-21
piece handle=/bkp/iv06b2l4_1_1 tag=TAG20210812T140732 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
Finished backup at 12-AUG-21

برای جلوگیری از این مسئله باید در هنگام اتصال به physical standby، پسورد کاربر sys را هم وارد کنیم که در این صورت، log switch در بانک اصلی انجام خواهد شد:

rman target sys/sys
RMAN> backup archivelog all  format '/bkp/%U';
Starting backup at 12-AUG-21
using target database control file instead of recovery catalog
'current log archived at primary database'
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=1321 device type=DISK
channel ORA_DISK_1: starting archived log backup set
channel ORA_DISK_1: specifying archived log(s) in backup set
input archived log thread=1 sequence=179829 RECID=83713 STAMP=1080395727
input archived log thread=1 sequence=179830 RECID=83714 STAMP=1080395729
input archived log thread=1 sequence=179831 RECID=83715 STAMP=1080396540
channel ORA_DISK_1: starting piece 1 at 12-AUG-21
channel ORA_DISK_1: finished piece 1 at 12-AUG-21
piece handle=/bkp/j106b2nv_1_1 tag=TAG20210812T140903 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:03
Finished backup at 12-AUG-21

در alert log محیط primary اطلاعات این log switch قابل مشاهده است:

2021-08-12T14:13:40.047070+04:30
ALTER SYSTEM ARCHIVE LOG
2021-08-12T14:13:40.066804+04:30
Thread 1 advanced to log sequence 179832 (LGWR switch)
  Current log# 3 seq# 179832 mem# 0: /oradata/DBORG/onlinelog/o1_mf_3_j4675ghj_.log
  Current log# 3 seq# 179832 mem# 1: /fra/DBORG/onlinelog/o1_mf_3_j4675jwx_.log
2021-08-12T14:13:40.285117+04:30
TT02 (PID:27803): SRL selected for T-1.S-179832 for LAD:2
2021-08-12T14:13:40.508384+04:30
NET  (PID:39106): Archived Log entry 362234 added for T-1.S-179831 ID 0x46023b59 LAD:1

 

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

نویسنده مطلب: وحید یوسف زاده Leave a comment

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 – قابلیت PDB Recovery Isolation

نویسنده مطلب: وحید یوسف زاده Leave a comment

در اوراکل نسخه 19c، دیتاگارد نمی تواند عملیاتی نظیر hot cloning و point-in-time recovery را در سطح PDB مدیریت کند و در صورت انجام این قبیل عملیات در primary، دیتاگارد بدون آنکه از حالت recover خارج شود، از آن PDB صرف نظر کرده و با نادیده گرفتن PDB، به کارش ادامه خواهد داد.

–Data Guard 19c

SQL> select OPEN_MODE from v$database;

OPEN_MODE

——————–

READ ONLY WITH APPLY

SQL> show pdbs

    CON_ID CON_NAME                       OPEN MODE  RESTRICTED

———- —————————— ———- ———-

         2 PDB$SEED                       READ ONLY  NO

         3 PDB1                           READ ONLY  NO

–Primary 19c

SQL> create pluggable database pdb2  from pdb1;

Pluggable database created.

SQL> alter pluggable database pdb2 open;

Pluggable database altered.

SQL> show pdbs

    CON_ID CON_NAME                       OPEN MODE  RESTRICTED

———- —————————— ———- ———-

         2 PDB$SEED                       READ ONLY  NO

         3 PDB1                           READ WRITE NO

         5 PDB2                           READ WRITE NO

–Data Guard 19c

SQL> select OPEN_MODE from v$database;

OPEN_MODE

——————–

READ ONLY WITH APPLY

SQL> alter pluggable database pdb2 open;

ORA-01111: name for data file 13 is unknown – rename to correct file

SQL> select name,status from v$datafile;

NAME                                STATUS

———————————– ——-

/oracle19c/home/dbs/UNNAMED00013    SYSOFF

/oracle19c/home/dbs/UNNAMED00014    RECOVER

/oracle19c/home/dbs/UNNAMED00015    RECOVER

/oracle19c/home/dbs/UNNAMED00016    RECOVER

(بیشتر…)

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

نویسنده مطلب: وحید یوسف زاده Leave a comment

یکی دیگر از قابلیتهای جدید اوراکل در نسخه 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

(بیشتر…)

اوراکل 21c – آماده سازی مقدمات راه اندازی دیتاگارد با Broker

نویسنده مطلب: وحید یوسف زاده Leave a comment

در اوراکل 21c می توان با کمک Data Guard Broker محیط دیتابیس primary را برای راه اندازی Data Gaurd آماده کرد. قرار دادن دیتابیس در مود archivelog، فعال کردن force logging، تنظیم پارامترها، ایجاد Standby Redo Log و … صرفا با اجرای یک دستور در محیط Broker انجام می شود. این دستور PREPARE DATABASE FOR DATA GUARD است که در قسمت زیر نحوه اجرای آن را به همراه عملیاتی که انجام می دهد، مشاهده می کنید:

DGMGRL> PREPARE DATABASE FOR DATA GUARD WITH DB_UNIQUE_NAME IS db21c

DB_RECOVERY_FILE_DEST_SIZE is “550G”

DB_RECOVERY_FILE_DEST is “/oracle21c/FRA”;

(بیشتر…)

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

نویسنده مطلب: وحید یوسف زاده Leave a comment

تا قبل از نسخه 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

نویسنده مطلب: وحید یوسف زاده Leave a comment

در این متن به ویژگی های جدید 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 و محیط دیتاگارد

نویسنده مطلب: وحید یوسف زاده Leave a comment

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

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

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

(بیشتر…)

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

نویسنده مطلب: وحید یوسف زاده 2 Comments

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

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

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

(بیشتر…)

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

نویسنده مطلب: وحید یوسف زاده 2 Comments

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

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

(بیشتر…)