database.sarang.net
UserID
Passwd
Database
DBMS
MySQL
PostgreSQL
Firebird
Oracle
Informix
Sybase
ㆍMS-SQL
DB2
Cache
CUBRID
LDAP
ALTIBASE
Tibero
DB 문서들
스터디
Community
공지사항
자유게시판
구인|구직
DSN 갤러리
도움주신분들
Admin
운영게시판
최근게시물
MS-SQL Tutorials 453 게시물 읽기
 News | Q&A | Columns | Tutorials | Devel | Files | Links
No. 453
SQL Server FAQ (4)
작성자
정재익(advance)
작성일
2002-07-17 00:16:30
조회수
41,233

인터넷 프로그램 개발

 

IDC 쿼리에서 레코드 개수를 반환하는 방법은? : IDC 쿼리에서 레코드 개수를 반환하는 방법은?

 

SQL Server 데이터베이스를 조회하기 위해서 IDC를 사용하고 있는데 ‘select count..’ 쿼리를 실행하였으나 .htx 파일에서 아무것도 출력할 수 없었다.

SELECT ‘count’=COUNT(*) FROM Mydatabase.dbo.Mytable

WHERE value like ‘%something%’

컬럼에 헤더 이름을 지정해 주어야 한다.

 

SQL Server의 정보를 웹 서버를 통해서 보여주려면 어떻게 해야 하는가? : SQL Server의 정보를 웹 서버를 통해서 보여주려면 어떻게 해야 하는가?

 

마이크로소프트의 IIS를 웹 서버로 사용한다면 인터넷 데이터베이스 커넥터(IDC)를 사용할 수 있다. IDC는 폼, IDC 파일, HTX 파일을 통해서 데이터베이스의 정보를 이용하여 결과를 생성한다. IDC 파일에는 데이터베이스에 대해서 실행되는 쿼리가 들어 있다. HTX는 결과의 포맷을 구성하고 있는 파일이며 폼 파일은 사용자로부터 파라미터를 받는 역할을 한다.

 

자세한 정보는 http://www.pobox.com/~swynk에서 찾을 수 있다. - IDC에 대해서 상세하게 설명하고 있는 MCP 매거진의 기사를 선택하면 된다.

 

또한 http://rampages.onramp.net/~steveg/iis4.html에 있는 ISAPI IDC 와 ODBC의 FAQ도 참조해 보도록 한다.

 

IDC에서 스토어드 프로시저로 파라미터를 넘길 수가 없는데… : IDC에서 스토어드 프로시저로 파라미터를 넘길 수가 없는데…

 

방명록 프로그램을 만들기 위해서 소규모의 SQL Server 데이터베이스를 하나 만들었다. 그리고 HTML 폼을 이용하여 데이터베이스에 저장된 정보를 사용하기 위해서 HTML과IDC 파일을 작성하였다. IDC 파일에는 다음 쿼리가 들어 있다.

 

SELECT * FROM users +WHERE firstname like "%FirstName%" + and lastname like "%LastName%" + and nick like "%Nick%" + and age like %Age% + and male_female = %Sex% + and ownpres_text like "%ownpres%" + and email like "%EMail%" + and school like "%School%" + and area_city like "%City_area%" + and state like "%State%" + and country like "%Country%"

 

위에서 Age, Sex, OwnPres 컬럼을 제외한 나머지 컬럼의 SQL Server 6.5 타입은 "CHAR" 이다. 이들 세 개는 각각 smallint, bin, text 이다.

 

데이터베이스의 정보를 사용하려고 하면 다음과 같은 에러가 발생한다.

 

Error Performing Query [State=22005][Error=257][Microsoft][ODBC SQL Server Driver] [SQL Server]Implicit conversion from datatype "int" to "varchar" is not allowed. Use the CONVERT function to run this query.

 

문제는 IDC 파일에 있다. SQL 쿼리로 전달되는 폼 변수는 문자열이기 때문에 Age, Sex와 비교할 때 에러가 발생하게 된다. 다음과 같이 처리하면 된다.

 

SELECT * from users WHERE firstname like "%FirstName%" and lastname like "%LastName%" and nick like "%Nick%" and convert(varchar,age) like "%Age%" and convert(varchar,male_female) = "%Sex%" and ownpres_text like "%ownpres%" and email like "%EMail%" and school like "%School%" and area_city like "%City_area%" and state like "%State%" and country like "%Country%"

 

