원본출처 : http://korea.internet.com/channel/content.asp?cid=113&nid=1087

개요, 목적, 면책 조항 : 이 FAQ는 무엇인가?

날짜 : 2000년 11월 08일

1.0 이 FAQ는 무엇인가?

2.0 누구에게 책임이 있는가?

3.0 SQL Server 관련 링크와 리뷰

FAQ란 Frequently Asked Questions, 즉 자주 물어보는 질문을 뜻한다. FAQ는 문제 해결을 위한 시발점이나 참조하기 위한 목적으로 작성된 것으로 같은 질문이 여러 번 반복되는 것을 줄여 주는 효과가 있다. 본 FAQ는 comp.databases.ms-sqlserver 뉴스그룹, SWINK.COM이 후원하는 SQL Server 메일링 리스트, 그리고 마이크로소프트가 운영하는 다음의 뉴스 그룹과 관련 되어 있다.

microsoft.public.sqlserver.connect

microsoft.public.sqlserver.misc

microsoft.public.sqlserver.odbc

microsoft.public.sqlserver.programming

microsoft.public.sqlserver.replication

microsoft.public.sqlserver.server

본 FAQ는 이들 그룹에 가장 자주 올라오는 질문에 대한 도움을 제공하려는 취지에서 만들어 졌으며 아울러 본 FAQ의 독자들이 문의한 내용과 제안 등도 포함시킬 계획이다.

SQL Server FAQ에 관한 추가 정보는 사이베이스의 웹 사이트, http://reality.sgi.com/pablo/Sybase_FAQ 또는 마이크로소프트의 웹 사이트, http://www.microsoft.com/sqlsupport/content/faq 등에서 찾을 수 있다.

SQL Server 관리

1.0 인스톨 실패

2.0 서버와 관리도구의 버전을 섞어서 사용해도 되는가?

3.0 테이블의 구조를 출력하는 방법은?

4.0 데이터베이스 디바이스를 옮기려면 어떻게 해야 하는가?

5.0 도움 요청! 데이터베이스가 suspect로 표시되어 있는데?

6.0 손상된 테이블을 삭제하려면 어떻게 해야 하는가?

7.0 SQL Server를 관리하는 데 있어서 참조할 만한 좋은 책은 어떤

SQL Server 관리 : 인스톨 실패

인스톨 과정이 끝나 갈 무렵에 실패하고 말았다. 데이터베이스에 접속할 수 없다면서 NT 상으로 빠져 나와 버렸다.

서버에 네트워크 어댑터와 프로토콜을 설치하였는지 확인한다. 물리적으로 네트워크에 접속해 있지 않더라도 네트워크를 인스톨 할 필요가 있다. 만약 이 경우에 해당한다면 제어판의 네트워크에서 MS 루프백(loopback) 어댑터를 인스톨 한다. 그러면 대부분 문제가 해결된다.

SQL Server를 업그레이드 하는 마지막 과정은 네트워크를 리셋 시키는 것인데 만약 커넥션이 접속되어 있거나 네트워크 어댑터가 없으면 이 단계에서 에러가 발생하는 것이다.

필자를 포함하여 많은 사람들이 문제의 심각성은 다소 차이가 있겠지만 이 에러를 경험하였는데 예방책 두 가지를 소개하면 다음과 같다.

컴퓨터가 네트워크에 연결되어 있지 않다면 MS 루프백 어댑터를 설치한다.

인스톨을 시작하기 전에 제어판에서 Workstation 서비스를 정지시킨다. 이렇게 하면 셋업 프로그램에서 인스톨 시에 로컬 파이프를 사용하게 된다.

기억할 점: 아마도 에러 메시지를 두 번 만나게 되는데 첫 번째는 재시도(Retry) 버튼과 함께 나온다. 첫 번째 에러는 SQL Server가 완전하게 기동 되지 못했기 때문에 발생하므로 재시도(Retry) 버튼을 누르기 전에 2분간 기다리도록 한다. 그러지 않으면 접속 시에 문제를 겪게 된다.

서버와 관리도구의 버전을 섞어서 사용해도 되는가? : 서버와 관리도구의 버전을 섞어서 사용해도 되는가?

6.x 버전의 엔터프라이즈 매니저를 7.0 데이터베이스에 사용해도 되는가?

