Maystyle :
Admin : New post
Guestbook
Local
media
Catergories
Recent Articles
Recent Comments
Recent Trackbacks
Calendar
Tag
Archive
Link
Search
 
해당되는 게시물 11건
  Audit Logout spends long time 
작성일시 : 2010.02.24 16:22 | 분류 : SQL Server/Development

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

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

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

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

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에 반영 되는군요.
image
 

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

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

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

               conn.Open();
               Console.WriteLine("DB Connection OK");
               string myInsertQuery = "Select * from T1";
               OleDbCommand myCommand = new OleDbCommand(myInsertQuery);
               myCommand.Connection = conn;
               Console.ReadLine();

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

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

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

  DB를 이용한 트레이스 파일 분석 
작성일시 : 2010.02.23 17:57 | 분류 : SQL Server/Development

트레이스 파일 밀어 넣기
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

  OLE DB에 대한 Connection Pooling에 관하여 
작성일시 : 2010.02.21 00:11 | 분류 : SQL Server/Development

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

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

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

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

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;";

image

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

image

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

image 

참고 문서
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

  SQLJDBC_XA DTC_ERROR 
작성일시 : 2010.02.20 22:08 | 분류 : SQL Server/Development

[현상]
image

확인해 봤더니 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에 명시된 버전보다 이전 버전입니다.

image

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

  Covered Index, Include Index, Bookmark lookup 
작성일시 : 2009.04.07 15:48 | 분류 : SQL Server/Development

허접씨와 Master님의 QnA 입니다.
어리버리 허접씨와 SQL 그루 이신 C 모님(MVP)과의 대화 입니다.

클러스터드 넌클러스터드외의 인덱스에 대한 용어 정리 및 이해에 도움이 될꺼 같아 올려봅니다. 아무래도 위의 3가지 용어에 대해 국내 블로그에도 피상적으로만 올라와 있고, BOL에도 너무 이해하기 어렵게 나와 있어서 그냥 한번 쏴악 이해하는 의미로 대화를 나눴습니다.

결론은 맨 하단에 있습니다.

Master님의 말:
커버드도 넌클에만 있고
간단하게 말해서 데이터 단을 읽지 않는...
북마크 룩없이 없는 인덱스가 커버드 인덱스야
조회하는 모든 데이터를 인덱스단에 올린거

허접님의 말:
그럼 클러스터드 인덱스에 선언된 절을 넌클러스터드 인덱스로
넣어주면
그게 커버든가요 ?

Master님의 말:
클러스터드랑은 상관고
클러스터등에 선언된거는 내부적으로는...
넌클러스터의 키니까 자동으로 포함되지

허접님의 말:
북마크 룩업이라는게 넌클러스터드 인덱스 서치 하고 나서 해당 포인터를 가지고 클러스터드 인덱스 서치하는거죠?
근대 어케 북마크 룩업이 없을 수 있어요?

Master님의 말:
클러스터드인덱스 서치라기보다는...
거기 달린 데이터를 가져오는거지
인덱스에 없는 데이터들...
그런데 조회하는 셀렉트 절에 모든 컬럼을...
넌 클러스터드 인덱스에 가지고 있으면...
데이터가 있는 클러스터드 인덱스쪽을 조회안해도 나오자너
인덱스만 조회해도....
그걸 커버드인덱스라고 그래...
인덱스에서 모든 데이터 조회가 가능(커버) 되니까

허접님의 말:
잠깐 이해가 될려구 하는데
아무튼 데이터는 클러스터드 인덱스를 타니간 북마크 룩업은 무조건 일어난다고
해야 하는거 아닌가요?

Master님의 말:
아니지...
북마크 룩업이라는게 비용이 많이드는 작업이야
클러스터드 인덱스를 만들게 되면...
힙과 달리
인덱스 끝에...
데이터가 달리자너
물리적으로

허접님의 말:

Master님의 말:
그런데 넌클러스터 인덱스에 가지고 올 데이터의 컬럼이 없다면...
데이터를 가져오기 위해서 해야될게 뭐겟어?
젤 빠른 인덱스를 찾겟지

허접님의 말:

Master님의 말:
다른 인덱스 중에서 그 데이터를 가진 인덱스가 없다면...
클러스터 인덱스를 이용해서
밑에 달린 데이터를 가져와야겠지?
그게 젤 빠를 테니까

허접님의 말:

Master님의 말:
그때데이터를 가져오는 작업이 논리적 이름이 룩업이야

허접님의 말:
아~

Master님의 말:
하지만 인덱스에서 그 데이터를 다 가져올수 있다면...
그 작업이 빠지겟지?

허접님의 말:
음 클러스터드 인덱스 스켄이랑 비슷하게 들리는데...

Master님의 말:
클러스터드 인덱스 스캔은...
테이블 스캔이지~
클러스터드 인덱스가 있으면...
테이블 스캔이 클러스터드 인덱스 스캔이 되니까...

허접님의 말:
여튼 검색 조건에 잇는 컬럼이 인덱스가 없어서
클러스터드 인덱스를 통해
데이터를 조회하니깐
이건 클러스터드 인덱스 스켄이랑 동일하게 들리는데요
;;

Master님의 말:
응 그 데이터 조회가 없는게 커버드 인덱스

허접님의 말:
아 아예 인덱스 스켄이 없는 경우를
커버드 인덱스라구 한다구요?

Master님의 말:
음...
넌 클러스터드 인덱스에는 데이터가 없지?
인덱스된 컬럼만 있고

허접님의 말:

Master님의 말:
넌 클러스터드 인덱스만 있을경우에는...

허접님의 말:
아하... 알았다....

Master님의 말:
클러스터 없고
말속에 길이 있어요

허접님의 말:
그니깐

Master님의 말:
커버드 인덱스(인덱스로만 조회)

허접님의 말:
select c1, c3 where c2=3
이렇게 할경우에

Master님의 말:
누가 누굴 카바한다는말하고 같은 의미의
c1, c2, c3가 넌클러스터드인덱스로 있으면...
다른 컬럼이 아무리 많아도

허접님의 말:
create index idx 1 (c2, c1, c3) 일케 되어 있음

Master님의 말:
다른데는 조회할일이 없자너

허접님의 말:
어차피 c1 c2 는 인덱스에서
잡혀 있으니깐
바로 조회가 된다는말?

Master님의 말:
엉...

허접님의 말:
클러스터드 인덱스 않타구요

Master님의 말:
인덱스의 데이터로만 조회가 되는

허접님의 말:
인클루드 인덱스는요?

Master님의 말:
사실 인덱스도 물리적은 데이터 모음이자너
그건 데이터를 떼서
가지고만 있는거지

허접님의 말:
그럼 인덱스 공간 차체가 어마 어마 하게 크겠네요

Master님의 말:
저장소와 별게로
커버드 인덱스는 젤 빠른 조회중 하나야
전같이 테이블이 7기가고
거기서 조회되는 컬럼이 많지 않은 작업이 있을경우...
70메가 또는 700메가만되도...
얼마나 빠르겠어
7기가서 하는거랑

허접님의 말:
그렇죠
근대
커버드인덱스
아까 같을때
각각 c1, c2, c3 에 대해서
idx1, idx2, idx3 로 선언을 하더라도
커버드 인덱스를 타죠?
동일 인덱스로 선언 않해두요

Master님의 말:
인덱스가 있음...
먼저 인덱스를 찾으니까...
건수나 뭐 분포도 따라서 달라질수도 있겠지
옵티마이저가
판단하기 나름
100%라고는 말못하지

허접님의 말:
c1,c2,c3를 idx1 으로 선언하거나 각각 인덱스로
잡거나
커버드로 처리 되겠죠 ?

Master님의 말:
뭐 의미만 놓고 보면...
인덱스로만 되면 커버드지

허접님의 말:


글구 인클루드는 인덱스에 데이터를 넣어버린다고 알고 있는데
맞나요?
리프에 데이터를 쑤셔 넣은

