• p397) 인덱스가 삭제된 이후 생성되었기 때문에 update문 실행계획 cost가 2인 것인지?
  • p399) truncate, delete 둘 다 redo 파일에 기록되는지?
  • p401) DML이 이루어 질 때마다 Redo, Undo 둘 다 기록되는 것인지?
    • TRUNCATE 의 경우 로그가 남지 않음 > DDL이므로 AUTO-COMMIT이 적용되기 때문에 COMMIT 관계없이 바로 비워짐
  • p402) MVCC모델을 사용하는 오라클의 2가지 모드: Consistent모드, Current모드
    • Current모드는 디스크에서 캐시로 적재된 원본 블록을 현재 상태 그대로 읽는 방식
    • Consistent모드는 쿼리가 시작된 이후에 다른 트랜잭션에 의해 변경된 블록을 만나면 원본 블록으루부터 복사본 블록을 만들고, 거기에 Undo 데이터를 적용함으로써 쿼리가 ‘시작된 시점’으로 되돌려서 읽는 방식
    • 자세한 내용은 ‘오라클 성능 고도화 원리와 해법’ 1권에 나옴
  • p404) Lock LEVEL: 처음엔 로우 레벨을 사용하다가 LOCK 설정 대상이 많아지면 점점 레벨을 올림 ⇒ Lock Escalation 이라고 부르는데, Oracle은 사용하지 않음
    • 로우 레벨
    • 블록 레벨
    • 익스텐트 레벨
    • 테이블 레벨
  • p405) DML이 Lock에 의해 블로킹된 경우, 커밋은 DML 성능과 직결된다
    • DB버퍼캐시
    • Redo 로그버퍼
  • p406)트랜잭션 데이터 저장 과정 순서를 알아야 머리에 잘 들어올 듯
    1. DML 문을 실행하면 Redo 로그버퍼 내용을 로그파일에 일괄 저장
      • 오라클은 DML 전 항상 로그부터 기록함
    2. 버퍼블록에서 데이터를 변경(레코드 추가/수정/삭제)한다. 물론, 버퍼캐시에서 블록을 찾지 못하면, 데이터파일에서 읽는 작업부터 한다.
    3. 커밋한다.
    4. LGWR 프로세스가 Redo 로그버퍼 내용을 로그파일에 일괄 저장한다.
      • Redo 로그를 기록하는 작업은 디스크 I/O 작업이다.
    5. DBWR 프로세스가 변경된 버퍼블록들은 데이터 파일에 일괄 저장한다.
  • 커밋을 하지 않아도 문제, 자주 해도 문제
    • 오랫동안 커밋하지 않고, 데이터를 계속 갱신하면 Undo 공간이 부족해져 시스템 장애 상황을 발생할 수 있음
    • 루프를 돌면서 건건마다 모두 커밋한다면, 프로그램 자체 성능이 느려짐 > 불필요한 커밋
    • ****DBWR, LGWR 에 대한 자세한 설명
      1. DBWR (Database Writer):
        • DBWR는 데이터베이스의 버퍼 캐시에서 변경된 블록들을 디스크에 기록하는 역할을 담당합니다.
        • 주요 역할은 디스크의 데이터 파일에 변경된 블록들을 일괄적으로 기록하여 데이터 일관성과 내구성을 보장하는 것입니다.
        • DBWR는 블록이 변경되거나 데이터베이스 버퍼 캐시에 공간이 부족해지면 해당 블록을 디스크에 쓰기 위해 작동합니다.
        • 변경된 블록은 먼저 더티(Dirty) 상태로 마킹되고, DBWR은 이러한 더티 블록들을 비동기적으로 디스크에 기록합니다.
      2. LGWR (Log Writer):
        • LGWR은 로그 버퍼의 내용을 디스크의 리도 로그 파일에 기록하는 역할을 수행합니다.
        • 로그 버퍼에는 데이터베이스에서 수행된 모든 변경 작업이 기록되어 있으며, 이를 장애 복구와 데이터 일관성을 보장하는 데 사용됩니다.
        • LGWR은 트랜잭션이 커밋될 때마다 변경된 내용을 로그 버퍼에 기록하고, 주기적으로 로그 파일에 비동기적으로 기록합니다.
        • 로그 파일에는 변경 작업의 세부 정보와 이전 상태로의 롤백에 필요한 정보가 포함되어 있습니다.
        • LGWR은 데이터베이스에 대한 지속적인 변경 작업을 보장하며, 성능을 향상시키기 위해 로그를 그룹으로 묶어 일괄 처리합니다.
  • p407) 중간 문단에 ‘서버 프로세스가 변경한 버퍼블록들을 디스크에 기록하지 않았더라도 커밋 시점에 Redo로 그를 디스크에 안전하게 기록했다면’ 의 뜻은 “DBWR가 Dirty블록들을 기록하지 않았어도, LGWR가 Redo 로그버퍼에 로그파일을 기록했다면” 이라는 말인가?
  • p409)DB Call
    • SQL은 세 단계로 나누어 실행
      • Parse Call
      • Execute Call
      • Fetch Call
    • Call 발생 경우에 따라 2가지로 나뉨, 어떤 Call이든 위 세 단계를 거침
      • User Call
        • DBMS 외부로부터 인입되는 Call
      • Recursive Call
        • DBMS 내부로부터 발생하는 Call
  • p418) 인덱스와 무결성 제약 조건을 DML 성능에 큰 영향을 끼침 > 대량 데이터를 적재하는 배치프로그램에서 큰 성능 개선 효과를 얻을 수 있음
    • 아래의 케이스 실습해보기
      • PK+Unique Index 있는 경우
      • PK+Non Unique Index
  • p437) 오라클은 버퍼캐시를 경유하지 않고 곧바로 데이터 블록을 읽고 쓸 수 있는 Direct Path I/O 기능을 제공함
    • 작동하는 경우 6가지(첫번째~세번째 가 가장 중요하고 활용도 높음)
      • 병렬 쿼리로 Full Scan 을 수행할 때
      • 병렬 DML을 수행할 때
      • Direct Path Insert를 수행할 때
      • Temp 세그먼트 블록들을 읽고 쓸 때
      • direct 옵션을 지정하고, export를 수행할 때
      • nocache 옵션을 지정한 LOB 컬럼을 읽을 때
  • p443)병렬DML 작업을 각 병렬 프로세스가 처리하는지, 아니면 QC(Query Coordinator)가 처리하는지 실행계획에서 확인 가능 > QC에 대해 별도로 찾아보는 것 필요!
    • ‘PX COORDINATOR’ 아래쪽에 DML 명령문이 있다면 각 병렬 프로세스가 처리
    • ‘PX COORDINATOR’ 위쪽에 DML 명령문이 있다면 QC가 처리
  • p446)파티션
    • 테이블 파티션
      • Range 파티션
      • 해시 파티션
      • 리스트 파티션
    • 인덱스 파티션
      • 로컬 파티션 인덱스
      • 글로벌 파티션 인덱스
      • 비파티션 인덱스 (=글로벌 비파티션 인덱스)

        • 일반적으로 생성하여 사용하는 인덱스

        • 로컬 비파티션 인덱스는 존재하지 않는다는 뜻??

  • p453) 테이블 파티션 구성이 변경되면, 물리적인 적재 장소가 바뀌어서 비파티션 인덱스가 비활성화 처리 된다는 뜻? row의 DBA가 바뀌는것?
  • p453) 글로벌 파티션 인덱스는 항상 Prefixed 인덱스
  • p456)온라인 상태로 파티션 구조를 빠르게 변경하려면 모든 인덱스가 로컬 파티션 인덱스여야 한다. >> 글로벌 인덱스가 하나라도 있으면 얼마나 느려질지?