SQL Server 와 연결 불가의 경우

성능 문제나 장애사항을 발견하는 첫 번째 Discover 단계는 SQL Server와 클라이언트간에 연결이 실패하는 경우입니다. 연결 불가의 오류 메시지를 받은 상황입니다.

여러분이 첫 번째로 해야 될 일은 발생된 정확한 오류 메시지를 보관해 두는 것입니다.

메시지 박스로 발생되었다면 해당 메시지 박스를 Alt+PrintScrn 키를 누르거나 이미지 도구를 사용하여 다음과 같이 저장하기 바랍니다.

이제 두 번째 단계인 오류 사항을 올바르게 정의하는 Explore the condition 단계입니다.

가장 먼저 이벤트 로그와 SQL Server 오류 로그를 확인하여 발생한 오류와 관련되는 정보의 기록 여부를 점검합니다. 뿐만 아니라 발생한 오류 메시지의 정보를 가지고 마이크로소프트 기술 문서나 다양한 SQL Server 커뮤니티 사이트 등을 통해서 관련 정보를 수집하여 원인 분석과 해결을 위한 참고 자료로 활용합니다.

가장 먼저 들러야 할 곳은 마이크로소프트사의 기술문서 검색 사이트입니다.

이미 마이크로소프트사에서 해결한 상황이나 참고 자료를 검색함으로써 가장 빠르고 정확하게 문제를 진단하고 해결점에 도달할 수 있습니다. 이곳에서 관련 자료나 해결 방법을 얻지 못한 경우에는 다음의 커뮤니티 사이트들을 통해서 유사한 질의와 답변이 있었는지 점검하고, 원하는 답변이 없는 경우에는 질의를 남기면 전 세계 전문가들을 통해서 가능한 빠르게 답변을 받을 수도 있을 것입니다.

이와 같은 참고 자료와 함께 오류가 발생한 주변 상황을 면밀히 검토합니다. 기존에는 연결이 잘 되다가 어느 순간부터 연결이 잘 되지 않는 것인지 아니면 클라이언트를 구성하고 처음 연결 시 발생하는 문제인지 구별해야 합니다. 뿐만 아니라 해당 클라이언트만 좌측의 메시지 가운데 하나를 받고 연결이 안 되는 것인지 아니면 모든 클라이언트들에서 연결이 실패하는지 구별해야 합니다.

만약, 다른 클라이언트는 현재도 연결이 잘 되는데 특정 클라이언트에서만 연결이 안된다면 해당 클라이언트의 설정상의 문제일 가능성이 높고, 기존에 연결이 잘되던 클라이언트 여러 대가 앞에서 살펴본 연결 불가 메시지를 동일하게 받았다면 해당 클라이언트들과 서버 간의 네트워크상의 문제일 가능성이 높다는 것을 추리할 수 있습니다.

만약, 해당 클라이언트를 포함해서 동시에 모든 클라이언트가 연결되지 않는 상황이라면 모든 클라이언트가 공용으로 공유하는 부분이나 서버 측의 문제일 가능성이 높습니다. 이와 같은 주변환경을 조사함으로써 발생된 문제를 명확하게 정의하도록 합니다.

이제 여러 가지 케이스를 가지고 세 번째 단계인 문제를 해결하기 위해서 전략을 수립하고 범위를 좁혀 나가는 Track down possible approach 단계와 네 번째 단계인 Execute the most likely approach 단계로 넘어가 해결에 접근해 보도록 하겠습니다.

CASE 1. 다른 클라이언트들에서는 이상이 없는 상황에서 최초 구성한 클라이언트만 연결이 실패하는 경우

가장 먼저 이벤트 로그와 시스템 로그를 확인합니다. IP 충돌이나 케이블 장애와 같은 해당 클라이언트의 네트워크상의 문제점이 있다면 시스템 로그에 기록이 남아 있을 것입니다. 클라이언트를 설치할 때 발생한 오류 사항은 응용 프로그램 로그에 기록될 수 있습니다. 이벤트 로그에 표시된 오류가 기록되어 있는 경우에는 적절한 해결을 시도합니다. 이상이 없는 경우에는, 운영체제 상에서 네트워크로 서버와 통신이 되는지를 먼저 점검합니다. 시작→실행에서 CMD를 입력하고 엔터 키를 눌러서 명령 프롬프트를 실행합니다. Ping 유틸리티를 실행해서 네트워크 연결 여부를 확인합니다.

