SQL Server 2005 개발자 가이드[4/13]

ADO.NET 2.0

.NET Framework 2.0 과 함께 소개될 ADO.NET 2.0은 이번 버전과 비교하기 힘들 정도로 많은 추가 기능과 향상을 제공합니다. 그것이 SQL Server 사용자들을 대상으로 한 이 책에서 ADO.NET 2.0을 소개하고자 하는 중요한 이유이기도 합니다. 즉 이 책에서는 ADO.NET 의 새로운 기능에 대한 구현 방법을 소개하기 보다는, SQL Server 관리자나 개발자와 같은 데이터베이스 사용자 입장에서 보다 전문적으로 ADO.NET 2.0의 어떤 점이 추가 향상 되었는지 어떠한 기능에 관심을 가져야 하는지 소개하고자 합니다. [참고] 현재 SQL Server를 연동하는데 사용되는 많은 어플리케이션들이 주로 ADO나 ADO.NET 과 같은 마이크로소프트의 데이터베이스 프로그래밍 API을 사용해서 프로그램 되어 있으며, JDBC를 사용한 자바 프로그램 또한 많이 늘어나고 있습니다. 현장에서 진단분석 및 튜닝 관련 컨설팅을 하면서 중요하게 경험하는 것 중의 하나가 바로 DBMS의 특징을 잘 모른 상태에서 잘못 작성된 코드, 개발 편의성만을 강조해서 만들어진 무성의한 코드, 데이터베이스용 API 기능들을 충분히 활용하지 못하고 있는 코드들이 SQL Server 성능에 상당히 큰 영향을 미치고 있다는 사실입니다. 현업 개발자들 대부분이 바로 그러한 한 점, 잘못 작성된 데이터베이스 관련 코드가 SQL Server에 미치는 성능 문제에 대해서 전혀 깨닫지 못하고 있거나 간과하고 있다는 것입니다. (그도 그럴 것이 많은 개발자들이 안정적이고 성능을 제공할 수 있는 코드를 만드는데 투자할 만한 충분한 시간과 경험을 제공받지 못하고 있습니다) ADO.NET 2.0에 향상된 기능들을 데이터베이스 사용자 입장에서 개략적으로 살펴봄으로써 새로 개발되는 데이터베이스용 어플리케이션들이 어떤 기능들을 요구할 수 있는지 이해하는데 도움이 될 것입니다.

ADO.NET 2.0 주요 기능 리스트

ADO.NET 2.0의 주요 기능들을 간단히 정리하면 다음과 같습니다. [표] ADO.NET 2.0 주요 기능    ㆍ Provider Factories    ㆍ Runs w/Partial Trust    ㆍ Server Enumerations    ㆍ Connection String Builder    ㆍ Metadata Schemas    ㆍ Batch Update Support    ㆍ Provider-Specific Types    ㆍ Conflict Detection    ㆍ Tracing Support    ㆍ Pooling Enhancements    ㆍ MARS    ㆍ SqlNotificationRequest    ㆍ SqlDependency    ㆍ IsolationLevel Snapshot    ㆍ Async Commands    ㆍ Client Failover    ㆍ Bulk Import    ㆍ Password Change API    ㆍ Statistics    ㆍ New Datatypes    ㆍ Promotable Tx    ㆍ AttachDbFileName 실제로 위에 소개한 기능들 이외에 많은 추가 향상 기능들이 제공됩니다. 다만, 그 내용들은 어플리케이션 개발자 입장에서 보다 중요한 부분이라 생략한 것입니다. 위 내용 중에서 몇가지 중요한 부분들을 소개합니다.

새로운 연결(Connection) 구성 방법

