LabHub
배우기 러닝패스 코스

되돌릴 수 없는 변경 · 승인 뒤 누군가 먼저 바꿨다 · 퀴즈

퀴즈: 승인 뒤 누군가 먼저 바꿨다

LabHub 에서 이어서 보기

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

  1. 배치의 첫 행 취소는 성공했지만 두 번째 행의 버전이 승인과 다릅니다. 필요한 결과는?

    1. 첫 행을 남기고 두 번째 행만 건너뛰어 전체 성공으로 보고한다
    2. 현재 버전으로 두 번째 대상을 고쳐 승인 없이 계속 적용한다
    3. 바깥 트랜잭션을 롤백하여 첫 행의 취소도 남기지 않는다
    4. 오류 메시지만 반환하고 첫 행이 남았는지는 확인하지 않는다
  2. 승인 버전을 SELECT로 비교한 다음 ID만 조건으로 UPDATE하면 어떤 틈이 생기나요?

    1. SELECT가 자동으로 모든 고객의 테이블을 영구 잠근다
    2. UPDATE가 앞 SELECT의 결과를 항상 자동 재사용한다
    3. RETURNING이 없는 조회만 PostgreSQL에서 실행될 수 있다
    4. 두 문장 사이 다른 변경이 들어와 오래된 승인으로 덮을 수 있다
  3. Read Committed에서 UPDATE가 다른 작업자의 행 잠금을 기다렸고, 앞 작업자가 revision을 올려 커밋했습니다. 기대 동작은?

    1. 갱신된 행에 WHERE를 다시 대조하여 오래된 revision 조건은 실패한다
    2. 처음 관측한 revision만 사용하여 잠금 뒤에도 무조건 변경한다
    3. 기다린 시간이 길면 승인 목록의 revision을 자동 증가시킨다
    4. 앞 작업자의 커밋을 취소하고 이전 버전의 행을 복원한다
  4. 감사와 변경을 커밋한 직후 클라이언트가 종료돼 성공 응답을 잃었습니다. 같은 ID·같은 승인 내용으로 다시 실행하면?

    1. 변경을 한 번 더 실행하고 revision을 다시 증가시킨다
    2. 확정 영수증을 확인하고 새 효과 없이 False를 반환한다
    3. 기존 영수증을 지우고 새로운 변경 ID로 강제 재시도한다
    4. 현재 상태가 cancelled이므로 성공 여부를 영원히 알 수 없다
  5. 영수증에는 주문 1·2가 있지만 현재 주문 2는 없어지고 주문 6이 같은 값으로 생겼습니다. reconcile의 판단은?

    1. 현재 총 건수가 같으므로 두 주문이 모두 일치한다고 본다
    2. 주문 6을 주문 2로 바꿔 영수증과 현재 상태를 강제로 맞춘다
    3. 원래 주문 2를 누락으로 표시하고 현재 데이터는 바꾸지 않는다
    4. 영수증에서 주문 2를 지워 이후 대조가 통과하게 만든다
  6. 기존 실습 DB는 fsync와 full_page_writes가 꺼져 있습니다. 클라이언트 강제 종료 시험의 통과로 말할 수 있는 범위는?

    1. 운영 서버의 전원 차단 뒤에도 모든 커밋이 보존된다는 보장
    2. 저장장치가 손상돼도 백업 없이 전체 데이터를 복원한다는 보장
    3. 여러 호스트의 장애와 네트워크 분할에서도 합의가 유지된다는 보장
    4. 살아 있는 DB 서버에서 연결 종료와 재접속의 결과를 확인한 사실