해당 서버가 이상이 없다면 포트와의 연결 여부를 확인합니다. SQL Server와 클라이언트간의 통신 여부를 마이크로소프트가 제공하는 다양한 툴을 통해서 확인할 수 있습니다. 다음에서 소개하는 portqry 유틸리티는 SQL Server가 지정된 포트에서 정상적으로 수신이 가능한지 여부를 확인할 수 있습니다. 먼저 portqry 유틸리티를 설치합니다. 다운로드 사이트는 다음과 같습니다.

명령 프롬프트에서 설치 경로(C:\PortqryV2)로 이동합니다.
다음의 매개 변수를 참고하여 portqry 유틸리티를 실행합니다.

<1433 포트가 정상적으로 수신되는 경우>

해당 포트가 NOT LISTENING 인 경우 SQL Server가 해당 포트를 바인딩하지 못했거나 다른 포트를 사용하고 있을 수도 있습니다. 다른 클라?이언트의 MDAC 구성을 확인하는 것이 필요합니다.

서버의 네트워크 구성 유틸리티를 실행하여 구성된 서버가 사용할 수 있는 프로토콜 및 해당 프로토콜의 포트 등의 구성과 해당 클라이언트의 MDAC 구성이 상호간 통신이 가능한지 여부를 확인합니다. 다음은 TCP/IP 네트워크 라이브러리의 경우입니다.

<서버의 구성>

<클라이언트 구성>

서버가 사용하는 포트와 클라이언트에 지정된 포트가 다르면 위와 같은 오류 메시지가 반환 됩니다. 클라이언트가 접속하고자 하는 SQL Server의 포트가 지정되지 않은 경우 UDP 1434 포트를 통해 접속하고자 하는 SQL Server가 사용중인 포트를 질의합니다. 따라서 서버가 사용중인 포트가 클라이언트 네트워크 유틸리티나 연결 문자열에 정확하게 지정되었는지 또는 UDP 1434 포트가 사용 가능한지 등을 확인하여야 합니다.

2. MDAC 구성에 이상이 없다면 MDAC 버전을 확인합니다. MDAC의 하위 버전은 상위 버전과 호환됩니다. 단 클라이언트 프로그램이 요구하는 기능에 따라서 최신 버전의 MDAC이 필요한 경우나 클러스터가 구성된 경우 해당 환경에서의 MDAC 설치와 관련된 사항을 기술문서를 통해서 확인한 후 설치하여야 합니다.
MDAC 버전을 확인하는 유틸리티와 MDAC을 버전 별로 다운로드 할 수 있는 사이트로 접속합니다.

MDAC 버전을 확인하는 Component Checker 유틸리티를 설치한 후 해당 클라이언트에서 실행하고 [OK] 버튼을 누르면 다음과 같이 버전을 확인할 수 있습니다.

또는 레지스트리에서도 확인이 가능합니다.

그러나 SQL Server간에 통신하거나 쿼리 분석기와 같은 SQL Server 클라이언트 도구를 사용하는 경우에는 상위 버전은 하위 버전과 통신이 불가능한 경우가 생기게 됩니다. 이런 경우는 상호 호환 가 Windows 2003 Enterprise 서버에 SQL Server RTM 버전이 설치되어 있는 예입니다. 클라이언트의 MDAC 버전을 확인하면 2.82가 설치되어 있지만 SQL Server는 SSNETLIB 8.0.194를 사용하므로 상위 버전의 SQL Server에서는 접속하지 못하는 문제가 발생할 수 있습니다.

다음은 서비스 팩3 또는 서비스 팩4가 설치된 SQL Server에서 RTM 버전의 SQL Server에 접속하려고 할 때 발생하는 오류 메시지입니다

위의 경우는 SQL Server의 기본 사용 네트워크 라이브러리인 TCP/IP 와 명명된 파이프 (Named Pipe)로 각각 통신을 시도한 후 연결할 수 없음을 표시하는 오류 메시지입니다.

<명명된 파이프로 연결 시도 시 오류 메시지>

CASE 2. 특정 클라이언트에서만 연결이 잘 되다가 갑자기 실패하는 경우

