1.   Windows RMS 구성요소별 요구사항 및 고객 환경

2.   RMS server설치 및 구성

RMS 와SQL이 DC에 같이 설치된 경우 다음과 같은 사전 작업이 필요합니다.

Active Directory

-      Active Directory 사용자 및 컴퓨터 관리자에서 RMS 서비스 계정으로 사용할 도메인 사용자 계정을 생성합니다. 이 계정은 Domain Admins에 포함되어 있어야 합니다.

-      도메인 안의 모든 DC들은 Global Catalog를 가져야 합니다.

SQL Server

도메인에 속해있는 사용자들이 DRMS_Config/DRMS_DirectoryServices/DRMS_Logging 데이터 베이스에 엑세스할 수 있도록 다음과 같이 Domain Users에 대해 로그온 권한을 부여합니다.

       I.          RMS Server Service를 설치할 서버에서 관리자 계정으로 logon 합니다.

     II.          RMS 서버 모듈을 설치 합니다.

http://www.microsoft.com/downloads/details.aspx?familyid=8EF6D80A-6A9C-4FB9-AB51-790980816FFE&displaylang=ko

   III.          “시작 > 모든 프로그램 > Windows RMS > Windows RMS 관리” 를 선택하여, “RMS 관리 툴”을 실행합니다.

A.       “RMS 관리 툴” 웹 페이지에서, “이 웹사이트에 RMS 제공(Provision)” 링크를 click합니다. 이를 통해 실제 이 서버에서 RMS service를 구현하게 됩니다.

B.       구성 데이터베이스 : RMS 서비스의 구성 정보를 저장할 데이터베이스가 존재하는 서버를 지정합니다.

C.       RMS 서비스 계정 : RMS의 서비스 계정을 지정합니다. 단일 서버 설치의 경우 로컬 시스템 계정을 선택할 수 있지만, 다른 경우에 대해서는 도메인 계정을 지정합니다. (예: DOMAIN\account) 단, RMS 설치에 사용된 도메인 계정은 RMS의 서비스 계정으로 지정할 수 없습니다.

D.       클러스터 URL : 루트 인증 클러스터의 URL을 지정합니다. 기본적으로 클러스터 URL은 서버의 이름 및 포트 번호로 구성됩니다. 포트 80이 아닌 경우라면 http://ServerName:8000과 같이 지정합니다. 참고로, 서버의 FQDN(Fully Qualified Domain Name)을 명시하는 것을 권장합니다.

E.       개인 키 보호 및 등록 : RMS에서 이 서버용 키 쌍을 만드는 과정입니다. 구성 데이터베이스에서 RMS 개인 키를 암호화하기 위해 소프트웨어 기반의 개인 키 보호를 사용할지, 하드웨어 기반의 암호화 서비스 공급자 보호 방법을 사용할지를 선택합니다. 기본 소프트웨어 기반 보호를 사용할 경우 키를 암호화하는 데 사용할 강력한 암호를 입력해야 합니다.

F.        RMS 프록시 설정 : “내 컴퓨터는 인터넷 연결을 위해 프록시 서버를 사용합니다” 부분을 uncheck 합니다. 실제 구성 환경에서 프록시 서버가 있다면, 이 부분을 check하고 필요한 정보를 입력합니다. 프록시 서버가 있음에도 프록시 서버 정보를 입력하지 않는다면, Provisioning에 실패하게 될 것입니다.

G.       해지 : 기본 설정을 그대로 사용합니다.

   IV.          모든 항목에 대해 입력이 끝나면, “전송” 버튼을 click합니다. 모든 구성이 완료되면, Provision이 성공했다는 메시지가 나오게 됩니다.

     V.          Provision이 완료되면 다시 “시작 > 모든 프로그램 > Windows RMS > Windows RMS 관리” 를 선택하여, “RMS 관리 툴”을 실행합니다.

   VI.          “RMS 관리 툴” 웹 페이지에서 “이 웹사이트에서 RMS 관리” 링크를 click 합니다. 단, “Enterprise Administrator” 권한을 가지고 있는 사용자로 실행해야 합니다.

 VII.          아직 RMS가 Active Directory에 연결 지점을 찾지 못해 실제 서비스의 구동이 완전하지 않은 상태입니다. 따라서 “이 웹사이트에서 RMS 관리” 웹 페이지에서 “RMS 서비스 연결 지점” 링크를 click하여 “RMS 서비스 연결 지점” 웹 페이지에서 “URL 등록” 버튼을 click합니다.

