이 옵션을 가능하게 하는 한가지 방법은 MS Exchange Server/Client를 인스톨 한 다음 SQL Server 6.5로부터 메일을 받는 계정을 대표하는 프로파일을 만드는 것이다. 그 다음에는 SQL Server의 SQL Mail 옵션이 이 프로파일을 가리키도록 설정할 수 있다. 이 방법을 실제로 사용해 본 결과 매우 잘 작동하였는데 SQL Server에서 메일을 발송하여 직접 Exchange/Outlook Inbox로 보낼 수 있었다.

SQL Server 6.0 버전도 이와 같은 방법을 사용할 수 있는 지와 이와 유사한 옵션이 MS Mail 사용자에게도 존재하는 지는 확실하지 않다.

스토어드 프로시저나 트리거에서 메일을 보낼 수 있는가?

xp_sendmail 프로시저를 사용하면 된다.

SQL Server는 4.2x 이후의 버전부터 사용자가 로그인 할 필요 없이 자동으로 MS Mail 세션을 시작하도록 설정할 수 있게 되었다.예를 들면 6.0에서는 SQLSetup 프로그램에서 메일 파라미터를 설정한다. 이 때 메일 세션을 자동적으로 실행하도록 확실하게 지정해야 한다(그렇지 않으면 xp_startmail 프로시저를 사용해서 메일 세션을 직접 시작 시킨다 - 파라미터로 사용자 명과 패스워드를 넘겨주어야 한다)

시스템 계정으로 SQL Server 서비스를 실행중이라면 Mail postoffice를 위해서 공유 자원을 만들어야 하며 이를 서비스에서 사용할 수 있도록 레지스트리에 지정해야 한다. 수정할 레지스트리 키는 다음과 같다.

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanmanServer

\Parameters\NullSession Shares...

이에 관한 정보는 마이크로소프트의 Knowledgebase Q118501에 나와 있으며 URL은 다음과 같다.

http://198.105.232.6:80/KB/bussys/sql_odbc/Q118501.htm

시스템 테이블

종속 관계(dependencies)를 확인하고자 할 때 sysdepends 테이블의 정보가 믿을만 한가?

sysdepends 테이블은 자식(child) 종속 관계만을 기록하며 부모(parent) 종속 관계는 기록하지 않는다. sysdepends 테이블은 생성되는 객체(예를 들면 CREATE PROCEDURE)로부터 얻을 수 있는 정보에 기초해서 내용이 채워진다는 점을 염두에 두어야 한다.

새로운 스토어드 프로시저가 sp2를 호출하는데 이 프로시저가 생성되는 시점에 sp2가 이미 존재하고 있다면 sysdepends에는 새로운 정보가 갱신된다. 그러나 sp2가 나중에 추가된다면 sysdepends에는 아무런 정보도 추가되지 않는다. sysdepends는 단지 보여주기 위한 것일 뿐이므로 그 내용을 과신해서는 안 된다.

SQL Server의 시스템 테이블을 고칠 수 있는가? 그리고 트리거를 시스템 테이블에 만들 수 있는가?

마이크로소프트에서 작성한 코드를 사용하지 않는 한 시스템 테이블을 직접 수정하는 것은 지원되지 않는다. 그러므로 확신이 서지 않는다면 아예 작업을 하지 말거나 백업을 꼭 받아두도록 한다.

syslocks와 sysprocesses 등과 같은 materialised table을 제외하면 일반적인 SQL 명령을 사용하여 시스템 테이블을 수정할 수 있다.

시스템 테이블에 따라서 SQL Server가 자체적인 API를 통해서 갱신하는 것도 있고 표준 TSQL을 사용해서 작업하는 것도 있다. 표준 TSQL을 이용해서 수정하면 트리거가 실행되겠지만 이렇게 작업할 수 있는 테이블의 목록을 알 수 없기 때문에 만약 사용하더라도 지원되지 않을 것이다.

시스템 테이블을 수정하려면 먼저 "allow updates" 플래그를 아래와 같이 설정해야 한다.

sp_configure ‘allow updates’,1

go

reconfigure with override

go

이제 시스템 테이블을 수정할 수 있다. 위의 작업은 반드시 트랜잭션 내부에서 하여야만 의도하는 것보다 더 많은 레코드를 수정하였을 때 롤백 시킬 수 있다. 작업이 끝난 다음에는 ‘allow updates’ 플래그를 원래대로 돌려 놓는다.

sp_configure ‘allow updates’,0

go

reconfigure with override

go

때로는 마이크로소프트가 사용자들이 함부로 건드릴 수 없도록 별도의 안전 장치를 해 놓은 경우도 있다. sysindexes를 예로 들 수 있는데 WHERE 절에서 name, id, indid 를 지정하지 않으면 갱신 명령이 실행되지 않는다.

전송/객체 및 데이터 이동

다른 DBMS나 포맷으로부터 SQL Server로 데이터를 옮기는 방법은?(예를 들면 FoxPro, Access, AS/400, DB/2, 오라클 등)

여러 가지 방법이 있다.

Access의 경우에는 마이크로소프트 웹 사이트에서 무료로 받을 수 있는 Access upsizing wizards를 사용하면 된다. http://www.microsoft.com/support로 가면 softlib 항목에서 찾을 수 있다. 이것을 사용하면 Access에서 SQL 4.x 또는 6.x로 변환할 수 있다. 현재 7.x로의 변환은 지원되지 않으므로 먼저 6.5로 변환한 후에 7.0으로 업그레이드 하는 절차를 거쳐야 한다.