CASE 1의 1단계와 2단계를 실행하여 해당 클라이언트의 운영체제와 하드웨어의 문제를 점검하고 이상이 없는 경우에는 연결이 실패하기 직전에 수행했던 작업을 점검해야 합니다.

최근에 설정을 변경하였거나 설치된 프로그램은 없는지도 점검해야 합니다. 액티브 디렉토리를 구성하여 중앙에서 계정관리를 하지 않는 경우 해당 클라이언트에서 사용하는 윈도우즈 계정의 패스워드를 변경하고, 접속하고자 하는 SQL Server에 있는 윈도우즈 계정의 패스워드를 변경하지 않으면 다음과 같은 오류 메시지를 발생합니다.

따라서, 클라이언트에서 최근에 변경된 사항을 중심으로 해결점에 접근합니다.

CASE 3. 일부 클라이언트들에서 연결이 실패하는 경우

기존에 연결이 잘되는 상황에서 일부 클라이언트에서만 연결이 되지 않는다면 스위치나 라우터 등 연결이 불가한 클라이언트들이 공통으로 사용하고 있는 부분에 초점을 맞추어 찾아 보아야 합니다.

CASE 4. 모든 클라이언트들에서 연결이 실패하는 경우

1. 가장 먼저 운영체제의 실행 여부를 확인합니다. Power Supply 등의 하드웨어 문제그와 SQL Server 오류 로그를 면밀히 살펴 보는 것이 필수입니다. 이어서 SQL Server 서비스의 실행 여부를 확인합니다. 이상이 없다면 서버의 로컬에서 쿼리분석기나 엔터프라이즈 관리자 등을 통한 연결 테스트를 진행합니다. 서버가 통신 포트를 바인딩하지 못한 것이 원인일수도 있습니다. 이벤트 로그를 통 해 확인할 수 있으며 명령 프롬프트에서 아래 명령을 실행해서 수신중인 TCP 1433 포트 (해당 서버의 SQL Server 사용 포트), UDP 1434 포트 등의 수신 대기를 확인합니다.

SQL Server 오류 로그를 통해서도 수신 대기 중인 네트워크 라이브러리를 확인할 수 있습니다.

서버 자체의 네트워크 문제가 아니라면 라우터나 방화벽, DNS서버나 WINS 서버 등 SQL Server와 클라이언트 사이에 위치한 공통 사용 영역이 문제일 수도 있습니다. PING, TRACERT 등의 명령을 통해서 통신이 가능한 범위를 점검하여 문제의 원인이 되는 지점에 접근합니다. 방화벽을 사용하는 경우 SQL Server가 기본 구성의 포트를 사용하는 경우 TCP 1433 포트와 UDP 1434 포트를, 별도의 포트를 지정해서 사용하는 경우 각 인스턴스 별로 사용하는 포트를 방화벽에서 허용해야 합니다.

2. SQL Server가 로컬에서도 연결이 불가능한 경우는 CPU나 메모리, 네트워크 등이 과도하게 사용되는 경우 연결을 기다리다가 시간 제한에 걸려 연결이 불가능한 경우도 예상할 수 있습니다.

이런 경우는 시스템 모니터를 통하거나 작업관리자를 사용하여 현재 사용중인 자원의 상태를 모니터링할 수 있으며 잘못 설치된 하드웨어 드라이버 등이 원인이기도 합니다. 뿐만 아니라, 자원을 과도하게 사용하는 경우는 웜 바이러스 등에 감염된 것이 원인이 될 수도 있습니다. 이런 경우는 서버에 최신의 핫픽스와 서비스 팩의 적용을 미루거나 바이러스 백신 프로그램 등을 적절하게 업데이트하지 못한 결과입니다.

3. 시스템의 메모리 단편화 문제는 기존의 연결에서의 작업 수행은 가능하지만 새로운 연결 은 실패하는 문제를 유발합니다. 메모리 단편화 문제는 SQL Server가 새로운 연결을 위 해서 필요로 하는 메모리의 연속적인 공간을 할당할 만한 메모리가 지원되지 않기 때문입 니다. 윈도우즈 인증을 사용하는 경우 다음과 같은 오류 메시지와 함께 연결되지 못합니다. 그러나 SQL 인증을 사용하는 경우에는 정상적으로 연결이 이루어지기도 합니다.

