Oracle DB 데이터 가 비정상적 으로 닫 힌 경우

우선 데이터베이스 가 정상적으로 닫 힌 상황 을 살 펴 보 겠 습 니 다.

SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup mount;
ORACLE instance started.
Total System Global Area 6680915968 bytes
Fixed Size                  2213936 bytes
Variable Size            3758098384 bytes
Database Buffers         2885681152 bytes
Redo Buffers               34922496 bytes
Database mounted.
SQL> alter session set events 'immediate trace name controlf level 12';
Session altered.
***************************************************************************
DATABASE ENTRY
***************************************************************************
 (size = 316, compat size = 316, section max = 1, section in-use = 1,
  last-recid= 0, old-recno = 0, last-recno = 0)
 (extent = 1, blkno = 1, numrecs = 1)
 12/16/2014 13:08:14
 DB Name "ORCL"
 Database flags = 0x00404001 0x00001200
 Controlfile Creation Timestamp  12/16/2014 13:08:14
 Incmplt recovery scn: 0x0000.00000000
 Resetlogs scn: 0x0000.000e6c20 Resetlogs Timestamp  12/16/2014 13:08:16
 Prior resetlogs scn: 0x0000.00000001 Prior resetlogs Timestamp  08/15/2009
 00:16:43
 Redo Version: compatible=0xb200000
 #Data files = 5, #Online files = 5
 Database checkpoint: Thread=1 scn: 0x0000.0027157c
 Threads: #Enabled=1, #Open=0, Head=0, Tail=0

 데이터베이스 항목 에서 Database checkpoint: Thread = 1 scn: 0x00000027157c 는 데이터베이스 의 종료 검사 점 을 표시 합 니 다.

***************************************************************************
REDO THREAD RECORDS
***************************************************************************
 (size = 256, compat size = 256, section max = 8, section in-use = 1,
  last-recid= 0, old-recno = 0, last-recno = 0)
 (extent = 1, blkno = 9, numrecs = 8)
THREAD #1 - status:0xe thread links forward:0 back:0
 #logs:3 first:1 last:3 current:3 last used seq#:0x8d
 enabled at scn: 0x0000.000e6c20 12/16/2014 13:08:16
 disabled at scn: 0x0000.00000000 01/01/1988 00:00:00
 opened at 12/31/2014 18:02:29 by instance orcl
Checkpointed at scn:  0x0000.0027157c 01/12/2015 17:00:59
 thread:1 rba:(0x8d.f96.10)

Redo Thread Records 에서 scn 에서 체크 포인트 확인:  0x0000.0027157c 01/12/2015 17:00:59

***************************************************************************
DATA FILE RECORDS
***************************************************************************
 (size = 520, compat size = 520, section max = 100, section in-use = 5,
  last-recid= 37, old-recno = 0, last-recno = 0)
 (extent = 1, blkno = 11, numrecs = 100)
DATA FILE #1: 
  name #7: /DBBK/oracle/oradata/orcl/system01.dbf
creation size=0 block size=8192 status=0xe head=7 tail=7 dup=1
 tablespace 0, index=1 krfil=1 prev_file=0
 unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00
 Checkpoint cnt:242 scn: 0x0000.0027157c 01/12/2015 17:00:59
 Stop scn: 0x0000.0027157c 01/12/2015 17:00:59
 Creation Checkpointed at scn:  0x0000.00000007 08/15/2009 00:16:48
 thread:0 rba:(0x0.0.0)

 
Data File Records 에서 Checkpoint 와 Stop 기록 보기
Checkpoint cnt:242 scn: 0x0000.0027157c 01/12/2015 17:00:59Stop scn: 0x0000.0027157c
이 표 의 이름 은 데이터베이스 가 정상적으로 shutdown 되 었 을 때 실제로 CKPT 가 발생 했 기 때문에 Checkpoint scn 은 Stop scn 과 일치 합 니 다.
정상적으로 닫 히 기 때문에 데이터베이스 후속 작 동 은 정상적으로 진 행 될 것 이다.
 
데이터베이스 가 비정상적 으로 닫 힌 경우

SQL> ALTER SYSTEM SWITCH LOGFILE;
System altered.
SQL> shutdown abort;
ORACLE instance shut down.
SQL> startup mount;
ORACLE instance started.
Total System Global Area 6680915968 bytes
Fixed Size                  2213936 bytes
Variable Size            3758098384 bytes
Database Buffers         2885681152 bytes
Redo Buffers               34922496 bytes
Database mounted.
SQL> alter session set events'immediate trace name controlf level 12';
SQL> @?/gettrcname
TRACE_FILE
--------------------------------------------------------------------------------
/DBBK/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_31004.trc

추적 로그 보기

