블로그 이미지
010-9967-0955 보미아빠

카테고리

보미아빠, 석이 (500)
밥벌이 (16)
싸이클 (1)
일상 (1)
Total
Today
Yesterday

달력

« » 2024.4
1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30

공지사항

최근에 올라온 글


누군가 tempdb 가 이상해요 라고 연락이 왔다. 아래 문서와 쿼리를 이용해 문제를 해결한다.



tempdb 를 core 수만큼 만드는 것은 tempdb 유지관리 비용으로 인해 allocation contention 해결 비용보다 더 클 수 도 있다는 설명도 들어있는 좋은 문서이다. workload 에 따라서 튜닝방법은 달라져야 한다. 
 



CREATE database perf_warehouse
GO
USE perf_warehouse
GO

CREATE TABLE tempdb_space_usage (
  -- This represents the time when the particular row was
  -- inserted
  dt datetime DEFAULT CURRENT_TIMESTAMP,
  -- session id of the sessions that were active at the time
  session_id int DEFAULT null,
  -- this represents the source DMV of information. It can be
  -- track instance, session or task based allocation information.
  scope varchar(10), 
  -- instance level unallocated extent pages in tempdb
  Instance_unallocated_extent_pages bigint,
  -- tempdb pages allocated to verstion store
  version_store_pages bigint,
  -- tempdb pages allocated to user objects in the instance
  Instance_userobj_alloc_pages bigint,   
  -- tempdb pages allocated to internal objects in the instance
  Instance_internalobj_alloc_pages bigint,
  -- tempdb pages allocated in mixed extents in the instance
  Instance_mixed_extent_alloc_pages bigint,
  -- tempdb pages allocated to user obejcts within this sesssion or task.
  Sess_task_userobj_alloc_pages bigint,   
  -- tempdb user object pages deallocated within this sesssion
  -- or task.
  Sess_task_userobj_deallocated_pages bigint,
  -- tempdb pages allocated to internal objects within this sesssion
  -- or task
  Sess_task_internalobj_alloc_pages bigint,
  -- tempdb internal object pages deallocated within this sesssion or
  -- task
  Sess_task_internalobj_deallocated_pages bigint,   
  -- query text for the active query for the task 
  query_text nvarchar(max) 
)
go

-- Create a clustered index on time column when the data was collected
CREATE CLUSTERED INDEX cidx ON tempdb_space_usage (dt)
go

 

 

아래 프로시저를 주기적으로 돌려 tempdb 문제를 일으키는 쿼리를 찾는다.

CREATE PROC sp_sampleTempDbSpaceUsage AS
  -- Instance level tempdb File space usage for all files within
  -- tempdb
  INSERT tempdb_space_usage (
    scope,
    Instance_unallocated_extent_pages,
    version_store_pages,
    Instance_userobj_alloc_pages,
    Instance_internalobj_alloc_pages,
    Instance_mixed_extent_alloc_pages)
  SELECT
    'instance',
    SUM(unallocated_extent_page_count),
    SUM(version_store_reserved_page_count),
    SUM(user_object_reserved_page_count),
    SUM(internal_object_reserved_page_count),
    SUM(mixed_extent_page_count)
  FROM sys.dm_db_file_space_usage
   
    -- 2. tempdb space usage per session
    --
  INSERT tempdb_space_usage (
    scope,
    session_id,
    Sess_task_userobj_alloc_pages,
    Sess_task_userobj_deallocated_pages,
    Sess_task_internalobj_alloc_pages,
    Sess_task_internalobj_deallocated_pages)
  SELECT
    'session',
    session_id,
    user_objects_alloc_page_count,
    user_objects_dealloc_page_count,
    internal_objects_alloc_page_count,
    internal_objects_dealloc_page_count
  FROM sys.dm_db_session_space_usage
    WHERE session_id > 50

    -- 3. tempdb space usage per active task
    --
  INSERT tempdb_space_usage (
    scope,
    session_id,
    Sess_task_userobj_alloc_pages,
    Sess_task_userobj_deallocated_pages,
    Sess_task_internalobj_alloc_pages,
    Sess_task_internalobj_deallocated_pages,
    query_text)
  SELECT
    'task',
    R1.session_id,
    R1.user_objects_alloc_page_count,
    R1.user_objects_dealloc_page_count,
    R1.internal_objects_alloc_page_count,
    R1.internal_objects_dealloc_page_count,
    R3.text
  FROM sys.dm_db_task_space_usage AS R1
    LEFT OUTER JOIN
    sys.dm_exec_requests AS R2
    ON R1.session_id = R2.session_id
    OUTER APPLY sys.dm_exec_sql_text(R2.sql_handle) AS R3
  WHERE R1.session_id > 50