위의 오류 메시지는 윈도우즈 인증으로 인증을 요청할 때 패스워드가 일치하지 않는 경우 발생한 오류 메시지와 유사하기 때문에 주의하기 바랍니다. 반드시 SQL Server 오류 로그를 통해서 발생된 문제를 정확하게 정의하여야 합니다. 먼저 패스워드를 확인하여 윈도우즈 인증의 오류인지를 점검하고, SQL Server 오류 로그를 확인하여 관련된 메시지가 있는지 점검합니다. 메모리 단편화의 경우 다음과 같은 오류 메시지를 확인할 수 있습니다.

이런 경우에는 적절하게 작성되지 않은 응용 프로그램이나 SQL Server용 확장 저장 프로시 저가 문제가 된다고 진단할 수 있습니다. SQL Server는 확장 저장 프로시저로 사용되는 DLL파일의 실행을 모두 SQL Server 오류 로그에 기록하므로 SQL Server가 시작된 뒤 실행 된 DLL 파일을 검사합니다.

메모리 단편화의 경우 기존 연결의 경우도 특정한 작업을 실행하게 되면 다음과 같은 오류 메시지를 반환하기도 합니다.

<확장 저장 프로시저 XP_CMDSHELL 을 실행한 경우>

<엔터프라이즈 관리자에서 권한 탭을 클릭한 경우>

4. 과도한 스레드(Thread)가 생성되어 서버의 구성 옵션인“max worker threads”의 임계 값에 도달한 경우 해당 스레드들이 종료될 때까지 새로운 연결이 불가능한 경우도 있습 니다. 이런 경우에도 역시 다음과 같은 오류 메시지가 반환되기도 합니다.

이러한 경우를 확인하기 위해 SQL Server 진단 유틸리티인 SQLDiag.exe를 실행하여 원인을 찾아 보겠습니다.

명령 프롬프트를 실행하여 SQL Server가 설치되어 있는“C:\Program Files\Microsoft SQL Server\MSSQL\Binn”폴더로 이동하여 SQLDiag.exe를 실행합니다.

SQLDiag.exe를 실행하면 기본적으로 오류 로그 폴더”C:\Program Files\Microsoft SQL Server\MSSQL\LOG”에 SQLdiag.txt 라는 결과 파일이 만들어집니다.

SQLDiag.exe 유틸리티는 다음 과정을 수행합니다.

그러나 작업자 스레드의 개수가“max worker threads”의 임계값(기본 설정 255개)에 도달하여 추가적인 스레드를 할당받을?의 ②~⑨ 번 작업까지의 결과를 출력하기 위해서 대기하게 됩니다. SQLdiag.txt를 살펴보면 ① Error Log 부분에서 17884 메시지를 발견하게 됩니다. 이것은 CPU당 하나씩 있는 SQL Server User Mode Scheduler가 새로운 스레드를 생성하지 못한다는 것을 의미합니다. 이 경우 SQL Server는 이와같은 상황을 교착상태로 처리합니다. 따라서, 추적 플래그(Trace flag) 1204를 지정하여 교착상태 발생과 관련해서도 관련된 정보를 수집할 수 있습니다. 마이크로소프트의 기술 문서에는 다양한 경우에 발생하는 17884 오류에 대한 설명과 핫픽스를 제공하고 있습니다. 만약, 단순히 동시 사용자가 많다면“max worker threads”임계 값을 적정하게 조정하여 이와 같은 현상을 방지할 수 있습니다.

다음은 마이크로소프트가 제공하는 OSTRESS 유틸리티를 사용하여 스레드 할당이“max worker threads”임계값에 도달하는 경우를 살펴 보겠습니다.

위의 사이트에서 OSTRESS 유틸리티를 다운로드 받고 setup.exe를 실행합니다.

OSTRESS 유틸리티를 실행하기 위한 환경은 다음과 같습니다.

시작→ 실행→ CMD를 입력한 후 엔터 키를 눌러서 명령 프롬프트를 실행합니다.

프로그램이 설치된 C:\Program files\rml 폴더로 이동하여 OSTRESS.EXE /? 를 입력하여 실행 매개 변수를 확인합니다.

이제 작업자 스레드의 개수가 기본 설정 임계값인 255에 도달하게 되면 어떤 현상이 발생하는지 테스트해 보겠습니다.

