데이터베이스 구축시 이것만은 주의하자



경영학과에 입학했지만, 컴퓨터에 자신이 없어 배워보려고 들어갔던 컴퓨터 동아리 때문에 인생이 바뀌었습니다. 대학원에서 정보시스템(IS) 석사 학위를 취득했고, 실무에서는 여러 프로젝트에서 시스템 구축과 데이터베이스 설계 업무를 맡았습니다. 최근에는 영진출판사에서 ‘솔라리스 서버 바이블’이라는 책을 내기도 했습니다.

지난 호까지 왜 개발자가 데이터베이스 설계까지 알아야 되는지, 그리고 실무에서 데이터베이스 설계는 어떻게 해아 하는지에 대해 살펴보았습니다. 마지막으로 이번 호에서는 데이터베이스를 구축하고 사용할 때 주의할 점을 중점적으로 다뤄보도록 하겠습니다.

이번 호에서는 데이터베이스를 구축하고 사용하는데 주의해야할 점을 말하고자 합니다. 아무리 설계를 잘했다 하더라도 제대로 구축하고 사용하지 못한다면 원하는 성능이 제대로 나올 수 없습니다. 하드웨어 사양이 아무리 좋아도 마찬가지입니다. 데이터베이스에 잠금이 발생해 속도가 느려졌는데, CPU 64개를 붙여놓은 엔터프라이즈 12000 모델을 구매한다고 해서 성능이 향상될 리 없습니다.

데이터베이스를 구축할 때 고려할 것

데이터를 클라이언트에 가져와서 처리하지 말자

서버에 있는 데이터를 클라이언트로 가져와서 처리하게끔 프로그램을 만드는 경우가 종종 있는데, 그 많은 데이터를 클라이언트로 가져오려면 속도가 무척 느려질뿐더러 네트워크 트래픽도 상당히 늘어납니다. 가능하면 프로시저 등을 통해 서버에서 데이터를 처리하고 그 결과 값만 클라이언트로 가져 오도록 만드는 게 좋습니다.

DBMS의 데이터 무결성 유지 기능을 적극 활용하자

주민등록번호는 13자리의 숫자로 이루어져야 합니다. 만약 주민등록번호가 10자리라면 가짜 주민등록번호이므로 입력을 막아야 합니다. 예전에는 이 작업을 클라이언트 프로그램에서 해줘도 어느 정도는 데이터의 안정성이 보장되었습니다. 클라이언트 프로그램으로만 입력이 가능했으니까요. 하지만 이제는 최종 사용자가 액셀 등을 사용해서 데이터를 임의로 접근하는 것도 가능하게 되었기 때문에 어떤 클라이언트 툴을 사용해서 데이터에 접근하든지 비정상적인 데이터는 입력이 되지 않게끔 막아야할 필요성이 생겼습니다. 따라서 클라이언트 프로그램에서 데이터의 안정성을 지키기보다는 서버에 주키 제약, 유일키 제약, 참조키 제약, 영역 제약 등을 모두 사용해 데이터의 무결성을 지키도록 노력해야 합니다.

영역 제약은 허용되는 데이터 값에 대한 제약입니다. 예를 들어, 고객의 마일리지가 규정상 0 이하로 내려갈 수 없다면, 0 이상의 정수만 입력될 수 있도록 영역 제약을 사용하는 것이지요. 이런 제약으로도 처리하기 힘든 복잡한 무결성도 프로시저나 트리거 등 서버에서 처리할 수 있는 방법을 동원하는 것이 여러모로 좋습니다. 이렇게 되면 업무 규칙이 바뀐다고 해도 서버 한 군데에서만 바꿔주면 되기 때문에 클라이언트 프로그램 모두를 바꿔주는 것보다 훨씬 간편합니다. 그렇게 하면 데이터베이스 서버의 부담이 가중되어 전체적인 성능이 나빠지지 않느냐구요? 설령 그런 경우가 있다고 해도 클라이언트 프로그램에서 데이터의 안정성을 보장하는 것이 아니라 애플리케이션 서버를 이용해 3티어(tier) 구조로 가는 것이 바른 길입니다.

