..

먼저 개인적인 나의 소견은..

갑작스레 Sybase 를 사용 하는일이 생겼다..

전에 작업 환견은 오라클에 미들웨어를 써서 이런 문제에 대해서..

거의 무관심 햇다고 봐도 된다.

Sybase에게 고마운건 철저한 쿼리 플랜을 가지고 분석하고 수많은 데드락과 싸워야 한다는

것이다. 디포트로 Page 단위의 트랜잭션으로 인한 .. 누구의 말마따나 이건 개발자에게

지옥 같은 DataBase 같다.

미들웨어 없이 수많은 커넥션이 이뤄지는 곳에서 데드락의 개념과 회피 방법을 찾던중

좋은 자료가 잇는것 같아서 올린다!!! 우야가 ㅎㅎ

작성자 : 손호성 (NTFAQ.CO.KR)

http://www.ntfaq.co.kr or http://www.mcse.co.kr

안녕하세요. 이번이 두 번째 세미나입니다.

잡지에 실린 제 글을 보고 많은 분들이 메일 주셨습니다. 그분들의 진심어린 충고와

의견에 아주 많이 감사 드립니다. 잡지가 출간되고 제가 원고를 준비하는 시간에 여유가

없는 관계로 이번 달 컬럼의 주제도 필자의 임의로 선택하게 되었습니다. 이번 주

주제는 데드락(Deadlock)입니다. 뭔가 무시무시한 기분이 들죠~

저번 세미나였던 인스테드 오브 트리거는 데이터 무결성에서 트리거 부분까지

너무 많은 사항들을 한정된 지면에 넣으려다 보니, 컬럼을 읽기가 너무 좋지 않았던 것

같습니다. 뭐가 그렇게 쓸게 많다고,  글씨들을 빽빽하게 집어넣으니, 필자인 저도

읽기가 힘들더군요. 되도록 이면 이번 세미나에서는 이러한 현상을 지양하려고 합니다.

지루하지 않도록 쉬어가면서 재미있게 진행해보도록 하겠습니다. ^^;

데드락(Deadlock)에 대해서

이번 주제인 데드락은 데이터베이스 및 데이터베이스를 이용해서 다루시는

많은 분들에게 익숙한 주제일 것입니다. 설마 SQL 서버 매거진을 보시면서

데드락이라는 현상을 모르시는 분들은 없으시겠죠. 하지만 데드락의 실체를

아시는 분도 그다지 많지는 않으리라고 생각합니다. 그럼 어떤 상황들이 데드락으로

의심될 수 있는지 살펴보기로 하죠.

우선 데드락은 사용자가 한명뿐인 상황에서는 그다지 발생하지 않습니다.

동시에 최소한 두개의 커넥션(Connection)이 이루어지는 경우, 혹은 동시에

수백에서 수천의 커넥션이 이루어지는 경우면 더 자주 발생할 수도 있겠죠. 이때

커넥션은 데이터베이스 이용자 하나를 가르키는 것이 아니고 쿼리 분석기나 혹은

클라이언트/서버 애플리케이션, 데이터베이스 연동 웹 프로그램들이 데이터베이스에

접속하기 위해서 필요한 그러한 커넥션을 지칭합니다.

따라서 데이터베이스에는 user1이라는 사용자가 있다고 한다면 이 user1 사용자의

계정을 가지고도 여러 개의 커넥션들이 이루어질 수 있으므로, 커넥션과 계정을

헷갈리지 마시기 바랍니다. 물론, user1과 user2 사용자가 있고 데이터베이스에

각각 이 계정들을 가지고 액세스하는 애플리케이션이 있다면 각 사용자들은

하나의 커넥션들을 가지게 되는 것이죠. 어쨌든, 여러 커넥션들이 있을 때 데드락이

발생한다는 것입니다.

간단히 데이터베이스와 이에 연동되는 애플리케이션을 가지는 웹 사이트가 있다고 합시다.

개발자가 해당 웹 사이트를 만들고서 내부에서 테스트할 때는 아무런 문제가 없었다고

가정합니다. 회원 가입도 잘되고, 제품 리스트도 잘 출력되고, 검색도 원활히 수행됩니다.

그리고 속도도 빠르게 작동된다고 합시다. 그래서 이제는 오픈 해도 괜찮다는 상관의

