쑤나이퍼's diary

 MS-SQL 에서 제공하는 가장 좋은 기능이자 운영시 많은 문제를 갖고 있는 양날의 검인 복제(Replication) 에 대해 포스팅 합니다.

최근 한 DB 장비의 성능이 문제가 되서 장비를 2대로 분리 하는 작업을 하였습니다.

그런데 작업 후에 여러 가지 문제가 나타나는 걸 보는데요.

그 중 하나가 복제와 연관된 부분이고 참고할 사항이기에 정리해 봅니다.

위에서 언급한 것처럼 2대의 장비로 신규 구성하고 한 대의 복제를 받는 장비가 있었는데요.

신규 구성되는 장비에 대해서만 신경을 쓰다보니 복제 서버에는 많이 신경을 쓰지 못하였습니다.

그러다 보니 일일 통계를 구하는 Job 이 이틀 정도 실패를 했는데도 모르고 있다가 삼일째가 되어서야 현상에 대해 인지하기 시작하였습니다.

평상시에는 일찍 끝나는 작업인데도 불구하고 몇 시간이 지나도록 끝이 나지 않다가 결국은 Fail !

실패시 Event 에도 기록하지 않고 메일 설정도 없고.. 하.. 관리자의 부재가 여기서 나타나는 군요.

그래서.. 여기 저기 살펴보니..

File Size 증가가 1M(기본값) 으로 설정되어져 있고..

통계를 구하는 SP 에선 Isolate 가 uncommited 로 되어져 있었습니다.

이 복제 대상(Source)의 DB는 평균 2-300 Batch Request 씩 처리 되고 있는 Database에 대해  복제로 설정되어져 있었고..

이러다보니.. 복제는 받는 쪽에서는 끊임 없이 File size 가 증가가 되면서 또 통계 SP 에서는 Dirty read 를 시도하다보니..

내부적으로는 Latch 카운트가 엄청나게 증가하더니 결국은 Job이 실패하고 있었던것이죠.

이 때 성능 카운터로 살펴보니 Disk Queueing 이 100 이상을 오르락 내리락 하고 있었습니다.

간접적으로 SQL 에서는 latch 카운트 수치로 이상여부를 나타내었지만.. 실질적으로는 I/O lock 을 유발하는 상황이 아니었을까 유추하였습니다.

그래서...

여기서의 해결방법은 매우 간단하였습니다.

1. File Size 증가 (10% 이상 Free space 를 주었습니다.)

   alter database modify file ( name = 땡땡땡, size = 100GB )

2. 자동 증가 사이즈 변경

   alter database modify file ( name = 땡땡땡, filegrowth = 1GB )

3. 통계 sp 의 isolate 설정을 read commited 로 변경

   어차피 전일 데이타에 대해서 통계를 구하는 부분임으로..

   이 부분은 sp 개발하신 분이 미처 생각하지 못하고 어디서 퍼 온 소스 기반으로 작업하지 않았나 싶습니다.

이렇게 설정하고 다시 통계 잡을 구하니 10초 만에 끝나네요. OTL !

이번 경험으로 다시 한 번 느끼게 된 것이..

서버 프로그래밍을 할 때도 그렇고 DB 튜닝을 할 때도 마찬가지도 성능을 좌우하는데 있어서 가장 큰 영향을 미치는 부분은 ..

역시나 IO 였던것 같습니다.

한정된 자원의 효율적인 분배.

그런데.. 생각해 보면 이건 컴퓨터 상의 얘기만은 아니지 않나요 ?

우리 삶에서도 한정된 자원(시간, 돈, 체력 등)을 얼마나 효율적으로 나누어서 사용할 수 있느냐는 끝없이 선택해야만 하는 우리의 사명인것 같습니다. ㅎ

ps>> 글을 쓰고 나니.. 이건 복제에 대한 얘기가 아닌 듯 ㅋㅋ