1. C:\Windows\winsxs
용도 : 하위 호환성 보장을 위하여 이전 버전의 DLL들을 저장해 놓는다.
제거 유무 : 서비스 팩이 설치 된 경우 제거 도구(VSP1CLN.exe)를 이용할 수 있으나, 그외에는 공식적으로 MS에서 지원하는 방법은 없다. 다만 이미 대체된 DLL 임으로 소유권을 가져와서 삭제 해도 큰 문제는 않될 꺼 같다. (백업 받고 진행 하고, MS 공식 입장은 삭제 불가 임을 명심하자)

2. C:\ProgramData\Microsoft\Windows\WER\ReportQueue
용도 : Windows 에러 레포팅
제거 유무 : Disk Cleanup 툴을 통해 제거 가능

테이블 잠금을 사용하지 않을 경우 table lock on bulk load 옵션이 on으로 설정되지 않으면 기본적으로 행 수준 잠금이 사용됩니다. sp_tableoption을 사용하여 table lock on bulk load 옵션을 설정하면 대량 가져오기 작업을 수행하는 동안 테이블에 대해 잠금 동작이 설정됩니다.

sp_tableoption 'dbo.bulkTest’, ‘table lock on bulk load’, ‘ON’;

아니면 아래와 같이 해당 구문 이용 시 힌트를 이용할 수 있습니다.

http://msdn.microsoft.com/ko-kr/library/ms180876.aspx
http://msdn.microsoft.com/ko-kr/library/ms173530.aspx

Database 에서 속성을 클릭했더니… 왠걸 아래와 같은 메세지가 발생 함께 실패하는 군요.

Cannot show requested dialog.
Additional information:
Cannot show requested dialog. (SqlMgmt)
Property Owner is not available for Database ’[     ]’.  This property may not exist for this object, or may not be retrievable due to insufficient access rights.
(Microsoft.SqlServer.Smo)

보통은 원래 있었던 DBO 로그인이 삭제되어서 발생 하는 문제라고 합니다.
해결방법은 간단하군요. Database의 Owner를 변경해 주시면 됩니다.

USE UserDB
EXEC sp_changedbowner 'sa'

출처 : http://www.sqlcoffee.com/Troubleshooting011.htm

아래에서 확인 할 수 있듯이 실제 쿼리 수행 시간은 0.1 초 입니다. (단위 : 마이크로 세컨드)

하지만 Audit Logout 에는 엄청난 시간이 걸리는 군요.

솔직히 왜 이렇게 오래 걸리는 지 확인은 모두 못했습니다.
다만 이 시간은 해당 Connection이 연결된 시점부터 종료된 시점을 의미한다는 것을 확인 했습니다.
중요한 것은 Applicaiton 입장에서 언제 Response 결과는 받느냐 입니다.
결론은 16시 22분 11초 593에 실행 되어 16시 22분 11초 603 에 실행이 종료가 되며 해당 결과는 Application 에 전달 된다는 점 입니다.

즉 Database 입장 에서 자신은 이미 데이터를 모두 전달했기 때문에 Application의 느림 현상은 It’s not my fault 가 됩니다. 아래는 위의 경우 Application에서 측정한 실행 결과 입니다.

Audit Logout 과 관계 없이 2.6초가 소요 되었습니다.

그렇다면 Audit Logout이 Application의 성능에 영향을 미치는 경우는 어떤 것이 있을까요?
먼저 Network 성능 이슈를 생각 할 수 있습니다.
그리고 다음으로 Application 성능 이슈를 생각 할 수 있습니다.

아래는 간단하게 만들어 본 OLEDB 연결 프로그램 입니다.
보시는 것 처럼 객체 선언 이후에 ReadLine () 함수를 호출 하여 대기 하도록 했습니다.