허락을 받고서 서비스를 오픈햇습니다. 많은 사람들이 가입하고 이 사이트의

데이터베이스를 이용하게 되자 문제가 발생했습니다. 갑자기 데이터베이스 연동

애플리케이션의 처리 속도가 느려지고, 한참동안 기다린 후에야 데이터베이스

연동 결과가 출력되기 시작한 것입니다.

개발자가 생각하기에 "아하, 그럼 현재 웹 서비스에 접속한 사람이 많아서 그런게 아닐까?"

그래서 이 개발자는 윈도 2000의 성능 모니터에서 현재 웹 서비스의 동시 접속자 수와

데이터베이스 커넥션 수를 살펴보았죠. 그의 예상대로라면 웹 서비스의 동시 접속자

수와 데이터베이스 커넥션 수 모두가 높아야만 할 것입니다. 아니 이런, 실제로

웹 서비스 동시 접속자 수는 그다지 높지가 않았습니다. 그런데, 여기에 맞지 않게

데이터베이스의 커넥션 수치는 굉장히 높았습니다. 이게 무슨 일이지 하고서는

서버실의 데이터베이스 서버 앞으로 갔습니다. 그리고는 늘 하던 대로 작업 관리자를

열어서는 CPU 및 메모리 이용도를 살펴보았습니다. 그런데 메모리는 좀 사용되고

있는데, CPU는 그다지 이용되고 있는 것 같지 않았습니다. 즉 서버 상황에는 별다른

이상이 없었던 것이죠.

이런 경우에 데드락이 발생한 것으로 예상할 수 있습니다. 보다 정확하게 데드락이

발생했는지를 알고 싶다면 아래와 같은 메시지가 웹 페이지에 나타난다면,

데드락이 발생했다고 보시면됩니다.

즉, 프로세스 아이디 17번이 다른 프로세스와 교착상태에 빠져서

데드락 희생자(Deadlock victim)로 선택되어 해당 트랜잭션이 취소되었다는 것이다.

확실하게 데드락을 보여주는 것이다. 물론 다른 방법으로 데이터베이스를 모니터링해서

데드락을 확인할 수도 있습니다. (데드락을 추적하는 방법에는 SQL 서버 프로필러를

이용하여 데이터베이스의 상태를 추적하는 방법이 있고, SQL 서버 엔터프라이즈 매니저에서

잠금 정보를 보는 방법, 그리고 sp_lock와 같은 시스템 저장 프로시저를 이용해서

이러한 정보를 보는 방법들이 있습니다. 즉 T-SQL을 이용해서 데이터베이스의 상태를

추적한다는 뜻이죠.)

대략 정리하면 아래와 같은 상황들이 데드락으로 의심되는 상황들이라고 볼 수 있습니다.

-        데이터베이스를 이용하는 애플리케이션의 성능이 갑자기 떨어진다.

-        웹 서비스의 동시 접속자는 그다지 많지 않은데, 데이터베이스 커넥션 수는 굉장히

          혹은 기하급수적으로 증가하였다.

-        트랜잭션이 데드락으로 취소되었다는 에러 메시지를 출력한다.

-        프로필러에서 데드락이 표시되었다.

-        기타 등등.

즉 다양한 경우들이 발생할 수 있습니다. 특히 이중에서 특별하게 서버에 무리가 가는

작업이 없고, 특별히 데이터베이스에 저장된 데이터의 양이 급증하지 않았는데도,

동시 접속자가 늘어나는 증가율에 비해 해당 애플리케이션의 성능이 갑자기 떨어진다면,

데드락으로 의심할 수가 있습니다.

그럼 데드락은 우리가 기피해야만 하는 상황인 것임에 틀림 없습니다. 왜냐면 저희가

사용하는 서비스 혹은 애플리케이션의 성능을 아주 획기적으로 떨어뜨려주니깐 이렇게

미울 게 없죠. 그리고 사용자들이 받는 에러 메시지와 개발자가 상사에게 받을

스트래스 및 야근을 생각한다면, 되도록이면 데드락이라는 상황을 피해야만 하는 것이

당연하겠지요. 말도 기분 나쁘잖아요. 데드락이라니...쩝. 데드락에 대해 설명하기에

앞서 데드락을 유발시키는데 관련이 있는 두 가지 요소인 트랜잭션과 락에 대해서

잠깐 살펴보도록 하겠습니다.