커밋하지 않은 변경은 나에게만 보입니다. 그래서 "저장했는데 안 보인다"는 문의의 절반은 커밋을 안 한 것입니다.
풀고 시작
문제 1. 트랜잭션의 네 가지 성질 중 트랜잭션이 완료되면 그 결과가 영구히 보존된다는 성질은?
지속성은 커밋된 결과가 장애가 나더라도 남아 있어야 한다는 성질입니다. 원자성은 전부 반영되거나 전부 취소되어야 한다는 성질, 일관성은 트랜잭션 전후로 데이터가 규칙을 지켜야 한다는 성질, 고립성은 수행 중인 트랜잭션이 서로 끼어들지 않아야 한다는 성질입니다.
트랜잭션이 지켜야 하는 네 가지
트랜잭션은 하나의 논리적 작업 단위입니다. 1과목 6강에서 모델이 트랜잭션의 범위를 말해 준다고 했던 그 단위죠. 계좌에서 돈을 빼고 다른 계좌에 넣는 두 작업은 함께 성공하거나 함께 실패해야 합니다.
이 요구를 네 가지 성질로 정리한 것이 흔히 앞 글자를 따서 부르는 규칙입니다.
원자성(atomicity)은 트랜잭션의 작업이 전부 반영되거나 전부 취소되어야 한다는 성질입니다. 절반만 반영된 상태가 남으면 안 됩니다. 일관성(consistency)은 트랜잭션이 끝난 뒤에도 데이터가 정의된 규칙을 지키고 있어야 한다는 성질입니다. 제약 조건이 이 성질을 지키는 장치죠. 고립성(isolation)은 동시에 수행되는 트랜잭션들이 서로의 중간 상태를 보지 않아야 한다는 성질입니다. 지속성(durability)은 커밋된 결과가 장애가 나더라도 남아 있어야 한다는 성질입니다.
넷 중 실무에서 가장 자주 조정하는 것이 고립성입니다. 완벽하게 격리하려면 동시성이 떨어지고, 동시성을 높이면 다른 트랜잭션의 중간 상태를 보게 될 수 있습니다. 그래서 격리 수준을 단계로 나눠 선택하게 되어 있습니다.
COMMIT, ROLLBACK, SAVEPOINT
COMMIT은 지금까지의 변경을 확정합니다. 확정되면 다른 사용자에게도 보이고, 되돌릴 수 없습니다. ROLLBACK은 확정 전의 변경을 전부 취소해 트랜잭션 시작 시점으로 되돌립니다.
커밋하기 전의 상태에는 특징이 있습니다. 변경한 사람에게는 바뀐 값이 보이지만 다른 사람에게는 이전 값이 보입니다. 그리고 변경된 행에는 잠금(lock)이 걸려 다른 트랜잭션이 같은 행을 바꾸려 하면 기다리게 됩니다. 그래서 커밋을 오래 미루는 습관은 다른 작업을 세워 두는 셈입니다. 반대로 너무 잘게 나눠 커밋하면 원자성이 깨집니다. 트랜잭션의 경계는 편의가 아니라 업무 규칙이 정해야 합니다.
SAVEPOINT는 트랜잭션 안에 되돌아갈 지점을 표시합니다. 긴 작업의 중간에 표시를 남겨 두고, 뒤에서 문제가 생기면 처음이 아니라 그 지점까지만 되돌릴 수 있습니다. 저장점까지 되돌리면 그 뒤의 저장점들은 사라지고 트랜잭션 자체는 아직 끝나지 않은 상태로 남습니다. 마무리는 커밋이나 롤백으로 따로 해야 합니다.
몇 가지 사실을 함께 기억해 두세요. 14강에서 본 것처럼 DDL은 대체로 자동 커밋되므로, 트랜잭션 중간에 테이블 구조를 바꾸면 그 전의 변경까지 확정되어 버립니다. 그리고 세션이 정상 종료되면 대체로 커밋되지만 비정상 종료되면 롤백됩니다. 제품별 동작에 차이가 있으니 실무에서는 명시적으로 끝내는 것이 원칙입니다.
권한을 주고 뺏기
DCL은 누가 무엇을 할 수 있는지를 정합니다. 명령은 두 개뿐입니다. GRANT로 권한을 주고 REVOKE로 거둡니다.
권한은 크게 두 갈래입니다. 접속하고 객체를 만들 수 있는지 같은 시스템 권한과, 특정 테이블을 조회하거나 수정할 수 있는지 같은 객체 권한입니다. 객체 권한은 대상을 지정해 주고, 컬럼 단위까지 좁혀 주는 것도 가능합니다.
권한을 줄 때 다시 남에게 줄 수 있는 권한까지 함께 주는 옵션이 있습니다. 편리하지만 위험합니다. 권한이 사슬처럼 퍼져 나가고, 나중에 원래 권한을 거둘 때 그 사슬을 어떻게 처리할지 결정해야 하니까요. 제품에 따라 연쇄적으로 함께 회수되기도 하고, 남아 있어 문제가 되기도 합니다.
롤(role)은 권한을 묶어 이름을 붙인 것입니다. 사용자가 스무 명이고 권한이 열 개면 관리해야 할 조합이 이백 개가 되는데, 롤을 만들어 권한을 담고 사용자에게 롤을 주면 관리 대상이 확 줄어듭니다. 사람이 늘거나 권한이 바뀔 때 고칠 곳이 한 군데뿐이죠. 실무에서 권한 관리가 무너지는 이유의 대부분은 롤을 쓰지 않고 개인마다 직접 권한을 준 탓입니다.
뷰, 권한과 편의가 만나는 자리
뷰(view)는 SELECT 문에 이름을 붙여 둔 것입니다. 실제 데이터를 갖지 않고 정의만 저장하므로 가상 테이블이라 부릅니다. 8강의 인라인 뷰가 그 자리에서만 사는 뷰라면, 이쪽은 데이터베이스에 이름으로 남는 뷰입니다.
뷰를 쓰는 이유가 셋입니다. 독립성입니다. 테이블 구조가 바뀌어도 뷰의 정의만 고치면 뷰를 쓰는 쪽은 그대로 갑니다. 편의성입니다. 복잡한 조인을 뷰로 감싸 두면 쓰는 사람은 테이블 하나처럼 다룹니다. 그리고 보안입니다. 민감한 컬럼을 뺀 뷰를 만들어 그 뷰에만 권한을 주면, 원본 테이블 권한 없이도 필요한 만큼만 보게 할 수 있습니다.
뷰의 성질 몇 가지도 알아 두면 좋습니다. 뷰를 통해 데이터를 바꿀 수 있는 경우도 있지만 집계나 그룹, 중복 제거가 들어간 뷰는 갱신할 수 없습니다. 어느 원본 행을 바꿔야 할지 정할 수 없으니까요. 그리고 뷰는 정의만 저장하므로 원본 테이블이 지워지면 뷰는 남아 있어도 동작하지 않습니다.
여기까지가 SQLD의 출제 범위입니다. 이제 서가로 돌아가 모의고사를 한 번 치러 보시면 어느 과목이 비어 있는지가 곧 드러납니다. 과락은 언제나 안 본 곳에서 나옵니다.
인출 문제
문제 1. SAVEPOINT까지 롤백한 뒤의 상태에 대한 설명으로 옳은 것은?
저장점까지의 부분 취소이므로 트랜잭션은 계속 진행 중이고 커밋이나 롤백으로 마무리해야 합니다. 그 뒤에 찍었던 저장점들은 사라집니다.
문제 2. 커밋하지 않은 변경에 대한 설명으로 옳은 것은?
확정 전에는 변경한 세션만 새 값을 보고 다른 세션은 이전 값을 봅니다. 변경된 행에는 잠금이 걸려 다른 트랜잭션이 기다리게 되며, 비정상 종료 시에는 대체로 롤백됩니다.
문제 3. 롤을 사용하는 가장 큰 이점은?
사용자마다 권한을 하나씩 주면 관리해야 할 조합이 곱으로 늘어납니다. 권한 묶음에 이름을 붙여 그것을 주고 거두면 고칠 곳이 한 군데로 줄어듭니다.
문제 4. 뷰를 통해 데이터를 변경할 수 없는 경우로 가장 적절한 것은?
여러 행이 하나로 요약된 뒤에는 어느 원본 행을 바꿔야 할지 정할 수 없으므로 갱신이 불가능합니다. 컬럼을 고르거나 행을 걸러 내거나 별칭을 붙인 것만으로는 원본 행과의 대응이 깨지지 않습니다.
생각해볼 질문 (정답 없음)
커밋을 자주 하면 잠금이 빨리 풀려 다른 작업이 편해지고, 드물게 하면 업무 단위가 온전히 지켜집니다. 이 둘이 충돌하는 작업을 만났을 때 무엇을 기준으로 경계를 그으시겠습니까.
더 풀기
출제기준의 세세항목을 따라 이 강의 범위에서 새로 낸 문제입니다. 모의고사도 여기에서 뽑습니다.
묶음 1
문제 1. 트랜잭션의 네 가지 성질로 바르게 묶인 것은?
흔히 앞 글자를 따서 에이시아이디라고 부릅니다. 정규성이나 유연성은 다른 맥락의 용어입니다.
문제 2. 일관성을 가장 잘 설명한 것은?
제약 조건과 업무 규칙이 트랜잭션 전후로 깨지지 않아야 한다는 뜻입니다.
문제 3. 고립성을 가장 잘 설명한 것은?
고립성이 없으면 다른 트랜잭션이 아직 확정하지 않은 값을 읽게 됩니다.
문제 4. 지속성을 가장 잘 설명한 것은?
확정 후에는 시스템이 죽어도 복구 과정에서 그 결과가 되살아납니다.
문제 5. COMMIT이 하는 일로 가장 알맞은 것은?
확정 전까지 변경은 자기 세션에서만 보입니다. COMMIT 이후 다른 사용자도 그 값을 보게 됩니다.
문제 6. ROLLBACK이 하는 일로 가장 알맞은 것은?
확정 전이라면 전체를 되돌립니다. 일부만 되돌리려면 저장점을 써야 합니다.
문제 7. SAVEPOINT의 쓰임으로 가장 알맞은 것은?
긴 처리 중간에 표시를 남겨 두면 문제가 생긴 부분만 되돌릴 수 있습니다.
문제 8. 저장점까지 되돌린 뒤 트랜잭션은 어떤 상태가 되나요?
부분 되돌림은 트랜잭션을 끝내지 않습니다. 끝내려면 확정하거나 전체를 되돌려야 합니다.
문제 9. DDL을 실행하면 진행 중이던 트랜잭션은 대개 어떻게 되나요?
많은 제품에서 DDL은 앞선 작업을 함께 확정합니다. 그래서 트랜잭션 중간에 DDL을 섞으면 위험합니다.
문제 10. 트랜잭션을 짧게 유지해야 하는 이유로 가장 알맞은 것은?
길게 열어 둘수록 충돌 가능성이 커집니다. 사용자의 입력을 기다리는 동안 트랜잭션을 열어 두는 설계는 특히 나쁩니다.
묶음 2
문제 1. 확정하지 않은 다른 트랜잭션의 변경을 읽는 현상을 무엇이라 하나요?
아직 확정되지 않은 값을 읽는 것이 더티 읽기입니다. 그 트랜잭션이 되돌리면 존재한 적 없는 값을 본 셈이 됩니다.
문제 2. 같은 조건으로 두 번 읽었는데 값이 달라지는 현상을 무엇이라 하나요?
그 사이 다른 트랜잭션이 값을 바꾸고 확정한 경우입니다.
문제 3. 같은 조건으로 두 번 읽었는데 없던 행이 새로 나타나는 현상을 무엇이라 하나요?
값이 바뀐 것이 아니라 조건에 맞는 행이 새로 생긴 경우입니다.
문제 4. 고립 수준을 높이면 생기는 대가로 가장 알맞은 것은?
정확성과 동시성은 맞바꾸는 관계입니다. 업무가 요구하는 만큼만 올리는 것이 원칙입니다.
문제 5. 교착 상태를 가장 잘 설명한 것은?
서로를 기다리므로 시간이 지나도 풀리지 않습니다. 대개 시스템이 한쪽을 강제로 되돌려 해소합니다.
문제 6. 교착 상태를 줄이는 실무 습관으로 가장 알맞은 것은?
순서가 뒤바뀌면 서로 마주 보며 기다리게 됩니다. 순서를 통일하면 교착이 생기지 않습니다.
문제 7. 자동 확정 모드로 작업할 때의 위험으로 가장 알맞은 것은?
이체처럼 두 문장이 함께 성공해야 하는 작업에서 치명적입니다. 도구의 기본 설정을 확인해야 합니다.
문제 8. GRANT 명령이 하는 일로 가장 알맞은 것은?
권한을 주는 것이 GRANT, 뺏는 것이 REVOKE입니다. 사용자 생성은 별도의 명령입니다.
문제 9. 롤을 쓰는 이유로 가장 알맞은 것은?
사람이 늘고 줄 때마다 권한을 하나씩 다루면 실수가 생깁니다. 역할 단위로 묶으면 관리가 단순해집니다.
문제 10. 권한을 부여할 때 그 사용자가 다시 다른 사람에게 권한을 줄 수 있게 하려면?
이 옵션이 없으면 받은 권한을 남에게 넘길 수 없습니다. 남용하면 권한이 어디까지 퍼졌는지 추적하기 어려워집니다.
묶음 3
문제 1. WITH GRANT OPTION으로 준 권한을 회수하면 그 사용자가 다시 준 권한은 어떻게 되나요?
권한의 출처가 사라지므로 그로부터 파생된 권한도 함께 사라집니다.
문제 2. 뷰를 가장 잘 설명한 것은?
뷰 자체는 데이터를 갖지 않습니다. 참조할 때마다 정의된 질의가 실행됩니다.
문제 3. 뷰를 쓰는 이유로 가장 알맞은 것은?
뷰는 논리적 독립성과 보안을 함께 얻는 수단입니다. 원본 테이블 권한 없이 뷰만 조회하게 할 수 있습니다.
문제 4. 뷰를 통해 데이터를 수정할 수 있는 조건으로 가장 알맞은 것은?
어느 행을 고쳐야 할지 특정할 수 있어야 수정이 성립합니다. 여러 행이 하나로 접힌 뷰는 되돌릴 방법이 없습니다.
문제 5. 뷰가 참조하는 테이블의 컬럼이 삭제되면 뷰는 어떻게 되나요?
뷰는 정의만 저장되어 있으므로 참조 대상이 사라지면 실행 시점에 깨집니다.
문제 6. 뷰가 성능을 개선해 준다는 말이 오해인 이유로 가장 알맞은 것은?
결과를 저장해 두고 싶다면 구체화된 뷰처럼 별도의 기능이 필요합니다.
문제 7. 뷰에 WITH CHECK OPTION을 붙이면 어떤 효과가 있나요?
이 옵션이 없으면 뷰를 통해 넣은 행이 정작 그 뷰에서는 보이지 않는 상황이 생깁니다.
문제 8. 특정 부서 사원만 보이는 뷰에 다른 부서 사원을 입력했더니 입력은 되는데 뷰에서 보이지 않습니다. 원인은?
뷰는 조회 조건일 뿐 입력을 막지 않습니다. 막으려면 옵션을 명시해야 합니다.
문제 9. 권한 관리에서 최소 권한 원칙이 뜻하는 것은?
필요 이상의 권한은 사고의 크기를 키웁니다. 조회만 필요한 계정에 수정 권한을 주지 않는 것이 기본입니다.