아래 명령을 쓰면, detach 후 attach 명령으로 붙인 데이터베이스가 norecovery 상태로 되고 이후 수행된 transaction log backup 으로 복구 할 수 있다.
여기에 continue_after_error 옵션도 적용 할 수 있으므로 oracle 과 같이 단순이 split 을 시키고 그다음 바로 복구를 할 수 있다. 그러므로 vdi 를 이용한 복원을 할 필요 없이 단순히 미러 이미지만 만들고 norecovery 상태로 만들 수 있다. 또한 Transaction log backup 도 계속 적용 할 수 있다.
backup log d1 to disk ='c:\d1.bak' with norecovery
use master
go
drop database CopyOnlyRecovery
go
use master
go
create database CopyOnlyRecovery
go
use CopyOnlyRecovery
go
create table tblx
(idx int identity(1,1)
,c1 char(5000)
)
go
insert into tblx values (1)
go 1000
select top 1 * from tblx
go
backup database CopyOnlyRecovery to disk ='c:\f1.bak' with init
go
insert into tblx values (2)
go 1000
backup log CopyOnlyRecovery to disk ='c:\l1.bak' with init
go
select top 1 * from tblx order by c1 desc
go
insert into tblx values (3)
go 1000
select top 1 * from tblx order by c1 desc
checkpoint
go
-- 위와 같은 상황에서 database shutdown 후 copy
-- 정상인 상태로 다시 start 한다.
use CopyOnlyRecovery
go
insert into tblx values (4)
go 1000
backup log CopyOnlyRecovery to disk ='c:\l2.bak' with init
go
insert into tblx values (5)
go 1000
backup log CopyOnlyRecovery to disk ='c:\l3.bak' with init
go
insert into tblx values (6)
go 1000
backup log CopyOnlyRecovery to disk ='c:\l4.bak' with init
go
checkpoint
-- 현재 데이터베이스는 6 까지 들어가 있음
--use CopyOnlyRecovery
--go
--select top 1 * from tblx order by c1 desc
---- 이제부터 예전 copy 한 파일로 부터 복원을 해보자.
--use master
--go
-- ***************************************************
-- 예전에 복사해둔 데이터베이스를 attach 한다.
-- stop
-- copy
-- start
-- select * from tblx 해당 파일에는 3까지 들어있다.
use CopyOnlyRecovery
go
select top 1 * from tblx order by c1 desc-- 3 확인완료
go
use master
go
-- 아래 명령을 날리면 3까지 복원된 상태에서 recovery 된다.
backup log CopyOnlyRecovery to disk = 'c:\fail2.bak' with norecovery , init , COPY_ONLY
go
-- 데이터베이스는 복구중 모드로 변경된다. 여기에서 이후 로그를 어플라이 시킨다.
-- with norecovery
--restore log CopyOnlyRecovery from disk = 'c:\l1.bak' with norecovery , continue_after_error
restore log CopyOnlyRecovery from disk = 'c:\l2.bak' with norecovery , continue_after_error
파일 1에서 데이터베이스 'CopyOnlyRecovery', 파일 'CopyOnlyRecovery'에 대해 0개의 페이지를 처리했습니다 .
파일 1에서 데이터베이스 'CopyOnlyRecovery', 파일 'CopyOnlyRecovery_log'에 대해 1517개의 페이지를 처리했습니다 .
RESTORE WITH CONTINUE_AFTER_ERROR가 성공했지만 약간의 손상이 발생했습니다. 데이터베이스 불일치가 발생할 수 있습니다.
RESTORE LOG이(가) 1517개의 페이지를 0.220초 동안 처리했습니다(53.868MB/초).
메시지 3456, 수준 17, 상태 1, 줄 1
페이지 (1:1), 데이터베이스 'CopyOnlyRecovery'(데이터베이스 ID 22)에서 트랜잭션 ID (0:6813)에 대한 로그 레코드 (35:10242:4)을(를) 다시 실행할 수 없습니다. 페이지: LSN = (35:10200:9), 유형 = 11. 로그: OpCode = 4, 컨텍스트 11, PrevPageLSN: (35:10229:13). 데이터베이스 백업에서 복원하거나 데이터베이스를 복구하십시오.
restore log CopyOnlyRecovery from disk = 'c:\l3.bak' with norecovery , continue_after_error
파일 1에서 데이터베이스 'CopyOnlyRecovery', 파일 'CopyOnlyRecovery'에 대해 0개의 페이지를 처리했습니다 .
파일 1에서 데이터베이스 'CopyOnlyRecovery', 파일 'CopyOnlyRecovery_log'에 대해 759개의 페이지를 처리했습니다 .
RESTORE WITH CONTINUE_AFTER_ERROR가 성공했지만 약간의 손상이 발생했습니다. 데이터베이스 불일치가 발생할 수 있습니다.
RESTORE LOG이(가) 759개의 페이지를 0.110초 동안 처리했습니다(53.848MB/초).
메시지 3456, 수준 17, 상태 1, 줄 1
페이지 (1:2), 데이터베이스 'CopyOnlyRecovery'(데이터베이스 ID 22)에서 트랜잭션 ID (0:8811)에 대한 로그 레코드 (35:22354:4)을(를) 다시 실행할 수 없습니다. 페이지: LSN = (35:10115:4), 유형 = 8. 로그: OpCode = 7, 컨텍스트 8, PrevPageLSN: (35:22257:4). 데이터베이스 백업에서 복원하거나 데이터베이스를 복구하십시오.
restore log CopyOnlyRecovery from disk = 'c:\l4.bak' with norecovery , continue_after_error
파일 1에서 데이터베이스 'CopyOnlyRecovery', 파일 'CopyOnlyRecovery'에 대해 0개의 페이지를 처리했습니다 .
파일 1에서 데이터베이스 'CopyOnlyRecovery', 파일 'CopyOnlyRecovery_log'에 대해 759개의 페이지를 처리했습니다 .
RESTORE WITH CONTINUE_AFTER_ERROR가 성공했지만 약간의 손상이 발생했습니다. 데이터베이스 불일치가 발생할 수 있습니다.
RESTORE LOG이(가) 759개의 페이지를 0.105초 동안 처리했습니다(56.403MB/초).
메시지 3456, 수준 17, 상태 1, 줄 2
페이지 (1:2), 데이터베이스 'CopyOnlyRecovery'(데이터베이스 ID 22)에서 트랜잭션 ID (0:10811)에 대한 로그 레코드 (36:9161:4)을(를) 다시 실행할 수 없습니다. 페이지: LSN = (35:10115:4), 유형 = 8. 로그: OpCode = 7, 컨텍스트 8, PrevPageLSN: (36:9060:4). 데이터베이스 백업에서 복원하거나 데이터베이스를 복구하십시오.
restore log CopyOnlyRecovery from disk = 'c:\fail2.bak' with norecovery
restore database CopyOnlyRecovery with recovery , continue_after_error
메시지 3456, 수준 16, 상태 1, 줄 2
페이지 (1:2), 데이터베이스 'CopyOnlyRecovery'(데이터베이스 ID 22)에서 트랜잭션 ID (0:10811)에 대한 로그 레코드 (36:9161:4)을(를) 다시 실행할 수 없습니다. 페이지: LSN = (35:10115:4), 유형 = 8. 로그: OpCode = 7, 컨텍스트 8, PrevPageLSN: (36:9060:4). 데이터베이스 백업에서 복원하거나 데이터베이스를 복구하십시오.
메시지 3313, 수준 16, 상태 2, 줄 2
데이터베이스 'CopyOnlyRecovery'에 로그된 작업을 다시 실행하는 중 로그 레코드 ID (36:9161:4)에서 오류가 발생했습니다. 일반적으로 특정 실패는 Windows 이벤트 로그 서비스에서 이미 오류로 로그됩니다. 전체 백업에서 데이터베이스를 복원하거나 데이터베이스를 복구하십시오.
복원에 성공했으나 지연된 트랜잭션이 남아 있습니다. 이러한 트랜잭션에는 사용할 수 없는 데이터가 있으므로 해결할 수 없습니다. RESTORE를 사용하여 데이터를 사용 가능하게 만들거나, 이 데이터가 다시 필요하지 않으면 파일 그룹을 삭제하십시오. 파일 그룹을 삭제하면 파일 그룹이 존재하지 않게 됩니다.
RESTORE WITH CONTINUE_AFTER_ERROR가 성공했지만 약간의 손상이 발생했습니다. 데이터베이스 불일치가 발생할 수 있습니다.
RESTORE DATABASE이(가) 0개의 페이지를 4.849초 동안 처리했습니다(0.000MB/초).
메시지 942, 수준 14, 상태 1, 줄 2
데이터베이스 'CopyOnlyRecovery'은(는) 오프라인 상태이므로 열 수 없습니다.
메시지 3013, 수준 16, 상태 1, 줄 2
RESTORE DATABASE이(가) 비정상적으로 종료됩니다.
--offline 상태
stop
start /m
DBCC SHOWFILESTATS
DBCC EXTENTINFO(CopyOnlyRecovery, TBLX, -1)
DBCC TRACEON(3604)
go
DBCC PAGE('CopyOnlyRecovery',1, 1000,2)
EXEC SP_RESETSTATUS 'CopyOnlyRecovery';
alter database CopyOnlyRecovery set emergency
use CopyOnlyRecovery
go
select top 1 * from tblx order by c1 desc
select count(*) from tblx
dbcc checkdb (CopyOnlyRecovery)
use master
go
ALTER DATABASE CopyOnlyRecovery SET SINGLE_USER WITH ROLLBACK IMMEDIATE
go
dbcc checkdb ('CopyOnlyRecovery', repair_allow_data_loss)
go
alter database CopyOnlyRecovery set multi_user
use CopyOnlyRecovery
go
select * from tblx
select * from tblx
restore database d1 with recovery
현재 나타나고 있는 현상은
Holding a database frozen for long periods of time may result in server-wide effects. This is particularly true for SQL Server 2000. In SQL Server 2005, background operations such as the lazy writer and checkpoint processes have been improved to avoid some of this "freeze spillover" effect.
VSS
v_backup.exe
SQLWriter.docVSS is basically a framework that consists of a set of functions that enable applications to perform backups of volumes.
Writer
Writers are applications that store information on disk and that work together with providers through the VSS interface.
SQL Server has 2 writers available:-
1) MSDE Writer - MSDEWriter works with SQL Server 7.0, SQL Server 2000, and SQL Server 2005.
2) SQL Writer - SqlServerWriter only works with instances of SQL Server 2005.
두개중 어떤것을 쓰고 있는지 확인해 봐야 한다.
확인해 보려는 근거는 아래와 같다.
|
A VSS writer (MSDE Writer) shipped with the VSS framework in Microsoft Windows XP and Microsoft Windows Server 2003. This writer coordinates with SQL Server 2000 and earlier versions to help in backup operations. Starting with SQL Server 2005 installation, SQL Writer is the preferred writer, though MSDE Writer will continue to work and will be the default writer if installed and SQL Writer is not enabled. To start and use the SQL Writer, first disable the MSDE writer from enumerating SQL Server 2005 databases. |
SQL Writer 설명에 보면,
http://msdn.microsoft.com/en-us/library/ms175536.aspx
The VSS is a set of COM APIs that implements a framework to allow volume backups to be performed while applications on a system continue to write to the volumes.
2008 이니 SQL Writer 일것 같은데.......그럼 Write 가 계속 가능한거 아닌가? 부작용이 있을수 있군...
http://technet.microsoft.com/en-us/library/bb795744.aspx 에 보면 WRITER 를 선택하는 REGI 값을 찾을 수 있다.
http://support.microsoft.com/kb/919023/en-us
Even though SqlServerWriter is installed with SQL Server 2005, it is not configured as the default writer for SQL Server 2005. You must manually configure SqlServerWriter as the default writer. 이런말이 있어 찾아 볼려고 한다. -_- 근데 7 에서는 기본값 이네..
1.
Creation of a Snapshot 파트에서는 the application receives a command to perform the snapshot. To prevent torn pages, writes to the database files are suspended within Microsoft® SQL Server™ until this command completes or aborts 라고 기술되어 있다. 그럼 log 파일에 하나도 기록 못한다는 소린데....... TEST 해봐야 알겠다.
2.
또한 VDF_SnapshotPrepare bit 가 설정되면, 볼륨의 여러 데이터베이스를 한번에 Snapshot 할 수 있다고 한다. 이건 설정되면 안될듯 하다. 여러 데이터베이스에서 한번에 동기화를 맞출려면 시간이 더 오래 걸릴 수 있을듯 하다. bit 값을 확인해 본다.
3.
The duration of the snapshot is the length of time between SQL Server's issuance of the snapshot command to the snapshot provider, and the return of a successful completion indication. Writes to the database files being captured are suspended for the duration of the snapshot operation. Hence, the snapshot must be completed as quickly as possible in order to avoid impact on SQL Server users.
Provider
Providers own the shadow copy data and instantiate the shadow copies.
VDI
SQL Server provides application programming interfaces (API's) that enable an ISV to integrate SQL Server into its products. These specifications are available publicly for third-party vendors to develop backup solutions. Some popular ones include Symantec NetBackup, SQL Litespeed, Legato etc.
VDI 개념도
http://www.sqlbackuprestore.com/3rdpartybackupapps_vdi.htm
CASE
http://blogs.msdn.com/b/psssql/archive/2009/03/03/how-it-works-sql-server-vdi-vss-backup-resources.aspx
VDI 를 통해 백업을 할때 데이터베이스마다 3개의 Thread 가 동작한다. 그런데 데이터베이스가 500개이다.
그럼 1500개의 Thread 가 필요하다
라고 CASE 가 Open 되었고, 결론은 Worker Therad 를 늘여라 라고 나왔고 다음 버전에서는 이 비효율을 고려하겠다라고 한다.
그런데, 두둥...Copy-on-Write 기술과 Split/Mirror 기술의 차이점은 무엇을까? 두둥 HDS HtPM 은 Split 을 하기 때문에 Write 를 못하고 EMC 솔루션은 가능한가? 이게 만약 Write 를 못한다고 한다면 해당 솔루션은 문제인데...라고 처음에 생각했는데.....SQL 이 아예 차단하는데 API 가 무슨수로 쓴단 말인가? 라는 생각도 든다.....단지 Snapshot 의 속도만 차이가 날 뿐 이라고 생각된다. 근본 Snapshot 의 속도를 빠르게 하는 수 밖에 없다. Universal Replicator 2분이나 걸려야 하나....MS 권고값은 10초 이하로 되어 있다. ShadowCopy 는 3초 였는데...ㅠ.ㅠ
그리고 MSDEWriter 와 SQLWriter 가 있다고 하는데 우리는 뭘 쓰고 있을까?
vssadmin list writers 한번 때려보고 싶다.
누군가 내가 하고 싶은 질문을 똑같이 한 것이 있다 저 위에 API 를 이용한 백업 말고 진정한 H/W 를 이용한 백업과 SQL Server 의 복구 기능만을 이용해서 백업 한다는 계획이다. 이런면에서 Oracle 은 넘사벽인듯 하다.
Oracle 은 Archive Log 로 부터 DB 를 동기화 해 올릴 수 있는 방법이 있는데, SQL Server 는 없는것 같다. 아 씨봉~
Oracle 은 begin backup 을 하면 log 를 다른방식으로 생성 한다고 한다. 그런데 SQL Server 는 테스트 해보니 backup 상태에서도 로그가 같다. 그렇기 때문에 split 밖에 선택할 수 없는 것인가? by design 이라면 최악이다. 사람들이 갈수록 구멍이란다.
I have implemented Split Mirror backups in many locations for Oracle and a few for DB2. I have a number of clients wanting to do this with SQL Server as well. Oracle has the ability to quisce the database and bring the log files current via RMAN scripts. I can not find a similar way to do this with SQL Server, but have found references to the VDI process. I am comfortable programming in C# and VB, is there a way to call these APIs in .NET? If so do you know of any samples that are available? A vbscript process would be the preferred solution for most of my clients though. Thanks for any info you may have
I have same issue like kds facing. We have requirement to do split/mirror backup and we would like put SQL database in backup mode or quies mode before splitting disks. How do we do that ? Oracle/SAP/Informix etc.. database easy to handle with Split mirror and I am struggling with SQL method. Any advice will be greatly appreciated
짜슥들 맛보기 함 해보삼 글
http://blogs.msdn.com/b/sqlserverfaq/archive/2009/04/28/informational-shedding-light-on-vss-vdi-backups-in-sql-server.aspx
METADATA 에 들어있는 정보 (LOG SEQUENCE 번호 같은거 없구만.....)
Writer Metadata Document: An Example
Given an example database named DB1, which belongs to SQL Server instance Instance1 on machine Server1, and which contains the following database/log files:
• Database file named “primary” stored at c:\db\DB1.mdf
• Database file named “secondary” stored at c:\db\DB1.ndf
• Database log file named “log” stored at c:\db\DB1.ldf
• Full-text catalog named “foo” stored under the directory c:\db\ftdata\foo
• Full-text catalog named “bar” stored under the directory c:\db\ftdata\bar.
Following is the database’s writer metadata:
Database level filegroup component
• ComponentType: VSS_CT_FILEGROUP
• LogicalPath: “Server1\Instance1”
• ComponentName: “DB1”
• Caption: NULL
• pbIcon: NULL
• cbIcon: 0
• bRestoreMetadata: FALSE
• NotifyOnBackupComplete: TRUE
• Selectable: TRUE
• SelectableForRestore: TRUE
• ComponentFlags: VSS_CF_APP_ROLLBACK_RECOVERY
Filegroup file
• LogicalPath: “Server1\Instance1”
• GroupName: “DB1”
• Path: “c:\db”
• FileSpec: “DB1.mdf”
• Recurisve: FALSE
• AlternatePath: NULL
• BackupTypeMask: VSS_FSBT_ALL_BACKUP_REQUIRED | VSS_FSBT_ALL_SNAPSHOT_REQUIRED
Filegroup file
• LogicalPath: “Server1\Instance1”
• GroupName: “DB1”
• Path: “c:\db”
• FileSpec: “DB1.ndf”
• Recursive: FALSE
• AlternatePath: NULL
• BackupTypeMask: VSS_FSBT_ALL_BACKUP_REQUIRED | VSS_FSBT_ALL_SNAPSHOT_REQUIRED
Filegroup file
• LogicalPath: “Server1\Instance1”
• GroupName: “DB1”
• Path: “c:\db”
• FileSpec: “DB1.ldf”
• Recursive: FALSE
• AlternatePath: NULL
• BackupTypeMask: VSS_FSBT_ALL_BACKUP_REQUIRED | VSS_FSBT_ALL_SNAPSHOT_REQUIRED
Filegroup file:
• LogicalPath: “Server1\Instance1”
• GroupName: “DB1”
• Path: “c:\db\ftdata\foo”
• FileSpec: “*”
• Recursive: TRUE
• AlternatePath: NULL
• BackupTypeMask: VSS_FSBT_ALL_BACKUP_REQUIRED | VSS_FSBT_ALL_SNAPSHOT_REQUIRED
Filegroup file:
• LogicalPath: “Server1\Instance1”
• GroupName: “DB1”
• Path: “c:\db\ftdata\bar”
• FileSpec: “*”
• Recursive: TRUE
• AlternatePath: NULL
• BackupTypeMask: VSS_FSBT_ALL_BACKUP_REQUIRED | VSS_FSBT_ALL_SNAPSHOT_REQUIRED
Note that if the server instance is the default instance on the machine, the logical path becomes one part – “Server1”.
1.
어제 넘 과로를 해서 이야기의 포인트를 잊어 버렸다..... 늙으면 죽어야지....에혀~
freeze unfreeze 과정에서 meta 파일이 있어야지 norecovery 모드로 만들 수 있다.
이 meta 파일이 없어 norecovery 로 만들수 있냐는 것이 질문이였는데....바보같이...ㅠㅗㅠ
MS 의 일반적인 복구 절차로는 없다라는 답변을 받았다......없는줄 알고 있다. 돌아삐겠다.
HDS 에서 어떻게 구현했는지 모림......
2.
Meta 파일에 들어가는 정보를 정확하게 받아야 한다.
3.
COW 가 Split/Mirror 보다 훨씬 빠른것 같고 HDS 에서는 COW 를 쓰지 않는것 같다.