Quiz: DDL and Change Control

'down 마이그레이션 스크립트가 있으니 안전하다'는 판단의 문제는?

• down 스크립트는 DBMS 가 지원하지 않는다
• down 스크립트는 항상 실행 시간이 더 길다
• down 스크립트는 인덱스를 복원하지 못한다
• DROP 을 되돌리는 down 은 컬럼 구조만 되살릴 뿐 사라진 데이터는 되살리지 못한다

500만 행 테이블에 대량 백필 UPDATE 를 한 트랜잭션으로 실행했을 때 조회 서비스에 나타나는 영향은?

• 트랜잭션 로그가 폭증하고 복제가 밀려, 복제본을 보는 조회가 옛 데이터를 준다
• 갱신은 별도 세션에서 도는 것이라 조회 쪽에는 영향이 없다
• 대량 갱신 중에는 인덱스가 잠시 비활성화되어 조회가 느려진다
• 갱신이 끝날 때까지 테이블이 읽기 전용으로 바뀌어 쓰기만 막힌다

확장-이관-축소(Expand/Migrate/Contract) 패턴의 핵심 규칙은?

• 모든 변경을 한 번의 배포에 몰아넣어 중단 시간을 줄인다
• 스키마 변경은 항상 애플리케이션보다 나중에 한다
• 인덱스를 먼저 만들고 컬럼을 추가한다
• 한 번의 배포에 두 단계를 함께 넣지 않아 각 시점에서 롤백이 가능하게 한다

컬럼 추가와 컬럼 삭제의 배포 순서를 바르게 정리한 것은?

• 추가는 DB 먼저 → 앱 나중, 삭제는 앱 먼저 → DB 나중
• 둘 다 DB 를 먼저 변경한다
• 둘 다 앱을 먼저 배포한다
• 추가는 앱 먼저, 삭제는 DB 먼저

블루그린 배포가 스키마 변경 문제를 해결하지 못하는 이유는?

• 블루그린은 애플리케이션 전용 전략이라 DB 계층에는 적용할 수 없어서
• 전환 뒤에는 이전 색이 정리되므로 되돌릴 수단이 남지 않기 때문에
• 전환 순간에 세션이 끊겨 완전한 무중단이 되지 않기 때문에
• 컴퓨트는 복제해도 DB 는 공유하므로 스키마가 구·신 양쪽과 호환돼야 하기 때문에

마이그레이션 검증에서 행 수와 합계만 비교하면 놓칠 수 있는 상황은?

• 한 건이 누락되고 다른 한 건이 중복되어 합계가 우연히 맞는 경우
• 테이블이 통째로 비어 있는 경우
• 인덱스가 생성되지 않은 경우
• 컬럼 타입이 바뀐 경우

변경관리 대장에 '롤백 스크립트 경로'를 필수 항목으로 두는 것의 가장 큰 효과는?

• 대장의 항목이 통일되어 검토와 승인 절차가 빨라진다
• 롤백을 쓰는 과정에서 '이 변경은 되돌릴 수 없다'는 사실을 배포 전에 깨닫게 된다
• 되돌릴 스크립트가 준비돼 있으면 DDL 을 더 공격적으로 실행할 수 있다
• 롤백 계획이 있으면 승인 단계를 한 번 건너뛸 수 있어 일정이 단축된다