[Oracle Architecture][2015 04-24] Bblock Cleanout and Snapshot Too Old

1. WareValley
http://www.WareValley.com
Database Audit and Protection [ DB 접근통제 ]
Database Encryption [ DB 암호화 ]
Database Vulnerability Assessment [ DB 취약점 분석 ]
Database SQL Query Approval [ DB 작업결재 ]
Database Performance Monitoring and Management [ DB 성능관리 및 개발 ]
WareValley
Oracle Architecture
Block Cleanout & Snapshot too old
오렌지팀 윤석준 선임연구원

2. Database security and management, WareValley.
http://www.WareValley.com
Block Cleanout

3. Database security and management, WareValley.
http://www.WareValley.com
Block Cleanout
 Delayed Block Cleanout
- Transaction에서 갱신한 Block이 총 Buffer Cache Block의 10%를 초과할 경우
- Commit 이후 해당 Block을 액세스 하는 첫 번째 Query에 의해 Cleanout 수행
=> 즉, SELECT 문에 의해서 Current Block에 Writing을 수행한다는 말임
 Commit Cleanout (= Fast Block Cleanout)
- Buffer Cache Block의 10%를 넘지 않을 경우
- Commit 시점에 불완전한 형태의 Cleanout 수행 : Online Redo Log를 남기지 않음
- 해당 Block에 대해서 갱신(DML)을 수행하는 다음 Transaction 에 의해 수행 : Log 수행
 Transaction에 의해 설정된 Row Lock을 해제하고,
Block Header에 Commit 정보를 기록하는 동작

4. Database security and management, WareValley.
http://www.WareValley.com
Snapshot too old

5. Database security and management, WareValley.
http://www.WareValley.com
발생원인
1. Undo Segment 의 Size가 너무 작을 경우
Query SCN 이후 Block이 변경됨
‘Read Consistent’ Image를 만들어야 하는데…
이미 다른 Transaction이 덮어 썼다면 ?
Undo Block에 해당 정보를 얻어야 하는데…
2. Undo Segment 의 개수가 너무 적을 경우
Commit 된 Transaction Table Slot에 확인할 정보가 있는데
이미 다른 Transaction에 의해 재사용되고 있다면 ?

6. Database security and management, WareValley.
http://www.WareValley.com
발생상황 #1 Undo 실패
SELECT /*+ ordered use_nl(b) */ A.고객ID
, NVL(SUM(과금액), 0) 과금액
, NVL(SUM(수납액), 0) 수납액
, NVL(SUM(과금액), 0) - NVL(SUM(수납액), 0) 미납액
FROM 과금 A, 수납 B
WHERE A.과금년월 = :과금년도
AND A.과금유형 = :과금유형
AND A.고객ID = B.고객ID(+)
AND A.과금년월 = B.수납년월(+)
GROUP BY A. 고객ID
1. 1시간 걸리는 Query 실행 : SCN 123
2. 고객입금 내역을 일괄처리하는 Batch
Program 수행 (건 별로 Commit)
‘홍길동’ 고객에 대한 수정 SCN 129
1. 대량의 Data를 Driving Table (과금) 으로 Nested Loop Join (use_nl)을 하면 시간이 오래 걸림
2. Inner Table (수납) 에 대해 같은 Block을 반복해서 방문할 가능성이 커짐
3. 입금내역 Batch Program의 Commit 건수가 너무 많음 (1건당 1 Commit)
3. SCN 129의 정보가 담긴 Undo Block이 다른 Transaction에 의해 재사용
4. 위 Query가 Current Block에서 ‘Read Consistent’ Image를 생성하여 하였으나,
5. Undo Block에 정보가 없음
 문제점

7. Database security and management, WareValley.
http://www.WareValley.com
발생상황 #2 Block Cleanout 실패
최저 Commit SCN이 Query SCN보다 훨씬 높아
질 정도로 갑자기 Transaction이 몰릴 경우
최저 Commit SCN : Transaction Slot이 필요할 때 재사용한 Commit SCN을 기록

8. Database security and management, WareValley.
http://www.WareValley.com
회피
난감해서 어렵다.
재현이 어렵다.
원인을 찾기가 어렵다.
0%로 줄이기가 어렵다.

9. Database security and management, WareValley.
http://www.WareValley.com
Oracle의 노력
 태초의 Oracle에서는…
DBA가 다 알아서 해야만 했다.
Undo Segment를 DBA가 수동으로 관리
 9i AUM (Automatic Undo Management)
Transaction 발생 상황에 따라 Undo Segment를 자동 조절
DBA는 Undo 정보가 오래 보존 되도록 큰 Undo Space 준비가 끝.
(가장 오랜 시간 수행되는 Query 기준)
 10g undo_retention auto tuning
undo_retention : 지정된 시간동안 Transaction이 종료되었어도 관련 Undo Segment 재사용 불가
DBA는 머하지 ???

10. Database security and management, WareValley.
http://www.WareValley.com
개발자의 노력
1. 불필요한 Commit 자제
Commit 횟수를 줄이자
2. Fetch across commit 프로그램 자제
Commit 이전에 열려있던 Cursor의 Fetch를 피하자.
그거없이 못살겠으면 Commit 횟수라도 줄이자.
3. Transaction 몰리는 시간에 오래 걸리는 Query 자제
스케줄러를 조정하자.
4. 큰 Table을 부분 처리 유도
부분 처리되도록 Query를 짜던지, Query 자체를 나누던지 (단, 그렇게 해도 일관성 문제가 없다면)
5. Nested loop join 및 Index를 경유한 Table Access 사용 자제
오랜 시간 같은 Block을 반복해서 사용하는 Query라면, Join 변경을 하던지, 차라리 Full Table Scan 해버리던지
6. Order by를 이용하여 Sort 연산 강제 발생
Server 내에서 빠르게 읽어서 Temp Segment에 저장하면 이후 같은 Block을 여러 번 읽어도 OK
7. Delayed block cleanout이 의심되면 -> 대량 Update 후 Table Full Scan
SELECT /*+ full(t) */ COUNT(*) FROM table_name t
8. Index가 문제라 의심되면 -> Index leap block을 Scan하도록 Query 수정
SELECT COUNT(*) FROM table_name WHERE index_column > 0