트리거는 성능에 악영향을 미친다

한 테이블의 데이터가 변경되었을 때 자동적으로 다른 테이블의 데이터를 변경해야 한다면 어떻게 할까요? 그때는 트리거를 쓰면 됩니다. 다만 트리거는 상당 부분 성능을 저하시키게 됩니다. 게다가 MS SQL 서버와 같은 DBMS는 최근 버전에서도 여러 레코드가 한꺼번에 변경되었을 때 첫 번째 레코드에만 트리거가 실행이 되는 문제점이 고쳐지지 않았습니다. 그러므로 커서 등을 이용해서 한 번에 하나의 레코드만 변경이 되도록 만들지 않으면 트리거가 제대로 작동하지 않습니다.

따라서 가장 좋은 것은 아예 트리거를 쓸 필요가 없게끔 만드는 것입니다. 정규화를 철저히 하면 대부분의 트리거는 사용할 필요가 없습니다. 정규화나 제약으로도 구현할 수 없는 복잡한 무결성 강화에만 트리거를 사용하기 바랍니다.


null 허용을 피하자

null 허용을 피할 수 있으면 피하는 게 좋습니다. null은 ‘해당되는 값이 없다’는 의미와 ‘해당되는 값이 있으나 알지 못한다’라는 두 가지 의미로 해석될 수 있기 때문에 개발에 많은 혼란을 가져옵니다. null이 있더라도 isnull 함수 등을 이용해 적절한 다른 데이터로 변경해 처리할 수도 있지만 가능하다면 아예 null을 사용하지 않도록 합니다.


SQL문을 작성할 때 고려할 것

트랜잭션 시작 명령을 사용하자

반드시 commit을 해줘야 변경사항이 반영되는 오라클 같은 DBMS를 사용하지 않는다면, 데이터를 변경하는 insert, update, delete 문을 쓰기 전에 반드시 트랜잭션 시작 명령을 적어주는 습관을 들이는 것이 좋습니다. update 문을 쓸 때, 혹은 delete 문을 쓸 때 실수로 where 절을 안 써주면 모든 데이터가 변경되어 버리기 때문에 중요한 데이터가 날아갑 수 있답니다. 여러분은 그런 실수 안할 것 같죠? 천만의 말씀입니다. 실제로 국내의 저명한 리크루팅 회사에서 개발자의 실수로 모든 회원의 암호가 동일하게 변경되어서 회원들한테 사과하고 암호를 다시 입력받는 일이 벌어진 적이 있습니다. 필자가 근무하는 회사에서도 베테랑 개발자가 A라는 회원의 적립금을 올려주려고 했는데 where 이름 = ‘A"라는 조건을 깜빡 잊고 해주지 않아 모든 회원의 적립금이 동일하게 변해버린 경우가 있었습니다. 모 리크루팅 회사와는 달리 황급하게 데이터베이스를 복원해서 별 문제없이 지나가긴 했습니다만, 백업마저 없었다면 더 큰일이 벌어졌겠죠. 그 개발자 왈 엔터키를 치는 순간 ‘아차’하는 생각이 들면서 눈앞이 노래지고 아무 것도 생각할 수 없더라는 군요. 그런 경험은 안 할수록 좋습니다. 예를 들어 MS SQL 서버에서 트랜잭션 시작을 명시적으로 선언해주려면 다음과 같이 하면 됩니다.

begin tran
delete 아시아에서_제일_중요한_테이블

실수였다면 rollback tran 명령을 내려주고, 의도하는 대로 되었다면 commit tran 명령을 내려주면 됩니다. 이와 같이 일일이 begin tran 명령을 내리기 귀찮다면 자동 commit이 안되게끔 서버 설정값을 바꾸는 것도 고려해보기 바랍니다.

커서의 사용을 피하자