시스템 테이블과 기본 객체 모델이 버전 간에 차이가 있기 때문에 6.x 버전의 엔터프라이즈 매니저를 7.0 데이터베이스를 관리하는 데 사용할 수 없다.

4.2 버전의 SQL Administrator와 Object Manager를 6.0 데이터베이스에 사용할 수 있는가?

ADMIN60.SQL과OBJECT60.SQL 스크립트를 사용하면 16-bit 4.21 버전의 툴을 SQL Server 6.0에서 안정적으로 사용할 수 있다. 이들 스크립트는 \\SQL60\INSTALL 디렉토리에 있다.

6.0 버전의 SQL 엔터프라이즈 매니저를 4.x 데이터베이스에 사용할 수 있는가?

4.2 데이터베이스에 대해서 SQL 엔터프라이즈 매니저를 사용할 수 있도록 해 주는 스크립트가 있다.

테이블의 구조를 출력하는 방법은? : 테이블의 구조를 출력하는 방법은?

가장 간단한 방법은 ISQL에서 sp_help와 sp_columns를 사용하는 것이다. 그 다음에 필요에 따라서 출력하거나 Cut&Paste 하면 된다.

데이터 모델링 툴을 가지고 있는 경우에는 데이터베이스에 대한 리버스 엔지니어링(reverse engineering)을 통해서 이미지를 수정한 다음 출력할 수도 있다. 이와 같은 프로그램으로는 PowerDesigner, ER/Studio, ERWin, Visio, System Architect 등이 있다.

데이터베이스 디바이스를 옮기려면 어떻게 해야 하는가?

공식적인 방법은 아니지만 다음과 같이 하면 가능하다. 이 방법이 마이크로소프트에서 지원되는 방법은 아님을 명심해야 하지만 하나의 새로운 수단을 알려줄 뿔 아니라 내부적으로 작업이 어떻게 돌아가는 지를 이해할 수 있게 해 준다.

디바이스를 옮기기 위해서는 SQL Server의 내부 테이블인 SYSDEVICES를 수정하여 DAT 파일의 새로운 위치를 지정하도록 해야 하며 아울러 데이터베이스 파일도 새로운 곳으로 이동시켜야 한다. 작업이 끝나면 SQL Server를 재기동 시켜서 변경사항을 인식할 수 있도록 한다.(실제로는 DAT 파일을 옮기기 전에 SLQ Server를 정지시켜야 하며 그러지 않고 사용중인 파일을 복사하면 에러가 발생하게 된다)

예를 들어서 testdb라는 디바이스가 C:\SQL\TESTDB.DAT 파일에 저장되어 있는 경우 이를 옮기기 위해서는 다음과 같이 하면 된다.

sysdevices 테이블을 수정하여 새로운 위치를 지정하도록 한다(예: D:\SQL\TESTDB.DAT)

SQL Server를 정지시킨다.

실제로 파일을 새로운 위치로 이동시킨다.

SQL Server를 기동한다.

마스터 데이터베이스를 옮길 때에는 이 방법을 사용할 수 없음을 주의해야 한다.

SP_MoveDevice 스토어드 프로시저를 사용하면 이 과정의 첫 번째 단계인 sysdevices 테이블의 수정 작업을 처리할 수도 있다.

공식적으로 지원되는 방법은 먼저 데이터베이스를 백업 받은 다음 데이터베이스와 디바이스를 모두 삭제하고 새로운 위치에 디바이스를 새로 만들어서 데이터베이스를 다시 생성한 후에 백업을 리스토어 하는 것이다.

7.0 버전에서는 sp_detach_db와 sp_attach_db 스토어드 프로시저를 사용하여 데이터베이스의 위치를 옮기는 작업을 간단하게 끝낼 수 있다.

도움 요청! 데이터베이스가 suspect로 표시되어 있는데?

다음과 같은 메시지가 나오는 데이터베이스가 있다 – “Database ‘DBname’ cannot be opened – it has been marked SUSPECT by recovery. The SA can drop the database with DBCC.”

하지만 데이터베이스를 삭제하고 싶지는 않다!!! 그냥 데이터베이스를 오픈 해서 복구 과정은 거치지 않고 있는 그대로 사용하고 싶다. 이 데이터베이스는 읽기 전용의 데이터베이스이므로 데이터는 다시 쉽게 넣을 수 있다. 그러나 데이터베이스를 삭제하면 모든 테이블과 인덱스, 스토어드 프로시저등이 없어지므로 그러게 하고 싶지는 않다.