Posted by 보미아빠
, |


언제? 어떤 호스트에서? 어떤 프로그램을 이용해서? 호스트의 프로세스 아이디는? 로그인 네임은 뭘로? text 는 뭐야?

아래 그림을 보면 음...... 이제 다 찾았습니다. 
용서를 할지.....로그인 기록부터 뒤져서....기때기를 때릴지...


if object_id('tbl_audit') is not null
 drop table tbl_audit
 go
 
create table tbl_audit
(eventtime datetime
 ,hostname varchar(100)
 ,program_name varchar(100)
 ,hostprocess int
 ,loginame varchar(100)
 ,text varchar(max))
 go
 
if object_id ('tblx') is not null
 drop table tblx
go
 
create table tblx
(idx int identity(1,1)
 ,c1 int)
 go
 
insert into tblx values (1)
 go 100
 
 
 
if object_id('tr_delete_tblx') is null
exec ('create trigger tr_delete_tblx on tblx after delete as select 1')
 go
 
alter trigger tr_delete_tblx
on tblx
after delete
as
 if @@rowcount > 0 begin
 set nocount on  -- trigger 에서는 주의!

 declare @buffertext table
 (eventtype varchar(100),parameters varchar(100),eventinfo nvarchar(max))
  declare @text nvarchar(max)
 
 insert into @buffertext exec('dbcc inputbuffer('+@@spid+')')
  select @text = eventinfo from @buffertext
 
 insert into tbl_audit (eventtime, hostname, program_name, hostprocess, loginame, text)
  select getdate() eventime, hostname, program_name, hostprocess, loginame, @text text
   from master.dbo.sysprocesses a
   where a.spid = @@spid
end
 go
 
delete from tblx where idx = 10
 go
 
select * from tblx
select * from tbl_audit


 

Posted by 보미아빠
, |


복잡하게 셋팅해야하는 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

Posted by 보미아빠
, |

VDI VSS

카테고리 없음 / 2011. 6. 18. 00:04

아래 명령을 쓰면, 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
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 를 쓰지 않는것 같다.

Posted by 보미아빠
, |

지우든지 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)
Posted by 보미아빠
, |


http://www.sqlbackuprestore.com/introduction.htm

이 사이트에 다 있다고 본다. 이거 번역해서 책으로 내면 좋을듯 하다.
대단한 분인듯.....

Backup 시 Disk SubSystem 의 Read Performance 를 측정하고 싶다는 욕구가 생기는가?
다음 command 를 사용해 봐라

backup database db1 to disk ='NUL' with copy_only

파일 1에서 데이터베이스 'db1', 파일 'DB1'에 대해 10184개의 페이지를 처리했습니다 .
파일 1에서 데이터베이스 'db1', 파일 'DB1_log'에 대해 1개의 페이지를 처리했습니다 .
BACKUP DATABASE이(가) 10185개의 페이지를 0.397초 동안 처리했습니다(200.427MB/초).

내 로컬 컴퓨터의 백업 읽기 속도이다. (SSD 임 -_-)

이런 유용한 명령어 뿐만 아니라. VDI 를 이용한 3rd Party Com 프로그램의 내용도 기술되어 있다.
하여간 내가본 Backup Restore 의 최강 사이트이다.