데이터베이스 어플리케이션에서 서버로의 연결을 위한 연결 문자열의 구성은 아주 중요한 부분입니다. ADO.NET 2.0에서는 웹 어플리케이션을 경우 Web.Config 파일 내에서, 윈도우즈 어플리케이션의 경우 App.Config 파일 같은 구성 파일 내의 <connectionStrings> 라는 섹션을 도입하고 하부 요소(Element)와 속성(Attribute)을 정의함으로써 기존 연결 문자열 (Connection String) 처리를 보다 편리하게 다룰 수 있도록 지원합니다. 이 파일 내의 서버 연결에 대한 정보, 서버 명, 로그인 ID, 암호 등의 모든 정보가 저장되는 것입니다. C#, VB 어플리케이션 내에서는 해당 *.Config 파일 내의 연결 문자열을 통해서 서버에 접속하고 데이터를 처리하게 됩니다. 다음은 *.Config 파일 내의 연결 문자열에 대한 예제 입니다. [예제] connectionStrings 섹션 <connectionStrings> <add name=”WinTest.Properties.Settings.NorthwindConnectionString” connectionString=”Data Source=YUKON;Initial Catalog=Northwind;User ID=Bob;Password=p@ssw0rd” providerName=”System.Data.SqlClient”/> </connectionStrings>

Server Enumeration 기능

이전 버전까지는 네트워크 상에서 어떤 SQL Server가 존재하는지 다른 어떤 DBMS 서버가 존재하는지에 대한 정보를 프로그래밍하는 기능이 기본적으로 제공되지 않았습니다. ADO.NET 2.0에서는 .NET Framework으로 설치되는 machine.config 파일 내의 .NET Data Provider들(예를 들어, SQLClient Data Provider 등)을 이용해서 네트워크에서 해당 공급자 (Provider)에 해당하는 모든 서버 목록과 관련된 정보를 쉽게 구성할 수 있도록 DbProviderFactories 클래스를 제공합니다. 특히 SQL Server에 대해서만 원할 경우, SqlDataSourceEnumerator 클래스를 통해서 보다 쉽게 처리할 수 있습니다. 다음은 몇 가지 관련된 예제 코드입니다. [예제] Server Enumeration 예제 // 1) 전체 Data Provider에 대한 목록 얻기 DataTable tblFactories = DbProviderFactories.GetFactoryClasses( ); // 2) 특정 Data Provider만 얻기 DbProviderFactory f = DbProviderFactories.GetFactory(r); // 혹은 DbProviderFactory f = DbProviderFactories.GetFactory“( System.Data.SqlClient”); // 3) 해당 Data Provider에 대해 네트워크 상의 모든 서버 정보 얻기 DbDataSourceEnumerator en = f.CreateDataSourceEnumerator( ); DataTable tblDataSources = en.GetDataSources( ); // 4) SQL Server 정보만 직접 구하는 경우 DataTable source = System.Data.Sql.SqlDataSourceEnumerator.Instance.GetDataSources( );

연결 풀링(Connection Pooling) 향상

서버 측에서뿐만 아니라, 클라이언트 측의 데이터베이스 프로그래밍 API에서도 연결 풀링 (Conneciton Pooling)을 지원하고 있으며 이는 데이터베이스 어플리케이션의 성능에 아주 중요한 한 요소입니다. 잘못된 프로그램으로 인해 연결 풀링을 활용하지 못하는 경우도 종 종 경험할 수 있습니다. 연결 풀링은 말 그대로, 한 번 구성되고 사용된 연결 개체를 연결이 끊어진 이후에도 풀에 남겨두고 다시 연결될 때 이를 재 사용함으로써 연결을 구성하고 초기화하는데 들어가는 비용과 시간을 줄이기 위한 방법입니다. 이를 통해서 확장성과 성능 향상을 얻을 수가 있습니다. ADO.NET 이전 버전에서는 연결 풀 내의 연결 개체가 제대로 제거되지 않거나 잘못된 연결 개체가 남아있어서 어플리케이션 수행 시의 문제를 일으킬 수가 있었습니다. ADO.NET 2.0 에서는 코드 상에서 이러한 연결 풀의 제거를 직접 수행할 수 있도록 두 가지 메서드를 제공합니다. ■ SqlConnection.ClearPool( )    ㆍ 지정된 특정 연결 개체만 제거합니다. ■ SqlConneciton.ClearAllPools( )    ㆍ 연결 풀 내의 모든 연결 개체를 제거합니다. 연결 풀링을 모니터링 하기 위한 성능 개체와 카운터도 변경되었습니다. ADO.NET 이전 버전에서는 .NET CLR Data 개체에서 관련된 연결 정보를 모니터링 할 수 있었지만, ADO.NET 2.0에서는 .NET Data Provider for SqlServer 라는 별도의 성능 개체와 그 관련된 카운터 값들을 제공합니다. [참고] 실제로 성능 카운터를 사용 시에는 해당 .NET 어플리케이션이 구동 중이어야 합니다.

