728x90

SQL Server 관리자 분들에게 도움이 되는 중요한 내용이라 퍼왔습니다.

마이크로소프트에서 기술 지원을 하고 계신 한기환님 블로그에서 가져왔습니다.

http://optimizer.tistory.com/entry/KILL-UOW

(기환님 메시지 남기고 펐어요! ^^)


아래 본문입니다.

------------------------------------------------------------------------

KILL UOW

2008/04/14 23:36

[공장이야기]

KILL 처음 접했을 '죽인다는 표현을 썼어야 했을까?'라는 의구심을 갖었었다. 지금은 'KILL 없으면 서비스를 재시작해야 하나?' 라는 반문 때문에 감사하며 쓰고 있다. 하지만, KILL로도 죽지 않는 생명력 강한 트랜잭션 있으니, 분리된(orphaned) 분산 트랜잭션이 바로 여기에 속한다. 관리자의 입장에서 보면 이러한 분산트랜잭션은 아주 골치가 아닐 없다. 그렇다면 해결책은 무엇인가? 그렇다. 재시작하면 깔끔히 사라진다. :-), 재시작없이 해당 세션을 종료할 있는 방법을 소개하려는 것이 글의 목적이다.

[문제]
사용되지 않는 분리된 분산트랜잭션용 세션(SPID=-2) sysprocesses에서 확인되었다. 서비스 재시작없이 세션을 종료시키고자 한다.

[해결]
다음 절차에 따라 분리된 분산트랜잭션을 KILL 시킬 있다.

1)
분리된 분산트랜잭션 확인
분리된 분산트랜잭션은 실제 세션ID 연결되어 있지 않고 인위적으로 -2라는 값을 갖는다.
select * from sys.dm_exec_sessions WHERE Session_ID = '-2';

2)
분리된 분산트랜잭션의 작업단위(UOW:Unit Of Worker) 확인
UOW
sys.dm_tran_locks 동적 관리 뷰의 request_owner_guid 열에서 가져올 있는 GUID이다.
select request_owner_guid, * from sys.dm_tran_locks where request_session_id = '-2';

3) KILL UOW
분산트랜잭션이 아닌 경우 UOW값은 00000000-0000-0000-0000-000000000000 으로 나타난다.
다음은 UOW값을 'D5499C66-E398-45CA-BF7E-DC9C194B48CF'라고 가정하고 KILL하는 예이다.
KILL '
D5499C66-E398-45CA-BF7E-DC9C194B48CF'

또는 구성 요소 서비스(dcomcnfg)에서도 미결 분산트랜잭션을 종료할 수 있다.
"
관리도구 - 구성 요소 서비스 - 내 컴퓨터 - 분산 트랜잭션 코디네이터 - 트랜잭션 목록"까지 선택 후,
오른쪽 화면의 목록 중 "작업 ID 단위"값이 위에서 확인한 UOW 값과 같은 분산 트랜잭션을 확인한다.
해당 분산 트랜잭션에서 오른 클릭 후 "해결"메뉴에서 "커밋:중단:무시" "중단" 선택

[참조]
1. KILL (SQL Server 2005 BOL)
http://technet.microsoft.com/ko-kr/library/ms173730.aspx

2.
특정 세션ID 롤백되고 있는 경우에 진행율 확인하기
세션ID 54 KILL하여 롤백중인 상태라면 다음과 같이 확인 가능하다
KILL 54 WITH STATUSONLY;

3.
특정 SPID 대해 롤백이 진행 중인 경우 특정 SPID 대한 sp_who 결과 집합의 cmd 열에 KILLED/ROLLBACK 표시된다.

4. SQL Server 2000에서는 다음과 같이 syslockinfo req_transactionUOW컬럼각으로 UOW 확인한다.
select req_transactionUOW, * from syslockinfo where spid='-2'

HTH,
한기환

728x90

김정선의 SQL Server 컨설팅 이야기

암시적 소유자로 인한 CacheMiss 한 방에 해결하기



사용자 삽입 이미지
김정선(jskim@feelanet.com)

필라넷 DB사업부 수석컨설턴트

SQLServer 아카데미/트라이콤 교육센터 강사

 

Microsoft SQL Server MVP

MCT/MCITP/MCDBA
 



무슨 얘기할려구?

