SP4를 설치하고, 아래에서 핫픽스를 설치하여 더욱 안전한 데이터베이스로 유지 하자.
http://support.microsoft.com/?kbid=894905
SELECT SERVERPROPERTY('productversion'), SERVERPROPERTY ('productlevel'), SERVERPROPERTY ('edition')SQL 2000
SELECT SERVERPROPERTY('productversion'), SERVERPROPERTY ('productlevel'), SERVERPROPERTY ('edition')
SELECT @@VERSION
쿼리문은 다음과 같다.
--1단계위의 쿼리를 실행시키면 아래와 같은 결과값을 볼 수 있다.
Restore FileListOnly
from Disk = 'c:\GOSLDW'
go
--2단계
restore database GOSLDW
from disk = 'c:\GOSLDW'
with move 'GOSLDW_Data' TO 'C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data\GOSLDW_Data.MDF',
MOVE 'GOSLDW_Log' TO 'C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data\GOSLDW_Log.ldf',
stats = 10
go
--3단계
sp_helpdb GOSLDW
go
EXEC sp_dbcmptlevel 'GOSLDW', '90'
go
sp_helpdb GOSLDW
go
MSX 서버에서 온 작업이나 그단계 또는 일정을 추가 업데이트 삭제할 수 없습니다
해결
/*srvid = 0 srvname='LEETEST'*/
use master
select * from sysservers
/*originating_server='WEBTEST' 를 'LEETEST'로 수정해서 해결함.' */
use msdb
select * from sysjobs
EXEC sp_configure 'allow updates', 1
Update sysjobs
set originating_server = 'LEETEST'
EXEC sp_configure 'allow updates', 0
이러한 메시지가 뜰 것입니다.
"MAX 서버에서 온 작업 이나 그단계 또는 일정을 추가 업데이트 삭제할 수 없습니다."
"DEVPIA에서 찾은 QNA를 발췌하겠습니다.
========================================================
이 문제는 SQL2000의 특성으로 인해 발생하는 문제입니다.
모든 scheduling job들은 ‘msdb..sysjobs’ 시스템 테이블에 저장됩니다.
sysjobs 테이블에는 ‘originating_server’ 칼럼이 존재하고 이 칼럼에는 job이 생성된 server의 이름이 저장됩니다.
SQL7.0에서는 ‘originating_server’ 칼럼에 항상 ‘(local)’ 값이 저장되기 때문에 Server의 이름을 변경해도 영향을 받지 않습니다. 하지만, SQL2000에서는 Multiple Instance가 지원되기 때문에 ‘originating_server’ 칼럼에 실제 SQL Server의 instance명이 저장되게 됩니다.
만일, Server의 이름이 변경되면 현재의 Server명과 msdb..sysjobs’ 테이블에 저장된 ‘originating_server’의 값이 다르기 때문에 job 변경/삭제시 14274에러가 발생하게 됩니다.
다음의 쿼리를 실행하여 jon 변경/삭제시 발생하는 에러를 없앨 수 있습니다.
update msdb..sysjobs set originating_server = ‘<new server>’
where originating_server = ‘<old server>’
만일, Named Instance를 사용하는 job이라면 다음의 쿼리를 실행합니다.
update msdb..sysjobs set originating_server = ‘<new server>\<instance>’
where originating_server = ‘<old server>\<instance>’
참고적으로 ‘select * from msdb..sysjobs’ 쿼리를 실행한 다음 originating_server 칼럼을 확인하여 모든 job들에 대해 설정되어 있는 SQL Server명을 확인할 수 있습니다.
========================================================
이렇게 수행하셔도 되고
EM을 열고 직접 msdb 가셔서 모든 행 반환해서 수정하셔도 같은 결과가 나올겁니다.
MSDN을 참고하면 SQL 백업/복구를 위한 많은 정보들을 찾을 수 있다.
그 중에 몇 가지들을 살펴 보자.
SQL Server에서의 백업 개요
http://msdn2.microsoft.com/ko-kr/library/ms175477.aspx
SQL Server에서의 백업 복원 및 복구 작동 방법 이해
http://msdn2.microsoft.com/ko-kr/library/ms191455.aspx
SQL Server의 백업 및 복원 성능 최적화
http://msdn2.microsoft.com/ko-kr/library/ms190954.aspx
SQL Server의 백업 및 복원 전략 소개
http://msdn2.microsoft.com/ko-kr/library/ms191239.aspx
백업 및 복원 방법 도움말 항목(Transact-SQL)
http://msdn2.microsoft.com/ko-kr/library/aa337534.aspx
하나의 테이블에 부모와 자식 값이 있다. 이것을 조인을 사용하여 부모와 자식 값을 연결 해준다. 그리고 결과값은 아래와 같이 나와야 한다.
--------------------------------------
PIDX | LORDER | TITLE
---------------------------------------
null 1 T1
1 1 T1-1
1 2 T1-2
1 3 T1-3
null 2 T2
2 1 T2-1
2 2 T2-2
그럼 PIDX와 LORDER을 기준으로 정렬을 하고 가상의 컬럼을 하나 추가해 PIDX와 같은 겂으로 넣어주고 NULL일때만 LORDER 값을 넣어 주면 된다.
CREATE TABLE TEST1 (
[IDX] [int] IDENTITY (1, 1) NOT NULL primary key clustered,
[PIDX] [INT]NULL , ------ 부모 IDX
[LORDER] [TINYINT] NOT NULL , ----------- 동일 부모의 자식들간의 출력순서
[TITLE] [varchar] (50) NOT NULL
)
go
INSERT INTO TEST1 values(null, 1, 'T1')
INSERT INTO TEST1 values(null, 2, 'T2')
INSERT INTO TEST1 values(1, 1, 'T1-1')
INSERT INTO TEST1 values(1, 2, 'T1-2')
INSERT INTO TEST1 values(1, 3, 'T1-3')
INSERT INTO TEST1 values(2, 1, 'T2-1')
INSERT INTO TEST1 values(2, 2, 'T2-2')
go
방법
select distinct a.pidx , a.lorder, a.title, order_IDX = case a.pidx when null then a.lorder else a.pidx end
from test a
left outer join test b on b.pidx = a.lorder
order by order_idx , lorder asc