3.   RMS Client설치 및 구성

       I.          RMS 서버와 동일한 도메인의 client 머신에서 관리자 계정으로 logon 합니다.

     II.          RMS Client 를 설치합니다.

http://www.microsoft.com/downloads/details.aspx?FamilyId=02DA5107-2919-414B-A5A3-3102C7447838&displaylang=en

   III.          설치를 완료한 다음 Microsoft Office 문서를 수행합니다.

   IV.          문서에서 IRM Button을 click합니다. IRM button을 click하면, RMS를 사용하기 위해서 사용할 계정을 선택할 수 있습니다. .NET Passport 계정과 Windows 계정 중에서 하나를 선택 합니다.

ASP.NET 1.X 에서는 compile time 때 Code Behind 파일인 aspx.cs를 compile하여 dll 을 만듭니다. 그리고 사용자의 최초 요청시 aspx파일이 aspx.cs로 변경되고 위에서 생성된 dll을 참조하여 compile 됩니다.

반면, ASP.NET 2.0 에서는 사용자의 최초 요청시에 비로소 dll을 생성합니다. 세부절차는 먼저 aspx를 대응하는 과정에서 cs 파일로 생성하는데 partial class를 활용합니다. 그 다음 Code Behind 파일(aspx.cs)에 포함된 클래스를 같이 compile하게 됩니다.

ASP.NET 1.X 에서는 compile time 때 code behind 파일이 DLL로 만들어지므로 응용 프로그램 소스 코드의 수정 작업이 필요할 경우 재컴파일이 필요하게 됩니다. 일반적으로, 배포 서버에서는 aspx.cs를 compile한 dll만을 배포하게 되므로 aspx.cs의 내용을 수정하기 위해서는 다시 개발서버에서 작업한 후 컴파일 해야하는 등의 복잡한 과정을 거치게 됩니다.

보통 웹 사이트는 배포 이후에도 지속적인 보완이 이루어지므로 추가적인 변경 작업이 일어나게 됩니다. 그러므로 소스 코드의 수정 작업을 원할하게 할 수 있도록 하기 위해 ASP.NET 2.0에서는 처음 요청시에 compile이 한번에 이루어 지는 방식으로 변경되었다고 생각합니다.

1.     CharSet = Character Set

l  영문 표현 그대로 문자 집합이라는 의미입니다.

l  즉, 컴퓨터에서 문자를 표현하기 위해 각 문자를 정수 값에 대응시켜 놓은 체계를 말합니다. 숫자 코드가 컴퓨터 상에서 어떻게 표현되는 가는 정해지지 않은 상태라고 보면 됩니다.

l  예를 들어 한글 문자 집합에는 ‘가’, ‘나’, ‘다’... 와 같은 문자들이 포함되어 있습니다. 이를 컴퓨터가 인식하기 위해서는 어떤 데이터이든 숫자로 표현해야 하기 때문에 '가' 라는 문자는 0xac00라는 숫자값으로 매핑시켜 사용하도록 정의한 것을 charset이라고 하는 것입니다.

l  이러한 CharSet에는 언어 종류만큼 여러 개가 있을 수 있고, CharSet에 따라 표현하고자 하는 문자의 값과 대응되는 숫자의 값이 달라지게 됩니다. 따라서 문자를 주고 받을 때 서로간에 CharSet을 일치시켜야 할 필요가 있습니다. 그렇지 않으면 원래 의도된 내용이 아니 깨진 문자들을 보게 될 것이기 때문입니다.

l  웹 페이지 작성 시 content-type의 일부로 CharSet을 명시하는 것은 웹 브라우저에게 사용하는 CharSet을 알려주어 오해가 없도록 하기 위해서 입니다.

2.     Encoding

l  CharSet이 문자에 대해 정수값을 지정한 것이라면, encoding은 문자를 표현하는 정수값을 어떤 bit 배열로 표현할 것인지를 의미합니다. 즉, encoding은 CharSet에서 더 나아가 컴퓨터 상에서 어떻게 표현되는 가까지 정해진 상태의 문자의 집합입니다. 예를 들어 같은 그림이라도 압축 방법에 따라 gif, png, bmp 등등의 파일 형식이 있듯이 CharSet과 encoding의 차이를 이해할 수 있습니다. 완성형 한글인 KSC-5601 CharSet은 UNIX에서는 EUC-KR이란 encoding으로 표현되고 윈도우즈에서는 cp949란 encoding으로 표현됩니다.

