단원 모의 문제

② — 인덱스는 찾을 행을 적게 읽게 해 주어 조회의 응답 시간을 줄입니다. 그 대신 행을 넣고 고칠 때마다 인덱스까지 함께 고쳐야 해서, 정해진 시간에 처리하는 트랜잭션 수는 떨어집니다. 함께 보는 셋은 하나를 좋게 하면 다른 하나가 나빠지는 맞바꾸는 관계입니다.

• ① 인덱스가 모든 일을 빠르게 한다고 봤습니다. 읽는 일은 빨라지지만 넣고 고치는 일에는 인덱스를 고치는 품이 더 붙습니다.
• ③ 저장할 것이 늘면 조회까지 느려진다고 봤습니다. 조회는 인덱스를 따라 몇 칸만 읽어 되레 빨라집니다.
• ④ 인덱스를 공간만 더 쓰는 것으로 봤습니다. 공간을 더 쓰는 대가로 줄이는 것이 응답 시간입니다.

다시 볼 레슨: 물리 설계와 칼럼 속성

③ — 열을 NOT NULL로 바꾸려면 그 열에 비어 있는 행이 하나도 없어야 합니다. 학생 표에는 학과코드가 비어 있는 강도현(107)이 있어, Oracle은 ORA-02296 오류를 내고 열을 그대로 둡니다. 그 행을 채우거나 지운 뒤에 다시 돌려야 합니다.

• ① 어긋나는 행을 DBMS가 치워 준다고 봤습니다. 제약 조건을 거는 문장은 행을 지우지 않고, 어긋나는 행이 있으면 거는 일 자체가 막힙니다.
• ② 비어 있던 칸이 어떤 값으로든 채워진다고 봤습니다. 칸을 채우는 것은 UPDATE 문이고, 제약 조건을 거는 문장은 값을 넣지 않습니다.
• ④ 칼럼 속성을 표를 만들 때만 정한다고 봤습니다. 자료형·길이·NULL 허용·기본값은 ALTER TABLE … MODIFY로 뒤에 바꿀 수 있습니다. 여기서 막은 것은 문법이 아니라 이미 들어 있는 NULL입니다.

다시 볼 레슨: DDL: CREATE·ALTER·DROP · 물리 설계와 칼럼 속성

① — VALUES LESS THAN (60)⁠은 60보다 작은 값까지만 받습니다. 점수 55·50 두 행이 P1에 들고, 60부터 79까지인 75·70·60·65·75 다섯 행이 P2에 들고, 80 이상인 85·80·95·100·90 다섯 행이 P3에 듭니다.

• ② 점수 80을 P2로 보냈습니다. P2가 받는 값은 80보다 작은 값까지라, 80은 다음 구간인 P3에 듭니다.
• ③ 점수 60을 P1로 보냈습니다. '60 미만'과 '60 이하'는 다릅니다.
• ④ 두 경곗값을 모두 앞 파티션으로 보냈습니다. 경계로 적은 값은 늘 뒤 파티션의 첫 값입니다.

다시 볼 레슨: 파티셔닝

④ — 클러스터링은 함께 읽는 일이 잦고 값이 잘 바뀌지 않는 짝에만 맞습니다. 넣기가 잦은 표는 키마다 잡아 둔 자리가 차서 넘친 행이 다른 블록으로 가고, 한 표만 전부 훑는 질의는 블록에 섞여 있는 다른 표의 행까지 읽습니다. 접속기록은 두 가지에 모두 걸립니다.

• ① 맞습니다. 함께 읽는 일이 잦고 클러스터 키가 바뀌지 않아 모아 두기에 맞는 짝입니다.
• ② 맞습니다. 키를 고치는 일이 아주 드물면 행이 다른 블록으로 옮겨 가는 품도 드물게 듭니다.
• ③ 맞습니다. 두 표에 공통인 값이 있고 그 값이 잘 바뀌지 않아 한 블록에 모아 둘 수 있습니다.

다시 볼 레슨: 클러스터링과 데이터 지역화

① — 클러스터는 클러스터 키가 같은 행을 표가 달라도 한 블록에 섞어 담습니다. 클러스터드 인덱스는 한 표의 행을 키 순서로 줄 세워 저장하는 것이고, 행은 한 가지 순서로만 놓일 수 있어 표에 하나뿐입니다.