***************************************************************************
DATABASE ENTRY
***************************************************************************
 (size = 316, compat size = 316, section max = 1, section in-use = 1,
  last-recid= 0, old-recno = 0, last-recno = 0)
 (extent = 1, blkno = 1, numrecs = 1)
 12/16/2014 13:08:14
 DB Name "ORCL"
 Database flags = 0x00404001 0x00001200
 Controlfile Creation Timestamp  12/16/2014 13:08:14
 Incmplt recovery scn: 0x0000.00000000
 Resetlogs scn: 0x0000.000e6c20 Resetlogs Timestamp  12/16/2014 13:08:16
 Prior resetlogs scn: 0x0000.00000001 Prior resetlogs Timestamp  08/15/2009
 00:16:43
 Redo Version: compatible=0xb200000
 #Data files = 5, #Online files = 5
 Database checkpoint: Thread=1 scn: 0x0000.0027157f
 Threads: #Enabled=1, #Open=1, Head=1, Tail=1

데이터베이스 검사 점 정보 보기: Database checkpoint: Thread = 1 scn: 0x00000027157 f

***************************************************************************
REDO THREAD RECORDS
***************************************************************************
 (size = 256, compat size = 256, section max = 8, section in-use = 1,
  last-recid= 0, old-recno = 0, last-recno = 0)
 (extent = 1, blkno = 9, numrecs = 8)
THREAD #1 - status:0xf thread links forward:0 back:0
 #logs:3 first:1 last:3 current:1 last used seq#:0x8e
 enabled at scn: 0x0000.000e6c20 12/16/2014 13:08:16
 disabled at scn: 0x0000.00000000 01/01/1988 00:00:00
 opened at 01/12/2015 17:27:19 by instance orcl
Checkpointed at scn:  0x0000.0027157f 01/12/2015 17:27:19
 thread:1 rba:(0x8d.f96.10)

Redo 보기: scn 에서 체크 포인트 됨:  0x00000027157f 01 / 12 / 2015 17: 27: 19 여기 서 Redo 기록 에서 검사 점 검 사 를 마 쳤 다 는 것 을 설명 합 니 다.

***************************************************************************

DATA FILE RECORDS

***************************************************************************

 (size = 520, compat size = 520, section max = 100, section in-use = 5,

  last-recid= 37, old-recno = 0, last-recno = 0)

 (extent = 1, blkno = 11, numrecs = 100)

DATA FILE #1: 

  name #7: /DBBK/oracle/oradata/orcl/system01.dbf

creation size=0 block size=8192 status=0xe head=7 tail=7 dup=1

 tablespace 0, index=1 krfil=1 prev_file=0

 unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00

 Checkpoint cnt:243 scn: 0x0000.0027157f 01/12/2015 17:27:19

 Stop scn: 0xffff.ffffffff 01/12/2015 17:00:59

 Creation Checkpointed at scn:  0x0000.00000007 08/15/2009 00:16:48

 thread:0 rba:(0x0.0.0)

 
Data File Records 를 검사 할 때 Checkpoint scn 과 Stop scn 이 일치 하지 않 는 경우 가 있 음 을 발 견 했 습 니 다. 
Checkpoint cnt:243 scn: 0x0000.0027157f 01/12/2015 17:27:19
Stop scn: 0xffff. ffffff 01 / 12 / 2015 17: 00: 59 이것 은 내 가 abort 를 통 해 데이터 베 이 스 를 닫 은 후에 닫 힌 CKPT 를 진행 하지 않 았 기 때문에 buffer 의 더러 운 데 이 터 를 데이터 파일 에 쓰 지 않 았 다 는 것 을 설명 합 니 다. 따라서 데이터 파일 의 Stop scn 은 최대 값 ffff. ffffff 로 표시 합 니 다.
 
Oracle 을 Open 상태 로 시작 하고 경고 로 그 를 관찰 합 니 다. 데이터 베 이 스 는 Redo 로그 에서 기록 되 지 않 은 데이터 파일 의 기록 을 읽 을 수 있다 면 Oracle 은 인 스 턴 스 복구 (Instance Recovery) 를 자동 으로 실행 합 니 다.
인 스 턴 스 복 구 는 두 단계 Cache Recovery 와 Transaction Recovery 를 포함한다.

Beginning crash recovery of 1 threads
 parallel recovery started with 7 processes
Started redo scan
Completed redo scan
 read 31 KB redo, 26 data blocks need recovery
Started redo application at
 Thread 1: logseq 141, block 4690
Recovery of Online Redo Log: Thread 1 Group 3 Seq 141 Reading mem 0
  Mem# 0: /DBBK/oracle/oradata/orcl/redo03.log
Recovery of Online Redo Log: Thread 1 Group 1 Seq 142 Reading mem 0
  Mem# 0: /DBBK/oracle/oradata/orcl/redo01.log
Completed redo application of 0.01MB
Completed crash recovery at
 Thread 1: logseq 142, block 2, scn 2582016
 26 data blocks read, 26 data blocks written, 31 redo k-bytes read
--     Cache Recovery  Redo                