다른 DBMS에서 플랫 파일 형태로(예를 들면 탭 또는 쉼표로 구분된 파일, 고정 포맷 파일 등) 데이터를 만들 수 있다면 BCP.EXE를 사용해서 작업하면 된다. BCP.EXE는 콘솔 프로그램으로 Books Online에 자세하게 설명되어 있는데 SQL Server에서 데이터를 뽑아내거나 로드하는 가장 빠른 방법이지만 플랫 파일만을 지원한다.

다른 포맷에 대한 ODBC 드라이버를 가지고 있다면 시중에는 데이터의 전송과 마이그레이션 기능을 가진 여러 가지 툴이 나와 있으며 이들은 GUI 기반으로 되어있지만 명령 행에서 자동으로 작업을 실행하는 것도 지원한다. 어떠한 ODBC 데이터 소스 간의 작업에도 사용할 수 있으며 어느 한 쪽이 꼭 SQL Server일 필요도 없다. 다음과 같은 제품들이 있다.

Data Junction(http://www.datajunction.com)

SQL Mover(http://www.sqlmover.com)

InfoPump(http://www.platinum.com)

DBArtisan(http://www.embarcadero.com)

SQL Server 7.0에는 위의 제품들과 유사한 기능을 하는 DTS 라는 툴이 포함되어 있다. 이것은 어떠한 ODBC 또는 OLE-DB 데이터 소스와도 작업을 할 수 있으며 어느 한 쪽이 반드시 SQL Server 7.0일 필요도 없다. 그러나 만약 SQL Server 7.0을 대상으로 작업을 하지 않는 경우에는 라이센스 문제가 없는지 먼저 확인을 해 보아야 한다.

AS/400을 위한 제품으로는 예전부터 이용되어온 몇 가지 툴이 있다(실시간 리플리케이션과 전송 기능을 제공함).

Data Mirror(http://www.datamirror.com)

Symbiator(http://www.execusoftsystems.com)

마스터의 tempdb 데이터베이스를 삭제하는 방법은?

다음과 같이 하면 된다.

tempdb를 2MB 크기로 RAM에 올라가도록 설정한다. SQL 엔터프라이즈 매니저나 sp_configure를 사용하면 된다.

reconfigure with override를 실행한다.

SQL Server를 재기동 한다.

tempdb를 위한 새로운 디바이스를 추가한다. 단, temp_db라는 이름은 사용하지 말고 다른 이름을 사용하도록 한다.

새로 만든 디바이스를 디폴트 디바이스가 되도록 한다. 특히 마스터를 포함해서 다른 디바이스가 "Default"로 지정되어 있지 않도록 한다. 디폴트 상태는 SQL 엔터프라이즈 매니저나 sp_diskdefault 스토어드 프로시저를 사용해서 설정할 수 있으며 두 가지 모두 Books Online에 자세하게 설명되어 있다.

tempdb를 RAM에 존재하지 않도록 설정한다(값을 0으로 지정하면 됨).

reconfigure with override를 실행한다.

SQL Server를 재기동 한다.

디폴트로 사용하고자 하는 디바이스를 원하는 대로 지정한다.

xp_cmdshell을 이용해서 bcp를 실행할 때 문제가 있다. bcp가 실행되지 않거나 찾아야 할 파일을 찾지 못하는 이유는 무엇인가?

먼저 xp_cmdshell을 실행할 수 있는 권한이 있는지 확인해야 한다(xp_cmdshell ‘dir’을 실행하여 파일 명들이 반환되는지 보면 된다).

그 다음에는 MSSQLSERVER 서비스가 별도의 NT credentials 하에서 실행 중인지를 확인한다. 어떤 유저로 로그인 하였는지는 상관 없다(SQL Server는 콘솔에 아무도 로그인 하지 않아도 잘 동작하지 않는가). 그러므로 로그온 계정이나 매핑된 드라이브는 아무 상관이 없다. bcp를 실행하는 것은 사용자가 아니라 SQL Server이기 때문에 로컬 시스템의 드라이브 밖에는 인식하지 못한다(여기서 로컬은 서버를 의미함). 만약 워크스테이션에서 쿼리를 실행할 때 쿼리가 워크스테이션의 로컬 드라이브를 참조한다고 혼동하지 말기 바란다.

MSSQLSERVER에 의해서 사용되는 NT credentials의 기본값은 Localsystem 계정이다. 어떤 계정 하에서 MSSQLSERVER가 수행되는지를 확인하려면 제어판->서비스 에서 MSSQLSERVER를 선택한 다음 start-up 옵션을 보면 된다.

Localsystem 계정은 네트워크를 사용할 수 있도록 인증되어 있지 않기 때문에 네트워크 상의 공유 자원을 사용할 수 없다.

따라서 xp_cmdshell에 의해서 수행되는 bcp가 네트워크 자원을 사용하도록 하려면 다음 같은 두 가지 방법 중 하나를 사용해야 한다.

MSSQLSERVER 서비스가 수행되는 계정을 네트워크 사용 권한이 있는 사용자 계정으로 변경한다.

대상 서버의 레지스트리에서 다음의 항목을 수정하여 사용하고자 하는 공유 자원을 추가한다(추가된 공유 자원은 누가 접속해 오는지를 검사하지 않기 때문에 Localsystem 계정에서도 사용 가능하게 된다). 변경된 사항이 적용되기 위해서는 대상 서버의 server 서비스를 재기동 시켜야 한다. 이 방법은 해당 공유 자원에 대한 보안 설정을 없애기 때문에 그곳에 보관되어 있는 내용이 유출될 수 있음을 주의하여야 한다.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer

\Parameters\NullSessionShares

어떠한 방법을 사용하던 간에 필요한 공유 자원을 참조할 때에는 드라이브 문자 대신 UNC 명을 사용해야 한다.

예를 들면. xp_cmdshell ‘bcp servername..tablename out \server01\share\bcp.fil .............’

SQL Server 디바이스를 한 디스크에서 다른 디스크로 옮기거나 이름을 변경하려면 어떻게 해야 하는가?

두 가지 방법이 있다.

디바이스 미러링을 사용한다. 해당 디바이스를 새로운 위치에 미러링 한 다음 미러링 관계를 끊고 이전의 디바이스를 삭제한다. 이 방법을 사용하면 SQL Server를 셧다운 할 필요가 없으며 GUI 또는 TSQL을 통해서 작업할 수 있다.

Books Online에 나와 있는 sp_movedevice를 사용한다. 변경 작업을 마친 다음에는 SQL Server를 정지시키고 물리적으로 디바이스를 이동시킨 후에 다시 SQL Server를 기동한다. 작업을 하는 동안에는 서비스 단절이 불가피하지만 운영체제의 명령이 SQL 미러링보다 빠르기 때문에 이 방법이 속도가 더 빠르다.

sp_movedevice은 sysdevices 테이블에서 phyname을 갱신하는 작업만 한다.

위의 방법은 모든 유저 데이터베이스에 대해서 적용할 수 있다. 이 방법으로 마스터 데이터베이스를 옮기려고 한다면 sysdevices의 phyname 파라미터는 단지 문서화를 위한 것임에 주의하여야 한다(다만 일관성을 유지하기 위해서 함께 변경해 주는 것이 좋다). SQL Server는 마스터 디바이스를 찾기 위해서 실제로는 다음의 레지스트리 항목을 참조한다.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\MSSQLServer

\Parameters\SQLArg0

그러므로 수정해야 할 것은 사실 이 레지스트리 키 값인 것이다.

인텔 머신과 알파 머신 사이에서 SQL Server 데이터를 전송하는 방법은?

SQL Serer 6.5 이하의 버전에서는 DUMP와 LOAD DATABASE 명령으로는 원하는 작업을 할 수가 없다(바이트 재정렬을 하지 않기 때문). 그러므로 bcp나 SQL 엔터프라이즈 매니저에서 제공하는 전송 도구를 사용하거나 아니면 직접 ODBC/DMO에 기반한 애플릿을 작성해야 한다.

SQL Server 7.0에서는 바이트 재정렬이 이루어지기 때문에 서로 다른 아키텍쳐를 가진 컴퓨터 간의 DUMP와 LOAD가 지원된다.

서로 다른 서버 상에 존재하는 SQL Serer 데이터베이스 사이에서 데이터를 전송하는 방법은?

전체 데이터베이스에 대해서 가장 빠르게 작업하는 방법은 DUMP DATABASE 또는 LOAD DATABASE 명령을 사용하는 것이다. 단, 데이터베이스의 크기가 같아야 하고 동일한 순서의 동일한 세그먼트 조각으로 이루어져 있어야 한다. 두 데이터베이스에 대해서 sp_help_revdatabase를 실행해 보면 필요한 DDL을 점검할 수 있도록 해 줄 것이다. 네트워크로 연결되어 있지 않다면 로컬 테이프에 덤프 시킨 다음 이 테이프를 보내는 방식으로 작업할 수도 있다.

만약 테이블과 데이터만을 전송하고자 한다면 BCP.EXE를 사용하면 된다. 이것은 콘솔 프로그램으로 Books Online에 자세히 설명되어 있다. 한번에 하나의 테이블에 대해서만 작업을 하며 디스크에 플랫 파일을 만들게 된다.

스토어드 프로시저 또는 뷰 등에 대해서 작업한다면 BCP처럼 동작하는 DEFNCOPY.EXE라는 오래된 콘솔 프로그램을 사용해 볼 수 있다. NT에서는 적어도 6.5 버전까지는 작동하긴 하지만 SQL Server를 OS/2에서 사용하지 않는다면 요즘은 잘 사용되지 않는다.

SQL 엔터프라이즈 매니저에는 GUI 형태로 사용 가능한 전송 기능이 내장되어 있으며 SQL Server 7에는 동일한 툴이 별도로 제공된다. 이것은 두 개의 데이터베이스/서버 간의 모든 객체를 전송하는 것을 지원하지만 반드시 서로 네트워크로 연결되어 있어야 한다.

다른 회사에서 판매중인 DBMS 관리 프로그램에는 다음과 같은 것들이 있다.

Data Junction (http://www.datajunction.com)

SQL Mover (http://www.sqlmover.com)

InfoPump (http://www.platinum.com)

DBArtisan (http://www.embarcadero.com)

문제해결 (Troubleshooting)

SQL Server는 제대로 끊어지지 않은 커넥션을 어떻게 정리하는가?

정리하지 않는다. 사용자가 KILL 명령을 내리거나 운영 체제로부터 사용중인 네트워크 커넥션이 끊어졌다는 신호를 받지 않는 한 커넥션을 끊지 않는다.

운영 체제가 네트워크 커넥션을 끊는 데 걸리는 시간과, 또는 실제로 끊느냐 끊지 않느냐는 사용하는 Net-Lib와 네트워크 프로토콜에 따라서 다르다. 각 네트워크 프로토콜의 Keep Alive Frames와 Session Time Outs 등의 파라미터에 대한 가장 좋은 지침서는 NT Server 리소스 킷으로 여기에는 NT의 다양한 네트워크 계층이 어떻게 동작하는 지에 대해서 설명하고 있다.

일반적으로 Netbeui를 통한 네임드 파이프 커넥션은 상당히 빨리 타임 아웃 되며 그 다음으로는 IP를 통한 네임드 파이프의 타임 아웃이 빠르다. TCP/IP 소켓을 사용한다면 세션들은 기본적으로는 타임 아웃 되지 않는다.

SQL Server의 printdmp.exe 프로그램을 사용하는 작동시킬 수 있는 방법은?

없다. 이 프로그램이 Access Violation 덤프 파일을 분석하여 생성한 결과는 SQL Server 소스 코드가 없다면 쓸모가 없다.

만약 Access Violation 덤프가 발생하고 이미 가장 최신의 서비스 팩을 설치하였다면 마이크로소프트의 PSS에 전화를 걸어서 지원을 요청하는 수 밖에 없다. 만약 PSS의 요청에 따라서 사용자가 직접 printdmp를 실행하는 경우에는 PSS에서 구체적인 방법을 알려줄 것이다. 그러나 아직까지 PSS에서 사용자가 printdmp를 실행하도록 요청한 경우를 본적이 없다(PSS에서는 일반적으로 덤프 파일 전체와 SQL errorlog(s), sp_configure 결과 등을 필요로 한다).

SQL Server/Client에서 공포의 파란 화면과 시스템 정지, 그리고 서버 재기동 등의 문제가 발생한다.

위의 모든 문제는 커널 모드에서 동작하고 있는 NT에서 발생한다. 예를 들면 NT의 일부분, 스카시 드라이버, 네트워크 드라이버, 비디오 드라이버 등이 발원지가 될 수 있다.

모든 SQL Server 코드는 다른 프로그램과 마찬가지로 유저 모드에서 동작하기 때문에 마이크로소프트 워드와 마찬가지로 파란 화면을 일으킬 소지가 없다.

만약 이와 같은 문제가 발생한다면 파란 화면이 떴을 때 조치하는 일반적인 방법대로 검사를 해야 한다. 예를 들면 문제의 발생 시점에 실행 중인 드라이버나 프로그램의 검사, dumpexam 사용, 최신의 서비스 팩을 설치, 마이크로소프트에 문의 등의 조치를 취해봐야 한다.

특정 쿼리를 실행하면 다른 사용자들이 시스템을 사용할 수 없도록 정지시켜 버리곤 한다. 특히 tempdb에서 문제가 발생하는데 어떻게 된 일인가?

이와 같은 문제는 보통 락(lock)과 관련이 있다. 문제의 쿼리가 어떤 일을 하고 있는지 sp_lock과 sp_lock2를 사용해서 확인해 보도록 한다.

마이크로소프트가 ATOMIC 트랜잭션을 도입하여 테이블을 트랜잭션 중간에 만들 수 있도록 허용함으로써 사람들을 곤혹스럽게 만드는 일들이 SQL Server 6.5에서 발생하기 시작했다. 이 기능으로 말미암아 SELECT INTO를 실행하면 관련된 시스템 테이블에 락을 걸어서 다른 사용자들이 사용할 수 없게 되는 것이다. 따라서 SELECT INTO가 오랜 시간동안 실행되면 정말 큰 문제를 일으키게 된다.

마이크로소프트는 이 문제를 인지해서 해결책을 제시하였는데 만약 서비스 팩 1이 설치되어 있다면 트레이스 플래그 T5302를 세팅함으로써 이 특성을 정지시킬 수 있다. 보다 자세한 정보는 Q153441을 참조하기 바란다.

SQL Server 데이터베이스가 "suspect"라고 표시되어 있다. 어떻게 하면 좋은가?

다음의 해결 방법 외에 추가 정보가 필요하면 http://www.microsoft.com/support 에서 특히 Q165918을 비롯한 Knowledgebase를 참조해 보기 바란다.

먼저 <sql>\LOG 디렉토리를 확인해서 최근에 생성된 errorlog(s) 파일들을 확인한다. 여기를 보면 데이터베이스가 suspect로 표시된 이유가 나와 있을 것이다. 어떤 문제가 나와 있던 간에(예를 들면 파일을 찾을 수 없음, 권한 문제, 하드웨어 에러 등) 먼저 그것부터 해결하도록 한다

문제가 해결된 다음에는 데이터가 이상이 없을 것임을 확신하거나 또는 백업 받은 것이 없어서 더 이상 잃을 것도 없다면 데이터베이스의 상태를 Normal로 변경하고 SQL Server를 재기동 한다. 데이터베이스의 상태를 변경하고 복구에 관한 보다 자세한 정보를 얻기 위해서는 Books Online에서 sp_resetstatus 스토어드 프로시저를 참조하기 바란다.

sp_resetstatus 정보를 참조할 수 없는 사용자를 위해서 간단히 정리하면 아래와 같다.

UPDATE master..sysdatabases SET status = status ^ 256 WHERE name = <dbname>

그래도 데이터베이스가 계속해서 suspect 모드로 돌아가 버리지만 원인을 찾을 길이 없고 최근에 받아둔 백업도 없다면 데이터베이스를 Emergency 모드로 전환함으로써 데이터베이스로부터 데이터를 뽑아낼 수 있다. 이렇게 하면 bcp나 Transfer Manager를 사용해서 데이터와 객체를 추출할 수 있으므로 새롭게 데이터베이스를 만들도록 한다. 단, 데이터가 손상을 입었거나 트랜잭션의 일관성이 깨져 있을 수도 있다.

데이터베이스를 Emergency 모드로 전환하려면 다음 명령을 수행해야 한다(그 전에 시스템 테이블에 대한 갱신을 허용해야 한다)

UPDATE master..sysdatabases SET status=-32768 WHERE name=‘<dbname>’

SQL errorlog를 보면 "Exception Access Violation" 메시지가 나와 있다.

SQL Server에서 GPF 또는 Access Violation이 발생하고 있는 것으로 보이므로 SQL errorlog에서 이와 관련된 메시지를 확인해 보아야 한다. 여기에는 단지 세 가지의 이유만이 존재한다.

데이터베이스 손상 - dbcc checkdb, newalloc, checkcatalog 명령으로 확인해 볼 수 있다.

하드웨어 문제 - 일반적으로 메모리 문제가 많다.

SQL Server 코드의 버그(이것이 가능성이 가장 높다 - 데이터베이스가 손상되어도 GPF를 일으키는 경우는 극히 드물며 하드웨어 에러도 대부분 다른 형태로 나타난다). SQLSERVER.EXE와 DLL을 구성하고 있는 것은 마이크로소프트의 C 코드이지 사용자의 TSQL 코드가 아니다. 만약 SQL 코드에서 Access Violation를 일으킨다면 이것은 사용자의 문제가 아니라 마이크로소프트의 버그이다.

데이터베이스의 손상 문제가 아니라고 가정하고 다음의 진단 과정을 따라서 점검해 보자.

테크넷의 마이크로소프트 Knowledgebase를 참조한다(테크넷을 가지고 있지 않다면 지금 바로 주문하는 것이 좋다). 또한 테크넷보다 최신의 정보를 담고 있는 웹 사이트인 http://www.microsoft.com/support도 참조해야 한다. Access Violation과 관련된 모든 버그를 찾아보면 해결 방법이 포함된 것들도 많음을 알 수 있다.

가장 최신의 SQL Server와 서비스 팩을 사용하고 있는가? 마이크로소프트는 각 서비스 팩에서 많은 Access Violation 에러를 수정하였기 때문에 최신 버전을 사용할만한 충분한 가치가 있다. 만약 최신 서비스 팩을 사용하지 않고 있다면 마이크로소프트에서는 가장 먼저 최신 서비스 팩을 설치하기를 권할 것이다.

SQL errorlog를 확인하여 특히 그 시점에 어떤 SQL문이 실행 중이었는지 등의 모든 메시지를 저장해 둔다.

\LOG 디렉토리에 생성되는 SQLxxxx.DMP 파일들을 점검한다. 이 파일에는 문제가 발생한 시점에 SQL Server가 수행하고 있던 작업과 모듈 스택 트레이스 등이 기록되어 있다. 마이크로소프트로부터 지원을 받기 위해서 필요하므로 이 파일들을 보관해 둔다(PRINTDMP.EXE 유틸리티가 있기는 하지만 이 프로그램의 결과는 SQL Server C 소스 코드를 가지고 있지 않으면 소용이 없다)

문제를 재현할 수 있는가? 문제가 생길 당시 실행중이던 SQL 문이 errorlog에 나오지 않는다면 그 시점에 사용자나 개발자가 어떠한 일을 하고 있었는지 확인해 보도록 한다. 할 수만 있다면 SQL Trace를 사용하여 현재 실행중인 SQL 코드를 캡쳐 한다. 문제를 재현할 수 없더라도 errorlog(s)와 덤프 파일을 가지고 있다면 마이크로소프트에 연락해 보는 편이 좋을 것이다.

문제를 재현할 수 있다면 문제를 재현하는 스크립트를 작성할 수 있는지 확인한다. 이 스크립트는 새롭게 인스톨한 SQL Server에서 실행하였을 때에도 동일한 문제를 재현할 수 있어야 한다. 그러므로 여기에는 모든 테이블과 사용자 정의 데이터 타입, 트리거, 뷰 등 문제를 보여주기 위해서 필요한 모든 것이 들어 있어야 한다. 데이터도 필요한 경우에는 데이터의 크기는 가능한 최소로 유지할 수 있도록 한다(스크립트와 데이터의 크기가 작은 경우에는 뉴스그룹에 등록하면 MVP 가운데 한 사람이 여러분을 대신 해서 마이크로소프트에 보고할 수도 있을 것이다).

SQL문을 다시 작성하여 문제를 해결할 수 있는가? 문제를 재현할 수 있는 스크립트가 있더라도 마이크로소프트에서 매우 빠르게 해결 방안을 제공하기는 어렵다(수 백만 달러 규모의 고객이 아닌 이상). 그리고 문제의 해결 방안이 나오더라도 하나의 문제만을 위한 작은 패치가 아니라 여러 가지 패치를 포함한 최신 버전을 인스톨 하게 될 것이다. 이것은 리그레션 테스트를 거치치 않기 때문에 오히려 더 많은 문제를 일으킬 소지도 있다.

마이크로소프트의 PSS에게 문제를 보고한다. 만약 스스로 해결할 수 있다고 하더라도 PSS에 알리는 것이 좋다. 마이크로소프트가 버그 리포트를 받지 못한다면 그들은 문제를 수정할 수가 없다(문제를 재현할 수 있는 스크립트를 가지고 MVP가 여러분을 대신해서 처리해 줄 것이다). 버그와 관련된 지원 비용은 무료이기 때문에 사용자가 지불한 대금은 반환된다(그러나 일반적인 고객지원 라인에서는 전화를 받는 직원이 버그와 관련된 문제인지를 알 수 없으므로 일단 사용자의 신용카드 정보를 요구할 것이다)

버그를 보고할 때에는 다음과 같은 것들을 마이크로소프트에 제공해야 한다.

SQL Errorlog(s)

NT 이벤트 로그(만약 NT 에러가 발생하였다면)

문제 발생 시점에 실행 중이던 TSQL 코드

하드웨어의 상세 정보, NT 버전, 서비스 팩 등. 이와 같은 정보는 WINMSDP의 결과로부터 쉽게 얻을 수 있다.

SQL Server 7에는 이상의 정보의 대부분을 자동으로 모을 수 있는 sqldiag라는 유틸리티가 제공된다.

sqldiag -U -P -O

MSDB 전체 또는 일부 테이블이 없어졌는데 어떻게 하면 다시 만들 수 있는가?

\INSTALL 디렉토리에는 MSDB 데이터베이스와 관련 테이블들을 생성하는 데 사용되는 스크립트가 있다. 이들을 다시 만들려면 모든 디바이스가 그대로 존재하는 것을 확인하고 ISQL/W 또는 ISQL을 이용해서 다음 스크립트를 실행한다.

instmsdb.sql

servmsgs.sql

web.sql

SQL Server의 identify 값의 일관성이 깨져서 갭이나 중복된 값이 발생하는 이유는 무엇인가? 직접 해결할 수 있는 방법은 없는가?

identity가 구현된 방식의 특성으로 인해서 발생하는 문제이다. SQL Server는 성능을 떨어뜨리지 않기 위해서 새로운 레코드가 추가될 떄 마다 현재의 identity를 갱신하여 시스템 테이블에 커밋 하지는 않는다. 그렇게 하지 않으면 특히 SQL 6.x의 페이지 레벨 락킹 아키텍쳐 하에서는 감내할 수 없을 정도로 성능을 떨어뜨리는 수가 있기 때문에(심지어는 데드락도 발생할 수 있다) identity 값을 메모리에 저장하고 SQL Server가 정상적으로 셧다운 될 때 비로소 디스크에 커밋 하는 것이다.

따라서 SQL Server가 정상적으로 셧다운 되지 않거나 Exception Violation으로 인해서 메모리의 문제가 발생한다면 identity 값은 다음에 SQL Server가 기동하였을 때 잘못된 값을 가지게 된다. 또한 이 값이 제대로 갱신되지 못하도록 하는 버그가 몇 개 있는데 6.5 버전의 서비스 팩 3에서 대부분 수정 되었다.

사용자가 직접 조치 할 수 있는 유일한 방법은 SQL Server가 기동할 때마다 이 값이 정확하게 고쳐지도록 startup 스토어드 프로시저에(자세한 내용은 Books Online 참조) dbcc checkident(<tablename>) 명령을 넣는 것이다(테이블이 큰 경우에는 몇 분 정도 소요된다).

마이크로소프트에서 만든 코드와 스토어드 프로시저도 이 문제로부터 자유롭지 않다. 한 가지 흔하게 나타나는 경우는 데이터베이스를 덤프할 때 sysbackuphistory(MSDB)에서 키 값이 중복되었다는 메시지를 받는 것이다. 이 테이블이 identity 컬럼을 사용하기 때문에 발생하는 문제이다.

(마이크로소프트에서는 identity 컬럼의 동작 방식을 새롭게 설계하여 SQL Server 7.x에서는 이런 문제가 발생하지 않을 것이라고 공언하였다)

SQL Server의 log 디렉토리에 있는 *.DMP 파일들은 무엇인가? PRINTDMP.EXE를 사용해서 인쇄해 보려고 하였으나 실패하였다.

SQL Server에서 GPF가 발생하였다는 것을 의미한다.

덤프 파일에는 그 시점에 SQL Server가 실행중인 작업 내용과 모듈 스택 트레이스 등의 정보가 들어 있다. PRINTDMP.EXE 유틸리티가 제공되기는 하지만 SQL Server C 소스 코드를 가지고 있지 않는 한 그 결과는 별로 도움이 되지 않는다.

덤프 파일을 errolog 정보 및 문제 발생 시점에 수행중이던 SQL 문 등과 함께 저장해 둔 다음에 마이크로소프트의 PSS에 연락한다(단, 먼저 최신의 서비스 팩을 설치하고 dbcc를 실행하여 데이터베이스에 아무런 문제가 없는 것을 확인해야 한다)

SQL Server에서 특정 테이블들에 대한 권한을 철회할 때 항상 문제가 발생하는 이유는 무엇인가? : SQL Server에서 특정 테이블들에 대한 권한을 철회할 때 항상 문제가 발생하는 이유는 무엇인가? 명령은 정상적으로 실행되었으나 사용자들이 계속 권한을 가지고 있다(sp_helprotect로 확인함)

테이블의 컬럼 개수가 8n-1(예를 들면 7,15,22 등)일 때 발생하는 SQL Server의 버그이다.

이 문제를 해결하려면 sysprotects의 모든 항목을 삭제하고 필요한 권한을 다시 부여해야 한다.

use

go

exec sp_configure "allow updates",1

go

reconfigure with override

go

delete sysprotects where id = object_id("")

go

exec sp_configure "allow updates",0

go

reconfigure with override

go

SQL Server에서 "WARNING: Process being freed while holding Dataserver semaphore" 메시지가 발생하는 이유는 무엇인가?

이것은 매우 일반적인 에러이다.

이전에 발생했던 에러를 검사한다. 이것은 때때로 실제로 발생한 에러가 아니라 이전의 에러 때문에 SQL Server가 혼동하여 발생하는 증상으로 사용중인 리소스를 해제 시키지 않고 루틴을 종료하려고 시도하게 된다. 실제로 테크넷이나 마이크로소프트 Knowledgebase에서 찾아보아야 할 것은 이전에 발생한 에러이다.

리소스가 충분하지 않기 때문에 발생하는 경우가 종종 있으므로 open objects, locks, open databases의 개수를 늘려주면 도움이 될 것이다.

최신의 서비스 팩을 설치한다. 이 에러와 이면에 감쳐줘 있는 에러가 이미 서비스 팩에서 수정되었을 것이다.

만약 그래도 해결되지 않고 이 문제가 기존에 알려지지 않는 새로운 것이라면 마이크로소프트의 PSS로 연락하도록 한다. 새로운 데이터베이스에서도 스크립트를 통해서 같은 문제를 재현할 수 있다면 패치를 작성하기가 훨씬 용이할 것이다.

SQL Server에서 1112 에러가 발생하는데 어떻게 된 것인가?

이 메시지는 SQL Server 4.x에서만 발생하며 그 이후의 버전에서는 모두 수정되었다. 따라서 완벽하게 해결하려면 SQL Server 6.0 이상의 버전으로 업그레이드 해야 한다.

이 에러는 SQL Server가 익스텐트를 할당하는 도중에 다운된 경우에 발생하는데 이 때 가끔 익스텐트에 "being allocated" 비트를 세팅 하게 된다. 차후에 SQL Server가 테이블의 크기를 늘리기 위해서 이 익스텐트를 사용하려고 할 때 세팅 되어서는 안될 비트가 세팅 되어 있으므로 뭔가 문제가 발생하였다고 판단하여 에러를 발생시키는 것이다.

SQL Server는 언제나 같은 순서로 익스텐트를 할당하기 때문에 한번 이 에러가 발생하면 다른 객체를 삭제해서 데이터베이스의 앞쪽에 보다 가깝게 위치한 익스텐트를 마련해 주지 않는 한 계속 발생하게 된다. 그리고 이 해결 방법은 단지 다음에 1112 에러가 발생하기 까지 시간을 조금 연장해 줄 뿐이다.

이 문제를 해결하려면 마이크로소프트 PSS 또는 ftp://ftp.microsoft.com/bussys/sql/transfer 에서 1112.EXE 파일을 받아서 실행하면 된다. 이 파일에는 사용 방법도 포함되어 있다(데이터베이스를 단일 사용자 모드로 전환한 다음에 작업해야 한다). 이 프로그램은 단지 익스텐트 맵을 검색하여 "being allocated"로 되어 있는 비트를 리셋 시켜주는 작업만 한다.

이 패치는 문제가 발생한 이후에만 사용하여 해결할 수 있음을 주의해야 한다. 이 문제는 또 다시 발생할 것이므로 궁극적으로는 완전하게 수정된 SQL Server 버전으로 업그레이드 해야 한다.

SQL Server에서 "sort failed 1051" 메시지가 발생하는데 어떤 문제인가?

이 문제는 보통 인덱스를 생성할 때 타임 아웃에 걸리기 때문에 발생한다(만약 1501 다음에 "state 12" 라고 나와 있다면 타임 아웃 문제가 틀림 없다). 소스 코드에 하드 코딩 된 타임 아웃 값은 SQL Server 6.5 서비스 팩 3 에서 상향 조정되었기 때문에 이제는 거의 발생하지 않는다(가끔씩은 아직도 발생함). 이 에러는 보통 디스크 서브시스템의 속도가 느리거나 디스크 사용자가 많을 때 발생한다(따라서 에러를 발생한 쿼리가 실행될 때 다른 프로세스로부터 방해 받지 않도록 보다 빠른 디스크와 콘트롤러를 사용해야 한다).

만약 타임 아웃 문제가 아니라면 sp_configure 에서 "sort pages" 파라미터를 상향 조정해 본다. 이렇게 하면 정렬 작업을 메모리 상에서 보다 많이 처리하기 때문에 에러를 방지하는 효과가 있다.

그래도 해결이 되지 않는다면 에러 메시지와 state 번호를 가지고 마이크로소프트 PSS에 연락하여 어떤 코드에서 해당 state 메시지가 발생하는지를 알아낼 수 있도록 한다(state 코드는 유일한 값을 가지고 있다).

SQL Server/Client의 NT 도메인을 방금 변경하였는데 왜 서버에 더 이상 접속할 수 없는 것인가?

이것은 SQL Server의 문제가 아니라 NT의 문제이다. NT 인증을 필요로 하는 Net-Lib(네임드 파이프나 멀티프로토콜)를 사용하고 있다면 SQL Server를 실행하고 있는 NT로부터 인증을 받아야 한다. 인증을 받는지는 클라이언트의 명령 프롬프트에서 “NET VIEW \서버이름”과 같이 실행해 보면 확인할 수 있다. 만약 접근 거부(Access Denied) 메시지나 패스워드를 입력하라고 나오면 인증을 받지 못하는 것이다.

이런 경우에는 도메인 간에 트러스트 관계를 설정해야 한다. 또는 TCP/IP 소켓과 같이 인증이 필요 없는 Net-Lib를 사용하면 된다.

만약 트러스트(이것이 가장 좋은 방법임)를 설정할 수 없다면 도메인에 존재하는 계정으로 "net use \ipc$ /user:\ "와 같이 실행하여 해결할 수 있다. 그러나 이 방법은 수작업이라는 단점도 있고 패스워드가 변경된 경우에는 실패할 가능성이 항상 존재한다.

tempdb를 RAM으로 올리고 나니 SQL Server를 재기동 할 수가 없다.

SQL Server에 의해서 할당된 메모리에는 RAM상의 tepmdb는 포함되지 않기 때문이다. SQL Server와 tempdb, 그리고 NT를 위한 메모리가 충분하지 않으면 SQL Server는 기동 되지 않는다. 이 문제를 해결하려면 다음과 같이 작업하면 된다.

SQL Server와 SQL Executive를 정지시킨다. SQL 엔터프라이즈 매니저가 실행 중이지 않음을 확인한다.

<sql>\binn 디렉토리로 가서 "sqlservr -c -f"를 실행하면 SQL Server가 단일 사용자 모드로 기동 될 것이다.

이 윈도우의 텍스트 메시지는 무시하고 사라질 때 까지 기다린다(10~20초 이상은 걸리지 않을 것이다).

SQL Server가 이제 기동 되었을 것이다.

다른 윈도우에서 ISQL/W를 실행하여 sa 계정으로 로컬 접속을 한다.

ISQL/W에서 다음 명령을 실행한다.

sp_configure tempdb, 0

go

reconfigure

go

SQL Server가 실행중인 윈도우로 가서 "showdown" 을 입력하고 엔터 키를 누른다.

SQL Server가 셧다운 되지 않으면 를 쳐서 셧다운 시킨다.

이제 SQL Server를 정상적으로 기동할 수 있게 된 것이다. tempdb가 마스터 데이터베이스에 초기의 2MB 크기로 존재할 것이므로 tempdb의 크기를 적절히 조정 하도록 한다.

SQL Server 엔터프라이즈 매니저를 실행하면 "SQLOLE OLE object could not be registered. Class not registered(80040154) " 에러가 발생한다.

레지스트리에 클래스가 정상적으로 등록되지 않아서 발생하는 문제이다. regsvr32 프로그램을 사용해서 직접 등록하도록 한다.

regsvr32 <sql>\binn\sqlole65.dll

단, <sql>에는 실제로 SQL Server가 설치 되어 있는 드라이브와 디렉토리 명을 입력해야 한다.

시스템 테이블이 손상되었을 때 해결할 수 있는 방법은?

인덱스를 다시 만들어서 해결될 수 있는 문제라면 이를 위한 시스템 스토어드 프로시저가 있다.

sp_fixindex <db_name>,<system_table_name>,<index-id>

(예) sp_fixindex pubs,sysindexes,2

만약 sp_fixindex를 사용하여 수정하는 것이 잘 안되면 관련된 dbcc 명령을 직접 실행할 수도 있다. sysobjects의 넌클러스터드 인덱스를 예로 들면 다음과 같이 작업하면 된다.

DBCC DBREPAIR(dbid, REPAIRINDEX, sysobjects, 2)

sysindexes와 sysobjects 테이블의 클러스터드 인덱스는 재생성 하는 것이 불가능하다.

만약 위의 방법도 도움이 되지 않는다면 마지막 방법은 새로운 데이터베이스를 만들어서 SQL 엔터프라이즈 매니저의 전송 도구를 사용하여 정상적인 데이터와 객체를 복사하는 것이다.

SQL Server에서 1117번 에러가 발생하는데 익스텐트를 어떻게든 재구성할 수는 없는가?

관련된 데이터를 모두 select나 bcp로 뽑아낸 다음 문제의 객체를 다시 만드는 것이 좋다. 그러나, 익스텐트를 재구성 해보고 싶다면 먼저 백업을 하고 데이터베이스를 단일 사용자 모드로 전환한 후에 다음과 같이 시도해 보면 된다.

dbcc rebuildextents (@db_id, @object_id, @index_id)

파라미터:

@db_id 데이터베이스의 ID

@object_id 재구성할 객체의 ID

@inex_id 재구성할 인덱스의 ID

튜니

tempdb란 무엇인가?

tempdb는 SQL Server에 의해서 임시 작업 테이블을 만들기 위한 공간으로 사용된다. SQL 문에서 하나 또는 그 이상의 작업 테이블을 만드는 경우는 매우 흔하게 발생한다. 또한 스토어드 프로시저에서 명시적으로 tempdb에 임시 작업 테이블을 만드는 것도 자주 볼 수 있다. ‘ORDER BY’ 절을 사용하면 tempdb에서 정렬 작업을 하게 된다.

tempdb의 필요한 크기는 데이터베이스의 크기와 데이터를 처리하는 작업에 따라서 결정된다. 데이터의 50% 또는 그 이상의 크기를 가진 tempdb를 필요로 하는 것이 비합리적인 것은 아니지만 실제로 필요한 크기는 대부분 이보다는 훨씬 작을 것이다(크기 결정에 관해서는 다음 주제 참조)

SQL Server가 인스톨 될 때 tempdb의 크기는 디폴트로 2MB로 생성되는데 이 정도로는 대부분의 경우 실제로 사용하기에 불충분하다.

tempdb의 크기는 얼마나 커야 하는가?

tempdb의 크기를 결정하는 것은 예술적인 영역이라고까지 알려져 왔다. tempdb는 크게 두 가지 용도로 사용된다.

서버의 커널은 조인 또는 ORDER BY 등을 처리하기 위한 작업 테이블을 생성하는 공간으로 tempdb를 사용한다.

사용자 또는 스토어드 프로시저가 생성한 임시 테이블을 저장하기 위한 공간으로 사용된다.

필자가 여러분의 응용 프로그램에 대해서 일일이 알 수는 없으므로 다음과 같은 지침을 제시하고자 한다.

응용 프로그램에서 임시 테이블을 생성하지 않는다면 전체 데이터베이스 크기의 일정 비율 정도로 만드는 것을 권장한다. 일단 전체 데이터베이스의 10~25% 정도의 크기에서 부터 출발한다. 전체의 25% 정도의 크기로 디스크 파티션을 할당한 다음 이 파티션 전체를 차지하는 디바이스를 만든다. 그리고 tempdb에게 우선 10% 만을 할당해서 상황을 지켜보는 것이다. 만약 응용 프로그램에서 임시 테이블을 생성하는 것이 확인되면 일반적인 용도로 필요한 비율과 어떤 한 시점에 생성되는 임시 테이블의 추정 크기를 합하여 tempdb의 전체 크기를 결정하면 된다.

로드/스트레스 테스트(load/stress test)를 하면서 매 초마다 tempdb에서 실제로 얼마나 많은 공간이 사용되는지를 확인한 다음 이 결과를 이용하여 운영 환경의 tempdb 크기를 결정한다.

다른 디바이스와 I/O를 분리하기 위하여 tempdb가 별도의 콘트롤러 및 디스크를 사용하도록 한다.

인스톨 시에 마스터 디바이스에 생성되는 2MB 크기의 tempdb는 deallocate 해서 tempdb 전용 디바이스에서만 I/O가 발생하도록 한다.