강제적으로 데이터베이스를 오픈 시킬 수 있는 방법은 없는가?

SQL Server 에러로그(Errorlog)와 NT의 이벤트 로그에 아무런 에러도 나와 있지 않다면 플래그를 리셋시키기 위해서 sp_reset_status 스토어드 프로시저를 실행시킨다. 그리고 SQL Server를 재기동 한다. 데이터베이스가 정상적으로 오픈 되면 DBCC를 이용하여 즉시 데이터베이스를 백업한다. 그러나 데이터베이스의 데이터가 손상을 입은 상태일 가능성이 높다.

no_checkpoint 옵션과 함께 dbcc를 실행한다. 여러분이 백업을 가지고 있기를 바란다. 경험에 따르면 데이터베이스로부터 완전 무결한 dbcc를 얻어내지 않는 한 결과는 무의미하다.

sysdatabases의 상태 비트(status bit)를 해킹 할 수도 있는데 그 값을 무조건 12로 변경해 버리면 된다. 데이터베이스가 과도하게 손상되지 않는 한 이 방법이 효과가 있음을 발견하였다.

** 마스터 데이터베이스를 먼저 백업할 것 **

sysdatabases의 서스펙트(suspect) 비트를 리셋 시켜서 데이터베이스를 “Emergency” 모드로 변경시킨 다음(Admin Companion의 “Creating suplemental stored procedures”, ch.24 참조) SQL Server를 재기동 한다. 다른 컴퓨터에 새로운 SQL Server를 만들고 손상된 데이터베이스에서 데이터를 빼내기 위해서 SQL Transfer Manager를 사용한다(또는 6.5 버전의 엔터프라이즈 매니저에서 Tools, Data/Object Transfer 사용). 일단 데이터가 정상적인 데이터베이스 상에 생성되었으면(반드시 백업할 것) 기존의 서버를 삭제하고 새로 만든다. 만약 양 서버의 CPU 타입과 문자열 셋, 정렬 순서 등이 모두 동일하다면 한 쪽에서 다른 쪽으로 덤프 시킬 수도 있다.

상태(status)를 리셋 시킬 수가 없다면 데이터베이스를 살릴 수 있는 희망은 없다. 가장 최근의 백업에서 리스토어 시켜야 한다.

손상된 테이블을 삭제하려면 어떻게 해야 하는가?

손상된 테이블: dbcc checktable을 실행해 보니 SQL 에러 7930, 2511이 발생하였다.

SQL Server 4.2의 손상된 테이블을 수리하기 위해서 문서화되어 있지 않은 기능을 사용할 수 있다. 4.2버전을 사용하고 있다면 다음과 같이 하면 된다.

1. sysbojects 테이블에서 손상된 테이블의 object id를 확인한 다음 기록해 둔다.

2. sp_rename을 사용해서 table의 이름을 변경하여 데이터를 보관한다.

3. 새로운 테이블을 만들고 기존의 테이블에서 데이터를 로드시킨 다음 필요하다면 인덱스도 생성한다.

4. 데이터베이스를 단일 사용자 모드(single user mode)로 전환시키고 시스템 테이블을 수정하기 위한 옵션을 설정한다.

5. 시스템 테이블(sysobjects, sysindexs 등)에서 단계1)에서 구한 기존 테이블의 object id를 참조하는 모든 경우를 삭제한다.

6. 손상된 테이블이 차지하고 있던 할당되지 않은 공간을 되찾기 위해서 마스터 데이터베이스에서 dbcc fix_al() 명령을 실행한다.

7. 추가적인 에러나 손상된 테이블이 없는지 단계6)의 결과를 확인한다.

8. 시스템 테이블을 수정할 수 없도록 옵션을 설정하고 데이터베이스를 다시 다중 사용자 모드로 전환한다.

9. dbcc checkdb 명령으로 모든 과정을 마무리한다.

이 방법을 몇 차례 사용해 본 결과 모두 성공적이었지만 작업을 하기 전에 반드시 기술 지원을 요청하는 것이 좋다. 모든 작업 이전에 데이터베이스를 덤프하여 백업하도록 하며 위험이 따르는 작업이기 때문에 전문가의 도움을 받도록 한다.

