LabHub

되돌릴 수 없는 변경 · 쓰기 전에 쓰는 것 · 퀴즈

퀴즈: 쓰기 전에 쓰는 것

LabHub 에서 이어서 보기

문항 6개. 정답과 해설은 풀어 본 뒤에 보여 드립니다.

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

    1. 요청한 담당자에게 서면 승인을 먼저 받는다
    2. 테이블 전체를 파일로 백업해 둔다
    3. 요청대로 옮겼을 때 실제로 몇 행이 바뀌는지 먼저 센다
    4. 변경을 트랜잭션으로 감싸 두고 바로 실행한다
  2. 시험 실행을 트랜잭션 안에서 UPDATE 한 뒤 ROLLBACK 하는 방식으로 하는 이유는?

    1. 실행 계획을 미리 만들어 두어 본 적용을 빠르게 하려고
    2. 세는 조건과 바꾸는 조건이 문자 그대로 같아지기 때문에
    3. 롤백한 트랜잭션은 감사 로그에 남지 않기 때문에
    4. COUNT 로 세는 것보다 잠금을 덜 잡기 때문에
  3. 변경 전에 파일 사본만 남기고 행 스냅샷을 남기지 않으면 무엇이 어려워지는가?

    1. 되돌리는 일 자체가 불가능해져 변경을 실행할 수 없다
    2. 백업 파일이 커져서 복원에 시간이 오래 걸리게 된다
    3. 트랜잭션 격리 수준을 높게 잡아야만 복원이 가능해진다
    4. 무엇이 어떤 값에서 바뀌었는지 설명할 수 없고, 되돌릴 때 남의 변경까지 함께 되돌아간다
  4. 좁힌 조건을 만족하지만 customers 테이블에 고객이 없는 주문 한 건을 발견했다. 가장 적절한 처리는?

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

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

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