사용자가 Sex 필드에 1 과 0을 입력하도록 해야 함을 주의하기 바란다.

 

IIS에서 SQL Server를 사용하기 위해서 익명의 사용자(anonymous user)를 만드는 방법은? : IIS에서 SQL Server를 사용하기 위해서 익명의 사용자(anonymous user)를 만드는 방법은?

 

IIS로 구성된 웹 폼에서 SQL Server 데이터베이스로 레코드를 삽입할 때 다음과 같은 에러가 발생한다.

"Microsoft OLE DB Provider for ODBC Drivers error ‘80004005’

[Microsoft][ODBC SQL Server Driver][SQL Server] Login failed"

이 분야에는 초보자로 웹에서 Access 데이터베이스를 다루는 것은 아무런 문제가 없으나 컴퓨터에 Administrator로 로그인 했음에도 SQL Server가 받아들이도록 하지 못하는 것 같다. guest가 서버를 사용할 수 있도록 설정도 해 보았으나 소용 없었다. 웹 서버에서 접속할 때 사용자 ID와 패스워드를 문자열로 서버에 보내야 하는가? 만약 그렇게 해야 한다면 적절한 구문의 예제를 찾을 수가 없다. 좋은 방법이 없는가? 어떠한 도움이든 감사히 받겠다.

 

일반적으로 데이터베이스를 사용하려면 제어판의 32bit ODBC Manager에서 DSN을 만들어야 한다. 그리고 이 DSN(접속 소프트웨어에 따라서 시스템 DSN 또는 사용자 DSN)을 이용하면 되는데 SQL Server가 사용을 허가하도록 사용자 명과 패스워드를 도메인에 제공해야 한다.

 

또 다른 방법은 SQL Server의 보안 모드를 Integrated Security를 구현하도록 변경하는 것이다. 이렇게 하면 NT 도메인에 의해서 인증된 사용자는 SQL Server를 사용할 수 있게 된다. SQL Server에서 Grant/Revoke를 사용해서 NT 도메인 사용자들의 접근을 추가적으로 제어할 수 있다.

 

트랜젝션 로그

 

fast bcp나 select into를 사용할 때 트랜잭션 로그가 차는 이유는? 이들이 로그를 발생시키지는 않는 것으로 알고 있다. : fast bcp나 select into를 사용할 때 트랜잭션 로그가 차는 이유는? 이들이 로그를 발생시키지는 않는 것으로 알고 있다.

 

Fast BCP와 select into는 레코드를 로깅하지 않는다. 그러나 익스텐트의 할당에 대해서는 로깅을 한다. 프로세스가 비정상적으로 종료되었을 때(정전 등의 원인) SQL Server가 해당 공간을 복구할 수 있도록 하기 위해서 이런 작업을 하게 된다.

 

따라서 큰 규모의 bcp나 select into를 실행할 때에는 많은 익스텐트가 발생하므로 트랜잭션 로그가 계속 차게 되는 것이다. 이런 경우에는 트랜잭션 로그의 크기를 더 크게 만들어야 한다.

 

SQL Server 로그를 볼 수 있는 방법은? : SQL Server 로그를 볼 수 있는 방법은?

 

SLQ Server 로그(syslogs)의 대부분의 정보는 표준 SQL 명령으로는 접근할 수가 없다. 이 정보를 보는 방법은 다음과 같다.

 

트랜잭션 ID와 명령 타입(operation type)은 select * from syslogs 쿼리를 통해서만 확인할 수 있다. 또는 편하게 읽으려면 다음의 코드를 사용한다.

SELECT

xactid AS TRAN_ID,

CASE op

WHEN 0 THEN "BEGINXACT Start Transaction"

WHEN 1 THEN "Not Used"

WHEN 2 THEN "Not Used"

WHEN 3 THEN "Not Used"

WHEN 4 THEN "INSERT Insert Row"

WHEN 5 THEN "DELETE Delete Row"

WHEN 6 THEN "INSIND Deferred Update step 2 insert record"

WHEN 7 THEN "IINSERT NC Index Insert"

WHEN 8 THEN "IDELETE NC Index Delete"

WHEN 9 THEN "MODIFY Modify Row"

WHEN 10 THEN "NOOP"

WHEN 11 THEN "INOOP Deferred Update step 1 insert record"

WHEN 12 THEN "DNOOP Deferred Update step 1 delete record"

