솔직해야 사람이 붙는다  

"네, 좋습니다."
"편한대로 하시지요."

좀처럼 자기 색깔을 드러내지 않는 사람들이 많다.
싫어도 좋은 것처럼, 좋아도 그저 그런 것처럼
자기 표현에 솔직하지 못한 것이다. 

매사에 자기는 죽이고 타인을 배려하는 것처럼
행동한다. 
과연 이같은 언행이 좋은 것일까? 

자신은 싫지만 상대를 편하게 해주기 위해
늘 타인의 입장에 서있는 것은 참으로 착한
삶이 아니겠느냐고 하는 이들도 있겠지만 결코
그렇지가 않다.

인간관계에 대한 처세술을 연구하는 전문가들
중에는 '이 같은 유형의 사람들을 가까이 하지
말라.' 는 말을 하기도 한다.

자신이 싫으면 싫다고, 좋으면 좋다고 솔직하게
말하는 사람들을 두고 우리는 흔히 '뒤끝이 없는
사람이다' 라고 말하기도 한다.

자신의 감정을 속이지 않고 사실 그대로를
표현하기 때문에 순간적으로는 '매정하다.' 거나
'차갑다.' 라는 느낌을 가질수도 있지만 적어도
상대에게 피해 주는 일은 없는 게 이런 성격을
지닌 사람들의 장점이다.

일례로 시장에서 고객이 물건을 고르면서 가격을
의심할 경우 장사꾼이 말하기를,
"최하가격이니 더 이상 깎을 생각은 하지 마십시오."
라고 했다고 치자. 
그런데도 불구하고 고객이 의심을 하고 계속해서
깎으려고 한다면 장사꾼은 화를 낸다.

솔직하게 털어놓았는데 고객이 믿어 주지 않기 
때문이다. 이런 사람들은 오히려 소비자들에게
매력을 끈다. 이유는 성격이 화끈해서 숨기는 것이
없어 보이기 때문이다.

반대로 처음에는 5백원 빼준다고 하다가 고객이
조르니 천원을 빼주는 장사꾼들도 있다. 
이럴때 고객은 물건을 구입한후 집에 가면서 내내
그런 생각을 하게 된다. 
'좀 더 깎을수도 있었는데 더 깎지 못한게 아쉽다.'
는 것이다. 그리고 장사꾼을 신뢰하지 않는다.

현대사회는 신용사회다. 
'나는 이런 사람이다.' 라고 솔직하게 보여줄때
사람들은 그렇지 않은 경우보다 믿음을 갖게 된다.
밀고 당기면서 상대를 재고 저울질을 하는 쪽보다는
있는 그대로 솔직하게 자신을 보여주는 것이 장기
적인 인간관계에서 성공의 열쇠가 될 수 있다.


      - 박창수 (언론인) -

탐색기 폴더에서, 도스창 실행 레지스트리: '여기에 명령 프롬프트' Command Line Here Registry

command_line_here.reg

데이터베이스 백업과 복구전략 (1) - 오라클의 데이터베이스 백업

엔코아 컨설팅 한 준 희

"복구에 실패한 DBA는 용서받을 수 있어도, 백업에 실패한 DBA는 용서받을 수 없다"

데이터베이스 백업과 복구전략 (1) - 오라클의 데이터베이스 백업

엔코아 컨설팅 한 준 희

"복구에 실패한 DBA는 용서받을 수 있어도, 백업에 실패한 DBA는 용서받을 수 없다"

이 길을 들어서서 제일 먼저 사수에게 들었던 전설과 같다는 말이다.
아무리 시스템의 성능이 고도화되고, 성능개선을 위해 숱한 시간을 허비했어도, 다음날 출근했을 때 어제의 작업, 심지어 그동안의 모든 작업이 허사가 되도록 시스템이 주저앉아버린다면 아무런 소용도 없게 된다.
본 문서는 ORACLE사의 RDBMS를 사용하는 사용자 및 운영자들이 적절한 수준에서 백업전략을 수립하고, 이에 맞는 복구전략을 숙지할 수 있도록 가이드를 하는 목적으로 작성하게 되었다.
본 장은 일반적인 데이터베이스 백업전략에 대해 정리해 보았다.

1. DATABASE-데이터베이스 백업

1.1 백업의 개요 및 목적