역시 낚시용 제목인가? 너무 거창한 듯 합니다. 이번 컨설팅 사례는 SQL Server에서 개체 참조 시 소유자명을 생략한 경우, 즉 흔히 말하는 암시적 소유자상태에서 Procedure Cache(이젠 Plan Cache라고 부르는)에서 실행할 쿼리의 플랜을 찾지 못하는 현상(CacheMiss)이 발생하는지? 그리고 이를 한 방에 해결할 수 있는 방법이 무엇이 있을까?를 고민하고 그 결과 생각해낸 특정 방법을 테스트해 본 결과입니다. 해당 고객 사에는 전반적인 기술 이슈는 전달을 했지만 아직 직접적으로 반영된 상태는 아닙니다. 그러나 이와 유사한 환경을 가진 다른 사용자 시스템이 많을 것으로 보여 컨설팅 결과를 공유하고자 합니다. 혹시 관심 있다면 테스트해보시기 바랍니다.

 

시스템 환경

 

항목

결과

OS

당연히 Windows Server… ^^

SQL Server 버전

2000

솔루션

CRM 관련 외산 솔루션 (ASP 기반)

 

 

 

 

뭔 일이 있었는데?

 

배경

쿼리 성능의 중요한 한 축을 차지하는 것이 바로 “Procedure(Plan) Cache”의 재사용 능력입니다. 쿼리를 처음 실행 할 때 한 번 컴파일 과정을 거치고 나면, 그 결과로 도출되는 쿼리 계획(Query Plan) Cache에 저장해 두고, 이후 동일한 쿼리가 호출되고 재사용 요건을 만족하게 되면 다시 컴파일 과정을 거치지 않고 해당 쿼리 계획을 Cache에서 바로 참조해서 실행하는 것이죠. 이러한 쿼리 계획 재사용 능력을 높이기 위해서는 기본적으로 두 가지 튜닝 이슈가 발생합니다. 바로 1) 쿼리가 잘 Caching될 수 있도록 도와주는 것 그리고 2) Cache된 계획을 잘 재사용할 수 있도록 도와주는 것이 그것입니다-김정선의 생각 ^^.

 

그런데, Cache된 계획을 재사용할 때 즉 동일한 쿼리 계획이면 재사용 요건을 만족하는가? 라는 것을 평가할 때 중요한 키의 하나로 검사 받는 것이 바로 개체 소유자 지정에 관한 이슈입니다.

 

결론부터 얘기하죠,

SQL Server에서는 개체(특히 이 경우의 프로시저)를 참조할 때 개체 이름만 지정하지 말고 개체 소유자명(owner.objectname)을 함께 지정하는 것입니다-사실 여기에는 개체의 종류 및 기타 요소에 다른 차이가 많으므로 현재 사례로만 국한해서 설명합니다-특히 저장 프로시저의 경우, 프로시저를 만들 때 지정한 사용자명(정확히 소유자로 지정된 사용자명)과 해당 프로시저를 호출할 때 사용자명이 다른 경우에 개체 소유자명을 생략하고 호출하면 문제가 될 수 있다는 것입니다.

 

상황 재현

예를 들어 보죠,

Sales라는 데이터베이스는 로그인 명이 ‘sa’인 관리자가 만들었습니다. 따라서 ‘sa’라는 로그인이 Sales 데이터베이스의 생성자이며 자동으로 해당 DB에서 ‘dbo’라는 사용자명(USER_NAME())으로 작업하게 됩니다. 여기에 해당 DB를 사용하는 ‘John’이라는 로그인이 있으면 해당 DB의 사용자명 또한 ‘John’으로 지정되어 있다고 가정합니다.

 

1) ‘dbo’ 사용자명으로 개체 생성하기

DB를 만들고 소유한, ‘dbo’라는 사용자가 다음과 같이 프로시저를 만듭니다. 두 프로시저의 소유자는 dbo로 지정되었습니다. (명시적이건 암시적이건)

 

예제 프로시저 생성

 

CREATE PROC dbo.pTest1

AS

go

 

CREATE PROC dbo.pTest2

AS

go

 

 

2) ‘John’ 사용자로 개체 참조 시 암시적 소유자명 사용하기

이제 ‘sa’-‘dbo’가 아닌 ‘John’이라는 사용자로 위에서 생성된 프로시저를 호출할 때, 소유자명을 생략한다면 어떻게 될까요?