WHEN 13 THEN "ALLOC Allocation"

WHEN 14 THEN "DBNEXTID Extent allocation"

WHEN 15 THEN "EXTENT Extent allocation"

WHEN 16 THEN "SPLIT Page split"

WHEN 17 THEN "CHECKPOINT"

WHEN 18 THEN "SAVEXACT Savepoint"

WHEN 19 THEN "CMD"

WHEN 20 THEN "DEXTENT Deallocate extent"

WHEN 21 THEN "DEALLOC Deallocate page"

WHEN 22 THEN "DROPEXTS Delete all extents on alloc pg"

WHEN 23 THEN "AEXTENT Alloc extent - mark all pgs used"

WHEN 24 THEN "SALLOC Alloc new page for split"

WHEN 25 THEN "Not Used"

WHEN 26 THEN "Not Used"

WHEN 27 THEN "SORT Sort allocations"

WHEN 28 THEN "SODEALLOC Related to sort allocations"

WHEN 29 THEN "ALTDB Alter database record"

WHEN 30 THEN "ENDXACT End Transaction"

WHEN 31 THEN "SORTTS Related to sort allocations"

WHEN 32 THEN "TEXT Log record of direct TEXT insert"

WHEN 33 THEN "INOOPTEXT Log record for deferred TEXT insert"

WHEN 34 THEN "DNOOPTEXT Log record for deferred TEXT delete"

WHEN 35 THEN "INSINDTEXT Indirrect insert log record"

WHEN 36 THEN "TEXTDELETE Delete text log record"

WHEN 37 THEN "SORTEDSPLIT Used for sorted splits"

WHEN 38 THEN "CHGINDSTAT Incremental sysindexes stat changes"

WHEN 39 THEN "CHGINDPG Direct change to sysindexes"

WHEN 40 THEN "TXTPTR Info log row WHEN retrieving TEXTPTR"

WHEN 41 THEN "TEXTINFO Info log for WRITETEXT/UPDATETEXT"

WHEN 42 THEN "RESETIDENT Used WHEN a truncate table resets an identity value"

WHEN 43 THEN "UNDO Compensating log record for Insert Only Row Locking (IORL)"

WHEN 44 THEN "INSERT_IORL Insert with Row Locking record"

WHEN 45 THEN "INSIND_IORL INSIND with IORL"

WHEN 46 THEN "IINSERT_IORL IINDEX with IORL"

WHEN 47 THEN "SPLIT_IORL Page split with IORL"

WHEN 48 THEN "SALLOC_IORL Alloc new page for split with IORL"

WHEN 49 THEN "ALLOC_IORL Allocation with IORL"

WHEN 50 THEN "PREALLOCLOG Pre-allocate log space for CLRs"

ELSE "Unknown Type" END AS LOG_RECORD

FROM syslogs

dbcc log 명령. 제대로 문서화되어 있지는 않지만 아래의 설명을 참조하도록 한다. 대부분의 문서화되어 있지 않은 dbcc 명령과 마찬가지로 결과를 보기 위해서는 먼저 dbcc traceon(3604)를 실행해야 한다.

 

 

www.dbsg.com의 Logview

 

 

www.platinum.com의 Log Analyzer

(모든 것은 현재는 6.5 이하 버전을 위한 것임)

 

dbcc log [ (@dbid, @objid, @pagenum, @rownum, @records, @type [, @printopt]) ]

dbcc log (5, 0, 0, 0, -1, 0, 1) // 로그에서 마지막 Begin Transaction 레코드를 보여줌

파라미터:

@dbid 데이터베이스 ID

@objid 객체 ID

(-)는 @pagenum과 @rownum이 로그 검색의 시작점으로 사용될 로그의 로우를 표시함을 의미한다.

0은 @pagenum 페이지의 변경된 로그 레코드가 결과에 포함됨을 의미한다.

(+)이고 @pagenum이 0이 아니면 @pagenum과 @rownum이 트랜잭션 ID를 표시함을 의미한다. 이 트랜잭션의 로그 레코드가 결과에 포함된다.

(+)이고 @pagenum과 @rownum이 모두 0이면 객체 ID를 의미한다. 이 객체의 변경사항에 관한 로그 레코드가 결과에 포함된다.

@pagenum 페이지 번호

@rownum 로그의 로우 번호

@pagenum과 함께 로그 검색시의 시작점 또는 트랜잭션 ID를 표시하는데 사용된다.