데 이터베이스 백업이라 함은 기간시스템의 장애가 발생할 경우 이를 복구하기 위한 “보험”과 같은 개념이다. 관계형 데이터베이스를 사용하는데 있어서 가장 큰 장점중의 하나는 데이터베이스의 이상 발생시 언제든지 데이터베이스 RECOVERY를 수행하여 현재의 상황으로 복구할 수 있다는 점이다. 이러한 복구가 가능하기 위해서는 데이터베이스 관리자는 복구가 가능한 상태로 데이터베이스를 운용하여야 한다. 예를 들어 사용자가 NO ARCHIVE MODE로 운용할 경우에는 불행히도 데이터베이스를 처음 생성한 시점이나 전체 백업 받은 시점으로만이 복구가 가능하기 때문이다.
일반적인 경우 백업 정책이 없이 무작정 과다한 양의 백업을 받을 경우 일정 기간이 경과하면 백업에 대한 의미가 희미해지게 되고 정상적인 작업을 수행하지 않을 때, 백업파일이 꼭 필요한 경우 작업을 할 수 없는 경우가 발생할 수도 있다.
데이터베이스 관리자는 백업에 대한 정책을 수립하여 꼭 필요한 데이터를 최소의 약으로 백업을 받고 최소의 시간을 소비- 고객의 MTTR(MEAN TIME TO RECOVERY)을 만족할 수 있는 시간-하면서도 항시 복구가 가능한 상태를 유지하여야 한다.

1.2 주요 고려사항

데 이터베이스는 기존의 파일시스템과는 달리 전체 사용자 OBJECT를 하나의 TABLESPACE로 관리하거나 필요에 따라 나누어 사용 및 관리하므로 백업뿐 아니라 복구 시에도 상당히 주의를 요한다. 만일 ARCHIVE LOG 상태에서 운용하고 있는 상태에서 이상이 발생할 경우 복구작업에 필요한 LOG FILE중에 하나의 파일이라도 없어지거나 사용할 수 없는 경우에는 정상적인 복구가 불가능하게 된다.
이러한 불행한 경우를 방지하기 위해서 DBA는 항시 복구가 가능한 상태로 작업하기 위한 백업정책을 수립하여 정확하게 작업하여야 한다.
또한 24 X 7(1년 365일) DOWN TIME없이 운용되는 시스템의 경우 백업 정책의 수립에 COLD BACKUP과 같은 FULL IMAGE 백업이 불가능 할 수 있기에 HOT BACKUP 혹은 EXPORT를 통한 LOGICAL 백업만이 가능할 수 있다. 이런 제약사항으로 인해 혹시 발생할 수 있는 장애에 적절한 대응을 하지 못할 수 있다.
이러한 결정상황을 파악하여 백업정책 수립에 심혈을 기울여야 할 것이며 , 시스템 운용의 묘를 살려야 할 것이다.
또한 HOT BACKUP등의 ONLINE상에서 데이터베이스를 백업하기 위해서는 반드시 ARCHIVE MODE로 운영되어야 한다.

1.3 백업 전략

DBA 가 어떠한 방법으로 백업을 유지하느냐에 따라 복구 성공률이나 복구 속도 등이 결정된다 물론 매일 작업 종료 후 전체 데이터베이스에 대하여 FULL BACKUP을 한다면 가장 안전한 백업이라고 볼 수 있으나 실질적으로 백업을 받는데 많은 시간을 요구하므로 현실적으로는 불가능한 작업이라 볼 수 있다.

예 : XXX시스템의 특징은 24시간 365일 무중단 운영을 원칙으로 하고 있고, 타 시스템과의 INTERFACE 대상의 DATA LOAD가 야간에 대량으로 발생하며, 정산 및 온라인 통계작업을 통한 대량의 TRANSACTION이 발생한다.이는 다시 말해 COLD BACKUP을 위한 시스템 중단이 사실상 불가능하다는 말과 같다.

이런 시스템의 특성을 반영한 백업시스템 정책은 현실적으로 적용 가능한 HOT BACKUP을 업무가 집중하지 않는 시간에 수행하는 것으로 정하여야 하며, 단위 업무별로 대량의 변화가 발생할 경우에 데이터의 수정 혹은 삭제, 변화가 발생하기 전에 각 단위 팀의 별도 APPLICATION을 통해 데이터 BACKUP을 수행하는 것으로 한다.

