되돌릴 수 없는 변경 · 쓰기 전에 쓰는 것 · 퀴즈
퀴즈: 쓰기 전에 쓰는 것
문항 6개. 정답과 해설은 풀어 본 뒤에 보여 드립니다.
고객이 문장으로 보낸 변경 요청을 SQL 조건으로 옮기기 전에 가장 먼저 할 일은?
- 요청한 담당자에게 서면 승인을 먼저 받는다
- 테이블 전체를 파일로 백업해 둔다
- 요청대로 옮겼을 때 실제로 몇 행이 바뀌는지 먼저 센다
- 변경을 트랜잭션으로 감싸 두고 바로 실행한다
시험 실행을 트랜잭션 안에서 UPDATE 한 뒤 ROLLBACK 하는 방식으로 하는 이유는?
- 실행 계획을 미리 만들어 두어 본 적용을 빠르게 하려고
- 세는 조건과 바꾸는 조건이 문자 그대로 같아지기 때문에
- 롤백한 트랜잭션은 감사 로그에 남지 않기 때문에
- COUNT 로 세는 것보다 잠금을 덜 잡기 때문에
변경 전에 파일 사본만 남기고 행 스냅샷을 남기지 않으면 무엇이 어려워지는가?
- 되돌리는 일 자체가 불가능해져 변경을 실행할 수 없다
- 백업 파일이 커져서 복원에 시간이 오래 걸리게 된다
- 트랜잭션 격리 수준을 높게 잡아야만 복원이 가능해진다
- 무엇이 어떤 값에서 바뀌었는지 설명할 수 없고, 되돌릴 때 남의 변경까지 함께 되돌아간다
좁힌 조건을 만족하지만 customers 테이블에 고객이 없는 주문 한 건을 발견했다. 가장 적절한 처리는?
- 이번 변경에서 제외하고, 제외 사실과 이유를 계획서에 적어 고객사에 확인을 요청한다
- 조건을 만족하므로 함께 바꾸고 보고서에 각주로 남긴다
- 고객 레코드를 새로 만들어 참조를 맞춘 뒤 함께 바꾼다
- 그 주문을 삭제해 데이터 정합성을 먼저 회복시킨다
적용 후 검증에서 대조군을 함께 세는 이유는?
- 적용에 걸린 시간과 잠금 대기 시간을 함께 기록해 두기 위해
- 롤백을 실행할 때 필요한 트랜잭션 번호를 확보하기 위해
- 바뀌어야 할 것만 세면 조건이 넓어 옆을 건드린 사고가 드러나지 않기 때문에
- 변경 대상 건수가 계획서의 숫자와 같은지 다시 확인하기 위해
계획서의 '되돌리는 방법' 절이 믿을 만한지 확인하는 가장 확실한 방법은?
- 복구 절차를 두 사람이 교차 검토해 문장을 다듬는다
- 백업 파일의 체크섬을 기록해 무결성을 확인해 둔다
- 백업을 뜬 시각과 변경 시각의 간격을 짧게 유지한다
- 사본에 변경을 적용하고 그 백업으로 실제 복원해 원본과 차이가 0인지 센다