@records 검사할 레코드 개수. (+)라면 처음부터

@type

@printopt

 

리플리케이션

 

트러스티드 커넥션에서의 리플리케이션 실패

 

리플리케이션을 셋업 할 때 다음과 같은 에러가 발생한다.

 

37000[Microsoft][ODBC SQL Server Driver] [SQL Server]Login failed-User; Reason: Not associated with a trusted SQL Server connection.

 

SQL Server에 로그인 하는 방법은 두 가지가 있음을 기억해야 한다. 하나는 SQL Server 로그인 명과 패스워드를 이용한 "표준" 보안 모델을 사용하는 것이고 다른 하나는 트러스티드 커넥션(trusted connection)을 이용하는 것이다. 만약 사용자가 다른 도메인에 위치하고 있다면 도메인 서버를 점검하고 가능하다면 두 도메인 간의 트러스트 관계를 설정한다. 또는 SQL Server 보안 모델을 "혼합"(Windows NT와 SQL Server) 모드(mixed mode) 변경한다. 만약 로그인을 "트러스티드"로 설정하였으나 Publication 서버가 Subscribing 서버에 의해서 트러스트되지 않는다면 바로 이곳에 문제가 있는 것이다.

 

만약 서버가 동일한 도메인에 존재한다면, Distribution 서버(또는 별도의 Distributor가 없다면 Publisher)에서 실행되는 SQL Executive 서비스의 계정을 얻도록 한다. 리플리케이션을 위해서는 이 계정은 도메인 전체에 걸쳐서 사용할 수 있어야 한다. 그 다음 Subscription 서버에서 다음을 점검한다.

 

이 계정이 Administrators 그룹에 속해 있는지

 

 

속해있지 않다면 이 계정이 SQL Server 계정인 repl_publisher으로 매핑되어 있는지 SQL Security Manager로 확인

 

이렇게 점검해도 성과가 없다면 xp_grantlogin을 사용해 볼 수 있다. 예를 들면

 

xp_grantlogin , "repl"

 

자세한 내용은 관련 문서를 참조한다(Transaction SQL Reference, 확장 프로시저, xp_grantlogin)

 

아직 사용해 보지는 않았지만 다른 방법으로는 Distribution Task에 사용자 ID와 패스워드를 지정하는 것이다. 보다 상세한 설명은 ‘Replication Tasks Scheduling’을 참조하기 바란다.

 

#1 리플리케이션을 위한 테이블이 하나도 나타나지 않는 문제

 

리플리케이션과 관련된 문제가 있다. test와 dialogue라는 두 개의 데이터 디바이스가 있는데 sherman 데이터베이스는 양쪽에서 모두 나타나지만 dialogue에서는 아무 테이블도 없이 비어 있다.

 

dialogue와 test에 있는 데이터베이스를 마스터로 사용하려고 여러 가지로 노력해 보았으나 허사였다. 마지막으로 Publish/Subscribe를 시도해 보았으나 매번 다음과 같은 에러가 발생하였다.

Installation of SQL server replication system requires the SQL executive to be run under a windows NT user account other than local system.

Admin으로도 시도해 보았으나 실패하였다. Publish/Subscribe 하는 방법을 알고 싶지만 그에 앞서 원래의 문제를 해결하는 일이 시급하다.

 

이 문제를 해결하려면 아래와 같이 하면 된다.

 

1) 제어판에서 서비스를 선택한다.

 

2) 서비스 목록에서 "SQLExecutive" 서비스를 선택한다.

 

3) "Startup" 버튼을 눌러서 "Log On As"를 체크한다. "This Account:"(그리고 계정 이름)가 선택되어야 한다.

 

#2 리플리케이션을 위한 테이블이 하나도 나타나지 않는 문제

 

리플리케이션으로 문제를 겪는 경우 고려해야 할 또 다른 부분은 Publish 하고자 하는 테이블의 유니크 키이다. 만약 유니크 키가 정의되어 있지 않으면 이 테이블은 Publish 가능한 테이블 목록에 나오지 않게 된다. Publish 하고자 하는 테이블에는 반드시 키가 생성되어 있어야 한다.

 

SQL Mail

 

SQL Server에서 MS Mail이나 Exchange Server를 사용하지 않고 SQL Mail을 셋업 하려면 어떻게 해야 하는가?

 