가. 업무수행에 지장을 받지 않는 시간대에 HOT BACKUP을 수행한다.
나. 업무변화가 대량으로 발생하기 전에 APPLICATION을 통한 BACKUP수행
다. 자주 read-write되는 tablespace는 자주 online backup을 수행.
라. 데이터베이스에 구조적인 변화가 생기기 前,後로 full backup을 수행.
마. 이전의 backup본을 최소한 2본 이상 가지고 있을 필요가 있다.
바. 특정 테이블들에 대한 data의 입력 오류로 인해 과거 특정 시점으로의 회귀가 필요하거나, 특정 테이블 데이터의 분실로 인해 다시 복귀를 하고자 할 경우를 대비하여 Logical Backup인 Export를 수시로 받아놓도록 한다.
사. Unrecoverable로 Creation된 Object는 redo log file에 logging되지 않기에 이러한 Object들에 대해서는 Export Utility를 사용하여 Backup하도록 하는 것이 좋으며, 초기 생성 후 정상적인 데이터 입력/수정이 이루어질 경우에는 logging으로 변경하도록 한다.

1.4 백업 방법

1.4.1 Physical Backup

물 리적인 데이터베이스 파일을 한 위치에서 다른 위치로 COPY하는 물리적인 복제를 Physical Backup이라 한다. 또한 Physical Backup은 Offline, Online Backup(Without Archiving / With Archiving)으로 나눌 수 있다. 즉 데이터베이스 상태가 Down인 상황에서 Backup을 수행하면 Offline Backup이며 이 백업은 Archive Log파일의 Backup은 불필요하나, 데이터베이스가 Online인 상황에서 Backup을 수행하는 Online Backup인 경우에는 Backup도중에도 Transaction이 발생할 수 있고, 이 기간 중에 발생한 데이터의 보존을 위해 Archive Log를 반드시 백업하고 있어야 한다.

1.4.1.1 Cold Backup (Offline Backup)

데이터베이스를 Shutdown 한 이후 아래와 같은 파일들을 백업 Library로 COPY하여야 한다.

가. DataFiles (V$datafile확인자료)
나. Redo Log Files (V$logfile확인자료)
다. Control Files (V$controlfile확인자료)
라. Parameter Files(initSID.ora, spfileSID, configSID.ora, etc)

1.4.1.2 HOT Backup(Online Backup)

데이터베이스가 구동중인 상태에서 datafile을 복사하는 방식으로 Archive Log Mode로 운영되어야 한다.

SQL> ALTER TABLESPACE …… BEGIN BACKUP;
$ *.DBF의 COPY수행
SQL> ALTER TABLESPACE ….. END BACKUP;

이 런 명령을 수행하는 기간 동안에는 해당 TABLESPACE가 HOTBACKUP MODE로 운영중이어서 해당 TABLESPACE안에 있는 TABLE에 대한 DML이 발생할 경우 DATAFILE WRITE가 불가능하기 때문에 REDO LOG에만 기록하는 기록하게 되고, 백업이 완료된 시점에서 LOG에 저장된 변경사항을 다시 Data file에 기록하기 위해 적지 않은 부하가 발생할 수 있다. 그러므로 ONLINE HOT BACKUP을 수행하는 시간은 작업량이 적고, 사용자의 접근을 최소화 할 수 있는 시간을 선정하여야 하며, 최소한의 시간에 HOT BACKUP을 수행할 수 있어야 한다.

또한 BACKUP의 시작과 끝에는 HOT BACKUP의 시작 바로 전까지 발생한 TRANSACTION의 REDO LOG를 CHANGE하도록 하여 ARCHIVING하도록 한다.또한 BACKUP이 종료한 후에도 LOG CHANGE를 하도록 하여 BACKUP중에 발생한 DATA에 대한 REDO LOG 내 변경분을 DATAFILE에 기록 및 ARCHIVING을 통한 ARCHIVE FILE BACKUP을 동시에 수행할 수 있도록 하여야 한다.

SQL> ALTER SYSTEM ARCHIVE LOG CURRENTS;

1.4.2 Logical Backup

Export Utility를 이용한 데이터 백업은 보통 DML 발생빈도가 높아 데이터블록의 활용도나 Capacity를 높이지 못할 경우 데이터블록을 최적화하기 위해 사용할 수 있고, 사용자의 실수 혹은 구조상의 문제로 인해 데이터의 손실을 최소화하기 위해 데이터의 보존을 목적으로 사용하는 방법이다.

Export Utility를 이용한 데이터 백업방법은 Full, User, Table단위의 Export Mode가 있다.

1.4.3 Archive Log File의 Backup

