Exchange 2003을 설치후 DC 서버종료시간이 길어지는 현상

Exchange는 AD환경에 아주 밀접하게 관련되어 있으며, 여러가지 AD 커뮤니케이션을 위해 여러가지 서비스를 제공합니다.

이런 서비스중 DSAccess 서비스 같은것은 여러가지 Exchange 컴포넌트를 위해 AD로부터 관련 케시정보를 제공합니다.

Information Store,MTA,그리고 AD환경에 필요한 다른 컴포넌트들도 이에 포함됩니다. 케시된 AD정보를 복원하기 위해 Exchange는 DC로부터 몇몇 직접적인 쿼리를 요구하기도 합니다.

Windows Server 2003 DC를 종료할때, 여러가지 서비스가 Windows 2000보다 빨리 종료되며, 이것은 Windows 20003에서 새로운 문제를 유발합니다.

예로 LSASS(로컬보안하위시스템)같은 서비스에는 DSAccess 와 아주 밀접하게 연관되어 있습니다. DSAccess를 확실하게 종료하기전에 이와 같은 서비스는 먼저 종료됩니다.

그래서 DSAccess서비스는 몇분동안 시스템이 종료되기까지 기달립니다.(기본으로 10분). 또한 Exchange의 다른 서비스들은 이런 현상때문에 사소한 문제가 있을수 있습니다.

1. 이와 같은 문제를 해결하기 위해서는 시스템 종료시 종료 스크립트를 만들어 실행하면 됩니다. 시스템셧다운시 다음과 같은 순서대로 종료시 Exchange 관련 서비스는 깔끔하게 종료할수 있습니다.
순서는 Exchange관련 서비스를 먼저 종료후, 나머지 관련 서비스를 종료하는 것입니다.

net stop msexchangeis
net stop msexchangemta
net stop msexchangemgmt
net stop msexchangesa
net stop resvc
net stop smtpsvc
net stop w3svc
net stop httpfilter
net stop http
net stop iisadmin
net stop winhttpautoproxysvc

2. 이 문제 해결에 대한 다른 접근 방법은 레지스트리 값을 수정하는 것입니다.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control 의 서브키중 WaitToKillServiceTimeout 의 값을 default 10분에서 20초(20000) 로 변경을 하면 됩니다.

이 값은 해당 서비스나 프로세스 스스로 종료을 하지 못하거나 delay가 발생할때, OS에서 강제적으로 delay가 걸리는 서비스를 종료하는 것입니다.




26-TechNetB_masthead_ltr.gif

Blocking 과 Dead-Lock에 대하여..

하나의 프로세스가 Table, Page 등에 대한 Lock을 붙들고 있어서 다른 프로세스가 오랜시간 계속하여 대기하고 있는 상태를 Blocking이라 하고, 두개의 프로세스가 서로 다른 프로세스가 잡고 있는 Table,Page Lock을 무한정 기다리고 있는 상태를 Dead Lock이라 한다. 이 Blocking과 Dead Lock은 DB Design 이나 응용프로그램을 잘못 작성한 경우에 발생할 수 있다.

Blocking이 발생하면 Application의 실행 속도가 현격히 저하되고, 심한 경우에는 클라이언트 입장에서 Hangup이 걸리는 경우가 있다. 즉, 한 사용자가 계속 자원을 사용하기 때문에 다른 사용자들이 무한정이 Waiting 상태가 되는 것이다. 이런 경우 다음과 같이 어떤 프로세스가 Blocking 을 하고 있는지 알아낼 수 있다.

SQL쿼리분석기에서 sp_who / sp_lock 프로시져를 통해서 어떤 프로세스에서 lock 상태인지 확인이 가능합니다. 물론 EM에서도 "잠금" 에서 확인이 가능하며 해당 프로세스를 종료시킬수도 있습니다.

[명령] Sp_who 

[결과] Spid  status  giname   hostname  blk   dbname 10  sleeping  sale1                                         

0       SALEDB 12    sleeping  sale1                                        

10      SALEDB 13    sleeping  sale1                                        

12      SALEDB 

[분석] 위의 경우는 spid 10번에 해당하는 유저가 12번,13번에 대해 Blocking을 걸고 있는 경우이다. 일시적으로 이러한 Blocking현상은 발생할 수 있지만 만약 한 유저가 수십명에 대해 Blocking을 잡고 있으면, 클라이언트는 Hangup이 된 것처럼 느끼게 될 것이다.

이런 경우 해당 유저가 사용하는 프로그램을 검토해 볼 필요가 있으며, Locking을 줄이며 트랜잭션의 길이가 짧도록 수정할 필요가 있다. 만약 위의 경우 10번 프로세스를 죽이기 위해서는 다음 명령을 사용할 수 있다 : KILL 10 또한 Sp_lock을 사용하면 어떤 Table, page에 대해 어떤 Locking이 걸려 있는지 찾아볼 수 있다.

Dead Lock의 경우는 SQL Server에서 자동으로 하나의 프로세스를 Kill함으로 인해 Dead lock을 풀어주게 된다. Kill되는 프로세스를 Victim이라고 하며 이것은 Log에 기록되게 된다. Dead Lock이 발견된 경우는 해당 프로그램을 즉시 수정할 필요가 있다.

모니터링은 Windows 퍼포먼스 모니터나, SNMP를 이용하는 툴에서 하는게 좋지 않을까..합니다. 퍼포먼스 모니터등은 순간적으로 lock을 걸린후 트랜잭션 종료후 lock이 풀리기 때문에 퍼포먼스 모니터에서는 계속해서 값이 체크되니 혼동하지 마세요..

lock이나, blocking 해결은 처음부터 lock이나 blocking이 발생하지 않도록 쿼리점검을 확실하게 하는거와 더불어 트랜잭션을 최대한 짧게 설정하는것이지만, 일단 발생한 것에 대해서는 해당 프로세스를 죽이거나, 다음번 lock 발생시 시간제한을 통해서 종료 하는 설정을 해주는 것도 좋다.

SELECT @@LOCK_TIMEOUT
결과값이 -1 은 default값이며 제한(무기한 대기)이 없다.

SET LOCK_TIMEOUT 1800 (밀리초 이므로 3분)

이 설정은 해당 트랜잭션을 종료시키지 않고, 오류메시지를 반환하므로 응용프로그램에서 이오류에 대한 예외처리를 꼭 해줘야 합니다.

출처 : 데브피아

ADSI & WMI Scripts 생성툴

다음 2개의 툴은 MS에서 제공하는 툴로 ADSI 및 WMI관련 개체 클레스 및 Attributes 를 자동으로 스크립팅 코드를 생성해 주는 툴입니다.

해당 개체를 정확히 알지 못해도 쉽게 생성을 해주며, 해당 샘플코드를 이용하실수 있습니다.

참 좋은 툴인듯..... ADSI Scriptomatic : 다운로드


The Scriptomatic Tool : 다운로드




10-ADSI_Scriptomatic.gif
10-Scriptomatic_Tool.gif