SQLP
시험 직전 요약장
판단 기준과 헷갈리는 개념, 대표 예제를 짧게 확인하세요.
Undo의 원리와 운영: Rollback·Read Consistency·AUM·ORA-01555
원래 이론 →판단 기준
표를 좌우로 밀어 나머지 열을 확인하세요. 키보드: ←·→, Home·End
| 혼동하기 쉬운 판단 | 정확한 기준 |
|---|---|
| Undo는 Rollback에만 사용 | Rollback·Transaction Recovery·Read Consistency와 Flashback 지원에 사용 |
| Redo는 변경 전 값을 저장 | Redo는 변경을 재현할 정보, Undo는 이전 상태 복원 정보 |
| COMMIT하면 Undo가 즉시 불필요 | 긴 Query와 Flashback이 Commit된 Undo를 사용할 수 있음 |
UNDO_RETENTION=3600이면 항상 1시간 보존 | Best-Effort 목표이며 Fixed Size·Autoextend 한도·Guarantee와 TUNED_UNDORETENTION을 함께 확인 |
| Guarantee를 켜면 Undo 공간 문제가 해결 | Unexpired Undo를 보호하는 대신 새 DML이 공간 부족으로 실패할 수 있음 |
| ORA-01555는 긴 Query이므로 Commit 횟수를 늘리면 해결 | 필요한 Undo Chain 재사용 여부, Query Plan·Fetch 시간·Undo 발생률·Tablespace 크기를 함께 진단 |
USED_UBLK가 큰 Session은 즉시 종료 대상 | 업무 중요도·진행률·Rollback 비용·Blocking 여부를 함께 판단 |
| Undo는 장기 보관용 과거 데이터 저장소 | 순환 재사용되는 내부 복구·일관성 구조 |
헷갈리는 개념
표를 좌우로 밀어 나머지 열을 확인하세요. 키보드: ←·→, Home·End
| 구분 | Undo | Redo |
|---|---|---|
| 핵심 목적 | 변경 취소·과거 버전 재구성 | 장애 후 변경 재적용 |
| 대표 사용 | ROLLBACK, Read Consistency, 미완료 Transaction 정리 | Instance Recovery, Media Recovery |
| 기록 내용 | 변경 전 상태를 복원할 정보 | 변경 작업을 재현할 Change Vector |
| 주요 저장 위치 | Undo Segment·Undo Tablespace | Redo Log Buffer·Online Redo Log |
| COMMIT 이후 | 긴 Query·Flashback을 위해 일정 기간 필요할 수 있음 | Commit 내구성을 위해 LGWR가 기록 |
Instance 장애 후 복구는 개념적으로 다음 순서로 이해할 수 있습니다.
도식좌우로 이동해 전체 내용을 확인하세요. 키보드: ←·→, Home·End
Redo 적용
→ Datafile에 반영되지 않았던 변경 재현
→ 이 과정에는 Commit된 변경과 미완료 변경이 함께 포함될 수 있음
Undo 적용
→ 장애 시점에 끝나지 않은 Transaction의 변경 취소
Redo는 Undo Segment Block과 Transaction Table의 변경도 보호합니다. 따라서 Roll Forward 과정에서 필요한 Undo 구조도 재생성할 수 있습니다. 그 뒤 Transaction Recovery가 Undo를 적용해 미완료 변경을 취소합니다. Redo만으로는 미완료 Transaction을 제거할 수 없고, Undo만으로는 장애 후 Commit된 변경을 재현할 수 없습니다.
내 최근 연습 오답
현재 브라우저의 연습 채점 기록에서 공개된 단원과 연결된 오답을 확인합니다.
오답 기록을 확인하고 있습니다.