### Lock 확인 쿼리
SELECT do.object_name, do.owner, do.object_type,do.owner, vo.xidusn, vo.session_id,
vo.locked_mode
FROM v$locked_object vo , dba_objects do
WHERE vo.object_id = do.object_id ;

####  어떤 object에 어떤 lock이 걸렸는지 확인
SELECT  T1.object_name, DECODE(locked_mode, 2, 'ROW SHARE', 3, 'ROW EXCLUSIVE',  4, 'SHARE', 5, 'SHARE ROW EXCLUSIVE', 6, 'EXCLUSIVE', 'UNKNOWN') lock_mode
FROM  dba_objects T1, v$locked_object T2
WHERE T1.object_id = T2.object_id;

#### session 확인
select * from v$session where status = 'ACTIVE'

#### cursor 확인
v$open_cursor

#### 테이블의 lock 확인
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 ('<테이블이름>');

/*******************************************************************************
* LOCK 관련
*******************************************************************************/

--V$LOCK 을 사용한 잠금 경합 모니터링
SELECT s.username, s.sid, s.serial#, s.logon_time,
  DECODE(l.type, 'TM', 'TABLE LOCK',
         'TX', 'ROW LOCK',
      NULL) "LOCK LEVEL",
  o.owner, o.object_name, o.object_type
FROM v$session s, v$lock l, dba_objects o
WHERE s.sid = l.sid
AND o.object_id = l.id1
AND s.username IS NOT NULL   

--락이 걸린 세션 자세히 알아보기
select a.sid, a.serial#,a.username,a.process,b.object_name,
decode(c.lmode,2,'RS',3,'RX',4,'S',5,'SRX',8,'X','NO') "TABLE LOCK",
decode (a.command,2,'INSERT',3,'SELECT',6,'UPDATE',7,'DELETE',12,'DROP TABLE',26,'LOCK TABLE','UNknown') "SQL",
decode(a.lockwait, NULL,'NO wait','Wait') "STATUS"
from v$session a,dba_objects b, v$lock c
where a.sid=c.sid and b.object_id=c.id1
and c.type='TM'

--락이 걸린 세션 간단히 알아보기
select a.sid, a.serial#, b.type, c.object_name, a.program, a.lockwait,
      a.logon_time, a.process, a.osuser, a.terminal
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';

select a.sid, a.serial#, a.username, a.process, b.object_name
from v$session a , dba_objects b, v$lock c
where a.sid=c.sid and b.object_id = c.id1
and c.type = 'TM'

--락이 걸린 세션을 찾아 내어 세션을 죽이려고 해도 죽지 않는 경우
--아래 쿼리문으로 OS단의 PROCESS ID를 찾아내어 OS에서 죽인다
--kill -9 프로세스아이디
select substr(s.username,1,11) "ORACLE USER", p.pid "PROCESS ID",
s.sid "SESSION ID", s.serial#, osuser "OS USER",
p.spid "PROC SPID",s.process "SESS SPID", s.lockwait "LOCK WAIT"
from v$process p, v$session s, v$access a
where a.sid=s.sid and
p.addr=s.paddr and
s.username != 'SYS'

--위 쿼리문의 결과가 있다면 락이 걸린 세션이 있다는것이므로 아래의 쿼리문으로 세션을 죽인다
ALTER SYSTEM KILL SESSION '11,39061'

/**************************************************************************************/

출처 : http://cocoroworld.com/blog/root/entry/오라클-락lock

/oracle>ps -ef |grep ora_ | sort
  oracle 3035324       1   2 09:17:01      -  1:56 ora_p000_SID 
  oracle 3162554       1   0   Aug 09      - 79:05 ora_mman_SID
  oracle 3235916       1   2 09:17:01      -  1:58 ora_p003_SID 
  oracle 3260664       1   0 09:17:01      -  0:55 ora_p007_SID 
  oracle 3322148       1   6 09:17:01      -  1:57 ora_p002_SID 
  oracle 3363190       1   1 09:17:01      -  1:55 ora_p001_SID 
  oracle 3523008       1   0 09:17:01      -  0:53 ora_p006_SID 
  oracle 3789048       1   0 09:17:01      -  0:56 ora_p005_SID 
  oracle 4227120 4100588   0 09:25:29  pts/5  0:00 grep ora_
  oracle 4345864       1   0   Aug 09      - 11:48 ora_arc0_SID 
  oracle 4370548       1   3   Sep 25      - 65:44 ora_j000_SID
  oracle 4382828       1   0 09:17:01      -  0:55 ora_p004_SID 
  oracle 4538568       1   0   Aug 09      -  0:06 ora_s000_SID 
  oracle 4575314       1 111   Aug 09      - 11929:31 ora_pmon_SID 
  oracle 4640950       1   0 09:10:51      -  0:00 ora_j003_SID 
  oracle 4657256       1   0   Aug 09      - 130:00 ora_mmnl_SID 
  oracle 4747466       1   0   Aug 09      - 41:08 ora_mmon_SID 
  oracle 4833430       1   0   Aug 09      - 12:44 ora_cjq0_SID 
  oracle 4862174       1   0   Aug 09      -  0:11 ora_reco_SID
  oracle 4890774       1   0   Aug 09      - 44:39 ora_smon_SID 
  oracle 4902992       1   0   Aug 09      - 45:36 ora_ckpt_SID 
  oracle 4931766       1   3   Aug 09      - 1322:01 ora_lgwr_SID 
  oracle 4939910       1   0   Aug 09      - 74:27 ora_dbw3_SID 
  oracle 4985182       1   0 09:05:51      -  0:01 ora_j002_SID 
  oracle 5050588       1   1   Aug 09      - 75:52 ora_dbw2_SIDA
  oracle 5083328       1   0   Aug 09      -  3:16 ora_psp0_SID 
  oracle 5157280       1   0   Aug 09      -  0:03 ora_d000_SID 
  oracle 5374404       1   0   Aug 09      - 13:39 ora_arc1_SID 
  oracle 5423472       1   0   Aug 09      - 78:26 ora_dbw0_SID 
  oracle 5431770       1   0   Aug 09      - 76:49 ora_dbw1_SID

== 백업 ==

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[공백][디비명] < [파일명]

'Database > Mysql' 카테고리의 다른 글

mysql 테이블과 인덱스 설계 시 주의사항 13가지  (0) 2015.06.23
프로시저의 예  (0) 2011.01.26
load data  (0) 2010.07.19
mysql replication error  (0) 2010.06.28
LOAD XML Syntax [v5.5]  (0) 2010.04.07

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

+ Recent posts