string source = "Provider=SQLOLEDB;Data Source=localhost;Initial Catalog=TEST;" +
            "UID=sa;PWD=12345;" +
            "OLE DB Services = -1;";
            OleDbConnection conn = new OleDbConnection(source);
            try
            {
               conn.Open();
               Console.WriteLine("DB Connection OK");
               string myInsertQuery = "Select * from T1";
               OleDbCommand myCommand = new OleDbCommand(myInsertQuery);
               myCommand.Connection = conn;
               myCommand.ExecuteNonQuery();
                            }
            catch(Exception ex)
            {
              Console.WriteLine("DB Connection Fail");
              Console.WriteLine(ex);
            }
            finally
            {
               if(conn !=null)
                {

                    conn.Close();
                }
            }
            Console.ReadLine();

결론은 정확하게 아래와 같이 Readline() 에서 대기했던 시간이 Audit Logout에 반영 되는군요.
 

이번에는 좀 더 오래 대기 시켜 보겠습니다.
역시 바로 반영됨을 확인 할 수 있었습니다.
 

결론을 말씀 드리자면 객체가 생성된 범위 내에 있을 경우 쿼리 실행은 종료 및 연결 종료가 진행 됐더라도 객체 선업의 외부로 나갈 때 혹은 프로세스 종료 그리고 연결 대기 시간의 Timeout 까지는 연결이 지속 되고, 이는 바로 Audit Logout의 Duration으로 표현 되게 됩니다.

마찬 가지로 아래와 같이 쿼리를 실행 하기 직전에 대기 시간을 갖게 만들었다면, Audit Logout이 늘어나는 것은 물론 쿼리 실행 즉 SQL:BatchStarting 이 늦어지게 됩니다. 이것은 고스란이 Audit Logout에 반영이 되게 되고, 이는 성능 문제로 비춰 질 수 도 있겠죠…^^

한 마디로 다양한 원인에 의해 해당 시간은 지속될 수 있다는 것이고, 전 그 한 예로 개발 코드의 문제를 예시로 보여드렸으며, DB 성능과는 그다지 관계가 없음도 알 수 있습니다.

앞으로 더 확인해야 할 내용들이 있다면 차차 업데이트를 하겠지만, 저는 Audit Logout 과 실제 Database의 성능과의 관계는 확인 하지 못했습니다. 물론 SQL Server 2000 에서는 관련 이슈가 있었던 것은 사실 입니다. Fix도 됐습니다. 하지만 SQL Server 2005에서는 음… 아직은 확인을 못했습니다.

확인 된 사항이 있으면 공유 좀 부탁드리면서 글을 마치겠습니다.

트레이스 파일 밀어 넣기
SELECT * INTO traceProblem FROM ::fn_trace_gettable('D:\002. Desktop\20100223\final.trc', default)

이벤트랑 맵핑 해서 내용 보기
SELECT   TE.name, T.*
FROM    dbo.traceProblem T -- table that contains the trace results
            JOIN sys.trace_events TE ON T.EventClass = TE.trace_event_id

커넥션 풀링을 사용하는 경우 (커넥션을 Close 한 이후에 사용 하는 경우)
1. 동일 프로세스에 동일한 Connection String을 가지고 있으며, SPTimeout / Wait Retry (이 후 설명) 안에서 실행 되는 경우
예) 아래의 경우 해당 객체를 close 한 경우에도 다른 객체로 동일한 Connection String 을 이용하여 연결한 경우 입니다.

위의 경우 sp_reset_connection 를 통해 이전 연결 설정을 재 사용함을 확인 할 수 있습니다.

커넥션 풀링을 사용하지 않는 경우
1. 동일한 프로세스가 아닌 경우
2. Connection String 이 다른 경우
3. 연결 객체 종료 (Close) 이후 SPTimeout / Wait Retry 의 기본 값 60초가 지난 경우
예)
아래는 동일 프로세스에 사용자 입력을 기다리는 형태로 구성되어 있습니다.
보는것과 같이 SPID가 54 입니다.
ㅏ
사용자 입력을 대기하도록 했습니다. 보는것과 같이 1분이 넘었습니다.
(아 Audit Logout 이벤트는 쿼리 성능과 관계없이 App에서 홀딩한 시간도 측정하는군요.)
 

