----------------------------------
SQL명: inet
SQL아이디 : inetid
SQL암 호 : inetpw
----------------------------------
mysqldump -inetid -p inet > inet.sql

명령어를 실행하시면 패스워드를 묻고 이때 "SQL 암호"를 입력하시면 됩니다.
고객님의 FTP계정에 DB백업파일이 생성되어 있는것을 확인하실 수 있습니다.

mysql을 하다가 실수로 root 패스워드를 분실하셨을 경우 아래의 방법으로 해결하시면 됩니다.

# killall mysqld (데몬을 모조리 죽입니다)

# safe_mysqld --skip-grant &

# mysql (mysql 실행)

mysql>UPDATE user SET password=PASSWORD('newpasswd') where user='root';

mysql> FLUSH PRIVILEGES

위와 같이 하시면 다시 패스워드를 바꾸실수 있습니다.

물론가능합니다..

MS - SQL은 "서버.DB.소유자.OBJECT" 형식의 객체지정 문법을 사용하는데, table은 객체범주에 들어간다.
테이블이름이 같더라도 소유자가 다르다면 그 테이블은 만들어진다.
예를 들어서 PUBS.DBO.SALES와 PUBS.USER1.SALES는 다른 객체로 인식되어지는 것이다. 그리고, 소유자가
DBO인 경우에는 로그인에 관계없이
USE PUBS
SELECT * FROM SALES 하면 질의가 성공적으로 수행되지만,
소유자 USER1인 경우에는,
SELECT * FROM USER1.SALES라고 해야지만 가능하다.(단, 현재 로그인이 USER1일 경우에는 제외)

결론적으로, 소유자가 다르면 같은 이름의 테이블은 존재할 수 있다.

RESTORE FILELISTONLY
FROM < backup_device >

위 T - SQL 사용하면 백업파일 안에 들어 있는 내용들이 보입니다.

RESTORE VERIFYONLY
FROM < backup_device >

위 T - SQL은 백업을 확인하지만 백업을 복원하지는 않고, 백업파일에 문제가 있는지 검사합니다.

출처 : http://www.devpia.com
1.Lock의 간단한 이해..

어느 웹팀이 웹페이지 개발을 하고 있는데 하나의 컴퓨터에서 터미날서비스를 이용하여 작업을 하고 있다.

하지만 A 라는 사람이 Default라는 화일을 사용하고 있고 B라는 사람이 이것을 열려고 한다면 어떻게 될것인가??

두사용자가 모두 쓰기를 해버린다면 작업은 엉망이 될것이다. 그것을 방지하기 위해서 VS.NET툴에 소스세이프라는 것을 이용하여

한사람이 작업을 할때는 다른이가 접근을 막아주는 기능을 한다.

이것이 바로 Lock의 개념인것이다.

쉽게 다른사람이 이 파일을 쓸때 다른 사람이 쓰지 못하도록 막는것.

멀티 스레드같은 프로그램에서도 많이 사용하는 개념이기도 하고

DataBase의 데이터 처리 역시 같은 개념인 것이다

2. NoLock과 DeadLock의 이해..

NoLock에 관해서 먼저 이해를 해보도록 하겠다.

Lock을 안걸면 되는거지 NoLock은 또 무엇인가??

이렇게 이해가 와 닿을수 있다. 하지만 ADO에서 지원하는 자동 트랙잭션 처리와 같은 경우가 있기에 NoLock이 필요한 것이다

그럼 왜 Lock을 걸지 않느냐..?? 한가지 예를 들어 설명 하도록 하겠다.

어느 경매사이트에 마감 1분을 남겨두고 있다. 헌데 벤츠가 50원이다.. 사람들이 미친듯이 입찰을 하려고 달려들 것이다.

그 숫자가 만명이라고 가정해보자 입찰을 할때 Update를 시킬텐데..수만명의 사용자가 그것의 처리를 기달려야 한다면..

그 차는 헐갑에 넘어 가고 말것이다.

정말 쉬운 예로 게시판에 글을 읽었을 때 조회수가 update가 된다. 헌데 이글을 수만명의 사람들이 동시에 접근을 한다고 한다.

그럼 한사람 한사람의 업데이트를 기달리게 될 것이고 사이트의 효율성이 떨어질것이다.

등등의 많은 예들이 NoLock의 필요성을 말해준다.


다음은 DeadLock의 관한 이해를 보도록 하겠다.

DeadLock은 쉽게 표현하자면 재귀함수와 같은 무한루프라고 표현에 가깝다. 이것 역시 간단한 예제를 통해 예를 들어 보겠다.

Transaction1 (A ->B)처리

Transaction2 (B ->A)처리

저기서 A와 B에 락이 걸려있다고 가정해보자.. 어떠한가? 서로 잡고 마냥 기달리기만 하지 않겠는가?

1번은 A를 잡고 있는 상태로 2번에서 잡고 있는 상태로 B를 놔주기를 기다릴것이고 2번은 B를 잡고 있는채로 A를 놔주기를

바라고 있을것이다. 이것이 잘 운영되던 사이트가 속도가 느려지고 이유도 모르게 서비스가 중지 되는 가장큰 이유가 된다.

반드시 처리해야할.. 이것이 바로 DeadLock 이라는 것이다.

3.DeadLock의 해결..

데드락을 해결하기 위해서는 3가지의 방법이 존재한다. 첫번째는 타임아웃을 주어 어느 일정시간 동안 락을 기달리다가 반응이 없으면

롤백시키는 즉 타임아웃을 설정하는 것이다.

EX)

-락타임 아웃의 설정

SET LOCK_TIMEOUT 10000

- 락 타임아웃 확인

SELECT @@LOCK_TIMEOUT

- 트랜잭션 코드 추가

데드락을 해결할수 있는 첫번째 방법이였다.

두번째는 프로시저에 우위를 설정해 주는것이다. 이방법은 우위가 낮은 프로시저를 먼저

취소시킨다는 것이다. 우선 순위의 레벨은 Low와 Normal로 나타낼수 있고 Priority라는것을 이용하여 설정 할수가 있다.

EX)

SET DEADLOCK_PRIORITY LOW

go

... 트랜잭션 구문



그리고 세번재 방법은 한 프로시저가 너무 오랫동안 사용하고 있다 의심되는것을 강제로 종료 시키는 방법이다.

이것은 KILL이라는 SQL명령어를 이용하여 사용 할 수 있다.

4.DeadLock 예방하기

데드락 발생시 처리해야 하는것도 중요하지만 데드락을 미리 예방을 하여 락과 블러킹의 횟수를 줄이는것 역시 중요하다.

그럼 데드락을 예방법 첫번재로 트랜잭션안의 구문의 처리 순서를 일치 시킨다는 것이다.

예를들어 보겠다.

트랜잭션1=> A작업->B작업->C작업

트랜잭션2=> C작업->A작업->B작업

이런식으로 처리 되어진다면 둘이 동시에 처리가 된다면 분명 데드락이 발생 할 것이다. 여기서 우리가 트랙잭션2의 작업의

순서를 1과 똑같이 A작업->B작업->C작업 으로 처리를 한다면 데드락의 발생 비율을 줄일수 있을 것이다.

그리고 두번째는 트랙잭션의 처리속도를 최대한 짧게 해준다는 것이다. 짧으면 짧을수록 락 발생 확률도 줄여 들기 때문이다.

이것은 너무 당연한 것일수 있고 가장 중요한것이 된다. 그리고 마지막으로 트랜잭션의 격리 수준을 최대한 낮게 해 주는것이다.

되도록 낮은 격리 수준을 사용하면 데드락은 물론 성능도 보다 향상시 킬수 있기 때문이다.

데드락의 예방은 무엇보다도 가장 기복적으로 락의 유지 시간을 보다 짧게 해주는것이 가장 중요할 것이다.

*TIP(출서: 모사이트였는데-_-)

HOLDLOCK : 필요한 테이블, 행 또는 데이터 페이지가 더 이상 필요 없게 되자마자 해제하지 않고 트랜잭션이 완료될 때까지 공유 잠금을 보유한다. HOLDLOCK은 SERIALIZABLE과 같은 의미.

NOLOCK : 공유 잠금을 실행하거나 단독 잠금을 유지하지 않음. 이 옵션을 적용하면 커밋되지 않은 트랜잭션이나 읽는 중 롤백된 페이지 집합을 읽을 수 있음. 커밋되지 않은 읽기가 가능합니다. SELECT 명령문에만 적용됨..

PAGLOCK 주로 단일 테이블 잠금이 취해지는 곳에서 페이지 잠금을 사용함.

READCOMMITTED : READ COMMITTED 격리 수준에서 실행되는 트랜잭션과 같은 잠금 방법을 사용하여 스캔을 수행함. 기본적으로, SQL Server 2000은 이 격리 수준에서 실행됨

READPAST : 잠겨 있는 행을 건너뜀 이 옵션을 사용하면 다른 트랜잭션이 이러한 행에 대해 잠금을 해제할 때까지 기다리지 않고 다른 트랜잭션에 의해 잠겨 있는 행을 건너뜀. 그렇지 않으면 일반적으로 결과 집합에 나타남. READPAST 잠금 참고는 READ COMMITTED 격리 수준에서 작동하는 트랜잭션에만 적용되며 행 수준 잠금 뒤만 읽음. SELECT 문에만 적용됨

READUNCOMMITTED == NOLOCK

REPEATABLEREAD : REPEATABLE READ 격리 수준에서 실행되는 트랜잭션과 같은 잠금 방법으로 스캔을 수행함.

ROWLOCK : 성긴 페이지 잠금 및 테이블 수준의 잠금 대신 행 수준 잠금을 사용함

RERIALIZABLE : SERIALIZABLE 격리 수준에서 실행되는 트랜잭션과 같은 잠금 방법으로 스캔을 수행함. HOLDLOCK과 같음

TABLOCK : 세부적인 행 또는 페이지 수준 잠금 대신 테이블 잠금을 사용함. SQL Server는 명령문이 끝날 때까지 이 잠금을 보유함. 그러나 HOLDLOCK을 함께 지정했으면 트랜잭션이 끝날 때까지 잠금이 보유됨.

TABLOCKX : 테이블에 대해 단독 잠금을 사용함. 이 잠금을 사용하면 다른 트랜잭션이 테이블을 읽거나 업데이트할 수 없고 명령문이나 트랜잭션이 끝날 때까지 보유됨

