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

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

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

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

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

برای مشاهده حالت دیتابیس به لحاظ force logging، باید مقدار ستون force_logging از ویوی v$database را مشاهده کرد:

SQL> select force_logging from v$database;

FORCE_LOGGING

—————————————

NO

همانطور که می بینید، دیتابیس در حالت force logging قرار ندارد با دستور زیر، خصیصه force logging را برای دیتابیس فعال می کنیم:

SQL> alter database force logging;

Database altered.

شیوه فعال سازی force logging در سطح tablespace هم با اجرای دستور زیر قابل انجام خواهد بود برای مثال، با دستور زیر، این خصیصه برای tablespace users فعال خواهد شد:

SQL> alter tablespace mytbs force logging;

Tablespace altered.

SQL> select tablespace_name,force_logging from dba_tablespaces where TABLESPACE_NAME=’MYTBS’;

TABLESPACE_NAME                FOR

—————————— —

MYTBS                          YES

با فعالسازی خصیصه force logging در سطح دیتابیس، فعال یا غیرفعال سازی آن در سطح tablespace، بی معنی خواهد بود پس در نتیجه، برای اعمال این تنظیمات در سطح tablespace، در ابتدا باید force logging را در سطح دیتابیس غیرفعال کرد.

هدف اصلی متن پیش رو، بررسی حالتی است که database و tablespace هر دو در حالت no force logging قرار دارند در این حالت، تکلیف عملیات nologging در محیط دیتاگارد چه خواهد شد؟ در ادامه سعی داریم به این سوال پاسخ دهیم.

در این قسمت، با انجام عملیات nologging در اوراکل نسخه 11g، دو شیوه از تعمیر بلاکهای nonlogged را در محیط دیتاگارد مورد بررسی قرار خواهیم داد.

–PRIMARY

sqlplus “/as sysdba”

SQL*Plus: Release 11.2.0.4.0 Production on Sat Apr 20 09:49:27 2019

Copyright (c) 1982, 2013, Oracle.  All rights reserved.

Coected to:

SQL> select force_logging from v$database;

FOR

—

NO

SQL> alter tablespace mytbs no force logging;

Tablespace altered.

SQL> select tablespace_name,force_logging from dba_tablespaces where TABLESPACE_NAME=’MYTBS’;

TABLESPACE_NAME                FOR

—————————— —

MYTBS                          NO

با اطمینان از no force logging قرار داشتن database و tablespace، جدولی را بصورت nologging در mytbs ایجاد می کنیم:

— PRIMARY

SQL> create table mytbl tablespace mytbs nologging as select * from dual;

Table created.

بعد از ایجاد جدول به صورت nologging، پرس و جوی زیر را در دیتاگارد اجرا می کنیم:

–Data Guard:

SQL> select * from mytbl;