마이크로소프트에서 공식적으로 지원되는 손상된 테이블을 복구하는 방법은 테이블을 삭제하고 다시 만들거나 백업 받은 것에서 리스토어 하는 것이다.

SQL Server를 관리하는 데 있어서 참조할 만한 좋은 책은 어떤 것들이 있는가?

SQL Server에 관한 좋은 책들이 많이 있으며 이 중 세 권은 본 FAQ의 관리자들이 직접 집필한 것이다.

7.0 용:

Special Edition Using SQL Server 7.0, Que Publishing

SQL Server System Administration, New Riders

Microsoft SQL Server 7.0 Unleashed

Microsoft SQL Server 7.0 DBA Survival Guide

Hitchhikers"s Guide to Visual Basic and SQL Server; William R. Vaughn; Microsoft Press; Paperback; $49.99

SQL Server 7 Developer"s Guide

SQL Server 7 Administrator"s Guide

Inside SQL Server 7.0

6.5 용:

Special Edition Using SQL Server 6.5 Second Edition, Que Publishing

Microsoft SQL Server 6 Unleashed

Microsoft SQL Server 6.5 DBA Survival Guide

The Microsoft SQL Server Survival Guide

Microsoft SQL Server Training : Hands-On, Self-Paced Training for Microsoft SQL Server Version 6.5

SQL Server 6.5 Secrets

Microsoft SQL Server : Planning and Building a High Performance Database

Microsoft SQL Server : What Database Administrators Need to Know

Hitchhikers"s Guide to Visual Basic and SQL Server

Teach Yourself Transact-SQL in 21 Days

Inside SQL Server 6.5

백업과 리스토어

SQL Server 데이터베이스가 “recovering” 상태라고 나와 있다. 어떻게 해야 하는가? : SQL Server 데이터베이스가 “recovering” 상태라고 나와 있다. 어떻게 해야 하는가?

SQL Server는 기동할 때 마다 모든 트랜잭션을 커밋 또는 롤백 시키기 위해서 복구(recovery) 작업을 수행한다. 이 복구 과정은 보통 수 초에서 수 분정도 소요되지만 한창 수정 작업이 진행되는 도중에 서버가 중단되었다면 복구 작업은 최소한 수정 작업이 진행된 시간 또는 로그 디바이스에 대한 경쟁 때문에 그 이상 걸릴 수 있다.

SQL Server가 복구할 수 있는 충분한 시간을 주도록 하고 현재와 과거의 에러 로그 파일 및 NT의 에러 로그를 점검하여 어떤 문제가 발생하지는 않았는지 확인해야 한다. 만약 하드웨어 문제나 SQL Server의 버그가 발생하였다면 에러가 기록되어 있을 것이다.

복구 작업이 CPU와 다스크를 사용하는지 알아보기 위해서 디스크의 작동상황을 알려주는 램프와 sysprocesses 활동 상황을 점검한다. 매우 드문 경우이긴 하지만 SQL Server가 데이터베이스를 정확하게 복구하지 못할 수도 있다.

복구 과정을 확인하는 그 밖의 방법으로는 각 트랜잭션이 롤포워드(roll forward) 또는 롤백(rollback) 되었을 때 에러 로그에 기록하도록 트레이스 플래그(trace flag) 3412를 설정할 수도 있다.

만약 데이터베이스가 복구되지 않고 백업한 것도 없다면 다음의 트레이스 플래그를 사용하여 복구 과정을 건너 뛸 수 있다. 단, 이렇게 하면 데이터베이스/데이터의 일관성이 깨질 수 있지만 다른 대안이 없는 경우에는 이 방법을 사용하되 반드시 필요한 객체를 BCP나 다른 툴을 사용하여 즉시 백업 받아야 한다.

3607 : 모든 데이터베이스의 자동 복구 생략

3608 : 마스터 데이터베이스를 제외한 모든 데이터베이스의 자동 복구 생략

그래도 데이터베이스를 사용할 수 없다면 – suspect라고 표시됨 – 다음의 명령을 실행하여 데이터베이스를 비상 모드(emergency mode)로 설정한다(먼저 수정작업을 허용해야 한다). 그 다음에 데이터베이스에 접속하여(SQL Server를 재기동할 필요 없음) 필요한 데이터를 백업 받으면 된다.