① 쿼리 분석기를 실행하여 다음과 같이 쿼리를 입력합니다.

위의 결과를 살펴보면“max worker threads”는 최소 32개에서 최대 32,767개까지 설정 가능하고 현재의 구성값은 255개이며, 현재 적용되어 있는 값도 255개라는 결과를 보여주고 있습니다.

다음과 같이 엔터프라이즈 관리자를 통해서도 확인 가능합니다. 서버의 속성 창을 실행해서
[프로세서] 탭을 클릭합니다. [최대 작업자 스레드 수] 부분의 값을 확인합니다.

② 쿼리 분석기에서 다음과 같은 쿼리를 입력하고 실행합니다. pubs 데이터베이스의 authors 테이블의 각 행에 각각 배타적 잠금(Exclusive Lock)이 걸리게 됩니다.

③ 명령 프롬프트를 실행하고 OSTRESS가 설치된 경로로 이동합니다.

④ 이제 254개의 활성 스레드를 생성합니다. 실행되는 254개의 스레드는 모두 ②에서 실행 된 트랜잭션의 잠금으로 대기하게 됩니다.

⑤ 이제 쿼리 분석기에서 추가로 새로운 창을 열어봅니다. 연결이 되기 위해서는 활성 스레드를 필요로 하는데 이미 255개의 작업자 스레드가 실행 중이므로 추가로 SQL Server에 연결하지 못함을 확인할 수 있습니다.

⑥ 쿼리 분석기 창으로 돌아가서 롤백을 실행하여 잠금을 해제합니다.

⑦ 명령 프롬프트에서 SQL Server가 설치된“C:￦Program File￦Microsoft SQL Server ￦MSSQL￦Binn”폴더로의 출력 파일을 열어 보면 17884 메시지를 발견하게 됩니다.

5. SQL Server를 설치한 이후 컴퓨터의 이름을 변경한 경우에도 로컬에서 Shared Memory를 이용한 접근이 아닌 경우 연결이 실패합니다. 클라이언트에서는 다음과 같은 오류 메시지를 받게 됩니다.

SQL Server의 기본 인스턴스의 이름은 설치된 컴퓨터의 이름과 같도록 구성되고 이 정보는 master 데이터베이스의 sysservers 시스템 테이블에 기록됩니다. 기록된 인스턴스의 이름 정보는 master 데이터베이스의 sysservers 시스템 테이블이나 sp_helpserver 시스템 저장 프로시저를 이용하여 확인할 수 있습니다.

① 명령 프롬프트를 실행한 후 hostname 을 입력하고 엔터 키를 눌러서 현재 컴퓨터의 이름을 확인합니다.

② master.dbo.sysservers 시스템 테이블을 조회하거나 sp_helpserver 시스템 저장 프로 시저를 실행하여 현재 인스턴스 이름의 등록 정보가 정확한지 확인합니다.

③ 컴퓨터 이름과 등록된 SQL Server 인스턴스 이름이 다른 경우 직접 master 데이터 베이스의 sysservers 시스템 테이블을 수정하거나 sp_dropserver, sp_addserver, sp_serveroption 시스템 저장 프로시저를 실행하여 기존에 등록된 서버를 삭제하고 새로 변경된 서버의 이름을 등록합니다. sp_serveroption 시스템 저장 프로시저는 sysservers 시스템 테이블에 등록된 서버의 등록 옵션을 지정하는 프로시저입니다.

6. SQL Server의 인증 모드 설정이 윈도우즈 인증인 경우 SQL 로그인으로 인증을 요청하게 되면 다음과 같은 오류 메시지가 반환됩니다.

이번에는 마이크로소프트 사이트에서 관련 메시지를 가지고 검색해 보겠습니다.

위에 표시된 사이트에 접속해 제품 검색에“SQL Server 2000”을 선택하고 검색어 부분에 오류 메시지 번호 또는 발생한 메시지를 입력하여 검색합니다.

이제 화살표를 누르면 다음과 같은 결과가 반환됩니다.

INF: Typical(표준) 설치로 SQL Server 2000을 설치하면 기본 보안 모드는“Windows 인증”이다 라는 부분을 클릭하여 내용을 보면 (INF란 단순 정보로 분류되었다는 의미 입니다.)

