BULK COLLECT의 LIMIT 값은 얼마가 적당한가
관행처럼 쓰는 100은 안전하지만 보수적이다. 메모리와 왕복 횟수의 절충점을 실제로 재서 정하는 방법과, FORALL 에러 처리까지.
Oracle PL/SQL
쿼리 튜닝
NOT IN에 NULL이 하나 섞이면 결과가 0건이 된다
NOT IN과 NOT EXISTS는 대개 같은 결과를 낸다. 그런데 비교 대상에 NULL이 하나라도 있으면 NOT IN은 에러 없이 0건을 반환한다. 이유와 대응.
운영 자동화
배치를 다시 돌려도 되게 만드는 법 — 멱등성 설계
절반쯤 처리하다 죽은 배치를 재실행해도 안전한가. 누적 대신 확정값, 처리 상태의 데이터화, 유일 제약으로 재실행 걱정을 없애는 설계.
MSSQL
같은 프로시저가 느려졌다 빨라졌다 하는 이유 — 파라미터 스니핑
코드도 인덱스도 그대로인데 프로시저가 어떤 날은 0.1초, 어떤 날은 30초다. 플랜 캐시가 첫 파라미터 값에 맞춰 세운 계획을 계속 쓰기 때문이다.
Oracle PL/SQL
WHEN OTHERS THEN NULL이 배치를 조용히 망가뜨리는 방식
예외를 삼키면 배치가 안 죽는 게 아니라 죽은 것이 안 보이게 된다. 데이터가 중간 상태로 남는 이유와, 자율 트랜잭션을 쓴 올바른 로깅 패턴.
쿼리 튜닝
인덱스가 있는데 안 타는 다섯 가지 흔한 이유
인덱스를 만들었는데 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분째에 죽은 진짜 원인과, 루프 안 커밋을 걷어내며 배치 시간까지 줄인 과정.