UPDATE master..sysdatabases SET status=-32768 WHERE name=’’

모든 방법이 실패하고 어떻게 해야 할 바를 모르겠다면 마이크로소프트 제품 지원 서비스(PSS)에 바로 전화하면 된다. 그들은 이와 같은 문제에 대비해서 1년 365일 24시간 내내 서비스를 제공하고 있으며 데이터 손실에 비하면 소요되는 비용은 무시 할 만 하다.

SQL Server 데이터베이스를 네트워크로 다른 곳에 백업/리스토어 받을 수 없는 이유는?

MSSQLSERVER 서비스가 별도의 NT Credential 하에서 수행되기 때문이다. 어떠한 사용자로 로그 온 했는지는 상관 없다(SQL Server는 콘솔에 아무도 로그 온 하지 않아도 잘 수행됨). 따라서 로그 온 계정과 매핑된 드라이브는 전혀 영향을 주지 못한다. 백업을 수행하는 것은 사용자가 아니라 SQL Server이기 때문이다.

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

Localsystem 계정은 네트워크를 사용하도록 인증되어 있지 않지 때문에 네트워크 상의 공유 드라이브를 사용할 수 없다. 따라서 네트워크를 통해서 백업을 하려면 다음의 두 가지 방법 가운데 하나를 선택해야 한다.

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

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

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer

\Parameters\NullSessionShares

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

예) DUMP DATABASE pubs to DISK="\\server01\share\backupdir\backup.dmp"

다른 서버의 테이프 드라이브로 백업할 수 있는가?

SQL Server에서 제공하는 툴에서는 지원되지 않는다. SQL Server는 로컬 시스템의 테이프 디바이스에만 백업할 수 있다. 만약 원격지의 테이프 드라이브를 마치 로컬 시스템의 디바이스처럼 보이게 하는 NT 드라이버가 있다면 SQL Server에서는 단지 표준 I/O 만을 사용하면 되므로 가능하겠지만 현재로서는 그와 같은 드라이버를 보지 못했다.

로컬 디스크에(또는 몇 가지 단서는 붙지만 네트워크를 통해서) SQL Server 데이터베이스를 덤프한 다음 테이프로 백업하면 된다.

마지막으로, SQL 에이전트를 가지고 있는 다른 회사의 백업 소프트웨어를 사용하면 가능하다. 제품 예를 들자면 BEI Ultraback, Cheyenne Arcserver, Seagate BackupExec, Legato Networker 그리고 IBM ADSM 등이 있다.

이들은 SQL 덤프를 (표준 네임드 파이프 인터페이스를 경유해서) 표준 덤프 테이프로 보낸다. 네임드 파이프가 네트워크를 통해서 연결되어 있다면 로컬시스템에 작업하는 것보다는 속도가 훨씬 떨어진다.

데이터베이스를 덤프하는 것에 비해서 리스토어 하는 시간이 훨씬 오래 걸리는 이유는?

로드 작업 중에는 SQL Server가 모든 페이지를 초기화하기 때문이다. 따라서 만약 5GB 크기의 데이터베이스에서 50MB의 데이터를 처리한다면 덤프의 경우에는 단지 50MB에 대한 작업만 하면 된다. 그러나 로드 작업은 50MB의 로드 작업(대체로 덤프와 비슷한 시간 소요)을 수행한 다음 나머지 4.95GB의 빈 공간을 초기화 시킨다. 이 초기화 작업은 페이지 단위로 실행되며 디스크의 허용 한도 내에서는 가장 빠른 속도로 진행된다.

DAT 디바이스만 남은 상태에서 어떻게 SQL Server 데이터베이스를 복구할 수 있는가?

SQL Server 6.5 이하의 버전에서는 DISK REINIT와 REFIT 명령을 사용한다. Books Online에 설명이 자세히 나와 있다.

SQL Server 백업 중에 테이프 압축을 하지 않는 방법은?

트레이스 플래그 3205를 사용하면 테이프 드라이브 압축을 하지 않게 된다.

클라이언트 프로그래밍

MS Access에서 SQL Server의 스토어드 프로시저를 실행하려면?