UPDLOCK : 테이블을 읽는 중 공유 잠금 대신 업데이트 잠금을 사용하며 명령문이나 트랜잭션이 끝날 때까지 보유됩니다. UPDLOCK을 사용하면 다른 트랜잭션이 읽는 것을 차단하지 않고 데이터를 읽을 수 있고 마지막으로 읽은 후 데이터가 변경되지 않으며 나중에 업데이트할 수 있습니다.

XLOCK : 명령문에 의해 처리되는 모든 데이터에 대해 트랜잭션이 끝날 때까지 보유될 단독 잠금을 사용합니다. 이 잠금은 PAGLOCK 또는 TABLOCK으로 지정할 수 있으며 이 경우 단독 잠금이 해당 세부성 수준에 적용됩니다.

데이터 원본 이름(DSN)은 데이터에 액세스하는 데 필요한 드라이브와 기타 정보를 참조하기 위해 ODBC(Open Database Connectivity)가 사용하는 논리 이름이다.
Internet Information Services에서 Microsoft SQL Server 데이터베이스와 같은 ODBC 데이터 원본에 연결하기 위해 사용한다.
이 이름을 설정하려면 제어판에서 ODBC 도구를 사용한다.

ODBC DSN 항목을 사용하여 연결 문자열 값을 외부적으로 저장하면 연결 문자열에 필요한 정보가 간단해진다.
이렇게 하면 데이터 원본이 코드 자체에 완전히 투명하게 변경된다.

* Windows 2000에서 시스템 DSN을 만드는 방법

1. 시작을 누르고 프로그램, 관리 도구를 차례로 가리킨 다음 데이터 원본(ODBC)을 두 번 누른다.

참고: Windows 2000 Professional에서는 시작을 누르고 설정을 가리키고 제어판을 누르고 관리 도구를 두 번 누른 다음 데이터 원본(ODBC)을 두 번 누른다.

2. 시스템 DSN 탭을 누른다.
3. 추가를 누른다.
4. 연결하려는 데이터베이스 유형에 해당하는 데이터베이스 드라이버를 누른 다음 마침을 누른다.
5. 데이터 원본 이름을 입력한다. 나중에 이 이름을 사용해야 하므로 기억하기 쉬운 이름을 입력한다.
6. 선택을 누른다.
7. 올바른 데이터베이스를 누른 다음 확인을 누른다.
8. 다음 두 대화 상자에서 확인을 누른다.

주의할 점

반드시 시스템 DSN을 만들어야 한다.
ADO(ActiveX Data Objects)는 사용자(또는 로컬) DSN을 인식하지 못한다.
레지스트리에 설정을 저장하기 때문에 시스템 DSN은 하드 디스크에 있는 파일에 연결 매개 변수를 저장하는 파일 DSN보다 성능이 약간 빠르다.

출처 : http://www.sqlworld.pe.kr

SQL Server의 데이터베이스를 다른 서버로 옮기기는 쉽습니다. 항상 문제가 되는 것은 다른 서버 로그인 정보를 옮기는 것입니다.(물론 몇개 안되면 다시 만들면 되지만) Master 데이터베이스를 백업받아 다른 서버에 리스토어 하면 되지만 그리 쉬운 방법은 아닙니다. DTS를 이용해서 로그인 정보를 다른 서버로 옮길 수 있으나 SQL Server 7.0에서는 패스워드를 정확히 옮기지 못하는 걸로 압니다. SQL Server 2000에서는 정확하게 로그인 정보를 옮길 수 있습니다.

이런 이유로 MS에서 SQL Server 7.0 간의 로그인 정보 이동을 위하여 제공하는 스크립트가 있습니다. 이 스크립트를 소개하고자 합니다.


1. 아래 스크립트를 수행하여 시스템 저장프로시져 sp_hexadecimal를 만듭니다.

USE master
GO

IF OBJECT_ID ('sp_hexadecimal') IS NOT NULL
DROP PROCEDURE sp_hexadecimal
GO

CREATE PROCEDURE sp_hexadecimal
@binvalue varbinary(256),
@hexvalue varchar(256) OUTPUT
AS
DECLARE @charvalue varchar(255)
DECLARE @i int
DECLARE @length int
DECLARE @hexstring char(16)
SELECT @charvalue = '0x'
SELECT @i = 1
SELECT @length = DATALENGTH (@binvalue)
SELECT @hexstring = '0123456789ABCDEF'

WHILE (@i <= @length)
BEGIN
DECLARE @tempint int
DECLARE @firstint int
DECLARE @secondint int
SELECT @tempint = CONVERT(int, SUBSTRING(@binvalue,@i,1))
SELECT @firstint = FLOOR(@tempint/16)
SELECT @secondint = @tempint - (@firstint*16)
SELECT @charvalue = @charvalue +
SUBSTRING(@hexstring, @firstint+1, 1) +
SUBSTRING(@hexstring, @secondint+1, 1)
SELECT @i = @i + 1
END

SELECT @hexvalue = @charvalue
GO
IF OBJECT_ID ('sp_help_revlogin') IS NOT NULL
DROP PROCEDURE sp_help_revlogin
GO

CREATE PROCEDURE sp_help_revlogin @login_name sysname = NULL AS
DECLARE @name sysname
DECLARE @xstatus int
DECLARE @binpwd varbinary (255)
DECLARE @txtpwd sysname
DECLARE @tmpstr varchar (255)

IF (@login_name IS NULL)
DECLARE login_curs CURSOR FOR
SELECT name, xstatus, password FROM master..sysxlogins
WHERE srvid IS NULL AND name <> 'sa'
ELSE
DECLARE login_curs CURSOR FOR
SELECT name, xstatus, password FROM master..sysxlogins
WHERE srvid IS NULL AND name = @login_name

OPEN login_curs
FETCH NEXT FROM login_curs INTO @name, @xstatus, @binpwd

IF (@@fetch_status = -1)
BEGIN
PRINT 'No login(s) found.'
CLOSE login_curs
DEALLOCATE login_curs
RETURN -1
END

SET @tmpstr = '/* sp_help_revlogin script '
PRINT @tmpstr
SET @tmpstr = '** Generated '
+ CONVERT (varchar, GETDATE()) + ' on ' + @@SERVERNAME + ' */'
PRINT @tmpstr
PRINT ''
PRINT 'DECLARE @pwd sysname'

WHILE (@@fetch_status <> -1)
BEGIN

IF (@@fetch_status <> -2)
BEGIN
PRINT ''
SET @tmpstr = '-- Login: ' + @name
PRINT @tmpstr

IF (@xstatus & 4) = 4
BEGIN -- NT authenticated account/group