다른 사용자로 개체 호출 시 Profiler에서 CacheMiss 발생 여부 모니터링

 

SETUSER 'John'

 

-- case1: 명시적 소유자

-- case2: 암시적 소유자

WHILE 1 = 1

BEGIN

--         exec dbo.pTest1

           EXEC pTest1

          

           WAITFOR DELAY '00:00:00.200'

 

--         exec dbo.pTest2

           EXEC pTest2

          

           WAITFOR DELAY '00:00:00.200'

END

SQL Server가 컴파일 과정의 일부인 이름 해석 단계에서 개체를 검사할 때 어떤 규칙을 사용하는지 알고 계시죠? 첫 번째는 누구? 두 번째는 누구? … 무려 다섯 단계 정도나 되죠. 그 첫 번째는? , 현재 사용자입니다. 예제대로라면 “EXEC pTest1”는 사실 상 “EXEC John.pTest1”로 해석이 된다는 것이죠. John.pTest1라는 프로시저가 Cache에 존재하는지 이름 해석을 수행하게 됩니다. 그럼 못 찾겠죠? CacheMiss라는 이벤트가 Profiler를 통해서 발생할 수 있습니다.

 

3) 모니터링 결과

예제는 두 프로시저는 0.2초 간격으로 무한 루프를 돌면서 호출합니다. 다음은 CacheMiss가 발생하는 것을 Profiler에서 추적한 화면입니다.

 

[그림] Profiler에서는 SP:CacheMiss 이벤트 추적 결과

사용자 삽입 이미지
 

CacheMiss가 계속 발생되고 있는 것을 볼 수 있습니다. 그렇다고 프로시저가 아예 호출되지 않는 건 아니겠죠? SQL Server가 첫 번째 현재 사용자명으로 개체를 찾지 못하면, 두 번째로 사용하는 소유자명이 바로 ‘dbo’. 따라서 두 번째 작업에서 개체를 찾고 실행할 수 있게 될 것입니다.

위 예제에서 주석으로 처리된 부분 dbo.pTest1을 해제하고 실행하면 더 이상 CacheMiss는 발생하지 않게 됩니다.

 

이상 김정선의 혼자만의 상상의 나래였습니다 ^^;

 

 

그래서 어떻게 해결했는데?

 

뭐 실행만 되면 되지, CacheMiss 발생한다고 성능이 얼마나 느려질까? 맞습니다. 뭐 얼마나 차이가 있겠습니까 ^^; (확인을 못해본 관계로). 그렇지만, 서두에서 언급한대로 발생하지 않아도 될 부가적인 Cache Miss로 인한 오버헤드는 해결하는 것이 옳을 것입니다. 문제는 여기서 시작됩니다. 결론은 모든 프로시저 호출 시 dbo.를 붙여주어야 한다는 것인데, 프로그램 안에 하드 코딩 된 그 많은 프로시저를 다 고칠 수는 없는 노릇 OTL.

 

뭐 좀 간단한 방법은 없을까? (이것이 모든 관리자의 마음 ^^)-모 드라마에서 유행했던 거 좀 쉽게 쉽게 가자’)-공감 100%.

그래서 생각해 본 방법. 결론은 개체 소유자와 호출자가 동일하면 된다는 것인데. ‘John’을 해당 DB의 소유자(db_owner)로 만들어 버리면, 자동으로 ‘John’‘dbo’ 사용자명으로 실행될 것이고 그럼 자동으로 현재 사용자명이 ‘dbo’가 되어서 첫 번째 CacheMiss를 피할 수 있지 않을까? 라는 것이었습니다. 그것도 프로시저가 호출되는 시점에서 라이브로 작업을 했을 때요……물론 여기엔 어떤 부작용이 있을 수도 있을 겁니다. 어쨌든 테스트해 봤죠 ^^

 

특정 DB의 소유자를 다른 로그인으로 바꾸기

 

USE testdb

 

-- 주의: 기존 사용자면 오류 발생, 제거해야함

-- EXEC sp_adduser 'John'

EXEC sp_dropuser 'John'

EXEC sp_changedbowner 'John'

 

 

DB의 소유자를 변경할 때, ‘sp_changeobejctowner’를 이용하시면 되죠? 주의하실 것이 있습니다.

예제 코드의 주의를 달아두었으니 참조하세요.

 