일괄처리 업데이트(Batch Update)

ADO.NET의 DataTable 혹은 DataSet에서 변경된 데이터를 서버에 반영할 경우, 한 번의 호출에서 다중 행을 반영하도록 지정하는 일괄처리 업데이트가 지원됩니다. 즉 일괄처리 (Batch)내에 여러 개의 명령을 하나의 일괄처리 단위로 서버에 전송을 하는 방법입니다. 실제 예제 코드는 다음과 같습니다. [예제] Batch Update // UpdateBatchSize >= 0 값으로 설정 sqlDataAdapter1.UpdateBatchSize = int.Parse(textBox1.Text); sqlDataAdapter1.Update(dsCustomers1.Customers); 위 코드는 텍스트박스 컨트롤(textBox1)에 입력된 값을 BatchSize로 지정합니다. 이는 한 일괄처리 내의 행 개수를 의미합니다. 그리고 SqlDataAdapter 개체의 Update 메서드를 호출해서 dsCustomers1 이라는 DataSet 내의 변경된 행을 서버에 적용하도록 호출하게 됩니 다. 이 때 실제 서버에 호출되는 일괄처리의 수는 바로 BatchSize에 지정된 행 개수와 DataSet 내에서 변경된 전체 행 수를 나눈 값 만큼 호출되게 됩니다. ■ 일괄처리 업데이트를 적용한 결과로 얻을 수 있는 이득은 다음과 같습니다.    ㆍ 네트워크 작업으로 인한 추가 지연을 방지    ㆍ 플랜 캐시(Plan Cache)와 재사용에 대한 도움    ㆍ 성능 역효과 또한 중요하게 고려 마지막에 성능 역효과를 고려하라는 부분은 무슨 의미일까요? 그것은 실제로 일괄처리 업데이트가 수행되는 내부 방식을 SQL 프로필러 통해서 추적을 해보시면 쉽게 판단하실 수 있습니다. 그 결과를 보시면, 각각의 명령(INSERT, UPDATE, DELETE) 단위로 sp_executesql로 변환되고 이를 서버에 전송해서 실행되는 것을 확인할 수 있습니다. 그 결과로만 보자면 일괄 처리 개념이 적용되지 않는 것 같지만, ADO.NET 팀에 소개에 의하면 SQL Server 내부 수준에서는 배치 단위로 처리가 된다고 합니다. [참고] ADO.NET 은 Bata1 과 그 이전 버전, 최근 버전에 이르기까지 계속해서 내용이 변화가 많았습니다. SQL Server 측면에서도 버전 별로 그 내부 동작의 차이가 많이 있습니다. 일괄 처리 업데이트 기능은 또한 Beta2와 CTP 6월 버전이 내부 동작의 차이가 있습 니다.

비 동기적인 명령 실행