백업 후 설정이 어떻게 되어 있는지 확인 할려면!

DBCC TRACEON (3604, -1)
DBCC TRACEON (3605, -1)
DBCC TRACEON (3213, -1)

 

Posted by 보미아빠
, |

restore verifyonly 를 하면 100% 복구 가능한가?
아니다.
그럼 확실한 방법은 뭔가?
실제로 restore 한 후 checkdb 를 수행하는 것 뿐이다.
근거는 뭔가?
http://www.yohz.com/help/sqlverify/howreliableisrestoreverify.htm 읽어봐라
Posted by 보미아빠
, |

DBCC FORCEGHOSTCLEANUP
● (dbname|id)
● Used to force all ghost records in a database to be cleaned up
● Very useful to reclaim space without having to do index rebuilds\

등의 명령어 설명

Posted by 보미아빠
, |
http://www.remotedbaexperts.com/Blog/2011/03/undocumented-trace-flags-inside-the-restore-process/

SQL Server supports numerous commands, most of which are extremely well documented with detailed examples provided in “Books on Line.” However, there are quite a few that were left out of the official documentation and remain unsupported by Microsoft.

You’ll find references regarding these in blogs across the Internet and some are more useful than others. Obviously, these are unsupported commands and should only be used with great care.

TRACE FLAGS

There are quite a few undocumented trace flags in SQL Server. However, I’m only going to touch on four today. They are trace flags 3004, 3014 3604 and 3605.

These can be enabled for the current session with the following commands:

– Enable the trace flags

DBCC TRACEON(3004);

DBCC TRACEON(3014);

DBCC TRACEON(3604);

DBCC TRACEON(3605);

GO

These trace flags are going to be used in conjunction with a database restore so we can get an idea about what SQL Server is doing during the process. We’ll be looking at output in the message output screen and output sent to the SQL Server error log.

Before we go much further, I want to briefly explain the purpose of these flags and why it’s important to use them together to get the information we’re looking for.

Trace Flag 3004

Most Database Administrators are aware of instant file initialization. In a nutshell, when instant file initialization is enabled the data files do not need to be zeroed out during creation. This can save an incredible amount of time during the restoration of VLDBs. As you can imagine, the zeroing out of a 1 TB data file can take a very long time.

Trace flag 3004 turns on information regarding instant file initialization. Enabling this trace flag will not make this information available to view. You will still need to turn on trace flag 3605 to send this information to the error log.

Trace Flag 3014

Trace flag 3014 provides detailed information regarding the steps performed during the backup and restore process. Normally, SQL Server only provides a limited amount of information in the error log regarding these processes. By enabling this trace flag you’ll be able to see some very detailed and interesting information.

Trace Flag 3604

Trace flag 3604 can be used under a variety of circumstances. If you’ve ever used DBCC IND or DBCC PAGE then you’ve probably already used trace flag 3604. It simply informs SQL Server to send some DBCC output information to the screen instead of the error log. In many cases, you have to use this trace flag to see any output at all.

Trace Flag 3605

Trace flag 3605 will send some DBCC output to the error log. This trace flag needs to be enabled to see the instant file initialization information made available by trace flag 3004.

Restore without Trace Flags

I created a full backup of the AdventureWorks database and then restored it with the following command:

– Restore the database

RESTORE DATABASE AdventureWorks

FROM DISK = ‘C:\TEMP\ADVENTUREWORKS.BAK’

GO

Without these trace flags the following information is returned to the message output screen:

You can also see very similar information in the error log. I returned the contents of the error log with the following command:

– Read the error log

EXEC xp_readerrorlog;

GO

Restore with Trace Flags

I’m going to perform the restore again. This time my four trace flags have been enabled and I’m hoping to see some additional information in both the message output window and the error log.

In order to make sure the error log is easy to read, I’ve cycled it with the following command:

– Cycle the error log

EXEC sp_cycle_errorlog;

GO

The next step is to execute the restore again.