Mon Jan 12 17:53:18 2015
LGWR: STARTING ARCH PROCESSES
Mon Jan 12 17:53:18 2015
ARC0 started with pid=27, OS id=32295 
ARC0: Archival started
LGWR: STARTING ARCH PROCESSES COMPLETE
ARC0: STARTING ARCH PROCESSES
Thread 1 advanced to log sequence 143 (thread open)
Mon Jan 12 17:53:19 2015
ARC1 started with pid=28, OS id=32297 
Mon Jan 12 17:53:19 2015
ARC2 started with pid=29, OS id=32299 
Thread 1 opened at log sequence 143
  Current log# 2 seq# 143 mem# 0: /DBBK/oracle/oradata/orcl/redo02.log
Successful open of redo thread 1
ARC1: Archival started
Mon Jan 12 17:53:19 2015
ARC3 started with pid=30, OS id=32301 
ARC2: Archival started
ARC2: Becoming the 'no FAL' ARCH
ARC2: Becoming the 'no SRL' ARCH
ARC1: Becoming the heartbeat ARCH
Mon Jan 12 17:53:19 2015
SMON: enabling cache recovery
Archived Log entry 85 added for thread 1 sequence 142 ID 0x531a7e3e dest 1:
Successfully onlined Undo Tablespace 2.
Verifying file header compatibility for 11g tablespace encryption..
Verifying 11g file header compatibility for tablespace encryption completed
--       Transaction Recovery            。
SMON: enabling tx recovery
Database Characterset is WE8MSWIN1252
No Resource Manager plan active
replication_dependency_tracking turned off (no async multimaster replication found)
Starting background process QMNC
Mon Jan 12 17:53:20 2015
QMNC started with pid=31, OS id=32305 
Completed: alter database open
ARC3: Archival started
ARC0: STARTING ARCH PROCESSES COMPLETE
Mon Jan 12 17:53:22 2015
Starting background process CJQ0
Mon Jan 12 17:53:22 2015
CJQ0 started with pid=32, OS id=32322
Mon Jan 12 18:03:20 2015
Starting background process SMCO
Mon Jan 12 18:03:20 2015
SMCO started with pid=19, OS id=852 
Mon Jan 12 22:00:00 2015
Setting Resource Manager plan SCHEDULER[0x3003]:DEFAULT_MAINTENANCE_PLAN via scheduler window
Setting Resource Manager plan DEFAULT_MAINTENANCE_PLAN via parameter
Mon Jan 12 22:00:00 2015
Starting background process VKRM
Mon Jan 12 22:00:00 2015
VKRM started with pid=24, OS id=21736 
Mon Jan 12 22:00:02 2015
Begin automatic SQL Tuning Advisor run for special tuning task  "SYS_AUTO_SQL_TUNING_TASK"
End automatic SQL Tuning Advisor run for special tuning task  "SYS_AUTO_SQL_TUNING_TASK"

 이 복구 과정 에서 오 라 클 은 두 가지 특성 으로 회복 의 효율 을 높 였 다.Fast - Start On - Demand Rollback 과 Fast - Start Parallel Rollback.
Fast - Start On - Demand Rollback 의 특징 으로 데이터 베 이 스 를 열 고 새로운 사 무 를 사용 할 수 있 습 니 다. 이것 은 보통 짧 은 Cache Recovery 시간 만 필요 합 니 다.사용자 보기 가 프로 세 스 가 잠 겨 있 는 기록 에 접근 하지 않 으 면 Oracle 은 새로운 사 무 를 요청 하 는 기록 을 되 돌려 줍 니 다.... 에 있다 Fast - Start On - Demand Rollback 에 서 는 백 엔 드 프로 세 스 SMON 이 스케줄 러 역할 을 하 며 여러 프로 세 스 를 병렬 스크롤 백 트 랜 잭 션 으로 사용 합 니 다.
Fast - Start Parallel Rollback 은 제출 되 지 않 은 업 무 를 장시간 실행 하 는 데 유효 합 니 다.특히 INSERT, DELETE, UPDATE 를 병행 하 는 데 효과 가 있다.SMON 은 제출 하지 않 은 사 무 를 언제 되 돌 릴 지 자동 으로 결정 하고 다 중 프로 세 스에 서 분산 작업 을 합 니 다.
 
Fast - Start Parallel Rollback 의 특수 한 형식 은 내부 트 랜 잭 션 복구 (Intra - Transaction Recovery) 가 내부 트 랜 잭 션 복구 에서 큰 트 랜 잭 션 을 분리 하여 여러 서비스 프로 세 스에 할당 하여 병렬 스크롤 백 을 할 수 있 습 니 다.
패스 트start_parallel_rollback 매개 변 수 는 병렬 스크롤 백 을 제어 합 니 다. 이 매개 변 수 는 세 개의 값 이 있 습 니 다.
FALSE  fast 사용 금지start_parallel_rollback
LOW 복구 프로 세 스 제한 cpucount*2
HIGH 제한 복구 프로 세 스 cpu 를 초과 할 수 없습니다count*4