커서를 불필요하게 사용하는 것은 데이터베이스를 사용해보지 않은 개발자들이 흔히 저지르는 오류입니다. 커서란 전체 데이터를 한꺼번에 처리하는 것이 아니라 한 레코드를 읽어 와서 처리하고 그 다음 레코드를 읽어 와서 처리하는 과정을 루프를 돌면서 반복적으로 해나가는 기법입니다. 일반적인 프로그래밍 언어에서는 반복문 등을 이용해 많이 사용하는 기법이지만, 데이터베이스는 원래 집합 지향적으로 만들어져있기 때문에 커서를 사용하면 상당히 성능이 저하됩니다. 커서는 될 수 있으면 하나의 insert, update, delete 문으로 처리가 가능하도록 바꿔야 합니다.

필요한 항목만 불러오자

다음과 같은 SQL문은 그다지 좋은 것은 아닙니다.

select * from 공급자 where 지역 = ‘대전’;
별표(*)는 from 절에서 명시한 테이블에 소속된 모든 항목을 표시합니다. 하지만 꽤 많은 부하를 가져옵니다. 사실 테이블의 모든 항목을 다 가져와야 하는 경우는 그렇게 많지 않습니다. 번거롭더라도 필요한 항목만 적어주는 것이 좋은 습관입니다.
연산자 왼쪽의 필드는 변형하지 말자

다음과 같은 SQL문은 성능을 저하시키는 대표적인 예입니다.

select 상품명, 수량 from 발주 where substr(상품명, 1, 2) = ‘마소’;
인덱스를 지정하면 검색속도가 비약적으로 향상된다는 것은 지난 호에 말한 바 있습니다만, 이와 같은 SQL문은 상품명 필드에 인덱스를 지정했다 하더라도 이를 사용하지 못하기 때문에 테이블의 모든 데이터를 일일이 뒤져야만 합니다. 당연히 엄청난 성능 저하가 발생하겠죠. 따라서 SQL문은 다음처럼 바꿔야 합니다.
select 상품명, 수량 from 발주 where 상품명 like "마소%‘;
다만 이 경우에도 ‘%마소%’나 ‘%마소’처럼 찾고자 하는 문자열이 중간에 있거나 마지막에 있다면 인덱스를 사용할 수 없습니다. 즉, 인덱스가 걸려있는 필드에 대해 like 연산자로 비교할 때 맨 앞에 ‘%’나 ‘_’가 오는 경우에는 인덱스를 이용하지 않습니다.
select 상품명, 수량 from 발주 where 가격*100 > 100000;
이 SQL문 역시 연산자 왼쪽 필드가 변형되었기 때문에 속도가 많이 느려집니다. 다음과 같이 바꿔야겠죠.
select 상품명, 수량 from 발주 where 가격 > 100000 / 100;
특히 필자의 경험상 거의 대부분의 초보 개발자가 실수하는 부분은 날짜 필드에 조건을 줄 때입니다.
select 상품명, 수량 from 발주 where year(발주일) = 2003;
2003년에 발주한 상품명과 수량을 조회하는 이 SQL문은 발주일 필드의 모든 데이터를 일단 한번 year 함수로 처리한 다음 그 값을 2003과 비교하게 됩니다. 따라서 인덱스를 사용할 수 없고 부하도 많이 걸립니다. 따라서 다음과 같이 바꿔야 합니다.
select 상품명, 수량 from 발주 where 발주일 >= ‘2003.1.1’ and 발주일 < ‘2004.1.1’;

not 연산자를 쓰지 말자

not 연산자를 사용하면 인덱스를 사용하지 않기 때문에 가능하면 사용하지 않는 게 좋습니다. 예를 들어 지난 호 숙제 ?번의 답은 아래와 같습니다.