다음 순서에 따라 작업해 보도록 한다(아래의 내용은 필자가 작성한 것이 아니기 때문에 직접 테스트 해보지는 않았지만 별 문제는 없을 것이다)

 

SQL Server 서비스를 셋업 한다. SQL Server 서비스는 Administrator 권한을 가지고 있는 사용자 계정을 이용해서 기동 되어야 한다. 이 계정은 또한 사용자가 서비스로 로그온 하는 것을 허용해야 한다. 이렇게 해야지만 SQL Server가 이메일을 주고 받을 수 있다. SQL Server 6.5는 "SQLExecutiveCmdExec"라는 계정을 디폴트로 생성한다. 이 계정이 제대로 만들어져 있는지 확인해야 한다.

 

윈도우에서 "Start" 버튼을 클릭한다.

 

"Programs"을 선택한다.

 

"Administrative Tools(Common)를 선택한다.

 

"User Manager for Domains"를 선택한다. 만약 "User Manager"라고 되어 있으면 9번으로 건너 뛴다.

 

"User Manager 프로그램이 뜨면 메뉴에서 "Users"를 선택한다.

 

"Select Domain"을 선택한다.

 

예를 들어 "DBASQLTEST"와 같이 컴퓨터 이름을 입력한다.

 

"OK" 버튼을 클릭한다.

 

이제 컴퓨터의 사용자 목록이 나왔을 것이다.

 

"SQLExecutiveCmdExec" 계정이 존재하면 이 사용자를 더블클릭 한다. 그러면 다이얼로그 박스가 하나 나타난다. 이제 18번으로 간다.

 

"SQLExecutiveCmdExec" 계정이 존재하지 않으면 메뉴에서 "Users"를 선택한다.

 

"New User"을 선택한다.

 

그러면 다이얼로그 박스가 하나 나타난다.

 

User Name 필드에는 "SQLExecutiveCmdExec"라고 입력한다.

 

Full Name 필드에도 "SQLExecutiveCmdExec"라고 입력한다.

 

Password 필드에는 패스워드를 입력한다(나중에 필요하므로 안전한 곳에 패스워드를 기록해 둔다).

 

Confirm Password 필드에 방금 입력한 패스워드를 다시 한번 입력한다.

 

"User Must change Password at Next Logon"의 체크 표시를 지운다.

 

"User Cannot Change Password"를 체크 한다.

 

"Password Never Expires"를 체크 한다.

 

"Groups" 버튼을 클릭한다.

 

그러면 Group Membership 다이얼로그 박스가 나타난다.

 

"Administrators" 그룹을 추가한다.

 

"OK" 버튼을 클릭하여 Group Membership 다이얼로그 박스를 닫는다.

 

"OK" 버튼을 클릭하여 "User Properties" 다이얼로그 박스를 닫는다.

 

메뉴에서 "Policies"를 선택한다.

 

"User Rights"를 선택한다.

 

그러면 User Rights Policy 다이얼로그 박스가 나타난다.

 

"Show Advanced User Rights"를 체크 한다.

 

드롭 다운 리스트에서 "Log on as a Service" 옵션을 선택한다.

 

"Add" 버튼을 클릭한다.

 

그러면 "Add Users and Groups" 다이얼로그 박스가 나타날 것이다.

 

드롭 다운 리스트에서 현재의 컴퓨터 이름을 선택한다(예를 들면 \SERVERNAME*).

 

"Show Users" 버튼을 클릭한다.

 

사용자 리스트를 스크롤 해 내려가서 "SQLExecutiveCmdExec"을 선택한다.

 

"Add" 버튼을 클릭한다.

 

이제 "Add Names:" 리스트에 "SQLExecutiveCmdExec" 사용자가 들어 있게 된다.

 

"OK" 버튼을 클릭하여 "Add Users and Groups" 다이얼로그 박스를 닫는다.

 

 

"OK" 버튼을 클릭하여 "User Rights Policy" 다이얼로그 박스를 닫는다.

 

Windows NT Messaging 인스톨

 

주의: Windows NT Messaging이 SQL Server가 설치되어 있는 컴퓨터에 인스톨되어 있는지를 확인해야 한다. SQL Mail에서 Windows Messaging을 사용하기 때문에 SQL Mail이 제대로 동작하기 위해서는 Windows Messaging이 정확하게 셋업 되어 있어야 한다. 다음과 같이 검사해 보면 된다.

 