– Restore the database

RESTORE DATABASE AdventureWorks

FROM DISK = ‘C:\TEMP\ADVENTUREWORKS.BAK’

GO

After the restore is finished, and with the log cleared and the trace flags enabled, we get the following information in the message output window:

It’s easy to see that this output is far more detailed when compared to what we received during our last restore. You notice that there are quite a few additional steps that were not reported when the trace flags were not enabled.

But wait, we also need to check the error log to see what additional information is available there too.

– Read the error log

EXEC xp_readerrorlog;

GO


The most interesting information in the error log is in regard to instant file initialization. You can see that SQL Server is zeroing out the data file during the container prepare process. This means we’re not benefiting from instant file initialization.

Conclusion

It’s important to understand that SQL Server purposely hides this level of detail from us on a daily basis. Arguably, this information isn’t really that necessary. However, if you feel as though you need to have a greater understanding about what’s going on inside the database engine then this is a good starting point on your journey.

Posted by 보미아빠
, |

net start mssql$sql2008r2 /m

ADMIN:.\sql2008r2

접속완료

update sys.sysdbreg set status = status |32 where name ='db'
update sys.sysdbreg set status = status &~32 where name ='db'

이런거 강제로 셋팅이 가능.


restore database db with recovery

Error: 927, Severity: 14, State: 2
먼저 에러가 나고 다음 아래와 같은 에러 발생


메시지 4333, 수준 16, 상태 1, 줄 2
로그가 복원되지 않아 데이터베이스를 복구할 수 없습니다.
메시지 3013, 수준 16, 상태 1, 줄 2
RESTORE DATABASE이(가) 비정상적으로 종료됩니다.

메시지 4333, 수준 16, 상태 1, 줄 2
The database cannot be recovered because the log was not restored.
메시지 3013, 수준 16, 상태 1, 줄 2
RESTORE DATABASE is terminating abnormally.



restore log db from disk ='c:\a.log1' with norecovery , CONTINUE_AFTER_ERROR



메시지 4320, 수준 16, 상태 11, 줄 1
데이터베이스 또는 파일 복원을 통해 파일 "db"을(를) 완전히 복원하지 못했습니다. 이 백업 세트를 적용하기 전에 전체 파일을 복원해야 합니다.
메시지 3119, 수준 16, 상태 1, 줄 1
RESTORE 문을 계획하는 동안 문제가 발견되었습니다. 자세한 내용은 이전 메시지를 참조하십시오.
메시지 3013, 수준 16, 상태 1, 줄 1
RESTORE LOG이(가) 비정상적으로 종료됩니다.

메시지 4320, 수준 16, 상태 11, 줄 2
The file "db" was not fully restored by a database or file restore. The entire file must be successfully restored before applying this backup set.
메시지 3119, 수준 16, 상태 1, 줄 2
Problems were identified while planning for the RESTORE statement. Previous messages provide details.
메시지 3013, 수준 16, 상태 1, 줄 2
RESTORE LOG is terminating abnormally.

dbcc traceon (3604)
dbcc dbtable


1 = autoclose; set with sp_dboption.
4 = select into/bulkcopy; set with sp_dboption.
8 = trunc. log on chkpt; set with sp_dboption.
16 = torn page detection, set with sp_dboption.
32 = loading.
64 = pre recovery.
128 = recovering.
256 = not recovered.
512 = offline; set with sp_dboption.
1024 = read only; set with sp_dboption.
2048 = dbo use only; set with sp_dboption.
4096 = single user; set with sp_dboption.
32768 = emergency mode.
4194304 = autoshrink.
1073741824 = cleanly shutdown.

binary diff 이용하기 위해 aptdiff winmerge 같은 툴 이용할것


drmsqlinit
drmsqlbackup
drmsqllogbackup

backup log a with no_log

씨봉~ ㅠ.ㅠ~

Posted by 보미아빠
, |

최근에 달린 댓글

최근에 받은 트랙백

글 보관함