보미네

복잡하게 셋팅해야하는 sqldiag xml 파일을 이제는 툴로 만들어 배포하고 있다.
좀 더 쉽게 성능을 모니터링 할 수 있다.

요런툴 자기만 쓸 수 있다고 편하게 생각하지 말자 툴은 툴이고, 현상을 분석하고 원리를 아는데 투자하는 시간을 많이 가지도록 한다.

뭐 다 알던 기능이라 흥미 있는 기능은 없다.
그래도 스크린샷 구경이나 한번 해보자
사용방법도 너무 쉬워서 아무 설명도 필요 없다. 
그래도 혹시 모르겠으면 소개 Page 의 instruction 을 읽어봐라.

다음은 Coniguration Manager 에서 간단하게 셋팅한 후 분석할 수 있는 스크린 샷이다.

위 툴은 너무 많이 알려줘 아무나 할 수 있다. 그런데, 현상에 대한 분석은 Google 신의 도움이 필요 할 수도 있다. 분석을 위한 시간이 많은 공부가 될 것이다.

이건 예전에 MS 내부 기술지원을 할 때 엔지니어가 셋팅하는 버전으로 있었는데 배포되었다. CASE 번호도 적을수 있도록 되어있다. (이건 좀 지우고 배포하지 -_-) 예전에 MS 내부 분석용 프로그램을 보니 저 넥서스에서 분석한것 외에도 sqldig 의 output 값으로 파싱해 리포트 결과를 보는 다른 툴도 있더라.

회사의 SQL Server 에 문제에 대한 선 분석이 필요하다고 생각되면 MS 에서 SQLRAP 을 받아보는 것도 좋다.

위 Config Manager 를 소개한 링크는 다음 링크를 참고한다.

http://blogs.msdn.com/b/psssql/archive/2011/05/24/pssdiag-sqldiag-configuration-manager-released-to-codeplex.aspx

아래 명령을 쓰면, 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.

v_backup.exe

SQLWriter.doc

VSS
VSS 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 를 쓰지 않는것 같다.

지우든지 index 를 만든다.

1) 인덱스 만들기
Another suggestion to speed up the deletion is to create an index on the media_set_id column in the backupset table. However, modifying system tables should always be done with caution.

2) 지우기
예전에 나두 하나 만들어 두었는데, 저기 있는게 더 좋아 보인다. -_-
http://www.sqlbackuprestore.com/backuprestorehistorytables.htm

백업 및 복원 기록 테이블에서 오래된 행을 삭제하려면

• sp_delete_backuphistory(Transact-SQL)
  
  

백업 및 복원 기록 테이블에서 특정 데이터베이스에 대한 모든 행을 삭제하려면

• sp_delete_database_backuphistory(Transact-SQL)