ORACLE - Instance 및 Media Recovery 구조

Instance 및 Media Recovery 구조

---

[그림 1]

▶Dynamic View

• Database 및 Instance에 대한 정보 얻기
  • V$SGA
  • V$INSTANCE
  • V$PROCESS
  • V$BGPROCESS
  • V$DATABASE
  • V$DATAFILE

▶LARGE POOL

• SGA의 개별 메모리 영역으로 구성될 수 있으며, 다음 목적으로 사용된다.
  • Oracle Backup 및 Restore 작업
    • 백업이라는 것은, 제어파일 데이터파일, 리두로그 파일을 복사해놓는 것을 의미합니다.
    • 이때 I/O 과정이 일어나는데, 그 과정 중 LARGE POOL을 사용합니다.(Recovery Manager사용시)
  • I/O Server Process
  • Shared Server용 세션 메모리 (UGA)
• LARGE_POOL_SIZE Parameter에 의해 크기가 조절된다.

▶Data Buffer Cache, DBWn 및 Data Files

▶Redo Log Buffer, LGWR 및 Redo Log Files

• Redolog 는 DML이 작성될때만 동작합니다.
• 오라클 서버는 DDL을 내장 SQL을 통해 처리합니다.
• 데이터 딕셔너리도 하나의 테이블이므로, 사용자가 테이블을 생성(CREATE), 변경(ALTER)등을 하게되면, 리두로그에는 UPDATE로 지정되어 기록됩니다. (왜냐면, 데이터딕셔너리를 업데이트 하는 것이므로)
• 리두로그 파일은 순환적으로 사용됩니다. 개수를 늘리지 않고, 기존에 고정된 개수만을 가지고 돌려가며 사용합니다.
• 온라인 리두로그 파일은 다음의 리두로그 정보가 차기전까지만 재사용이 가능합니다.
• 이 리두로그의 파일의 목적은 오로지 복구를 위한 것임을 명시해주세요.

▶다중화된 Redo Log Files

• 복구를 위한 정보가 들어가있는 리두로그의 정보가 손상되면 안됩니다.
• 따라서 동일한 정보가 가지고 있는 여러개의 리두로그 그룹(멤버가 모이면)을 다른 디스크에 각 그룹의 멤버끼리 떼어놓고 다중화를 시켜야 합니다.

▶Database Checkpoint

• Checkpoint는 Recovery가 시작될 위치를 결정하는데 사용된다.
• Checkpoint 위치 – Recovery 시작 위치
• Checkpoint Queue – Dirty Block의 연결 목록
• 더티리스트를 저장하기 위한 큐 입니다. 이 큐의 임계치가 도달하면 DBWR이 Dirty Block 를 내려쓰기 위한 목록입니다.

▶Checkpoint 유형

• Full Checkpoint - 인스턴스 메모리에 모든 내용이 기록되어야 하는 작업(Shutdown 시)
  • 모든 Dirty Buffer 기록
  • SHUTDOWN NORMAL, IMMEDIATE, TRANSACTIONAL
  • ALTER SYSTEM CHECKPOINT
• Incremental Checkpoint (Fast-Start Checkpoint)
  • 주기적으로 기록
  • 리두로그의 체크포인트 파라미터를 사용했던 것처럼, 이전 체크포인트 후에 추가적으로 부분적으로 더티 블록들이 내려오는 것입니다.
• Partial Checkpoint
  • Tablespace에 속하는 Dirty Buffer
  • ALTER TABLESPACE …. BEGIN BACKUP - DB 운영중에 DB를 백업하는 방식
  • ALTER TABLESPACE ….OFFLINE NORMAL - 특정 테이블스페이스와 관련된 작업
  • 테이블 스페이스와 관련된 작업입니다.

▶CKPT Process

• 체크포인트 작업을 주관하는 프로세스
• 체크포인트가 완료될때마다 데이터파일과 제어파일의 헤더를 갱신해줍니다.

▶다중화된 Control Files

• 데이터베이스를 운영할 때 필요한 최소의 데이터파일은 1개 입니다.
• 제어파일이 손상되면 DB를 운영할 수 없으므로 최소한 2개이상 복사본이 있어야 합니다.
  

▶Control file 내용 - 2진 파일이므로 운영체제 상에서는 읽을 수 없습니다.

• Database 이름
• Database 생성된 시간기록
• Recovery에 필요한 동기화 정보(Checkpoint 및 Log Sequence 정보)
• Datafile과 Redo log file 이름과 위치
• Database의 Archive 모드
• 현재 Log Sequence Number
• Recovery Manager Backup meta Data

▶ARCn Process 및 Archived Log Files

• 미디어가 손상되었을 때는 완벽하게 지원하지 못합니다.
• 따라서 이 프로세스및 아카이브 로그 파일들은 리두로그에 대한 모든 버전을 백업해 놓습니다.
• 아카이브 로그 파일은 동적으로 계속 늘어날 수 있습니다. 트랜잭션이 클 수록 로그 파일은 많이 증가하게 됩니다.

