Alice's Story

ORA-39001: invalid argument value
ORA-39000: bad dump file specification
ORA-39142: incompatible version number 2.1 in dump file "/oracle/mikyungnet/dnshop/z_dnshop_target.dmp"

--------------------------------------------------------------------------------------------------------------------

11g에서 10g로 스키마째 밀어 넣어야 되는데
버전이 틀려서 import/export는 동작 안한다.
벌써 이거가지고 몇번을 삽질한건지.. 정리 좀 해야겠다.

검색해보니까 data pump란게 있다. 버전이 상관없댄다. 그래서 그런줄 알았다.

그래서 expdp test/test@SID schemas=TEST dumpfile=TEST.dmpdp
이렇게 덤프를 뜨고

impdp test/test schemas=TEST dumpfile=TEST.dmpdp 했다.

그랬더니 디렉토리가 없다고 에러를 뱉어 낸다.
또 뒤졌다.

기본으로 잡혀있는 디렉토리가 있는데 해당 유저에게 권한을 줘야 한다.
디렉토리를 path로 주는게 아니라 오라클 객체를 사용하나보다.
grant read, write on directory DATA_PUMP_DIR to test;

아니면 디렉토리를 하나 만들고 아래처럼
CREATE OR REPLACE DIRECTORY data_pump_dir AS '/home/oracle/admin/ora10/dpdump';
GRANT read, write ON DIRECTORY data_pump_dir TO test;

이렇게 해주고

impdp test/test schemas=TEST directory=data_pump_dir dumpfile=TEST.dmpdp 했다.

근데 또 안된다. 망할..

ORA-39142: incompatible version number 2.1 in dump file 라고 뜬다.

또 검색..

뒤져보니 덤프를 뜰때 버전을 명시해줘야 한댄다..
그러니까 같은 11g라고 하더라도 서브버전이 틀린 경우는 그냥 되는데 메이저 버전이 틀린 경우는 그러니까 이번같이 11g에서 10g로 내려가는 경우는 덤프를 뜰때 버전을 명시해줘야 한다.

expdp test/test@SID schemas=TEST dumpfile=TEST.dmpdp VERSION=10.2

이렇게 해야되는건가 보다.

원래 EXPDP할때도 directory를 지정해줘야 하지만 지정안하면 기본 디렉토리에 덤프파일이 깔린다. 기본디렉토리는.. 아 쓰기 귀찮다. 덤프 다 뜨면 경로 나온다.

추가로 import할 곳에 스키마가 다른 경우라면 impdp ~~~~ REMAP_SCHEMA=test:test1 를 추가해주고 테이블 스페이스가 다른 경우 REMAP_TABLESPACE=test:test1 로 변경할 수도 있다.

돌려보니까. expdp를 아무 옵션안주고 뜨면 그 스키마에 걸려 있던 롤까지 통째로 가져와서 impdp할때 에러가 난다. 그다지 중요한 롤이 아니었으니 일단 skip하지만 나중엔 좀 챙겨놔야할 듯.

결론. 오라클의 data pump로 하위 호환성을 가지게 덤프를 뜨려면(스키마를 다른이름의 스키마로 다른 테이블 스페이스에)

expdp test/test@SID schemas=TEST dumpfile=TEST.dmpdp VERSION=10.2

요렇게 떠서

impdp test/test schemas=TEST directory=data_pump_dir dumpfile=TEST.dmpdp REMAP_SCHEMA=test:test1 REMAP_TABLESPACE=test:test1

요렇게 밀어 넣는다.

이것 외에 db를 통채로 이관하거나 특정테이블만 골라서 덤프를 뜰 수도 있으며 여러가지(스키마, 테이블스페이스, datafile 등) 리매핑 작업이 가능하다. 또한 덤프를 뜰때 타겟 버전만 명시해주면 타버전 호환도 가능하다.(물론 10g부터 나온거니까 그 이후로만)

ORA-02049 : 시간초과 : 분산 트랜잭션이 잠금으로 대기중입니다.

