Quiz: What You Write Before You Write

고객이 문장으로 보낸 변경 요청을 SQL 조건으로 옮기기 전에 가장 먼저 할 일은?

• 요청한 담당자에게 서면 승인을 먼저 받는다
• 테이블 전체를 파일로 백업해 둔다
• 요청대로 옮겼을 때 실제로 몇 행이 바뀌는지 먼저 센다
• 변경을 트랜잭션으로 감싸 두고 바로 실행한다

시험 실행을 트랜잭션 안에서 UPDATE 한 뒤 ROLLBACK 하는 방식으로 하는 이유는?

• 실행 계획을 미리 만들어 두어 본 적용을 빠르게 하려고
• 세는 조건과 바꾸는 조건이 문자 그대로 같아지기 때문에
• 롤백한 트랜잭션은 감사 로그에 남지 않기 때문에
• COUNT 로 세는 것보다 잠금을 덜 잡기 때문에

변경 전에 파일 사본만 남기고 행 스냅샷을 남기지 않으면 무엇이 어려워지는가?

• 되돌리는 일 자체가 불가능해져 변경을 실행할 수 없다
• 백업 파일이 커져서 복원에 시간이 오래 걸리게 된다
• 트랜잭션 격리 수준을 높게 잡아야만 복원이 가능해진다
• 무엇이 어떤 값에서 바뀌었는지 설명할 수 없고, 되돌릴 때 남의 변경까지 함께 되돌아간다

좁힌 조건을 만족하지만 customers 테이블에 고객이 없는 주문 한 건을 발견했다. 가장 적절한 처리는?

• 이번 변경에서 제외하고, 제외 사실과 이유를 계획서에 적어 고객사에 확인을 요청한다
• 조건을 만족하므로 함께 바꾸고 보고서에 각주로 남긴다
• 고객 레코드를 새로 만들어 참조를 맞춘 뒤 함께 바꾼다
• 그 주문을 삭제해 데이터 정합성을 먼저 회복시킨다

적용 후 검증에서 대조군을 함께 세는 이유는?

• 적용에 걸린 시간과 잠금 대기 시간을 함께 기록해 두기 위해
• 롤백을 실행할 때 필요한 트랜잭션 번호를 확보하기 위해
• 바뀌어야 할 것만 세면 조건이 넓어 옆을 건드린 사고가 드러나지 않기 때문에
• 변경 대상 건수가 계획서의 숫자와 같은지 다시 확인하기 위해

계획서의 '되돌리는 방법' 절이 믿을 만한지 확인하는 가장 확실한 방법은?

• 복구 절차를 두 사람이 교차 검토해 문장을 다듬는다
• 백업 파일의 체크섬을 기록해 무결성을 확인해 둔다
• 백업을 뜬 시각과 변경 시각의 간격을 짧게 유지한다
• 사본에 변경을 적용하고 그 백업으로 실제 복원해 원본과 차이가 0인지 센다