앞의 반복 호출을 수행하고 있는 상태에서, 이 코드를 수행하면 CacheMiss가 바로 중단되는 것을 알 수 있습니다. OK~

 

 

더 할 말 있남?

너무 심각하게, 진지하게 받아들이지 않으셔도 될 것 같습니다. 그냥 오호~ 정도 ^^.

결론은 간단할 것 같습니다. 그냥 개체 참조할 때 소유자명 꼭 쓰세요~ 귀찮으면 그냥 DB에 오로지 1명의 사용자만 존재하도록 만든다? ^^

 

아참, 프로시저 접두사도 sp_ 시작되면 CacheMiss 2번 이상 발생되는 거 아시죠? ^^

 

 

주의

이 내용은 김정선이 개인적으로 실험한 결과입니다. 절대적인 근거 자료는 아니니 참고 사항으로 보시기 바랍니다. 그 어떤 보장도 하지 않습니다.

728x90

사용된 명령어 정리

저장 프로시저
저장 프로시저 이름 설명
sp_readerrorlog SQL Server 오류 로그를 반환합니다.
sp_cycle_errorlog SQL Server를 재시작하지 않고 새로운 오류 로그 파일만 생성합니다.
sp_helpserver master.dbo.sysservers 시스템 테이블에 등록된 정보를 반환합니다.
sp_dropserver master.dbo.sysservers 시스템 테이블에서 서버를 삭제합니다.
sp_addrserver master.dbo.sysservers 시스템 테이블에 서버를 등록합니다.
sp_serveroption master.dbo.sysservers 시스템 테이블에서 등록된 서버의 옵션을 변경합니다.
sp_blocker_pss80 잠금 정보와 블로킹하는 프로세스와 블로킹 당하는 프로세스의 정보를 반환합니다.
http://support.microsoft.com/default.aspx?scid=kb;en-us;299518
sp_tempdbspapce tempdb 의 공간 사용 정보를 반환합니다.
sp_configure 서버의 구성 옵션을 변경합니다.
sp_attach_db 데이터베이스를 SQL Server에 연결합니다.
sp_attach_single_file_db 로그 파일이 손실된 데이터베이스를 SQL Server에 연결합니다.
sp_detach_db 데이터베이스를 분리합니다.
sp_resetstatus 데이터베이스에서 주의 대상 플래그를 해제합니다.
sp_helpfile 현재 데이터베이스 파일의 물리적 이름 및 특성을 반환합니다.
sp_change_users_login 로그인 계정과 사용자 계정의 연결을 설정합니다.
sp_hexadecimal Binary값이나 Decimal값을 16진수 형태의 varchar 타입으로 변경한 값을 반환합니다.
http://support.microsoft.com/KB/246133
sp_help_revlogin 원본과 동일한 SID와 패스워드를 가지는 로그인을 생성하는 스크립트를 반환합니다.
http://support.microsoft.com/KB/246133
 
DBCC 명령어
DBCC 명령 설명
DBCC ERRORLOG 새로운 SQL Server 오류 로그를 생성합니다.
DBCC SHOW_STATISTICS 인덱스의 통계 정보를 보여 줍니다.
온라인 설명서 참조.
DBCC SHOWCONTIG 인덱스의 단편화 정보를 보여 줍니다.
온라인 설명서 참조
DBCC DBREINDEX 인덱스를 재구성합니다.
온라인 설명서 참조
DBCC INDEXDEFRAG 인덱스의 페이지를 재정렬합니다.
온라인 설명서 참조
DBCC SQLPERF
(WAITSTATS)
각 대기 유형별로 대기 시간을 확인합니다.
DBCC SQLPERF
(LOGSPACE)
로그 파일의 사용 공간을 확인합니다.
온라인 설명서 참조
DBCC INPUTBUFFER 해당 프로세스의 명령문을 확인합니다.
온라인 설명서 참조
DBCC CHECKDB 지정한 데이터베이스에서 모든 개체의 할당과 구조적 무결성을 검사합니다.
온라인 설명서 참조
DBCC CHECKTABLE 지정한 테이블에서 할당과 구조적 무결성을 검사합니다.
온라인 설명서 참조
DBCC DBRECOVER 데이터베이스를 재시작하지 않고 복원합니다.
DBCC REBUILD_LOG 로그 파일 손상 시에 새로운 로그 파일을 생성합니다.
DBCC TRACE 추적 플래그를 설정합니다.
온라인 설명서 참조
DBCC TRACESTATUS 추적 플래그 설정 여부를 보여 줍니다.
온라인 설명서 참조