• ② (나)를 넌클러스터드로 봤습니다. 넌클러스터드 인덱스는 행을 그대로 두고 키와 행 위치만 따로 정렬해 두는 것이라 여럿 만들 수 있습니다.
• ③ 두 이름을 바꿔 봤습니다. 이름이 닮았지만 클러스터는 표가 다른 행까지 모으고, 클러스터드 인덱스는 한 표의 행만 줄 세웁니다.
• ④ (가)까지 인덱스로 봤습니다. 클러스터드 인덱스는 한 표의 행을 줄 세우는 것이고, 표 둘의 행을 한 블록에 섞어 담지는 않습니다.

다시 볼 레슨: 인덱스 · 클러스터링과 데이터 지역화

② — 열을 골라 가르는 것이 수직 단편화입니다. 조각마다 같은 키 열을 두고, 다시 모을 때는 그 키로 이어 붙입니다.

• ① 행을 조건으로 가르는 쪽입니다. '서울 사원은 서울 서버, 부산 사원은 부산 서버'처럼 나누면 수평 단편화입니다.
• ③ 쪼갠 조각을 어느 서버에 둘지 정하는 일의 이름입니다. 쪼개는 방향의 이름이 아닙니다.
• ④ 같은 조각을 여러 서버에 두는 것입니다. 여기서는 서로 다른 열을 나눠 두었습니다.

다시 볼 레슨: 분산 데이터베이스

④ — 타임스탬프 순서는 트랜잭션에 붙인 시각의 앞뒤로 접근 순서를 따지고, 낙관적 검증은 끝낼 때가 되어서야 부딪혔는지 따집니다. 둘 다 락을 걸지 않아 서로의 락을 기다리는 교착 상태가 생기지 않습니다.

• ① 둘 다 락을 거는 기법입니다. 2단계 로킹은 락을 얻는 단계와 푸는 단계를 나눈 규약이고, 교착 상태를 막지는 못합니다.
• ② 타임스탬프 순서는 락을 쓰지 않지만, 로킹은 락을 거는 일 그 자체입니다.
• ③ 낙관적 검증은 락을 쓰지 않지만, 2단계 로킹은 락을 거는 규약입니다.

다시 볼 레슨: 병행 제어

③ — 커밋을 먼저 마치고 변경을 나중에 보내는 Lazy 방식에서 일어나는 일입니다. Eager 방식은 복제 서버에 반영한 뒤에 커밋을 마치므로, 커밋이 끝난 뒤 복제 서버를 읽으면 늘 새 값이 나옵니다.

• ① 맞습니다. 커밋이 복제 서버의 반영을 기다리므로 고치는 데 걸리는 시간이 늘어납니다.
• ② 맞습니다. 변경과 복제가 한 트랜잭션에 묶여 있어, 복제 서버에 반영할 수 없으면 변경 자체가 취소됩니다.
• ④ 맞습니다. 어느 순간에 봐도 두 서버의 값이 같은 것이 이 방식을 고르는 까닭입니다.

다시 볼 레슨: 데이터베이스 이중화

① — 바꾼 값을 그때그때 써 넣는 방식이라, 끝내지 못한 S의 변경이 이미 데이터베이스에 들어가 있을 수 있습니다. 그래서 S는 로그의 바꾸기 전 값으로 되돌리고, COMMIT을 마친 T는 로그의 바꾼 뒤 값으로 다시 반영합니다. 이 방식은 두 연산을 모두 씁니다.

• ② 끝내지 못한 트랜잭션의 흔적이 데이터베이스에 없다고 봤습니다. 그것은 끝낼 때까지 데이터베이스를 건드리지 않는 지연 갱신입니다.
• ③ 바로 써 넣었으니 다시 반영할 것이 없다고 봤습니다. 이 방식은 COMMIT한 트랜잭션에 REDO를, 끝내지 못한 트랜잭션에 UNDO를 모두 씁니다.
• ④ 로그를 보고 할 일이 없다고 봤습니다. 회복은 로그에 COMMIT이 적혔는지로 두 트랜잭션을 가릅니다.

다시 볼 레슨: 회복