▶Database 동기화 - CheckPoint

• Database Open을 위해서는 모든 동기화 된 Datafile이 필요하다.(Offline/Read Only 제외)
• 파일이 읽기전용상태이거나, 파일이 꺼져있을 때는 CKPT가 정보 갱신을 하지 못합니다.
• 동기화는 현재의 Checkpoint 번호를 기반으로 한다.
• Redo log file에 기록된 변경사항을 적용하면 Datafile이 동기화된다.
• Redo log file은 Oracle Server에 의해 자동으로 요청된다.

▶Phases for Instance Recovery (인스턴스 복구 단계)

▶Crash 및 Instance Recovery 성능 튜닝

• Instance 및 Crash Recovery 기간 튜닝
• Instance Recovery 단계 튜닝

▶Instance 및 Crash Recovery의 기간 튜닝

Instance 및 Crash Recovery의 기간을 User가 지정한
범위로 유지하는 방식 :

• 초기화 Parameter 를 설정하여 Recovery에 포함된 Redo log 레코드와 Data Block 수에 영향을 줌
• Redo log file의 크기를 조정하여 Checkpoint 빈도에 영향을 줌
• SQL문을 실행하여 Checkpoint 시작
• Instance Recovery 작업 병렬화

▶Checkpoint에 영향을 주는 초기화 Parameter

▶V$INSTANCE_RECOVERY

• Recovery I/O를 제한하는데 사용할 수 있는 방식 모니터에 사용됨
• 이 뷰의 통계를 사용하여 Checkpoint에 가장 큰 영향을 주는 Parameter 계산

▶Crash 및 Instance Recovery 단계 튜닝

• Rollforward 단계 튜닝
  • 병렬 Block Recovery
  • RECOVERY_PARALLELISM 동시 Recovery Process의 수를 지정
    
• Rollback 단계 튜닝
  • Fast-start On-demand Rollback
  • Fast-start 병렬 Rollback

▶CKPT와 인스턴스 리커버리

• 만약에, 500m 중에서 200m 단위로 체크포인트를 했었다면, RBA는 80m 위치를 가리키고 있었을 것이고, 결론적으로 80m만 복구해주면 되는 것입니다.
• CheckPoint
• Shutdown -abort 를 제외한 종료
• Log Switch
• Parameter
• log_checkpoint_interval
• log_checkpoint_timeout
• ▲위의 2가지는 Oracle 8 버전까지 사용하면서 제어를 했습니다.
• # 위의 파라미터는 SGA에 적재되어있던 Dirty의 정보는 제어하지 못합니다.
• # 따라서 복구시에 Dirty에 얼마나 있었냐에 따라 Startup 시간이 달라질 수 있습니다.
• # 아무리 파라미터를 가지고 체크포인트 옵션을 정의해주더라도, 데이터베이스가 빠쁠 시간에는 15분마다 일어난다고 할때 이전에 정의했던 timeout 옵션은 사용되지 않습니다(시간을 30분이라고 지정했을 경우)
• # 데이터베이스가 바쁘지 않을 경우에는 굳이 체크포인트를 할 필요가 없는데도 불구하고, 계속 정해진 시간마다 체크포인트를 하기 때문에, 오히려 운영상의 성능에는 효과가 떨어집니다.
• # 따라서, DBA는 이러한 성능 제어를 원활하게 해주어야 합니다
• 이러한 문제로 인해, 8i 버전에서는 fast_start_io_target 이라는 파라미터가 추가 되었습니다.
• 즉, 이것은 SGA에 적재된 Dirty의 정보를 계산해놓도록 합니다.
• 9i 부터는 다음의 파라미터가 추가 됩니다.
• Fast_Start_MTTR_Target
• 인스턴트 장애시 보다 빠른 시작을 위해서 복구시간을 지정할 수 있습니다.
• 이 파라미터는 설정된 시간에 따라 나머지 파라미터를 자동으로 제어합니다.
• 이 파라미터를 설정하면 기존 8 및 8i에 정의된 파라미터는 설정하면 안됩니다.
• 하지만, 어떤 시스템에서 운영하느냐에 따라서 이 값은 달라져야 합니다.
• 이 값은 오라클이 나중에는 알아서 셀프튜닝을 해놓고 v$ 뷰에 값을 제시해 놓습니다. 이 값을 사용하면 되겠죠 ^^
• 하지만 10g에서는 이러한 파라미터를 아예 사용하지 않도록 합니다. 오라클서버 스스로 해주겠다 이거죠. 으흐흐흐흐흐흐흐흐흐
• 인스턴스 리커버리 과정
• ① Roll forward. >> 완료되고 SMON이 DB를 OPEN 합니다.
• ② Rollback