ADO 에서는 지원이 되었지만, ADO.NET 에서는 지원되지 않았던 아쉬운 부분 중의 하나가 바로 비동기적으로 명령을 실행하는 것입니다. 기본적으로 얻을 수 있는 이득이 바로 클라이언트 측에서 결과 집합의 반환을 대기하면서 발생하는 사용자 인터페이스 상의 차단 현상을 줄일 수 있다는 것입니다. 그 때는 모래 시계가 왠지 싫죠! ADO.NET 2.0에서 다시 비 동기 처리가 지원됩니다. .NET 코드는 .NET의 비동기 처리 매커니즘과 코딩 패턴을 그대로 사용하므로, 기존 개발자들은 어렵지 않게 사용할 수 있습니다. 우선 연결 문자열에 비 동기 처리를 위한 속성을 지정해야 합니다. (아래 예제 참고) 최종적으로 결과를 반환 받기 위한 접근 방법에 따라서, 전용의 비 동기 호출 메서드를 사용하는 방법, 폴링이나 차단을 위해서 IAsyncResult를 사용하는 방법, 그리고 Callback 메서드(이것이 일반적인 방법)를 사용하는 방법 등을 고려할 수 있는 특히 Callback 메서드를 이용하는 경우엔 서로 다른 쓰레드로 호출되기 때문에, 별도의 동기화 처리를 필요하게 됩니다. [예제] 비 동기적인 명령 실행 1. 연결 문자열 속성 지정 “Asynchronous Processing = true;”혹은“Async=true; 2. 완료될 때까지 폴링하며 대기하는 경우의 코드 예제 // 완료에 대한 Polling 수행 코드 IAsyncResult ar = cmd.BeginExecuteReader( ); while(!ar.IsCompleted) { // 작업 수행 } SqlDataReader reader = cmd.EndExecuteReader(ar); 3. Callback 메서드를 사용하는 경우의 코드 예제 // Callback 사용 IAsyncResult ar = cmd.BeginExecuteReader( new AsyncCallback(ExecCallback), null, CommandBehavior. CloseConnection ); // 다른 작업 수행… // 필요한 경우 작업 대기(옵션) ar.AsyncWaitHandle.WaitOne( ); // 작업이 완료되는 이 콜백 메서드가 호출되며, 결과를 처리할 수 있다. private void ExecCallback( IAsyncResult ar ) { SqlDataReader rdr = _cmdAsync.EndExecuteReader(ar); }

대량 입력(Bulk Import)

SQL Server에서 대량 로드를 위해서 사용하는 BCP.EXE 혹은 BULK INSERT 명령처럼 ADO.NET 에서 고 성능의 데이터 로드 작업을 위해 SqlBulkCopy 클래스를 제공합니다. 데이터 원본으로 DataRow[ ], DataTable, 그리고 IDataReader 인터페이스를 지원합니다. BatchSize 와 같은 속성 값을 지정해서 일괄처리의 단위, 트랜잭션 단위를 조정하거나 기타 옵션들을 제어할 수 있습니다. [예제] SqlBulkCopy 를 사용한 대량 데이터 로드 예제 //destConn은 미리 정의된 목적지 데이터 원본에 대한 연결 SqlBulkCopy bcp = new SqlBulkCopy(destConn, SqlBulkCopyOptions.Default); bcp.DestinationTableName =“ Customers”; // 컬럼명이 일치한다면, 연관을 지을 필요는 없다. // bcp.ColumnAssociators.Add“( customerid”,“ customerid”);// 이름vs. 이름 // bcp.ColumnAssociators.Add(2, 2); // 컬럼번호 vs. 컬럼번호 bcp.ColumnAssociators.Add(0, 0); // 위 방법 중 한가지를 선택해서 사용 bcp.ColumnAssociators.Add(1, 1); /* Batch 크기를 지정할 수 있다. 디폴트는 0 (한 Batch로 모두 복사) bcp.BatchSize = 50; bcp.WriteToServer(tblCustomers); bcp.Close( ); ADO.NET 2.0에서 향상된 기능 들 중의 SQL Server 사용자가 관심 있게 볼 만한 몇 가지 주제들을 살펴보았습니다. 이제 이전의 ODBC, OLEDB API에 추가로 SQL Server 2005에 추가된 전용 기능들을 제공하기 위해서 새롭게 개발된 SQL Native Client(SNAC) API와 함께 SQL Server 2005의 전용 향상 기능들과 그 관련된 ADO.NET 2.0의 내용들을 살펴보겠습니다.

SQL Native Client

