روشهای شناسایی و رفع Block Corruption

block corruption در بانک اطلاعاتی اوراکل خطای بسیار معروفی است که ممکن است سبب از دست رفتن داده شود این خطا معمولا به خاطر مشکلات سخت افزاری یا سیستم عاملی رخ می دهد و در صورت نداشتن backup سالم از قسمت خراب شده به ناچار باید از اطلاعات ذخیره شده در آن قسمت، صرف نظر کنیم. این اتفاق به دو شکل ممکن است رخ دهد:

Physical corruption: در این صورت، اطلاعات بلاک غیرقابل فهم است و سبب می شود تا کاربر نتواند به اطلاعات ذخیره شده در آن، دسترسی پیدا کند. علت این اتفاق به خطای در i/o، خطای در حافظه، Server Controller  و ... بر می گردد. همچنین بلاک می تواند به دلایل مختلفی مثل خرابی هدر، نامعتبری checksum بلاک و ناسازگاری ابتدای بلاک با دنباله آن، خراب محسوب شود. این خطا با ORA-01578 ظهور و بروز می کند.

Logical corruption: در این نوع خطا معمولا header و footer بلاک سالم هستند ولی در محتویات بلاک تناقض وجود دارد برای مثال، فضایی را که هدر بلاک نشان می دهد، با فضای واقعی یکسان نیست. این نوع خطا را می توانیم با ابزار dbv پیدا کنیم البته اگر پارامتر db_block_checking فعال شود، این خطا بصورت ORA-600 [kddummy_blkchk] و ORA-600 [kdBlkCheckError] و یا ORA-00600[3339] در alert log ثبت می شود.

خرابی بلاک ممکن است برای datafile،control file  و یا redo logها رخ دهد ولی در این مطلب روشهای شناسایی و رفع بلاکهای خراب شده data file را مورد بررسی قرار می دهیم. این خرابی ممکن است در چهار سطح Sort block، Undo header and Undo block، Data dictionary object، Fileheader block و Data / Index blockاتفاق بیفتد که بدترین حالت آن Data dictionary object است که ممکن است کل بانک را به نابودی بکشاند.

برای شناسایی سریعتر block corruption و همچنین جلوگیری از رخ دادن آن، پارامترهایی موثزند که از نمونه db_block_checksum است که مقدار پیش فرض آن true است یعنی DBWR بر اساس بیتهای ذخیره شده در بلاک، بیت کنترلی را محاسبه کرده و آن را در cache header بلاک می نویسد زمانی که این بلاک برای read مورد دسترسی قرار می گیرد، checksum بر اساس اطلاعات درون بلاک دوباره مورد محاسبه قرار می گیرد و اگر با مقدار ذخیره شده در هدر بلاک یکسان نبود، خطای ORA-01578 رخ خواهد داد. این پارامتر حدود1  تا 5 درصد ممکن است بر روی عملیات DMLای بار اضافه ایجاد کند.

پارامتر db_block_checking هم سبب می شود تا بلاک قبل از انتقال به دیسک، از نظر صحت header،footer  و بقیه قسمتها مورد ارزیابی قرار بگیرد. این پارامتر حدود1 تا 10 درصد ممکن است بر روی عملیات DMLای بار اضافه ایجاد کند.

در این قسمت سعی داریم تا به طور مختصر روشهای شناسایی و رفع block corruption را بیان کنیم.

روشهای شناسایی و رفع block corruption

در ابتدا با استفاده از دستور لینوکسی dd، بلاک جدولی را خراب می کنیم(در ویندوزمی توان datafile را با یک ویرایشگر باز کرد و قسمتی از آن را دستکاری کرد) و با استفاده از روشهایی که آورده می شود، این بلاک، بازیابی یا skip می شود. پس از دستور dd تنها برای محیط تست استفاده می کنیم(البته این دستور کاربردهای دیگری هم دارد). همچنین می توان از ابزار درونی اوراکل با نام BBED برای دستکاری و یا حتی ترمیم بلاکهای datafile استفاده کرد.

در مثال ما، جدول usef_temp در ابتدا کاملا سالم بوده و جواب پرس و جو نشان می دهد که این جدول 10000 رکورد در خود دارد:

select count(*) from usef.usef_temp;

 10000

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

 

select * from (select distinct dbms_rowid.rowid_block_number(rowid)  from USEF_TEMP)   where rownum < 6;

 

10246  

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

dd of=/u01/oracle/11g/db1/dbs/USEF_TBS.dbf  bs=8192  seek=10246  conv=notrunc  count=1  if=/dev/zero

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

alter system flush buffer_cache;

select *  from usef.usef_temp;

ERROR:

ORA-01578: ORACLE data block corrupted (file # 5, block # 10246)

ORA-01110: data file 5: '/u01/oracle/11g/db1/dbs/USEF_TBS.dbf'

با دستور زیر، دقیقا مشخص می کنیم که اطلاعات کدام object خراب شده است:

SELECT tablespace_name, segment_type, owner, segment_name, partition_name FROM dba_extents WHERE file_id = 5 AND 10246 between block_id and block_id + blocks-1;

در جدول زیر، بعضی از روشهای شناسایی و ترمیم لیست شده اند که در ادامه قصد داریم در مورد هر یک از آنها، مطالبی به طور مختصر را بیان کنیم:

تعمیر	شناسایی
ROWID	DBVERIFY
export(expdp)	export
RMAN	RMAN
Event	Event
DBMS_REPAIR	DBMS_REPAIR
Data guard	ORA-1578 و ALERT.LOG
Data Recovery Advisor	Data Recovery Advisor
	ANALYZE TABLE

 

ادامه مطلب

به دلیل طولانی بودن مطلب، لطفا pdf این مطلب را مطالعه بفرمایید(لطفا اینجا کلیک کنید)