شناسایی و تعمیر Corruption در پایگاه داده اوراکل
۱-مقدمه
Oracle corruption در اکثر مواقع بدلیل دیسک معیوب ایجاد می‌شود، اگرچه در موارد نادری logical corruption نیز در بلاک‌های مشاهده می‌شود.
Oracle data corruption میتواند در یک Table و یا Index اتفاق بیافتد. Index corruption را میتوان با حذف و بازسازی مجدد (درصورت امکان) برطرف کرد، همچنین میتوان از برخی ابزارهای Oracle برای شناسایی و ترمیم corruption استفاده نمود.
شناسایی و تعمیر Corruption در پایگاه داده اوراکل
۲-RMAN (BACKUP VALIDATE, RESTORE VALIDATE, VALIDATE)
بوسیله Oracle Recovery Manager (RMAN) می‌توانیم validate بودن دیتابیس را با استفاده از دستورBACKUP VALIDATE بررسی کنیم.
RMAN> BACKUP VALIDATE DATABASE ARCHIVELOG ALL;
در خروجی این عملیات همان اطلاعاتی که زمان تهیه بک‌آپ مشاهده می‌کنیم را می‌توانیم ببینیم با این تفاوت که پشتیبانی (backup) تهیه نمی‌شود. هرblock corruptions در view زیر و همچنین در خروجی RMAN قابل مشاهده است.
V$DATABASE_BLOCK_CORRUPTION
دستور فوق بصورت پیش‌فرض physical corruption را مورد بررسی قرار می‌دهد. با افزودن شرط CHECK LOGICAL بررسی شامل logical corruption نیز می‌شود.
RMAN> BACKUP VALIDATE CHECK LOGICAL DATABASE ARCHIVELOG ALL;
RMAN با استفده از دستور RESTORE VALIDATE میتواند معتبر بودن محتویات فایل‌های پشتیبان را بررسی کند.
RMAN> RESTORE DATABASE VALIDATE;
RMAN> RESTORE ARCHIVELOG ALL VALIDATE
در روشی مشابه دستور BACKUP VALIDATE ، دستور RESTORE VALIDATE عملیات restore را بدون انجام واقعی restore بررسی می‌کند.
قبل از ۱۱g ، دستور VALIDATE تنها برای اعتبار سنجی فایل‌های بک‌آپ مورد استفاده می‌گرفته. در اوراکل ۱۱g و بعد از آن، دستور VALIDATE میتواند اعتبارسنجی (VALIDATE) دیتافایل‌ها، tablespace و یا کل دیتابیس را بررسی و تایید کند، بنابراین می‌توانیم بجای دستور BACKUP VALIDATE از آن استفاده کنید.
RMAN> VALIDATE DATAFILE 1;
RMAN> VALIDATE DATAFILE ‘/u01/app/oracle/oradata/ORCL/system01.dbf’;
RMAN> VALIDATE CHECK LOGICAL DATAFILE 1;
RMAN> VALIDATE CHECK LOGICAL DATAFILE ‘/u01/app/oracle/oradata/ORCL/system01.dbf’;
RMAN> VALIDATE TABLESPACE users;
RMAN> VALIDATE CHECK LOGICAL TABLESPACE users;
RMAN> VALIDATE DATABASE;
RMAN> VALIDATE CHECK LOGICAL DATABASE;
تمامی block corruptions ها در V$DATABASE_BLOCK_CORRUPTIONقایل مشاهده هستند. با استفده از این کوئری می‌توانیم objectهای دارای block corruptions را شناسایی کنیم.
COLUMN owner FORMAT A20
COLUMN segment_name FORMAT A30
SELECT DISTINCT owner, segment_name
FROM v$database_block_corruption dbc
JOIN dba_extents e ON dbc.file# = e.file_id AND dbc.block# BETWEEN e.block_id and e.block_id+e.blocks-1
ORDER BY 1,2;
۳-Multitenant: RMAN VALIDATE
بسیاری از دستورات RMAN برای Instance اصلی را میتوان برای (PDB) و یا container استفاده کرد. زمانیکه به container متصل هستید می‌توانید مراحل زیر را انجام دهید.
rman target=/
# Everything.
VALIDATE DATABASE;
VALIDATE CHECK LOGICAL DATABASE;
# Just the root container.
VALIDATE DATABASE ROOT;
VALIDATE CHECK LOGICAL DATABASE ROOT;
# Just the specified PDB, or comma-separated list.
VALIDATE PLUGGABLE DATABASE pdb1;
VALIDATE CHECK LOGICAL PLUGGABLE DATABASE pdb1;
زمانیکه به PDB متصل هستید می‌توانید دستورات را مستقیماً صادر کنید.
rman target=sys/SysPassword1@pdb1
# Just the specified PDB.
VALIDATE DATABASE;
VALIDATE CHECK LOGICAL DATABASE;
۴-DBVerify
DBVerify بکی از ابزارهای خارجی است که امکان validation دیتافایل‌ها را بصورت offline و online فراهم می‌کند. علاوه بر دیتافایل‌های offline میتوان از آن برای بررسی validate بک‌آپ دیتافایل‌ها نیز استفاده کرد.
dbv file=/u01/app/oracle/product/../system01.dbf feedback=10000 blocksize=8192
معمولاً از این ابزار برای controlfile ، redo logها استقاده نمی‌شود. با اینحال در MOS Doc ID 1949795.1 مثالی از استفاده همراه controlfile وجود دارد.
۵-ANALYZE … VALIDATE STRUCTURE
دستور analyze میتواند برای بررسی هر block از اطلاعات ،در object مورد استفاده قرار گیرد. درصورت شناسایی corruption سطر جدید در جدول invalid_rows اضافه می‌شود.
— Create the INVALID_ROWS table
SQL> @C:\Oracle\901\rdbms\admin\UTLVALID.SQL
— Validate the table structure.
SQL> ANALYZE TABLE scott.emp VALIDATE STRUCTURE;
— Validate the table structure along with all it’s indexes.
SQL> ANALYZE TABLE scott.emp VALIDATE STRUCTURE CASCADE;
— Validate the index structure.
SQL> ANALYZE INDEX scott.pk_emp VALIDATE STRUCTURE;
۶-DB_BLOCK_CHECKING
زمانیکه پارامتر DB_BLOCK_CHECKING مقدار[true | high] تنظیم شده باشد، اوراکل با بررسی دیتا داخل بلاک بررسی می‌کند self_consistent باشد. متاسفانه block checking میتواند بین ۱ و ۱۰٪ overhead به دیتابیس تحمیل کند. اوراکل توصیه می‌کند اگر overhead موجود قابل قبول است مقدار پارامتر را تنظیم کنید.
مقادیر قابل قبول شامل: [OFF|FALSE], LOW, MEDIUM, [HIGH|TRUE].
۷-Block Media Recovery (BMR)
Block Media Recovery اجازه می‌دهد تا بلاک‌های مشخص شده بدون تاثیر بر کل دیتافایل ریکاوری شوند. این فقط برای استفاده در جایی درنظر گرفته شده که تعداد محدود و مشخصی از بلاک‌ها در آن آسیب دیده باشند. اینکار منجر به کاهش میانگین زمان ریکاوری (MTTR) و دسترسی بالاتر می‌شود، زیرا فقط بلاک‌های آسیب دیده حین عملیات آفلاین خواهند بود. BMR تنها از طریق RMAN و با دستور blockrecover قابل انجام است.
• Block Media Recovery یک ویژگی نسخه enterprise می‌باشد.
Block corruption به روش‌های زیر قابل شناسایی می‌باشد:
• پیغام خطا
• بررسی alert log
• دنبال کردن فایل‌ها
• دستورات ANALYZE [TABLE | INDEX]
• ابزارهای بررسی دیتابیس
• فهرست corrupt blocks مربوط به بک‌آپ در V$BACKUP_CORRUPTION و V$COPY_CORRUPTION
• فهرست corrupt blocks شناسایی شده دیتابیس در حین انجام عملیات RMAN .
بلاک‌های بازیابی شده تا زمان انجام مجدد عملیات بک‌آپ، در لیست باقی می‌مانند.
پس از شناسایی، corrupt blockها می‌توانند بصورت جداگانه بازیابی شوند. از طرف دیگر از CORRUPTION LIST میتوان برای بازیابی تمام بلاک‌های فهرست شده در V$DATABASE_BLOCK_CORRUPTION استفاده نمود. با استفاده از گزینه UNTIL میتوان این فهرست را محدود کرد.
BLOCKRECOVER DATAFILE 3 BLOCK 121;
BLOCKRECOVER CORRUPTION LIST RESTORE UNTIL TIME ‘SYSDATE – 7’;
۸-DBMS_REPAIR
برخلاف روش‌های ذکر شده قبلی، پکیج DBMS_REPAIR به شما امکان شناسایی و تعمیر block corruption را نیز می‌دهد. این پروسه نیاز به ۲ جدول مدیریتی برای نگهداری لیست block corruption و index keys به آن بلاک‌ها دارد. ایجاد این موارد بشرح زیر می‌باشد:
BEGIN
DBMS_REPAIR.admin_tables (
table_name => ‘REPAIR_TABLE’,
table_type => DBMS_REPAIR.repair_table,
action => DBMS_REPAIR.create_action,
tablespace => ‘USERS’);
DBMS_REPAIR.admin_tables (
table_name => ‘ORPHAN_KEY_TABLE’,
table_type => DBMS_REPAIR.orphan_table,
action => DBMS_REPAIR.create_action,
tablespace => ‘USERS’);
END;
/
با جداول مدیریتی ایجاد شده می‌توانیم جدول مورد نظر را با استفاده از procedure CHECK_OBJECT بررسی کنیم.
SET SERVEROUTPUT ON
DECLARE
v_num_corrupt INT;
BEGIN
v_num_corrupt := 0;
DBMS_REPAIR.check_object (
schema_name => ‘SCOTT’,
object_name => ‘DEPT’,
repair_table_name => ‘REPAIR_TABLE’,
corrupt_count => v_num_corrupt);
DBMS_OUTPUT.put_line(‘number corrupt: ‘ || TO_CHAR (v_num_corrupt));
END;
/
اگر تعداد corrupt blocks از ۰ بیشتر باشد میتوان از ستون‌های CORRUPTION_DESCRIPTION و REPAIR_DESCRIPTION جدول REPAIR_TABLE برای کسب اطلاعات بیشتر در مورد corruption استفاده کرد.
در این مرحله currupt blocksها شناسایی شده ولی هنوز نشانه گذاری نشده‌اند. از procedure FIX_CORRUPT_BLOCKS میتوان برای نشانه‌گذاری بلاک‌ها به عنوان corrupt استفاده کرد.
SET SERVEROUTPUT ON
DECLARE
v_num_fix INT;
BEGIN
v_num_fix := 0;
DBMS_REPAIR.fix_corrupt_blocks (
schema_name => ‘SCOTT’,
object_name => ‘DEPT’,
object_type => Dbms_Repair.table_object,
repair_table_name => ‘REPAIR_TABLE’,
fix_count => v_num_fix);
DBMS_OUTPUT.put_line(‘num fix: ‘ || TO_CHAR(v_num_fix));
END;
/
زمانی که corrupt blocks جدول واقع شده و index مشخص شده‌اند، باید بررسی شود که هر یک از ورودی‌های اصلی (key) به یک corrupt block اشاره داشته باشد. اینکار با استفاده از procedure :DUMP_ORPHAN_KEYS انجام می‌شود.
SET SERVEROUTPUT ON
DECLARE
v_num_orphans INT;
BEGIN
v_num_orphans := 0;
DBMS_REPAIR.dump_orphan_keys (
schema_name => ‘SCOTT’,
object_name => ‘PK_DEPT’,
object_type => DBMS_REPAIR.index_object,
repair_table_name => ‘REPAIR_TABLE’,
orphan_table_name => ‘ORPHAN_KEY_TABLE’,
key_count => v_num_orphans);
DBMS_OUTPUT.put_line(‘orphan key count: ‘ || TO_CHAR(v_num_orphans));
END;
/
اگر تعداد کلیدهای (بدون نام و نشان) بیشتر از ۰ باشد، index باید rebuilt شود.
پروسه علامت‌گذاری corrupt blockهای جدول، بطور خودکار آنرا از لیست (freelist) حذف می‌کند. این میتواند مانع دسترسی freelist به بلاک‌های زیر مجموعه corrupt block شود. برای اصلاح این موضوع، freelist باید با استفاده از procedure : REBUILD_FREELISTS بازسازی ((rebuilt شود.
BEGIN
DBMS_REPAIR.rebuild_freelists (
schema_name => ‘SCOTT’,
object_name => ‘DEPT’,
object_type => DBMS_REPAIR.table_object);
END;
/
مرحله نهایی در این پروسه اطمینان از نادیده گرفتن اطلاعات بلاک‌های مشخص شده به عنوان corrupt توسط دستورات DML می‌باشد. اینکار بوسیله procedure: SKIP_CORRUPT_BLOCKS انجام می‌شود.
BEGIN
DBMS_REPAIR.skip_corrupt_blocks (
schema_name => ‘SCOTT’,
object_name => ‘DEPT’,
object_type => DBMS_REPAIR.table_object,
flags => DBMS_REPAIR.skip_flag);
END;
/
ستون SKIP_CORRUPT در DBA_TABLES نشان دهنده موفقیت‌آمیز بودن این عملیات می‌باشد.
در این مرحله جدول مجدداً قابل استفاده خواهد بود ولی باید اقداماتی را برای اطلاعات از دست‌رفته مربوط به بلاک‌های از دست رفته انجام دهیم.
۹- Other Repair Methods
روش‌های دیگر برای اصلاح corruption عبارتند از:
• بازیابی کامل دیتابیس.
• بازیابی دیتافایل‌ها بصورت تکی.
• ساخت مجدد جدول با استفاده از دستور CREATE TABLE .. AS SELECT. محافظت از جدول در برابر corrupt blocks بوسیله محدود کردن where clause در دستور فوق.
• حذف جدول و بازگردانی آن از اکسپورت قبلی. اینکار ممکن است به جایگزینی دستی اطلاعات از دست رفته نیاز داشته باشد.
دیدگاه خود را ثبت کنید
تمایل دارید در گفتگوها شرکت کنید؟در گفتگو ها شرکت کنید.