IF (@xstatus & 1) = 1
BEGIN -- NT login is denied access
SET @tmpstr = 'EXEC master..sp_denylogin ''' + @name + ''''
PRINT @tmpstr
END

ELSE BEGIN -- NT login has access
SET @tmpstr = 'EXEC master..sp_grantlogin ''' + @name + ''''
PRINT @tmpstr
END

END

ELSE BEGIN -- SQL Server authentication
IF (@binpwd IS NOT NULL)
BEGIN -- Non-null password
EXEC sp_hexadecimal @binpwd, @txtpwd OUT
IF (@xstatus & 2048) = 2048
SET @tmpstr = 'SET @pwd = CONVERT (varchar, ' + @txtpwd + ')'
ELSE
SET @tmpstr = 'SET @pwd = CONVERT (varbinary, ' + @txtpwd + ')'
PRINT @tmpstr
SET @tmpstr = 'EXEC master..sp_addlogin ''' + @name
+ ''', @pwd, @encryptopt = '
END

ELSE BEGIN
-- Null password
SET @tmpstr = 'EXEC master..sp_addlogin ''' + @name
+ ''', NULL, @encryptopt = '
END

IF (@xstatus & 2048) = 2048
-- login upgraded from 6.5
SET @tmpstr = @tmpstr + '''skip_encryption_old'''
ELSE
SET @tmpstr = @tmpstr + '''skip_encryption'''
PRINT @tmpstr
END

END

FETCH NEXT FROM login_curs INTO @name, @xstatus, @binpwd
END

CLOSE login_curs
DEALLOCATE login_curs
RETURN 0
GO



2. EXEC master..sp_help_revlogin 를 수행하면 로그인 정보를 만드는 스크립트가 만들어집니다.

3. 이 스크립트를 복사하여 새로운 서버에서 수행합니다.

※ 이 내용는 http://support.microsoft.com/support/kb/articles/Q246/1/33.ASP의 내용을 참고한 것임을 알려드립니다.

-EM(Enterprise Manager)를 이용한 데이터베이스 분리

1.데이터베이스 위에서 마우스 오른쪽 번튼을 눌러 나타나는 단축메뉴에서 [모든작업(K)] - [데이터베이스 분리(H)] 를 선택합니다.

2.[데이터베이스 분리] 대화창이 표시됩니다. 이 화면에서 "분리 전에 통계 먼저 업데이트[S]"를 선택하시고 [확인] 버튼을 누르시면 데이터베이스가 분리됩니다.

-sp_detach_db 시스템 저장프로시져를 이용한 데이터베이스 분리

1.다음과 같이 sp_detach_db 시스템 저장프로시져를 이용하여 간단하게 데이터베이스를 분리 할 수 있습니다.

USE master
GO
EXEC sp_detach_db test




-EM(Enterprise Manager)를 이용한 데이터베이스 연결

1. 우선 연결할 대상이 되는 *.mdf, *.ldf 파일을 특정한 디렉토리에 위치를 시킵니다. 예로 test.mdf, test_log.ldf 파일을 E:\Data 폴더에 있다고 가정합니다.

2. "데이터베이스" 위에서 마우스 오른쪽 버튼을 눌러 단축메뉴를 표시하면 [모든작업(K)] - [ 데이터베이스 연결(A)]을 선택할 수 있습니다.

3. 데이터베이스 연결을 위한 대화창이 표시됩니다.

4. 찾기 버튼 [...] 을 누르면 연결할 데이터베이스 파일의 위치를 쉽게 찾을 수 있는 탐색창이 뜹니다. 이 화면에서 연결하고자 하는 데이터베이스 파일 *.mdf 을 선택하면 됩니다.

5. 데이터베이스 파일을 선택한 후의 화면입니다. 원하는 경우 "다음 이름으로 연결(A)" 부분에 다른 이름을 주어 기존의 데이터베이스와는 다른 이름을 갖는 데이터베이스로 연결을 할 수 있습니다.

6. [확인] 버튼을 누르면 데이터베이스 연결이 완료됩니다.


-sp_attach_db 또는 sp_attach_single_file_db 시스템 저장프로시져를 이용한 데이터베이스 연결

sp_attach_db의 경우는 데이터베이스 파일이 여러개인 경우(한개의 *.mdf 파일과 여러개의 *.ndf 파일들)에 사용을 하게 되며, sp_attach_single_file_db의데이터베이스 파일이 한개(한개의 *.mdf 파일)인 경우 사용하면 됩니다. 데이터베이스 파일이 한개인 경우는 두가지 방법중 아무거나 사용하시면 됩니다. 그리고 sp_attach_db의 경우는 16개의 데이터베이스 파일까지 한번에 지정이 가능합니다.

만일 위에서 연결했던 test.mdf 파일을 sp_attach_db를 이용해서 연결한다면 다음과 같이 하시면 됩니다.


USE master
GO
EXEC sp_attach_db 'test', 'E:\Data\test.mdf', 'E:\Data\test_log.ldf'


위 연결 방법은 정확히 한다면 다음과 같은 문법에 따라 사용하셔야 합니다. 하지만 변수명 생략이 가능하기 때문에 위와 같이 사용한 것입니다.


USE master
GO
EXEC sp_attach_db @dbname = 'test', @filename1 = 'E:\Data\test.mdf', @filename2 = 'E:\Data\test_log.ldf'


test.mdf 파일을 sp_attach_single_file_db를 이용해서 연결한다면 다음과 같이 하시면 됩니다.


USE master
GO
EXEC sp_attach_single_file_db 'sqlworld', 'E:\Data\sqlworld.mdf'

-- 또는

EXEC sp_attach_single_file_db @dbname = 'test',
@physname = 'E:\Data\test.mdf'

-- 또는

이전 서버와 문자셋 정보(sp_helpsort 명령으로 보실수 있습니다.)가 같고

이전에 사용하던 SQL서버가 정상적인 상태로 종료 되었을때(엔터프라이즈 관리자에서

SQL서버를 스탑 시켰거나.. 정상적으로 윈도우 시스템을 종료시킨 경우 - 해당

mdf 화일과 ldf 화일이 정상적으로 닫혔을 경우) 복구가 가능하며 이때 사용하는 명령은


EXEC sp_attach_db 'pubs'

, 'c:\Program Files\Microsoft SQL Server\MSSQL\Data\pubs.mdf'

, 'c:\Program Files\Microsoft SQL Server\MSSQL\Data\pubs_log.ldf'


명령으로 복구할 수 있습니다.

mdf, ldf파일을 복사하려하는데 ‘원본이나 대상 파일이 사용중인 것 같습니다’라
는 에러메시지가 뜨면서 복사가 안되는 경우 SQL서비스를 중지하고 복사작업을 하
면되지만 서비스중인 SQL을 중지하기가 난감한 경우엔 다음과 같은 방법으로 데이
터베이스를 분리한뒤 다시 붙이는 식으로 작업을 하면됩니다.

1. 쿼리분석기를 이용하는 방법으로 알려드리겠습니다.
sp_detach_db를 이용해서 Db를 분리해낸 뒤 복사하고
다시 sp_attach_db를 이용해서 DB를 붙이시면 됩니다.
query문
sp_detach_db ‘DB명’
go
쿼리문 실행하고 파일복사후
sp_attach_db ‘DB명’ , ‘ c:\...\DB명_Data.mdf ’ , ‘ c:\...\DB명_Log.ldf ’
go
이렇게 하시면 됩니다.

Enterprise manager로 사용시
1. 같은 이름의 db를 만든다 (텅빈 db)
2. 빈 db를 그냥 풀 백업 한다.
3. 원본서버에서 가져온 백업본으로 리스토어 한다.
4. 리스토어시 옵션의 강제로 덮어쓰기 하시면 됩니다.
SQL Query Analyzer
쿼리문은 다음과 같습니다.
restore database 데이터베이스 이름 from disk = '백업 세트 경로'

원인 : SQL Server는 내부적으로 Windows 컴퓨터 이름을 사용하는 데 Windows 이름이바뀌더라도 SQL Server가 참조하는 이름 정보를 변경하지 않기 때문입니다.

해결책 : 이 문제를 해결하기 위하여 다음의 두 방법 중에서 선택할 수 있습니다.

첫째, Windows 컴퓨터 이름을 이전 상태로 바꾸는 것입니다.
둘째, SQL Server 원본 CD에서 SQL Server Setup을 수행하는 것입니다.
Setup을 수행하면 실제 설치 작업을 하는 것이 아니라 SQL Server가 참조하는 컴퓨터 이름 정보만 수정하므로 시간이 오래 걸리지 않습니다. 이와 더불어 수행해야 할 작업은 SQL Server가 내부적으로 저장하고 참조하는 SQL Server 이름 정보의 갱신입니다. 이를 수행하지 않을 경우 분산 질의나 Replication 과 같이 로컬 서버 이름을 참조하는 작업을 진행할 수 없습니다. SQL Server의 내부 서버 이름을 변경하기 위하여 다음의 절차를 따릅니다.

1. Query Analyzer에서 다음을 수행합니다.

sp_dropserver 'old_servername'
go
sp_addserver 'new_servername', local
go

2. Service Manager나 Enterprise Manager에서 SQL Server를 중지합니다.
3. SQL Server를 시작합니다.
4. Query Analyzer에서 Server 이름이 갱신되었는지 확인하기 위하여 다음을 수행합니다.

Select @@SERVERNAME

출처 : http://korea.internet.com

마지막 활성 트랜잭션 로그를 백업할 수 있다면 데이터베이스의 복원이 가능한데 이번 기사에서는 마스터 및 데이터베이스 파일이 손상되었을 때 마지막 트랜잭션 로그를 백업해 이후 복원에 활용하는 방법에 대해서 Microsoft 고객기술지원부의 내용을 알아보자.

데이터베이스 파일이 손상되었어도 트랜잭션 로그 파일을 액세스할 수 있으면 현재의 활성 트랜잭션 로그를 백업할 수 있다. Microsoft SQL Server 7.0에서는 주 데이터 파일과 트랜잭션 로그 파일을 모두 액세스할 수 있어야 마지막 활성 트랜잭션 로그를 백업할 수 있다. 마스터 데이터베이스도 손상된 경우 데이터 파일과 마스터 장치가 둘 다 손상된 미디어에 있으면 먼저 마스터 데이터베이스를 다시 생성하고 복원한 다음 액세스할 수 없는 데이터베이스의 마지막 활성 트랜잭션 로그를 백업할 수도 있다. 그러나, 마스터 데이터베이스 백업을 사용할 수 없는 경우에도 SQL Server 7.0에서 주 데이터 파일과 트랜잭션 로그 파일을 액세스할 수 있으면 아래 방법을 사용하여 데이터베이스의 마지막 활성 트랜잭션 로그를 백업할 수도 있다.

Microsoft SQL Server 2000에서는 트랜잭션 로그 파일만 액세스할 수 있으면 마지막 활성 트랜잭션 로그를 백업할 수 있다.

SQL Server 2000 에서는

마스터 데이터베이스와 사용자 데이터베이스의 데이터 파일이 손상되었으나 데이터베이스의 트랜잭션 로그 파일에 여전히 액세스할 수 있으면 아래 단계를 수행하여 데이터베이스의 마지막 활성 트랜잭션 로그를 백업함으로써 데이터 손실을 줄일 수 있다.
트랜잭션 로그 파일의 이름을 변경한다.
마스터 데이터베이스를 다시 만든다.
유사한 데이터베이스를 만든다. 새 데이터베이스는 크기가 같을 필요는 없지만 포함하는 데이터 파일 및 로그 파일의 수는 같아야 한다.
SQL Server를 중지한다.
새로 만든 데이터베이스의 데이터 파일을 모두 삭제하여 복구되지 않게 한다. 트랜잭션 로그를 백업할 수 있도록 새 데이터베이스의 로그 파일을 원래의 로그 파일로 바꾼다.

Microsoft SQL Server 7.0 에서는

주 데이터 파일과 트랜잭션 로그 파일의 이름을 변경한다.
마스터 데이터베이스를 다시 만든다.
유사한 데이터베이스를 만든다. 새 데이터베이스는 크기가 같을 필요는 없지만 포함하는 데이터 파일 및 로그 파일의 수는 같아야 한다.
SQL Server를 중지한다.
새로 만든 데이터베이스의 데이터 파일을 모두 삭제하여 복구되지 않게 한다. 트랜잭션 로그를 백업할 수 있도록 새 데이터베이스의 주 데이터 파일과 로그 파일을 원래의 파일로 바꾼다.
SQL Server를 다시 시작한다.
아래 명령을 실행하여 로그의 마지막 부분을 복원한다.
Backup Log to Disk = With NO_TRUNCATE
sp_dbremove 저장 프로시저를 사용하여 데이터베이스를 제거한다. 모든 로그 파일과 함께 데이터베이스를 복원한다.

출처 : http://korea.internet.com

Microsoft SQL Server 2000 설치 작업 도중 실패하여 이후 프로그램 제거 옵션을 사용하지 못할때 해결 하는 방법에 대해서 알아보자. 여기에서 제안하는 방법은 잘못된 설치 환경을 깨끗하게 제거 하기 위해 같은 환경과 방법으로 설치를 한다. 이를 통해 제거 옵션을 사용해서 제거 하는 방법이고 이를 가능하게 하기 위해 안정된 재 설치 시점으로 되돌리는 방법에 대해서 이야기 한다.

Microsoft SQL Server 2000을 제거하기 전에

기본 데이터베이스 중 하나에 속할 수 있는 변경 사항과 함께 현재 상태로 저장하고자 하는 데이터베이스가 있을 수 있다. 그럴 경우 본 문서의 단계를 사용하기 전에 MSSQL 디렉터리를 삭제해야 하므로 MSSQL 디렉터리 이외의 디렉터리에 저장해야 하는 데이터의 양호한 백업이나 모든 데이터와 로그 파일의 복사본이 있는지 확인한다.

이러한 파일에는 Microsoft SQL Server 2000이 기본적으로 설치하는 데이터베이스 파일이 포함된다.

Distmdl.*
Master.*
Mastlog.*
Model.*
Modellog.*
Msdbdata.*
Msdblog.*
Northwnd.*(옵션 설치)
Pubs.*
Pubs_log.*
Tempdb.*
Templog.*
또한 다음과 같이 하는 것이 좋다.

Microsoft SQL Server 2000이 클러스터된 경우 다른 클러스터 리소스가 Microsoft SQL Server 2000에 종속되어 있는지 확인한다.
활성 연결이 있으면 제거 프로세스가 성공적으로 완료되지 못할 수 있으므로 Microsoft SQL Server 2000을 중지한다.
Microsoft SQL Server 2000 클라이언트 또는 관리 도구가 다른 노드에서 열려 있지 않도록 한다.
Microsoft SQL Server 2000 서비스 계정이나 동등한 권한을 가진 계정(로컬 관리자 계정의 구성원인 계정)으로 서버에 로그온한다. SQL Server가 클러스터된 경우 사용하는 계정은 모든 클러스터 노드에 있는 로컬 관리자의 구성원이어야 한다.
제거 하려면 다음과 같이 진행한다.

다음 목록에서 사용자의 환경에 따라 옵션을 한 가지 이상 사용할 수 있다. 아래 순서대로 옵션을 실행한다.

2단계와 3단계는 Microsoft SQL Server 2000의 로컬 설치에 적용할 수 있으며 Microsoft SQL Server 2000의 클러스터된 설치에는 적용할 수 없다.

CD의 Microsoft SQL Server 2000 설치 프로그램을 사용하고 제거를 누른다.
제어판에서 프로그램 추가/제거 애플릿을 연다.
regedit을 실행한 다음 다음 레지스트리 키를 찾는다.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall
제거 키에서 제거하려는 Microsoft SQL Server 2000의 인스턴스에 해당하는 제품 키를 찾는다.
작업 표시줄에서 시작을 누른 다음 실행을 누른다.
실행 대화 상자에 다음 명령을 복사하여 붙여넣거나 입력한다.
C:\WINNT\IsUninst.exe -f"C:\Program Files\Microsoft SQL Server\MSSQL$Server1\Uninst.isu" -c"C:\Program Files\Microsoft SQL Server\MSSQL$Server1\sqlsun.dll" -msql.mif i=I1
앞의 단계가 작동하지 않는 경우 마지막 수단으로 다음 단계를 사용하여 Microsoft SQL Server 2000을 수동으로 제거할 수 있다.
참고로 당장 SQL Server 2000을 제거하는 것은 아니다. 이 단계는 시스템을 성공적으로 다시 설치할 수 있는 상태로 만든 다음 Microsoft SQL Server 2000 인스턴스를 적절하게 제거하는 것이다.
설치용 Data 폴더를 찾고 데이터를 저장해야 할 경우 이름을 바꾼다. 또는 Data 폴더를 삭제한다. 마이크로소프트는 MDF와 LDF 형식으로 데이터베이스 백업을 사용할 수 있게하기 위해, 사용자들이 데이터 폴더를 삭제하는 것을 권장하지 않는다.
%drive% :\Program Files\Microsoft SQL Server\MSSQL\Binn 폴더를 찾은 다음 삭제한다.
다음 레지스트리 키를 찾은 다음 삭제한다.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server
다음 레지스트리 키를 찾은 다음 삭제한다.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSSQLServer
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SQLSERVERAGENT
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSSQLServerADHelper
앞의 레지스트리 키 세 개는 Microsoft SQL Server 2000의 기본 인스턴스에 대응한다. instance_name은 특정 인스턴스에 주어진 이름이기 때문에 명명된 인스턴스는 $instance_name과 함께 d단계에 표시된 것과 비슷하게 나타난다. 제거하려는 인스턴스의 올바른 키를 찾아서 해당 키를 선택하고 삭제한다. 주의해야 할점은 다른 서비스에서 MSSEARCH를 사용하는지 않는 경우 다음 서비스만 삭제한다.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSFTPSVC
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSSCNTRS
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSSEARCH
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSSGATHERVER
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSSGTHRSVC
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSSINDEX
만약 SQL 서버 인스턴스가 클러스터되어 있으면, 클러스터 관리자에 남아 있을 수 있는 이 SQL 서버 인스턴스의 클러스터 리소스를 제거한다. 반드시 SQL 서버의 리소스만 제거해야 한다.
Microsoft SQL Server 2000을 다시 설치하고 같은 이름, IP 주소 등을 사용한다.
설치 프로그램을 실행하고 정상적인 제거를 수행하여 설치 실패로 인해 남아 있을 수 있는 구성 문제나 오류를 해결한다.
때로는 폴더 %drive%:"\Program Files\Microsoft SQL Server\80이 삭제되지 않을 수 있으며 이 때는 수동으로 삭제해야 한다.
SQL Server 2000을 제거하면 다음과 같은 오류 메시지가 나타날 수 있다.
설치 시스템에 이전 프로그램 설치 과정에서 생긴 보류된 파일 작업이 있다. 설치를 실행하기 전에 컴퓨터를 다시 시작해야 한다.
오류 메시지가 나타나면 서버를 다시 시작한 다음 설치를 다시 해본다. 서버를 다시 시작한 후에 오류 메시지가 다시 나타나면 삭제하려는 파일이 읽기 전용일 가능성이 있다. 파일이 읽기 전용인지 확인하려면 다음 레지스트리 키를 찾는다.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\PendingFileRenameOperations

데이터베이스를 물리적인 위치를 변경시키는 다양한 방법

Database를 다른 위치로 이동/복사하고자 하는 경우에 다음의 세 가지 방법을 사용할 수 있다.

-Database Backup을 수행한 다음에 Restore 작업을 수행하면서 이동이 가능하다.
-Database를 detaching하고 Database File들을 원하는 위치로 이동한 다음에 다시 attaching함으로써 이동이 가능하다.
-BCP, DTS를 사용하여 이동이 가능하다.

어떤 방법을 사용할 것인지는, SQL Server 버전, SQL Server가 사용하는 Character Set/Sort Order, Database Size, 운영 여건 등의 여러 가지 요소들을 확인한 다음에 결정해야 한다.

위의 세 가지 방법 중에서 두 번째 방법을 사용하여 데이터베이스를 이동하는 방법에 대해서 자세히 알아보자. 동일한 SQL Server 내에서 Database의 파일 위치를 이동하는 경우에는 관계 없지만, 서로 다른 SQL Server간의 이동을 위해 두 번째 방법을 사용하고자 하는 경우에는, Source Database가 존재하는 SQL Server와 Destination Database가 존재할 SQL Server의 버전이 동일해야 하며 양쪽 SQL Server가 사용하는 Character Set과 Sort Order가 동일해야 한다.

데이터베이스를 분리하고 다시 연결하는 방법

SQL Server 7.0과 2000에서 Database의 위치를 이동하고자 하는 경우에, sp_detach_db와 sp_attach_db를 사용하여 작업하는 것이 가능하다.

이용하기전 온라인 도움말의 sp_detach_d, sp_attach_db 예제 구문을 보면 이해가 쉬울 것이다.

다음과 같이 작업하면 된다.

아래의 예문들은 Database 명이 "userdb" 라고 가정하고 작성된 내용이므로, "userdb" 라고 기술한 위치에 실제 작업할 Database명을 기술하면 된다. 작업에 앞서 기존내용들을 백업한 후 테스트 해보기 바란다.

-작업할 Database file의 위치를 확인한다.
Use userdb
Go
Sp_helpfile
Go

-해당 Database를 SQL Server에서 분리한다. 이 작업을 수행하기 위해서는, 해당 Database를 사용하는 Process가 없어야 한다. 현재 해당 Database를 사용하는 사용자가 있다면, 현재 수행중인 작업들이 종료되기를 기다렸다가 작업하시기 바란다. 그리고, Query Analyzer 등에서, 작업할 Database에 연결한 사용자들이 있다면 모두 그 Database에서 빠져 나가도록 한 다음에 작업을 수행해야 한다. 기다리는 것이 지루하다면 서비스를 잠시 멈췄다가 사용할 수 있다.
sp_detach_db userdb
go

-위의 Scripts를 수행한 다음에 Results창에 다음과 같이 메시지가 나타나는지 확인한다.
Successfully detached Database 'userdb'.
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

-만약, 작업할 Database를 사용하고 있는 사용자가 있으면, 다음과 같이 에러 메시지가 발생하면서 작업이 중단된다.
Server: Msg 3702, Level 16, State 1, Line 0
Cannot drop the Database 'userdb' because it is currently in use.
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

-해당 Database가 제대로 분리(detaching)되었는지 확인한다.
sp_helpdb userdb
go

-제대로 분리되었다면, 다음과 같은 형태의 메시지가 리턴 될 것이다.
Server: Msg 15010, Level 16, State 1, Procedure sp_helpdb, Line 51
The Database 'userdb' does not exist. Use sp_helpdb to show available Databases.

-이동하고자 하는 위치로 Database file들을 이동/복사한다.

-이동한 Database file을 원하는 SQL Server에서 다시 부착(attaching)해 준다.
sp_attach_db N'userdb', N'E:\mssql7\Dbdevice\userdbdata.mdf', N'E:\mssql7\Dbdevice\userdblog.ldf'
go

-위의 Scripts를 수행하면, 다음과 같은 메시지가 리턴된다.
Successfully attached Database 'userdb'.

-해당 Database가 SQL Server에 제대로 부착되었는지 확인한다.
sp_helpdb userdb
go

우선, win2k에서 제어판의 국가별 옵션에서 일본어를 추가해줘야 합니다.

디비 생성시 japanese_unicode_cs_as_ks_ws로 설정하고

Sql서버의 테이블 관련컬럼의 데이터 타입을 유니코드 데이터 타입으로 설정하시기 바랍니다.
예)nchar, nvarchar등으로

자세한사항은 아래 페이지들을 참고하세요..

http://sqler.pe.kr/prolec/pse03.asp

http://www.microsoft.com/korea/msdn/library/techart/IntlFeaturesInSQLServer2000.htm

출처 : http://support.microsoft.com
요약
이 문서에서는 Microsoft SQL Server 7.0 또는 Microsoft SQL Server 6.5 설치를 Microsoft SQL Server 2000 버전 8.0으로 변환하는 방법에 대한 질문과 대답을 설명합니다.
추가 정보
질문: SQL Server 7.0 데이터베이스를 분리하고 SQL Server 2000 서버에 연결할 수 있습니까?

대답: 예. SQL Server 7.0 데이터베이스는 SQL Server 2000과 호환되지만 예외가 있습니다. 이 예외 목록을 보려면 SQL Server 2000 온라인 설명서의 "SQL Server 7.0에서 데이터베이스 업그레이드" 항목을 참조하십시오. SQL Server 7.0 데이터베이스를 SQL Server 2000에 연결하면 SQL Server 7.0 데이터베이스가 SQL Server 2000 데이터베이스로 자동 업그레이드되고 SQL Server 7.0 설치에서 더 이상 데이터베이스를 사용할 수 없습니다.
질문: SQL Server 2000 데이터베이스를 분리하고 SQL Server 7.0 서버에 연결할 수 있습니까?

대답: 아니요. SQL Server 2000 데이터베이스를 SQL Server 7.0 서버로 이동하는 유일한 방법은 데이터 변환 서비스(DTS), bcp 또는 링크된 서버 간의 쿼리 사용 같은 방법을 사용하여 데이터를 변환하는 것입니다.
질문: SQL Server 7.0 데이터베이스 백업을 SQL Server 2000 서버로 복원할 수 있습니까?

대답: 예. master, model, msdb 및 배포 데이터베이스 이외의 SQL Server 7.0 데이터베이스는 SQL Server 2000과 호환됩니다.
질문: SQL Server 2000 데이터베이스 백업을 SQL Server 7.0 서버로 복원할 수 있습니까?

대답: 아니요. SQL Server 2000 데이터베이스를 SQL Server 7.0 서버로 이동하는 유일한 방법은 DTS, bcp 또는 링크된 서버 간의 쿼리 사용 같은 방법을 사용하여 데이터를 변환하는 것입니다.
질문: SQL Server 6.5 데이터베이스를 SQL Server 2000으로 복원하거나 연결할 수 있습니까?

대답: 아니요. SQL Server 6.5 데이터베이스를 SQL Server 2000으로 이동하는 유일한 방법은 업그레이드 마법사를 실행하는 것입니다.
질문: 업그레이드하려면 SQL Server 7.0 서비스 팩이 필요합니까?

대답: Microsoft 고객기술지원부에서는 최신 서비스 팩을 설치할 것을 권장하지만 SQL Server 7.0을 SQL Server 2000 버전 8.0으로 업그레이드하는 데 서비스 팩은 필요하지 않습니다.
질문: SQL Server 2000 버전 8.0으로 업그레이드하는 데 어떠한 SQL Server 6.5 서비스 팩이 필요합니까?

대답: SQL Server 6.5를 같은 컴퓨터에서 SQL Server 2000의 인스턴스로 업그레이드할 때 먼저 SQL Server 버전 6.5 서비스 팩 5a 이상을 적용해야 합니다. SQL Server 6.5를 다른 컴퓨터에서 SQL Server 2000의 인스턴스로 업그레이드할 때는 먼저 SQL Server 버전 6.5 서비스 팩 3 이상을 적용해야 합니다.
질문: SQL Server 6.5 데이터베이스를 업그레이드하는 프로세스에는 시간이 얼마나 걸립니까?

대답: SQL Server 6.5 데이터베이스를 SQL Server 2000 버전 8.0으로 업그레이드하는 데 필요한 시간에 영향을 미치는 요소는 여러 가지가 있습니다. SQL Server 2000 데이터베이스에서 SQL Server 6.5 데이터베이스의 각 개체를 다시 작성해야 하며 모든 행을 전달해야 합니다. 각 데이터베이스의 복잡성에 따라 행과 개체의 수가 다른 두 개의 10GB 데이터베이스를 변환하는 데 필요한 시간은 크게 다릅니다. 또한 하드웨어 플랫폼, 프로세서 수, 디스크 하위 시스템 및 RAM의 양은 업그레이드에 필요한 시간을 결정하는 데 중요한 역할을 합니다. 설치하는 동안 "데이터 유효성 검사"를 선택하면 두 가지 요소에 의해 업그레이드를 수행하는 데 필요한 시간이 증가합니다. 업그레이드 프로세스에 필요한 일반적인 시간은 다음과 같습니다.

데이터베이스 크기 업그레이드에 필요한 예상 시간
400MB 20분 미만
1GB 1시간 미만
10GB 4시간 미만
50GB 12시간 미만
100GB 24시간 미만

질문: 설치 업그레이드 프로세스를 실행하는 동안 SQL Server 7.0 서버에 연결할 수 있습니까?

대답: 아니요. 설치 업그레이드를 수행하면 SQL Server 7.0 서버가 중지되고 시작되므로 사용자는 연결을 유지할 수 없습니다. 사용자가 연결을 유지하고 있을 때 업그레이드를 수행하려면 SQL Server 2000의 개별 인스턴스를 설치한 다음 데이터베이스 복사 마법사를 사용하여 Microsoft SQL Server 7.0의 각 데이터베이스를 Microsoft SQL Server 2000의 해당 인스턴스로 복사해야 합니다. 데이터베이스 복사 마법사를 사용하면 프로세스에서 서버를 종료하지 않고 SQL Server 7.0 데이터베이스를 업그레이드할 수 있습니다.
질문: 업그레이드 프로세스를 실행하는 동안 SQL Server 6.5 서버에 연결할 수 있습니까?

대답: 아니요. 업그레이드 프로세스 동안 SQL Server 6.5 서버가 중지되고 시작되면서 개체가 스크립트되고 데이터가 추출됩니다. 또한 데이터 전송이 시작되면 SQL Server 2000만 실행되고 SQL Server 6.5에는 액세스할 수 없습니다.
질문: 업그레이드를 수행하기 전에 SQL Server 6.5 서버를 어떻게 구성해야 합니까?

대답: SQL Server 2000을 실행하는 새 컴퓨터로 기존 SQL Server 6.5 서버를 업그레이드하는 경우 두 컴퓨터 모두 MSSQLServer 서비스에 대해 도메인 사용자 이름과 암호를 사용하도록 구성해야 합니다. 또한 도메인 사용자 계정은 두 컴퓨터에서 모두 Administrators 그룹에 속해야 합니다. 한 컴퓨터 업그레이드는 로컬 시스템 계정으로 충분합니다. 여러 도메인에서 업그레이드하는 경우 업그레이드를 시작하기 전에 도메인 간에 트러스트 관계를 설정해야 합니다.
질문: 둘 이상의 6.5 SQL Server 서버에서 하나의 SQL Server 2000 서버로 데이터베이스를 통합할 수 있습니까?

대답: 아니요. 업그레이드 프로세스는 업그레이드 중인 서버를 추적하여 하나의 6.5 SQL Server 서버의 데이터베이스만 업그레이드할 수 있도록 합니다. 여러 서버의 데이터베이스를 통합하면 사용자 로그인 ID, 사용자 계정 및 개체 사용 권한에 문제를 일으킬 수 있습니다. 다른 6.5 SQL Server 서버의 여러 데이터베이스를 통합하려면 단일 SQL Server 서버로 통합할 모든 데이터베이스를 이동하고 SQL Server 2000으로 업그레이드하기 전에 응용 프로그램이 올바르게 작동하는지 확인하십시오.
질문: 데이터베이스를 하나 또는 몇 개만 SQL Server 2000으로 업그레이드할 수 있습니까?

대답: 기존 SQL Server 7.0 인스턴스를 SQL Server 2000으로 업그레이드하면 SQL Server 7.0이 SQL Server 2000으로 대체되기 때문에 항상 모든 데이터베이스가 업그레이드됩니다. SQL Server 7.0 데이터베이스의 일부만 업그레이드하려면 SQL Server 2000을 별개의 인스턴스로 설치하고 데이터베이스 복사 마법사를 사용하여 데이터베이스를 업그레이드해야 합니다. 자세한 내용은 SQL Server 온라인 설명서의 "SQL Server 7.0에서 데이터베이스 업그레이드" 항목을 참조하십시오.

SQL Server 6.5를 업그레이드하면 SQL Server 데이터베이스 하나, 일부 또는 전부를 SQL Server 2000으로 업그레이드할 수 있습니다. 서버의 모든 데이터베이스를 업그레이드하기 전에 개별 데이터베이스를 테스트나 실습 목적으로 변환할 수도 있습니다. 그러나 문제 발생 가능성을 최소화하기 위해 서버에 있는 모든 프로덕션 데이터베이스를 동시에 변환하는 것이 좋습니다. 기존 SQL Server 데이터베이스의 하위 집합만 변환하려면 동시에 모두 변환해야 합니다.

모든 SQL Server 6.5 데이터베이스를 동시에 업그레이드하지 않는 경우 몇 가지 문제가 발생할 수 있습니다. 뷰, 저장 프로시저, 트리거 등 다른 데이터베이스의 내용에 의존하는 개체는 개체 또는 종속 데이터베이스가 없는 경우 만들어지지 않습니다.

추가 개체를 포함하도록 SQL Server 6.5 model 데이터베이스가 수정된 경우 다른 모든 SQL Server 6.5 데이터베이스와 동일한 시간에 또는 마지막으로 변환해야 합니다. SQL Server 6.5 model 데이터베이스에 추가되는 기본이 아닌 개체의 결과로 SQL Server 6.5 데이터베이스에서 만든 개체는 업그레이드 프로세스 동안 스크립팅됩니다.

model 데이터베이스가 이미 변환된 후에 다른 SQL Server 6.5 데이터베이스가 업그레이드되면 SQL Server 6.5 model 데이터베이스에 따라 기본이 아닌 개체가 포함됩니다. 개체는 처음에 SQL Server 2000 model 데이터베이스에서 만들어질 때 새로운 SQL Server 2000 데이터베이스에 추가되기 때문에 작성 스크립트는 데이터베이스에 이미 있는 개체를 만들지 못합니다. 따라서 model 데이터베이스를 마지막으로 변환함으로써 데이터베이스 구조의 모든 변경은 새로운 SQL Server 2000 데이터베이스에만 적용됩니다. SQL Server 6.5로 변환된 데이터베이스의 모든 기본이 아닌 개체는 이러한 데이터베이스를 변환하는 동안 스크립트에서 만들어집니다.
질문: 같은 컴퓨터에서 SQL Server 7.0 또는 6.5와 동시에 SQL Server 2000을 실행할 수 있습니까?

대답 : SQL Server 6.5 및 SQL Server 7.0은 서버에 기본 인스턴스로 설치되며 특정 컴퓨터에서 한 번에 두 버전 중 하나만 실행할 수 있습니다. 그러나 SQL Server 2000에서는 SQL Server 데이터베이스 엔진의 여러 인스턴스가 동일한 컴퓨터에서 동시에 실행될 수 있습니다. SQL Server 2000을 명명 인스턴스로 설치한 경우 컴퓨터에 이전에 설치된 SQL Server 6.5 또는 SQL Server 7.0 기본 인스턴스와 함께 실행할 수 있습니다. SQL Server 2000을 기본 인스턴스로 설치한 경우 컴퓨터에 이미 있는 SQL Server 6.5 또는 7.0 기본 인스턴스가 업그레이드됩니다. SQL Server 6.5를 실행하는 컴퓨터에서 이렇게 될 경우에 업그레이드한 후 vswitch 유틸리티를 사용하여 SQL Server 2000 기본 인스턴스와 SQL Server 6.5 기본 인스턴스 간에 전환할 수 있습니다. SQL Server 7.0 기본 인스턴스가 업그레이드되는 경우에 업그레이드한 후 SQL Server 2000 기본 인스턴스에 액세스할 수 있습니다.

SQL Server 데이터베이스 엔진의 각 인스턴스에 인스턴스 간 공유되지 않는 시스템 및 사용자 데이터베이스의 고유한 집합이 있다는 것을 알고 있어야 합니다.

자세한 내용은 SQL Server 온라인 설명서의 "SQL Server의 인스턴스 및 버전 작업" 항목을 참조하십시오.
질문: SQL Server 6.5 변환 동안 아래와 같은 내용의 오류가 나타나는 이유는 무엇입니까?



@@servername이 유효하지 않습니다
대답: 이 오류 메시지는 업그레이드 중인 SQL Server 6.5에 이름이 지정되지 않은 경우 발생할 수 있습니다. 이 문제를 해결하려면 6.5 SQL Server 서버에서 다음 단계를 수행하십시오.


ISQL 또는 ISQL/w에서 다음 쿼리를 실행하여 서버에 이름이 있는지 확인하십시오.SELECT @@servername

서버에 이름이 없는 경우 다음 저장 프로시저를 실행하여 이름을 추가하십시오. sp_addserver , local

질문: SQL Server 6.5 서버를 업그레이드하면 다음과 같은 내용의 오류 메시지가 나타나는 이유는 무엇입니까?

기본 데이터베이스를 열 수 없습니다


@@servername을 쿼리하는 동안 오류가 발생했습니다
대답: 시스템 관리자(SA)의 기본 데이터베이스를 아직 복구하지 않은 경우 또는 그렇다고 의심되는 경우 업그레이드 마법사는 이러한 오류 메시지 중 하나를 표시합니다. 기본 데이터베이스의 문제를 해결하고 업그레이드 마법사를 다시 실행하십시오.
질문: SQL Server 6.5 서버를 업그레이드하면 업그레이드 마법사가 응답을 중지하는 것 같습니다. 그 이유는 무엇입니까?

대답: 변환 프로세스 동안 응용 프로그램이나 서비스가 ODBC를 SQL Server 6.5 서버에 연결하는 경우 SQL Server 서버를 완전하게 종료하지 못할 수 있습니다. SQL Server 6.5 서버가 완전히 중지되었는지 확인하지 못하면 변환 프로세스는 다음 단계로 진행하지 못합니다. 변환 프로세스는 응답하지 않는 것으로 나타나며 이 경우 결국 프로세스가 실패합니다. 이 문제를 해결하려면 업그레이드를 수행하기 전에 ODBC에 연결되었거나 SQL Server를 사용 중일 수 있는 모든 응용 프로그램과 서비스를 닫으십시오. SQL 추적이 버전 6.5 SQL Server 서버에 연결된 경우 비슷한 문제가 나타나게 됩니다. 서버는 실제로 응답을 중지하지 않지만 일단 발생한 작업이 아주 많은 CPU 시간을 빠르게 사용하여 속도가 급격히 느려집니다.
질문: 업그레이드 프로세스 동안 발생할 수 있는 오류 기록은 어디에서 볼 수 있습니까?

대답: 업그레이드 프로세스 동안 자세한 로그가 생성되어 SQL 디렉터리에 저장됩니다. 업그레이드 프로세스 동안 오류가 발생하면 프로세스 끝에 대화 상자가 표시됩니다. 이 대화 상자는 오류 파일의 내용을 표시합니다. 이 출력 파일은 Program Files\Microsoft SQL Server\MSSQL\Upgrade\__ 디렉터리에 있습니다. 각 데이터베이스는 업그레이드 프로세스 동안 생성된 출력과 오류를 저장한 자체 하위 디렉터리를 갖고 있습니다.
그래도 원하는 정보를 찾을 수 없으면 다음 Microsoft SQL Server 뉴스 그룹을 방문하십시오. Microsoft SQL Server 뉴스 그룹

이 문서나 다른 Microsoft SQL Server 기술 자료 문서에 대한 의견이 있으면 SQLKB로 보내 주시기 바랍니다.

출처 : http://support.microsoft.com

요약
SQL Server 트랜잭션 로그가 가득 차면 데이터베이스에서 CHECKPOINT를 비롯하여 UPDATE, DELETE 또는 INSERT 작업을 더 이상 할 수 없습니다. 이러한 상황은 아래와 같은 오류 1105로 나타납니다.

Can't allocate space for object syslogs in database dbname because the logsegment is full. If you ran out of space in syslogs, dump the transaction log. Otherwise use ALTER DATABASE or sp_extendsegment to increase the size of the segment.
master 또는 tempdb를 비롯한 어떤 데이터베이스에서나 이러한 상황이 발생할 수 있습니다. 본 문서에서는 오류 1105를 일으키는 문제점에 대한 가능한 원인과 해결 방법을 설명합니다. 트랜잭션 로그가 가득 차서 오류 1105가 발생한 경우에는 DUMP TRANSACTION 문을 사용하여 로그를 비워야 합니다. DUMP TRANSACTION의 사용 방법에 대한 자세한 내용은 SQL Server 설명서를 참조하십시오.
추가 정보
Microsoft SQL Server 같은 전형적인 관계형 데이터베이스의 기본 특성은 트랜잭션 무결성을 보장하는 것입니다. 모든 트랜잭션은 시스템 오류가 발생한 경우에도 변경 내용이 모두 적용되거나 전혀 적용되지 않는다는 점에서 완전한 원자성(즉, 개별적으로 기능을 수행)을 가져야 합니다. 사용자 정의 트랜잭션에서 BEGIN TRANSACTION 문과 COMMIT TRANSACTION 문 사이에 있는 모든 문은 모두 적용되거나 또는 전혀 적용되지 않습니다. 암시적 트랜잭션에서는 각각의 개별 SQL 문을 원자 단위로 간주합니다.

이러한 기능 때문에 SQL Server는 프로덕션 단계에서 전원 공급이 차단되거나 운영 체제가 충돌하는 등의 문제가 발생한 다음 다시 시작되고 나면 사용자의 개입 없이 자동으로 데이터베이스를 일관된 상태로 복구합니다. 이와는 대조적으로 비 관계형 시스템에서는 시스템 오류가 발생하면 데이터베이스의 일관성 문제를 검사하기 위해 오랜 시간에 걸친 수동 작업이 필요한 경우가 많습니다.

이러한 기능은 바로 트랜잭션 로그 메커니즘에 의해 제공됩니다. 트랜잭션 무결성은 SQL Server의 기본 기능, 즉 본질적인 특성으로 간주되기 때문에 로깅 설정을 해제할 수 없습니다. 특정 유틸리티를 사용하거나 빠른 BCP 또는 SELECT INTO 같은 유지 관리 작업을 통해 최소 로깅을 수행할 수 있지만 이러한 최소 로깅에서도 나중에 롤백할 수 있도록 익스텐트 할당을 기록합니다.

로깅에는 상당히 많은 공간이 필요할 수 있습니다. 예를 들어, 대개의 경우 업데이트되는 각 데이터 행의 업데이트 이전 및 이후 이미지뿐만 아니라 영향을 받는 모든 인덱스 행의 이미지도 기록해야 합니다. 로그에 기록되는 각 행에 대해 일정 양의 트랜잭션 레코드 오버헤드를 기록해야 하기 때문에 업데이트되는 데이터와 소모되는 로그 공간의 비율은 행 너비에 따라 상당히 다를 수 있습니다. 좁은 행인 경우에는 특정 UPDATE, DELETE 또는 INSERT 작업에 소모되는 로그 공간이 소모되는 데이터 공간의 10배가 될 수 있습니다. 행이 넓으면 소모되는 로그 공간이 상대적으로 작아집니다. 트랜잭션 무결성을 제공하기 위해서는 로그 공간 소모를 피할 수 없습니다. 데이터베이스 관리자는 설치 시 충분한 로그 공간을 제공해야 합니다.

필요한 로그 공간은 여러 가지 요인에 따라 달라질 수 있기 때문에 정확하게 예측하기는 어렵습니다. 처음에 로그 크기를 데이터베이스 크기의 15-30% 크기로 할당하는 것이 적절하다는 일반적인 규칙이 있지만, 실제 상황에서는 이 규칙도 매우 다를 수 있습니다. 성공적인 SQL Server 설치에서는 사용할 특정 데이터 및 응용 프로그램에 필요한 로그 공간을 대략적으로 예측하기 위해 간단한 실증적 테스트를 수행한 다음 그 예측을 바탕으로 로그 크기를 정합니다. 테스트 없이 계산만을 바탕으로 로그 크기를 정하기는 어려우며 정확하지 않을 수 있습니다.

예측하기 어려운 여러 가지 요인이 로그 공간 소모량의 변화에 영향을 미칠 수 있습니다. 그러한 요인 중 하나는 쿼리 최적화 프로그램(Query Optimizer)입니다. 특정 SQL 데이터 수정 문의 경우 액세스 계획은 데이터의 통계적 분포에 따라 시간이 가면서 달라질 수 있습니다. 액세스 계획마다 서로 다른 크기의 로그 공간을 소모할 수 있습니다. 또 따른 요인은 피할 수 없는 내부 데이터베이스 조각화로서 이는 수행되는 페이지 분할의 수에 영향을 미칠 수 있습니다. SQL Server는 사용자를 대신하여 데이터를 자동으로 관리하기 때문에 이 프로세스를 조사하거나 이 프로세스에 영향을 주기 위해 사용자가 할 수 있는 일이나 해야 할 일은 없습니다.

간단한 테스트 예제로 DBCC CHECKTABLE(syslogs)을 실행할 수 있습니다. 그러면 데이터 수정 쿼리에 대한 대표 예제를 실행하기 전과 실행한 후에 로그에 있는 2048바이트 데이터 페이지 수가 반환됩니다. 이 방법으로 이 유형의 쿼리에 필요한 로그 공간 크기를 대략적으로 알 수 있습니다. SQL Server 같은 관계형 데이터베이스에 로그 공간이나 데이터 디스크 공간을 제공할 때는 일반적으로 공간을 과다하게 할당하는 것이 최선의 방법입니다.

SQL Server 7.0 및 2000 클래스 서버는 필요에 따라 트랜잭션 로그를 확장하는 기능이 있습니다. 확장되는 크기를 사용자가 조정할 수도 있고 사용 가능한 디스크 공간을 모두 이용하도록 지정할 수도 있습니다. 로그 파일은 여러 개의 가상 로그 파일로 구성됩니다. 이 가상 로그 파일의 개수와 크기는 SQL Server에서 자동으로 결정하며 사용자가 구성할 수 없습니다. 데이터베이스를 처음 생성할 때 각 실제(Physical) 로그 파일은 최소한 두 개의 가상 로그 파일을 가집니다. 데이터베이스 관리자는 로그 공간 부족이 발생하지 않도록 하기 위해 데이터베이스의 "검사점에서 로그 자름(Truncate log on checkpoint)" 옵션을 사용 가능하게 설정하기도 합니다. 이 옵션의 목적은 주로 백업을 위해 로그 덤프에 의존하지 않는 개발용 또는 테스트용 데이터베이스를 위해 자동으로 로그를 자르는 방법을 제공하는 것입니다. 이 옵션을 설정해도 로깅 또는 트랜잭션 무결성의 설정이 해제되지는 않습니다. 이 옵션을 설정하면 단지 검사점(Checkpoint) 처리기가 약 60초 간격으로 로그를 자를 뿐입니다. "검사점에서 로그 자름(Truncate log on checkpoint)" 옵션이 설정된 데이터베이스에 수동 검사점(Checkpoint) 명령을 실행하면 로그가 잘리지 않습니다. tempdb 데이터베이스에 대해서는 이 옵션이 항상 설정되어 있지만 sp_help 저장 프로시저(stored procedure) 출력의 상태 열에는 나타나지 않습니다.

"검사점에서 로그 자름(Truncate log on checkpoint)" 옵션을 설정하더라도 여러 가지 요인에 의해 로그 공간이 부족할 수 있습니다. 이러한 각각의 요인을 아래에서 설명합니다.
대량 원자 트랜잭션, 특히 일괄적인 UPDATE, INSERT 또는 DELETE 작업 트랜잭션: 각각의 단일 SQL 문은 완전히 적용되거나 전혀 적용되지 않아야 하는 원자 단위로 간주됩니다. 따라서 모든 행 교체가 로그에 기록되어야 하며 수행되는 동안에는 트랜잭션이 잘리지 않습니다. 예를 들어, 실행하는 데 5분이 걸리는 대량 일괄 INSERT가 실행될 경우 이 시간 동안은 해당 트랜잭션에 소모되는 로그가 잘리지 않습니다. 데이터베이스 관리자는 예상되는 가장 큰 일괄 작업을 수행하는 데 충분한 로그 공간을 제공하거나 일괄 작업을 좀더 작은 그룹으로 나누어 수행해야 합니다.
커밋되지 않은 트랜잭션: 로그는 가장 오래된 커밋되지 않은 트랜잭션 이전까지만 잘립니다. 커밋되지 않은 트랜잭션의 원인은 몇 가지가 있을 수 있지만 대개는 응용 프로그램 오류가 그 원인입니다. 원인은 아래와 같습니다.
일괄 트랜잭션: 위에서 설명한 것처럼 대량 일괄 트랜잭션이 수행되는 동안에는 트랜잭션에 의해 생성되는 로그 레코드가 잘리지 않습니다. 그러나 그러한 트랜잭션 때문에 같은 기간에 커밋을 수행하는 좀더 짧은 다른 트랜잭션의 로그도 잘리지 않습니다.

예를 들어, 데이터베이스 관리자가 가능한 가장 큰 일괄 트랜잭션을 수행하는 데 충분한 크기의 로그를 할당했다고 가정합니다. 그러나 이 트랜잭션이 실행되는 동안 좀더 짧은 다른 데이터 수정 문도 역시 로그 공간을 소모할 수 있습니다. 대량 일괄 트랜잭션이 먼저 시작되었고 그것이 가장 오래된 커밋되지 않은 트랜잭션이기 때문에 로그 공간은 잘리지 않습니다. 관리자는 대량 일괄 트랜잭션의 동시성과 로그에 미치는 영향을 인식하고 적절하게 로그 크기를 조정해야 합니다.
사용자 정의 트랜잭션 내에서 사용자 입력 또는 시간이 오래 걸리는 다른 작업을 허용하는 잘못 설계된 응용 프로그램: 응용 프로그램이 BEGIN TRANSACTION을 실행한 후 사용자의 동작에 따라 시간이 오래 걸릴 수도 있는 입력을 사용자에게 요구하는 경우를 예로 들 수 있습니다. 이 경우, 사용자가 응답하고 응용 프로그램이 COMMIT을 실행할 때까지는 로그를 자를 수 없습니다.
트랜잭션이 커밋되지 않는 응용 프로그램 오류: 이 오류의 일반적인 원인은 사용자 정의 트랜잭션 내에서 DB-Library 호출 dbcancel()을 잘못 처리하는 것입니다. dbcancel()을 사용하여 쿼리를 취소할 경우 현재 실행 중인 SQL 문은 중단되고 롤백되지만 다른 트랜잭션은 계속 실행됩니다. 응용 프로그램에서 이를 인식하고 필요한 ROLLBACK TRANSACTION 또는 COMMIT TRANSACTION 문을 실행하여 트랜잭션을 닫아야 합니다. 그렇지 않으면 아래와 같은 오류 3902가 발생합니다.

The commit transaction has no corresponding BEGIN TRANSACTION.
응용 프로그램에서 SELECT @@TRANCOUNT를 보내어 어떤 트랜잭션 중첩 수준이 있는지 확인하는 것이 유용할 수도 있습니다. 그러나 응용 프로그램에서 무조건 SELECT @@TRANCOUNT를 보낸 다음 COMMIT/ROLLBACK을 실행하여 @@TRANCOUNT=0을 얻을 수는 없습니다. @@TRANCOUNT가 응용 프로그램이 예상하는 것과 다르면 응용 프로그램이 트랜잭션 중첩 수준을 추적하는 데 실패했음을 의미하므로 응용 프로그램 설계에 오류가 있는 것입니다. 이 시점에서 COMMIT/ROLLBACK을 실행하면 응용 프로그램은 어떤 트랜잭션이 의도하지 않은 트랜잭션 수준이 되었는지 알지 못하기 때문에 의도하지 않은 트랜잭션이 적용되거나 중단될 수도 있습니다. 대신에 프로그래머는 응용 프로그램 및 관련된 저장 프로시저(stored procedure)를 디버깅하여 의도하지 않은 트랜잭션 수준의 원인을 알아내야 합니다.
네트워크 연결 끊김을 SQL Server에 알리지 않는 네트워크 오류: 사용자 정의 트랜잭션이 실행되는 동안 클라이언트 워크스테이션이 응답하지 않거나 다시 부팅되거나 종료되면 네트워크 계층에서 SQL Server에 이 사실을 알려야 합니다. 네트워크가 적절하게 이 사실을 알려주지 않으면 SQL Server에게는 클라이언트가 여전히 존재하는 것처럼 보이기 때문에 클라이언트가 열어 놓은 트랜잭션이 계속 유지됩니다. 이는 네트워크 문제이므로 네트워크를 조사해야 합니다. 관리자가 sp_who, sp_lock 또는 네트워크 유틸리티를 사용하여 여전히 존재하는 클라이언트 세션을 확인한 다음 수동으로 제거함으로써 이 문제를 해결할 수 있습니다.
차단으로 인해 커밋되지 않은 트랜잭션: 다중 사용자 환경에서는 열려 있는 트랜잭션이 다른 프로세스가 설정한 잠금(Lock)에 의해 차단될 수 있습니다. 이 경우 트랜잭션이 계속 열려 있어 로그를 자르지 못하게 합니다. 이 문제를 확인하려면 프로그래머 또는 데이터베이스 관리자가 sp_who, sp_lock 또는 기타 도구를 사용하여 동시성 환경을 분석해야 합니다. 대부분의 경우 적절한 쿼리, 인덱스 및 데이터베이스 설계를 통해 차단 문제를 줄이거나 없앨 수 있습니다.
데이터 수정 쿼리를 취소하는 데 실패: 응용 프로그램이 dbcancel()을 실행했으나 네트워크 또는 SQL 문제로 인해 쿼리가 취소되지 않으면 쿼리는 계속 실행되고 트랜잭션은 열린 상태를 유지합니다. 이 문제가 의심스러우면 sp_who를 사용하여 쿼리가 취소되었는지 확인합니다. TCP/IP 소켓 클라이언트에서 취소를 시도하는 경우에는 명명된 파이프(Named Pipe) 클라이언트에서 테스트를 수행하거나 로컬 파이프를 사용하여 서버 컴퓨터에서 클라이언트 응용 프로그램을 실행합니다. 이 방법은 쿼리가 취소되지 않은 것이 네트워크 문제 때문인지 SQL 문제 때문인지 구분하는 데 도움이 됩니다.
검사점(Checkpoint) 처리기 잘라내기 대역폭 초과: 로그는 60초마다 잘리지만 이 잘라내기 속도는 제한적입니다. 이 시나리오는 일반적이지 않으므로, 먼저 기타 가능한 로그 오버플로의 원인을 고려하여 배제한 후 이 시나리오에 해당하는지 검사해야 합니다. 그러나, 많은 클라이언트가 동시에 대량 업데이트를 수행하면 최대 잘라내기 속도보다 로그가 차는 속도가 더 빠를 수 있습니다. 이는 액체를 일정한 속도로만 배출할 수 있는 깔대기를 사용할 때 배출하는 동안에도 액체가 넘칠 수 있는 것과 유사합니다. 이 시나리오에 해당하면 업데이트되는 행의 수를 줄이도록 응용 프로그램을 다시 구성할 수 있습니다. 업데이트되는 행의 수를 줄이는 것은 항상 모든 관계형 데이터베이스의 기본 설계 목표가 되어야 합니다.

이 방법으로 해결할 수 없으면 스트라이핑, 추가 컨트롤러 등을 통해 디스크 I/O 대역폭을 늘리도록 시스템을 재구성할 수 있습니다. 이 경우에는 일반적으로 검사점(Checkpoint) 처리기 프로세스가 로그 잘라내기를 계속 시도하면서 DUMP TRANSACTION 상태에서 점점 더 많은 시간을 소모하는지 확인합니다. 잘라내기 임계값을 초과하고 나면(아래 참조) 로그를 지울 때까지 검사점(Checkpoint) 처리기가 해당 데이터베이스에서 잘라내기를 시도하는 것을 보지 못할 수도 있습니다.
잘라내기 임계값 초과: 검사점(Checkpoint) 처리기는 기본적으로 DUMP TRANSACTION WITH TRUNCATE_ONLY를 수행합니다. 로그가 이미 특정 지점까지 가득 찼으면 수동으로 실행했을 때처럼 덤프가 항상 성공하지는 않습니다. 예를 들어, 검사점(Checkpoint) 처리기가 로그를 잘라낸 후 다음에 다시 잘라내기 전에 많은 업데이트 작업이 몰려 로그가 95%까지 채워질 수 있습니다. 검사점(Checkpoint) 처리기가 잘라내기를 시도할 때는 로그가 완전히 채워지지는 않았지만 거의 가득 차서 잘라내기가 불가능할 수도 있습니다. 이 때 잘라내기를 수행할 수 없는 이유는 로그 잘라내기 자체를 로그에 기록해야 하기 때문입니다. 이 경우 유일한 해결 방법은 DUMP TRANSACTION WITH NO_LOG를 사용하여 수동으로 로그를 잘라내는 것입니다. NO_LOG 옵션을 사용하는 것은 로그에 기록되지 않는 작업이기 때문에 이 작업을 하는 동안 시스템에 오류가 발생하면 데이터베이스 오류로 이어질 수 있으므로, 반드시 필요한 경우가 아니면 NO_LOG 옵션을 사용하지 않는 것이 좋습니다.
위 요인들 간 상호 작용: 예를 들어, 업데이트가 많은 환경인 경우 정상 조건에서는 검사점(Checkpoint) 처리기 잘라내기 속도에서 로그가 가득 채워지지 않습니다. 예를 들어, 잠금(Lock) 경쟁 같은 위 조건 중 하나에 의해 일시적으로 열린 트랜잭션이 로그를 50%까지 채운다고 가정하면 다른 업데이트 상황을 처리하기 위한 공간이 줄어들어 자동 잘라내기가 불가능한 지점인 잘라내기 임계값까지 도달할 가능성이 더욱 커집니다. tempdb 데이터베이스에서의 트랜잭션은 다른 데이터베이스의 경우와 마찬가지로 로그에 기록됩니다. TRUNCATE LOG ON CHECKPOINT는 tempdb에 있기 때문에 대부분의 경우 로그가 잘리고 오버플로가 발생하지 않습니다. 그러나 위에 언급한 상황으로 인해 tempdb 로그가 가득 채워질 수 있습니다. Tempdb는 일반적으로 혼합된 로그 및 데이터(sysusages.segmap=7)를 위해 구성되므로 데이터 작업과 로그 작업이 사용 가능한 동일 공간을 차지하기 위해 경쟁합니다. GROUP BY, ORDER BY DESC 등과 같은 특정 Transact-SQL 구성 요소는 작업 공간을 확보하기 위해 자동으로 tempdb를 요구합니다. 이 트랜잭션은 또한 작업 공간을 위해 tempdb에서 암시적 BEGIN TRANSACTION 레코드를 발생합니다. 이 tempdb 트랜잭션은 사용자 데이터베이스에서 트랜잭션 기간 동안 계속되며 이로 인해 이 기간 동안 tempdb 로그 잘라내기가 지연될 수 있습니다. 잠금(Lock)에 의한 차단 또는 응용 프로그램이 dbnextrow()를 완전히 처리하지 않는 등의 문제로 인해 사용자 데이터베이스에서 트랜잭션이 중단되면 tempdb에서의 트랜잭션이 열린 상태로 남게 되어 tempdb 로그 잘라내기를 방해할 수 있습니다. 프로그래머는 응용 프로그램을 디버깅하고 이 문제를 유발한 동시성 문제를 해결해야 합니다.
SQL Server 7.0 및 2000 클래스 서버에서 트랜잭션 로그 잘라내기는 가상 로그 파일(VLF)을 잘라냄으로써 수행됩니다. 활성 로그의 일부분이 특정 VLF에 있으면 해당 VLF를 잘라낼 수 없습니다. 활성 로그가 모든 VLF에 있으면 해당 로그를 잘라낼 수 없습니다. autogrowth가 사용 가능하게 설정되어 있고, 트랜잭션 로그가 있는 볼륨에 공간이 있으며 최대 파일 크기에 도달하지 않았으면 트랜잭션 로그는 로그 파일 등록 정보에 지정된 크기까지 커집니다.
아래에서는 TRUNCATE LOG ON CHECKPOINT의 설정 여부에 따라 SQL을 시작할 때의 로그 잘라내기 동작을 설명합니다.
TRUNCATE LOG ON CHECKPOINT를 설정했고 시작할 때 로그가 가득 차있으면 no_log를 사용하여 로그가 자동으로 덤프됩니다.
마스터 데이터베이스의 로그를 별도의 장치에 넣으면 로그가 로드될 수 없기 때문에 이제 마스터 데이터베이스에서는 TRUNCATE LOG ON CHECKPOINT가 기본값입니다. 가능한 옵션은 로그가 가득 찼을 때 삭제하는 것 뿐입니다.
TRUNCATE LOG ON CHECKPOINT를 설정하지 않았고 시작할 때 로그가 가득 차지 않았으면 복구는 완료되지만 최종 검사점(Checkpoint)이 작성되지 않습니다. 관리자는 데이터베이스에 액세스하여 no_truncate로 로그를 덤프하여 데이터를 저장한 다음 no_log로 덤프하여 로그를 제거하거나 덤프 작업 없이 바로 제거할 수 있습니다.


참조

SQL Server 2000에 대한 자세한 내용은 다음 서적을 참조하십시오.

Microsoft Corporation Microsoft SQL Server 7.0 System Administration Training Kit Microsoft Press, 2001

Microsoft Corporation MCSE Training Kit: Microsoft SQL Server 2000 System Administration Microsoft Press, 2001

Microsoft Corporation Microsoft SQL Server 2000 Resource Kit Microsoft Press, 2001

자세한 내용은 다음 Microsoft 교육 및 인증 과정을 참조하십시오.
Microsoft Corporation 2072 Administering a Microsoft SQL Server 2000 Database

SQL Server 7.0 이후 버전과 관련된 문제는 Microsoft 기술 자료의 다음 문서를 참조하십시오.
317375 INF: SQL Server에서 트랜잭션 로그가 예기치 않게 커지거나 가득 찬다

실행 중인 SQL Server 2000의 버전을 확인하는 방법

실행 중인 SQL Server 2000의 버전을 확인하려면 쿼리 분석기를 사용하여 SQL Server 2000에 연결한 다음 아래의 코드를 실행하십시오.

SELECT SERVERPROPERTY('productversion'), SERVERPROPERTY ('productlevel'), SERVERPROPERTY ('edition')


실행 결과는 다음과 같습니다.

제품 버전(예: 8.00.534).
제품 수준(예: "RTM" 또는 "SP2").
에디션(예: "Standard Edition").

예를 들어 아래와 유사한 실행 결과가 나타납니다.

8.00.534 RTM Standard Edition

아래 표는 Sqlservr.exe 버전 번호를 나열한 것입니다.

릴리스 Sqlservr.exe
RTM 2000.80.194.0
SQL Server 2000 SP1 2000.80.384.0
SQL Server 2000 SP2 2000.80.534.0
SQL Server 2000 SP3 2000.80.760.0


실행 중인 SQL Server 7.0의 버전을 확인하는 방법

실행 중인 SQL Server 7.0의 버전을 확인하려면 쿼리 분석기를 사용하여 SQL Server 7.0에 연결한 다음 아래의 코드를 실행하십시오.

SELECT @@VERSION

아래와 유사한 실행 결과가 나타납니다.

Microsoft SQL Server 7.00 - 7.00.623 (Intel X86)
Nov 27 1998 22:20:07
Copyright (c) 1988-1998 Microsoft Corporation
Desktop Edition on Windows NT 5.1 (Build 2600: )

참고: 이 예에서 버전 번호는 7.00.623입니다.

다음 표의 버전 번호를 사용하여 제품 또는 서비스 팩 수준을 확인합니다.

버전 번호 서비스 팩
7.00.1063 SQL Server 7.0 서비스 팩 4(SP4)
7.00.961 SQL Server 7.0 서비스 팩 3(SP3)
7.00.842 SQL Server 7.0 서비스 팩 2(SP2)
7.00.699 SQL Server 7.0 서비스 팩 1(SP1)
7.00.623 SQL Server 7.0 RTM(Release To Manufacturing)


제일 빠른 방법은 SQL 도구모음에서 엔터프라이즈 관리자(EM)에서 해당 서버의 등록정보를 확인해 보시면

설치 되어 있는 서비스 팩의 정보가 나타납니다.

MS-SQL2000에서 로그가 꽉차서 작업이 불가능시에

로그를 잘라내어 문제를 해결하는 방법입니다.

SQL query 분석기를 실행시키고 'backup log DB명 with truncate_only'문을 사용하여

로그를 삭제할 수 있습니다.

DB명변경 명령어는 sp_renamedb '현재디비명', '새 디비명' 입니다.

하지만 제약 조건이 있습니다.

먼저 해당하는 DB에 Single user모드가 설정 되어야 합니다.

이를 위해서는

USE master
EXEC sp_dboption '디비명', 'single user', 'true'

하시면 됩니다. 만약 사용자가 있어 수행이 불가하다는 메세지가 나온다면?

sp_who로 누가 해당하는 DB에 붙어 있는지 보시고.. 해당하는 사용자의 spid번호를

기억하신후..

kill spid번호

명령으로 죽이신후 해 보시길 바랍니다.

싱글유져가 되었다면..

sp_renamedb를 수행하시길 바랍니다.

예제
다음은 accounting 데이터베이스의 이름을 financial로 바꾸는 예제입니다.

EXEC sp_renamedb 'accounting', 'financial'

수행후 다시 싱글 유져를 필요에 의해 풀어 주시면 되며

TRUE를 FALSE로만 바꾸신후 다시 수행하시면됩니다.