자세한 설명은 온라인 설명서와 SQL Server DBA 가이드를 참조하기 바랍니다.
 
유틸리티
유틸리티 이름 설명
Portqry.exe 윈도우즈 서버에서 사용중인 포트 상태를 점검합니다.
http://support.microsoft.com/kb/310099
Componet Checker
(cc_pkg.exe)
MDAC 버전 정보 및 파일 정보를 점검합니다.
http://msdn.microsoft.com/data/mdac/downloads/default.aspx
SQLDiag.exe SQL Server 진단 툴입니다.
C:\Program Files\Microsoft SQL Server\MSSQL\Binn
Ostress.exe 커넥션 및 스트레스 테스트를 합니다.
http://www.microsoft.com/downloads/details.aspx?FamilyId
=5691AB53-893A-4AAF-B4A6-9A8BB9669A8B&displaylang=en
Rebuildm.exe 시스템 데이터베이스를 재구성합니다.
C:\Program Files\Microsoft SQL Server\MSSQL\Binn
DTCPing.exe MSDTC 의 구성 정보와 상태 정보를 점검합니다.
http://support.microsoft.com/default.aspx?scid=kb;ko;306843
 
시작옵션 및 추적 플래그
시작 옵션 및 매개 변수 설명
/d master 데이터베이스 데이터 파일의 위치를 지정합니다.
/l master 데이터베이스 로그 파일의 위치를 지정합니다.
/e SQL Server 오류 로그 파일의 위치를 지정합니다.
/f 최소 구성으로 시작합니다.
/m 단일 사용자 모드로 시작합니다.
/c SQL Server를 서비스로 시작하지 않고 응용 프로그램으로 시작합니다.
/g 확장 저장 프로시저, OLE 자동화 개체, 분산 쿼리 등을 위한 메모리 공간을 MB단위로 지정합니다.
/x CPU 시간과 캐시 적중률 통계를 유지할 수 없도록 합니다. 해당 정보를 모니터링할 필요가 없는 경우에 지정하면 성능이 다소 향상됩니다.
-T 추적 플래그를 설정합니다.
T1118 모든 데이터베이스에 유니폼 익스텐트만 할당합니다.
(7.0 에서는 인덱스 생성 시 등에 오류가 발생합니다.)
T1204 교착 상태를 모니터링하여 SQL Server 오류 로그에 기록합니다.
T1807 UCN 경로를 이용하여 네트워크 드라이브에 데이터 파일 및 로그 파일을 생성할 수 있습니다.
T2520 DBCC PAGE 등 문서화 되지 않은 DBCC 명령어의 매개 변수를 DBCC HELP를 통해서 확인 합니다.
T3604 DBCC 실행 결과를 화면에 출력합니다.
T3605 DBCC 실행 결과를 SQL Server 오류 로그에 기록합니다.
T3607 모든 데이터베이스에서 인스턴스 복구 프로세스를 생략합니다.
T3608 master 데이터베이스를 제외한 모든 데이터베이스에서 인스턴스 복구 프로세스의 실행을 생략합니다.
T3609 tempdb 생성을 생략합니다.
T4013 새로운 연결이 생성되는 경우 해당 정보를 SQL Server 오류 로그에 기록합니다.
T4220 Startup procedure의 실행을 비활성화합니다.
T7300 OLEDB의 보다 상세한 오류 메시지를 반환 받을 수 있습니다.
T8602 인덱스 힌트를 적용하지 않습니다.
T8755 잠금 힌트를 적용하지 않습니다.

마치면서

"이 세상에 진리는 존재하지 않는다, 객관성을 가장한 주관적 해석만이 존재할 뿐이다"라는 말이 있습니다. 지금은 최선의 방법이라고 생각할지 모르지만 하룻밤이 지나고 나면 더 적절한 방법을 발견하거나 추가적인 조치가 미비했음을 인지할 때가 있습니다. 점차 엔진이 발달하고 핫픽스가 개발되어짐에 따라서 어제의 방법이 더 이상 최선의 선택이 아닐 수도 있다는 사실을 유념하시기 바랍니다. 이 조그마한 지식을 바탕으로 끊임없이 발전하는 여러분을 기대합니다.

+ Recent posts