Master님의 말:
잠시만...
아까 말했다 시피...
인클루드는...
복사본을 만드는거야
단 인클루드열은...
인덱스크기에서 빠져서 엔진에서 계산되고~
장점은 인덱스의 한계를 벗어나서 만들수 있다~
16개열 900 바이트
단점은 무리한 인클루드는 리프단에 복사되기 때문에 저장공간및 i/o추가 발생~
커버드인덱스와의 차이는...
비슷하긴 한데...
커버드 인덱스도 인덱스기 때문에
위에서 말한 인덱스의 한계를 벗어날수 없음

허접님의 말:
형님 점심 먹고 나서
제가
정리한 걸로 말씀 드릴께요
ㅎ,.ㅎ
대충 정리 완료

Master님의 말:
어~~~
밥먹고 왔당

허접님의 말:
형님 그럼 커버드 인덱스는
create index idx1 (c2, c1, c3) 이렇게 만드는것만
해당하네요
따로 인덱스 만들어서는 커버드가 아니네요
그럼 c2로 정렬이 되고
이미 c2의 인덱스에 c1, c3 값이 있으니
클러스터 인덱스를 안타고 바로 데이터를 접근
따로 인덱스를 만들게 되면
C2만 사용하게 되고 그럼 클러스터 인덱스를 통해 c1과 c3를 접근해야하고
즉 create index idx1 (c1) , create index idx2 (c2), create index idx3 (c3) 은 정확하게 커버드 인덱스라 부를 수 없네요

Master님의 말:
ㅎㅎ 그리고 그렇게 인덱스를 만들지도 않지

허접님의 말:
즉 커버드는 create index idx1 (c2, c1, c3) 를 말하는 거죠?
create index idx1 (c1) , create index idx2 (c2), create index idx3 (c3) 이건 커버드가 아니죠?

Master님의 말:
뒤에꺼 같이 만들면 정렬에 따라서 인덱스 끼리 머지하거나 해서 플랜이 나올껄

허접님의 말:
제가 정리를 하자면
검색조건에
검색조건이
인덱스로 지정이 되어 있고
Select 절에
해당 인덱스의 하위절로 정의된 컬럼들만 요구하고 있다면
해당 데이터는 클러스터드 인덱스를 검색하지 않고 인덱스만으로 데이터를 반환한다.

Master님의 말:
맞습니다
그것이 커버드 인덱스입니다

허접님의 말:
원칙은 커버드는 해당 열을 포함하는 인덱스를 만들어야 하나
간혹 옵티마이저에 의해
인덱스들을 조인 혹은 머지해서
커버드 인덱스로 처리하기도 한다.
인클루드 인덱스는 커버드 인덱스와 비슷하나 커버드가 인덱스 안에 데이터가 있다면 인클루드는 리프레벨에 데이터가 붙는다
잉 아닌데 인클루드도... 위쪽부터 커버드처럼 데이터가 붙어야 정상이지 않나요?
구조 자체도 동일해버리네요

Master님의 말:
둘다 데이터 포함돼
헌데 인클루드는 인덱스의 한계를 넘고
아까 말했듯이 엔진에서 크기 계산시 인클루드 열이 빠진다는거

허접님의 말:

Master님의 말:
그리고
간혹 옵티마이저에 의해
인덱스들을 조인 혹은 머지해서
커버드 인덱스로 처리하기
요건...
뭐랄까 용어 문제긴한데...
저것도 커버드 인덱스로 보느냐 마느냐는 잘 몰겠다
ㅎㅎ

- 결론
1. Covered Index
형님 그럼 커버드 인덱스는
create index idx1 (c2, c1, c3) 이렇게 만드는것만
해당하네요
따로 인덱스 만들어서는 커버드가 아니네요
그럼 c2로 정렬이 되고
이미 c2의 인덱스에 c1, c3 값이 있으니
클러스터 인덱스를 안타고 바로 데이터를 접근
따로 인덱스를 만들게 되면
C2만 사용하게 되고 그럼 클러스터 인덱스를 통해 c1과 c3를 접근해야하고
즉 create index idx1 (c1) , create index idx2 (c2), create index idx3 (c3) 은 정확하게 커버드 인덱스라 부를 수 없네요

2. Include Index
인덱스의 한계를 넘고
아까 말했듯이 엔진에서 크기 계산시 인클루드 열이 빠진다는거