Control Panel에서 Add/Remove Programs을 더블 클릭 한다.

 

Windows NT Setup 탭을 선택한 다음 리스트 박스의 가장 아래까지 스크롤 해서 내려간다.

 

Windows Messaging이 체크되어 있는지 확인한다.

 

만약 체크되어 있지 않다면 지금 체크 한다.

 

"OK"를 클릭한다.

 

 

Windows Messaging을 인스톨 하려면 Windows NT CD가 필요하다.

 

Mail Services 설정

 

주의: 작업을 계속하기에 앞서 두개의 인터넷 메일 계정이 필요하다.

 

POP 메일 계정의 로그인과 패스워드, 그리고 서버 이름이 필요하다.

 

SMTP 메일 계정의 로그인과 패스워드, 그리고 서버 이름이 필요하다.

 

이제 SQL Server가 설치되어 있는 컴퓨터의 모든 프로그램을 종료한 다음 새로운 사용자(SQLExecutiveCmdExec)로 로그인 한다.

 

데스크탑의 "Inbox" 아이콘에서 오른 쪽 마우스 버튼을 클릭한 다음 "Properties"를 선택한다. 이제 SQLExecutiveCmdExec 사용자를 위한 새로운 프로파일(profile)을 추가해야 한

다. Windows Messaging Profile을 생성하기 위해서 "Add" 버튼을 클릭한다.

 

"Microsoft Mail"의 체크표시를 지운다(Exchange Server가 사용 가능하지 않은 한)

 

"Internet Mail"가 체크되어 있는지 확인한다.

 

"Next" 버튼을 클릭한다.

 

메일 서버로 접속하기 위한 방법을 물어보면 "Network" 라디오 버튼을 체크한다.

 

"Next" 버튼을 클릭한다.

 

메일 서버의 이름이나 IP 어드레스를 물어보면 둘 중의 하나를 입력한다.

 

"Next" 버튼을 클릭한다.

 

메시지를 전송하는 모드를 선택해야 한다. "Automatic" 라디오 버튼을 체크 한다.

 

"Next" 버튼을 클릭한다.

 

이메일 주소를 물어볼 것이다. Email Address 필드에 이메일 주소를 입력한다.

 

Full Name 필드에 "SQLExecutiveCmdExec"라고 입력한다.

 

"Next" 버튼을 클릭한다.

 

메일박스 이름을 물어볼 것이다. Mailbox name 필드에 메일박스 이름을 입력한다. 예를 들면 USERID(메일 서버의 로그인 명)를 입력한다.

 

Password 필드에 메일박스 이름의 패스워드를 입력한다(메일서버 로그인 명의 패스워드)

 

"Next" 버튼을 클릭한다.

 

Personal address book의 위치를 물어볼 것이다. 디폴트 값을 그대로 사용한다.

 

"Next" 버튼을 클릭한다.

 

Personal folder file의 위치를 물어볼 것이다. 디폴트 값을 그대로 사용한다.

 

"Next" 버튼을 클릭한다.

 

셋업이 모두 끝났다는 메시지가 나올 것이다.

 

"Finish" 버튼을 클릭한다.

 

프로파일 리스트 박스에서 이제 "Windows Messaging Settings:" 라는 항목을 볼 수 있을 것이다.

 

"Copy" 버튼을 클릭한다.

 

새로운 프로파일의 이름을 지정하라고 나오면 "SQLExecutiveCmdExec"를 입력한다.

 

복사를 하기 위해서 "OK" 를 클릭한다.

 

프로파일 리스트 박스에서 이제 "SQLExecutiveCmdExec" 항목을 볼 수 있을 것이다.

 

"When Starting windows Messaging, use this profile:" 드롭 다운 리스트에서 새롭게 생성된 "SQLExecutiveCmdExec" 프로파일을 선택한다.

 

"Close" 버튼을 눌러서 셋업 과정을 완료한다.

 

SQL Server 서비스와 SQLExecutive가 새로운 메일 계정을 사용하도록 설정 한다.

 

SQL Server 서비스를 정지시켜야 한다.

 

Control Panel을 연다.

 

Services를 더블 클릭한다.

 

Microsoft SQL Server를 찾을 때 까지 스크롤 해서 내려가서 선택한 다음 stop 버튼을 클릭한다.

 

이제 서비스의 상태가 stopped로 바뀌었을 것이다.

 

