인덱스가 있는데 안 타는 다섯 가지 흔한 이유
인덱스를 만들었는데 FULL SCAN이 찍힌다. 컬럼 가공, 암묵적 형변환, 선두 컬럼 누락, 부정 조건, NULL 검색까지 자주 나오는 다섯 가지와 각각의 해법.
쿼리 튜닝
운영 자동화
DBMS_SCHEDULER 잡이 실패했는데 로그가 비어 있을 때
잡은 실패 상태인데 원인이 어디에도 없다. 시작이 안 된 것인지, 실패한 것인지, 끝나지 않는 것인지부터 가르고 각각에 맞는 딕셔너리 뷰를 본다.
MSSQL
NOLOCK을 붙이기 전에 알아야 할 것 — 더티 리드보다 무서운 두 가지
NOLOCK은 락을 안 거는 힌트가 아니라 격리 수준을 낮추는 선택이다. 더티 리드뿐 아니라 같은 행을 두 번 읽거나 아예 빠뜨리는 일이 에러 없이 발생한다. 대안은 RCSI다.
쿼리 튜닝
통계정보는 최신인데 쿼리가 갑자기 느려졌다 — 바인드 변수 피킹
코드도 인덱스도 그대로인데 같은 쿼리가 어느 날 8초가 된다. 옵티마이저가 첫 실행의 바인드 값을 엿보고 만든 계획이 재사용되기 때문이다. 확인 쿼리와 대응 선택지.
Oracle PL/SQL
MERGE 문이 ORA-30926으로 죽을 때 — 원인은 거의 항상 하나다
unable to get a stable set of rows in the source tables. 메시지는 모호하지만 원인은 하나다. USING 집합이 ON 키 기준으로 유일하지 않은 것. 진단 쿼리와 세 가지 해결 패턴.
운영 자동화
HL7 메시지를 DB에서 파싱할 때 실제로 터지는 것들
네 번째 장비를 붙이자 필드가 한 칸씩 밀려 들어갔다. 구분자 하드코딩, 이스케이프 시퀀스, 세그먼트 구분자와 문자셋까지 HL7 파서에서 실제로 터진 지점들.
쿼리 튜닝
인덱스를 탔는데도 3초 — 실행계획에서 실제로 봐야 하는 두 줄
INDEX RANGE SCAN이 찍혔는데도 쿼리가 3초 걸렸다. 실행계획에서 operation 이름 대신 A-Rows와 Predicate Information을 보면 원인이 바로 드러난다.
Oracle PL/SQL
야간 배치가 2시간 40분째에 죽는다 — ORA-01555와 커밋의 함정
ORA-01555는 UNDO 공간이 부족해서 나는 에러가 아니다. 야간 집계 배치가 매번 2시간 40분째에 죽은 진짜 원인과, 루프 안 커밋을 걷어내며 배치 시간까지 줄인 과정.