l  CharSet이 같다면 그 CharSet을 지원하는 어떤 encoding을 사용하든지 각 문자에 대응하는 논리적인 정수값은 동일하다고 할 수 있습니다. 그러나 실제로 기록되는 bit 배열은 encoding에 따라 달라질 수 있습니다. 이 경우, 제대로 데이터를 주고 받으려면 CharSet뿐만 아니라 encoding도 맞춰야 합니다.

3.     EUC & CodePage

l  EUC는 Extended Unix Code의 약자입니다. Unix 시스템이 전세계로 퍼져 나가면서 각국의 언어를 어떻게 표기할까를 고민하다가 각 나라별로 표준 CharSet을 개발하였는데, 이렇게 만들어진 것이 EUC입니다. 한국어는 EUC-KR(ksc5601+US-ASCII)로, 일본어는 EUC-JP으로 정의되어 있습니다.

l  CodePage는 Microsoft의 Windows 시스템에서 각 나라의 문자를 표기하기 위해 만든 CharSet입니다. 한국어는 949번을 할당 받아 cp949 혹은 codepage949로 소개되었습니다.

4.     Unicode

l  모든 글자 표현 체계를 하나로 통합하겠다는 취지로 만들어진 CharSet 입니다.

l  Unicode 자체는 어떤 특정한 바이트 형태를 지정하지는 않습니다. 그렇기 때문에 encoding이 필요하게 됩니다. 즉 Unicode != UTF-8 이며 Unicode encoding 중의 하나가 UTF-8은 될 수 있습니다.

l  UTF-8은 ASCII로 표현 가능한 영문자는 1바이트로 표현을 하고 다른 문자들은 2~3바이트로 표현을 합니다. UTF-16은 4바이트까지 사용합니다.

l  Windows 9x (Windows 95, 98, me) 계열은 Windows API를 표준적으로 ANSI 버전을 지원합니다. 즉, UNICODE를 Windows API에서 직접 지원하지 않고 MBCS만을 직접 지원합니다. 이때, ANSI는 MBCS라고 생각해도 무관합니다.

l  ‘Windows NT (Windows NT, 2000, XP)계열은 Windows API를 ANSI 버전과 UNICODE 버전을 모두 지원합니다. ANSI의 API를 쓰는 경우에는 OS가 API를 다시 UNICODE 버전으로 변환해야 하므로 UNICODE 버전으로 만들어진 프로그램은 windows NT계열에서 약간의 속도 향상을 가져올 수 있다고 하겠습니다.

5.     UNIX에서의 Encoding

l  HTML : ISO-8859-1와 ISO-10646

l  XML : UTF-8

l  웹 브라우저: 내부적으로 모두 유니코드로 처리를 함

l  HTTP/1.0 : ISO-8859-1

l  HTTP (URL,URI) : US-ASCII, %hexadecimal_code, JavaScript escape() 함수 사용

l  Java : 유니코드 2.0

l  직렬화된 Java Class : UTF-8

l  J2EE : ISO-8859-1

l  Oracle : UTF-8 (AL32UTF8), 한국에서는 KSC5601 (KO16KSC5601)

일반적으로 파일의 내용을 변경 하기 위해서는 일단 파일을 메모리로 불러들여서 내용을 변경한 후, 변경된 메모리를 다시 파일로 저장하는 방식을 사용하였습니다. MMF(Memory Mapped File) 을 사용하여 파일 내용을 변경한다면 어떻게 동작하게 될까요.

MMF란 프로세스의 가상 메모리 일부를 파일의 일부 영역에 연결하는 메커니즘입니다.

다시 말하면 파일과 메모리 객체를 연결 시킨 후 그 메모리 객체에 이름을 지어준 다음,

그 이름을 이용하여 메모리에 데이터를 읽고 쓰고 하는 작업을 하는 것입니다. 이는 메모리에 들어있는 내용이 메모리와 연결되어 있는 파일에 똑같은 효과가 적용되는 구조라고 할 수 있습니다. 

아래 그림은 MMF 동작 원리를 잘 나타내고 있습니다.
















구현 과정은 다음과 같이 요약할 수 있습니다.

  1. 파일 열기 or 생성                             : CreateFile()
  2. 파일 연결 오브젝트(메모리 객체) 생성: CreateFileMapping()
  3. 가상 메모리에 파일 연결                    : MapViewOfFile()