위와 같은 메시지가 뜬다면 테이블이 락이 걸려서 TOAD의 사용이 막힌 경우 테이블의 락을 풀어줘야 하는데, 보통은 SYSTEM 계정으로 접근하여 문제가 있는 트랜잭션을 찾는다.

--Transaction 찾는 쿼리
SELECT A.SID, A.SERIAL#, B.TYPE, C.OBJECT_NAME
FROM V$SESSION A, V$LOCK B, DBA_OBJECTS C
WHERE A.SID=B.SID
AND B.ID1=C.OBJECT_ID
AND B.TYPE='TM'
--AND C.OBJECT_NAME IN ('IFRS_VAL_ACCT') --특정 테이블에서 tx 찾을때 사용
;

찾은후 해당 SID와 SERIAL# 값으로 아래를 실행하여 아래와 같은 쿼리를 실행하면
테이블의 락이 해제된다.

--session kill하는 쿼리  
--alter system kill session 'SID, SERIAL#'
alter system kill session '365,41540';

하지만, 테이블 락을 해제 쿼리를 입력하여도 ORA-00031 : session marked for kill 의 메시지가 나오는 경우가 있다. 직접적으로 아래의 쿼리를 이용하여 oracle 계정으로 시스템에 접근하여 프로세스를 kill 하는 방법이 있다.
( 어떤 세션이 매우 긴 트랜잭션을 수행하다가 강제로 kill이 되게 되면, 우선은 해당 트랜잭션이 사용하던 rollback segment가 회수되게 됩니다. 이때, 그 사이즈가 크면 클 수록 롤백되는 시간이 길어지는데요. 그 동안은 어쨋든 세션은 유지되어야 하는거죠.kill marking만 되구요. 이 때에도 해당 롤백세그먼트는 사용될 수 있습니다. )

SELECT VS.SID, VS.USERNAME, VS.OSUSER,
            VS.PROCESS FG_PID,VP.SPID BG_PID
FROM V$SESSION VS, V$PROCESS VP
WHERE VS.PADDR = VP.ADDR;

위의 쿼리를 실행하여, PID(ProcessID)를 확인후 오라클 계정으로 시스템에 접근하여, kill 명령어를 이용하여 해당 프로세스를 종료한다.

$ kill -9 pid

물론 앞서 메시지가 나오고 방금 kill 이 안되는 경우에도 어느정도 시간을 갖고 기다리면 rollback segment의 수치가 점점 작아져 결국 테이블 락이 해제가 된다.

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

Error:  ORA 3113
Text:   end-of-file on communication channel
-------------------------------------------------------------------------------
Cause:  An unexpected end-of-file was processed on the communication channel.
        The problem could not be handled by the SQL*Net, two task, software.
        This message could occur if the shadow two-task process associated with
        a SQL*Net connect has terminated abnormally, or if there is a physical
        failure of the interprocess communication vehicle, that is, the
        network or server machine went down.

Action: If this message occurs during a connection attempt, check the setup
        files for the appropriate SQL*net driver and confirm SQL*Net software
        is correctly installed on the server. If the message occurs after a
        connection is well established, and the error is not due to a physical
        failure, check if a trace file was generated on the server at failure
        time. Existence of a trace file may suggest an Oracle internal error
        that requires the assistance of customer support.

*** Important: The notes below are for experienced users - See Note:22080.1


Explanation:
        There are numerous causes of this error. It is a 'catch all' type
        error which means 'I cannot communicate with the oracle shadow process'.
        This usually occurs when the Oracle server process has died for
        some reason.

Diagnosis:
        Oracle support need more information to determine what caused the
        error. The most useful items are:

        1) Does this occur when trying to (a) make a connection to the
           database or (b) on an established connection ?

        2) There should be a trace file from the failed session in
           USER_DUMP_DEST

        3) Does a particular statement reproduce this problem or is it
           random ? Use SQL_TRACE on the session to find the problem
           statement.

Articles:
        ORA-3113 on Unix - What Information to Collect       Note:17613.1