ORA-01578: ORACLE data block corrupted (file # 6, block # 131)

ORA-01110: data file 6:

‘/u01/oracle/oradata/HRMSTB/datafile/o1_mf_mytbs_gb8m80ng_.dbf’

ORA-26040: Data block was loaded using the NOLOGGING option

با اجرای این پرس و جو، خطایی مبنی بر خرابی بلاک 131 از دیتافایل شماره 6 به کاربر برمی گردد همچنین این خطا، در alert log هم قابل مشاهده است.

راه حل اول: برای حل این مشکل در محیط دیتاگارد(اوراکل نسخه 10g و 11g)، راه حلهای مختلفی وجود دارد، یکی از این راه حلها، ارسال مجدد دیتافایل به محیط دیتاگارد می باشد.

— PRIMARY

SQL> alter tablespace mytbs begin backup;

Tablespace altered.

[root@prim_host ~]# scp /u01/oracle/oradata/HRMDB/datafile/o1_mf_mytbs_gb8k8lcv_.dbf stb_host:/u01/oracle/oradata/HRMSTB/datafile/

–Data Guard:

SQL>  alter database rename file ‘/u01/oracle/oradata/HRMSTB/datafile/o1_mf_mytbs_gb8m80ng_.dbf’ to ‘/u01/oracle/oradata/HRMSTB/datafile/o1_mf_mytbs_gb8k8lcv_.dbf’;

Database altered.

با این کار، اطلاعات جدول mytbl در محیط دیتاگارد، قابل رویت خواهد بود:

SQL> select * from mytbl;

D

–

X

در صورتی که حجم عملیات nologging نسبت به حجم دیتافایل بسیار ناچیز باشد، روش مذکور، نسبتا پرهزینه خواهد بود.

راه حل دوم: به عنوان راه حل دوم، با بدست اوردن scn اولین عملیات nologging انجام شده، از دیتافایل مورد نظر، بکاپی را تهیه می کنیم و بکاپ گرفته شده را در محیط دیتاگارد برمی گردانیم.

در این روش، حجم تغییرات انجام شده در دیتافایل از زمان استارت تا زمان کنونی فاکتور بسیار مهمی خواهد بود و در صورت بالا بودن حجم تغییرات در دیتافایل، استفاده از این روش به صرفه نخواهد بود.

در ادامه با طی چند مرحله، به روش incremental، بلاکهای خراب شده در محیط دیتاگارد را بازسازی می کنیم.

مرحله اول: در ابتدا در محیط دیتاگارد، لیست دیتافایلهایی که در اثر عملیات nologging، تعدادی از بلاکهای آنها خراب شده را مشخص می کنیم:

–Data Guard:

SQL> col FIRST_NONLOGGED_SCN  format 999,999,999,999

SQL> SELECT FILE#, FIRST_NONLOGGED_SCN FROM V$DATAFILE WHERE FIRST_NONLOGGED_SCN > 0;

     FILE# FIRST_NONLOGGED_SCN

———- ——————-

         6     710,265,766,493

همچنین این دستور، زمان انجام اولین عملیات nonloggin را برای این دیتافایلها مشخص خواهد کرد.

مرحله دوم:دیتاگارد را از حالت ریکاوری خارج می کنیم:

–Data Guard:

SQL> alter database recover managed standby database cancel;

Database altered.

مرحله سوم: با scn بدست امده در مرحله اول، از دیتافایل شماره 6، به صورت incremental بکاپ می گیریم و بکاپ ایجاد شده را به محیط دیتاگارد منتقل می کنیم:

— PRIMARY

RMAN> BACKUP INCREMENTAL FROM SCN 710265766493 DATAFILE 6 FORMAT ‘/home/oracle/NOLOGG_%U’;

Starting backup at 03-APR-19

using target database control file instead of recovery catalog

allocated chael: ORA_DISK_1

chael ORA_DISK_1: SID=1892 device type=DISK

chael ORA_DISK_1: starting full datafile backup set

chael ORA_DISK_1: specifying datafile(s) in backup set

input datafile file number=00006 name=/u01/oracle/oradata/HRMDB/datafile/o1_mf_mytbs_gb8sqb3n_.dbf

chael ORA_DISK_1: starting piece 1 at 03-APR-19

chael ORA_DISK_1: finished piece 1 at 03-APR-19

piece handle=/home/oracle/NOLOGG_notu2ja3_1_1 tag=TAG20190403T132523 comment=NONE

chael ORA_DISK_1: backup set complete, elapsed time: 00:00:01

chael ORA_DISK_1: starting full datafile backup set

chael ORA_DISK_1: specifying datafile(s) in backup set

including current control file in backup set

chael ORA_DISK_1: starting piece 1 at 03-APR-19

chael ORA_DISK_1: finished piece 1 at 03-APR-19

piece handle=/home/oracle/NOLOGG_nptu2ja4_1_1 tag=TAG20190403T132523 comment=NONE

chael ORA_DISK_1: backup set complete, elapsed time: 00:00:01

Finished backup at 03-APR-19

[root@db_host~]# scp -P 2333 /home/oracle/NOLOGG_n* STB_HOST:/home/oracle/

مرحله چهارم: کنترل فایل مربوط به دیتاگارد را بازسازی می کنیم:

—PRIMARY

SQL> alter database create standby controlfile as ‘/home/oracle/control01.ctl’;

Database altered.

[root@db_host~]# scp /home/oracle/control01.ctl STB_HOST:/u01/oracle/oradata/

مرحله پنجم: با اتصال به RMAN در محیط دیتاگارد، فایلهای بکاپ را به کنترل فایل معرفی کرده و اصطلاحا آنها را کاتالوگ می کنیم:

–Data Guard:

RMAN> catalog backuppiece ‘/home/oracle/NOLOGG_notu2ja3_1_1’;

backup piece handle=/home/oracle/NOLOGG_notu2ja3_1_1 RECID=1575 STAMP=1004623281

RMAN> catalog backuppiece ‘/home/oracle/NOLOGG_nptu2ja4_1_1’;

cataloged backup piece

backup piece handle=/home/oracle/NOLOGG_nptu2ja4_1_1 RECID=1576 STAMP=1004623291

مرحله ششم: در مرحله اخر، با دستور زیر، ریکاوری را انجام می دهیم:

–Data Guard:

RMAN> RECOVER DATAFILE 6 NOREDO;

Starting recover at 03-APR-19

using chael ORA_DISK_1

chael ORA_DISK_1: starting incremental datafile backup set restore

chael ORA_DISK_1: specifying datafile(s) to restore from backup set

destination for restore of datafile 00006: /u01/oracle/oradata/HRMSTB/datafile/o1_mf_mytbs_gb8vvch6_.dbf

chael ORA_DISK_1: reading from backup piece /home/oracle/NOLOGG_notu2ja3_1_1

chael ORA_DISK_1: piece handle=/home/oracle/NOLOGG_notu2ja3_1_1 tag=TAG20190403T132523

chael ORA_DISK_1: restored backup piece 1

chael ORA_DISK_1: restore complete, elapsed time: 00:00:01

Finished recover at 03-APR-19

با اجرای دستور زیر، خواهیم دید که دیتافایل شماره 6، به جهت عملیات nologging، بلاک خرابی ندارد:

SQL> SELECT FILE#, FIRST_NONLOGGED_SCN FROM V$DATAFILE WHERE FIRST_NONLOGGED_SCN > 0;

no rows selected

همچنین امکان مشاهده اطلاعات جدول mytbl در محیط دیتاگارد، فراهم شده است:

SQL> select * from mytbl;

D

–

X

در نسخه 12cR1، قابلیت جدیدی در این زمینه ارائه نشد و همان روشهای قبلی، در این نسخه هم قابل استفاده می باشند منتها در این نسخه، انتقال دیتافایل به محیط دیتاگارد، صرفا با یک دستور قابل انجام خواهد بود که شاید در این زمینه هم بتواند کمک موثری باشد.

RMAN> RESTORE DATAFILE 5 FROM SERVICE prim_srv;

با ارائه نسخه 12cR2 توسط اوراکل، قابلیت جدیدی در زمینه رفع خرابی بلاکهای nonlogged ارائه شد که با کمک آن، می توان با اجرای یک دستور، تمامی این بلاکهای خراب را از دیتابیس به دیتاگارد منتقل کرد.

در ادامه متن، شیوه استفاده از این قابلیت را مشاهده خواهید کرد.

sqlplus “/as sysdba”

SQL*Plus: Release 12.2.0.1.0 Production on Wed Apr 10 15:03:53 2019

Copyright (c) 1982, 2016, Oracle.  All rights reserved.

Coected to:

SQL> select force_logging from v$database;

FORCE_LOGGING

NO

SQL> create tablespace tbs12cR2;

Tablespace created.

SQL> alter tablespace tbs12cR2 no force logging;

ORA-12925: tablespace TBS12CR2 is not in force logging mode

SQL> create table mytbl tablespace TBS12CR2 nologging as select * from dual;

Table created.

بعد از ایجاد جدول به صورت nologging، پرس و جوی زیر را در دیتاگارد اجرا می کنیم:

–Data Guard:

SQL> select * from mytbl;

ORA-01578: ORACLE data block corrupted (file # 113, block # 131)

ORA-01110: data file 113: ‘+DATA01/HUMSTDB/DATAFILE/tbs12cr2.376.1005248097’

ORA-26040: Data block was loaded using the NOLOGGING option

با کمک ویوی v$nonlogged_block، لیست بلاکهایی که به دلیل عملیات nologging به دیتاگارد منتقل نشده اند، قابل مشاهده خواهند بود:

SQL> select FILE#,BLOCK#,BLOCKS,OBJECT# from v$nonlogged_block;

     FILE#     BLOCK#     BLOCKS OBJECT#

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

       113        131          1 5838349

برای انتقال این بلاک از محیط primary به دیتاگارد، در ابتدا باید ریکاوری را لغو نمود:

SQL> alter database recover managed standby database cancel;

Database altered.

و با اجرای دستور زیر، بلاکهای خراب را ریکاوری کرد:

RMAN> recover database nonlogged block;

Starting recover at 10-APR-19

using target database control file instead of recovery catalog

allocated chael: ORA_DISK_1

chael ORA_DISK_1: SID=1994 device type=DISK

starting recovery of nonlogged blocks

List of Datafiles

=================

File Status Nonlogged Blocks Blocks Examined Blocks Skipped

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

1    OK     0                0               646143       

2    OK     0                0               4193535      

3    OK     0                0               1201151      

4    OK     0                0               4194301      

5    OK     0                0               4194301      

113  OK     1                1               12798        

Details of nonlogged blocks can be queried from v$nonlogged_block view

recovery of nonlogged blocks complete, elapsed time: 00:01:02

Finished recover at 10-APR-19

همانطور که مشاهده می کنید، با اجرای دستور بالا، بلاکهای خراب دیتافایل شماره 113 ریکاور و تعمیر شده اند.

همراه با اوراکل نسخه 18c، قابلیت جدیدی در این زمینه ارائه شد که بر اساس ان، می توان عملیات nologging را با ملاحضات PERFORMANCEای و AVAILABILITY کنترل کرد. البته استفاده از این قابلیت، صرفا در محیط exadata امکان پذیر می باشد و مجوز استفاده از ان در نسخه EE هم وجود ندارد.

بر اساس این قابلیت جدید، می توان عملیاتی که بصورت nologging اجرا می شوند، را به دو شکل مدیریت کرد:

STANDBY NOLOGGING FOR DATA AVAILABILITY: در این حالت، بدون انکه redoای برای عملیات nologging ایجاد شود، بلاکهای حاوی اطلاعات nologging، به دیتاگارد ارسال خواهند شد و عملیات commit تا زمان ارسال این اطلاعات به دیتاگارد، معلق خواهد ماند.

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

SQL> ALTER DATABASE SET STANDBY NOLOGGING FOR DATA AVAILABILITY;

STANDBY NOLOGGING FOR LOAD PERFORMANCE: در محیطی که performance دیتابیس نسبت به AVAILABILITY آن، اهمیت بیشتری دارد، می توان از این قابلیت استفاده کرد در این صورت، تضمینی برای انتقال عملیات nologging از محیط primary به محیط Data Guard، وجود ندارد و صرفا در صورت ایجاد گپ، دیتاگارد در اسرع وقت، این بلاکها را از دیتابیس اصلی، واکشی خواهد کرد.

با دستور زیر، دیتابیس در حالت STANDBY NOLOGGING FOR LOAD PERFORMANCE قرار خواهد گرفت:

SQL> ALTER DATABASE SET STANDBY NOLOGGING FOR LOAD PERFORMANCE;

تالار های تخصصی...