#include "stdafx.h"
int _tmain(int argc, _TCHAR* argv[])
{
 // 1. 파일 핸들 생성
 HANDLE hFile;
 
 hFile = CreateFile(_T("data.dat"), GENERIC_READ|GENERIC_WRITE, 0, NULL,
     CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL);
 
 if ( hFile == INVALID_HANDLE_VALUE )
  _tprintf(_T("Could not open file."));

 TCHAR fileData[] = _T("Best test string~ ^^");
 DWORD numOfByteWritten = 0;
 WriteFile(hFile, fileData, sizeof(fileData), &numOfByteWritten, NULL);

 //2. 파일 연결 오브젝트 생성
 HANDLE hMapFile;
 
 hMapFile = CreateFileMapping(hFile, NULL, PAGE_READONLY, 0, 0, NULL);
 
 if ( hMapFile == NULL )
  _tprintf(_T("Could not create map of file.\n"));

 //3. 메모리에 연결
 TCHAR *pWrite;

 pWrite = (TCHAR *)MapViewOfFile(hMapFile, FILE_MAP_READ, 0, 0, 0);

 if ( pWrite == NULL )
  _tprintf(_T("Could not create map view of file.\n"));

 _tprintf(_T("String in file: %s\n"), pWrite);

 UnmapViewOfFile(pWrite);
 CloseHandle(hMapFile);

 CloseHandle(hFile);
 _tprintf(_T("End of process!\n"));

 return 0;
}

사용자가 asp 페이지를 클릭해서 데이터를 보는 과정은 asp 프로그램 안에 데이터베이스에 들어가는 정보를 갖고 준비해둔 쿼리문을 실행하여 결과를 가져오는 것이라고 설명할 수 있습니다. 
이와 같이 웹 어플리케이션에서 데이터베이스를 다루기 위해서 ADO 객체를 사용합니다.
여기서 ADO(ActiveX Data Object)란 데이터 베이스를 다루는 객체라고 할 수 있습니다. 

1. 접속 및 연결 
   데이터베이스에서 데이터를 가져오기 위해서는 우선 데이터소스에 연결해야 합니다. 
   연결을 하기 위해 필요한 정보는 다음과 같습니다.
   - ODBC와 OLEDB중 어떤 연결 방법을 사용할 것인가.
   - 어떤 종류의 데이터베이스를 사용할 것인가.
   - 데이터베이스 위치가 어디인가. (어느 서버의, 어떤 데이터베이스인가.)
   - 데이터베이스에 접근 가능한 ID와 비밀번호는 무엇인가.

  1.1. ODBC driver: 관계형 DB에 접속

 1.1.1. 데이터 원본(DSN)을 통한 연결
        제어판 -> 관리도구 -> 데이터원본(ODBC)

   선택 -> DB 경로 확인 후 선택
       
       
       
      
        연결
        > Access DB 일 경우

Bug 란 무엇인가

1.     Exception by Crash

1.1.   Kernel mode

-      Operating system components / Driver / File system / Low-level virtual memory에서 발생

-      블루스크린(Blue Screen) 발생

1.2.   User mode

-      User Application에서 발생

-      Hardware Exception : Page-Fault, Divide by zero, Access violation

-      Software Exception : User application이나 OS에서 명시적으로 발생시키는  

                           Exception (RaiseException())

2.     Hang

2.1.   High CPU

2.2.   Dead lock

2.3.   IO Pendding

3.     Memory Leak

Debugger, Debugging tool을 이용해서 Bug를 해결하는 과정이 필요

Debugging 종류 및 방법

1.     Post Mortem Debugging

-      장애시 수집된dump 파일을 분석

2.     Live Debugging

-      실행시 debugger에 process를 attach하여 분석

Dump 정의 및 종류

1.     정의 : 메모리 영역의 데이터의 이미지를 디스크에 기록한 것

2.     Mode, Type에 따라 나뉨

2.1.         Kernel Mode Dump

              - Full Dump : machine의 모든 물리적 메모리를 Dump

                                 User mode process들의 정보를 모두 debugging 할수 있음

              - Mini Dump : fault에 대한thread의 context, stack등 최소한의 정보를 가짐

    2-2.   User Mode Dump

  - Full Dump  : 특정 application관련된 모든 메모리 영역 데이터를 dump

- Mini Dump : crash에 대한 기본 정보와 관련된 모든 thread context, stack에 대한  

                   정보를 가짐

1.     Dump 수집

2.     WinDBG 세팅

2.1  WinDBG를 구동한다.

