یکی از مراحل پیکربندی دیتاگارد، قراردادن دیتابیس در حالت 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 در محیط دیتاگارد چه خواهد شد؟ در ادامه سعی داریم به این سوال پاسخ دهیم.
رفع خرابی بلاکهای nonlogged در اوراکل 11g
در این قسمت، با انجام عملیات 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.
Connected 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 channel: ORA_DISK_1
channel ORA_DISK_1: SID=1892 device type=DISK
channel ORA_DISK_1: starting full datafile backup set
channel 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
channel ORA_DISK_1: starting piece 1 at 03-APR-19
channel ORA_DISK_1: finished piece 1 at 03-APR-19
piece handle=/home/oracle/NOLOGG_notu2ja3_1_1 tag=TAG20190403T132523 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
including current control file in backup set
channel ORA_DISK_1: starting piece 1 at 03-APR-19
channel ORA_DISK_1: finished piece 1 at 03-APR-19
piece handle=/home/oracle/NOLOGG_nptu2ja4_1_1 tag=TAG20190403T132523 comment=NONE
channel 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 channel ORA_DISK_1
channel ORA_DISK_1: starting incremental datafile backup set restore
channel 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
channel ORA_DISK_1: reading from backup piece /home/oracle/NOLOGG_notu2ja3_1_1
channel ORA_DISK_1: piece handle=/home/oracle/NOLOGG_notu2ja3_1_1 tag=TAG20190403T132523
channel ORA_DISK_1: restored backup piece 1
channel 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
رفع خرابی بلاکهای nonlogged در اوراکل 12c
در نسخه 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.
Connected 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 channel: ORA_DISK_1
channel 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 ریکاور و تعمیر شده اند.
رفع خرابی بلاکهای nonlogged در اوراکل 18c
همراه با اوراکل نسخه 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;
وحید یوسف زاده
ارائه خدمات مشاوره ، پشتیبانی و نصب و راه اندازی پایگاه داده اوراکل در سراسر کشور...................... تلفن: 09128110897 ایمیل:vahidusefzadeh@gmail.com
Comments (2)