Alice's Story

사실 함 같은건 안할려고 했는데..
시간도 그다지 없고 이거저거 번거로운건 하기 싫었는데.. ;;
그래도 형식상 해야할꺼 같기도 하고..
엄마 아빠도 한번 받는 함이기도 하고.. ㅋㅋ
뜻도 좀 있고 해서.. ;;

결국 함을 만들어서 부산에 갔음;;
친구들 가고.. 머 이런건 전혀 없이 낭군이 그냥 짊어지고 갔음. ㅋㅋ
부모님한테 큰절하고.. 끝.. 별껀 없음. ;;
함 사진도 찍을껄.. 정신 없이 갔다가.. 그냥 대충.. 절만 하고.. ㅋㅋ

== 백업 ==

DB전체 덤프
mysqldump -u[아이디] -p[비밀번호] -all-databases > [저장될 파일명]

DB만 덤프
mysqldump -u[아이디] -p[비밀번호] [디비명] > [저장될 파일명]

테이블 구조만
mysqldump -u[아이디] -p[비밀번호] --no-data [디비명] [테이블명] > [저장될 파일명]

테이블구조를 제외한 데이터만 덤프
mysqldump -u[아이디] -p[비밀번호] --no-create [디비명] [테이블명] > [저장될 파일명]

==복구 ==

덤프파일을 이용한 복구
mysql -u[아이디] -p[암호][디비명] < [파일명]

패스워드 동시 입력시 복구 안되면
mysql -u[아이디] -p[공백][디비명] < [파일명]

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