2.2  .Dump파일을 연다.

2.3  Symbol Path에는 *.pdb가 있는 경로와 인터넷을 통해 Windows의 Symbol을 받을 수 있는  경로를 셋팅한다.

path: SRV*[STORAGE PATH]*http://msdl.microsoft.com/download/symbols

3.     Symbol로딩      

3.1. >> .reload 하여 전체 모듈의 Symbol을 다시 로딩한다.

4.     >> !analyze –v를 통해서 exception에 대한 정보를 본다.

5.     추가 정보 확인

5.1. “lm” 명령을 사용하여 로딩된 모듈을 확인한다.

WinDBG Useful Command

“k” Command         

          - “k”: 현재 쓰레드의  Stack Frame 정보를 보여준다. 현재 Stack Frame상의 함수이름도 보여줌

          - “kb”: Stack Frame에서 DWORD형태의 파라미터 3개의 값을 보여줌

          - “kd”: 현재 Stack Frame상의 Stack 데이터를 DWORD크기만큼씩 짤라서 보여줌

          - “kv”: Stack Frame 값을 보여줌

"lm" Command

          현재 로드된 모듈의 정보를 보여줌

"dv" Command

          현재 Stack Frame의 로컬변수의 이름과 값을 보여줌

"dt" Command

          "dt [DATANAME]" : [DATANAME]의 값을 보여줌

"d" Command

          "da" : ANSI 문자열 형태로 값을 보여줌

          "db" : BYTE 형태로 값을 보여줌

          "dc" : 해당주소의 코드값을 보여줌

          "dd" : DWORD형태로 값을 보여줌

          "dw" : WORD or Unicode 문자값 형태로 값을 보여줌

"u" Command

          해당하는 주소의 에셈블리 코드를 보여줌

          - "u 0143ff3c" : 0143ff3c부터의 어셈블리 코드를 보여줌

"g" Command

          현재 쓰레드를 동작 시킨다. 쓰레드를 지정할 수도 Start,Break주소를 명시 할수도 있음

"r" Command

          현재 Context의 Register정보를 보여줌

".logopen", ".logappend", ".logclose" Command (새로생성, 덧붙여기록하기, 파일닫기)

현재 WinDBG Command창에 보여지는 모든 내용을 기록

"!analyze"

          현재 Exception에 대한 리포팅을 보여줌

          "!analyze -v" : Exception에 대한 정보

다음 기술문서에서 IIS 6.0 (Windows Server 2003)과 IIS 7.0 (Windows Server 2008)이 각각 이전 버전에 대하여 향상된 기능을 확인하실 수 있습니다.

인터넷 정보 서비스 6.0의 새로운 기능
http://www.microsoft.com/korea/windowsserver2003/evaluation/overview/technologies/iis.mspx

IIS 7.0의 가장 중요한 10가지 성능 향상
http://technet.microsoft.com/ko-kr/magazine/cc745952.aspx

다음 기술문서는 IIS 6.0에서 ASP의 중요 변경 사항에 대하여 열거하고 있으며, IIS 6.0/7.0 모두 해당됩니다.
따라서 Windows 2000 Server 기반의 IIS 5.0에서 업그레이드시 유의하셔야 합니다.

ASP의 중요 변경 사항
http://technet.microsoft.com/ko-kr/library/cc784267.aspx

Changes in ASP Features in IIS 6.0
http://msdn.microsoft.com/en-us/library/ms524938.aspx

*추가정보*
1. IIS 7.0으로 업그레이드에 대한 기술문서
IIS 7.0: Upgrading to IIS 7.0 on Windows Server 2008
http://technet.microsoft.com/en-us/library/cc754138.aspx

Web Deployment Tool
http://learn.iis.net/page.aspx/346/web-deployment-tool/

Migrating a Web Server from IIS 6.0 to IIS 7.0 by Using the Microsoft Web Deployment Tool
http://technet.microsoft.com/en-us/library/cc627317.aspx
http://www.microsoft.com/windowsserver2008/en/us/iis-app-deployment.aspx

2. IIS 6.0으로 업그레이드에 대한 기술문서
웹캐스트: Microsoft 인터넷 정보 서비스 6.0: 이전 버전에서 IIS 6.0으로 전환하는 최선의 방법
http://support.microsoft.com/kb/330692

Upgrading an IIS Server to IIS 6.0 (IIS 6.0)
http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/449dd92f-4a87-478f-bce1-770f59d7782a.mspx?mfr=true