1.4.3.1 Archive Log Mode 구조

오라클에서 Online Backup을 받거나 완벽한 복구작업을 수행하기 위해서는 데이터베이스를 “Archive Log Mode”로 운영하여야 한다.
오라클의 log File기록방법은 “순환”기록방법을 채택하고 있다. 첫 번째 log File을 기입하고 나면 두 번째 것을 기입하고, 그것이 끝나면 세 번째 log를 기록한다. 그리고 마지막 Online Redo Log File을 쓰고 나면 Log Writer(LGWR)가 첫번째 Log File을 다시 선택하여 덮어쓰기 시작한다.
Oracle Archive Log Mode에서 작동하고 있을 때에는 Archive Background Process(ARCH)는 각각의 Redo Log File을 덮어쓰기 전에 그에 대한 복사본을 지정된 디렉토리에 만들게 된다.


[그림 1 No Archive Log Mode]

CheckPoint가 발생할 때 까지는 Redo Log File은 재사용되지 않으며 ARCH에 의해 물리적으로 Redo Log File은 다시 backup된다.


[그림 2 Archive Log Mode]

1.4.3.2 Archive Mode와 No-Archive Mode의 비교

위 그림에서 보는 바와 같이 Redo Log가 덮어 쓰이기 시작하고 Archive Mode가 아니면 Media Recovery는 마지막으로 Full Backup받은 시점으로 밖에 복구가 불가능 하다. 반면에 Archive Mode로 운영되는 데이터베이스는 가장 나중의 변화까지도 복구가 가능하다. Archive Log Mode로 운영 시 log_archive_dest Directory밑에 Archive File이 계속 발생하여 할당된 Space가 부족할 경우 log Change가 발생하지 않아 데이터베이스가 Hang-Up이 될 수 있으므로 Space관리를 유의하여야 한다.

1.4.3.3 Archive Log의 백업

데이터베이스 백업주기 결정시 archive log의 backup주기도 결정되어야 한다.
Archive log는 O/S Backup 을 통해 보관하고, Archive Log가 너무 많이 발생하지 않도록 Archive Log의 Size 즉 Redo Log의 사이즈를 적절히 조절하여야 복구를 위한 필요시간을 줄일 수 있다.
Archive Log는 데이터베이스 백업수행과는 별도로 Space의 여유분을 Check하여 일정수치 이상 Free Space가 부족할 경우 자동적으로 Copy한 다음 삭제하도록 스케쥴링하여야 한다.

1.5 백업 주기

1.5.1 백업주기의 결정

백업의 주기 및 백업 시기, 시간은 어떠한 백업방법을 적용할 것인가와 어느 정도의 Down Time을 허용할 것인가에 따라 결정된다.
즉 Hot Backup만을 허용하는 사이트에는 Transaction양이 최소화되는 시간을 선택하여 백업을 수행할 것이고, 시스템을 사용할 수 없는 최대한의 시간을 1~3시간으로 선정었다면 복구를 위해 주어진 시간이 1~3시간으로 판단되어 이에 맞는 백업주기가 결정되게 된다.

전체 시스템을 모두 Backup하는데 걸리는 시간을 산정하여야 한다. 예를 들어 전체 시스템을 Hot Backup하는데 걸리는 시간이 최대 3시간이 걸린다 할 경우 이를 3일 주기로 전체시스템을 백업할 수 있도록 나눈다면 하루에 백업에 소요되는 시간은 대략 1시간이 될 것이다.
그런데 3일 주기로 백업의 한 사이클이 종료되는 관계로 월요일에 백업한 테이블스페이스에 속한 데이터파일에 문제가 생긴 시기가 수요일 오후라면 약 이틀간 발생한 Archive Log를 이용하여 복구를 하여야 하는데 DataFile, Archive Log Restore 및 복구를 마치는데 주어진 Down Time안에 해결할 수 있는지 판단하여야 한다.
일반적으로 백업의 주기는 1년,1분기,1월,1일에 두고 주기 및 방법을 정한다. 또한 백업의 주기 뿐 아니라 백업한 Media의 보관 주기 또한 백업 및 복구에 큰 영향을 미치는 요소이다.

1.5.2 백업 주기 별 대상 결정

백업의 주기(일단위,주단위,월단위,분기단위,년단위,기타)별로 백업 대상을 선정하여 백업 매체를 선정하고, 백업대상을 LIST-UP한 다음 백업하도록 한다.

1.5.2.1 백업 주기