Microsoft SQL Server 서비스를 더블클릭 하여 Properties 다이얼로그 박스를 띄운다.

 

다이얼로그 박스의 아래쪽을 보면 SQL Server가 startup시에 사용하는 계정이 나와 있다. 이것을 SQLExecutiveCmdExec으로 변경한다. 패스워드를 정확하게 입력하지 않으면 SQL Server가 기동 되지 않는다.

 

"OK" 버튼을 클릭하여 다이얼로그 박스를 닫는다.

 

start 버튼을 클릭하여 이 서비스를 기동한다.

 

서비스가 성공적으로 기동 되지 않으면 (6)에서 입력한 패스워드가 User Manager for Domains에서 입력한 패스워드와 일치하는 지를 확인한다.

 

SQLExecutive가 나올 때 까지 스크롤 해서 내려 가서 선택한 다음 stop 버튼을 클릭한다.

 

이제 서비스의 상태가 stopped로 바뀌었을 것이다.

 

SQLExecutive 서비스를 더블클릭 하여 Properties 다이얼로그 박스를 띄운다.

 

다이얼로그 박스의 아래쪽을 보면 SQL Server가 startup 시에 사용하는 계정이 나와 있다. 이 것을 SQLExecutiveCmdExec 계정을 사용하도록 변경한다. 패스워드를 정확하게 입력하지 않으면 SQL Server가 기동 되지 않는다.

 

"OK" 버튼을 클릭하여 다이얼로그 박스를 닫는다.

 

start 버튼을 클릭하여 서비스를 기동한다.

 

 

서비스가 성공적으로 기동 되지 않으면 (13)에서 입력한 패스워드가 User Manager for Domains에서 입력한 패스워드와 일치하는 지를 확인한다.

 

SQL Server 셋업 옵션의 설정

 

"Start" 버튼을 클릭한다.

 

"Programs"을 선택한다.

 

"Microsoft SQL Server 6.5"를 선택한다.

 

"SQL Setup"을 선택한다.

 

"Welcome" 다이얼로그 박스가 나타나면 "Continue" 버튼을 클릭한다.

 

"SQL Server Already Installed" 다이얼로그 박스가 나타나면 "Continue" 버튼을 클릭한다.

 

"Set Server Options" 라디오 버튼을 체크 한다.

 

"Continue" 버튼을 클릭한다.

 

"Autostart SQL Mail" 을 체크 한다.

 

"Mail Profile" 버튼을 클릭한다. 이것은 다이얼로그 박스 중간의 가장 마지막 버튼이다.

 

다이얼로그 박스가 나타나면 "SQLExecutiveCmdExec"를 입력한다.

 

"OK" 버튼을 클릭한다.

 

"Change Options" 버튼을 클릭한다.

 

"Exchange Login Configuration" 다이얼로그 박스가 나타나면 "Continue" 버튼을 클릭한다.

 

옵션이 성공적으로 설정되었다는 다이얼로그 박스가 나타나면 "Exit to Windows NT" 버튼을 클릭한다.

 

이제 SQL Server를 재기동 해야 한다.

 

"Start" 버튼을 클릭한다.

 

"Programs"을 선택한다.

 

"Microsoft SQL Server 6.5"를 선택한다.

 

"SQL Server Manager"를 선택한다.

 

그러면 신호등이 그려져 있는 다이얼로그 박스가 나타날 것이다.

 

서비스를 정지시키기 위해서 빨간색 등을 더블 클릭한다. 다이얼로그 박스의 아래 쪽에 "The service is stopped"라는 메시지가 나오는 것을 확인한다.

 

초록색 등을 더블 클릭하여 서비스를 기동한다. 다이얼로그 박스의 아래 쪽에 "The service is running"이라는 메시지가 나오는 것을 확인한다.

 

 

다이얼로그 박스를 닫는다.

 

인터넷 메일 설정(MAPI 셋업)

 

서버에는 적어도 인터넷 익스플로러가 설치되어 있어야 한다.

 

데스크탑에서 "Internet Explorer"를 더블 클릭한다.

 

메뉴에서 "Go"를 선택한다.

 

"Read Mail"을 선택한다.

 

"Browse for Folder" 다이얼로그 박스가 나타날 것이다.

 

원하는 폴더를 선택하거나 아니면 디폴트 그대로 사용한다.

 

"OK" 버튼을 클릭한다.

 

새로운 "Wizard"가 나타날 것이다.

 