① — 증분 백업은 마지막 백업 뒤에 바뀐 것만 담아 날마다 담은 것이 서로 다릅니다. 밑바탕인 전체 백업을 되살린 뒤 그 뒤의 증분을 뜬 순서대로 모두 되돌리고, 마지막으로 로그 백업을 시간 순서대로 반영해 장애 직전으로 맞춥니다.

• ② 가장 최근 하나로 끝난다고 봤습니다. 그것은 뒤의 것이 앞의 변경까지 품는 차등 백업입니다. 증분은 하나라도 빠지면 그 뒤를 되돌릴 수 없습니다.
• ③ 증분을 먼저 되돌렸습니다. 되살릴 밑바탕이 아직 없어 되돌릴 자리가 없습니다.
• ④ 로그 백업을 먼저 반영했습니다. 로그 백업은 데이터 백업 뒤에 쌓인 변경이라 맨 마지막에 반영합니다.

다시 볼 레슨: 데이터베이스 백업

③ — 서버 여럿이 함께 쓰면서 업무 트래픽에 밀리지 않아야 하니, 저장 장치만을 위한 전용 망으로 묶는 방식이 맞습니다. 서버는 블록 단위로 받아 자기 디스크처럼 씁니다.

• ① 장비를 더하지 않는 쪽만 보고 골랐습니다. NAS는 업무용 네트워크를 함께 써서, 그 네트워크가 붐비면 데이터를 읽는 속도도 함께 떨어집니다.
• ② 블록 단위로 주는 쪽을 NAS로 봤습니다. NAS는 파일 단위로 주고, 블록 단위로 주는 쪽은 DAS와 SAN입니다.
• ④ DAS의 모습을 SAN에 붙였습니다. 케이블로 바로 꽂는 쪽이 DAS이고, 그러면 붙은 서버 한 대에 매여 넷이 함께 쓸 수 없습니다.

다시 볼 레슨: 스토리지: DAS·NAS·SAN

② — 암호화한 열은 값의 순서가 뒤섞여 범위 검색이나 정렬이 그대로 되지 않고, 그 열의 인덱스 범위 스캔도 쓸 수 없습니다. 그래서 범위로 좁히던 질의가 모든 행을 되돌려 견주는 일이 됩니다.

• ① 암호문이 길어지는 것은 맞습니다. 다만 그것만으로는 범위로 찾는 질의만 유난히 느려지는 까닭이 되지 않습니다. 길어지는 것은 열 길이를 늘려야 할 수 있다는 이야기입니다.
• ③ 읽을 때 되돌리지 않는다고 봤습니다. 암호화한 열은 읽을 때 되돌려 보여 주고, 그 되돌리는 일에도 시간이 듭니다.
• ④ 읽기는 그대로라고 봤습니다. 암호화와 복호화 모두 시간이 들어 넣기와 읽기가 함께 느려집니다.

다시 볼 레슨: 데이터베이스 암호화

④ — 개체는 실제로 만들 표가 되고, 두 개체를 잇던 관계는 한쪽 표의 열에 거는 외래키 제약 조건이 됩니다. 속성이 열과 그 타입·길이가 되고, 키 속성이 기본키 제약 조건이 됩니다.

• ① 개체를 열로, 관계를 기본키로 봤습니다. 열이 되는 것은 속성이고, 기본키가 되는 것은 키 속성입니다.
• ② 관계는 맞게 봤지만 개체를 열로 봤습니다. 개체 하나가 표 하나가 됩니다.
• ③ 개체는 맞게 봤지만 관계를 기본키로 봤습니다. 기본키는 한 표 안에서 행을 가리키는 키이고, 두 표를 잇는 것은 외래키입니다.

다시 볼 레슨: 물리 E-R 다이어그램과 CRUD 분석

② — 데이터를 보지 않고 정해 둔 순위만 따르는 것이 규칙 기반 옵티마이저입니다. '인덱스가 있으면 인덱스를 쓴다'는 순위를 따르므로, 표가 작아 전체를 읽는 편이 싼 경우에도 인덱스를 거칩니다.