Access의 쿼리 디자이너에서 패스 쓰루(Pass-Through) 쿼리를 만들고 쿼리의 텍스트에 스토어드 프로시저의 이름을 넣는다. 필요하다면 쿼리의 커넥션(connection) 속성을 편집하여 쿼리에서 필요로 하는 데이터 소스 등을 입력한다(도움이 되는 빌더(builder)가 있음). 쿼리를 실행하면 스토어드 프로시저로부터 반환되는 결과는 쿼리의 결과 셋(result set)으로 나타나게 된다.

C/C++에서 SQL Server를 사용하는 방법

C++에서 SQL Server를 사용하는 방법은 ODBC와 DB-Library 두 가지가 있다.

DB-Lib는 좀 더 오래 전부터 사용해온 방법으로 보다 네이티브(native)한 접근 방식에 해당된다. DB-Lib가 SQL Server만을 지원하는 반면 ODBC는 여러 데이터베이스가 상호 동작이 가능하도록 마이크로소프트가 개발한 표준이다. 마이크로소프트의 데이터베이스 뿐 아니라 다른 수많은 데이터베이스와 호환되며 ISO 표준이 되었다. 마이크로소프트에서는 네이티브 방식으로 구현한(DB-Lib에 씌워지는 계층이 아님) SQL Server의 OOBC 드라이버를 제공하며 그 성능이 뛰어나기 때문에 SQL Server의 TPC-C 벤치마크 시에도 사용한다.

MFC 데이터베이스 클래스는 ODBC에 기반을 두고 있으며 Derived Database와 레코드 셋 클래스에서 자유롭게 ODBC를 사용할 수 있다. 이런 이유로 해서 MFC 프로그램에서는 ODBC를 주로 선택하게 된다.

Access 데이터베이스를 SQL Server로 옮기려면?

추가 정보가 필요하면 Knowledge Base Q152032를 참조하기 바란다.