아 sp_reset_connection 이 실행 되지 않고 있음을 확인 할 수 있습니다.
다시 말해서 풀링을 사용하고 있지 않다는 말이군요.

SPTimeout / Wait Retry 시간 조정

먼저 각 드라이버 별로 SPTimeout 값을 늘려줄 수 도 있습니다. 해당 레지스트리 아래에 SPTimeout 값을 늘려주면 됩니다.
SQLOLEDB (SQL Server native provider) : HKEY_CLASSES_ROOT\CLSID\{0C7FF16C-38E3-11d0-97AB-00C04FC2AD98}
Microsoft.Jet.OLEDB.4.0 (Jet native provider) ": HKEY_CLASSES_ROOT\CLSID\{dee35070-506b-11cf-b1aa-00aa00b8de95}
MSDAORA (Oracle native provider) : HKEY_CLASSES_ROOT\CLSID\{e8cc4cbe-fdff-11d0-b865-00a0c9081c1d} MSDASQL (OLE DB Provider for ODBC) : HKEY_CLASSES_ROOT\CLSID\{c8b522cb-5cf3-11ce-ade5-00aa0044773d}

Wait Retry 의 경우 이 대기 시간의 전역 설정이라고 볼 수 있습니다.
아래의 값을 조정하게 되면 전체적으로 대기 하는 시간을 늘려 줄 수 있습니다.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\DataAccess\Session Pooling\Retry Wait
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\DataAccess\Session Pooling\ExpBackOff

커넥션 풀링 이용하기
1. Connection String에 OLE DB Services = –1 값을 추가 합니다. (의미는 아래 표를 참고 합니다.)
예)
string source = "Provider=SQLOLEDB;Data Source=localhost;Initial Catalog=TEST;" +
            "UID=sa;PWD=pass1234;" +
            "OLE DB Services = -1;";

2. OLEDB Driver 의 OLEDB_SERVICES 를 0xffffffff 로 수정합니다. (의미는 아래 표를 참고 합니다.)
예)

-- 실제로는 해당 이벤트 확인이 않됩니다.
이는 EventSubClass 를 통해서 Connection 의 Pooling 여부를 확인 할 수 있다고 하는데, 실제로는 않되네요…;;
그림 출처 : http://weblogs.sqlteam.com/billg/archive/2007/10/31/Login-Events-include-Pooled-Connections.aspx

참고 문서
http://blogs.msdn.com/selvar/archive/2007/11/10/ole-db-resource-pooling.aspx
http://msdn.microsoft.com/en-us/library/ms810829.aspx
http://support.microsoft.com/kb/237977

[현상]

확인해 봤더니 hotfix가 있더군요.
hotfix에서 명시하는 Exception과 동일합니다.

- 현상 예
javax.transaction.xa.XAException: java.sql.SQLException: DTC_XA_START:Status:0 msg:*** SQLJDBC_XA DTC_ERROR Context: xa_start, state=7, StatusCode:-7 (0xFFFFFFF9) ***
at com.microsoft.sqlserver.jdbc.SQLServerXAResource.start(Unknown Source)
at <ClassName>.main(<ClassName>.java:<LineNumber>)

본 예외는 SQL Server 2005 JDBC 드라이버에서 XA 트렌젝션 (오라클에서 지원하는 트렌젝션이죠~~)과 DTC를 동시에 이용할 때 발생하는 예외라고 합니다.
확인해 보니 hotfix에 명시된 버전보다 이전 버전입니다.

[조치 사항]
http://support.microsoft.com/kb/950520 를 적용합니다.
아래와 같이 SQL Server 가 설치된 Binn 디렉토리에 SQLJDBC_XA.dll 을 복사해주면 됩니다.
(이전 설치 본의 경우 리네임을 해놓고 불어 넣는거 아시죠?)

* 아직은 많이 부족하기 때문에 제가 자신이 생길 때 까지 본 글은 제 블로그에 대한 링크만 허용합니다.

