BLOCK CORRUPTION (ORACLE8 에서 ORA-1578 조치방법)

Question

제품 : ORACLE SERVER
작성날짜 : 2002-04-26
BLOCK CORRUPTION (ORACLE8 에서 ORA-1578 조치방법)
================================================
PURPOSE
본 bulletin 에서는 Oracle8 에서의 data block corruption error
(ORA-1578) 에 대해서 조치방법을 알아본다.
BACKGROUND
ORA-1578 은 data block 에 corruption 이 생긴 경우에 발생한다.
이 error 는 corruption 이 발생한 곳의 file number 와 block
number 를 알려준다.
본 bulletin 에서는 file number 를 'f', block number 를 'b' 로
지칭하기로 한다. ORA-1578 과 함께 return 되는 file number는
relative file number 가 아닌 absolute file number 를 의미한다.
(Oracle8 에서 새롭게 소개된 relative file number 에 대해서는 본
bulletin 의 6번 항목에서 다루도록 한다.)
RESOLUTION
1. 최선의 해결책은 backup 받아둔 file 을 restore 한 후
recover 작업을 하는 것이다. 이 작업을 위해서는 archive
log mode 로 운영 중이어야 한다.
dba_data_files 또는 v$datafile 과 ORA-1578 error 에서
return 된 absolute file number 를 이용하여 corruption이
발생한 datafile 의 이름을 알아낼 수 있다.
Oracle8 에서는, dba_data_files 에 absolute file number
(file_id) 와 함께 relative file number (relative_fno) 를
가지고 있다.
v$datafile 에는 아직 absolute file number (file#) 만을 가진다.
backup 을 restore 하기 전에 hardware 의 문제를 fix 해야 할
필요가 있을 수 있다. 만약 corruption 이 disk 불량에 의해
발생하였다면, backup 받아둔 datafile 을 문제가 없는 disk 에
restore 하고, startup mount 한 후, 새로운 위치로 datafile
rename 을 하고 recover 한다.
만약 해당 datafile 이 system tablespace 에 속하지 않는다면
offline tablespace recovery 도 가능하다.
2. backup datafile 을 restore 하고 recover 하지 않을 것이라면
우선, 어떤 object 에서 corruption 이 발생하였는지 확인해야
한다.
다음의 SQL 문을 이용한다.
SELECT owner, segment_name, segment_type, relative_fno
FROM dba_extents
WHERE file_id = f
AND b BETWEEN block_id AND block_id + blocks - 1 ;
3. 해당 segment 가 non-data dictionary index라면, 해당 index를
drop 한 후 재생성한다.
4. 해당 segment 가 table 이라면, corruption 이 발생한 block 의
data 는 소실된 것이다.
5. 만약 해당 table 에 대한 최근의 export dump file이 존재한다면,
해당 table 을 drop 한 후 import 함으로써 복구할 수 있다.
최근의 export dump file 이 없거나 이를 export 받을 수 있는
최근의 backup 이 없다면 다음과 같은 방법을 이용할 수 있다.
6. corruption 이 발생한 non-clustered table 에서 corrupted
block 을 access 하지 않고 나머지 data 들을 select 할 수
있도록 ROWID 를 이용할 수 있다. non-clustered table의 모든
row 들은 해당 row 의 물리적인 주소를 가리키는 고유한 ROWID를
갖는다(해당 row가 여러 block에 조각이 나 있다면 첫번째 조각에
대한 주소). clustered table 인 경우에는 서로 다른 table 의
data 들이 같은 block 에 존재할 수 있으며, 같은 ROWID 를 가질
수 있다.
Oracle 은 index 를 구성하기 위하여 내부적으로 ROWID 를 사용한다.
따라서 where 절에 ROWID 를 사용하여 select 하면 강제로 range
scan 를 할 수 있다.
Oracle8 에서는 이를 위하여 ROWID hint 를 사용할 필요가
없어졌다.
ROWID 를 이용하여 table 로부터 data 를 추출하기
예제로써 ACCT_NO, PERSON, WEEKNO 등의 column 으로 구성된
SCOTT user의 EXAMPLE 이라는 table 이 있다고 가정한다.
이때, ORA-1578 "ORACLE data block corrupted (file # 5,
block # 2) 가
발생하였다고 가정하자.
ROWID in Oracle8 :
Oracle8 에서의 ROWID 는 'OOOOOOFFFBBBBBBSSS' format 을 가진다.
OOOOOO = data object number
Oracle7 의 object_id 와는 별도로 segment 의 id 를 갖는다.
dba_objects 의 data_object_id 에서 확인가능
FFF = relative file number
BBBBBB = block number
SSS = row number
Oracle8에서의 ROWID 는 absolute file number 가 아닌 relative
file number 를 갖는다는 점에 주목해야 한다.
relative file number 는 tablespace 에 대해 상대적이며
(tablespace마다 첫번째, 두번째, 세번째 datafile 을 가질 수
있음을 의미) absolute file number 는 전체 database 내에서
고유하다. 두개의 서로다른 file 들이 동일한 relative file
number를 가질 수 있다.
만약 EXAMPLE table 에서 ACCT_NO, ROWID 를 select하면 다음과
같은 결과가 나올 수 있다.
ACCT_NO ROWID
12345 AAAAh3AAGAAACJAAAA
19283 AAAAh3AAGAAACJAAAB
22345 AAAAh4AAFAAAAADAAA
60372 AAAAh4AAFAAAAADAAB
33456 AAAAh5AAEAAAAIuAAA
29473 AAAAh5AAEAAAAIuAAB
이러한 format 을 extended ROWID character format 이라고
지칭한다.
extended ROWID 는 number 이므로 substr 함수를 이용하여
extended ROWID 로부터 일부를 떼어낼 수 없다.
ROWID 를 생성하기 위해서는 모든 component 를 알아야 한다.
그런다음, DBMS_ROWID package 의 function 을 이용하여 ROWID 를
생성할 수 있다.
function rowid_create(rowid_type IN number,
object_number IN number,
relative_fno IN number,
block_number IN number,
row_number IN number)
return rowid;
pragma RESTRICT_REFERENCES(rowid_create,WNDS,RNDS,WNPS,RNPS);
-- rowid_type - type (restricted=0/extended=1)
-- object_number - data object number
(rowid_object_undefined for )
-- restricted
-- relative_fno - relative file number
-- block_number - block number in this file
-- file_number - file number in this block
corruption 이 발생한 block 의 data object number 를 알기
위해서는 dba_objects 를 조회한다.
SELECT data_object_id FROM dba_objects
WHERE owner = 'SCOTT'
AND object_name = 'EXAMPLE' ;
DATA_OBJECT_ID
2168
우리는 이미, 위에서 사용한 다음의 SQL 에 의해서 relative file
number 를 알고 있다.
SELECT owner, segment_name, segment_type, relative_fno
FROM dba_extents
WHERE file_id = 5
AND 2 BETWEEN block_id AND block_id + blocks - 1 ;
OWNER SEGMENT_NAME SEGMENT_TYPE RELATIVE_F
SCOTT EXAMPLE TABLE 5
corruption 이 발생한 block 이 2이므로, block# 2 이전의 access
가능한 마지막 ROWID 는 block# 1 에 존재한다. 그리고 block# 2
이후의 access 가능한 첫 ROWID 는 block# 3에 존재한다. block
안에 몇개의 row number 가 존재할 지 모르므로 row number 0 을
이용한다.
이제 corrupted block 이전의 ROWID 와 이후의 ROWID 를 생성할
준비가 끝났다.
corrupted block 이전의 ROWID :
SELECT DBMS_ROWID.ROWID_CREATE(1,2168,5,1,0) FROM example ;
DBMS_ROWID.ROWID_C
AAAAh4AAFAAAAABAAA
corrupted block 이후의 ROWID :
SELECT DBMS_ROWID.ROWID_CREATE(1,2168,5,3,0) FROM example ;
DBMS_ROWID.ROWID_C
AAAAh4AAFAAAAADAAA
다음으로, EXAMPLE table 과 같은 spec 으로 table 을 하나 만든다.
CREATE TABLE temp AS SELECT * FROM example WHERE 1=2;
그리고 corrupted block 이외의 block 에서 data 를 추출하여
insert 한다.
INSERT INTO temp SELECT * FROM example
WHERE ROWID <= 'AAAAh4AAFAAAAABAAA';
INSERT INTO temp SELECT * FROM example
WHERE ROWID >= 'AAAAh4AAFAAAAADAAA';
이후 원본 table 을 drop 하고, TEMP 를 rename 한다.
7. 만약 data dictionary 에 속하는 table, index 또는 rollback
segment에 corrupted block 이 발생하였다면 Oracle Support 의
지원을 받는다.
8. 일반적으로, ORA-1578 은 hardware 의 문제때문에 유발된다.
하지만 만약에 ORA-600[3374] 가 발생한다면 memory 상에서
corruption 이 발생한 경우이다.
이 경우 database 를 restartup 하면 문제가 해결될 수 있다.
Reference Documents
--------------------

Answer 1

Hello,
Please check the link i posted.
Example: Detecting Corruption
The CHECK_OBJECT procedure checks the specified object, and populates the repair table with information about corruptions and repair directives. You can optionally specify a range, partition name, or subpartition name when you want to check a portion of an object.
Validation consists of checking all blocks in the object that have not previously been marked corrupt. For each block, the transaction and data layer portions are checked for self consistency. During CHECK_OBJECT, if a block is encountered that has a corrupt buffer cache header, then that block is skipped.
The following is an example of executing the CHECK_OBJECT procedure for the scott.dept table.
SET SERVEROUTPUT ON
DECLARE num_corrupt INT;
BEGIN
num_corrupt := 0;
DBMS_REPAIR.CHECK_OBJECT (
SCHEMA_NAME => 'SCOTT',
OBJECT_NAME => 'DEPT',
REPAIR_TABLE_NAME => 'REPAIR_TABLE',
CORRUPT_COUNT => num_corrupt);
DBMS_OUTPUT.PUT_LINE('number corrupt: ' || TO_CHAR (num_corrupt));
END;
SQL*Plus outputs the following line, indicating one corruption:
number corrupt: 1