3. Bookmark Lookup
허접님의 말:
북마크 룩업이라는게 넌클러스터드 인덱스 서치 하고 나서 해당 포인터를 가지고 클러스터드 인덱스 서치하는거죠?
근대 어케 북마크 룩업이 없을 수 있어요?
Master님의 말:
클러스터드인덱스 서치라기보다는...
거기 달린 데이터를 가져오는거지
인덱스에 없는 데이터들...

  CTE 
작성일시 : 2009.04.07 10:56 | 분류 : SQL Server/Development

WITH TopSales (SalesPersonID, NumSales) AS
(SELECT SalesPersonID, Count(*)
FROM Sales.SalesOrderHeader GROUP BY SalesPersonId )

위와 같이 선언하게 되면 TopSales Table이 만들어 지게 되고 일반 Table과 마찬가지로 사용할 수 있다.

  Join Hint 
작성일시 : 2009.01.07 11:49 | 분류 : SQL Server/Development

Nested Loop
It is more a effective method then a merge Join when the data is small.

select *
from employee e inner loop join jobs j
on e.job_id = j.job_id
image

Sort Merge Join
It is more efficient in the most cases.

select *
from employee e inner merge join jobs j
on e.job_id = j.job_id

image

Hash Match Join
If you don't have any indexs or sorted data in a compare clue. SQL server use this method.
It is less efficient method.

  SQL Server 열에 Caption (Commant, Description)을 달자 
작성일시 : 2008.03.13 15:51 | 분류 : SQL Server/Development | 태그 : caption, Column, commant, SQL Server, table

Oracle의 경우 Table 생성 시 각 열에 맞게 commant를 달아 줄 수 있습니다.







SQL Server 또한 동일한 주석을 달아 줄 수 있는데, 이는 Table 생성 이후에 달 수 있습니다.
다음 예제는 AdventureWorks 데이터베이스의 Address 테이블의 PostalCode 열에 Caption을 다는 것입니다.
USE AdventureWorks;
GO
EXEC sp_addextendedproperty
@name = N'Caption', @value = 'Postal code is a required column.',
@level0type = N'Schema', @level0name = Person,
@level1type = N'Table', @level1name = Address,
@level2type = N'Column', @level2name = PostalCode;
GO
참고 : 확장 속성을 관리하는 저장 프로시저

sp_addextendedproperty
sp_updateextendedproperty
sp_dropextendedproperty
fn_listextendedproperty()

출처 : http://technet.microsoft.com/ko-kr/library/ms180047.aspx
  데이터 형식 이해하기 (일반 데이터 형식 생략) 
작성일시 : 2008.02.18 09:38 | 분류 : SQL Server/Development | 태그 : ANSI null default, ANSI_NULL_DFLT_OFF, ANSI_NULL_DFLT_ON, char, nchar, null, nvchar, varchar

내용을 쓰다보니 너우 어렵게 쓰는거 같습니다.
일단 제가 공부하는 내용 위주로 업데이트를 한 이후에 설치 부분 및 각 Feature 소개 같은 부분은 업데이트 하도록 하겠습니다.

목차
Database 기본기 다지기
1. 선언적 데이터 무결성(Declarative Data Integrity)
2. 트랜잭션 프로세싱

트랜잭션 로그와 데이터 복원
1. 데이터 파일 쓰기
2. 로그 파일 쓰기
3. 트랜잭션 로그를 통한 데이터 복구

트랜잭션 로그 파일과 데이터 파일
1. 트랜잭션 로그 파일
2. 데이터 파일

내부 저장소
1. 데이터 형식 이해하기 (일반 데이터 형식 생략)

데이터 형식 이해하기 (일반 데이터 형식은 생략)

• 날짜/시간 데이터 형식
– 형식

• 문자 데이터 형식
– 종류 :
가변 길이 단일 바이트 문자 스트링 (char, varchar)
고정 길이 유니코드 문자 스트링 (nchar, nvchar)

