1. 증후
ORA-01578 or alert 에 corrupt message
2. 일반적인 Error Message
- ORA-01578 - Physical Structual damage
Error: ORA-1578
Text: ORACLE data block corrupted (file # %s, block # %s)
-------------------------------------------------------------------------------
Cause: The data block indicated was corrupted, mostly due to software
errors.
Action: Try to restore the segment containing the block indicated. This
may involve dropping the segment and recreating it. If there
is a trace file, report the errors in it to your ORACLE
representative.
SQL> SELECT segment_name , segment_type , owner , tablespace_name
FROM sys.dba_extents
WHERE file_id = &bad_file_id
AND &bad_block_id BETWEEN block_id and block_id + blocks -1
dbv utility, export, Rman 을 통해서 분석 가능
주로 ) Index 관련 nologging 후 recover 를 통해서 발생
EX) 8i Live Database -> Archive 전송 -> Standby Database 환경
No Logging Operation =========> Standby database recover
==> Standby Database Activate 시에 Nologging 작업을 한
block 이 corrupt 로 발견된다.
- ORA-08103 - Logical Corrupt Error
Error: ORA 8103
Text: object no longer exists
-------------------------------------------------------------------------------
Cause: The object has been deleted by another user since the operation began.
Action: Remove references to the object.
7.3.2.3 에서만 발견되는 Error
SQL> analyze table .. validate structure cascade ; 로 분석
SQL> SET ARRAY 1
SQL> SELECT ROWID, LAST_COLUMN_OF_TABLE from TABLE;
를 통해서 corrupt 발생한 rowid 발견
- ORA-600 [2662] - block corruption
Data block 의 SCN 이 Current SCN 보다 앞설때 발생하며,
결과적으로 Instance Filure 가 발생하고, Physical Corrupt 가 발생할
가능성이 있다. 주로 DB Startup 시 발생...
3. Check Physical Corruption
A. DBV Utility 를 통해서 Check
한계점 :
- Table 과 Index 간의 Mismatch 는 검색 불가 [ 논리적 Corrupt 검색 불가]
- Undo/Redo 의 Logical Corrupt 검색 불가
장점 :
- File 에 대한 Access 가 가능하면 가능하다.
- Database Online / Offline 과 무관하게 사용가능
B. RMAN 을 통한 Check
RMAN> BACKUP VALIDATE DATABASE ;
RMAN> BACKUP VALIDATE DATAFILE 1;
: RMAN 을 통해서 Backup 이 구현된 경우 Corrupt Checking Option 을 추가하여
정기적인 Checking 이 가능
C. Export Utility 를 통한 Check
file=/dev/null 로 지정후 full 로 export 진행 하여 Database 전체 검색
혹은 의심가는 Segment 에 대한 export 진행 하여 해당 Segment 검색
한계점 :
- 첫번째 Corruption 에서 Error 발생 - 그 다음에 존재하는 Corrupt Check 불가
- Index 에 대한 Check 불가 [ Export 는 Table Full Scan ]
- Data Dictionary 에 대한 검색 불가
D. Analyze 를 통한 Check
SQL> Analyze table <OWNER.TABLE_NAME> VALIDATE STRUCTURE [CASCADE] ;
Table + Index [ CASCADE ]
SQL> Analyze index <OWNER.INDEX_NAME> VALIDATE STRUCTURE ;
Index Only
SQL> Analyze Table <OWNER.TABLE_NAME> VALIDATE STRUCTURE CASCADE INTO
INVALID_ROWS ;
Partition Table
한계점 :
1. 운영중 analyze ... validate structure 는 lock 이 발생 할 수 있어
성능 문제를 유발 할 수 있다.
2. Export 와 마찬가지로 첫번째 Corrupt 만 발견 가능
4. Corrupt Segment 판별
SQL> SELECT segment_name , segment_type , owner , tablespace_name
FROM sys.dba_extents
WHERE file_id = &bad_file_id
AND &bad_block_id BETWEEN block_id and block_id + blocks -1
- Index 면 Rebuild, Table 이면 ...
5. Oracle 문제인지 판별(?)
관련 Oracle bug 를 찾아본다 ㅡ_ㅡ;
6. Restore / Recover
Recovery 를 통해 해결이 가능. But 일반적으로 OS/Hardware 문제로
해결이 Recovery 시 문제가 재발 가능
7. Restore / Recover 시 문제 재발은 무엇이 일으키는가 ?
Data file, redo file 에 대한 Dump 후 trace 분석.
8. Corrupt Checking 을 위한 Oracle Parameter
a. DB_BLOCK_CHECKING=TRUE
TRUE - 모든 Block 에 대한 Checking, 1~10% Overhead 발생
FALSE - System Tablespace Checking
b. DB_BLOCK_CHECKSUM=TRUE
DBwn ... Checksum...
FALSE - System Tablespace Checking
- Disks, Storage System, I/O System 에 의해 발생한 Corrupt만 Checking