윈도우즈 플랫폼에서 데이터베이스 어플리케이션들은 주로 MDAC(Microsoft Data Access Components) 으로 제공되는 ODBC, OLE DB API 혹은 프로그램 가능한 개체 형식으로 제공되는 ADO 등을 사용했습니다. SQL Server 2000은 MDAC 2.6 버전으로 업데이트가 되고, SP3의 경우 MDAC 2.7 버전으로 업데이트가 되었죠. MDAC은 현재 윈도우즈(혹은 서비스 팩)를 통해서만 배포가 가능하도록 변경된 상태입니다. 따라서, SQL Server 2005와 향후 추가 기능들을 별로도 배포하는 문제가 발생하게 될 것입니다. 이에 대해 SQL Server는 새로운 기능에 대한 지원을 MDAC에서 별도로 분리할 필요가 발생하게 되고 결과적으로 만들어진 새로운 API 가 바로 SQL Native Client 이며, 이는 단일 DLL(\Windir%￦System32￦SQLNCLI.dll)로 존재합니다. 즉, SQL Server 2005의 전용 기능들을 위해서는 SNAC를 사용하게 됩니다. 성능 부분에 있어서도 내부 테스트의 결과 OLE DB와 유사한 성능을 제공하며, 기존 ODBC 에 대해서 20%까지의 성능 향상을 언급하고 있습니다. 따라서 기존 어플리케이션의 경우에도 적합한 경우 SNAC를 사용하도록 조정을 할 수 있을 겁니다. 간단히 연결 문자열만 변경을 하면 됩니다. ■ SQL Native Client를 통해서 지원되는 기능들은    ㆍ 데이터베이스 미러링    ㆍ 새로운 데이터 형식    ㆍ 다중 결과 집합 (MARS)    ㆍ 쿼리 알림, 혹은 동적 웹 캐싱    ㆍ 암호 변경과 만료    ㆍ 스냅숏 격리 수준 등 입니다. 그럼, 각 항목별로 살펴보시죠.

데이터베이스 미러링 - 클라이언트 장애 조치

데이터베이스 미러링은 기존 장애조치 클러스터링(Fail-over Clustering)의 자동으로 수행되는 장애조치 기능과 로그 전달(Log Shipping)과 같은 데이터베이스 이중화 기능을 모두 제공하는 데이터 가용성과 확장성을 위한 SQL Server 2005의 새로운 기능입니다. ADO.NET 2.0에서는 데이터베이스 미러링에 대해서 클라이언트 측의 자동 장애조치 기능을 지원합니다. 즉, 초기 연결 시의 데이터베이스 미러링을 자동으로 인식하고 서비스 장애 발생 시 자동으로 대기 서버(미러 서버)로 연결을 재 시도하는 기능입니다. ■ 클라이언트 장애조치 방법은    ㆍ 데이터베이스 미러링을 자동 인식하고 장애조치 준비    ㆍ 필요할 경우, 연결 문자열에 장애조치 Partner를 명시적으로 지정하는 것도 가능하며, 이 경우        첫 번째 연결에서 장애조치가 발생하는 경우에도 처리가 가능    ㆍ 대기 서버에 대한 PartnerID를 클라이언트 캐시에 저장    ㆍ 오류 시 연결을 해제하고 Partner로 재 연결 시도, 재 연결은 투명하게 수행 해당 트랜잭션은 손실 즉, ADO.NET 프로그램 상에서 별도로 할 작업은 없습니다. 다만, 명시적인 Partner 지정이 필요한 경우에 다음과 같은 연결 문자열을 추가합니다. [예제] 명시적인 Partner 지정 시 연결 문자열 추가 내용 Failover Partner=YukonPortal;

다중 결과 집합 (MARS, Multiple Active Result Sets)