앞에서 보았던 것과 동일한 오류 메시지를 발견할 수 있습니다. 또한 이에 대한 해결방법으로 아래의 지시에 따라 인증모드를 변경함으로써 해결할 수 있다는 사항도 발견할 수 있습니다.

인증 모드를“Windows NT Authentication Mode(only)”에서“Mixed Mode”로 변경하려면
아래 단계를 수행합니다.

또는 레지스트리를 통해서도 SQL Server의 인증 모드의 확인과 변경이 가능합니다. 레지스트리 편집기를 실행합니다. 다음의 레지스트리 키를 확인합니다.

REG_DWORD 값이 1인 경우는 윈도우즈 인증만 가능한 설정이고 2인 경우는 혼합 모드로 윈도우즈 인증과 SQL 인증이 모두 가능한 상태입니다. 값을 변경하는 경우에는 SQL Server 서비스를 재시작해야 합니다.

위에 열거한 방법들을 통해 해결점에 도달했다고 판단하셨습니까? 물론 위에서 열거한 경우 외에 다양한 원인이 있을 수 있습니다.

이제 다섯 번째 단계인 Check for Success 단계로 들어가 보겠습니다. 성공 여부를 면밀히 점검해야 합니다. 동일한 오류 메시지가 여러 가지의 경우에 발생 가능하다는 것을 확인할 수 있었습니다. 또한, 단순히 눈에 보이던 현상만 해결되었다고 해서 문제가 완전히 종결된 것은 아닐 수도 있기 때문입니다. 문제가 해결된 것으로 판단된다면 원인을 찾아 내었을 것이고, 그렇다면 테스트 환경을 구축하고 발생했던 문제와 동일한 상황을 이끌어 내고 앞에서 성공한 방법으로 다시 한번 확인하기 바랍니다. 그리고, 잠재적인 다른 문제점들은 없는지 점검해야 합니다.

"모로 가도 서울만 가면 된다"는 말은 아주 위험한 발상입니다. 오히려 나중에 더 큰 문제를 야기할 수도 있기 때문입니다. 해결은 하였으나 그 방법이 적절하지 않아 또 다른 문제를 야기하는 경우도 있을 수도 있고 그 방법보다 더 효율적인 방법이 있을 수도 있기 때문에 마지막 단계인 Tie up Loose ends 단계로 넘어가서 발생한 문제의 원인과 해결방법의 정합성을 점검하고 이것을 문서로 정리하여 향후 발생되는 문제에 대해 참고 자료로 활용토록 해야 합니다.

또한, 앞 단계에서 진행한 해결 방법과 원인의 진단이 정확했는지 인터넷의 관련 사이트 등을 통해서 유사한 문제와 해결 방법 등에 대한 사항을 꼼꼼히 점검해 보아야 합니다. 앞의 단계에서 해결점에 도달하지 못한 경우에도 인터넷에 공개되어 있는 사례를 수집하여 유용하게 참고자료로 활용할 수 있습니다.

자?와 인터넷 검색을 통해 얻어낸 관련 자료들을 모아 비교 정리하여 다음의 예와 같이 장애 일지나 오류 발생 일지와 함께 보관하면, 일련의 문제 해결 과정이 완전하게 마무리됩니다.

오류 발생 일지

① 개발 서버에서 엔터프라이즈 관리자 또는 쿼리 분석기로 운영 서버에 접속 시 다음과 같은 오류 메시지가 반환되고 연결되지 않음

② 개발 서버에서 운영 서버로의 Linked Server 연결 시 아래와 같은 오류 메시지가 반환되고 연결되지 않음

오류 발생 시 환경

① 개발 서버에 서비스 팩 3 적용

② 운영 서버는 현재 서비스 팩 1이 설치되어 있고 서비스 팩 3은 미 적용 상태임

③ 상기 사항 외에 운영 서버에 패치 등의 프로그램 설치 작업은 수행된 바 없음.

조치사항

① 운영 서버에 서비스 팩 3 설치

주의 및 확인 사항

① 서비스 팩 설치 시 스탠바이 서버와 같은 읽기 전용 데이터베이스가 존재할 경우 설치가 실패함 (서비스 팩 3 설치 전에 읽기 전용 속성을 해제하여야 하며 스탠바이 데이터베이스는 재구성하여야 함)

기타사항

참고 자료 : 서비스 팩 프로그램 폴더의 sp3readme.htm