이번에 소개해 드릴 내용은 백업과 복구의 전략 입니다.
실질적인 작업을 통해 여러가지 백업과정을 진행해 보도록 하지요.
| USE master
GO
--백업을 테스트할 DB 생성
CREATE DATABASE bkupTest
|
먼저 테스트할 데이터베이스를 기본 옵션으로 생성합니다.
아시다시피 가장 기본적인 세팅이지요?
CREATE DATABASE 프로세스에서 'bkupTest' 디스크에 0.75MB를 할당하는 중입니다.
CREATE DATABASE 프로세스에서 'bkupTest_log' 디스크에 0.49MB를 할당하는 중입니다.
식의 메시지가 나오면 성공한 겁니다.
간단히 데이터베이스의 정보를 보도록 하지요.
| --생성된 DB의 정보를 봅니다.
sp_helpdb bkupTest
go
|
어떠세요? 흥미있게 보실 부분으로..
status라는 부분을 보시면? Recovery=FULL 이라는게 있을 겁니다.
기본 옵션으로 데이터베이스를 생성하면 복구 모델은 FULL이라는 거지요.
백업의 타겟은 크게 두가지로 나눌수 있습니다.
디바이스와 화일 입니다.
디바이스라는 가상의 장치 또는 테입장치 등을 연결해 백업을 하거나..
화일단위로 백업을 하실 수 있습니다.
최근의 상황을 볼때 디스크가 매우 저렴해졌지요. 디바이스 백업을 수행시
디바이스라는 하나의 장치에 여러 백업을 두게 되므로 편할 수 있을지 모르나..
독립적인 화일로 위치시키실 경우 조금더 눈으로 쉽게 확인이 가능하므로
코난이의 경우 유지관리계획에 등록시켜 화일로 생성해 두는 것을 좋아 한답니다.
참고로 제가 말씀 드리는 디바이스는 영구 디바이스라고도 불리며
화일 단위 백업은 임디시바이스라고도 합니다.
차근차근 보도록 하겠습니다.
먼저 화일로 백업하는 경우 입니다.
| --테이블을 생성 합니다.
USE bkupTest
GO
CREATE TABLE tblBkupTest(
name varchar(10)
, age int
)
GO
INSERT INTO tblBkupTest(name, age) VALUES('코난', 20)
INSERT INTO tblBkupTest(name, age) VALUES('까까', 30)
GO
--화일로 백업
BACKUP DATABASE bkupTest TO DISK='c:\bkupTest_full_bkup' WITH INIT
GO
|
이렇게 테이블을 생성하고 데이터를 넣은후 백업을 진행 했습니다.
백업후 결과는
1 파일에서 'bkupTest' 데이터베이스, 'bkupTest' 파일에 대해 96페이지를 처리했습니다.
1 파일에서 'bkupTest' 데이터베이스, 'bkupTest_log' 파일에 대해 1페이지를 처리했습니다.
BACKUP DATABASE이(가) 97페이지를 0.549초(1.436MB/초)만에 처리했습니다.
식으로 결과를 보실 수 있을 겁니다. -결과역시 중요합니다. 특히 백업 수행 시각을
자세히 보는 습관을 들이세요.
복구는 어떻게 할까요? 간단히 해 보도록 할까요?
| --테이블 삭제
DROP TABLE tblBkupTest
GO
--데이터 조회 불가.
SELECT * FROM tblBkupTest
--masterDB 사용 - 해당 DB가 사용중이면 복구가 불가하기 때문
USE master
GO
--복구
restore database bkupTest from disk ='c:\bkupTest_full_bkup'
GO
USE bkupTest
GO
--데이터 조회
SELECT * FROM tblBkupTest
|
복구시 완료 메세지는 다음과 같을 겁니다.
1 파일에서 'bkupTest' 데이터베이스, 'bkupTest' 파일에 대해 96페이지를 처리했습니다.
1 파일에서 'bkupTest' 데이터베이스, 'bkupTest_log' 파일에 대해 1페이지를 처리했습니다.
RESTORE DATABASE이(가) 97페이지를 0.732초(1.075MB/초)만에 처리했습니다.
역시나 주의하실 점으로 항상 복구 완료 시각을 눈여겨 보시길 바랍니다.
위의 케이스는 단순히 데이터베이스를 풀 백업 했습니다. WITH INIT은 해당 백업 타겟을
초기화 시키고 백업을 진행하라는 의미 이지요. - 백업의 여러 옵션은 천천히
다룰 겁니다.
아울러 풀 백업을 restore 구문으로 복구 했습니다.
DROP으로 날린 테이블이 잘 복구가 되었지요?
복구하기 전에 USE master 구문으로 master DB에서 복구를 진행한 이유는..
해당하는 DB가 사용중이면 복구가 불가하기 때문입니다.
만약 넷웍을 통해 사용자가 붙을 가능성이 있다면.. 잠시 사용자를..
sp_who 명령으로 SPID를 보신후.. KILL <SPID번호>로 죽이시고 수행하시면 되며
처음 SQL서버를 시작할때.. 시작 매개변수를 주어서..
sqlservr.exe -m
형식으로 단일사용자 모드로 SQL서버 시작을 하시고.. 복구를 하시는것도 좋은
방법 입니다.
계속 이야기를 진행하죠.. 화일로 백업(임시 디바이스)하고 복구하는걸 해 보셨죠..
이젠 개인적으로 별로 사용하지 않지만.. 영구 디바이스를 생성하고
백업하고 복구하는것을 해 보도록 하지요.
| --영구 백업 디바이스 생성
sp_addumpdevice 'disk', 'bkupTestDevice', 'c:\bkupTestDevice_full_bkup'
--디바이스로 백업 할때는?
BACKUP DATABASE bkupTest TO bkupTestDevice
|
결과를 보시면?
'Disk' 장치를 추가했습니다.
라는 결과와 함께 디바이스가 추가 된걸 아실 겁니다.
아울러.. 디바이스에 백업 완료시 메세지는..
1 파일에서 'bkupTest' 데이터베이스, 'bkupTest' 파일에 대해 96페이지를 처리했습니다.
1 파일에서 'bkupTest' 데이터베이스, 'bkupTest_log' 파일에 대해 1페이지를 처리했습니다.
BACKUP DATABASE이(가) 97페이지를 0.580초(1.357MB/초)만에 처리했습니다.
식일 겁니다.
| --테이블 삭제
DROP TABLE tblBkupTest
GO
--데이터 조회 불가.
SELECT * FROM tblBkupTest
--masterDB 사용 - 해당 DB가 사용중이면 복구가 불가하기 때문
USE master
GO
--복구
restore database bkupTest from bkupTestDevice
GO
USE bkupTest
GO
--데이터 조회
SELECT * FROM tblBkupTest
|
복구시 메세지는
1 파일에서 'bkupTest' 데이터베이스, 'bkupTest' 파일에 대해 96페이지를 처리했습니다.
1 파일에서 'bkupTest' 데이터베이스, 'bkupTest_log' 파일에 대해 1페이지를 처리했습니다.
RESTORE DATABASE이(가) 97페이지를 0.911초(0.864MB/초)만에 처리했습니다.
식일 것입니다. 아울러 데이터를 조회해 보면 잘 된것을 아실 겁니다.
많은 분들이 여기까지는 쉽게 이해하시고 잘 하시는데..
다음에 보시는 로그 백업에 대해서 많이 이해를 못하시지요.
이제 전략적인 측면에서.. 전체 / 로그 / 차등 백업을 이해해 보도록 하지요.
1. 풀백업만을 진행할 경우
먼저 이러한 타임라인이 있다고 생각해 봅시다.
주단위이며.. 위는 월요일 / 화요일 / ... 식으로 나올 겁니다.
두번째로. 시각은 08시부터 회사의 업무 시간인 6시까지 있을 겁니다.
이럴때 풀백업만을 진행할 경우 입니다. 풀 백업은 매일 아침 08시 업무가 시작되기 전에
이루어 집니다. 매일매일 하루에 한번씩 08시에 풀 백업을 받는 거지요!
이렇게 운영하시는 분들이 대단히 많을 겁니다. 문제 상황을 생각해 보지요.
1. 로그를 백업하지 않으므로 로그가 계속 불어나는 상황이 발생할 수 있다.
로그는 데이터의 변경본 입니다. 백업하면 지워지지만 지우지 않으므로.. 데이터는
50메가인데.. 로그는 1기가 이런 사태가 발생하게 되지요.
2. 문제 발생시 복구 가능한 데이터가 가장 적다.
실제 문제 상황을 생각해 봅시다.
자 이렇게 12시 30분에 데이터베이스가 깨졌다고 가정해 봅시다.
언제까지의 데이터로 복구가 가능할까요? - 진짜 쉽죠? ^_^;;
가장 최근의 백업본이 월요일 08시 이니..
월요일 08시의 데이터로만 복구가 가능한 겁니다. - 물론 한번도 백업한 적이 없다면?
복구 불가 하지요. -_-;;
08시부터 4시간 30분간의 데이터는 복구가 불가해 지는 겁니다. 아득하지요.
만약 다른 분 말씀으로.. "그렇다면 풀백업을 한시간에 하나씩 받으면 되자나요"
하지만.. 여기에 맹점이 있을 수 있지요.
SQL2000부터는 대단히 백업작업이 가벼워 진 편입니다. 온라인상에서 백업을 진행해도
큰 무리없이 진행이 가능하지요. 하지만.. 대부분의 일반적인 회사에서..
데이터의 용량은 대단히 큽니다. 어느곳은 데이터가 1기가를 훌쩍 넘기도 하지요.
만약 이럴때 한시간에 한번씩 백업을 한다면? 대단히 많은 부하가 걸려 백업만 하다가
시스템 리소스를 다 잡아 먹힐수도 있게 되겠지요. 그래서 좋은 방법이 될 수 없습니다.
다른 방법으로 풀백업 + 로그 백업의 방법이 있습니다.
2.풀백업 + 로그 백업
이러한 식으로.. 매일 아침 08시 풀 백업.. 매시간마다 로그를 백업하는 겁니다.
그럼 어떨까요? - 이때의 제약 사항으로 SQL서버의 해당 DB는 반드시 단순 모델이 아니어야
합니다. SQL서버의 데이터베이스가 단순 모델이면? 로그 백업이 불가해 집니다.
- 샘플에서 보여 드릴 거구요.. - 전체 모델이나.. 또는 대량 로그(Bulk Load)모드
이어야 합니다.
"저렇게 한시간에 한번씩 로그를 백업하는것도 부하가 대단히 많지 않나요?"
라고 생각하실지도 모르지만.. 로그는 대단히 그 크기가 작습니다.
예를들어 게시판을 생각해 보세요. INSERT UPDATE DELETE 작업은 대단히 작지만..
실제 내용은 수천건이 들어가 있을 수 있지요. 실제 회사의 기간 데이터일 경우는
더더욱 그렇습니다. 이제 실제 문제 상황을 생각해 보도록 하지요.
이럴 경우는 어디까지 복구가 가능할까요?
이렇게 보는 바와 같이.. 08시 부터의 데이터가 저렇다고 생각해 보도록 하지요.
08시에 풀 백업본이 있었지요? 풀 백업본을 리스토어 하면? 데이터는 어떻게 될까요?
네 맞습니다. 위와 같은 데이터가 살아나겠지요?
그러면.. 우리는 여기까지만 복구가 가능한 걸까요? 아니요!!!
우리에겐 로그 백업본이 있었습니다. 09시의 로그 백업본을 리스토어 하면?
네 맞습니다.
이렇게 데이터가 수정된 녀석으로 복구가 되겠지요?
즉!! 로그는 데이터의 변경이므로.. 데이터의 변경을 그대로 적용시켜 나가면?
우리의 데이터가 나오게 되겠지요!!! - 이작업을 REDO라고 말하기도 합니다.
여기서 문제 입니다. 9시, 10시, 11시, 12시 까지의 로그를 잘 리스토어 했습니다.
여기까지 데이터를 잘 복구 했군요.
그렇지만.. 이후 12시 20분의 데이터는?
로그를 백업하지 못했지요? 그러므로 복구가 불가해 지는 겁니다.
단!!! SQL2000의 전체 복구 모델일 경우는 12시 20분뿐 아니라... 12시 29분 까지 복구가
가능합니다. - 이유는? 데이터베이스가 깨졌지만!!! 만약 데이터 화일만 깨지고
로그가 깨진것이 아니라면? 로그를 데이터베이스가 깨진 후 백업할 수 있습니다.
- 안될것 같지만 됩니다. - 그후!! 이 로그를 복구하면? 12시 29분까지의 데이터를
복구할 수 있게 되는 것이지요.
이 샘플은 잠시 후 보여 드리기로 하구요.
마지막으로 차등 모델에 대해서 간략하게 말씀 드리지요.
3. 차등 백업
로그 백업의 범위는 이렇습니다. 정확히 마지막 로그 백업 이후의 로그 데이터를
백업하게 되지요. 따라서.. 09시의 로그 백업은? 08시~09시 까지의 데이터 변경만을
백업하게 되며.. 10시의 로그 백업본은 09시~10시 사이의 데이터 변경만을.. 식으로
백업을 하게 됩니다.
하지만 차등 백업은?
이러한 방식으로.. 가장 최근의 풀백업본 부터 전체 변경을 포함하게 됩니다.
즉! 09시의 차등 백업본은? 08시~09시 까지의 데이터 변경을 가지게 되며
12시의 차등 백업본은? 08시~12시 까지의 데이터 변경을 가지게 됩니다.
로그를 중복해서 가지게 된다는 의미 이지요.
하지만 중복보다도.. 어느정도의 복구 속도를 높일 수 있으며..
SQL2000부터는 비트맵 백업 방식이라고 해서 대단히 빠르게 백업이 가능하다는 장점이
있게 되었습니다. 하지만 역시 개인적으로는 풀백업 + 로그 백업을 선호하며
여러 장점이 있기 때문에 더 선호합니다.
차등 백업일 경우 역시나 12시 30분에 데이터베이스가 깨졌다고 생각해 보도록
하지요.
이럴 경우 어떻게 복구를 하면 될까요?
08시의 풀백업본을 리스토어 합니다.
이어서!!!
12시의 차등 백업본 하나만!! 복구를 하면? 가능한 데이터의 복구가 된 것이겠지요.
자 세가지의 복구 방법을 차근차근 보신 겁니다.
이해가 되시나요?
그렇다면!!!
조금더 다른 이야기를 해 보도록 하지요.
복구 모델에 대한 이야기 입니다.
복구 모델
먼저 말그대로 단순한 단순 모델부터 보도록 하지요.
1. 단순 복구 모델
| USE pubs
GO
--pubsDB의 복구 모델을 단순으로 한다.
ALTER DATABASE pubs SET RECOVERY simple
--풀 백업 수행
BACKUP DATABASE pubs TO DISK = 'c:\pubsFull' WITH INIT
--데이터 조회
SELECT TOP 1 title_id, price FROM titles
--조회된 값은? - 꼭 적으세요.
--데이터 수정
UPDATE titles SET price = price * 2
--데이터 조회 - 조회된값 꼭 적으세요.
SELECT TOP 1 title_id, price FROM titles
--복구 모델이 단순일 경우 로그 백업이 가능한가?
BACKUP LOG pubs TO DISK = 'c:\pubsLog' WITH INIT
--불가하다.
--SQL서버 시스템 종료SHUTDOWN
--탐색기등으로 pubs의 데이터 화일인
--mdf 화일을 지우자.
--C:\Program Files\Microsoft SQL Server\MSSQL\Data
--이 기본 경로이다.
--다시 SQL서버를 시작한다.
|
SQL서버를 시작하면 당연히 문제가 있습니다. PubsDB를 로드할 수 없다고 나오지요.
이런 식으로요..
pubs - 주의대상 - 바로 공포의 서스펙트 모드라고 하는 혼수상태 입니다.
이렇게 데이터베이스 이름이 나오는 이유는? 데이터베이스 이름과 같은 정보는
바로 MasterDB에 있기 때문입니다.
여하간 우리가 mdf 화일을 지웠으니 당연한가요? 이제 복구를 해 보도록 하지요.
|
--master DB 에서 작업한다.
USE master
GO
--데이터 조회가 가능한가?
SELECT TOP 1 title_id, price FROM pubs..titles
--불가하다.
--로그 백업이 가능한가? (이후 풀모델과 비교를 위해서 입니다.)
BACKUP LOG pubs TO DISK = 'c:\pubsLogNoTrunc' WITH NO_TRUNCATE, INIT
--불가하다.
--복구를 진행하자.
RESTORE DATABASE pubs FROM DISK = 'c:\pubsFull'
--데이터를 조회해 보자.
SELECT TOP 1 title_id, price FROM pubs..titles
--조회된 값은?
|
자 복구를 하고 조회를 해 보았습니다. 값이 얼마가 나왔죠?
BU1032 19.9900
의 값이 나왔을 겁니다. 왜 그렇죠?
위에서 분명히 UPDATE를 한번 하지 않았나요?
하지만.. 우리가 UPDATE를 하기 전에 풀 백업을 진행 했지요?
아울러 로그 백업도 불가했고 데이터베이스가 깨진 이후에도 아무것도 할 수 없었기
때문에 오로지 가장 최근의 풀 백업본 까지만!!! 복구가 가능한 겁니다.
이게 바로 단순 모델입니다. - 물론 로그 백업 자체가 불가합니다.
하지만 자동으로 로그를 비워주니 로그가 한없이 커지는 사태는 발생하지 않지요.
다음으로 대량 로그 모델을 봐 보도록 할까요?
2. 대량 로그 모델
먼저샘플텍스트화된 화일 을 다운로드 받으세요.
압축을 푸시면 titles.txt와 titles2.txt 화일이 있습니다.
아래 샘플에서 사용되니 이두 녀석을 c:\ 에 두시길 바랍니다.
| --pubs DB를 대량 로그 모델로 바꾼다.
ALTER DATABASE pubs SET RECOVERY bulk_logged
--데이터베이스를 풀 백업 한다.
BACKUP DATABASE pubs to DISK = 'c:\pubsFull' WITH INIT
--데이터를 조회한다.
SELECT TOP 1 title_id, price FROM pubs..titles
--조회된 값은?
--가격을 *2 한다.
UPDATE pubs..titles SET price = price * 2
--데이터를 조회한다.
SELECT TOP 1 title_id, price FROM pubs..titles
--조회된 값은?
--BULK 작업을 한다.
--다운로드 받은 titles.txt 화일을 c:\에 둔다. - SQL7에서
--BULK 작업은 로그에 남지 않았으나 SQL2000에서는 남는다.
--일반적인 INSERT, UPDATE, DELETE는 기본적으로 로그에 남는다.
--그리고 작업한다.
BULK INSERT pubs..titles FROM 'c:\titles.txt'
--데이터를 조회한다.
SELECT top 2 title_id, price FROM pubs..titles
--Bulk INSERT로 삽입된 값은 BU1001 에 39.98이다.
--SQL7과 틀리게 sp_dboption없이 BULK INSERT가 가능하다.
--로그를 백업하자. - BULK INSERT가 로그에 남을까 남지 않을까?
--SQL7까지는 LOG에 남지 않는 작업이었다.
BACKUP LOG pubs TO DISK = 'c:\pubsLog' WITH INIT
--다시 하나의 데이터를 BULK INSERT로 넣자.
--지금 넣는 값은 title_id가 BU1002이며 가격은 23.9 이다.
BULK INSERT pubs..titles FROM 'c:\titles2.txt'
--데이터를 조회해 보자.
SELECT top 3 title_id, price FROM pubs..titles
--조회된 값은?
--역시나 시스템을 내리고 pubs의 mdf 화일을 지우자.
SHUTDOWN
|
자 이 샘플에서 언급하는 조회되는 값을 잘 적어 두시길 바랍니다.
그래야 어디까지 복구가 가능한지 알 수 있지요.
이제 복구 작업을 진행해 보도록 하지요.
|
--다시 SQL서버를 시작 시키자.
USE master
GO
--데이터가 조회 가능한가? - 불가하다.
SELECT TOP 3 title_id, price FROM pubs..titles
--데이터베이스를 복구하자.
--현재 풀백업본을 복구하는 것이다.
--이후 LOG를 복구할게 더 있으므로 옵션으로
--WITH NORECOVERY를 붙인다.
RESTORE DATABASE pubs FROM DISK = 'c:\pubsFull'
WITH NORECOVERY
--로그를 복구하자.
--이때 마지막 복구본 이므로
--WITH RECOVERY 옵션을 준다.
RESTORE LOG pubs FROM DISK = 'c:\pubsLog'
WITH RECOVERY
--데이터를 조회해 보자.
SELECT TOP 3 title_id, price FROM pubs..titles
|
데이터를 맨 마지막에 조회해 보니 어떤가요?
대량 로그 백업 샘플에서는 분명히 마지막에 어떤 값이었지요?
BU1001, BU1002, BU1032였을 겁니다. 분명히 LOG에 BULK INSERT의 데이터가 남았기
때문에 BU1001이 보이지요? 또한 두번째 BULK INSERT한 BU1002값은?
추후 로그를 백업하지 않았기 때문에 볼 수 없지요.
따라서.. 대량로드 작업에서는 가장 최근의 로그 백업본 까지만!!!
복구가 가능한 겁니다.
이제 전체 모델을 봐 보도록 하지요.
3. 전체 모델
| --사용된 데이터베이스를 최초 상태로 복구 합니다.
--맨처음 단순모델할때 사용했던 백업본입니다.
RESTORE DATABASE pubs FROM DISK = 'c:\pubsFull'
--다음 풀모델을 위해 풀백업을 진행합니다.
BACKUP DATABASE pubs TO DISK = 'c:\pubs1' WITH INIT
--데이터를 조회해 보면?
SELECT TOP 1 title_id, price FROM pubs..title
--조회된 값은?
--price를 *2 합니다.
UPDATE pubs..titles SET price = price * 2
--BULK INSERT로 데이터를 넣습니다. 값은 BU1001입니다.
BULK INSERT pubs..titles FROM 'c:\titles.txt'
--데이터를 조회하면?
SELECT TOP 2 title_id, price FROM pubs..titles
--조회된 값은?
--로그를 백업 합니다.
BACKUP LOG pubs TO DISK = 'c:\pubsLog' WITH INIT
--또다시 BULK INSERT를 합니다.
BULK INSERT pubs..titles FROM 'c:\titles2.txt'
--데이터를 조회하면?
SELECT TOP 3 title_id, price FROM pubs..titles
--조회된 값은?
--시스템 셧다운
SHUTDOWN
--pubs의 mdf 화일을 삭제 합니다. 단!
--ldf 화일은 건드리지 마세요.
|
mdf 화일을 삭제 했습니다. 조회된 값은 얼마죠?
BU1001, BU1002, BU1032일 겁니다. 그렇죠?
그럼 이제 복구를 해 볼까요?
| --복구를 진행합니다.
USE master
GO
--데이터를 조회가 가능한가요? - 불가합니다.
SELECT TOP 2 title_id, price FROM pubs..titles
--로그를 백업합니다.
--바로 풀백업의 중요한 부분으로
--문제가 발생해도 로그가 깨지지 않았다면?
--로그가 백업이 됩니다.
--이때 반드시 WITH NO_TRUNCATE 옵션이 필요합니다.
--INIT는 초기화 시켜 백업하라는 옵션이지요.
BACKUP LOG pubs TO DISK = 'c:\pubsLogNoTrunc' WITH NO_TRUNCATE, INIT
--로그 백업이 성공합니다.
--데이터베이스를 복구해 보도록 하지요.
--복구할게 더 있으니 NORECOVERY로 합니다.
RESTORE DATABASE pubs FROM DISK = 'c:\pubsFull'
WITH NORECOVERY
--로그를 복구해 보도록 하지요.
--복구할게 더 있으니 NORECOVERY로 합니다.
RESTORE LOG pubs FROM DISK = 'c:\pubsLog'
WITH NORECOVERY
--로그를 복구해 보도록 하지요.
--이 로그는? pubs가 깨진후 로그만 백업한것이죠?
--위에서 옵션인 WITH NO_TRUNCATE옵션으로 백업한 로그 입니다.
--복구할게 더이상 없으니 RECOVERY로 합니다.
RESTORE LOG pubs FROM DISK = 'c:\pubsLogNoTrunc'
--데이터를 조회해 보면?
SELECT TOP 3 title_id, price FROM pubs..titles
--어디까지 복구가 되었나요?
|
자 여기까지 보셨으면 이제 다 보신 겁니다.
어떠세요? 데이터 백업 + 로그백업 이해 되시나요?
아울러 SQL2000의 새로운 복구 모델 세가지두 이해 되시구요?
그럼 이제 많이 받는 질문인.... 개발자나 관리자의 실수로..
WHERE절 없이 DELETE나 UPDATE를 쳐 버렸을때 복구하는 방법을 말씀 드리지요.
4. STOPAT을 이용한 복구
이때는 반드시 모델이 전체 모델 또는 대량 로그 이어야 합니다.
| --데이터베이스를 초기화 시키기 위해 리스토어 합니다.
RESTORE DATABASE pubs FROM DISK = 'c:\pubsFull'
--데이터베이스를 풀 백업 합니다.
BACKUP DATABASE pubs TO DISK = 'c:\pubs1' WITH INIT
--데이터를 조회합니다.
SELECT TOP 1 title_id, price FROM pubs..titles
--초기화가 잘 되었는지 확인하는 겁니다.
--데이터를 하나 삽입 합니다.
BULK INSERT pubs..titles FROM 'c:\titles.txt'
--데이터를 조회하면?
SELECT TOP 2 title_id, price FROM pubs..titles
--조회된 값은?
--로그를 백업해 보도록 하지요.
BACKUP LOG pubs TO DISK = 'c:\pubsLog' WITH INIT
--역시나 데이터를 하나 더 넣도록 합니다.
BULK INSERT pubs..titles FROM 'c:\titles2.txt'
--데이터를 조회하면?
SELECT TOP 3 title_id, price FROM pubs..titles
--조회된 값은?
--!!자 이제 문제 상황입니다.
--개발자의 실수로 UPDATE를 WHERE절 없이 쳐버렸습니다.
UPDATE pubs..titles SET price = 0
--컨트롤 + Z는 아무리 눌러도 데이터는 복구 안됩니다.
SELECT title_id, price FROM pubs..titles
--바로 문제가 발생한 시각을 알아야만 합니다.
SELECT GETDATE()
--결과 시각은?
--코난이의 경우 아래와 같은 시각 입니다.
2001-08-23 16:06:14.320
--어떻게 해야 할까요?
--1. 즉시 로그를 백업 합니다.
--2. STOP AT 구문으로 복구 합니다.
--로그를 백업 합니다.
BACKUP LOG pubs TO DISK = 'c:\pubsLogNoTrunc' WITH NO_TRUNCATE, INIT
--데이터베이스를 복구합니다.
--이때 첫번째 로그 백업과.. 문제가 발생한후 로그 백업 사이로
--복구를 진행해야 합니다. 그렇지요?
--STOP AT을 적절히 사용하도록 하지요.
--풀 백업본을 리스토어 합니다.
RESTORE DATABASE pubs FROM DISK = 'c:\pubsFull'
WITH NORECOVERY
--첫번째 로그 백업본을 복구 합니다.
RESTORE LOG pubs FROM DISK = 'c:\pubsLog'
WITH NORECOVERY
--문제가 발생한후 로그를 백업한 것입니다.
--약간 특이하게 STOP AT이 있습니다.
--시각 지정은.. 문제가 발생한 시각 - 1분 정도로 하겠습니다.
--2001-08-23 16:06:14.320 빼기 1분
--그래야만.. 문제가 발생하기 바로 전 시각으로 되돌릴 수 있겠지요?
--당연히 문제가 발생한후 즉시 알아야만 데이터 손실을 그만큼 줄일수 있겠죠
--한 일주일 정도 지난후 문제가 발생한걸 알고.. 또한
--중요한 회원 데이터였다면? 생각하기도 끔찍해 지겠지요.
RESTORE LOG pubs FROM DISK = 'c:\pubsLogNoTrunc'
WITH STOPAT = '2001-08-23 16:05:14.320', RECOVERY
--데이터를 조회해 보면?
SELECT TOP 3 title_id, price FROM pubs..titles
--원하는 데이터인 BU1001, BU1002, BU1032가 맞습니까?
|
어떠세요?
이제 STOPAT을 어떻게 사용하는지 감이 좀 잡히시나요? ^_^
자.. 그러면!!
이제 자동화를 이용해서 이러한 백업과 리스토어를 쉽게 하는 이야기를 조금
드려 보지요.
데이터베이스 유지관리 계획은.. 총체적으로 데이터베이스를 유지 관리하기 위한
기능입니다.
백업 / 인덱스 구축 등등의 관리자의 손이 개입되어야 하는 작업들을..
자동적으로 수행할 수 있게 도움을 주는 매우 유용한 기능입니다.
이렇게 해당 DB에서.. 유지관리 계획을 선택 합니다.
해당 데이터베이스를 선택 하구요.
아래쪽의 트랜젝션 로그를 다른 SQL서버로 전달 - 항목은.. 로그 전달이라는 다른
모델을 구축하기 위한 것입니다. 다음 강좌에서 소개해 드릴 겁니다.
최적화는 인덱스에서 설명드린 FILLFACTOR를 말하는 겁니다.
10으로 잡은 것은.. FILL FACTOR 값이 90이라는 것이지요.. 일정 여유를 둔다는
것입니다. 실제 시스템일 경우 잡아 줘야 하며.. 적절히.. 아래 일정 부분을 선택해..
하루에 한번 식으로 유지해 줘야 합니다.
아래의 공간 제거는.. AUTO SHRINK로.. 빈공간 유지인데.. 사실 거의 필요 없으며..
부하를 주므로 선택하지 않는것이 좋습니다.
무결성 검사는..
DBCC CHECKDB 명령입니다. 데이터베이스 개체들의 무결성을 검사하는 것이지요.
예를들어.. 인덱스와 데이터를 연결하는 체인이 끊어지거나 하는 검사를 하며
고치는 기능입니다. 주기적으로 물론 해주는 것이 좋습니다. 또한..
백업전헤 하길 권장하는 이유는?
깨진 데이터를 백업하면 의미가 있을까요? 따라서.. 약간의 비용이 더 들지만..
백업전에 해주는 것이 좋습니다. 일정은 역시 적절히 잡아 주시구요.
이 백업 계획 지정은..
풀백업 진행 여부를 묻는 것이며 당연히 해야 겠지요. ^_^;;
완료시 백업본의 무결성 자동 검사..
또한 테입 장치 OR 디스크로 할 수 있습니다. 일정은 백업 전략대로 적절히 잡아
주셔야 겠지요?
디렉토리 지정이며.. 당연히.. 디스크가 통째로 깨져버리는 사태를 대비해..
데이터가 있는 디스크와는 다른 물리적인 디스크를 지정해야겠지요?
데이터베이스마다 하위 디렉 만들기는.. 개인적으로 구분이 잘되어 선호합니다.
4주 이상이 지나면 사실 별 의미가 없으니 자동으로 지우게 선택합니다.
물론 4주가 아니라.. 적절히 적용하셔도 되겠지요?
백업 화일의 확장자는 개인적으로 적었습니다. BAK라고만 하지 마세요.
트랜젝션 로그를 백업할지 묻는 겁니다. 풀백업과 같습니다.
적절히 일정을 잡아 주시면 되겠지요.
로그백업화일에 대한 정보를 지정해 주는 겁니다. 풀백업과 비슷 하지요?
완료 정보 등을 보고서로 쓰게 됩니다. 어렵지 않으실 것이며..
아래 보시면 운영자가 나오는데요.. 운영자를 등록하면 나타나게 되며..
메일 / NET SEND명령 등으로 알림이 가능합니다.
유지 관리에 대한 기록은 MSDB에 저장되는데요. 여기에 쓸것인지.. 아울러 쓴다면
로우의 갯수를 얼마로 제한할지 결정하는 것입니다.
원격서버는 MSX서버라고 해서.. 다른 시스템에 쓰는 것입니다.
주의하실 점으로.. 이런 유지관리계획과 같은 스케쥴 작업을 수행 하려면?
반드시 SQL SERVER 에이젼트가 실행중이어야 합니다.
확인하셔야 하는 부분이구요.
실질적으로 이를 비쥬얼하게 보실 수 있습니다.
SQL7 강좌에서 같은 이야기를 드렸지요. 또한 복구를 엔터프라이즈 관리자에서
진행하는 방법 역시 있습니다. 이에 대한 글은
자동화를 이용한 관리작업
부분을 보시면 실제 온라인 시스템을 흉내 내면서 데이터를 지속적으로
계속 삽입 합니다. - 실제 시스템 흉내내기.
그러면서 스케쥴을 이용한 백업을 위의 그림들보다 좀더 상세히 표현해
실제 백업되는 데이터와 로그 백업 데이터를 확인하실 수 있으며
리스토러 하는 화면 역시 쉽게 보실 수 있으니 참고 하세요.
또한 STOPAT을 엔터프라이즈 관리자에서 하는 화면 역시 보실 수 있으니 참고 하세요.
이정도면 백업에 대한 이야기는 대강 마무리 된듯 하네요.
엔터프라이즈로 복구하는 샘플들은?
SQL7 기본강좌 - 백업의 전략 부분을 참고 하시길 바랍니다.
대단히 간단합니다. - 하지만..
가급적이면.. 스크립트로 구성해 두셔서.. 빠르게 복구 가능하도록 하시는 것도 좋지요
백업과 복구의 가장 중요한 부분은 얼마나 자주 백업할 것인가를 결정하는 부분과
어떤 백업과 복구 방식을 사용할 것인가의 적절한 선택 입니다.
이정도로 마치고.. 다음 이야기를 진행하도록 하지요.
10. 백업과 복구 - 2. 백업과 복구의 전략 문서의 끝입니다.
| 