쓰래드의 백미는 스택입니다.

가끔 우리는 어항과 물고기를 통해 이 프로세스와 쓰래드의 관계를 표현하게 됩니다.
즉 어항은 프로세스 실제 해엄을 치고 있는 물고기는 쓰래드가 되죠.

그 경우 이 물고기들은 자신이 해엄치는 자취를 남기게 되는데, 이를 콜 스택이라고 볼 수 있습니다. 다시 말해서 어떠한 일을 한다 즉 함수를 실행 할 때 그 함수 실행의 자취를 콜 스택으로 비유 할 수 있습니다.

우리가 만드는 함수는 아래와 같은 모습이 됩니다.

Int Procedure1( ) { --------- 4
Procedure2( )       --------- 5
}
Int Procedure2( ) { --------- 6
…                      --------- 7
}
Main( ) {              --------- 1
…                      --------- 2
Procedure1( );       --------- 3
…                      --------- 8
}

제가 함수 옆에 숫자를 붙여 놓았는데, 이는 실행 순서 입니다. 여러분도 아시는 것 처럼 이 함수들은 먼저 Main( )이 실행 된 다음 Procedure1( )이 호출 되고, 호출된 Procedure1( ) 이 실행 되고 다시 Procedure2( ) 가 실행되고 다시 Main( )이 실행 됩니다.

이를 위하여 컴퓨터에서는 복귀 주소를 이용하게 되는데, 아래 그림과 같이 먼저 Main( )이 실행 하면 먼저 Main( )의 복귀 주소가 저장이 됩니다. 그리고 Procedure1( )을 호출 하게 되면 스택에 역시 Procedure1 ( )의 복귀 주소가 저장이 되고, 다시 Procedure1 ( )에서 Procedure2 ( )가 호출되게 되면 역시 Procedure 2( )의 복귀 주소가 저장이 되고, 실행 코드가 실행 이 된 후 다시 차례로 자신을 호출했던 복귀 주소로 돌아가 실행 결과를 전달하게 됩니다.

이는 콜 스택이라는 형태로 Thread 상에 표현되게 됩니다.
즉 Main의 복귀 주소를 저장한 후 Procedure1 이 실행 되고, 이 Procedure1 실행 중 Procedure2 를 호출하는 경우 다시 Procedure1 의 복귀 주소를 스택에 저장한 후 Procedure2가 실행 되는 거죠. 역시 최종적으로 실행 되던 Procedure2가 실행이 끝나면 저장했던 복귀 주소를 통해 차례로 Procedure1 과 Main 이 실행 됩니다.
(참고로 콜 스택의 현재 실행 위치는 ESP 레지스터에 저장됩니다.)

아래는 사용자가 notepad의 윈도우의 형태를 변경하는 메시지를 입력하는 순간에 잡은 유저 쓰래드입니다.
자 쓰래드를 한번 들여다 보도록 하겠습니다.

아래에서 보시는 것 처럼 notepad.exe의 콜 스택에서 81bddcb0 이 실행 중이였습니다.
kd> !thread
THREAD 81bddcb0 Cid 094c.0950 Teb: 7ffdf000 Win32Thread: e19a7970 RUNNING on processor 0
Owning Process 81e5db78 Image: notepad.exe
ChildEBP RetAddr Args to Child
f7f8ad4c 808234cb 0007fefc 00000000 00000000 win32k!NtUserGetMessage (FPO: [SEH])
f7f8ad4c 7c8285ec 0007fefc 00000000 00000000 nt!KiFastCallEntry+0xf8 (FPO: [0,0] TrapFrame @ f7f8ad64)
WARNING: Stack unwind information not available. Following frames may be wrong.
0007fed8 01002a3b 0007fefc 00000000 00000000 ntdll!KiFastSystemCallRet
0007ff1c 01007527 01000000 00000000 000a24b2 notepad!WinMain+0xe5 (FPO: [4,8,0])
0007ffc0 77e6f23b 00000000 00000000 7ffda000 notepad!WinMainCRTStartup+0x182 (FPO: [SEH])
0007fff0 00000000 010073a5 00000000 78746341 kernel32!ProcessIdToSessionId+0x209