데이터베이스 어플리케이션에서 쿼리를 실행하고 반환된 결과 집합을 처리하기 위해서 커서 형식(CursorType)과 커서 위치(CursorLocation)를 지정하게 됩니다. ADO에서는 디폴트가 서버 측 커서였으며(adUseServer), ADO.NET에선 서버 커서는 지원되지 않고 대신 클라이언트 측 커서만 지원을 했습니다. 클라이언트 측 커서(커서 형식과도 관련이 됩니다)로 선언된 후 쿼리를 실행하는 경우 SQL Server 측에서는 해당 결과 집합을 기본 결과 집합(Default Result Sets) 혹은 일명 Firehose 커서라고 불리는 형식으로 클라이언트에 전송을 합니다. 이 경우 클라이언트는 모든 결과 집합이 반환될 때까지 대기 상태에 있게 되며, 해당 연결(Connection)에서 또 다른 명령을 실행할 수가 없게 됩니다. 두 개 이상의 결과 집합(혹은 행 집합)을 처리하고자 하는 경우에도 첫 번째 결과 집합을 닫아야만(Resultset.Close) 그 다음 결과 집합 처리가 가능합니다. 만일 두 개 이상의 명령을 유사하게 처리하거나 두 개 이상의 결과 집합을 동시에 열어 놓고 작업을 하고자 한다면, 다음과 같은 방법들을 생각해 볼 수 있습니다. ■ 서버 측 커서 사용 ■ 필요한 명령 수 만큼 다중 연결(Connection)을 선언해서 개별적으로 사용 그러나 위와 같은 방법들은 리소스의 낭비, 네트워크 병목과 같은 또 다른 문제들을 불러올 수 있었습니다. SQL Server 2005에서는 이제 하나의 연결에서 여러 개의 기본 결과 집합을 가질 수 있습니다. 즉, 여러 개의 결과 집합을 열어 놓고 이들을 오가며 데이터를 처리할 수 있고 또한 기본 결과 집합을 처리하면서 INSERT, UPDATE, DELETE 혹은 저장 프로시저 호출과 같은 다른 명령들을 수행할 수 있습니다. ■ 다중 결과 집합으로 인한 성능과 확장성의 이득은    ㆍ 물리적인 연결 당 다중 세션을 포함    ㆍ 클라이언트와 서버 자원 사용 감소    ㆍ 연결 초기화/풀링(Pooling) 로직의 생략    ㆍ 비 동기 처리와 조합을 통해서 최대 성능 제공 가능 기존 어플리케이션 개발자들이 데이터 처리에 있어서 불편함을 겪었던 부분들이 상당히 해소될 수 있을 것으로 기대합니다. 특히, 서버 측 커서를 주로 사용하던 다른 플랫폼 개발자들이 ADO.NET을 사용하는 경우의 불편함을 덜 수 있을 겁니다. 물론 이러한 기능이 필요할 때에 제한적으로 사용하는 것이 무엇보다 우선될 것입니다. [예제] MARS 예제 //이전 코드 생략 SqlCommand cmdCust = new SqlCommand“( select customerid, companyname from dbo.customers order by customerid”, cnn); SqlCommand cmdOrd = new SqlCommand“( select customerid, orderid from dbo.orders order by customerid, orderid”, cnn); cnn.Open( ); SqlDataReader rdrCust = cmdCust.ExecuteReader(CommandBehavior.CloseConnection); SqlDataReader rdrOrd = cmdOrd.ExecuteReader(CommandBehavior.CloseConnection); while (rdrCust.Read( )) { listBox1.Items.Add(rdrCust.GetString(0) +“ ,“ + rdrCust.GetString(1)); } // rdrCust 가 열려 있는 상태에서 rdrOrd 를 처리 while (rdrOrd.Read( )) { listBox2.Items.Add(rdrOrd.GetString(0) +“ ,“ + rdrOrd.GetInt32(1)); } //이후 코드 생략

쿼리 알림(Query Notification)