• ① 방식의 이름은 맞게 봤지만 고르는 길을 거꾸로 봤습니다. 어느 쪽이 싼지 따지려면 행 수와 분포를 담은 통계 정보가 있어야 합니다.
• ③ 통계 정보를 보고 싼 쪽을 고르는 쪽은 비용 기반이 맞습니다. 다만 문제의 옵티마이저는 통계를 보지 않습니다.
• ④ 비용 기반이 인덱스를 늘 쓴다고 봤습니다. 비용 기반은 걸리는 행이 많거나 표가 작으면 전체 스캔을 고릅니다.

다시 볼 레슨: SQL 성능 튜닝과 옵티마이저

받는 답: (가) 차등 백업 · (나) 로그 백업

(가)의 실마리는 '밤마다 떴는데 되돌린 것은 가장 최근 하나뿐'입니다. 마지막 전체 백업 뒤에 바뀐 것을 모두 담기 때문에, 뒤에 뜬 하나에 앞의 변경이 다 들어 있습니다. (나)는 '데이터 백업 사이에 쌓인 것을 떠서 장애 직전까지 맞춘다'가 실마리입니다.

• 같은 이름의 다른 꼴: (가) Differential Backup · (나) Log Backup — 영문 이름입니다. 문제가 한글로 물었습니다.
• 틀리는 꼴 증분 백업 — (가)에: 마지막 백업 뒤에 바뀐 것만 담습니다. 그렇게 운영했다면 화·수·목에 뜬 것을 뜬 순서대로 모두 되돌려야 합니다.
• 틀리는 꼴 전체 백업 — (가)에: 데이터베이스를 한 벌 통째로 뜨는 백업이고, 문제에서 월요일 밤에 뜬 것이 그것입니다.
• 틀리는 꼴 로그 — (나)에: 데이터베이스가 쌓아 두는 변경 기록 자체의 이름입니다. (나)는 그 기록을 따로 떠 두는 백업의 이름입니다.

다시 볼 레슨: 데이터베이스 백업

받는 답: Access Control

실마리는 '누가 어느 표에 무엇을 할 수 있는지 미리 정해 두고 그 밖의 요청을 막는다'입니다. 권한을 주고 거두는 일이 그 수단이고, 그 일 전체를 가리키는 이름입니다.

• 같은 이름의 다른 꼴: 접근 제어 — 한글 이름입니다. 문제가 영문으로 물었습니다.
• 틀리는 꼴 ROLE: 권한 여러 개를 묶어 이름을 붙인 것입니다. 묶음의 이름이고, 요청을 막는 일의 이름이 아닙니다.
• 틀리는 꼴 TDE(Transparent Data Encryption): 저장하는 값을 열쇠 없이 읽지 못하게 바꿔 두는 방식입니다. 권한은 질의하는 길을 막고, 암호화는 데이터 파일을 들고 가도 읽지 못하게 합니다.

다시 볼 레슨: DCL: GRANT·REVOKE · 데이터베이스 암호화

받는 답: 다섯 줄 · 계획 A의 비용 3 · 계획 B의 비용 2 · 계획 B에도 TABLE ACCESS 줄이 있다

계획 A는 인덱스가 없어 학생 표를 처음부터 끝까지 읽는 전체 스캔이라 두 줄입니다. 인덱스를 만든 뒤인 계획 B는 인덱스에서 CS인 행의 위치를 찾고(ID 2), 고르는 열인 학년이 인덱스에 없어 그 위치로 표를 찾아갑니다(ID 1). 그래서 B는 세 줄이고, 둘을 합해 다섯 줄입니다. 비용은 3에서 2로 줄었습니다.

• 틀리는 꼴 네 줄 · B의 비용 1 · TABLE ACCESS 줄 없음: 인덱스만 읽고 끝난다고 봤습니다. 고르는 열이 조건 열과 같으면 그렇지만, 여기서는 학년을 고르므로 표를 찾아가야 합니다.
• 틀리는 꼴 네 줄 · B의 비용 3 · 전체 스캔 그대로: 인덱스를 만들어도 계획이 바뀌지 않는다고 봤습니다. 비용 기반 옵티마이저는 인덱스를 거치는 쪽이 싸면 그쪽으로 바꿉니다.
• 틀리는 꼴 다섯 줄 · B의 비용 3: 계획은 바뀌지만 비용은 그대로라고 봤습니다. 계획이 바뀐 까닭이 어림한 비용이 더 작기 때문입니다.

다시 볼 레슨: SQL 성능 튜닝과 옵티마이저 · 인덱스