아 보니깐 대충 “모듈명!함수명”으로 되어 있습니다.

그리고 이 콜 스택을 통해 해당 함수의 로컬 변수 뿐 아니라 매개 변수까지 모두 사용할 수 있습니다. 방법은 간단하죠. 하나의 함수가 선언되어 있다면 해당 함수의 복귀 주소가 저장이 될 것이고 차례로 지정해 놓은 변수들이 해당 스택에 쌓이게 될꺼니깐요. 만약 해당 변수를 매개 변수로 받는 다면 현재의 복귀 주소에서 함수 호출 시 사용한 매개 변수가 있는 위치만큼 위치를 더해서(4K 단위로) 값을 가져 올 수 있습니다.

그래서 이용하는 레지스터가 EBP입니다.

ESP는 현재 실행 하고 있는 콜 스택 상의 최 상위 실행 번지 입니다. 문제는 함수가 실행 함에 따라 ESP는 지속적으로 변경이 된다는 거죠. 그렇다면 우리가 사용하는 변수들을 단순위 ESP 값에 번지를 더하는 수준으로는 사용이 어려울 수 있습니다. 그래서 함수가 호출되게 되면 처음에 ESP의 값을 EBP 값으로 변경하고 이 EBP를 기준으로 변수를 접근하게 됩니다.

이렇게 함수들이 실행이 되게 되면 최종적으로는 쌓이다가 다시 꺼내게 되어 있습니다. 이때 사용하는 명령어가 바로 어셈블리어로 Ret 인데, 위의 예제에서는 RetAddr로 표현되고 있습니다. 이 Ret 명령어는 복귀 주소를 ‘Pop’ 즉 꺼내서 ‘Jmp’ 점프 즉 복귀하라는 의미입니다.