Migrating IIS Web Sites to IIS 6.0 (IIS 6.0)
http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/6b6d6f50-351f-49d2-9c26-fdb515fd84c1.mspx?mfr=true

IIS6.0 리소스 킷 Migration Tool
http://www.microsoft.com/downloads/details.aspx?FamilyID=2aefc3e4-ce97-4f25-ace6-127f933a6cd2&displaylang=en

Heap Corruption
일반적으로 응용 프로그램이 주어진 크기의 힙 메모리 블록을 할당한 다음 힙 블록의 요청된 크기를 초과하는 메모리 주소에 기록하면 힙이 손상됩니다. 또한 이미 해제된 메모리 블록을 해제할 때도 힙이 손상될 수 있습니다.

힙 손상 문제 해결을 위한 자세한 정보는 다음 기술문서를 참고하시기 바랍니다.

IIS에서 힙 손상 문제를 디버깅하는 방법
http://support.microsoft.com/kb/300966

Windows XP 및 Windows 2000에서 Pageheap.exe를 사용하는 방법
http://support.microsoft.com/kb/286470

Microsoft OLE DB Provider for SQL Server(SQLOLEDB)에서 암시적 연결을 생성할 때 이 연결은 풀링되지 않습니다.

암시적 연결을 생성하는 경우는 다음 두 가지 경우입니다.

1.      처음 세션이 열려있는 동안 동일한 데이터 원본 개체로부터 추가 세션을 생성하는 경우, 공급자는 SQL Server에 대한 각각의 추가적인 세션을 위해 암시적인 연결을 생성합니다.

2.      동일한 연결로부터 여러 명령을 실행하고 읽기 전용, 정방향 전용 Resultset 커서를 지정하는 경우, SQL Server는 Firehose로 알려진 기본 결과 집합 커서 당 연결마다 하나 이상의 보류된 결과 집합을 허용하지 않으므로 DBPROP_MULTIPLECONNECTIONS가 기본값이 VARIANT_TRUE로 설정된 경우 공급자는 암시적으로 다른 연결을 생성합니다.

<증상>

만약 데이터베이스 서버 연결시 동일한 연결에서 여러 명령을 실행하는 경우 연결 풀링이 사용되지 않아 무수히 많은 연결이 생성되게 됩니다. 이러한 경우 사용할 수 있는 포트가 부족하여 추가 연결을 생성하지 못하고 새로운 요청이 모두 실패합니다. 네트워크 사용량과 관련해서 포트 문제가 있을 경우 SQL Server에 연결하려고 하면 다음 오류 메시지가 발생할 수 있습니다.

-       SQL Server가 없거나 액세스가 거부되었습니다.

-       시간이 초과되었습니다.

-       일반 네트워크 오류입니다.

<해결 방안>

따라서 네트워크 사용량이 많을때 위와 같은 문제를 해결하기 위해서 서버 단에서 사용할 수 있는 포트 수를 늘려줍니다. 다음 기술문서를 참고하여 MaxUserPort 레지스트리 값을 추가하고 최대 값인 65534로 설정하여 주시기 바랍니다.

(1) MaxUserPort 레지스트리 값을 추가하고 최대 값인 65534로 설정

When you try to connect from TCP ports greater than 5000 you receive the error 'WSAENOBUFS (10055)'

http://support.microsoft.com/kb/196271

(2) TcpTimedWaitDelay 설정을 30으로 설정

보다 자세한 내용은 다음 기술문서를 참고하시기 바랍니다.

SQL Server 연결 풀링이 해제될 때 조정해야 할 수 있는 TCP/IP 설정에 대한 설명

http://support.microsoft.com/kb/328476

추가적으로 동일한 연결에서 두 번째 이후의 수행되는 명령이 암시적인 연결을 사용하지 않도록, 하나의 명시적인 연결에서 하나의 명령만을 수행하도록 응용 프로그램을 수정하는 방법이 있습니다.

만약 전방향 전용, 읽기 전용 Resultset 을 사용해야만 하는 경우 (다중 연결을 피하기 위해서) ADO Resultset 개체의 CursorLocation을 adUseClient로 설정하는 것입니다. 이것은 SQL 서버에서 관리되지 않는 클라이언트 쪽 Resultset 생성을 야기하고, 연결 개체는 Resultset 과 연결되지 않습니다. 그러나, 대용량 데이터 집합을 다루는 시나리오에서는 서버쪽 커서가 성능에 유리합니다.