"Next" 버튼을 클릭한다.

 

Name 필드에 "SQLExecutiveCmdExec"라고 입력한다.

 

Email Address 필드에 이메일 주소를 입력한다(예를 들면 user@domain.com)

 

"Next" 버튼을 클릭한다.

 

"Incoming mail(POP3) server" 필드에 POP3 서버의 이름을 입력한다.

 

"Outgoing mail(SMTP) server" 필드에 SMTP 서버의 이름을 입력한다.

 

"Next" 버튼을 클릭한다.

 

"Account Name" 필드에 이메일 계정의 이름을 입력한다(예를 들면 USERID)

 

"Password" 필드에 이메일 계정의 패스워드를 입력한다.

 

"Next" 버튼을 클릭한다.

 

접속하는 타입을 물어보면 "I use a LAN connection:"을 선택한다.

 

"Next" 버튼을 클릭한다.

 

"Finish" 버튼을 클릭한다.

 

MAPI 메일 클라이언트가 나타나면 종료 시켜도 된다.

 

SQL 엔터프라이즈 메니저를 기동한다. 트리에서 사용 중인 서버를 확장하여 SQL Mail 아이콘이 초록색으로 변했는지를 확인함으로써 SQL Mail이 작동 중인지를 검사한다. 만약 SQL Mail 아이콘이 빨간색이라면 뭔가 잘못된 것이다. 초록색은 SQL Mail이 정상적으로 작동함을 의미한다. 아이콘의 색깔이 다른 색으로 바뀌기 위해서는 약간 시간이 걸리므로 일단 잠시 기다려 본다. 만약 모든 것이 정상적으로 작동하는 것 같으면 SQL Tool을 열어서 다음과 같이 입력한다.

 

xp_sendmail "user@domain.com",@message="This is a test message." 여기서 user@domain.com은 실제로 메일을 받을 수 있는 이메일 주소이다.

 

CTRL-E 또는 쿼리 툴의 초록색 GO 버튼을 눌러서 실행한다. 결과 화면에 메일이 보내졌다는 메시지가 나올 것이다.

 

셋업 과정이 제대로 진행되었다면 SQL Server는 이제 메일을 처리할 수 있게 된 것이다. 주고 받는 메일을 처리하기 위한 여러 가지 스토어드 프로시저가 준비되어 있다. 자세한 정보는 SQL 레퍼런스 매뉴얼을 참조하기 바란다.

 

SQL Mail을 인스톨 하려면 어떻게 해야 하는가? SQL Server에 SQL Mail을 인스톨 하려고 하는데 잘 되지 않는다.

 

먼저 관련 매뉴얼을 읽어보도록 한다. SQL Server는 매우 유용하고 검색 기능도 갖춘 Books Online을 제공하고 있다.

 

그 다음에는 http://www.microsoft.com/supprot 에서 다음의 SQL Mail Knowledgebase 자료를 참조하기 바란다.

 

Q118501 MS-Mail post-offices 관련 자료

Q153159 Exchange post-offices 관련 자료

 

다른 문제가 있을 경우 "SQLMAIL" 이라는 검색어로 찾아보면 보다 구체적인 자료를 찾을 수 있을 것이다.

 

Windows NT 4.0에서 SQL Server 6.0 Mail을 기동할 수가 없다. 내장된 NT Mail 서비스를 위해서 정확한 프로파일을 설정하였으나 SQL Mail이 기동 되지 않는다.

 

이 옵션을 가능하게 하는 한가지 방법은 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가 발생하도록 한다.

[Top]
No.
제목
작성자
작성일
조회
507T-SQL의 해결사 - CASE 함수
정재익
2002-08-29
27233
506동적 쿼리의 해결사 sp_executesql vs. exec
정재익
2002-08-29
18449
504DB 파일을 D드라이브로 옮기는 방법
정재익
2002-08-29
11953
453SQL Server FAQ (4)
정재익
2002-07-17
41233
452SQL Server FAQ (3)
정재익
2002-07-16
19259
448SQL Server FAQ (2)
정재익
2002-07-14
26772
447SQL Server FAQ (1)
정재익
2002-07-14
29578
Valid XHTML 1.0!
All about the DATABASE... Copyleft 1999-2019 DSN, All rights reserved.
작업시간: 1.080초, 이곳 서비스는
	PostgreSQL v11.5로 자료를 관리합니다