Access에서 SQL Server로 옮기는 작업은 현재 사용 중인 Access의 버전과 조금 관계가 있다. Access 95에서는 마이크로소프트 웹사이트의 Access 페이지(http://www.microsoft.com/access)에서 업사이징 마법사(Upsizing Wizard)를 다운로드 받아서 사용하면 된다. Access 2.0에서도 환경에 맞는 업사이징 마법사를 사용해서 작업한다.

경험담:

응용 프로그램을 비주얼 베이직이나 스토어드 프로시저를 이용하여 다시 작성한 것보다는 속도가 떨어질 것이다(실제로는 직접 Access나 파일 서버를 사용하는 것보다도 느릴 것이다). 그러나 SQL Server를 사용하면 보다 많은 사용자를 지원할 수 있으며 데이터 무결성이 강화되고 관리가 간편해지는 장점이 있다.

SQL 프로그래밍에 이제 입문하였다면 한 번에 한 단계씩 옮겨보도록 한다. 일단 데이터베이스가 원활하게 동작하게 되면 프론트 엔드(front end) 쪽에서도 패스 쓰루(pass through) TSQL 문의 사용 양을 더 늘리거나 비주얼 베이직으로 새로 작성해 나간다.

SQL Server를 사용함으로써 얻게 되는 진짜 보상은 트랜잭션 쿼리를 서버의 스토어드 프로시저로 옮겼을 때 얻게 된다.

백 엔드(back end)에서 유의할 점:

Access의 케스케이드(cascade) 관계는 SQL Server에서 대응되는 것이 없기 때문에 마스터 레코드를 지운다고 해서 그에 의존하는 디테일 레코드까지 삭제되지는 않는다.

ODBC 드라이버를 2.65 버전 대신 2.50 버전을 사용하도록 한다. 2.65버전에서는 널 레코드를 삭제할 때 문제를 겪게 된다.

Access의 날짜와 SQL Server의 날짜는 서로 시작부터가 다르다. 시간을 저장하기 위해서 날짜 필드를 사용한다면 데이터를 옮길 때 약간 놀라게 될 것이다.

SQL Server의 테이블은 수정이 가능하려면 유니크 인덱스를 가지고 있어야 한다. Access의 테이블이 철저하게 관계형 규칙을 따르지 않는다면 SQL Server로 옮겨질 수 없다.

인덱스가 걸려 있지 않은 필드를 검색하는 것은 매우 속도가 느리기 때문에 사용자들이 함부로 검색하지 못하도록 할 필요가 있다.

Access의 테이블 명에서 허용되는 공백문자는 SQL Server의 테이블에서는 사용할 수 없다.

일반적으로 SQL Server로의 이전을 염두에 두지 않고 작성된 Access 프로그램은 옮기기가 훨씬 힘들거나 코드를 뜯어고치지 않는 한 불가능한 경우가 많다.

필자가 최근에 행한 업사이징(upsizing) 프로젝트는 작업에 익숙함에도 불구하고 3개월의 기간이 소요되었다.

추가 정보:

Access 97을 사용한다면 업사이징 마법사를 마이크로소프트에서 개발 중이라고는 하지만 이 글을 쓰는 시점에는 나와있지 않다. 현재(1997/01/26) ETA는 구할 수가 없다. 관련 서적은 다음과 같다.

The Revolutionary Guide to Microsoft Access

Special Edition Using SQL Server 6.5, Second Edition (두번째 판임을 꼭 확인할 것)

참고: 공정함을 기하기 위해서 밝힌다면 필자(Steve Wynkoop)가 이 책을 저술하였으며 시중에는 다른 책들도 많이 있을 것이다. 보다 자세한 정보는 다음 주소에서 찾을 수 있다. http://www.pobox.com/~swynk

Access 97에서 수작업으로 업사이징 하거나 마법사가 출시되기를 기다리는 방법 외의 대안이라면 일단 테이블을 Access 95 포맷으로 변환한 다음에 업사이징 툴을 사용하는 것이다. 세련되었다고는 할 수 없지만 충분히 활용 가능한 방법이다.

업사이징 툴을 만드는 업체들이 몇 군데가 있다. 그들의 사이트를 방문하여 제품을 확인해 보기 바란다.

Weir Performance Technologies(http://www.weirperf.com)는 업사이징 툴과 Access 최적화 툴을 생산한다. 그들은 또한 플랫폼 간의 변환 시에 사용되는 흥미로운 툴들을 가지고 있다. 이 툴들은 변환하는 대상 플랫폼 들의 함수 구문의 차이점을 알고 있다.

Aditi Technologies는 Access에서 SQL Server로 이전할 때 도움이 되는 업사이징 툴을 제공한다. 추가 정보가 필요하면 그들의 웹사이트(http://www.aditi.com)를 방문해 보기 바란다.

ODBC를 통한 스토어드 프로시저 사용

스토어드 프로시저에서 커서 페치(fetch) 구문을 사용하면 결과가 미완성된 상태에서 ODBC 클라이언트로 넘어가는 문제가 있는데 어떻게 이를 방지해야 하는가?

SQL Server에서 SET NOCOUNT ON을 사용하면 스토어드 프로시저의 각 명령에 대해서 DONE_IN_PROC 메시지를 클라이언트에게 보내는 일을 하지 않는다. NOCOUNT가 ON 상태에서도 @@ROWCOUNT 전역변수는 계속 갱신된다.

ODBC와 ISQL에서 NULL에 대한 등식 비교의 결과가 다른 이유는

ODBC와 ISQL에서 NULL에 대한 등식 비교의 결과가 왜 다르게 나타나는가?

ANSI_NULLS 전역 변수는 비교 연산자-같다(=) 와 다르다(<>)-의 ANSI 표준 행태를 지정한다. ANSI 표준에 따르면 NULL이 들어 있는 모든 문장은 결국 NULL로 평가된다. 디폴트 값은 OFF인데 ODBC는 이 값을 기본적으로 ON으로 설정하기 때문에 SET ANSI_NULLS OFF 명령을 사용해서 변경시켜야 한다.

자동으로 증가하는 필드를 만드는 방법은?

SQL Server 6.5에서 자동으로 증가하는 필드를 만들려면?

IDENTITY데이터 타입을 사용하면 된다. 여기에 종자 값(seed)과 증가 분(increment)을 지정할 수 있다. 또한 유니크 키를 만들기 위한 좋은 컬럼이기도 하다(대체로 유니크 키로 가장 자주 이용됨). 컬럼을 만들 때 필드의 크기(int, smallint, 등)를 선택함으로써 identity의 범위를 지정할 수 있다.