select 공급자이름, 지역 from 공급자 where 지역 not in ("서울‘, ’대전‘, ’인천‘);
만약 지역이 ‘서울’, ‘대전’, ‘인천’, ‘광주’, ‘수원’, ‘부산’, ‘제주’, ‘울산‘밖에 없다면 not 연산자를 쓰지 않고 다음과 같이 변경하는 것이 인덱스를 사용할 수 있기 때문에 훨씬 속도 향상에 도움이 됩니다.
select 공급자이름, 지역 from 공급자 where 지역 in (‘광주’, ‘수원’, ‘부산’, ‘제주’, ‘울산‘);

상관내포문을 피하자.

일반적인 하위질의(내포문)는 하위질의가 완전히 실행된 후 그 결과 값을 바탕으로 상위 질의가 실행됩니다. 그러나 하위질의와 상위 질의의 결과 값이 서로 연결되어 있는 경우가 있는데, 이를 상관내포문이라고 합니다. 상관내포문은 일반적인 하위질의와 형태상으로는 비슷해 보이나 하위질의에서 상위 질의의 테이블명이 사용되는 점이 다릅니다. 또한 상위 질의의 결과 값을 하위질의가 이용하므로 하위질의만 따로 실행시켰을 경우 에러가 발생한다는 것도 차이점입니다. 지난 호의 숙제 ??번이 상관내포문을 써야하는 예입니다.

select 상품번호, 공급자번호, 단가 from 발주 o1 where 단가 > (select avg(단가) from 발주 o2 where o2.상품번호 = o1.상품번호);
이 SQL문이 실행되는 순서를 보면 먼저 하위질의를 실행하기 위해 현재 상위 질의에서 검색된 레코드의 상품번호와 같은 레코드를 검색해서 평균 단가를 구합니다. 즉, o1 테이블의 첫 번째 상품번호가 105번이므로 앞의 하위질의는 실제로 다음과 같은 SQL 문을 실행하는 것과 동일합니다.

(select avg(단가) from 발주 o2 where o2.상품번호 = 105);
이 하위질의의 실행 결과, 상품번호 105번의 평균 주문단가가 205이므로 이제 상위 질의는 실제로 다음과 같은 질의를 실행하는 것과 동일해집니다.

select 상품번호, 공급자번호, 단가 from 발주 o1 where 단가 > (205);
o1 테이블의 첫 번째 레코드의 단가가 210이므로 자기 상품의 평균 발주 단가보다 높으므로 검색되고, 다음 레코드로 이동해서 앞의 과정을 반복하게 됩니다.

제대로 알지 못하는 경우는 아예 모르는 것보다 더 안 좋은 경우도 있습니다. 상관내포문은 어려워서 작성하기도 힘들지만, 상관내포문을 갓 배운 초보개발자들은 자기의 실력을 과시할 겸 다른 방법으로 구할 수 있는 정보라도 굳이 상관내포문으로 표현하는 경우가 있습니다.

상관내포문을 쓰면 성능이 상당히 저하가 됩니다. 꼭 써야 하는 경우라면 할 수 없지만, 다른 방법이 있다면 사용하지 않도록 합니다. 그리고 한 줄의 상관내포문보다 커서를 써서 반복적으로 루프를 돌려서 처리하는 게 오히려 빠른 경우도 있다는 것을 명심하십시오.

트랜잭션과 잠금 문제

개발 당시에는 잘 작동하던 시스템이 실제로 업무에 투입이 되었을 때 문제가 되는 경우가 종종 있습니다. 개발할 때에는 다수의 사용자가 동시에 한 데이터에 접근하는 경우가 별로 없습니다만, 실제 업무에서 동시에 다수의 사용자가 한 데이터에 접근하게 되면서 트랜잭션과 관련한 문제가 발생하기 때문입니다. 앞장에서 트랜잭션의 개념과 필요성, 그리고 트랜잭션 로그를 이용한 데이터베이스의 복구에 대해서 간단히 살펴보았습니다만, 그 외에 실무에서 데이터베이스를 사용하다 만나게 되는 트랜잭션과 관련된 사항을 몇 가지 더 말씀드리겠습니다.

실무에서 가장 많이 부딪히는 사례는 사용량이 많지도 않은데 데이터베이스가 먹통이 된 것처럼 아무 것도 처리하지 못하는 경우일 겁니다. 이 경우는 십중팔구 트랜잭션이 완료(commit)되지 않아서 데이터베이스가 잠겨 있기 때문입니다. 보통 락(lock)이 걸려있다고도 표현을 합니다.

잠금이 발생하는 이유

잠금이 왜 발생하는지 <그림 2>를 예로 들어 설명해보겠습니다. 재고가 10개인 상태에서 주문 A, B가 동시에 발생했다고 생각해봅시다. 주문이 들어오면 팔 수 있는 재고를 하나 감소시켜야 하기 때문에 주문 A에서 재고량을 하나 줄인 9개로 수정해서 저장합니다. 그럼 주문 B에서는 어떨까요? 주문 A와 동시에 주문된 것이므로 재고가 9개로 줄어들기 이전에 재고를 읽게 됩니다. 따라서 주문 B에서도 재고량은 10개로 읽어 들입니다. 당연히 주문 B에서도 재고량을 하나 줄인 9개로 수정해서 저장하겠죠. 주문 2개가 들어왔기 때문에 실제로 팔 수 있는 재고량은 8개가 되어야 함에도 불구하고 9개가 저장되어 버린 거죠. 이런 문제가 발생한 이유는 트랜잭션 사이의 간섭이 일어났기 때문입니다.

[그림 1] 동시 변경시의 문제

대부분의 DBMS에서는 이런 간섭을 줄이기 위한 매커니즘을 제공하는데, 그 중 대표적인 것이 데이터를 잠가(lock)버리는 것입니다. 주문 A가 재고량을 변경하기 전에 변경할 데이터를 미리 잠가버리고 재고량 수정이 끝나기 전까지는 다른 사용자가 그 데이터에 접근하는 것을 차단하는 겁니다. 따라서 주문 B는 주문 A가 종료된 다음에 진행이 되기 때문에 트랜잭션 사이의 간섭이 일어나지 않습니다.

[그림 2] 잠금을 이용한 동시 변경 문제 해결

이처럼 잠금은 동시에 한 데이터를 변경할 때의 문제점을 해결하기 위한 간단한 방법이지만, 이로 인한 또 다른 문제를 발생시킵니다.

commit 하지 않은 트랜잭션

오라클에서는 데이터를 변경해도 commit 명령을 내려주기 전까지는 트랜잭션을 완료하지 않습니다. 트랜잭션이 완료되지 않았기 때문에 잠겨있는 상태로 남아있고, 그 데이터는 다른 사용자가 이용할 수 없습니다. 문제는 데이터를 변경한 세션에서는 변경된 데이터를 그대로 보여주기 때문에 사람들이 종종 commit하는 것을 깜빡 잊는다는 겁니다. 이렇게 되면 사무실이 난리가 납니다. 잘 돌아가던 데이터베이스는 먹통인 상태로 응답을 하지 않고 여기저기서 시스템이 죽었다는 전화가 걸려옵니다. commit 명령만 내려주면 해결이 가능한 간단한 문제지만, 때로는 이런 문제를 해결하지 못해 하루 종일을 소모할 수도 있습니다. 이런 초보적인 실수를 하는 경우가 있냐구요? 실무에서 이런 경우는 비일비재하게 발생합니다. 특히 자동 commit이 디폴트 값이 아닌 오라클 등의 DBMS를 사용하는 경우에는 아예 처음부터 데이터를 변경하고 나면 commit 명령을 사용하거나, 오라클 접속을 끊는 버릇을 들이는 게 좋습니다. 자동 commit을 하는 DBMS라도 명시적으로 트랜잭션 시작 명령을 내린 경우엔 commit하지 않는 한 계속 데이터가 잠겨있게 되므로 주의해야 합니다.

교착상태

둘 이상의 트랜잭션이 각기 다른 데이터를 잠근 다음, 서로 상대방의 데이터가 잠김에서 풀리기를 기다리는 경우에는 대기 상태가 영원히 지속되는 문제가 발생합니다. 이를 교착상태(deadlock)라고 하는데, 일상생활에서 경험할 수 있는 교착상태는 <그림 3>처럼 교차로에서 서로가 서로의 진행을 막아서 발생할 수 있습니다.

[그림 3] 교차로에서의 교착상태

예를 들어 트랜잭션 A는 레코드 X를 잠근 다음 레코드 Y를 변경하면 끝나고, 트랜잭션 B는 레코드 Y를 잠근 다음 레코드 X를 변경하면 끝난다고 합시다. 두 트랜잭션이 따로 실행이 되면 아무런 문제가 발생하지 않지만, 트랜잭션 A가 레코드 X를 잠근 이후에 트랜잭션 B가 시작되어서 레코드 Y를 잠가버리면 어떤 일이 일어날까요? <그림 4>처럼 트랜잭션 A는 레코드 Y가 잠겨있기 때문에 더 이상 작업이 진행되지 못하고, 트랜잭션 B는 레코드 X가 잠겨있기 때문에 아무런 작업이 진행되지 않습니다.

[그림 4] 교착상태의 예

DBMS는 이런 교착상태를 감지해 강제로 어느 한쪽의 트랜잭션을 취소하여 교착상태를 해소합니다. 하지만 교착상태를 해결하기까지 어느 정도의 시간이 소요되므로 상당한 성능저하를 가져오게 됩니다. 가장 좋은 것은 교착상태가 일어나지 않도록 개발을 하는 것이죠. 첫째, 트랜잭션을 짧게 사용합니다. 트랜잭션이 길어지면 잠금도 오래가고 교착상태가 발생할 가능성도 커지게 됩니다. 둘째, 데이터를 사용하는 순서를 동일하게 하도록 노력해야 합니다. 즉, 레코드 X와 Y를 변경하는 트랜잭션은 모두 X를 먼저 잠근 다음 Y를 변경하게끔 개발을 한다면 <그림 4>와 같은 교착상태는 발생하지 않을 겁니다.

대규모 데이터의 변경

대규모 데이터를 변경할 때에도 잠금의 문제는 발생할 수 있습니다. 몇 개 레코드를 변경하는 경우엔 트랜잭션의 소요시간이 아주 짧으므로 데이터가 잠겨있는 시간도 짧고, 잠겨있는 레코드도 몇 개 안되기 때문에 문제가 되지 않습니다. 하지만 대규모 데이터를 변경할 때는 얘기가 다릅니다. 예를 들어 수백만 회원의 정보가 들어있는 테이블에서 어떤 필드 값을 변경한다고 해봅시다. 수백만 레코드의 데이터가 모두 변경될 때까지 회원 테이블이 잠겨있기 때문에, 그 시간동안 회원 가입, 정보 변경, 탈퇴 등이 모조리 불가능해집니다.

따라서 대규모 데이터를 변경할 때에는 커서 등을 이용해서 한 레코드씩 변경을 해주는 것이 좋습니다. 데이터베이스 책에서 커서를 될 수 있으면 쓰지 말라고 했다고요? 물론 그 말이 정답입니다. 커서를 쓰지 않으면 한 시간에 끝날 작업이 커서를 쓰면 두 시간이 걸릴 수도 있습니다. 그만큼 비효율적인 것은 사실입니다. 그래서 일반적인 경우는 커서를 쓰지 않는 것을 권장합니다. 다만 대규모 데이터를 변경하는 경우 1시간동안 모든 작업이 중지되는 것보다는 두 시간에 걸쳐 일어나지만 모든 작업이 원활하게 진행되는 쪽이 좋을 경우가 많습니다.

대규모 데이터의 조회

잠금은 데이터를 변경할 때만 일어나는 것이 아니라 데이터를 읽을 때에도 발생합니다. 예를 들어, 회원의 수가 몇 명인지 알아보기 위해서 회원 데이터를 읽고 있는 중간에 회원 가입이나 탈퇴가 이루어져 버린다면 정확한 회원수를 알아낼 수 없기 때문에 그 시간동안에는 잠금이 발생해 회원 가입과 탈퇴를 막는 것이죠. 이처럼 잠금이 발생하기 때문에 응용 프로그램을 만들 때 많은 데이터를 불러올 수 있게 만드는 것은 별로 바람직하지 않습니다. 기껏해야 화면에서 보고 처리할 수 있는 레코드는 몇백개 미만인데, 모든 데이터를 불러오느라 잠금이 발생해서 전체적인 데이터베이스 성능이 나빠지게 됩니다. 하지만, 예를 든 것처럼 회원수가 몇 명이 되는지 알아보려고 하면 전체 데이터를 조회할 수밖에 없습니다. 다만 그런 경우는 대부분 정확한 데이터가 필요한 것이 아니라 대략적인 것만 알아도 충분한 경우가 많은데, 그 경우엔 잠금이 필요 없습니다. 따라서 대규모 데이터를 대상으로 대략적인 값을 알고 싶을 때는 잠금이 발생하지 않도록 격리 수준(isolation level)을 최소로 변경해주는 것이 좋습니다. MS SQL 서버인 경우 격리 수준을 최소로 변경해주기 위해서는 set transaction isolation level read uncommitted라는 명령을, 기본 격리 수준으로 돌아가려면 set transaction isolation level read committed라는 명령을 내려주면 됩니다. 이렇게 하면 정확한 데이터는 구할 수 없지만, 잠금으로 인해 데이터베이스가 먹통이 되는 사태는 막을 수 있습니다.

잠금 문제를 일시적으로 해결하려면

데이터베이스가 아무런 반응을 보이지 않거나, 프로그램에서 Time out 오류가 많이 나는 경우엔 잠금이 발생하지 않았는지 조회해보는 것이 좋습니다. 오라클인 경우 v$lock을 조회해보면 잠금 정보를 알 수 있고, MS SQL 서버인 경우 sp_who 명령으로 잠금 정보를 알 수 있습니다. DBMS에 따라 잠금 정보를 알아내는 방법이 다르므로 해당 DBMS의 매뉴얼을 참고하기 바랍니다. 잠금 때문에 문제가 발생한 경우에는 일단 급한 불은 꺼야 하므로 kill 명령으로 해당 트랜잭션을 종료시켜버리면 문제를 해결할 수 있습니다. 그 후 반드시 왜 그런 잠금이 발생했는지 원인을 찾아 조치를 해야 합니다. 그렇지 않으면 계속해서 같은 문제가 발생할테니까요.

꾸준한 공부가 지름길

데이터베이스에 대해서 공부하기 시작한지 벌써 3개월이 되었습니다. 그동안 데이터베이스 공부를 열심히 하셨나요? 열심히 하셨다는 분에게 박수를 보냅니다. 노파심에서 여쭤보는데 정규화는 자신 있게 할 수 있으신가요? 만약 아니라면 다시 처음부터 꼼꼼하게 공부하길 권해드립니다. 그리고 열심히 하지 못했다는 분께는 다시 한번 격려의 말씀을 드립니다. 데이터베이스를 업무에 적용하는 데 필요한 지식은 상식 수준을 크게 벗어나지 않기 때문에 조금만 노력해도 상당한 실력 향상을 이룰 수 있습니다.

혹시, 이런 내용은 알지 못해도 별 문제가 없다고 생각하고 그냥 넘어가는 분은 없나요? 세상 모든 분야처럼 IT 쪽에도 일류 개발자는 그다지 많지 않답니다. 그래서 자신의 부족한 지식만으로도 충분히 만족하고 더 이상 앞으로 나아가려 하지 않고 있는 모습들이 엿보일 때가 종종 있습니다. 하지만 가정을 팽개치고 건강을 희생해가면서 평생 노력해도 도저히 따라갈 수 없을 거라는 절망감을 느끼게 하는 초절정 고수들은 여러분 상상보다 많습니다. 필자는 여러분에게 그 정도의 반열에 오를 것을 요구하는 것도 아닙니다. 단지 그런 사람들에게 ‘넌 개발자도 아냐’라는 비아냥을 듣지 않을 정도가 되기 위해서도 아직 가야할 길이 멀고 험난합니다. 매일 한 시간씩만 데이터베이스 공부에 투자하십시오. 여러분이 스스로 이정도면 충분하다고 생각하는 그 수준보다 최소한 한 단계 더 높은 수준이 될 때까지 말입니다. 그리고 지난 달 SQL 명령을 내리는 문제에 대한 정답풀이는 ‘이달의 디스켓’으로 제공합니다. 자신의 답과 비교해가며 설명 부분을 참고해가며 이해하기 바랍니다.