웹 어플리케이션이나 웹 기반 서비스의 사용이 보편화되면서, 대형 웹 사이트의 경우 동시의 수 많은 서비스 요청을 처리해야만 하는 요구가 발생합니다. 캐시는 하드웨어적으로 혹은 프로그램 적으로 웹 서비스의 동시 처리 능력을 향상시키는데 아주 중요한 역할을 합니다. 그러나 동적으로 임의 시점의 변경될 수 있는 데이터베이스의 경우 일정 간격으로 밖에 처리되는 않는 데이터 동기화 매커니즘을 가진 기존 캐시 처리가 적합하지 않게 됩니다. 물론 파일의 날짜 혹은 버전이 갱신되는 시점에 캐시를 갱신할 수 있는 기능과 테이블의 트리거 등의 개념을 활용하면 데이터베이스가 변경된 시점에서 캐시가 갱신되도록 구성할 수는 있습니다만, 여기에는 또한 여러 가지 어려움이 있습니다. SQL Server 2005에서는 특히 기존의 웹 어플리케이션에서 아주 중요하게 요구되던 동적 캐시 처리 기능을 지원합니다. 바로 쿼리 알림(Query Notification)이라는 기능입니다. 물론 이 기능은 윈도우즈 어플리케이션에서 훌륭하게 적용될 수 있습니다. 다만 웹 기반에서 웹의 특성 상 별도의 구성을 가지고 있을 뿐입니다. 쿼리 알림은 쿼리에서 반환된 결과 집합에 대해 클라이언트의 로컬(혹은 웹 서버)에서 캐시에 저장을 해 두고, 이후로는 서버의 연결과 데이터 처리가 필요 없이 캐시의 데이터만을 재사용하게 됩니다. 데이터베이스에서 해당 결과 집합의 변경이 발생하게 되면. 클라이언트에게 캐시가 더 이상 유효하지 않음을 알리게 됩니다. 윈도우즈 어플리케이션의 경우 알림을 받기 위한 해당 이벤트가 호출되어서 캐시에 대한 갱신 작업을 수행할 수 있으며, 웹 어플리케이션의 경우 서버로의 재 연결과 쿼리 실행 그리고 캐시 재 설정 작업이 자동으로 수행되며 이후 작업이 반복이 됩니다. 실제로 이러한 내부 동작은 SQL Server 2005의 서비스 브로커 서비스(Service Broker Service) 아키텍처와 결합되어서 지원이 됩니다. 어플리케이션의 유형별, 버전 별 구현 방법의 차이가 있으며 간단히 정리하면 다음과 같습니다. ■ 윈도우즈 어플리케이션의 경우    ㆍ System.Data.SqlClient.SqlDependency        클래스를 사용해서 간단하게 구현할 수 있습니다.    ㆍ System.Data.SqlClient.SqlNotificationRequest        클래스를 사용하는 경우, 저-수준에서 보다 세밀한 제어가 가능합니다. ■ ASP.NET은 자체 구현을 포함하고 있습니다.    ㆍ System.Web.Caching.SqlCacheDependency ■ ASP.NET + SQL Server 2000의 경우는 폴링을 통해서 하위 호환성 용으로 제공됩니다.    다음과 같은 별도의 구성 작업이 필요합니다.    ㆍ aspnet_regsql 유틸리티를 사용, Cache Notification을 활성화    ㆍ OutputCache 선언    ㆍ Web.Config 파일 변경 ASP.NET + SQL Server 2000의 경우 데이터베이스 구조의 변경, Polling 간격에 따른 서버 부하와 Cache 처리 등의 주의를 기울여야 합니다.

암호 변경/만료

SQL Server 2005에서는 보안 기능에 많은 변화를 경험할 수 있습니다. 그 중에 하나는 SQL Server 인증에 대해서도 윈도우즈 인증과 같은 수준의 보안 기능을 제공하는 것입니다. 예를 들어, 암호 만료 정책이나 윈도우즈 암호 정책을 적용할 수 있는 부분입니다. 따라서 SQL Server 인증의 경우에도 로그인 시 암호를 변경하거나 만료 시 안호를 변경하는 작업 등이 필요하게 됩니다. ADO.NET 2.0에서는 SqlConnection.ChangePassword( ) 정적 메서드(VB 경우 공유 메서드)를 통해서 연결 시 암호를 변경할 수 있도록 지원이 됩니다. [예제] SqlConnection.ChangePassword 메서드 // 기존 연결 정보 string pwd = string.Format“( data source=yukon;initial catalog=northwind; User ID={0};Password={1};”, textBox1.Text.Trim(), textBox2.Text.Trim( )); // 기존 연결에 대해서 textBox3.Text 의 값으로 암호 변경 SqlConnection.ChangePassword(pwd, textBox3.Text.Trim( ));

스냅숏 격리(Snapshot Isolation)

SQL Server 2005에 추가된 새로운 격리 수준인 스냅숏 격리 수준을 ADO.NET 2.0에서 트랜잭션 개체 선언 시의 IsolationLevel 옵션을 통해 어플리케이션 측에서 조정을 할 수 있습니다. [예제] IsolationLevel.Snapshot // 트랜잭션 선언 시 격리 수준의 조정 SqlTransaction Tx3 = cnn3.BeginTransaction(IsolationLevel.Snapshot); sqlCmd3.Transaction = Tx3;