– 가변 길이 데이터 코드의 허와 실
장점 :
1. 데이터 공간 절약이 가능
2. I/O 동작에 따른 효율 증가 (한번의 I/O로 대량의 데이터 확보)
단점 :
1. 오프셋 연산 필요 (성능 영향 미비)
2. 행 크기 증가로 인한 Page 확보 시 로드 증가
(클러스터 인덱스 적용 시 동일 레벨로 새로운 페이지 이동으로 인한 로드)

• NULL
– NOT NULL 칼럼만 사용 하도록 한다. (NULL 조건은 어플리케이션 버그의 원인이 된다.)
– NULL 대신 Default 값 정의를 사용한다.
– ANSI null default (ANSI_NULL_DFLT_ON, ANSI_NULL_DFLT_OFF)
  SQL Server는 기본적으로 ANSI_NULL_DFLT_ON 이다.
ON 을 설정하면 반대 옵션으로 OFF가 설정되나, OFF 를 설정하면 ON 설정 없이 현재 ON 설정을 중지 시킨다.

  SQL 서버에서 AD 쿼리 하기 
작성일시 : 2007.12.20 17:31 | 분류 : SQL Server/Development | 태그 : sql 2005 ldap

먼저 Linked 서버로 등록하신 후 Select 문으로 확인 합니다.

- Linked 서버 만들기

다음과 같이 provider_name으로 ADSDSOObject를 사용하고 sp_addlinkedserver 시스템 저장 프로시저의 data_source 인수로 adsdatasource를 사용하여 연결된 서버를 만듭니다.

EXEC sp_addlinkedserver 'ADSI', 'Active Directory Services 2.5', 'ADSDSOObject', 'adsdatasource' GO

Windows 인증 로그인의 경우 자체 매핑만으로도 SQL Server 보안 위임을 사용하여 디렉터리를 액세스하기에 충분합니다. sp_addlinkedserver를 실행하여 생성된 연결된 서버에 대해서는 기본적으로 자체 매핑이 만들어지므로 다른 로그인 매핑은 필요하지 않습니다.

SQL Server 인증 로그인의 경우 sp_addlinkedsrvlogin 시스템 저장 프로시저를 사용하여 디렉터리 서비스에 연결하기 위한 적절한 로그인과 암호를 구성할 수 있습니다.

- 디렉터리 서비스 쿼리

Microsoft OLE DB Provider for Microsoft Directory Services는 디렉터리 서비스를 쿼리할 수 있도록 두 명령 언어 LDAP과 SQL을 지원합니다. OPENQUERY 함수를 사용하여 디렉터리 서비스에 명령을 보내고 그 결과를 SELECT 문에서 사용할 수 있습니다.

(Microsoft 디렉터리 서비스용 Microsoft OLE DB 공급자는 Integration Services에서 직접 LDAP 쿼리를 지원하지 않습니다. 대신 Microsoft 디렉터리 서비스에 연결된 서버를 만들어 이 항목에서 설명한 OPENQUERY 또는 스크립트 작업을 사용합니다. 자세한 내용은 Querying the Active Directory with the Script Task를 참조하십시오. )

다음 예에서는 OPENQUERY를 사용하여 도메인 주소가 sales.adventure-works.comADSISrv 서버에 있는 디렉터리의 정보를 반환하는 뷰를 만드는 방법을 보여 줍니다. OPENQUERY 함수 안에 있는 명령은 디렉터리에 대한 SQL 쿼리로 해당 디렉터리의 지정된 계층적 위치(OU=Sales)에서 contact 클래스에 속한 개체의 Name, SNST 특성을 반환합니다. 그러면 모든 SQL Server 쿼리에서 이 뷰를 사용할 수 있습니다.

CREATE VIEW viewADContacts
AS
SELECT [Name], SN [Last Name], ST State
FROM OPENQUERY( ADSI, 'SELECT Name, SN, ST FROM ''LDAP://
ADSISrv/ OU=Sales,DC=sales,DC=adventure-works,DC=com''
WHERE objectCategory = ''Person'' AND objectClass = ''contact''')
GO
SELECT * FROM viewADContacts

원문 : http://technet.microsoft.com/ko-kr/library/ms190803.aspx

 Prev   1   2   Next