스택 트레이싱의 예
(처음에는 그냥 작성 하다 정말 좋은 글을 발견 했습니다. 출처: http://byung.egloos.com/4750412)

제가 간단한 프로그램을 만들어서 해당 프로그램을 통해서 확인 하도록 하겠습니다.
(먼저 스택은 포인터의 집합이고 실제 데이터는 힙에 산계하여 있음을 알려드립니다.)
프로그램은 아래와 같습니다.

#include "stdio.h"
int sum(int a, int b);
int min(int a, int b);
int _tmain(int argc, _TCHAR* argv[])
{

int a, b, c;
a=7;
b=3;
scanf("%d", &c);
sum(a,b);
min(a,b);
return 0;

}

nt sum(int a, int b)
{

int s;
s = a + b;
return s;

}

int min(int a, int b)
{

int m;
m = a - b;
return m;

}

Windbg를 통해서 해당 실행 파일을 실행 합니다.
먼저 int Sum() 함수에 BP 즉 브레이크 포인터를 걸겠습니다.
Kd> Bp DebugTest!sum
Kd> g

해당 함수가 실행 되는 상황에서 콜 스택을 확인 했습니다.
0:000:x86> k
ChildEBP RetAddr
002efdcc 010e1414 DebugTest!sum [d:\000. documents\visual studio 2008\projects\debugtest\debugtest\debugtest.cpp @ 22]
002efecc 010e1a88 DebugTest!wmain+0x54 [d:\000. documents\visual studio 2008\projects\debugtest\debugtest\debugtest.cpp @ 16]
002eff1c 010e18cf DebugTest!__tmainCRTStartup+0x1a8 [f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c @ 579]
002eff24 76fe3677 DebugTest!wmainCRTStartup+0xf [f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c @ 399]
002eff30 77569d72 kernel32!BaseThreadInitThunk+0xe
002eff70 77569d45 ntdll32!__RtlUserThreadStart+0x70
002eff88 00000000 ntdll32!_RtlUserThreadStart+0x1b

자 그렇다면 이때 무슨일이 일어 나고 있는지 CPU 레지스터 정보를 보겠습니다.

0:000:x86> r
eax=00000003 ebx=7efde000 ecx=00000007 edx=700c13e8 esi=002efddc edi=002efecc
eip=010e1490 esp=002efdd0 ebp=002efecc iopl=0 nv up ei pl zr na pe nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000246

DebugTest!sum:
10e1490 55 push ebp

위에서 저는 ESP의 한계로 인해 EBP를 이용한다고 말씀 드렸습니다. 막 스택에 EBP를 넣었군요. 그렇다면 다음에는 ESP의 값을 EBP에 넣어주겠죠? 하지만 지금은 그 단계는 아닙니다.

위에서 현재 실행되고 있는 스택의 주소는 002efdd0 입니다.
직접 스택을 보도록 하겠습니다.
로컬 변수 7과 3 역시 스택에 저장되어 있으며, 스택의 꼭대기에는 현재 복귀를 위한 주소가 저장되어 있습니다.

0:000:x86> dds esp
002efdd0 010e1414 DebugTest!wmain+0x54 [d:\000. documents\visual studio 2008\projects\debugtest\debugtest\debugtest.cpp @ 16]
002efdd4 00000007
002efdd8 00000003
002efddc 00000000
002efde0 00000000
002efde4 7efde000

자 스택의 ESP 에 있는 010e1414 함수를 확인 하기 위하여 디스어셈블리 해보도록 하겠습니다.
16 010e140f e84bfcffff call DebugTest!ILT+90(?sumYAHHHZ) (010e105f)
16 010e1414 83c408 add esp,8

그리고 이전에 설명 드린것과 같이 EBP를 기준으로 하여 로컬 변수 7과 3이 저장하는 것을 볼 수 있습니다.
13 010e13de c745f807000000 mov dword ptr [ebp-8],7
14 010e13e5 c745ec03000000 mov dword ptr [ebp-14h],3

보시는 것과 같이 자신의 EBP를 기준으로 포인터를 4 8 C… 즉 4 단위로 이동하면서 지정하는 것을 확인 할 수 있습니다.
위와 같이 DebugTest!ILT 를 호출합니다.
보시는 것과 같이 해당 함수의 다음 라인 즉 함수가 처리된 이후에 리턴 될 주소를 가르키고 있습니다.
ChildEBP RetAddr
002efdcc 010e1414

우리는 레지스터를 통해 현재 실행 중인 명령어 라인을 알 수 있습니다.
0:000:x86> r
eax=00000003 ebx=7efde000 ecx=00000007 edx=700c13e8 esi=002efddc edi=002efecc
eip=010e1490 esp=002efdd0 ebp=002efecc iopl=0 nv up ei pl zr na pe nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000246

DebugTest!sum:
010e1490 55 push ebp

마지막으로 이 콜 스택은 위에서부터 프래임 0 번부터 프레임 1 2 3 으로 표현이 됩니다.
우리는 프래임을 확인하여 실제 프레임에서 사용하는 매게 변수를 확인 할 수 있습니다.
0:000:x86> .frame 0
00 002efdcc 010e1414 DebugTest!sum [d:\000. documents\visual studio 2008\projects\debugtest\debugtest\debugtest.cpp @ 22]
0:000:x86> dv /i /V
prv param 002efdd4 @ebp+0x08 a = 7
prv param 002efdd8 @ebp+0x0c b = 3
prv local 002efdc4 @ebp-0x08 s = 3079640
0:000:x86> .frame 1
01 002efecc 010e1a88 DebugTest!wmain+0x54 [d:\000. documents\visual studio 2008\projects\debugtest\debugtest\debugtest.cpp @ 16]
0:000:x86> dv /i /V
prv param 002efed4 @ebp+0x08 argc = 1
prv param 002efed8 @ebp+0x0c argv = 0x001a1350
prv local 002efeac @ebp-0x20 c = –858993460
prv local 002efeb8 @ebp-0x14 b = 3
prv local 002efec4 @ebp-0x08 a = 7