러브하우스

통영케이블카

2009-11-17T22:13:47Z

한려수도 조망케이블카

한려수도 조망 케이블카는 한국의 100대 명산(산림청 지정) 중 하나인 통영 미륵산(해발 461m)에 설치된 국내 최장(1,975m)의 케이블카입니다. 8인승 곤돌라(총 48기)를 타고 미륵산 정상에 오르면 한려수도의 보석 같은 섬들과 동양의 나폴리라 불리는 통영 항, 그리고 용화사와 미래사를 비롯한 고찰, 이순신 장군의 구국의 혼이 서린 한산대첩지 등을 한눈에 조망할 수 있습니다.
한려수도 조망 케이블카는 세계적인 기술을 인정받고 있는 스위스 가라벤타 사의 기술제휴로 설치되어 그 안정성을 보장받고 있습니다. 또한 환경보호와 탑승객의 승차감을 위해 중간지주를 대폭 줄였으며, 미륵산 정상까지는 환경친화적인 데크가 설치되어 등산객의 편의를 제공하고 있습니다.

소재지 : 경남 통영시 도남동 349-1번지
홈페이지 : http://www.ttdc.co.kr

요금안내
대인 : 왕복 9,000원 편도 5,500원
소인(만4세~초등) : 왕복 5,000원 편도 3,000원

※ 단체(25인 이상)는 통영관광개발공사로 연락하세요.

[퍼옴]가을을 담은 여행 찰칵! 순천만

2009-11-17T21:37:18Z

오라클에서 자동증가칼럼(Sequence) 사용하기

2009-11-09T11:19:05Z

Unique Key를 생성하는 방법은 DBMS마다 차이가 있다.
MS-SQL은 IDENTITY를, MySQL은 auto_increment와 같이 쉽게 사용할 수 있는 방법이 있는데 오라클에서는 Sequence를 사용하여 다음과 같이 유사하게 구현할 수 있다

1. 자동증가컬럼을 사용하고자 하는 MYTABLE테이블을 생성한다.

CREATE TABLE MYTABLE
(ID NUMBER, NAME VARCHAR2(20));

2. CREATE SEQUENCE 라는 문장을 사용하여 SEQ_ID라는 이름의 시퀀스를 만든다.

CREATE SEQUENCE SEQ_ID INCREMENT BY 1 START WITH 10000;

-- INCREMENT BY 1 : 증가값은 1
-- START WITH 10000 : 10000부터 증가

3. 테이블에 데이터 입력시에는 NEXTVAL이라는 슈도 칼럼(Pseudo-column)을 이용하여 시퀸스를 사용한다.

INSERT INTO MYTABLE VALUES( SEQ_ID.NEXTVAL, '홍길동');

-- CURRVAL : 현재 값을 반환 합니다. .
-- NEXTVAL : 현재 시퀀스값의 다음 값을 반환 합니다.

----------------------------------------------------------------------------------------------------------

* Sequence 구문

CREATE SEQUENCE sequence_name
        [START WITH n]
        [INCREMENT BY n]
        [MAXVALUE n | NOMAXVALUE]
        [MINVALUE n | NOMINVALUE]
        [CYCLE | NOCYCLE]

* START WITH
시퀀스의 시작 값을 지정합니다. n을 1로 지정하면 1부터 순차적으로 시퀀스번호가 증가 합니다.

* INCREMENT BY
시퀀스의 증가 값을 말합니다. n을 2로 하면 2씩 증가합니다.
START WITH를 1로 하고 INCREMENT BY를 2으로 하면 1, 3, 5,7,..
이렇게 시퀀스 번호가 증가하게 됩니다.

* MAXVALUE n | NOMAXVALUE
MAXVALUE는 시퀀스가 증가할수 있는 최대값을 말합니다.
NOMAXVALUE는 시퀀스의 값을 무한대로 지정합니다.

* MINVALUE n | NOMINVALUE
MINVALUE는 시퀀스의 최소값을 지정 합니다.
기본값은 1이며, NOMINVALUE를 지정할 경우 최소값은 무한대가 됩니다

[사용규칙]

  * NEXTVAL, CURRVAL을 사용할 수 있는 경우
    - subquery가 아닌 select문
    - insert문의 select절
    - insert문의 value절
    - update문의 set절

  * NEXTVAL, CURRVAL을 사용할 수 없는 경우
    - view의 select절
    - distinct 키워드가 있는 select문
    - group by, having, order by절이 있는 select문
    - select, delete, update의 subquery
    - create table, alter table 명령의 default값

[수정과 삭제]

ALTER SEQUENCE sequence_name
        [INCREMENT BY n]
        [MAXVALUE n | NOMAXVALUE]
        [MINVALUE n | NOMINVALUE]
        [CYCLE | NOCYCLE]

START WITH는 수정할수 없습니다.
START WITH 절이 없다는 점을 빼고는 CREATE SEQUENCE와 같습니다.

DROP SEQUENCE sequence_name

자료참고 : http://www.oracleclub.com/

오라클 전체 테이블 목록 조회하는 쿼리

2009-10-27T11:06:24Z

SELECT RANK() OVER(PARTITION BY A.TABLE_NAME ORDER BY A.table_COMMENT, A.COLUMN_POSITION, A.COLUMN_NAME) AS RK, A.*
FROM
(
    SELECT D.COMMENTS AS COLUMN_COMMENT,
           b.COLUMN_NAME,
           NVL2(E.INDEX_NAME, 'Y', '') AS PK,
           DECODE(B.NULLABLE, 'Y', 'Null 허용, Default값 있음', 'Not Null, Default값 있음') AS NULLYN,
           b.DATA_TYPE, b.DATA_LENGTH, b.DATA_TYPE||decode(b.DATA_LENGTH, 'DATE', '', 'CLOB', '', 'LONG', '', '('||b.DATA_LENGTH||')') AS TYPE,
           NVL(E.COLUMN_POSITION, '') AS COLUMN_POSITION
           ,a.TABLE_NAME, c.COMMENTS as table_COMMENT
    FROM USER_TABLES A
         ,USER_TAB_COLUMNS B
         , all_Tab_COMMENTs c
         , all_col_comments d
         , (
            SELECT A.TABLE_NAME, A.COLUMN_NAME, B.CONSTRAINT_TYPE, B.INDEX_NAME, A.COLUMN_POSITION
              FROM SYS.ALL_IND_COLUMNS A ,
                SYS.ALL_CONSTRAINTS B
              WHERE A.INDEX_OWNER = B.OWNER
              AND     A.TABLE_NAME = B.TABLE_NAME
              AND     A.INDEX_NAME = B.CONSTRAINT_NAME
              AND     B.CONSTRAINT_TYPE = 'P'
         ) E
    WHERE A.TABLE_NAME = B.TABLE_NAME
    and a.TABLE_NAME = c.TABLE_NAME
    and b.TABLE_NAME = d.TABLE_NAME
    and b.COLUMN_NAME = d.COLUMN_NAME
    AND b.TABLE_NAME = E.TABLE_NAME(+)
    and b.COLUMN_NAME = E.COLUMN_NAME(+)
    AND a.TABLE_NAME != 'PLAN_TABLE'
) A
ORDER BY A.table_COMMENT, A.COLUMN_POSITION, A.COLUMN_NAME
;

오라클에서 테이블 목록 보기

2009-10-27T11:05:00Z

현재 내 스키마에 있는 테이블의 목록을 보고싶을 때가 있다. 좋은 툴을 쓰면 잘 보여주지만 SQL로도 어찌 안 될까. SELECT * FROM tab; 이라는게 있다. 그런데 테이블이 아닌 인덱스나 시퀀스 같은 것은 어떻게 찾을 수 있을까? 그래서 찾아보니 있더라. USER_OBJECTS 라는 테이블을 보는 것이었다.

select object_name from user_objects where object_type = 'TABLE';
select object_name from user_objects where object_type = 'SEQUENCE';

타입에는 정확히 대문자로만 적어야 나온다.

원래 이것을 찾아본 이유는, 자동생성된 수십개의 시퀀스의 이름을 일괄적으로 바꾸어야할 일이 생겼기 때문이다. prefix정책이 바뀌는 바람에 이미 만들어진 시퀀스의 prefix들을 바꾸는 것이었는데 그것을 위해 문제의 시퀀스들을 찾고 그것의 이름을 바꾸는 쿼리를 생성해야한다. 시쿼스 이름 바꾸는 것은 RENAME seqname TO newname 으로 비교적 간단했다.

select 'RENAME '||object_name||' TO NEWPREFIX_'||substr(object_name,11)||';' AS queries from user_objects where object_type = 'SEQUENCE' AND OBJECT_NAME like 'OLDPREFIX_%';

ASP LoadPicture 이미지사이즈

2009-09-29T09:28:40Z

Dim objPic

Set objPic = LoadPicture("이미지 경로")
Response.Write(objPic.Height & "
")
Response.Write(objPic.Width & "
")
Response.Write(objPic.Type & "
")
Response.Write(objPic.Handle & "
")
Response.Write(objPic.hPal & "
")
Set objPic = Nothing

'pic : server.MapPath("/") & imgName

Function GetImageSizeX(pic)
Set p = LoadPicture(pic)
width = CLng(CDbl(p.Width) * 24 / 635)
Set p = Nothing
GetImageSizeX = width
End Function

Function GetImageSizeY(pic)
Set p = LoadPicture(pic)
height = CLng(CDbl(p.Height) * 24 / 635)
Set p = Nothing
GetImageSizeY = height
End Function

tag : LoadPicture, 이미지사이즈

디지털아카이빙시스템

2009-08-13T13:48:38Z

1111

Digital Archive란 기업/기관 등에서 보유 중인 아날로그 형태의 영상자료(베타, 디지베타, VHS,
6mm/8mm 등)를 디지털영상 표준인 MPEG2/MPEG4로 인코딩하고 그 내용을 자동으로 분석(카달로깅)하여 대용량 스토리지에 저장/관리하기 위한 시스템을 말한다. 저장된 디지털 영상물은 체계적으로 분류된 카테고리를 따라 관리/검색되며, 색인된 메타데이터, 대표프레임, 유사이미지, 핵심어등을 기반으로 고속 검색이 가능하다. 또한 저장된 디지털 영상물은 비선형편집시스템(NLE), 자동송출시스템과 연동될 수 있으며, 웹 배포/심의/복사 신청등의 기관 / 기업 내 워크플로우에 통합 될 수
있다.

기존의 아날로그 방식의 방송테잎을 디지털화하여 반영구적인 자료의 보관 및 관리검색의 효용성을 제고시키며 업무의 효율화를 도모한다. 영상자료의 데이터베이스화를 통해 자료에 대한 Text 및 내용기반 검색, 관리 시스템을 도입함으로써 업무의 효율성을 제고시키며, 영상자료에 대한 지식 자산으로서의 가치를 증대시키며, 영상자료에대한 관리기능을강화한다. 또한, 아카이브 시스템의 도입을 통해 아날로그 테잎(베타캠, 유매틱테잎)의 저장 및 보관에 따르는 문제를 해결하게 됨으로써 적은 공간에 많은 양의 영상을보관 할 수 있으며, 저장 비용의 감소 효과를 가져 올 수 있다.

출처 : Tong - koil000님의 기본통

성능향상을 위한 asp 프로그램 tips 과 정보들

2009-08-12T21:09:56Z

여러분들은 프로그램을 구현할 때 이렇게 짤 수도 있고 저렇게 짤 수 도 있습니다. 하지만, 같은 기능을 구현하더라도 소스코드를 보면 한 사람은 굉장히 간결하게 되어 있고, 다른 한 사람은 복잡하게 되어있습니다. 복잡하게 되어 있다는 것은 그 사람은 나름대로 열심히 했지만, 별루 좋지 않은 것이죠. 마치 프로그램을 짤 때 요령이 있는 사람과 그렇지 않은 사람의 차이라고 할 수 있죠. 또, 모든 프로그램이 다 그렇듯이 같은 구현된 결과가 같다고 하더라도 소스코드를 살펴보면 제각기 다르다는 것을 알 수 있습니다. 일종의 프로그래머의 개성이라고나 할까? 하옇튼, 같은 프로그램이라고 해도 성능이나 기능이 더 뛰어나도록 최적화시켜 구현하는 것이 또하나의 프로그램을 평가하는 중요한 관점입니다. 이런 말을 왜 하냐구요? 왜냐면, 우리는 잘 몰라서 혹은 생각이 거기에 미치지 못해서 평소에 프로그래밍시 쉽게 구현할 수 있는 것을 어렵게 짜는 경향이 있기 때문입니다. 여기서는 우리는 이러한 점을 감안해서 가장 기본적인 것부터 새로운 마음으로 ASP 프로그램의 팁과 테크닉을 키워봅시다.

성능향상을 위한 알아두면 좋을 ASP 프로그램 Tips

여기서 설명하는 내용은 MSDN이나 다른 여러 사이트의 게시판에서도 여기에 대한 내용을 많이 올려 놓아 있습니다. 참고하시구요. 저는 초보자를 위한 것이기에 좀더 쉬운 내용에 해당하는 몇가지 간단한 것들에 대해 쉽게 나름대로 정리해 보겠습니다.

1. Session변수를 꼭 필요할 때만 사용합시다.

세션(Session)변수는 클라이언트 즉, 사용자 한명과 서버를 일대일로 연결되어 있는 전역변수입니다. 즉, 그 사용자가 웹서버에 접근했을 때 생성되어, 브라우저를 종료할때까지 살아있습니다. 물론, 서버측에서 강제로 종료시킬 수도 있지만, 보통은 그렇죠. 만약, 많은 사용자들이 서버에 접근한다면, 세션변수에 의한 서버의 부하는 엄청 늘어나게 됩니다. 이를 대비하여 되도록 세션변수의 사용은 피하되 가급적 간단한 값을 저장하라는 것입니다. 예를 들어 ADO 개체같은 것은 다음과 같이 사용하지 마라는 것입니다.

set Conn = Server.CreateObject("ADODB.Connection")

Conn.Open "test", "", ""

set Session("qna_db") = Conn

2. 생성된 개체는 반드시 해제 시켜야 합니다.

우리는 Server.CreateObject와 같은 방법을 이용해서 개체를 생성하고 이를 사용했습니다. ADO개체나 서버컴포넌트와 같은 개체가 그 예입니다. 지난 호에서도 설명했듯이, 개체를 쓰고 난 뒤에는 반드시 Close, set 변수=Nothing을 사용해서 해제시켜 주어야 합니다. 그래야만 서버가 힘들어하지 않으니깐요.

set Conn = Server.CreateObject("ADODB.Connection")

...

Conn.Close

set Conn=Nothing

3. SSI는 자주 반복되는 경우에만 사용합시다.

SSI (Server Side Include)는 보통 과 같은 방식으로 사용되며, 반복적인 작업이 있을 경우 사용됩니다. 특히, DB를 연결시에 해당되는 코드는 항상 반복되는 작업이므로 위와같이 인클루딩을 통해서 처리하곤 합니다. 그러나, 이러한 SSI는 아주 필요한 곳 이외는 가급적 사용하지 말아야 합니다. ASP는 IIS에서 컴파일하기 때문에 ASP의 파일 크기가 커지면 컴파일하는데 속도가 느려지게 됩니다. 예를들어, 하나의 ASP파일 안에 여러개의 SSI가 있으면 당연히 속도가 느려지겠죠?

4. 변수를 꼭 정의합시다.

ASP는 변수를 정의하지 않고 바로 사용할 수 있습니다. 아무런 문제가 없죠. 하지만, 되도록 Dim문을 이용해서 변수를 정의해서 사용하는 게 좋다고 합니다.

5. 문자열 경로를 사용합시다.

Server.MapPath를 사용하여 서버의 물리적 경로를 알아내곤 했습니다. 이것도 역시 꼭 필요할 때 사용해야겠네요. 왜냐면, IIS는 경로를 알아내기 위해서 엄청난 고생을 하게 되기 때문이죠.

6. 서버변수의 사용을 줄입시다.

서버변수를 이용할때는 필요한 변수만 액세스하는 것이 아니라 모든 서버변수를 가져오기 때문에 성능 저하가 일어납니다. 즉, 처음 호출시에는 이러한 일이 일어나죠. 다음 번부터 호출할 때에는 이러한 성능저하가 없다고 합니다.

7. 반복적으로 사용하는 Request의 Collection은 변수를 이용합시다.

아래 예제와 같이 여러번 반복적으로 Collection값을 사용할 필요가 있을 경우에는 option=Request.Form("Option")과 같은 방법으로 변수에 저장하여 사용하면 속도의 향상을 가져올 수 있습니다. 여러번 서버에 요청해서 가져오는 것보다 한번 요청하는 것이 훨씬 빠르겠죠?

If Request.Form("Option")="1" Then

...

End If

...

If Request.Form("NAME")="10" Then

...

End If

8. 되도록 Option Explicit을 씁시다.

ASP는 원래 변수를 선언하지 않고 사용할 수 있습니다. 하지만, 이는 속도저하를 초래합니다. 그래서 습관적으로 <%Option Explicit%>라고 써 주고, 변수를 Dim으로 선언하는 것이 좋습니다. Option Explicit는 변수를 선언하지 않으면 에러를 발생시킵니다.

9. 가능하면 클라이언트 사이드 스크립트로 처리합시다.

서버사이드 스크립트는 ASP와 같이 서버에서 실행되는 스크립트 언어이고, 자바스크립트나 VB스크립트는 클라이언트에서 실행되므로 클라이언트 사이드 스크립트라고 합니다. 우리가 지금 ASP를 배우고 있기는 하지만, 굳이 ASP로 처리하지 않아도 되는 기능들이 있습니다. 예를 들어, 아이디와 패스워드를 입력 받을때 빈 문자열을 검사하여 사용자의 입력이 제대로 되었는지를 체크할 때, 혹은 브라우저가 IE인지 Netscape인지를 체크할 때, 우리는 자바스크립트나 VB스크립트를 이용함으로써, 서버에서 실행되는 불필요한 코드들을 생략함으로써 성능을 향상시킬 수 있습니다.

10. 항상 테스트합시다.

프로그램의 코드를 수정했다면 꼭 테스트 해 보는 습관이 중요합니다. 코드의 변경에 따라 성능의 차이를 알아보고, 다시 고쳐나가는 것이 좋습니다. 저의 경험으로 똑같은 결과를 나타내는 코드를 다른 방식으로 바꾸었을 때 엄청난 속도차이가 나는 것을 알 수 있었습니다. 이렇게 테스트해 봄으로써 좀더 좋은 성능을 가지게 할 수 있을 것입니다.

알아두면 유용한 ASP 활용 Tip&Tech

ASP 프로그래밍 시에 알아두면 프로그래밍이 쉬워지는 팁과 테크닉을 알아보죠. 여러분들이 평소에 궁금했던 내용들이 모두 이 안에 있었으면 하네요.

SSI(Server Side Include) 이용

위에서 SSI는 필요할때만 사용하라고 했습니다. 이것에 대해 좀더 자세히 알아봅시다. DB에 연결시켜주는 코드나 또는 자주 사용하는 함수를 파일에 저장해두고 이것을 필요할 때 가져와 사용하면 훨씬 코드도 간단해지고, 성능도 개선되겠죠? 다음을 살펴봅시다.

다음과 같은 DB연결 코드를 입력하고 Dbconn.inc라는 이름으로 저장합니다.

set Conn = Server.CreateObject("ADODB.Connection")

Conn.Open("Maso")

위의 코드가 필요한 곳에다가 다음과 같이 를 적어주면 됩니다.

Set rs=Conn.Execute("Select * From board")

...

자주 사용하는 함수도 마찬가지로 하면 됩니다. 여기서 뒤의 확장자는 굳이 inc로 할 필요는 없습니다. txt나 다른 확장자를 사용해도 되지만, 왠만하면 많이 사용하지 않는 확장자의 형태를 취하는 것이 속도면에서 좋습니다. 왜냐하면, 컴파일시에 빨리 인식하기 때문이죠.

Replace로 문자 바꾸기

보통 게시판을 만들 때, 특정 문자를 변환할 필요가 있습니다. 이 경우, 이 함수를 사용하면 쉽게 해결 할 수 있습니다. 게시판에서 만약, content라는 변수에 글의 내용이 저장되어 있고, 이를 DB에 저장할 경우, '''나 '|'는 에러를 일으킬 수 있습니다. 그렇기 때문에, 이 두 문자는 Replace문을 이용하여 다음과 같이 변환 시켜 저장합니다.

content=Replace(content, "'", "''")

content=Replace(content, "|", "|")

이렇게 하고 난 뒤 DB에서 가져와 보여줄때는 그냥 그대로 가져오면 됩니다. 왜냐하면, 저장될 때에는 원래 그대로 저장되기 때문입니다. 그냥 레코드에서 읽어와서 <%=rs("Content")%>하시면 원래대로 출력됩니다. 이것은 이미 지난호의 Q&A게시판 예제소스를 보시면 될 것입니다.

게시판의 글을 올릴때, HTML태그를 이용해서 글을 쓰면 그대로 먹혀 나타나게 됩니다. 그래서 만약 HTML이 먹히지 않게 하고 싶다면 다음과 같이 하면 됩니다. 이 코드를 DB에 저장할 때 또는 불러올 때 어느 한 경우에 사용하면 나타나는 결과는 같습니다.

content=Replace(content, "<", "<")

content=Replace(content, ">", ">")

다음과 같이 HTMLEncode를 사용해도 같은 결과가 나타납니다.

<%content = Server.HTMLEncode(content)%>

게시판에서 줄바꾸기

게시판에서 글보기를 했을 때, 모든 글이 한줄로 붙어버리는 경우가 있습니다. 이를 방지하기 위해서는 엔터를 인식하게하여 줄바꾸기를 해 주어야합니다. 물론, Replace문을 사용하면 되겠죠. 여기서 Chr(13)&Chr(10)은 엔터를 의미합니다. 주의할 점은, 글 수정시에 다시 원래대로 바꿔주어야 한다는 것입니다.

<%content= Replace(Request("content"), Chr(13)&Chr(10), "
")%>

하이퍼링크로 특수 문자 보내기

저에게 어떤 분이 이렇게 질문하셨더군요. "temp.asp?code=aaaa에서 aaaa라는 값을 넘겨 줄때 +, - 기호가 있으니까 이상하게 변합니다. 연산자는 넘겨 줄 수 없는건지 아님 다른 방법이 있는 겁니까? 예를 들면 넘겨줄 값이 "aa-aa" 라면은 처리가 이상하게 됩니다."라구요. 물론, 해답은 간단히, Server.URLEncode를 사용하시면 됩니다. 물론, 다른 방법도 있지만, 이게 제일 간단하고 쉬운 방법입니다.

">test

ODBC없이 DB연결하기

지난 호에서 MS-Access로 ODBC를 연결하여 DB에 접근하는 방법을 공부했습니다. ODBC를 연결해 줄려니 귀찮기 짝이 없었겠지요. 그래서 바로 연결하는 방법이 있습니다.

MyDB = "C:\Inetpub\wwwroot\Maso.mdb"

DbConn = "Driver={Microsoft Access Driver (*.mdb)}; DBQ=" & MyDB

Set Conn = Server.CreateObject("ADODB.Connection")

Conn.Open(DbConn)

왜 Refresh가 안될까?

ASP 프로그램을 하다보면 브라우저로 직접보고 수정을 해야합니다. 디버깅이 좀 불편하죠. 안 그래도 원하는 대로 결과가 안나와서 짜증나는데, 계속 예전에 불러졌던 화면이 브라우저에 나타날때는 정말 미칠지경까지 갈 겁니다. 이것은 브라우저의 캐시기능 때문입니다. 브라우저는 기본적으로 캐시기능이 설정되어 있어서 한번 불러온 웹페이지는 다음에 접근했을 때, 임시디렉토리에 저장되어있던 예전의 것을 가져와 보여주기 때문입니다. 물론, HTML에서 Meta 태그로 캐시기능을 제어하는 게 있지만, 그렇게 잘 듣지 않는 걸로 알고 있습니다. 그러나, ASP에서는 이것도 쉽게 제어가 가능하지요. <%Response.Expires="0"%>를 을 포함한 모든 코드의 맨 위에다가 두면 됩니다. 이것은 디버깅할 때나 자주 업데이트되는 사이트에서 사용하면 좋지만, 그렇지 않은 경우에는 필요가 없습니다.

문자열 Split으로 나누기

만약, 계산기를 만들 때, 연산기호를 빼내고 숫자만 가져올려면면 어떻게 해야 할까요? 일단은 텍스트 박스로 입력을 받고 난뒤에 Replace문으로 연산기호들은 특정문자(여기서는 "|"로 구분)로 대체하고 Split 함수로 나누면 됩니다. 다음과 같이 하면, val은 배열변수로 바뀌며 val(0)=1, val(1)=2, val(2)=33, val(3)=21으로 저장됩니다. 이것을 주민등록번호 앞자리와 뒷자리 구분과 같이 다른 곳에서도 응용할 수 있습니다.

val="1+2*33/21"

val=Replace(val, "+", "|")

val=Replace(val, "-", "|")

val=Replace(val, "*", "|")

val=Replace(val, "/", "|")

val=split(val,"|")

특정 시간 내에 있는 게시물 보여주기

DB에있는 시간과 현재의 시간을 비교하여 DB에 있는 시간이 현재의 시간보다 24시간 이내일 경우 해당 DB내용을 WEB에 Display할려고 하면 어떻게 해야 할까요? 다음 예제를 봅시다.

i=1

Do until rs.EOF or i>rs.pagesize

If Datediff("h",rs("datetime"), now()) < 24 then

게시물 출력

rs.MoveNext

i=i+1

end if

loop

DateDiff문은 두 날짜 사이의 간격을 되돌려 주는 함수입니다. 첫 번째 인자 'h'는 시간을 나타냅니다. 두 번째 인자(rs("datetime"))과 세 번째 인자 현재시간(now())의 차이를 시간으로 되돌려줍니다. 물론, 'h' 대신 'n'을 쓰면 분을 나타내고 's'를 쓰면 초를 나타냅니다. 이 함수에 대한 자세한 설명은 지난호 이달의 디스켓에 첨부된 VB스크립트 도움말을 참조하십시오.

Redirect에서 여러 값을 한꺼번에 넘기기

Redirect는 단지 특정 URL로 이동시켜주는 역할을 합니다. 여기에 값을 같이 넘겨줄려면 보통 하이퍼링크에서처럼 값을 넘겨주면 되죠. 그런데, 여러 개의 값을 넘겨줄려면 어떻게 해야 할까요? 다음과 같이 &만 잘 써주면 됩니다.

id=request("id")

pwd=request("pwd")

Response.Redirect "check.asp?id="&id&"&pwd="&pwd

Redirect로는 Target이 없다.

물론입니다. Redirect는 Target을 설정할 수 없습니다. 대신 자바스크립트나 VB스크립트를 써야 합니다.

VB스크립트나 자바스크립트에서의 ASP 변수값 넘기기.

ASP프로그래밍시에 자바스크립트나 VB스크립트안에서 ASP의 변수값이 필요가 있을 때가 있습니다. 이럴 때는 다음과 같이 하면 됩니다.

url="test.asp"

target="NewWindow"

아직도 Y2K 버그?

게시판의 날짜를 보니깐 00-09-01로 나온다면, 이것은 Y2K버그입니다. 하하, 농담이구요. 이것은 쉽게 수정할 수 있습니다. 일단, 제어판을 선택하고 국가별 설정이라는 것을 클릭하면 여러가지 탭 메뉴가 나오는데 거기서 날짜 탭을 선택하고 yyyy-MM-dd의 형태로 바꾸어 주시면 됩니다.

쿠키 확인하기.

클라이언트의 쿠키가 사용 가능한지 확인하는 방법이 있습니다. 일반적으로 세션이 지원되면, 쿠키도 가능합니다.

session("check") = "IsCookie" '세션변수에 아무 값이나 넣는다.

if IsEmpty(session("check")) then '세션값이 없다면 쿠키사용안함

<%end if%>

세션 배열 사용하기.

세션으로 배열을 저장할 수 있습니다. 다음과 같이하면 배열변수에 저장되어 있는 모든 배열값들이 세션에 저장됩니다. 다시 불러올때는 배열변수에서 값을 불러오는 방법과 마찬가지로 불러오면 됩니다.

Dim temp(3)

temp(0)="사과"

temp(1)="복숭아"

temp(2)="배"

Session("Fruit")=temp

<%For i=0 To UBound(Session("Fruit"))%>

<%=Session("Fruit")(i)%>

<%Next%>

SiteGalaxy 업로드 서버 컴포넌트 이용하기.

예전에 Q&A 게시판에서 파일을 업로드하기위해 Fileman.dll이라는 서버 컴포넌트를 사용했었습니다. 이번에는 그것보다는 훨씬 설치하기가 쉽고 사용하기 편리한 사이트 갤럭시 서버 컴포넌트의 이용법을 알아보겠습니다. 사이트 갤럭시 컴포넌트는 setup.exe를 실행시키면 자동적으로 설치가 되기 때문에 Regsvr32로 등록절차를 생략하셔도 됩니다. Default로 설치하면, c:\program files\sitegalaxy\sample에 업로드 예제 ASP파일이 있습니다. 그걸 참고하셔도 좋구요. 다음은 사이트 갤럭시를 이용하여 이미지 파일을 업로드하는 예제입니다. 사이트 갤럭시 컴포넌트는 이달의 디스켓을 참고하십시오.

'SiteGalaxy Upload 콤포넌트 세팅

set UploadForm = Server.CreateObject("SiteGalaxyUpload.Form")

'Check that the form has correct type

if UploadForm.ContentDisposition <> "form-data" then

Response.Write("당신의 사용하시는 브라우져가 옛날 버전이거나 파일 uploading을 지원하지 않습니다.")

Response.End

end if

strDirectory = "G:\IMG\" '저장할 디렉토리

if UploadForm("ImageFile").Count <> 1 then %>

파일이름이 없습니다. 다시 해 주세요.

<%Else

'파일크기를 제한

if UploadForm("ImageFile").Size > 10*1024 then

Response.Write("Image size is limited to 10K")

Response.End

end if

'파일 이름을 세팅

attach_file = UploadForm("ImageFile").FilePath

filename = Mid(attach_file, InstrRev(attach_file, "\") + 1)

'올리는 파일이름만 뽑아냄.

strFile2 = Mid(filename ,1, Instr(filename , ".")-1)

'파일 확장자를 제거한 파일 이름을 구함.

strExt = Mid(filename ,Instr(filename , ".")+1)

'확장자를 구함.

'파일시스템 객체 생성

Set fso = CreateObject("Scripting.FileSystemObject")

bExist = True

'만약 파일이 존재하면

strFileNameTemp = strDirectory & filename

'저장할 파일의 완전한 이름을 만듦

countfilename = 0

'파일이 존재할 경우, 이름 뒤에 붙이 숫자를 세팅함.

While bExist = True ' 우선 있다고 생각함.

If (fso.FileExists(strFileNameTemp )) Then '파일이 있다면

'Response.Write strFileNameTemp & "이(가) 있습니다.
"

'파일 이름에 숫자를 붙인 새로운 파일 이름 생성(파일명 중복 방지)

countfilename = countfilename + 1

strFileNameTemp = strDirectory & strFile2 & countfilename & "." &

strExt

else '파일이 없다면

'Response.Write strFileNameTemp & "이(가) 없습니다.
"

strFile2 = strFile2 & countfilename

bExist = False '파일이 존재하지 않으므로 False.

End If

Wend

Set fso = nothing ' Scripting.FileSystemObject를 닫아줌.

strFileName = strFileNameTemp '위에서 구한 이름을 저장할때 사용하기 위해

'저장할 파일이름을 만듦.

on error resume next

'파일을 저장한다.

nLen = UploadForm("ImageFile").Size

UploadForm("ImageFile").SaveAs strFileName

Upload File 정보
사용자의 파일이름	<%=attach_file%>
서버의 파일이름	<%=strFileName%>
파일 크기(bytes)	<%=nLen%>
파일 Type	<%=UploadForm("ImageFile").MimeType%>

set uploadform = Nothing

End If %>

-------------------------------------------------------------------------------------

박스기사:ASP 칼럼

ASP에 왠 포토샵?

홈페이지 작업에는 ASP와 같은 프로그램적인 요소도 필요하지만, 이미지 구성이나 처리와 같은 디자인 작업 또한 필요합니다. 그래서 여러분의 PC에 페인트샵이나 포토샵이 깔려 있을 경우가 있습니다. 여기서 포토샵이 문제가 되는데요. 포토샵을 설치하고 ASP파일을 클릭하게되면 이상하게도 포토샵 화면이 뜨게 됩니다. 정말 짜증나지요. 이럴 때 해결하는 방법이 있습니다. 저도 인터넷 어느 사이트에서 이 방법을 찾아 냈습니다. 바로 레지스트리를 건드리는 방법입니다.

1)시작을 클릭하고 실행을 선택하고 regedit를 실행시킵니다.

2)HKEY_CLASSES_ROOT아래에 .asp라는 이름의 키를 찾습니다. 이 키의 기본값은 "photoshop.Sep TablesFile"로 되어 있습니다.

3).asp의 기본값을 "ASPfile"이라고 바꾸고, 같은 이름의 키를 하나 추가합니다. 만들어진 키를 찾아가서 기본값을 "Active Server Page"로 고치면 이 이름이 윈도우상에서 통하는 확장자의 명칭이 됩니다.

4)EditFlags라는 이름의 [이진값]을 등록하여 값을 "00 00 01 00"으로 기입합니다. 이렇게 해주면 폴더옵션에 이 확장자가 나타나게 됩니다.

5)탐색기를 띄우고 폴더옵션에서 "Active Server Page"를 찾아 아이콘 이미지과 실행방법을 선택하면 됩니다.

ASP Error는 가라!

ASP 프로그래밍을 하다가 에러가 나면 쉽게 디버깅이 가능한 경우, 즉 문법적인 에러인 것도 있지만, 그렇지 않은 경우도 많습니다. 특히 자기가 짠 코드가 틀린게 없다고 생각하는데도 이상하게 제대로 실행이 되지 않는 경우가 허다합니다. 여러분들이 자주 만나거나 부딪히게될 이런저런 에러에 관해서 제 경험과 여러 가지 자료를 바탕으로 살펴보겠습니다. 굉장히 많은 에러가 있지만, 여기서는 몇가지만 살펴보고 나머지는 다음 사이트를 참고 하십시오.(참고사이트 : http://www.ultimateasp.com/reference/error.asp)

클라이언트 브라우저에 HTTP 헤더가 이미 쓰여 있습니다.

'HTTP 헤더가 이미 쓰여 있습니다. HTTP 헤더는 페이지 내용을 쓰기 전에만 수정해야 합니다.'라는 에러는 주로 Response.Redirect, Write구문의 잘못된 사용으로 나타납니다. 이 에러를 그대로 생각하시면 됩니다. 즉, HTTP헤더에 뭔가가 쓰여졌기때문에, 구문을 실행할 수 없다는 뜻이죠. 그러니까, Redirect 문의 경우 이나 HTML코드의 앞에 놓여져야지 된다는 것입니다. Redirect나 Write는 헤더에 쓰기 때문이지요. Write가 Redirect보다 앞에 있어도 이런 에러가 납니다. 만약 소스코드를 바꾸기가 굳이 어렵다면, 책을 찾아서 response.buffer이나 response.flush을 찾아보세요. 그럼 도움이 될 겁니다.

외부 개체 트랩오류가 발생했습니다.

이 경우는 주로 자신이 만든 ASP 서버 컴포넌트를 이용했을 때, 발생합니다. 저도 이같은 경우를 가끔 당했지요. 이건 간단히 DLL을 서버에 등록시켜주기만 하면 됩니다. 만약, 그래도 안되는 경우는 자신이 만든 서버 컴포넌트 자체에 버그나 동작이 제대로 되지 않을 경우도 있습니다.

ODBC 드라이버는 요청한 등록 정보를 지원할 수 없습니다.

이 에러는 SQL문법에 어긋났을 경우에 일어나는게 대부분입니다. 아니면, DB의 테이블 이름이나 필드명을 잘못 써서 에러가 날 수도 있습니다. 한마디로 SQL이 실행되는 문장에 에러가 있다는 것이죠. 잘 살펴보면 해결할 수 있습니다.

[Microsoft][ODBC Microsoft Access 97 Driver] .... 문(절)의 구문 오류입니다.

이 경우는 ...문(절)을 잘 살펴보면 해결방안이 나타납니다. 보통 에러는 잘못된 구문의 행을 가르쳐주니깐 그 행을 자세히 살펴보면 되겠죠. 이것도 또한 SQL문법오류이거나 지원하지 않는 함수를 사용하였을 때 발생합니다.

BOF나 EOF가 참이거나. 현재 레코드가 삭제되었습니다. 요청하신 작업은 현재 레코드를 필요로 합니다.

레코드의 유무를 판별하는 <%If Not rs.EOF%>나 <%While Not rs.EOF%>를 이용하여 에러를 잡을 수 있습니다.

ASP 가능한 Web Site

많은 분들이 ASP를 공부해서 자신의 홈페이지를 꾸밀려고 하고 있습니다. 하지만, 개인적으로 웹서버를 운영하는 것은 참으로 어려운 일입니다. 국내 여건상 서버사이드 스크립트인 ASP를 지원해주는 사이트는 없는 걸로 알고 있습니다. 그러나 너무 실망하지 마십시오. 외국에는 있으니깐요. 무료홈페이지계정에 ASP를 지원하는 사이트 두가지 입니다.

동영상변환시간

2009-08-05T09:45:55Z

삼성 관계자는 "PC성능, 화질여부, 압축률에 따라 변환시간이 달라지기 때문에 일률적인 변환시간 측정은 어렵다"며 "디빅스(DivX) 동영상 파일의 경우 코덱에 따라 변환이 가능할 수도 있고 불가능할 수도 있다"고 밝혔다.

흔히 인터넷에서 유포되는 동영상은 디빅스(DivX) 기반에 'AC3'(돌비디지털)나 'DTS'로 인코딩된 파일이 대부분이다.

관계자는 "변환시간은 PMP 기능과는 상관없이 PC사양과 관계되며, 통상적으로 파일재생시간의 절반 정도"라고 말했다.
즉 60분짜리 동영상을 보려면 30분 정도는 변환시간이 걸린다는 설명이다.

오라클 백업 및 복구

2009-08-04T10:45:31Z

1장 오라클 서버의 구조와 백업/복구원리

주종면 | 플랜정보기술

오라클 데이터베이스를 사용하다 보면 다양한 에러코드와 함께 장애가 발생하는 경우를 한두 번쯤 경험해 보았을 것 입니다. 이런 경우 대부분의 사용자들은 자신이 알고 있는 모든 지식을 기반으로 복구작업을 수행하게 됩니다. 하지만, 막연한 방법과 절차는 복구작업에 도움이 되지 않을 뿐 아니라 오히려 불필요한 시간의 낭비를 초래할 수 있기 때문에 무엇보다도 철저한 계획과 준비가 요구됩니다. 또 한가지 염두에 두어야 할 점은 다양한 장애와 복구방법에 대한 이해를 하기 전에 반드시 오라클 서버 구조에 대한 이해를 하셔야 합니다. 구조에 대한 명확한 이해 없이는 장애에 대한 복구작업을 수행할 수가 없기 때문입니다.

자~ 그럼 오라클 서버의 전체 구조와 복구 원리를 소개하도록 하겠습니다.

1-1 오라클 서버의 구조

먼저, 오라클 서버에 대한 장애와 복구를 체계적으로 습득하기 위해서는 물리적 구조에 대한 이해를 명확히 하셔야 합니다. 예를 들어, 어느날 여러분이 소유하고 계신 자동차가 갑자기 정상적으로 시동이 걸리지 않는다면 어떻게 하시겠습니까?

만약, 여러분이 자동차 구조에 대한 해박한 지식을 가지고 있다면 직접 원인을 찾기 위해 다양한 점검을 하게 되고, 또한 조치를 하게 될 것 입니다. 하지만, 자동차 구조에 대해 전혀 이해를 못한다면 이러한 경우 여러분이 할 수 있는 것은 아무것도 없을 것 입니다.

이와 같은 원리로 오라클 서버환경에서도 장애가 발생했을 때 적절한 조치와 복구작업이 수행되기 위해서는 장애가 발생한 원인을 분석할 수 있어야 합니다. 또한, 그 원인을 분석하기 위해서는 오라클 서버에 대한 철저한 이해가 요구됩니다. 다음은 오라클 서버의 기본구조에 대한 설명입니다. 오라클 서버는 다음과 같이 3가지 영역으로 구성되어 있습니다.

1) 메모리 영역

오라클 서버가 사용 가능한 상태가 되면 모든 사용자들은 데이터베이스에 접속할 수 있으며, 또한 테이블을 통해 데이터를 검색할 수 있게 됩니다. 이때, 읽혀진 테이블 정보들이 잠시 저장되는 공간이 메모리 영역 입니다. 이 공간은 SGA (System Global Area) 영역이라고 부르며 다음과 같이 4가지 영역으로 구성되어 있습니다.

• 공유-풀 영역 (Shared Pool Area)
• 데이터버퍼 캐시 영역 (Data Buffer Cache Area)
• 로그버퍼 영역 (Log Buffer Area)
• 라지-풀 영역 (Large Pool Area)
• 자바-풀 영역 (Java Pool Area)
• 스트림-풀 영역 (Stream Pool Area)

2) 프로세스 영역

사용자가 오라클 서버에 접속하기 위해서는 SQL*PLUS 또는 사용자의 애플리케이션 프로그램을 통해 접속하게 됩니다. 이때, 활성화 되는 영역을 사용자 프로세스(User Process)라고 합니다. 그리고, 사용자가 실행한 SQL문이 실행되기 위해서는 서버 프로세스(Server Process)에 의해 분석되며 테이블로부터 읽기 또는 쓰기 작업을 수행하게 됩니다.

또한, 오라클 서버가 효과적으로 운영되기 위해서 다음과 같은 백그라운드 프로세스(Background Process)가 기본적으로 제공됩니다.

• DBWR (Database Writer Process)
• LGWR (Log Writer Process)
• PMON (Process Monitor Process)
• SMON (System Monitor Process)
• CKPT (Check-Point Process)
• ARCH (Archive Process)
• RVWR
• MMAN (Memory Manager Process)
• RBAL
• ORBn
• RFS (Remote File System Proces)
• MRO

3) 파일 영역

사용자 또는 오라클 서버에 의해 생성되는 모든 테이블 정보가 저장되는 물리적 구조를 파일 영역 또는 데이터베이스(Database) 영역이라고 합니다.

다음은 오라클 서버의 기본 파일구조 입니다.

• 파라메터 파일 (Parameter File)
• 데이터 파일 (Data-File)
• 리두로그 파일 (Redo-Log File)
• 컨트롤 파일 (Control File)
• 플래시-백 데이터베이스 로그 파일 (Flash-Back Database Log File)
• 아카이브 리두로그 파일 (Archive Redo-Log File)

자~ 그럼 보다 구체적으로 오라클 서버의 각 구조를 알아 보도록 하겠습니다.

1-2 SELECT문의 처리과정

이번에는 SELECT문의 처리과정을 통해 오라클 서버의 구조를 보다 구체적으로 알아 보도록 하겠습니다. 사용자들이 실행하는 SELECT문의 결과가 리턴될 때 오라클 서버의 각 구조를 어떻게 사용하는지를 이해해 보십시오.

1) STEP-1 : Parsing

SQL*PLUS 툴을 통해 SCOTT 사용자 계정과 TIGER 암호로 오라클 서버에 접속합니다.

사용자가 실행한 SELECT문은 사용자 프로세스를 거쳐 서버 프로세스로 전송이 됩니다. 서버 프로세스는 사용자가 실행한 SELECT문에 대해 다음과 같이 구문분석(Parsing) 작업을 수행합니다.

<구문분석>
(1)	메모리 영역 중에 공유-풀 영역을 검색하여 사용자가 실행한 문장과 동일한 문장이 존재하는지 확인합니다. 동일한 문장이 발견되면 구문분석 작업을 중단하고, 동일한 문장이 발견되지 않으면 다음 단계의 작업을 계속 수행합니다.

(2)	사용자가 실행한 SELECT문의 문법을 확인합니다.

(3)	SELECT문에 작성된 테이블과 컬럼 들이 사용가능한지 확인합니다.

(4)	해당 사용자가 테이블과 컬럼 들을 검색할 수 있는 권한이 있는지 확인합니다.

(5)	모든 검증작업이 완료되고 나면 구문 분석된 결과를 공유-풀 영역에 저장합니다. 분석결과를 저장하는 이유는 다른 사용자에 의해 동일한 문장이 재 실행되는 경우 구문분석 작업을 재 수행하는 불필요한 작업을 피하게 함으로써 SELECT문의 실행성능을 빠르게 하기 위함 입니다.

2) STEP-2 : Execution

해당 테이블이 저장되어 있는 데이터 파일로부터 데이터를 읽어서 메모리 영역인 데이터-버퍼 캐시 영역(Data-Buffer Cache Area)에 저장해 둡니다. 먼저, 테이블과 데이터 파일과의 관계를 이해하기 위해서는 다음 문장에 대한 이해가 필요합니다.

SQL> CREATE TABLESPACE insa
DATAFILE 'C:\ORACLE\ORADATA\ORA92\INSA01.DBF' SIZE 10M;
→ 인사 업무에 관련된 테이블이 저장될 공간

SQL> CREATE TABLE emp
(EMPNO NUMBER(4),
ENAME VARCHAR2(15))
TABLESPACE insa;
→ EMP 테이블이 저장될 공간은 INSA 테이블스페이스 입니다. 다른 의미로 표현한다면
EMP 테이블이 저장될 공간은 INSA01.DBF 파일입니다.

3) STEP-3 : Fetch

STEP-2 단계에 의해 데이터 버퍼 캐시영역에 저장되어 있는 데이터를 읽어서 사용자의 SQL*PLUS 화면에 출력해 주는 단계를 인출(FETCH)라고 합니다. 이 단계는 SELECT문을 실행하는 경우에만 수행되며 UPDATE, DELETE, INSERT문을 실행할 때는 수행되지 않습니다. 즉, SQL문을 실행한 후 처리된 결과가 화면에 출력되는 것을 인출이라고 합니다.

1-3 DML문의 처리과정

이번에는 DML문 (UPDATE, INSERT, DELETE)의 처리과정에 대해 자세히 알아 보도록 하겠습니다. 사용자가 실행한 DML문에 대해 구문분석을 수행하는 단계까지는 SELECT문과 동일한 방법과 절차에 의해 수행됩니다.

먼저, 처리과정에 대해 알아보기 전에 DML문에서 만 사용되는 오라클 서버의 기본구조에 대해 알아 보겠습니다.

[C:\] sqlplus SCOTT/TIGER
SQL>	UPDATE emp SET sal = sal * 1.1 WHERE empno = 7934;
SQL>	SELECT * FROM emp WHERE empno = 7934; 7934 KING 1100

SQL>	ROLLBACK;
SQL>	SELECT * FROM emp WHERE empno = 7934; 7934 KING 1000

SQL 문장 중에 DML문들은 항상 실행한 후 COMMIT 또는 ROLLBACK문을 실행해야 해당 트랜잭션이 종료됩니다. 위 예제와 같이 UPDATE 문을 실행한 후 ROLLBACK문을 실행하게 되면 변경되었던 모든 행 정보는 취소됩니다. 이러한 과정을 처리하기 위해서는 UPDATE문이 실행될 때 마다 변경 전 데이터 (7934 KING 1000)와 변경 후 데이터(10 KING 1100)를 모두 어딘가에 저장해 두었다가 ROLLBACK문을 만나는 순간 변경 전 데이터로 변경 후 데이터를 복구해야 할 것 입니다. 이때 변경 전 데이터를 잠시 저장해 두는 공간을 롤백-세그멘트(Rollback Segment) 또는 언두 세그멘트(Undo Segment)라고 합니다. 위 그림에서 데이터 파일에 생성되어 있는 RBS01은 언두 세그멘트 입니다. 현재, 위 그림의 공유-풀 영역을 보면 사용자가 실행한 UPDATE문의 구문 분석된 결과가 저장되어 있으므로 UPDATE문이 파싱까지 수행되어 있는 것을 알 수 있습니다.

1) STEP-1/STEP-2

데이터 파일로부터 해당 테이블을 읽어 행 데이터를 데이터 버퍼 캐시영역에 저장합니다.
이때, 메모리에 저장되는 행 데이터에 대한 변경 작업을 수행하기 위해서는 만약 변경 작업 후 ROLLBACK문을 수행할 것을 대비하며 변경 전 데이터를 저장해 둘 수 있는 언두 세그멘트의 공간을 확보해 두어야 합니다. 위 그림에서 RBS01 데이터 파일과 데이터 버퍼 캐시영역에 일정한 공간을 확보합니다.

2) STEP-3

공유-풀 영역을 구성하는 데이터 딕션어리 캐시영역 (Data Dictionary Cache Area)은 사용자가 실행한 DML문의 구문분석을 수행하기 위한 테이블 정보와 락(Lock) 정보를 저장해 주는 메모리 영역입니다.
UPDATE문을 실행했을 때 어떤 행에 락(LOCK)이 발생하였는지를 기록해 두었다가 다른 사용자들이 똑 같은 행 데이터에 대해 변경작업을 수행하려고 하면 더 이상 작업을 수행하지 못하도록 DML문을 대기상태로 만들게 됩니다.

3) STEP-4

마지막 단계는 리두로그 버퍼영역에 변경 전 데이터(1 주종면 100)와 변경 후 데이터(1 주종면 110)를 모두 백업(Backup)하게 됩니다.(이렇게 모든 변경정보를 백업하는 이유는 "백업과 복구 원리"에서 자세히 소개됩니다.)

1-4 COMMIT문의 처리과정

마지막으로 DML문을 수행한 후 트랜잭션(Transaction)을 종료하기 위해 실행하는 COMMIT 문의처리 과정에 대해 자세히 알아보도록 하겠습니다.

1) STEP-1

사용자가 DML문을 실행한 후 COMMIT문을 실행하면 서버 프로세스로 전송됩니다.

2) STEP-2

서버 프로세는 로그버퍼 영역에 백업되어 있는 데이터에 대해 시스템 변경번호(System Change Number)를 부여합니다. 사용자가 COMMIT문을 수행할 때 마다 오라클 서버에 의해 연속적으로 부여되며 해당 트랜잭션이 데이터베이스 생성 후 몇 번째로 COMMIT 된 것인지를 나타냅니다. (SCN의 사용 용도에 대해서는 "백업과 복구 원리"에서 자세히 설명됩니다.)

3) STEP-3

일정한 시점이 되면 LGWR는 로그버퍼 영역에 백업되어 있는 데이터를 리두로그 파일로 저장합니다. 왜냐하면, STEP-2 단계에서 언급한대로 리두로그 버퍼는 사용자들이 실행한 DML문에 의해 발생한 모든 변경된 데이터를 저장하는 공간인데, 만약, 시스템이 갑자기 정전되면 리두로그 버퍼에 저장되어 있던 모든 데이터들이 유실되기 때문입니다. 그래서, 일정시점이 되면 LGWR 프로세는 리두로그 버퍼의 데이터들을 영구히 저장될 수 있는 운영체계 상의 리두로그 파일로 저장하게 되는 것 입니다.

다음은 LGWR가 리두로그 버퍼의 내용을 리두로그 파일로 저장하는 시점의 경우입니다.

• 사용자가 COMMIT문을 실행하는 경우
• 매 3초가 지날 때 마다 오라클 서버에 의해 실행되는 경우
• CHECKPOINT가 발생하는 경우
• 오라클 서버가 정상적으로 SHUTDOWN 되는 경우

4) STEP-4

LGWR 프로세스에 의해 리두로그 파일에 백업 데이터가 저장되고 나면 사용자의 화면에 "Commited"라는 메시지를 출력하게 됩니다.
즉, "커밋 되었습니다"라는 메시지의 의미는 변경 데이터를 테이블에 저장했다는 의미가 아니라 관련 데이터를 백업했다는 의미를 가지고 있습니다.

5) STEP-5

LGWR 프로세스가 리두로그 버퍼의 모든 데이터를 리두로그 파일에 기록하지 못한 경우에는 다음 리두로그 파일로 이동하여 계속적으로 데이터를 기록하게 됩니다.

6) STEP-6

LGWR 프로세스가 하나의 리두로그 파일에 모든 로그버퍼의 데이터를 저장하지 못하면 다음 로그파일로 이동하게 되는데 이때 CKPT 프로세스는 체크포인트(CHECKPOINT)를 발생시켜 현재 시점까지의 모든 변경 상태를 컨트롤 파일(Control File)과 데이터 파일(Data File)에 기록하게 됩니다. (모든 변경상태를 기록해 두는 이유는 "백업과 복구 원리"에서 자세히 설명됩니다.)

7) STEP-7

DBWR 프로세스는 데이터 버퍼 캐시영역에 저장되어 있는 테이블의 변경 후 데이터를 최종적으로 테이블에 기록하게 됩니다.

1-5 오라클 서버의 시작과 종료

지금까지 사용자가 실행하는 SELECT문, DML문, COMMIT문의 처리과정을 통해 오라클 서버의 각 구조가 어떤 역할을 하게 되는지 자세히 알아 보았습니다.

이번에는 오라클 서버의 시작과 종료단계에 대해 보다 구체적인 이해를 해 보도록 하겠습니다. 또한, 기본구조를 설명하면서 소개되지 않았던 다른 구조들과 시작과 종료의 기본 원리에 대해서도 함께 소개될 것 입니다.

오라클 데이터베이스를 사용하면서 발생하는 장애에 대한 원인을 쉽게 파악하고 복구 절차를 이해하기 위해서는 지금부터 소개 드리는 내용이 매우 중요합니다.

1)NOMOUNT 단계

STARTUP 명령어에 의해 오라클 서버를 시작하는 첫 번째 단계를 NOMOUNT 단계라고 합니다. 이 단계를 수행하게 되면 오라클 서버의 기본구조 중에 메모리 영역(SGA 영역)과 백그라운드 프로세스가 사용 가능한 상태로 활성화 됩니다.

결론적으로 메모리 영역이 활성화 되기 위해서는 데이터 버퍼 캐시영역과 로그버퍼 영역 그리고, 공유-풀 영역을 활성화 해야 하며 각 영역에 대한 크기를 결정해야 할 것 입니다.

각 메모리 영역의 크기는 initora 파라메터 파일을 참조하면 다음과 같은 파라메터 값을 참조하게 됩니다.

[C:\] EDIT initORCL.ora

SHARED_POOL_SIZE		= 33000000	← 공유-풀 영역의 크기를 결정
LOG_BUGGER		= 8192	← 로그버퍼 영역의 크기를 결정
DB_CACHE_SIZE		= 33000000	← 데이터 버퍼 캐시영역의 크기를 결정

(1)	init.ora 파라메터 파일을 읽어 관련된 파라메터 값을 참조합니다.
(2)	관련 파라메터 값을 기반으로 SGA 영역을 활성화 합니다.
(3)	관련 파라메터 값을 기반으로 백그라운드 프로세스를 활성화 합니다.
(4)	BACKGROUND_DUMP_DEST 파라메터가 지정하는 경로에 있는 ALERT_.LOG 파일에 데이터베이스의 시작과 관련된 모든 로그 정보를 기록해 둡니다.

만약, init.ora 파라메터 파일을 읽을 수 없다면 어떻게 될까요 ?

[C:\] CD C:\ORACLE\ORA92\DATABASE
[C:\] MOVE initORCL.ora initORCL.bak
[C:\] sqlplus "/as sysdba"
SQL> STARTUP
ORA- ERROR
→ NOMOUNT 단계를 수행하기 위해서 init.ora 파일을 읽어야 하지만 파라메터 파일은 이미 MOVE 된 상태이기 때문에 읽을 수가 없습니다.

2) MOUNT 단계

오라클 서버의 두 번째 시작 단계를 MOUNT 단계라고 합니다. 이 단계는 현재 데이터베이스의 모든 상태 정보를 읽어오게 됩니다.

(1)	먼저, 오라클 데이터베이스의 모든 상태정보를 저장하고 있는 컨트롤 파일을 읽습니다.

(2)	오라클 데이터베이스의 환경을 결정하는 init.ora 파라메터 파일을 읽습니다.

(3)	컨트롤 파일과 파라메터 파일에 저장되어 있는 여러가지 환경 정보(DB_NAME 명)가 일치하는지를 검증합니다. 만약, 이 단계에서 환경정보가 일치하지 않으면 MOUNT 단계는 실패하게 되고 사용자들은 데이터베이스를 사용할 수 없게 됩니다. 그러므로, init.ora 파일 내에 환경설정 정보를 임의로 변경해서는 안됩니다.

(4)	기타, 데이터 파일과 리두로그 파일의 이름과 경로, 현재 상태정보도 읽습니다.

만약, control01.ctl 컨트롤 파일을 읽을 수 없다면 어떻게 될까요 ?

[C:\] CD C:\ORACLE\ORADATA\ORA92
[C:\] MOVE control01.ctl control01.bak

[C:\] sqlplus "/as sysdba"
SQL> STARTUP

ORA- ERROR
→ MOUNT 단계를 수행하기 위해서 control01.ctl 파일을 읽어야 하지만 컨트롤 파일은 이미 MOVE 된 상태이기 때문에 읽을 수가 없습니다. NOMOUNT 단계 수행 후 MOUNT 단계를 수행하지 못해 에러가 발생합니다.

3) OPEN 단계

오라클 서버의 마지막 시작 단계를 OPEN 단계라고 합니다. 이 단계는 MOUNT 단계에서 수집한 데이터베이스의 상태정보가 정상적인지 확인하는 작업을 수행하게 됩니다.
예를 들어, 컨트롤 파일 내에는 SYSTEM 테이블스페이스가 c:\oracle\oradata\ora92\users01.dbf 파일로 존재한다는 상태 정보를 가지고 있는데, 실제 운영체계 상의 해당 경로에 해당 파일이 존재하는지를 검증하게 됩니다.
참고로, SQL*PLUS 상에서 테이블스페이스를 생성하게 되면 관련된 모든 정보가 컨트롤 파일에 저장됩니다. 이렇게 저장하는 이유는 데이터베이스의 시작단계에서 사용자가 생성한 테이블스페이스 인지를 검증하기 위해서 입니다. 컨트롤 파일에 정의되어 있는 파일 및 경로가 운영체계 상에 실제 파일 및 경로로 존재하지 않으면 데이터베이스를 더 이상 OPEN 하지 않으며 사용할 수 없게 됩니다.
만약, 모든 상태정보가 일치한다면 사용자들은 오라클 서버에 접속할 수 있게 되고 또한 테이블을 검색 및 조작할 수 있게 됩니다.

만약, system01.dbf 데이터 파일을 읽을 수 없다면 어떻게 될까요 ?

[C:\] CD C:\ORACLE\ORADATA\ORA92
[C:\] MOVE users01.dbf users01.bak
[C:\] sqlplus "/as sysdba"
SQL> STARTUP
ORA- ERROR c:\oracle\oradata\ora92\users01.dbf
→ OPEN 단계를 수행하기 위해서 컨트롤 파일에 정의되어 있는 데이터 파일의 상태정보와 실제 운영체계 상의 파일의 상태정보가 일치 하는지를 확인하게 됩니다. SYSTEM01.DBF 데이터 파일은 이미 MOVE 된 상태이기 때문에 읽을 수가 없습니다.

1-6 백업과 복구 원리

데이터베이스를 운영하다 보면 예상하지 못한 시스템 에러나 사용자의 실수 또는 갑작스런 정전 등과 같은 주변환경의 문제로 인해 더 이상 데이터베이스를 운영할 수 없는 상황에 부딪히게 됩니다. 이런 경우가 발생하더라도 데이터베이스 관리자는 사용자의 데이터를 안전하게 복구할 수 있는 준비를 평소에 해야 하는데 오라클 데이터베이스에서는 여러 가지 백업과 복구방법을 제공하고 있습니다. 자신이 운용하는 데이터베이스가 어떤 성격의 데이터를 가지고 있으며, 얼마나 많은 데이터를 가지고 있는지, 장애가 발생한 경우 데이터의 복구시간이 더 중요한지 아니면 데이터의 복구율이 더 중요한지를 잘 이해하고 분석하여 적절한 백업 방법을 준비해야 합니다.

다음은 오라클 서버구조에서 사용자들이 실행하는 DML문에 의해 변경되는 데이터들에 대한 백업과 복구 원리에 대해서 알아 보도록 하겠습니다.
오라클 데이터베이스의 구조에서 로그버퍼 영역에는 사용자가 DML문을 통해 변경한 모든 데이터가 백업되며 로그기록기(LGWR)에 의해 로그파일에 저장됩니다. 로그버퍼와 로그파일에 변경 전 데이터와 변경 후 데이터 모두를 저장하는 이유는 갑작스런 시스템 에러나 사용자 실수, 정전 등으로부터 데이터베이스가 다운되거나 시스템이 다운될 때 변경된 데이터가 미처 테이블에 저장되지 못 했을 경우를 위해 백업작업을 수행하는 것입니다. 이런 경우, 모든 변경 데이터는 리두로그 파일에 저장되어 있다가 데이터베이스가 다시 정상적으로 시작될 때(STARTUP) 리두로그 파일에 저장되어 있던 데이터를 통해서 데이터를 복구하게 됩니다.

예를 들어, 대부분의 사용자들은 한두 가지의 워드 프로세스 툴을 사용하고 계실 것 입니다. 만약, 여러분이 자신이 수행하고 있는 업무에 대해 담당 관리자에게 보고서를 제출하기 위해 열심히 워드 프로세스 작업을 수행하고 있다고 가정해 보십시오.
약 10장 정도의 보고서를 작성하고 있는데 갑자기 정전이 되었다고 생각해 보십시오. 불행하게도 지금까지 작성한 보고서를 미처 저장도 하기 전에 정전이 되었다면 그때까지 입력한 모든 문서들은 삭제가 되고 말 것입니다. 바로 이런 문제를 해결하기 위해서는 워드 프로세스 툴의 환경설정에서 사용자가 직접 문서에 대해 저장하지 않더라도 툴에서 자동 저장해 주는 기능을 설정해 둘 수 있을 것 입니다.

오라클 데이터베이스 환경은 워드 프로세스와 같이 한명의 사용자가 데이터를 저장하는 구조가 아닙니다. 무수히 많은 사용자들이 데이터를 입력, 수정, 삭제, 조회하는 아주 복잡하고 까다로운 구조를 가지고 있는 시스템 소프트웨어 입니다.
이런 환경에서 어떤 사용자는 입력을 수행하고, 또 다른 사용자는 수정과 삭제를 수행하다가 갑자기 시스템이 정전에 의해 다운된다면 그때까지 처리되고 있던 모든 데이터들은 어떻게 될까요 ?
기본적으로 정전이 되던 시점까지 사용자가 COMMIT문을 수행하였다면 그 모든 데이터들은 리두로그 파일에 백업이 되어 있으며, 만약, COMMIT문을 수행하지 못했다면 모든 데이터들은 자동 롤백(Rollback)이 되게 됩니다.
그리고, COMMIT문을 처리하는 단계에서 보았던 것처럼, 리두로그 파일에는 백업되었지만 테이블에는 저장되지 못한 데이터들은 다시 데이터베이스가 재 시작하게 될 때 SMON 백그라운드 프로세스에 의해 리두로그 파일의 백업 데이터들이 읽혀져서 복구작업이 수행되게 됩니다.

1-7 시스템 변경 번호

이번에는 오라클 데이터베이스의 파일구조와 SCN 에 대해서 좀 더 자세히 알아보겠습니다.
먼저, 모든 데이터베이스 파일에는 사용자들이 COMMIT문을 실행할 때마다 발행되는 SCN(SYSTEM CHANGE NUMBER)이 CKPT 프로세스에 의해 모든 데이터 파일과 컨트롤 파일에 저장됩니다. (앞에서 소개 드린 "COMMIT문의 처리과정"을 참조하십시오.) SCN을 파일의 헤드 영역들에 저장하는 이유는 데이터베이스에서 COMMIT된 현재 시점을 구분하기 위해서 입니다. 만약, 향후에 데이터베이스에 문제가 발생하여 복구 작업을 수행해야 할 경우 특정시간, 특정 SCN을 기준으로 복구작업을 수행해야 할 때 경우도 있습니다.

SCN은 데이터베이스가 시작될 때(STARTUP) OPEN 단계에서 데이터 파일의 무결성을 검증할 때 사용되기도 합니다. ("오라클 서버의 시작과 종료"를 참조하십시오.)
예를 들어, 위 그림에서 2001년 6월 30일 백업 당시에 SCN은 100 이었다고 합니다. 그리고, 2001년 7월 31일 백업 당시에 SCN은 101 이었다고 합니다. 2001년 8월 10일 현재 시점에 컨트롤 파일에 장애가 발생하여 마지막에 백업되었던 컨트롤 파일(2001년 7월31일)을 현재 컨트롤 파일 위치로 복사 하였다고 합니다. 이런 경우, 데이터베이스를 다시 재 시작하면 어떻게 될까요 ?
결론적으로 데이터베이스는 정상적으로 시작되지 않습니다.

왜 그럼 정상적으로 사용할 수 없는 걸까요 ? 데이터베이스의 시작단계 중 OPEN 단계는 오라클 서버의 모든 데이터 파일과 컨트롤 파일들이 같은 시점의 데이터들 인지를 검증하기 위해 시스템 변경번호(System Change Number)를 검증하게 되는데, 컨트롤 파일에는 현재 SCN이 101이라고 되어 있고, 다른 데이터 파일들은 102 라고 되어 있기 때문에 이 파일들은 같은 시점의 데이터가 아니라고 판단하여 정상적으로 시작하지 않는 것 입니다.
시스템 변경번호는 COMMIT문을 실행할 때 마다 오라클 서버에 의해 발행되며 데이터베이스의 시작과 종료단계에서 데이터의 무결성을 보장하기 위해 사용되는 중요한 상태 값 중에 하나입니다. SCN은 컨트롤 파일과 데이터 파일의 헤드영역에 항상 기록되어 있습니다.

1-8 오라클 데이터베이스의 파일 구조

자~ 이번에는 오라클 서버의 구조 중에 파일(Files)에 대해 자세히 알아 봅시다.
오라클 데이터베이스를 자동으로 설치해 주는 유니버셜 인스톨러(Universal Installer)에 의해 오라클 서버를 설치하면 위 그림과 같이 CREATE DATABASE~문에 의해 기본적인 파일 구조들이 생성됩니다.

1) 파라메터 파일	CREATE DATABASE ~ ; 문법이 실행되기 전에 생성하며, 오라클 서버의 환경설정과 관련된 정보를 저장해 두는 파일입니다. 사용자가 직접 내용을 편집할 수 있는 텍스트 파일구조 입니다.

2) 리두로그 파일	CREATE DATABASE ~ LOGFILE ~ ; 문법에 의해 생성되며 사용자들이 실행하는 DML문에 의해 발생하는 모든 변경 데이터를 백업해 줍니다.

3) 컨트롤 파일	CREATE DATABASE ~ ; 문법에 의해 생성되며 이 문법에 정의되어 있는 모든 파일들에 대한 이름과 경로,크기,상태에 대한 정보를 저장합니다.

4) 데이터 파일	CREATE DATABASE ~ ; 문법에 의해 기본적으로 SYSTEM.DBF, UNDO.DBF, TEMP.DBF 파일을 생성해 주면 사용자에 의해 추가적으로 데이터 파일이 생성 됩니다.

2장 오라클 DB의 논리적/물리적 구조의 이해

주종면 | 플랜정보기술

대부분의 오라클 데이터베이스 사용자들은 유니버설 인스톨러(Universal Installer)에 의해 오라클 서버를 설치하게 되며 자신들의 데이터를 저장, 관리하는 일에 대부분의 시간과 노력을 투자하게 됩니다.

하지만, 자신들의 데이터를 안전하게 저장, 관리하기 위해서는 먼저, 오라클 서버의 기본구조를 명확히 이해해야 하며, 기본구조에 대한 안전한 구조설계를 해야 만 효과적으로 데이터를 저장, 관리할 수 있게 됩니다.

이번 섹션에서는 오라클 데이터베이스를 설치하고 난 후 반드시 고려해야 하는 구조설계에 대해 소개하고자 합니다.

2-1 오라클 DB의 논리적/물리적 구조

오라클 데이터베이스의 안전한 구조설계를 통해 데이터의 효과적인 저장, 관리를 하기 위해서는 먼저, 논리적, 물리적 구조에 대한 이해가 필수적입니다.

다음은 오라클 데이터베이스의 논리적 구조에 대한 설명입니다.

1) 데이터베이스

오라클 데이터베이스는 크게 논리적 구조와 물리적 구조로 나누어 구성되어 있습니다.
일반적으로 사용자들이 말하는 데이터베이스(Database)는 논리적 개념에서 사용되는 용어이며, 데이터(Data)의 집합이란 의미를 가지고 있습니다.
하지만, 오라클 서버에서 데이터베이스는 하나의 연속적인 공간을 일컫는 말은 아니며, 위 그림을 보시는 것처럼, 여러 개의 테이블스페이스(Tablespace)라는 논리적 구조가 모여서 하나의 데이터베이스를 구성하게 됩니다.

2) 테이블스페이스와 데이터 파일

하나의 데이터베이스를 구성하는 여러 개의 논리적 구조들을 테이블스페이스(Tablespace)라고 합니다. 일반적으로, 테이블스페이스는 유니버셜 인스톨러(Universal Installer)에 의해 기본적으로 3개(SYSTEM , UNDOTBS, TEMP 테이블스페이스)가 생성되며 또한, 사용자에 의해 추가적으로 여러 개의 테이블스페이스가 생성될 수도 있습니다.

(1) SYSTEM 테이블스페이스

데이터베이스는 기본적으로 자료사전(Data Dictionary) 테이블을 제공합니다. 데이터베이스 내에 생성되어 있는 모든 객체들에 대한 정보 뿐만 아니라 데이터베이스의 현재 상태를 보여주며 서버에 의해 생성되며 관리됩니다. 이와 같은, 자료사전 테이블들이 저장되는 논리적 구조를 SYSTEM 테이블스페이스 라고 합니다.

SQL> CONNECT system/manager
SQL> SELECT * FROM DBA_USERS;
SQL> SELECT * FROM DBA_DATA_FILES;

결론적으로 이 공간에는 데이터베이스의 모든 상태정보가 저장되어 있는 공간입니다.

(2) UNDOTBS 테이블스페이스

사용자들이 데이터베이스에 접속한 다음 DML문(Update, Delete, Insert)을 실행한 후 만약, 트랜잭션을 취소해야 한다면 ROLLBACK문을 수행하게 됩니다.

SQL>	CONNECT scott/tiger
SQL>	SELECT empno, ename, sal FROM emp WHERE empno = 7934;

SQL>	UPDATE emp SET sal = sal * 1.1 WHERE empno = 7934;
SQL>	SELECT empno, ename, sal FROM emp WHERE empno = 7934;

SQL>	ROLLBACK;
SQL>	SELECT empno, ename, sal FROM emp WHERE empno = 7934;

UPDATE문을 실행한 후 SELECT문을 수행하면 해당 사원의 SAL 컬럼 값이 변경되어 있는 것을 확인할 수 있습니다. 하지만, ROLLBACK문을 수행한 후 다시 SELECT문을 실행하면 UPDATE문을 실행하기 이전 상태로 돌아가 있는 것을 확인할 수 있을 것 입니다.
그렇다면, ROLLBACK문을 실행하기 이전에는 변경 후의 값이, 실행하고 난 후에는 변경 전의 값을 확인할 수 있다는 것은 사용자는 알 수 없지만 어딘가에 변경 전의 값이 잠시 저장되어 있다는 것을 미루어 짐작할 수 있을 것 입니다.
바로, 이 공간이 UNDOTBS 테이블스페이스 입니다. 결론적으로 이 공간에는 사용자의 ROLLBACK 데이터가 ROLLBACK 문장이 수행될 때까지 잠시 저장되어 있는 임시 공간입니다.

(3) TEMPORARY 테이블스페이스

UNDOTBS 테이블스페이스와 함께 사용자들이 자주 사용하는 것이 TEMP 테이블스페이스 입니다.

SQL>	CONNECT scott/tiger

SQL>	SELECT empno, ename, sal FROM emp ORDER BY deptno;

대부분의 사용자들이 데이터베이스에 접속하여 실행하는 문장들은 내부적으로 분류작업(Sorting)이 발생하게 됩니다. (ORDER BY, GROUP BY, DISTINCT, UNION CREATE INDEX~ 등)
왜냐하면, 기본적인 테이블 구조들은 데이터를 입력했을 때 입력하는 순으로 저장되기 때문에 테이블의 정보를 SELECT 해 보면 그 결과를 쉽게 참조할 수 없는 단점을 가지고 있기 때문입니다. 결국, 그 데이터를 분류작업(Sorting) 하기 위해서는 별도의 임시공간이 필요하게 되는데, 바로 이 공간이 TEMP 테이블스페이스 입니다.
결론적으로 이 공간에는 사용자의 SQL문이 분류작업을 요구하는 경우 잠시 사용하는 임시 공간입니다.

(4) 데이터 파일

지금까지 소개 드린 SYSTEM, UNDOTBS, TEMP 테이블스페이스는 다음과 같이 CREATE DATABASE ~ ; 문법에 의해 오라클 데이터베이스가 설치될 때 생성됩니다.

CREATE DATABASE ora90 LOGFILE GROUP 1 ('c:\oracle\oradata\ora92\redo01.log') size 10m, GROUP 2 ('c:\oracle\oradata\ora92\redo02.log') size 10m) DATAFILE 'c:\oracle\oradata\ora92\system01.dbf' size 100m UNDO TABLESPACE undo DATAFILE 'c:\oracle\oradata\ora92\undo01.dbf' size 50m DEFAULT TEMPORARY TABLESPACE temp TEMPFILE 'c:\oracle\oradata\ora92\temp01.dbf' size 30m EXTENT MANAGEMENT LOCAL UNIFORM size 1m CHARACTER SET ko16ksc5601 NATIONAL CHARACTER SET al16utf16 SET TIME_ZONE = 'Korea/Seoul';

이 문법에서 SYSTEM01.DBF 데이터 파일은 SYSTEM 테이블스페이스에 대한 물리적 구조를 표현한 것이며, UNDO01.DBF 는 UNDOTBS 테이블스페이스, TEMP01.DBF는 TEMPORARY 테이블스페이스에 대한 물리적 구조를 표현한 것 입니다.

3) 세그멘트

데이터베이스 내에 생성되는 모든 객체( 테이블, 인덱스, 뷰, 시퀀스, 시노늄 등)들을 세그멘트(Segment) 라고 합니다. 다음 문법을 보시는 것처럼, 하나의 세그멘트는 하나의 테이블스페이스에 저장되는 하나의 구성요소 입니다.

SQL>	CONNECT system/manager
SQL>	CREATE TABLESPACE insa DATAFILE 'C:\ORACLE\ORADATA\ORA92\test01.dbf' size 10M;

SQL>	CONNECT scott/tiger
SQL>	CREATE TABLE test (a NUMBER(2), b CHAR(10)) TABLESPACE insa;
← TEST 테이블(세그멘트)는 INSA 테이블스페이스에 생성됩니다.

4) 익스텐트

하나의 테이블스페이스가 여러 개의 세그멘트로 구성되어 있는 것처럼, 하나의 세그멘트도 여러 개의 익스텐트(Extent)가 모여서 구성됩니다. 하나의 테이블을 생성하면 처음부터 아주 큰 하나의 저장공간이 할당되는 것이 아니라, 처음에는 익스텐트라는 공간이 할당되고, 이 공간이 모두 사용되면 다시 익스텐트를 할당 받아 연속적으로 데이터를 저장하게 되는 것 입니다.

SQL>	CONNECT scott/tiger
SQL>	CREATE TABLE test1
	CREATE TABLE test1
	a NUMBER(2), b VARCHAR2(10))
	TABLESPACE insa
	STORAGE (	INITIAL	10K ← 테이블의 최초 크기를 결정합니다.
		NEXT	10K ← 최초 크기가 모두 사용된 후 다음 크기를 결정합니다.
		MINEXTENT	1
		MAXEXTENT	UNLIMITED
		PCTINCREASE	50);

결론적으로, 하나의 테이블은 하나의 연속적인 공간으로 생성되는 것이 아니라 익스텐트라는 작은 구성요소로 생성되어 있는 것을 확인할 수 있습니다.

5) 블록

오라클 데이터베이스의 가장 작은 저장구조를 블록(Block)이라고 합니다. 앞에서 소개 드린 익스텐트 구조는 사실은 하나의 연속적인 공간이 아니라 블록구조가 여러 개 모여 만들어지는 하나의 공간입니다. 결국, 여러 개의 블록이 모여 하나의 익스텐트를 만들게 됩니다.

그렇다면, 하나의 익스텐트를 왜 여러 개의 작은 구성요소로 만들었을까요 ??

만약, 하나의 익스텐트를 하나의 연속적인 공간으로 만들었다면 테이블의 데이터를 읽을 때 한번에 많은 데이터를 읽어야 하기 때문에 시간이 많이 소요될 뿐만 아니라 한번에 많은 데이터를 저장해야 하기 때문에 효과적인 저장과 관리가 용이하지 않기 때문입니다.
그래서, 연속적인 데이터를 여러 개의 블록구조로 쪼개서 관리함으로써 효율성을 높이게 되는 것 입니다.

오라클 데이터베이스의 논리적, 물리적 저장구조에 대한 보다 자세한 설명은 "오라클 데이터베이스의 관리"에 관련된 참고서적을 참고해 주십시오.

사례-1

사용자의 데이터가 저장되어 있는 테이블에 입력, 수정, 삭제작업을 수행하다 보면 자주 발생하는 에러현상이 있습니다. 이 현상은 테이블이 저장되어 있는 테이블스페이스의 공간이 부족한 경우에 주로 발생합니다.

• ORA-01653 에러코드가 발생하는 경우
• 테이블스페이스를 생성 또는 변경하거나 크기를 관리해야 경우

1) 테스트를 위해 TEST 테이블스페이스를 생성하십시오.

[C:\] sqlplus "/as sysdba"
SQL>	startup force
SQL>	create tablespace test datafile 'c:\oracle\oradata\ora92\test_01.dbf' size 3M;

SQL>	select tablespace_name, bytes, file_name from dba_data_files;

2) TEST 테이블을 TEST 테이블스페이스에 생성하십시오.

[C:\] sqlplus "/as sysdba"
SQL>	create table test(name char(30)) tablespace test storage(initial 2M);

3) TEST 테이블이 생성되었으면 연속적으로 행들을 입력하여 익스텐트 확장 시 에러가 발생하도록 하십시오. SQL> declare x number(2); begin for x in 1 .. 10000 loop insert into test values('111111111111111111111111111111'); end loop; end; / SQL> / SQL> / SQL> / ← 익스텐트 에러가 발생할 때 까지 반복적으로 실행하십시오. SQL> / declare * 1행에 오류: ORA-01653: SYS.TEST 테이블을 128(으)로 TEST 테이블스페이스에서 확장할 수 없습니다 ORA-06512: 줄 5에서

4) 테이블스페이스의 크기가 부족하여 발생하는 에러를 해결하기 위해서는 해당 테이블스페이스에 새로운 데이터 파일을 추가하는 방법입니다. SQL> alter tablespace test add datafile 'c:\oracle\oradata\ora92\test_02.dbf' size 3M; SQL> declare x number(2); begin for x in 1 .. 10000 loop insert into test values('111111111111111111111111111111'); end loop; end; / SQL> select tablespace_name, bytes, file_name from dba_data_files; SQL> host dir c:\oracle\oradata\ora92 → "test_02.dbf" 파일의 존재여부와 파일 크기를 확인하십시오. test_01.dbf test_02.dbf

5) 테이블스페이스의 크기를 늘리는 두 번째 방법은 기존의 데이터 파일을 RESIZE절로 늘리는 방법입니다. SQL> alter database datafile 'c:\oracle\oradata\ora92\test_02.dbf' resize 5M; SQL> select tablespace_name, bytes, file_name from dba_data_files; SQL> host dir c:\oracle\oradata\ora92

6) 실습이 끝나면 TEST 테이블스페이스를 삭제하십시오. 해당 테이블스페이스 내에 관련 테이블이나 인덱스가 생성되어 있으면 테이블스페이스를 삭제할 수 없습니다. SQL> drop tablespace test; drop tablespace test * 1행에 오류: ORA-01549: 테이블스페이스가 비어있지 않으므로 INCLUDING CONTENTS 옵션 을 사용해 주십시오 SQL> drop tablespace test including contents; SQL> select tablespace_name, bytes, file_name from dba_data_files; SQL> host dir c:\oracle\oradata\ora92 test_01.dbf test_02.dbf

7) 테이블스페이스를 삭제하더라도 관련 데이터 파일은 삭제되지 않습니다. 추가적인 작업을 통해 관련 데이터 파일을 함께 삭제하십시오. SQL> host del c:\oracle\oradata\ora92\test_0* SQL> host dir c:\oracle\oradata\ora92 SQL> exit

사례-2

사용자들이 실행하는 SQL문장 중에는 SORTING(분류작업)이 유발되는 경우가 매우 많습니다. 동시에 많은 사용자들이 이러한 문장을 실행하게 되면 Temporary 테이블스페이스를 통해 분류작업을 수행하게 되는데 만약 TEMPORARY 테이블스페이스의 데이터 파일이 유실된다면 더 이상 작업이 진행되지 못하여 장애가 발생하게 됩니다. 이런 경우, 어떻게 장애를 복구해야 할까요 ?

1) 이 실습을 수행하기 위해 오라클 데이터베이스가 정상이라는 것을 확인하십시오. [C:\] sqlplus "/as sysdba" SQL> startup SQL> select tablespace_name, file_name from dba_temp_files; → 현재 오라클 서버환경에서 TEMPORARY 테이블스페이스의 이름과 위치를 분석하십시오. SQL> host dir c:\oracle\oradata\ora92\temp02.dbf

2) 다음과 같은 실습 시나리오를 통해 TEMP 테이블스페이스에 장애가 발생 합니다. SQL> shutdown abort → 오라클 서버가 비정상적으로 종료됩니다. 갑자기, 정전이 발생하여 시스템이 종료되는 것과 동일한 시나리오를 연출하기 위함 입니다. SQL> exit [C:\] cd c:\oracle\oradata\ora92 [C:\] move temp02.dbf temp02.org → Temp 테이블스페이스가 디스크의 장애로 인해 읽기, 쓰기 작업이 수행되지 못하는 경우를 연출하기 위해 임의로 이동됩니다. [C:\] sqlplus "/as sysdba" SQL> startup mount SQL> alter database open; → TEMP 테이블스페이스에 장애가 발생하여 더 이상 읽기,쓰기 작업을 수행할 수 없지만 오라클 서버는 정상적으로 오픈 됩니다. 왜냐하면, TEMP 테이블스페이 스는 사용자의 데이터가 저장되는 공간이 아니라 SQL문을 실행할 때 발생하는 SORTING 데이터가 잠시 저장되는 임시 공간이기 때문에 직접적인 복구가 요구 되지 않기 때문에 오라클 서버는 정상적으로 오픈되는 것 입니다. 오라클 서버 가 오픈 된다는 것은 TEMP 테이블스페이스가 사용 가능하다는 것을 의미하는 것은 아니며, 오픈 후 복구작업을 수행해야 합니다.

3) 다음은 TEMP 테이블스페이스를 복구하는 방법과 절차입니다.

TEMP 테이블스페이스에는 사용자의 데이터가 저장되어 있지 않으므로, 데이터에 대한 복구는 요구되지 않으며 다만, TEMP 테이블스페이스의 구조를 재생성 하는 것이 복구작업의 모든 것 입니다.

SQL> select * from dba_tablespaces; → 자료사전 테이블에는 Temp" Tablespace는 그래도 존재합니다. 왜냐하면 Temp Tablespace의 구성 File 중 하나를 Drop한 것 뿐이기 때문입니다. SQL> drop tablespace temp including contents; → DROP 문장을 실행하면 컨트롤 파일 내에 존재하는 TEMP 테이블스페이스에 대한 정보와 데이터 딕션어리 테이블에 저장되어 있는 정보가 모두 삭제됩니다. SQL> create temporary tablespace temp2 tempfile 'c:\oracle\oradata\ora92\temp02.dbf' size 3m; → CREATE 문장을 실행하면 컨트롤 파일에 TEMP 테이블스페이스에 대한 정보가 저장되며 데이터 딕션어리 테이블에도 관련 정보가 저장됩니다. 컨트롤 파일에 관련 정보를 저장하는 이유는 데이터베이스의 무결성을 보장하기 위해서 입니다. SQL> host dir c:\oracle\oradata\ora92\temp02.dbf → 해당 경로에서 파일과 크기 확인 SQL> shutdown immediate SQL> exit [C:\] del c:\oracle\oradata\ora92\temp02.org → 이전 TEMP 파일은 불필요함으로 삭제 [C:\] cd

2-2. 컨트롤 파일

2-2-1 다중 컨트롤 파일 시스템 이란?

오라클 데이터베이스를 설치하면 기본적으로 생성되는 파일들이 있습니다. 이 중에 컨트롤 파일은 별도의 문법에 의해 생성되지는 않으며 단지, CREATE DATABASE ~ 문법에 의해서만 자동 생성되고 데이터베이스 생성 시 모든 상태 정보를 저장하게 됩니다.
(파일명과 경로, 시스템 변경번호, 로그-시퀀스 번호, 데이터베이스 명, 설치날자, Characterset 등)
또한, 데이터베이스 생성 시 오라클 서버는 init.ora 파라메터 파일에 정의되어 있는 CONTROL_FILES 파라메터 값을 참조하여 정해진 경로에, 정해진 파일이름으로, 정해진 개수 만큼의 컨트롤 파일을 생성하게 됩니다.

[C:\] CD C:\ORACLE\ORA92\DATABASE [C:\] EDIT init.ora CONTROL_FILES = ("C:\ORACLE\ORADATA\ORA92\CONTROL01.CTL", "C:\ORACLE\ORADATA\ORA92\CONTROL02.CTL")

예를 들어, 위 문법과 같이 2개의 컨트롤 파일에 대한 정보를 init.ora 파일에 정의하였다면, 데이터베이스 생성 시 오라클 서버는 컨트롤 파일을 정해진 위치에 정해진 이름으로 2개를 생성해 줍니다. 이때, 첫 번째 컨트롤 파일이 원본이며, 두 번째 파일은 미러링(Mirror) 컨트롤 파일입니다. 만약, init.ora 파일에 3 번째 컨트롤 파일에 대한 정보를 정의하였다면, 생성 후 하나의 원본 컨트롤 파일과 2개의 미러링 컨트롤 파일을 확인할 수 있을 것 입니다. 이러한 구조를 다중 컨트롤 파일 시스템(Multipled Control File System) 이라고 합니다. (기본적으로 오라클 서버는 사용자가 init.ora 파일에 컨트롤 파일에 대한 정보를 정의하지 않으면 1개의 원본 컨트롤 파일만 생성해 줍니다.)

결론적으로, 오라클 서버가 하나의 원본 컨트롤 파일과 여러 개의 미러링 컨트롤 파일을 제공하는 이유는 무엇일까요 ?

그 이유는 , 컨트롤 파일은 데이터베이스를 사용하면서 없어서는 안될 가장 중요한 파일 중에 하나이기 때문에 무엇보다도 잘 관리해야 만 오라클 데이터베이스의 안정성이 보장될 수 있기 때문 입니다.

1) 데이터베이스의 시작단계에서 반드시 필요한 컨트롤 파일

데이터베이스를 시작할 때(STARTUP), NOMOUNT 단계가 끝나고 MOUNT 단계가 되면 컨트롤 파일 정보를 읽어 데이터베이스의 모든 파일 상태를 검증하게 되는데 만약, 컨트롤 파일을 읽을 수 없다면(사용자의 실수로 삭제되거나 디스크의 이상으로 생기는 문제) 데이터베이스는 더 이상 MOUNT 작업을 수행하지 않으며, 사용자들은 데이터베이스를 사용할 수 없게 됩니다. (1편 "오라클 서버의 시작과 종료"를 참조하십시오.)

[C:\] CD C:\ORACLE\ORADATA\ORA92 [C:\] DEL *.CTL ← 모든 컨트롤 파일이 삭제됩니다. [C:\] sqlplus SQL*Plus: Release 9.0.1.0.0 - Production on Tue Mar 2 10:33:39 2004 (c) Copyright 2001 Oracle Corporation. All rights reserved. Enter user-name: /as sysdba Connected to an idle instance. SQL> startup ORACLE instance started. Total System Global Area 26140792 bytes Fixed Size 434296 bytes Variable Size 20971520 bytes Database Buffers 4194304 bytes Redo Buffers 540672 bytes ORA-00205: error in identifying controlfile, check alert log for more info

2) COMMIT문을 실행할 때 SCN을 기록하기 위해 반드시 필요한 컨트롤 파일

1편 "COMMIT문의 처리과정"에서 소개한대로 컨트롤 파일의 용도는 사용자들이 DML문을 실행한 후 COMMIT문을 실행할 때 데이터베이스의 상태정보를 기록해 두는 파일입니다.
만약, 이 파일을 일기, 쓰기 할 수 없다면 더 이상 사용자들은 DML문을 실행할 수 없게 됩니다. (1편 "COMMIT문의 처리과정"을 참조하십시오.)

[C:\] sqlplus SCOTT/TIGER SQL> UPDATE emp SET sal = sal 1.5; SQL> COMMIT; SQL> CONNECT /AS SYSDBA SQL> SHUTDOWN ORA-00210: cannot open the specified controlfile ORA-00202: controlfile: 'C:\ORACLE\ORADATA\ORA92\CONTROL01.CTL' ORA-27041: unable to open file SVR4 Error: 2: No such file or directory Additional information: 3

결론적으로, 컨트롤 파일은 항상 잘 관리해야 하고 문제가 발생했을 때 쉽게 대처할 수 있도록 평소에 백업을 잘 해 두는 것을 습관화 해야 합니다.
WINDOWS 환경에서 유니버설 인스톨러에 의해 오라클 데이터베이스를 설치하면 기본적으로 3개의 컨트롤 파일이 생성됩니다. 첫 번째 파일이 원본 컨트롤 파일이며 두 번째, 세 번째 컨트롤 파일은 원본에 대한 미러링(MIRRORING) 파일입니다. 원본 컨트롤 파일에 문제가 발생하면 두 번째, 세 번째 파일로 쉽게 복구할 수 있도록 오라클 서버가 기본적으로 제공하는 것 입니다.(UNIX 환경에서는 기본적으로 하나의 컨트롤 파일이 생성됩니다.)
현재, 데이터베이스에서 사용하고 있는 컨트롤 파일의 위치와 이름을 알고 싶다면 init.ora 파일의 CONTROL_FILES 파라메터를 참조하십시오.

[C:\] CD C:\ORACLE\ORA92\DATABASE [C:\] EDIT init.ora ########################################### # 파일 구성 ########################################### control_files=( "C:\oracle\oradata\ORA92\CONTROL01.CTL", ← 원본 컨트롤 파일 "C:\oracle\oradata\ORA92\CONTROL02.CTL", ← 미러링 컨트롤 파일 "C:\oracle\oradata\ORA92\CONTROL03.CTL") ← 미러링 컨트롤 파일

또는, 다음과 같이 V$CONTROLFILE 자료사전을 참조해 보십시오.

SQL> CONNECT system/manager SQL> SELECT * FROM V$CONTROLFILE; STATUS NAME --------------------------------------------- C:\oracle\oradata\ORA92\CONTROL01.CTL C:\oracle\oradata\ORA92\CONTROL02.CTL C:\oracle\oradata\ORA92\CONTROL03.CTL

2-3. 리두로그 파일

2-3-1 다중 리두로그 파일 시스템의 설계와 방법

이번에는 오라클 데이터베이스의 안정적 운영을 위해 요구되는 구조적 설계에서 가장 중요한 다중 리두로그 파일 시스템(Multipled Redo-Log File System)에 대해서 자세히 알아 보도록 하겠습니다.

1) 리두로그 파일 시스템

사용자의 SQL문에 대해 COMMIT문을 실행하면 SQL*PLUS 화면에 "커밋이 성공적이다"라는 메시지를 확인할 수 있습니다. 이 메시지의 의미는 커밋 되었던 모든 행 데이터(변경 전 데이터와 변경 후 데이터)를 리두로그 버퍼 영역에 백업했다는 의미이며, 이어 LGWR 백그라운드 프로세스가 일시적으로 저장되는 리두로그 버퍼 영역의 모든 데이터를 영구히 저장할 수 있는 리두로그 파일로 저장했다는 의미입니다. 결론적으로, 현재 변경한 행 데이터를 리두로그 파일로 백업했다는 의미를 가지게 됩니다. 리두로그 버퍼와 리두로그 파일에 모든 변경정보를 저장하는 이유는 갑작스런 시스템의 다운(DOWN) 또는 갑작스런 데이터베이스의 다운 시 처리하고 있던 모든 작업 내용이 테이블에 미쳐 저장되기 전이라면 데이터의 유실이 발생할 수 있기 때문입니다. 이때 리두로그 파일에 백업해 둔 데이터를 통해 데이터베이스를 복구하기 위해서 입니다.

사용자가 생성한 테이블에 대해 DML문을 실행할 때 모든 데이터가 리두로그 버퍼에 백업될 수 있는 이유는 해당 테이블이 생성될 때 LOGGING 문법 절에 의해 결정됩니다.

SQL> CONNECT SCOTT/TIGER SQL> CREATE TABLE TEST1 (NO NUMBER, NAME VARCHAR2(15)) LOGGING;

테이블을 생성할 때, LOGGING 절을 부여하지 않으면 오라클 서버는 기본적으로 LOGGING 절을 적용해 줍니다.

SQL> CREATE TABLE TEST2 (NO NUMBER, NAME VARCHAR2(15)) LOGGING;

만약, 해당 테이블에 대해서는 DML문이 실행될 때 모든 데이터를 백업하지 않아도 된다면 다음과 같이 NOLOGGIN 절을 사용할 수도 있습니다.

SQL> CREATE TABLE TEST3 (NO NUMBER, NAME VARCHAR2(15)) NOLOGGING;

일반적으로, 다른 데이터베이스 환경에서 다운로드를 통해 재 사용되는 테이블이거나, 언제든지 해당 테이블에 대한 복구가 용이한 경우에는 NOLOGGING절을 사용할 수도 있습니다.
하지만, 이러한 경우가 아닌 경우에는 데이터베이스 차원에서 모든 데이터들에 대한 백업정보를 로그버퍼에 저장해 주는 것이 기본 모드입니다.

자 ~ 그럼 리두로그 파일의 구조에 대해서 조금 더 자세히 알아 보도록 하겠습니다.

기본적으로 CREATE DATABASE 문에 의해 오라클 데이터베이스를 생성하면 최소 2개의 리두로그 파일이 생성되며, 운영체계에 따라 차이는 있지만, 기본적으로 3개의 리두로그 파일이 생성됩니다.

SQL> CREATE DATABASE ora90 LOGFILE GROUP 1 ('c:\oracle\oradata\ora92\redo01.log') size 100m, GROUP 2 ('c:\oracle\oradata\ora92\redo02.log') size 100m, GROUP 3 ('c:\oracle\oradata\ora92\redo03.log') size 100m) DATAFILE 'c:\oracle\oradata\ora92\system01.dbf' size 100m UNDO TABLESPACE undo DATAFILE 'c:\oracle\oradata\ora92\undo01.dbf' size 50m DEFAULT TEMPORARY TABLESPACE temp TEMPFILE 'c:\oracle\oradata\ora92\temp01.dbf' size 30m EXTENT MANAGEMENT LOCAL UNIFORM size 1m ;

또는, V$LOGFILE 자료사전을 통해서도 확인할 수 있습니다.

SQL> SET LINESIZE 1000 SQL> SELECT * FROM V$LOGFILE; GROUP# STATUS TYPE MEMBER ---------- -------- ------- ------------------------------------ 1 STALE ONLINE C:\ORACLE\ORADATA\ORA92\REDO01.LOG 2 STALE ONLINE C:\ORACLE\ORADATA\ORA92\REDO02.LOG 3 ONLINE C:\ORACLE\ORADATA\ORA92\REDO03.LOG

2) 다중 리두로그 파일 시스템

이러한 리두로그 파일은 오라클 데이터베이스에 장애가 발생한 경우 복구작업을 수행하기 위해서는 반드시 필요한 백업 데이터를 저장하고 있기 때문에 철저한 관리가 요구됩니다.
그런데, 리두로그 파일이 저장되어 있는 디스크에 장애가 발생한다면 어떻게 될까요 ?
결론적으로 말하자면, 복구 시 사용해야 할 백업 데이터에 문제가 발생한 경우이므로, 만약, 데이터 파일에 대한 복구가 필요하다면, 복구작업을 수행할 수 없게 됩니다. 즉, 데이터의 유실이 발생하게 됩니다.
그래서, 오라클 사에서는 원본 리두로그 파일에 장애가 발생할 것을 대비하여 미러링(Mirroring) 리두로그 파일을 생성하게 함으로써, 어떤 장애가 발생하더라도 모든 데이터에 대한 복구작업을 수행할 수 있기 해 줍니다.
이러한 데이터베이스 환경을 다중 리두로그 파일 시스템(Multiplex Redo-Log File System)이라고 합니다. 개념적으로, 다중 컨트롤 파일 시스템(Multiplex Control File System)과 같이 원본 파일에 대한 복사본 파일을 항상 유지해 둠으로써 원본에 문제가 발생하면 복사본 파일로 대체하여 오라클 데이터베이스를 사용 가능하게 해 줍니다.

다음은 다중 리두로그 파일 시스템을 구축하는 방법과 절차입니다.

(1) 먼저, 현재 사용중인 데이터베이스 환경에서 리두로그 파일 상태를 확인하십시오. [C:\] sqlplus "/as sysdba" SQL> SELECT * FROM V$LOG; GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS ---------- ---------- ---------- ---------- ---------- --- --------- 1 1 63 5242880 1 NO INACTIVE 2 1 62 5242880 1 NO INACTIVE 3 1 64 1048576 1 NO CURRENT ← MEMBERS 컬럼의 값 1은 다중 리두로그 파일 시스템이 아닌 것을 의미합니다. 만약, 다중 리두로그 파일 시스템이라면 2 이상의 값을 확인할 수 있습니다.(2) 현재, 데이터베이스 환경은 몇 개의 리두로그 그룹을 가지고 있는지 확인하십시오.
그리고, 새로운 그룹을 추가하십시오. SQL> ALTER DATABASE ADD LOGFILE GROUP 4 'C:\ORACLE\ORADATA\ORA92\REDO04.LOG' size 500k;
(3) 새로운 그룹을 추가하였으면, 다중 리두로그 파일 시스템을 구축해 보십시오.
그리고,리두로그룹 4에 대한 미러링 파일을 추가 생성합니다. SQL> ALTER DATABASE ADD LOGFILE MEMBER 'C:\ORACLE\ORADATA\ORA92\REDO04B.LOG' TO GROUP 4;
(4) 이번에는 리두로그 그룹1, 그룹2, 그룹3에 대한 각각의 미러링 파일을 추가하십시오. SQL> ALTER DATABASE ADD LOGFILE MEMBER ] 'c:\oracle\oradata\ora92\REDO01B.LOG ' TO GROUP 1; SQL> ALTER DATABASE ADD LOGFILE MEMBER 'c:\oracle\oradata\ora92\REDO02B.LOG' TO GROUP 2; SQL> ALTER DATABASE ADD LOGFILE MEMBER 'c:\oracle\oradata\ora92\REDO03B.LOG' TO GROUP 3; SQL> SELECT * FROM v$logfile; GROUP# STATUS TYPE MEMBER ------ ------- ------- ---------------------------------------- 1 STALE ONLINE C:\ORACLE\ORADATA\ORA92\REDO01.LOG 1 STALE ONLINE C:\ORACLE\ORADATA\ORA92\REDO01B.LOG 2 STALE ONLINE C:\ORACLE\ORADATA\ORA92\REDO02.LOG 2 STALE ONLINE C:\ORACLE\ORADATA\ORA92\REDO02B.LOG 3 ONLINE C:\ORACLE\ORADATA\ORA92\REDO03.LOG 3 STALE ONLINE C:\ORACLE\ORADATA\ORA92\REDO03B.LOG 3 ONLINE C:\ORACLE\ORADATA\ORA92\REDO04.LOG 3 STALE ONLINE C:\ORACLE\ORADATA\ORA92\REDO04B.LOG SQL> SELECT * FROM V$LOG; GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS ---------- ---------- ----------- --------- -------- --- ---------- 1 1 62 5242880 2 NO INACTIVE 2 1 63 5242880 2 NO INACTIVE 3 1 64 1048576 2 NO CURRENT 4 1 61 1048576 2 NO CURRENT

3장 노-아카이브와 아카이브 모드
	3-1 백업과 복구의 종류
	오라클 데이터베이스에는 4 가지 백업 방법과 8 가지 복구 방법이 제공됩니다. 백업 방법은 다시 두 가지 방법으로 실행할 수 있는데, 첫 번째, 물리적 방법(PHYSICAL MODE)은 오라클 데아터베이스와 관련된 모든 파일들(데이터 파일, 컨트롤 파일, 리두로그 파일, 파라메터 파일)을 운영체계에서 제공하는 복사 명령어(도스-COPY,UNIX-cp, cpio, ufsdump 등)로 다른 물리적 장치에 복사하는 방법을 의미합니다. 두 번째 논리적 방법(LOGICAL MODE)은 오라클 사에서 제공하는 EXPORT 유틸리티를 통해 데이터베이스 내의 테이블, 뷰, 인덱스, PL/SQL 블록 등을 운영체제 상의 파일형태로 복사하는 방법을 의미합니다. 다음은 복구방법 입니다. 복구 방법도 두 가지 모드에서 실행할 수 있습니다. 첫 번째 방법은 노-아키이브 모드(NOARCHIVE MODE))입니다. 백업과 복구 원리에서 알아보았듯이 사용자의 모든 변경 정보는 기본적으로 로그버퍼 영역과 리두로그 파일에 저장되어 데이터베이스 복구 시 사용됩니다. 이러한 환경을 노-아카이브 모드라고 하며 오라클 데이터베이스를 설치하면 기본적으로 노-아카이브 모드로 설정됩니다. 이 모드는 사용자의 모든 변경정보가 리두로그 파일에 백업되기 때문에 리두로그 파일의 크기와 개수가 백업할 수 있는 데이터의 크기를 좌우하게 됩니다. 결론적으로 데이터베이스를 복구해야 할 때 리두로그 파일이 아주 오래 전의 복구 데이터를 가지고 있지 않다면 복구를 할 수 없는 단점을 가지고 있습니다. 두 번째 방법은 아카이브 모드(ARCHIVE MODE)입니다. 이 모드에는 완전복구(COMPLETE RECOVERY)와 불완전 복구(INCOMPLETE RECOVERY) 방법이 있습니다. 모든 복구 데이터를 가지고 있으며 데이터베이스에 문제가 발생했던 시점까지 복구할 수 있는데 이러한 방법을 완전복구(Complete Recovery)라고 하며, 반대로, 복구할 수 있는 데이터가 백업되어 있지 않다면 문제가 생겼던 시점까지 복구할 수 없는데 이러한 방법을 불완전 복구(In-Complete Recovery)라고 합니다. 사용자들은 이러한 다양한 백업과 복구방법을 통해 데이터베이스의 가용성을 높일 수 있습니다. 자~ 그럼 노-아카이브 모드와 아카이브 모드에 대해 자세히 알아 보도록 하겠습니다.



	3-2 노-아카이브 모드
	오라클 서버는 사용자들이 입력, 수정, 삭제작업을 수행할 때 마다 발생하는 모든 변경 전 데이터와 변경 후 데이터들을 리두로그 버퍼 영역에 백업하게 됩니다. 이어, LGWR 백그라운드 프로세스는 리두로그 버퍼의 데이터들을 영구히 저장할 수 있는 리두로그 파일로 저장하게 됩니다. 이것이, 오라클 서버가 제공하는 백업 메커니즘입니다. 그런데, 기본적으로 오라클 데이터베이스를 설치하면 3개의 리두로그 파일이 제공됩니다. 최초, LGWR 프로세스는 첫번째 리두로그 파일에 데이터를 저장하며, 이 파일이 모두 사용되면, 두 번째 리두로그 파일로 이동하여 계속적으로 데이터를 저장하게 됩니다. 두 번째 리두로그 파일도 모두 저장되고 나면 세 번째 리두로그 파일에 쓰기 작업을 계속하게 됩니다. 그런데, 세 번째 리두로그 파일도 모두 사용되고 나면, 더 이상 제공되는 리두로그 파일이 없기 때문에 다시 첫 번째 리두로그 파일에 백업 데이터들을 저장하게 됩니다. 이때, 이전에 저장되어 있는 백업 데이터 위에 새로운 백업 데이터들을 저장하기 때문에 이전 백업 데이터들은 모두 유실되는 문제가 발생하게 됩니다. 이미 소개 드린 대로 리두로그 파일의 용도는 오라클 데이터베이스에 장애가 발생하는 경우 백업된 리두로그 파일의 데이터들을 통해 데이터베이스를 복구하기 위한 용도라고 배웠습니다. 그런데, 위 그림처럼, 백업될 충분한 공간이 확보되지 못한 경우에는 결국 이전에 사용된 리두로그 파일을 재사용할 수 밖에 없게 되는 문제가 발생하게 됩니다. 오라클 데이터베이스에서는 이러한 환경을 노-아카이브 모드(No-Archive Mode)라고 하며 기본적으로 오라클 데이터베이스 설치하면 노-아카이브 모드가 기본 환경입니다. 다음은 사용 중인 데이터베이스의 아카이브 모드 상태를 확인하는 방법입니다. SQL> CONNECT /AS SYSDBA SQL> ARCHIVE LOG LIST Database log mode No Archive Mode ← 노-아카이브 모드 Automatic archival Disabled Archive destination C:\oracle\ora92\database\arch Oldest online log sequence 51 Current log sequence 53 이 결과를 참조했을 때 "Database log mode"의 결과가 "No Archive Mode"임을 확인할 수 있습니다. SQL> SET LINESIZE 1000 SQL> SELECT GROUP#, SEQUENCE#, ARCHIVED, STATUS FROM V$LOG; GROUP# SEQUENCE# ARC STATUS ---------- ---------- ---- ----------- 1 52 NO INACTIVE 2 53 NO CURRENT 3 51 NO INACTIVE 이 결과를 참조했을 때 ARC 컬럼의 값이 "NO"는 노-아키이브 모드라는 것을 의미합니다. SQL> SELECT ARCHIVER FROM V$INSTANCE; ARCHIVE ------- STOPPED 이 결과를 참조했을 때 "STOPPED"는 노-아키이브 모드라는 것을 의미합니다.



	3-3 오프라인 백업
	오라클 사에서 제공하는 백업방법 중에 가장 대표적인 방법이며 또한 가장 쉽고 간단하게 수행할 수 있는 방법입니다. 하지만, 경우에 따라서는 가장 수행하기 어려운 방법 중에 하나이기도 합니다. 오프라인 백업 방법은 버전에 따라 콜드백업(Cold Backup), 전체백업(Whole Backup)이라고도 부르며 다음과 같은 주요 특징이 있습니다.
	1) 반드시, 오라클 서버를 종료(Shutdown) 해야 합니다. [C:\] sqlplus "/as sysdba" SQL> SHUTDOWN SQL> EXIT 여기서, 한가지 주의해야 할 점은 오라클 서버를 종료할 때 반드시 정상적인 종료 옵션(NORMAL, TRANSACTIONAL, IMMEDIATE)을 사용하셔야 합니다. 만약, ABORT와 같은 비정상적인 옵션을 사용하여 데이터베이스를 종료한 후 백업작업을 수행한다면, 이 백업 데이터는 장애 발생 시 사용하지 못하게 됩니다. 즉, 데이터베이스를 복구할 수 없게 되는 치명적인 난관에 부딪히게 됩니다. 그 이유는 간단합니다. ABORT 옵션의 의미는 현재 오라클 서버에 할당된 메모리 공간을 즉시 종료하고 사용 중이던 모든 파일의 상태를 비정상적인 상태로 남긴 후 데이터베이스를 종료 시키기 때문입니다. 예를 들어, WINDOWS 환경에서 어떤 작업을 수행하다가 시스템을 종료해야 한다면 [시작] 버튼을 클릭한 후 [시스템 종료]를 선택합니다. 이것은 정상적인 방법으로 시스템을 종료하는 방법이지요. 하지만, 때로는, 갑작스런 정전으로 인해 미처 정상적인 방법으로 시스템을 종료하지 못하는 경우도 있게 마련입니다. 이런 경우, 다시 시스템을 부팅하게 되면 운영체계는 시스템을 복구모드로 전환하여 갑작스런 다운 시 정상적인 종료를 하지 못한 파일들을 정상적으로 종료 시킨 후 다시 오픈 시켜주는 작업을 수행하게 됩니다. 오라클 데이터베이스 환경에서 SHUTDOWN ABORT 옵션의 의미는 바로 갑작스런 정전으로 인해 데이터베이스가 비정상적으로 종료된 경우와 동일한 상태를 의미하게 됩니다. 결론적으로, 이런 경우, 데이터베이스를 다시 재 시작(Startup)하게 되면 오라클 서버는 내부적으로 복구 작업을 수행하게 됩니다. 이때 , 복구작업을 수행하는 백그라운드 프로세는 SMON(System Monitor) 입니다. 사용자의 순간적인 실수로 백업된 모든 데이터들이 사용되지 못하는 경우가 실제 기업 환경에서 종종 볼 수 있습니다. 이러한 백업 작업을 안전하게 수행할 때는 2번 ~ 3번 확인하신 후 절차에 의해 작업 하셔야 합니다.
	2) 오라클 데이터베이스와 관련된 모든 파일 (데이터 파일, 컨트롤 파일, 리두로그 파일, 파라메터 파일)을 같은 시점에 운영체계 명령어(UNIX의 경우는 cp, mv, ufsdump/WINDOW의 경우 copy, move 등)를 사용하여 디스크 또는 테이프 장치에 복사합니다. [C:\] mkdir C:\BACKUP [C:\] CD C:\ORACLE\ORADATA\ORA92 [C:\] COPY .DBF C:\BACKUP ← 데이터 파일의 백업 [C:\] COPY .CTL C:\BACKUP ← 컨트롤 파일의 백업 [C:\] COPY .LOG C:\BACKUP ← 라두로그 파일의 백업 [C:\] COPY C:\ORACLE\ORA92\DATABASE\.ORA C:\BACKUP ← 파라메터 파일 백업 오라클 사에서 제공하는 오프라인 백업이라는 것은 결론적으로 운영체계 상에서 현재, 오라클 데이터베이스가 구성하고 있는 모든 파일(데이터 파일, 컨트롤 파일, 리두로그 파일, 파라메터 파일)들을 지정한 장치로 복사하는 것을 의미합니다. 이런 경우, 가장 주의해야 할 점은 백업 데이터가 저장될 디스크 또는 테이프 장치에 충분한 사용공간이 존재하는지를 확인하는 것 입니다. 또한, 한가지 더 주의해야 할 점은 반드시 관련된 모든 파일들을 복사하셔야 합니다. 예를 들어, 오늘은 데이터 파일 만 백업하고 내일은 컨트롤 파일을 백업하고 모레에는 리두로그 파일만 백업하는 방법은 정상적인 오프라인 백업 방법이 아니며, 이렇게 백업된 데이터들은 복구 시 사용할 수 없게 됩니다. 그 이유는 다음과 같습니다. 위 그림처럼, ① 현재시점 2001년 6월 30일 SCN(시스템 변경번호)이 100 번인 경우, 데이터베이스를 종료하고 오프라인 백업을 수행하였습니다. 당시, 모든 백업 파일들은 같은 시점의 SCN 100 번인 시점의 데이터들 이었습니다. ② 한 달의 시간이 흘렀고, 현재시점 2001년 7월 31일 SCN이 101 번인 경우, 데이터베이스를 종료한 후 오프라인 백업을 수행하였습니다. 모든 백업 파일들은 SCN이 101번인 시점의 데이터들 이었습니다. ③ 또다시, 한 달의 시간이 흘렀고 현재 시점 2001년 8월 31일에 컨트롤 파일이 저장되어 있는 디스크에 장애가 발생하면서 모든 컨트롤 파일이 사용될 수 없는 치명적인 상태가 되었습니다. 이 경우, 데이터베이스를 복구하기 위해서는 마지막으로 백업되었던 2001년 7월 31일의 백업 데이터를 이용해야 합니다. 위 그림처럼, SCN이 101번을 가지고 있는 7월 31일 백업된 컨트롤 파일을 SCN이 102번을 가지고 있는 현재시점의 데이터베이스 환경으로 재설치를 하고 있습니다. 하지만, 현재 시점의 데이터베이스 환경에서 장애가 발생하지 않은 데이터 파일, 리두로그 파일들은 SCN이 102번 인데, 조금 전에 재 설치된 컨트롤 파일은 SCN이 101번을 나타내는 문제점을 가지게 됩니다. 이 경우, 데이터베이스를 시작(Startup)하게 되면 컨트롤 파일과 다른 파일들이 같은 시점의 데이터들이 아니므로 정상적으로 시작되지 않습니다. 위 그림에서, ③의 경우 데이터베이스의 OPEN 단계는 현재 컨트롤 파일, 리두로그 파일, 데이터 파일들의 SCN을 확인하여 모두 같은 시점의 SCN을 가지고 있는지를 비교하게 되는데 이때, 같은 SCN 번호가 아닌 파일이 발견되면 오라클 데이터베이스에 장애가 발생한 것으로 확인하여 더 이상 OPEN 단계를 수행하지 않으며 다음과 같은 에러 메시지를 출력하게 됩니다.(다음 예제는 USERS01.DBF 데이터 파일의 경우입니다.) [C:\] sqlplus "/as sysdba" SQL> STARTUP MOUNT; SQL> ALTER DATABASE OPEN; alter database open * ORA-01113: 9 파일이 매체 복구되어야 합니다. ORA-01110: 9 데이터 파일: C:\ORALCE\ORADATA\ORA92\USERS01.DBF 이 에러 메시지의 의미는 USERS01.DBF 데이터 파일의 SCN 번호와 다른 데이터 파일, 컨트롤 파일, 리두로그 파일의 SCN 번호가 일치하지 않는 것을 의미합니다. 즉, 데이터베이스에 장애가 발생한 것이며, USERS01.DBF 파일에 대한 복구가 요구 된다는 의미이기도 합니다. 결론적으로, 데이터베이스에 장애가 발생한 경우 오프라인 백업에 의해 데이터를 복구하기 위해서는 같은 시점에, 같은 SCN 번호를 가진 모든 파일들이 필요하다는 것 입니다. 즉, 오프라인 백업 시 모든 파일을 같은 시점에 백업해야 합니다.
	3) 노-아카이브 모드 또는 아카이브 모드에 관계없이 사용할 수 있습니다. 오프라인 백업 방법은 노-아카이브 모드에서 수행할 수 있으며, 앞으로 소개할 아카이브 모드에서도 수행할 수 있는 방법입니다.



	다음은 오프라인 백업의 단점에 대해서 알아 보도록 하겠습니다.
	1) 주요 특징에서 설명 드린 대로 이 방법은 데이터베이스를 종료(Shutdown)한 후 관련된 모든 파일들을 운영체계 상에서 복사해야 합니다. 문제는 복사해야 할 파일들의 크기가 작은 경우에는 문제되지 않겠지만, 파일들의 크기가 매우 큰 경우(몇 십, 몇 백 기가바이트 또는 테라 바이트)에는 많은 시간이 소요될 수 있기 때문에 그 동안 데이터베이스를 계속적으로 종료상태로 두어야 한다는 것 입니다. 결국, 오프라인인 백업이 수행되는 동안에 어떤 사용자도 데이터베이스에 접속할 수 없으며 데이터를 참조할 수 도 없다는 것 입니다.
	2) 오프라인 백업이 수행되기 위해서는 충분한 디스크 공간이 확보되어야 합니다. 현재 데이터 파일과 리구로그 파일의 크기 만큼 사용공간이 확보되어 있어야 만 오프라인 백업을 수행할 수 있기 때문입니다. 만약, 충분한 사용공간이 확보되지 않는다면 백업작업을 효과적으로 진행할 수 없게 됩니다.



	사례-1
	다음 사례는 노-아카이브 모드에서 사용자의 데이터 파일이 유실되는 경우 장애를 복구하는 방법입니다. 현재, 오라클 서버는 노-아카이브 모드이며 이미 오프라인 백업방법에 의해 데이터베이스 전체 백업이 수행되어 있는 상태입니다. 어느날, 오라클 데이터베이스에 장애가 발생하였고 관련 백업 파일들을 재 설치하려고 합니다. 그런데, 모든 백업 파일들은 정상적으로 재 설치 하였는데, USERS01.DBF 파일은 원래 디스크 경로에 재 설치할 수가 없었습니다. 왜냐하면, 해당 경로의 디스크에 베드 블록(Bad Block)이 발생하여 읽기, 쓰기 작업을 더 이상 수행할 수가 없기 때문입니다. 노-아카이브 모드에서 이런 경우가 발생하면 어떻게 오라클 데이터베이스를 복구할 수 있을까요?
	1) 먼저, 오프라인 백업 경로에서 백업된 파일들을 확인한 후 관련 경로에 재설치 하십시오. [C:\]cd c:\backup [C:\] dir System01.dbf …………………. init.ora …………………. [C:\] copy .ctl c:\oracle\oradata\ora92\.ctl ← 컨트롤 파일을 재설치 [C:\] copy .dbf c:\oracle\oradata\ora92\.dbf ← 데이터 파일을 재설치 [C:\] copy .log c:\oracle\oradata\ora92\.log ← 리두로그 파일을 재설치 [C:\] copy .ora c:\oracle\ora92\database ← 파라메터 파일을 재설치 [C:\] cd c:\oracle\oradata\ora92 [C:\] dir users01.dbf redo01b.log redo02b.log log3b.log ………………. [C:\] move users01.dbf d:\oracle\oradata\users01.dbf → USERS01.DBF 파일은 원래 디스크 경로에 재설치 할 수 없어 일단 다른 디스크 경로에 재설치합니다. [C:\]cd c:\oracle\ora92 [C:\] dir users
	2) USERS01.DBF 파일은 본래 경로에 재 설치하진 못했지만 기타 모든 파일들은 재설치 하였으므로 오라클 서버를 시작해 보십시오. 오픈 단계에서 USERS01.DBF 파일의 본래 경로로부터 관련 파일을 검색해 보지만 파일이 존재하지 않으므로 에러가 발생할 것 입니다. [C:\] sqlplus "/as sysdba" SQL> startup mount SQL> alter database open; alter database open * ORA-01157: cannot identify data file 3 - file not found ORA-01110: data file 3: 'c:\oracle\oradata\ora92\users01.dbf' SQL> select name from v$datafile; NAME ---------------------------------------------------……………………………………. c:\oracle\oradata\ora92\users01.dbf → 오라클 서버는 USERS01.DBF 파일이 처음에 있던 디렉토리 경로에 계속 있는 걸로 알고 있습니다.
	3) 이런 경우, 오라클 서버에게 재 설치된 경로가 어디인지 알려주게 되면 해당 경로로부터 관련 파일을 검색하게 됩니다. 오라클 서버의 구조 중에 관련 파일의 경로와 파일명이 저장되어 있는 곳은 컨트롤 파일입니다. 다음 명령문을 수행하게 되면 컨트롤 파일 내의 해당 정보가 변경되며 오픈 단계에서 이 정보를 통해 데이터베이스를 오픈하게 됩니다. SQL> alter database rename file 'c:\oracle\oradata\ora92\users01.dbf' to 'd:\oracle\ora92\users01.dbf ';
	4) 다시 오라클 서버를 시작해 보십시오. 오라클 서버는 컨트롤 파일 내에 변경된 경로로부터 USERS01.DBF 파일을 검색하여 정상적으로 오픈하게 됩니다. SQL> alter database open; → 정상적으로 오픈 됩니다.



	3-4 아카이브 모드
	지금까지, 노-아카이브 모드에 대한 개념과 데이터베이스에 장애가 발생한 경우 노-아카이브 모드에서 복구하는 방법과 절차에 대해서 자세히 알아 보았습니다. 이번에는 아카이브 모드에 대해서 자세히 알아 보도록 하겠습니다. 노-아카이브 모드에서 사용자가 실행한 DML문에 의해 발생하는 모든 데이터(변경 전 데이터와 변경 후 데이터)들은 리두로그 버퍼에 백업된 다음 LGWR 프로세스에 의해 리두로그 파일에 저장됩니다. 또한, 오라클 서버는 데이터베이스 생성 시 기본적으로 3개의 리두로그 파일을 제공하며 LGWR 프로세스는 첫 번째 파일에서 두 번째 파일로, 두 번째 파일에서 세 번째 파일로 쓰기 작업을 계속하게 됩니다. 이때, 마지막 세 번째 리두로그 파일도 모두 쓰여지고 나면 다시 첫 번째 리두로그 파일로 이동하여 쓰기 작업을 계속하게 됩니다. 문제는 첫 번째 리두로그 파일에 저장되어 있던 이전 백업 데이터는 새로운 백업 데이터에 의해 재작성(Rewrite) 되어 삭제된다는 것 입니다. "1편 오라클 서버구조와 백업/복구원리"에서도 자세히 설명 되었던 대로 리두로그 파일에 백업되는 데이터들은 장애 발생 시 데이터베이스를 복구하기 위한 용도입니다. 그런데. 이 데이터들이 LGWR 프로세스에 의해 재 작성된다는 것은 만약, 데이터베이스에 장애가 발생하는 경우 복구해야 할 백업 데이터들이 유실된다는 것을 의미합니다. 즉, 복구작업을 수행할 수 없게 된다는 것 입니다. 바로 이런 문제점을 개선하기 위해 오라클 사는 아카이브 모드(Archive Mode)라는 백업 메커니즘을 제공합니다. 위 그림에서, LGWR 프로세스가 첫 번째 리두로그 파일에 모든 변경 데이터를 저장한 후, 두 번째 리두로그 파일로 이동하는 순간, ARCH 백그라운드 프로세스는 첫 번째 리두로그 파일을 사용자가 미리 지정한 경로로 복사하게 됩니다. 그리고, 두 번째 파일에서 세 번째 리두로그 파일로 이동할 때도 두 번째 리두로그 파일을 ARCH 프로세스가 지정한 경로로 복사합니다. 마지막으로, 세 번째 리두로그 파일에서 다시 첫 번째 리두로그 파일로 이동할 때도 세 번째 리두로그 파일을 지정한 경로로 복사하게 됩니다. 그런 후, 다시 첫 번째 파일에 백업 데이터들을 재 작성하여 저장하게 됩니다. 아카이브 모드에서는 다시 첫 번째 리두로그 파일에 백업 데이터를 저장하더라도 이전 백업데이터는 이미 사용자가 지정한 경로에 ARCH 프로세스에 의해 복사되어 있기 때문에 데이터베이스에 장애가 발생하더라도 아카이브 파일을 통해 복구작업을 수행할 수 있게 됩니다. 즉, 데이터베이스에서 발생하는 모든 데이터(변경 전 데이터와 변경 후 데이터)들이 ARCH 프로세스에 의해 항상 백업되는 메커니즘을 아카이브 모드(Archive Mode)라고 합니다. 기본적으로 오라클 데이터베이스는 노-아카이브 모드이며 설치 후 아카이브 모드로 전환하는 작업을 수행하셔야 합니다.



	3-4-1 아카이브 모드의 환경설정 방법 다음은 데이터베이스를 노아카이브 모드에서 아카이브 모드로 전환하는 방법입니다.
	1) 먼저, init.ora 파일에 아카이브 모드와 관련된 파라메터를 설정하십시오. [LOG_ARCHIVE_START] 파라메터는 ARCH 백그라운드 프로세스에 의해 데이터베이스를 아카이브 모드로 전환하고 로그스위치가 발생하면 자동으로 아카이브를 실행합니다. [LOG_ARCHIVE_DEST] 파라메터는 리두 로그 파일에 대한 아카이브 파일이 생성될 기본 저장 경로를 의미합니다. LOG_ARCHIVE_DEST_n] 파라메터는 아카이브 경로를 여러 군데 지정할 때 사용합니다. 최대 10개의 경로지정이 가능합니다 [LOG_ARCHIVE_FORMAT] 파레메터는 [LOG_ARCHIVE_DEST] 또는 [LOG_ARCHIV E_DEST_n] 파라메터에 의해 지정된 경로에 생성될 아카이브 파일의 파일 포맷를 결정합니다. 파일의 포맷은 다음과 같습니다. [ %s ] 자동으로 생성될 아카이브 파일의 일련번호를 결정해 줍니다. (예) 1, 2, 3,,, [ %S ] 자동으로 생성될 아카이브 파일의 일련번호를 0 값으로 채워서 결정해 줍니다. (예) 00001, 00002, 00003 …… [ %t ] 데이터베이스가 하나의 인스턴스인지 또는 여러 개의 인스턴스(OPS 환경)로 구성되어 있는지를 구분하여 표시해 줍니다. (예) 1, 2, 3, ,,, [ %T ] 데이터베이스가 하나의 인스턴스인지 또는 여러 개의 인스턴스(OPS 환경)로 구성되어 있는지를 0 값으로 채워서 결정해 줍니다. (예) 001, 002, 003,,, [ %r ] 오라클 데이터베이스의 백업과 복구작업을 수행하다 보면 백업되었던 시점은 다르지만 동일한 아카이브 파일명이 생성되는 경우가 있습니다. 이런 경우, 현재 생성된 아카이브 파일과 이전에 생성된 아카이브 파일명이 동일하여 아카이브 파일을 저장, 관리하는데 혼돈을 유발시키게 됩니다. 이런 문제를 해결하기 위해 ALTER DATABASE OPEN RESETLOGS 명령어에 의해 데이터베이스가 재 시작된 후 새롭게 생성되는 아카이브 파일의 번호를 초기화할 수 있습니다. 이 구분 값은 오라클 10g 버전부터 제공됩니다. (예) 0533062963 , 0533062973



	2) 데이터베이스를 아카이브 모드로 전환하기 위해서는 데이터베이스를 다시 시작해야 하며 마운트(mount) 단계에서 'ALTER DATABASE ARCHIVELOG' 명령어를 실행해야 합니다. 반대로, 아카이브 모드에서 노아카이브 모드로 전환할 때는 'ALTER DATABASE NOARCHIVELOG' 명령어를 실행하십시오. 아카이브 모드로 전환이 되었으면 데이터베이스를 오픈 시키십시오.
	3) 전환작업이 완료되었으면 환경설정이 제대로 되었는지 확인해 보십시오. 다음은 사용 중인 데이터베이스에서 아카이브 모드 상태를 확인하는 방법입니다. SQL> CONNECT /AS SYSDBA SQL> ARCHIVE LOG LIST Database log mode Archive Mode ← 아카이브 모드 Automatic archival Enabled Archive destination C:\oracle\ora92\database\arch Oldest online log sequence 51 Current log sequence 53 이 결과를 참조했을 때 "Database log mode"의 결과가 "Archive Mode"임을 확인할 수 있습니다. SQL> SET LINESIZE 1000 SQL> SELECT GROUP#, SEQUENCE#, ARCHIVED, STATUS FROM V$LOG; GROUP# SEQUENCE# ARC STATUS ---------- ---------- ----- ---------------- 1 52 YES INACTIVE 2 53 NO CURRENT 3 51 NO INACTIVE 이 결과를 참조했을 때 ARC 컬럼의 값이 "YES"는 아키이브 모드라는 것을 의미합니다. SQL> SELECT ARCHIVER FROM V$INSTANCE; ARCHIVE ------- STARTED 이 결과를 참조했을 때 "STARTED"는 아키이브 모드라는 것을 의미합니다.

4장 OFF-Line 백업을 이용한 완전복구
	4-1 데이터베이스의 구조분석
	먼저, 오라클 사에서 제공하는 완전복구 방법에 대해 소개하기 전에 데이터베이스 관리자로써 장애와 복구에 대한 전반적인 내용을 이해하고 장애가 발생한 경우 효과적으로 복구작업을 수행하기 위해서 반드시 준비하셔야 할 내용이 있습니다. 그것은 바로, 여러분들이 관리하고 계시는 오라클 데이터베이스의 모든 파일에 대한 구조와 시스템에 대한 기본적인 정보입니다. 데이터베이스 관리자가 평소에 얼마나 정확하게 자신이 관리하고 있는 데이터베이스의 물리적 구조를 잘 이해하느냐는 장애 발생 시 얼마나 빠르고 효과적으로 데이터베이스를 복구할 수 있느냐를 결정하는 첫 번째 기준이 됩니다. 다음은 오라클 데이터베이스의 모든 물리적 구조정보를 분석하는 방법입니다.
	1) 현재 생성되어 있는 모든 물리적 구조를 분석한 다음 그 정보를 파일로 생성하십시오. [C:\] sqlplus "/as sysdba" SQL> SPOOL oracle_files.dat - 먼저, 모든 데이터 파일의 구조를 분석하십시오. SQL> COL TABLESPACE_NAME FORMAT A15 SQL> COL FILE_NAME FORMAT A50 SQL> SELECT file_id, file_name, tablespace_name FROM dba_data_files; FILE_ID FILE_NAME TABLESPACE_NAME -------- ------------------------------------- --------------- 1 C:\ORACLE\ORADATA\ORA92\SYSTEM01.DBF SYSTEM 2 C:\ORACLE\ORADATA\ORA92\UNDOTBS.DBF UNDOTBS 3 C:\ORACLE\ORADATA\ORA92\TEMP01.DBF TEMP 4 C:\ORACLE\ORADATA\ORA92\USERS01.DBF USERS- 다음은, 모든 컨트롤 파일의 구조를 분석하십시오. SQL> COL NAME FORMAT A50 SQL> SELECT * FROM v$controlfile; STATUS NAME ------------------------------------------------ C:\ORACLE\ORADATA\ORA92\CONTROL01.CTL C:\ORACLE\ORADATA\ORA92\CONTROL02.CTL C:\ORACLE\ORADATA\ORA92\CONTROL03.CTL- 마지막으로, 모든 리두로그 파일의 구조를 분석하십시오. SQL> COL MEMBER FORMAT A50 SQL> SELECT * FROM v$logfile; GROUP# STATUS TYPE MEMBER ---------- --------- ------ ---------------------------------- 1 ONLINE C:\ORACLE\ORADATA\ORA92\REDO01.LOG 2 ONLINE C:\ORACLE\ORADATA\ORA92\REDO02.LOG 3 ONLINE C:\ORACLE\ORADATA\ORA92\REDO03.LOG SQL> SPOOL OFF ← 운영체계 상에 ORACLE_FILE.DAT 파일이 생성됩니다. SQL> EXIT [C:\] EDIT ooracle_files.dat ← 저정된 물리적 구조정보를 참조할 수 있습니다.



	4-2 완전복구 방법
	4-2-1 전체 완전 복구 아카이브 모드 환경에서 데이터베이스에 장애가 발생하면 2가지 방법으로 복구작업을 수행할 수 있습니다. 첫 번째 방법은 완전 복구(Complete Recovery) 이며, 두 번째 방법은 불완전 복구(InComplete Recovery) 입니다. 장애가 발생한 시점에 어떤 복구 방법에 의해 데이터베이스를 복구할 것인지를 결정하는 것은 장애의 발생상태 및 복구 전략에 따라 선별적으로 사용할 수 있습니다. 예를 들어, 장애가 발생한 상태를 확인했을 때, 데이터 파일 만 문제가 생긴 경우와 데이터 파일과 리두로그 파일 모두에 문제가 발생한 경우에 복구 방법은 달라질 수 있다는 것 입니다. 또는, 오라클 데이터베이스를 구성하는 파일구조에 문제가 발생한 것이 아니라, 특정 테이블을 사용자가 실수에 의해 DROP 한 경우 복구 방법은 달라질 수 있습니다. 결론적으로, 장애가 발생한 시점에 먼저, 장애 원인을 정확하게 분석할 수 있어야 하며, 그 결과에 따라 적절한 복구 방법을 선택해야 한다는 것 입니다. 이러한 과정을 통해 장애 복구를 원활하게 수행하기 위해서는 오라클 서버의 구조를 완벽하게 이해해야 하며, 또한 각각의 복구 방법과 절차에 대한 명확한 이해와 장단점을 잘 알고 있어야 합니다. 자 ~ 그럼 아카이브 모드에서 수행할 수 있는 완전복구에 대해 보다 자세히 알아 봅시다. 완전복구(Complete Recovery)는 데이터베이스에 장애가 발생한 경우 마지막으로 수행한 오프라인 백업 데이터와 그 이후 생성된 아카이브 파일 그리고 아카이브 되지 않은 현재 시점의 백업 데이터를 저장하고 있는 리두로그 파일을 통해 장애가 발생한 시점까지의 모든 데이터를 완전하게 복구하는 방법입니다. 위 그림에서, 현재시점 2001년 6월 10일 오전 12시에 데이터베이스를 종료한 후 오프라인 백업을 통해 SCN 번호가 95인 모든 파일(데이터 파일, 컨트롤 파일, 리두로그 파일)들을 백업하고 있습니다. 현재, 데이터베이스는 아카이브 모드이며, 오프라인 백업 이후 발생한 모든 트랜잭션 데이터들은 아카이브 파일과 리두로그 파일에 기록되어 있습니다. 첫 번째 아카이브 파일 ARC1.LOG 에는 마지막 오프라인 백업 이후부터 2001년 6월 11일 오전 12시까지의 백업 데이터들이 저장 되었다고 합니다. 그리고, 두 번째 아카이브 파일 ARC2.LOG 에는 2001년 6월 11일 오전 12시부터 2001년 6월 12일 오전 12시까지의 백업 데이터들이 저장되었으며, 2001년 6월 12일 오전 12시부터 6월 12일 오후 13시까지의 데이터들은 ARC3.LOG 파일에 기록되어 있다고 합니다. 현재 시점, 2001년 6월 12일 오후 13시에 USERS01.DBF 데이터 파일이 저장되어 있는 디스크에 장애가 발생하여 더 이상 데이터베이스를 사용할 수 없다고 합니다.



	사례-4.
	아카이브 모드에서 DB 내의 특정 데이터 파일들이 장애가 발생하여 더 이상 입력, 수정, 삭제 작업을 수행할 수 없다고 합니다. 다행히 최근에 백업된 데이터 파일들과 아카이브 파일들은 정상적으로 사용 가능한 상태라고 합니다. 전체 데이터베이스 완전 복구를 수행해 보도록 하겠습니다.
	1) 오라클 서버가 사용 가능한 상태인지 확인하고 아카이브 파일들이 정상적으로 생성되는지 확인하십시오. [C:\] sqlplus "/as sysdba" SQL> startup SQL> host dir c:\oracle\oradata\ora92\arch\.arc → 현재, 아카이브 파일의 개수와 마지막 아카이브 파일번호를 메모해 두십시오. SQL> host more moredept.sql alter system switch logfile; insert into scott.dept values(1,'Personnel','Pusan'); insert into scott.dept values(2,'Account','Pusan'); insert into scott.dept values(3,'Q.C','Pusan'); alter system switch logfile; insert into scott.dept values(4,'Personnel','Seoul'); insert into scott.dept values(5,'Account','Seoul'); insert into scott.dept values(6,'Q.C','Seoul'); alter system switch logfile; insert into scott.dept values(7,'Personnel','Daejeon'); insert into scott.dept values(8,'Account','Daejeon'); insert into scott.dept values(9,'Q.C','Daejeon'); commit; select count() from scott.dept; → 이 스크립트를 실행하면 아카이브 파일들이 생성됩니다. SQL> @moredept.sql SQL> shutdown immediate SQL> exit [C:\] dir c:\oracle\oradata\ora92\arch\*.arc → MOREDEPT.SQL을 실행한 후 아카이브 파일이 몇 개 추가생성 되었는지 확인하십시오.
	2) 이 사례를 위해 USERS01.DBF 파일을 삭제한 후 오라클 서버를 다시 시작해 보십시오. OPEN 단계에서 파일의 삭제로 인해 데이터베이스의 무결성이 보장되지 않아 에러가 발생할 것 입니다. [C:\]dir c:\oracle\oradata\ora92\.dbf → USERS 테이블스페이스를 구성하는 데이터 파일 [C:\]del c:\oracle\oradata\ora92\users01.dbf → 해당 파일이 존재하는 디스크에 장애가 발생한 것으로 시나리오를 만듭니다. [C:\] dir c:\oracle\oradata\ora92\.dbf [C:\] sqlplus "/as sysdba" SQL> startup ORA-01157 데이터 9파일을 식별 또는 잠금할 수 없습니다-DBWR 추적파일을 보십시오 ORA-01110 : 9 데이터 파일: C:\ORALCE\ORADATA\ORA92\USERS01.DBF SQL> shutdown SQL> exit
	3) 이전에 받은 전체 오프라인 백업파일로부터 손상된 데이터 파일들을 재설치 한 후 전체 완전복구 방법으로 복구작업을 수행합니다. [C:\]cd c:\backup [C:\] dir [C:\]copy users01.dbf c:\oracle\oradata\ora92\users01.dbf [C:\]sqlplus "/as sysdba" SQL> startup Database mounted. ORA-01113: 9 파일이 매체 복구되어야 합니다. ORA-01110: 9 데이터 파일: C:\ORALCE\ORADATA\ORA92\USERS01.DBF SQL> SELECT * FROM V$RECOVER_FILE; FILE# ONLINE ERROR CHANGE# --------------------------------------------- 9 ONLINE 406577 SQL> recover database ORA-00279: Change 7474 generated at 04/24/97 22:52:31 ORA-00289: Suggestion : c:\oracle\oradata\ora92\arch\arch_256.arc ORA-00280: Change 7474 for thread 1 is in sequence #256 Specify log: {=suggested \| filename \| AUTO \| CANCEL} AUTO ← AUTO를 입력한 후 Enter를 누르면 모든 아카이브 파일들을 자동으로 적용해줍니다. Media recovery complete. → 정상적으로 복구작업이 완료되면 반드시 이 메시지가 출력됩니다. SQL> alter database open; → 현재 오라클 서버는 마운트 상태이므로 OPEN 합니다.
	4) 오라클 데이터베이스가 정상적으로 복구 되었는지 확인해 보십시오. SQL> select count(*) from scott.DEPT; SQL> shutdown immediate SQL> exit



	4-2-2 테이블스페이스 완전복구 이번에는, 완전복구(Complete Recovery) 3가지 방법 중에 테이블스페이스 완전복구에 대해 알아 보도록 하겠습니다. 전체 완전복구는 MOUNT 단계에서 모든 데이터 파일을 대상으로 복구작업을 수행하는 방법이라면, 테이블스페이스 완전복구는 OPEN 단계에서, 장애가 발생한 데이터 파일의 테이블스페이스를 기준으로 복구 작업을 수행하게 됩니다. 위 그림에서, 현재시점 2001년 6월 10일 오전 12시에 데이터베이스를 종료한 후 오프라인 백업을 통해 SCN 번호가 95인 모든 파일(데이터 파일, 컨트롤 파일, 리두로그 파일)들을 백업하고 있습니다. 현재, 데이터베이스는 아카이브 모드이며, 오프라인 백업 이후 발생한 모든 트랜잭션 데이터들은 아카이브 파일과 리두로그 파일에 기록되어 있습니다. ARC1.LOG, ARC2.LOG, ARC3.LOG 파일에 모든 백업 데이터들이 저장되었다고 합니다. 현재시점, 2001년 6월 12일 오후 13시에 USERS01.DBF 데이터 파일이 저장되어 있는 디스크에 장애가 발생하여 더 이상 관련 테이블스페이스를 사용할 수 없다고 합니다.



	사례-5.
	아카이브 모드에서 DB 내의 특정 데이터 파일들이 장애가 발생하여 더 이상 입력, 수정, 삭제 작업을 수행할 수 없다고 합니다. 다행히 최근에 백업된 데이터 파일들과 아카이브 파일들은 정상적으로 사용 가능한 상태라고 합니다. 그리고, 문제가 발생한 데이터 파일은 특정 테이블스페이스에 포함된 데이터 파일이라고 합니다. 이런 경우, 데이터베이스 전체를 대상으로 복구작업을 수행하게 되면 많은 시간이 소요될 수 있으므로 테이블스페이스 완전 복구방법을 수행해 보도록 하겠습니다.
	1) 오라클 서버가 사용 가능한 상태인지 확인하고 아카이브 파일들이 정상적으로 생성되는지 확인하십시오. [C:\] sqlplus "/as sysdba" SQL> startup SQL> host dir c:\oracle\ora92\database\arch\.arc → 현재, 생성되어 있는 아카이브 파일의 개수 및 마지막 파일명을 메모해 두십시오. SQL> host more moredept.sql alter system switch logfile; insert into scott.dept values(1,'Personnel','Pusan'); insert into scott.dept values(2,'Account','Pusan'); insert into scott.dept values(3,'Q.C','Pusan'); alter system switch logfile; insert into scott.dept values(4,'Personnel','Seoul'); insert into scott.dept values(5,'Account','Seoul'); insert into scott.dept values(6,'Q.C','Seoul'); alter system switch logfile; insert into scott.dept values(7,'Personnel','Daejeon'); insert into scott.dept values(8,'Account','Daejeon'); insert into scott.dept values(9,'Q.C','Daejeon'); commit; select count() from scott.dept; SQL> @moredept.sql SQL> shutdown immediate SQL> exit [C:\]dir c:\oracle\ora92\database\arch\*.arc → MOREDEPT.SQL을 실행한 후 생성된 아카이브 파일의 개수와 마지막 파일명을 메모해 두십시오.
	2) 이 실습을 위해 USERS01.DBF 파일을 삭제한 후 오라클 서버를 재 시작해 보십시오. OPEN 단계에서 해당 파일이 존재하지 않으므로 에러가 발생할 것 입니다. [C:\]dir c:\oracle\oradata\ora92\.dbf → USERS 테이블스페이스를 구성하고 있는 데이터 파일명을 확인하십시오. [C:\]del c:\oracle\oradata\ora92\users01.dbf → 이 실습을 위해 해당 파일을 삭제합니다. [C:\] dir c:\oracle\oradata\ora92\.dbf [C:\] sqlplus "/as sysdba" SQL> startup ORA-01157 데이터 9파일을 식별 또는 잠금할 수 없습니다-DBWR 추적파일을 보십시오 ORA-01110 : 9 데이터 파일: C:\ORALCE\ORADATA\ORA92\USERS01.DBF SQL> shutdown SQL> exit
	3) 이전에 수행된 전체 오프라인 백업 파일들로부터 손상된 USERS01.DBF 파일을 재설치한 후 테이블스페이스 완전복구 방법을 이용한 복구작업을 수행하십시오, [C:\]cd c:\backup [C:\]dir [C:\]copy users01.dbf c:\oracle\oradata\ora92\users01.dbf [C:\]sqlplus "/as sysdba" SQL> startup Database mounted. ORA-01113: 9 파일이 매체 복구되어야 합니다. ORA-01110: 9 데이터 파일: C:\ORALCE\ORADATA\ORA92\USERS01.DBF SQL> SELECT * FROM V$RECOVER_FILE; FILE# ONLINE ERROR CHANGE# ------ ----------- ------------- ------------ 9 ONLINE 406577 SQL> select FILE#, STATUS, NAME from v$datafile; ← USERS01.DBF 파일의 상태는 ONLINE SQL> alter database datafile 'c:\oracle\oradata\ora92\users01.dbf' offline; SQL> select FILE#, STATUS, NAME from v$datafile; ← USERS01.DBF 파일의 상태는 OFFLINE SQL> alter database open; SQL> select TABLESPACE_NAME, STATUS from dba_tablespaces; TABLESPACE_NAME STATUS ----------------------- -------------------------- USERS ONLINE SQL> alter tablespace users offline immediate; SQL> select TABLESPACE_NAME, STATUS from dba_tablespaces; TABLESPACE_NAME STATUS ------------------------ ------------------------ USERS OFFLINE SQL> recover tablespace users ORA-00279: Change 7220 generated at 02/24/97 23:51:30 ORA-00289: Suggestion : /DBAX/DBA805/dba숫자/arch_219.arc ORA-00280: Change 7220 for thread 1 is in sequence #219 Specify log: {=suggested \| filename \| AUTO \| CANCEL} AUTO → 관련된 모든 아카이브 파일들을 자동 적용해 줍니다. SQL> select count() from scott.dept; ← 에러 발생, 복구는 되었지만 offline 상태 ORA-00376: 현재 파일 9를 읽을 수 없습니다. ORA-01110: 9 데이터 파일 SQL> alter tablespace users online; SQL> select count() from scott.dept; → 정상적으로 수행 됨 SQL> shutdown immediate SQL> exit



	4-2-3 데이터 파일 완전복구 이번에는, 완전복구의 마지막 방법 인 데이터 파일 완전복구 방법을 소개하도록 하겠습니다. 위 그림에서, 현재시점 2001년 6월 10일 오전 12시에 데이터베이스를 종료한 후 오프라인 백업을 통해 SCN 번호가 95인 모든 파일(데이터 파일, 컨트롤 파일, 리두로그 파일)들을 백업하고 있습니다. 현재, 데이터베이스는 아카이브 모드이며, 오프라인 백업 이후 발생한 모든 트랜잭션 데이터들은 아카이브 파일과 리두로그 파일에 기록되어 있습니다. ARC1.LOG, ARC2.LOG, ARC3.LOG 파일에 모든 백업 데이터들이 저장되었다고 합니다. 현재시점, 2001년 6월 12일 오후 13시에 USERS01.DBF 데이터 파일이 저장되어 있는 디스크에 장애가 발생하여 더 이상 관련 파일을 사용할 수 없다고 합니다.



	사례-6
	아카이브 모드에서 DB 내에 특정 데이터 파일들이 장애가 발생하여 더 이상 입력, 수정, 삭제 작업을 수행할 수 없다고 합니다. 다행히 최근에 백업된 데이터 파일들과 아카이브 파일들은 정상적으로 사용 가능한 상태라고 합니다. 현재, 장애가 발생한 데이터 파일은 하나의 데이터 파일이라고 합니다. 이런 경우, 전체 데이터베이스 또는 특정 테이블스페이스 완전 복구방법을 수행하게 되면 불필요한 복구 시간이 소요될 수 있으므로 이번에는 데이터 파일 완전 복구 방법을 수행해 보도록 하겠습니다.
	1) 오라클 서버가 사용 가능한 상태인지 확인하고 아카이브 파일들이 정상적으로 생성되는지 확인하십시오. [C:\] sqlplus "/as sysdba" SQL> startup SQL> host dir c:\oracle\ora92\database\arch\.arc → 현재 생성되어 있는 아카이브 파일의 개수와 마지막 파일명을 메모해 두십시오. SQL> host more moredept.sql alter system switch logfile; insert into scott.dept values(1,'Personnel','Pusan'); insert into scott.dept values(2,'Account','Pusan'); insert into scott.dept values(3,'Q.C','Pusan'); alter system switch logfile; insert into scott.dept values(4,'Personnel','Seoul'); insert into scott.dept values(5,'Account','Seoul'); insert into scott.dept values(6,'Q.C','Seoul'); alter system switch logfile; insert into scott.dept values(7,'Personnel','Daejeon'); insert into scott.dept values(8,'Account','Daejeon'); insert into scott.dept values(9,'Q.C','Daejeon'); commit; select count() from scott.dept; SQL> @moredept.sql SQL> shutdown immediate SQL> exit [C:\]dir c:\oracle\ora92\database\arch\*.arc → MOREDEPT.SQL을 실행한 후 추가 생성된 아카이브 파일의 개수와 마지막 파일명을 메모해 두십시오.
	2) 이 실습예제를 수행하기 위해 USERS01.DBF 파일을 삭제한 후 오라클 서버를 다시 시작해 보십시오. 해당 파일이 더 이상 존재하지 않기 때문에 OPEN 단계에서 에러가 발생할 것 입니다. [C:\]dir c:\oracle\oradata\ora92\.dbf → USERS 테이블스페이스가 구성하는 테이터 파일을 확인하십시오. [C:\]del c:\oracle\oradata\ora92\users01.dbf → 실습 시나리오를 위해 USERS01.DBF 파일을 삭제하십시오. [C:\] dir c:\oracle\oradata\ora92\.dbf [C:\] sqlplus "/as sysdba" SQL> startup ORA-01157 데이터 9파일을 식별 또는 잠금할 수 없습니다-DBWR 추적파일을 보십시오 ORA-01110 : 9 데이터 파일: C:\ORALCE\ORADATA\ORA92\USERS01.DBF SQL> shutdown SQL> exit
	3) 이전에 수행된 전체 오프라인 백업 파일로부터 해당 파일을 재설치하고 데이터 파일 완전복구 방법을 이용한 복구작업을 수행하십시오. [C:\] cd c:\backup [C:\] copy users01.dbf c:\oracle\oradata\ora92\users01.dbf [C:\]sqlplus "/as sysdba" SQL> startup Database mounted. ORA-01113: 9 파일이 매체 복구되어야 합니다. ORA-01110: 9 데이터 파일: C:\ORALCE\ORADATA\ORA92\USERS01.DBF SQL> SELECT * FROM V$RECOVER_FILE; FILE# ONLINE ERROR CHANGE# ------ --------- ------------- ----------------- 9 ONLINE 406577 SQL> select FILE#, STATUS, NAME from v$datafile; ← USERS01.DBF 파일은 삭제되었지만 데이터 딕션어리에는 해당 파일이 아직 사용 가능한 상태로 나타납니다.(ONLINE 컬럼이 ONLINE) 데이터 파일 완전복구 작업을 수행하기 위해서는 OFFLINE 상태이어야 합니다. SQL> alter database datafile 'c:\oracle\oradata\ora92\users01.dbf' offline; SQL> alter database open; ← 컨트롤 파일 내에 USERS01.DBF 파일의 상태가 OFFLINE 되었기 때문에 오라클 서 버를 오픈할 수 있습니다. 이 의미는 USERS01.DBF가 ONLINE 상태에서는 항상 파 일의 존재 유무를 확인하게 되지만, OFFLINE 상태에서는 확인하지 않기 때문에 오라클 서버를 오픈할 수 있게 됩니다. SQL> recover datafile ' c:\oracle\oradata\ora92\users01.dbf' ; ORA-00279: Change 7220 generated at 02/24/97 23:51:30 needed ORA-00289: Suggestion : c:\oracle\oradata\ora92\arch\arch_219.arc ORA-00280: Change 7220 for thread 1 is in sequence #219 Specify log: {=suggested \| filename \| AUTO \| CANCEL} Auto ← 관련된 모든 아카이브 파일들을 자동으로 적용해 줍니다. Media Complete Recovery … ← 정상적으로 복구작업이 완료되었습니다. SQL> select count() from scott.dept; - → USERS01.DBF 파일은 아직 OFFLINE 상태이기 때문에 검색할 수 없습니다. SQL> alter database datafile 'c:\oracle\oradata\ora92\users01.dbf ' online; SQL> select count() from scott.dept; → 정상적으로 수행 됨

5장 OFF-Line 백업을 이용한 불완전 복구
	5-1 불완전 복구
	완전복구(Complete Recovery) 방법은 데이터베이스에 장애가 발생한 경우 그 시점까지의 모든 백업 데이터를 아카이브 파일과 리두로그 파일에 저장해 둔 후 복구 작업 시 사용하는 방법입니다. 실제 기업환경에서 데이터베이스를 운영하다 보면 예기치 못한 원인으로 인해 장애가 발생하는 경우 거의 대부분의 경우는 문제가 발생한 시점까지 모든 데이터를 복구하는 것이 원칙일 것 입니다. 하지만, 특별한 경우에는 문제가 생긴 시점이 아닌 그 이전 시점의 어느 순간까지 만 복구해야 하는 경우도 때로는 발생하게 됩니다. 이런 경우, 완전복구 방법으로는 과거 어느 시점까지의 복구는 할 수 없기 때문에, 반드시 불완전 복구방법을 사용해야 합니다. 오라클 사에서는 시간기반 불완전 복구(Time Based Incomplete Recovery), 취소기반 불완전 복구(Cancel Based Incomplete Recovery), 변경기반 불완전 복구(Change Based Incomplete Recovery) 방법을 제공하고 있습니다.
	5-1-1 시간기반 불완전 복구 자~ 그럼, 불완전 복구의 대표적 방법인 시간기반 복구에 대해서 먼저 알아보겠습니다. 데이터베이스를 운영하다 보면 대부분의 경우는 물리적 구조(시스템, 디스크 장치 등)의 장애로 인해 더 이상 데이터베이스를 사용할 수 없는 경우를 보게 됩니다. 하지만, 사용자가 DML문을 수행한 후 실수로 COMMIT문을 실행하게 되는 경우나 DROP 또는 ALTER 문장으로 원치 않게 데이터가 변경되는 경우가 발생하게 됩니다. 시간기반 불완전 복구방법은 주로 사용자의 실수로 인해 해당 테이블의 데이터가 변경되어 데이터베이스의 신뢰성이 깨지는 경우 데이터베이스를 변경 이전상태로 복구하기 위해 사용되는 복구방법 중에 하나 입니다. 위 그림에서, 현재 시점 2001년 6월 10일 오전 12시에 데이터베이스를 종료한 후 오프라인 백업을 통해 SCN 번호가 95인 모든 파일(데이터 파일, 컨트롤 파일, 리두로그 파일)들을 백업하고 있습니다. 현재, 데이터베이스는 아카이브 모드이며, 오프라인 백업 이후 발생한 모든 트랜잭션 데이터들은 아카이브 파일과 리두로그 파일에 기록되어 있습니다. ARC1.LOG, ARC2.LOG, ARC3.LOG 파일에 모든 백업 데이터들이 저장되었다고 합니다. 현재시점, 2001년 6월 11일 오후 12시 10분 11초에 사용자가 실수로 EMP 테이블을 삭제했다고 합니다. 이 사실을 모른체 사용자들은 다른 테이블에 대해 입력, 수정, 삭제작업을 계속 수행했다고 합니다. 현재시점, 2001년 6월 12일 13시 USERS01.DBF 데이터 파일이 저장되어 있는 디스크에 장애가 발생하여 더 이상 데이터베이스를 사용할 수 없다고 합니다. 데이터베이스 관리자는 완전복구 방법을 통해 장애가 발생한 USERS01.DBF 데이터 파일을 복구하려고 합니다. 하지만, 완전복구 작업을 수행하게 되면 EMP 테이블은 여전히 DROP된 상태로 복구되기 때문에 테이블을 복구할 수 없다고 합니다. EMP 테이블이 복구되기 위해서는 장애가 발생한 시점까지 복구해서는 안되며, EMP 테이블이 DROP 되기 이전 상태까지만 복구해야 합니다.



	사례-7.
	사용자가 실수로 테이블을 DROP 했다고 합니다. 완전복구 작업을 수행하게 되면 해당 테이블이 삭제된 상태로 복구되기 때문에 반드시 불완전 복구작업을 수행해야 합니다.
	(1) 오라클 서버가 사용 가능한 상태인지 확인하고 MOREDEPT.SQL을 실행한 후 아카이브 파일들이 정상적으로 생성되는지 확인하십시오. [C:\] sqlplus "/as sysdba" SQL> @moredept.sql alter system switch logfile; insert into scott.dept values(1,'Personnel','Pusan'); insert into scott.dept values(2,'Account','Pusan'); insert into scott.dept values(3,'Q.C','Pusan'); alter system switch logfile; insert into scott.dept values(4,'Personnel','Seoul'); insert into scott.dept values(5,'Account','Seoul'); insert into scott.dept values(6,'Q.C','Seoul'); alter system switch logfile; insert into scott.dept values(7,'Personnel','Daejeon'); insert into scott.dept values(8,'Account','Daejeon'); insert into scott.dept values(9,'Q.C','Daejeon'); commit; select count(*) from scott.dept;
	(2) 데이터베이스를 사용하던 중 개발자가 실수로 DEPT 테이블을 삭제하였다고 합니다. 이 테이블은 전체 업무에서 사용되는 아주 중요한 데이터를 저장하고 있기 때문에 반드시 필요한 테이블이라고 합니다. 하지만, DROP 명령어는 AUTO-COMMIT을 자동 수행하기 때문에 삭제된 테이블은 더 이상 사용할 수 없게 됩니다. SQL> host date → 현재 날짜를 메모해 두십시오. SQL> host time → 현재 시간을 메모해 두십시오, SQL> drop table scott.dept cascade constraints; --> 개발자가 실수로 DEPT 테이블을 삭제하였다고 합니다. SQL> select * from scott.dept; select * from scott.dept * ERROR at line 1: ORA-00942: table or view does not exist
	(3) 지금까지 대부분의 시나리오는 운영체계 상에서 관련된 파일들을 더 이상 사용할 수 없게 되는 경우에 대한 물리적 복구 방법이었다면, 이번 시나리오는 데이터베이스 내에서 중요한 테이블이 삭제된 경우의 논리적 복구방법을 소개하게 될 것 입니다. 이전에 오프라인 백업된 파일들 중에 모든 데이터 파일들 만 해당 경로에 재설치 하십시오. 반드시, 데이터 파일들 만 재 설치하셔야 하며 컨트롤 파일과 리두로그 파일들은 정상적으로 사용 가능한 상태이므로 재 설치하실 필요는 없습니다. SQL> shutdown immediate SQL> exit [C:\] cd c:\backup [C:\] copy *.dbf c:\oracle\oradata\ora92 → 반드시, 모든 데이터 파일들 만 재 설치하십시오.
	(4) 자, 그럼, 삭제된 하나의 테이블을 복구하기 위해 시간기반 불완전 복구작업을 수행해 보도록 하겠습니다. [C:\] sqlplus "/as sysdba" SQL> startup mount SQL> recover database until time '2001-01-23:16:44:47'; ORA-00279: Change 7220 generated at 02/24/97 23:51:30 needed ORA-00289: Suggestion : c:\oracle\oradata\ora92\arch\arch_219.arc ORA-00280: Change 7220 for thread 1 is in sequence #219 Specify log: {=suggested \| filename \| AUTO \| CANCEL} Auto ← 관련된 모든 아카이브 파일들을 자동으로 적용해 줍니다. Media Complete Recovery → 마지막, 오프라인 백업파일을 재 설치하고 그 이후에 생성된 아카이브 파일들을 순차적으로 적용하면서 실수로 테이블을 DROP한 이전 시점까지 만 복구한다면 삭제된 테이블을 복구할 수 있을 것 입니다. (2) 단계에서 메모해 둔 날자와 시간정보를 'YYYY-MM-DD HH:MM:SI'포맷으로 정의하시면 됩니다. 반드시, 날자 포맷을 임의로 변경해서는 안됩니다. SQL> alter database open resetlogs; → 불완전 복구가 수행되었으면 데이터베이스를 RESETLOG 옵션을 사용하여 OPEN 하십시오. 불완전 복구에 의한 복구작업 시에는 반드시 이 옵션을 사용하셔야 합니다. 현재, 데이터베이스는 과거 DEPT 테이블이 삭제되기 이전 상태로 복구된 상태 입니다. 그런데, 컨트롤 파일과 리두로그 파일은 복구작업을 수행하기 이전의 현 상태 에 대한 정보를 가지고 있기 때문에 시점이 일치하지 않는 문제점이 발생하게 됩니다. 결국, 이 상태에서는 데이터베이스를 정상적으로 OPEN 할 수 없기 때문에 RESETLOG 옵션을 사용하여 모든 상태정보를 초기화할 수 밖에 없게 됩니다. SQL> archive log list 데이터베이스 로그모드 아카이브 모드 가장 오래된 온라인 로그순서 1 ← 상태정보가 초기화된 것을 확인하십시오. 아카이브할 다음 로그 1 현재 로그순서 1 SQL> select * from scott.dept; → 삭제되었던 DEPT 테이블이 다시 검색됩니다. 현재, 데이터베이스는 DEPT 테이블이 삭제되기 이전 상태로 복구되어 있기 때문에 DEPT 테이블을 검색할 수 있는 것 입니다. SQL> shutdown immediate SQL> exit
	5) 불완전 복구가 완료되었으면 현재 시점의 오프라인 백업을 수행하십시오. 대부분의 개발자들이 불완전 복구를 수행한 후 오프라인 백업을 수행하지 않다가 여가지 문제로 인해 데이터베이스를 복구하지 못하는 경우가 종종 발생합니다. 현재 시점에서는 마지막 오프라인 백업된 파일들은 더 이상 복구작업에 사용될 수 없는 무의미한 파일들에 불과합니다. 이유는 불완전 복구를 수행하게 되면, 데이터베이스 내의 모든 상태 정보들이 초기화되기 때문에 이전의 오프라인 백업 파일들이 가지고 있는 상태정보와 일치될 수 없기 때문 입니다. [C:\] cd c:\oracle\oradata\ora92 [C:\] copy . c:\backup [C:\] copy c:\oracle\ora92\database\init.ora c:\backup → 관련된 모든 데이터 파일, 컨트롤 파일, 리두로그 파일, 파라메터 파일들을 오프라인 백업 하십시오. [C:\] del c:\oracle\oradata\ora92\arch\*.arc → 불완전 복구에 의해 데이터베이스의 모든 상태 정보들이 초기화되면 이전까지 생성 되었던 아카이브 파일들도 이젠 더 이상 필요 없는 파일들이 됩니다. 아카이브 파일들은 사용 가능한 마지막 오프라인 백업파일 이후에 생성된 것 들만 사용 가능하므로 초기화된 현재 시점에서는 이전의 아카이브 파일은 사용될 수 없습니다.



	5-1-2 취소기반 불완전 복구 이번에는 불완전 복구의 두 번째 방법인 취소기반 복구방법에 대해서 알아 보도록 하겠습니다. 대부분의 기업환경에서 데이터베이스에 장애가 발생하면 장애가 발생한 시점까지의 모든 데이터를 안전하게 복구하는 것이 원칙일 것 입니다. 하지만, 백업 데이터 파일과 아카이브 파일의 보관 및 관리 상의 문제로 인해 복구를 정상적으로 수행하지 못하는 경우도 때로는 발생하게 됩니다. 이런 경우에는 사용 가능한 백업 데이터를 이용하여 복구할 수 있는 시점까지 만이라고 최대한 복구작업을 수행해야 할 것 입니다. 바로 이런 경우의 복구방법을 취소기반 불완전 복구라고 합니다. 위 그림에서, 현재 시점 2001년 6월 10일 오전 12시에 데이터베이스를 종료한 후 오프라인 백업을 통해 SCN 번호가 95인 모든 파일(데이터 파일, 컨트롤 파일, 리두로그 파일)들을 백업하고 있습니다. 현재, 데이터베이스는 아카이브 모드이며, 오프라인 백업 이후 발생한 모든 트랜잭션 데이터들은 아카이브 파일과 리두로그 파일에 기록되어 있습니다. ARC1.LOG, ARC2.LOG, ARC3.LOG 파일에 모든 백업 데이터들이 저장되었다고 합니다. 현재시점, 2001년 6월 12일 오후 13시, 시스템 관리자가 실수로 USERS01.DBF 데이터 파일을 삭제했다고 합니다. 이 사실을 모른체 사용자들은 해당 데이터 파일에 저장되어 있는 테이블에 대해 입력, 수정, 삭제작업을 수행하려고 합니다. 하지만, 이 시점에 해당 디크크에는 USERS01.DBF 파일은 존재하지 않기 때문에 사용자들은 더 이상 데이터베이스를 사용할 수 없게 됩니다. 문제는, 이 데이터 파일에 대한 복구 작업을 수행하기 위해 복구작업 시 사용되어야 할 모든 아카이브 파일들 중에 몇 개가 유실되어 사용될 수 없다고 합니다.



	사례-8
	어느 날, 모든 리두로그 파일이 존재하는 디스크에 장애가 발생했다고 합니다. 현재 데이터베이스는 아카이브 모드이며 최근에 전체 데이터베이스 백업이 수행되었다고 합니다. 장애가 발생한 시점까지의 모든 데이터는 복구할 수 있을까요 ? 결론적으로 말씀드리면, 마지막 백업 데이터가 저장되어 있던 온라인 리두로그 파일이 아카이브 되지 않은 상태에서 유실되었기 때문에 완전복구 작업은 수행할 수 없는 상태입니다. 즉, 불완전 복구작업을 수행해야 합니다.
	(1) 오라클 서버가 사용 가능한 상태인지 확인하고 MOREDEPT.SQL을 실행한 후 아카이브 파일들이 정상적으로 생성되는지 확인하십시오. [C:\] sqlplus "/as sysdba" SQL> startup SQL> @moredept.sql alter system switch logfile; insert into scott.dept values(1,'Personnel','Pusan'); insert into scott.dept values(2,'Account','Pusan'); insert into scott.dept values(3,'Q.C','Pusan'); alter system switch logfile; insert into scott.dept values(4,'Personnel','Seoul'); insert into scott.dept values(5,'Account','Seoul'); insert into scott.dept values(6,'Q.C','Seoul'); alter system switch logfile; insert into scott.dept values(7,'Personnel','Daejeon'); insert into scott.dept values(8,'Account','Daejeon'); insert into scott.dept values(9,'Q.C','Daejeon'); commit; select count(*) from scott.dept;
	(2) 이번 시나리오는 여러 개의 리두로그 파일들 중에 LGWR 프로세스에 의해 현재 쓰여지고 있는 CURRENT 리두로그 파일에 장애가 발생한 경우 복구하는 방법과 절차를 소개합니다. 먼저, 현재 사용하고 있는 오라클 서버에서 CURRENT 상태의 리두로그 파일을 확인하십시오. 그리고, CURRENT 리두로그 파일을 삭제하여 장애가 발생한 시나리오를 만들어 보시기 바랍니다. SQL> select member from v$log where status = 'CURRENT'; MEMBER --------------------------------------------------- c:\oracle\oradata\ora92\redo01.log → 만약, 현재 데이터베이스에서 REDO01.LOG 파일이 CURRENT 상태의 리두로그 파일이 라면 다음과 같이 화면에 출력됩니다. SQL> host dir c:\oracle\oradata\ora92 SQL> host del c:\oracle\oradata\ora92\redo01.log → Windows 환경의 운영체계에서는 서버에 의해 삭제가 안됩니다. SQL> host del c:\oracle\oradata\ora92\redo01b.log → Windows 환경의 운영체계에서는 서버에 의해 삭제가 안됩니다. SQL> host dir c:\oracle\oradata\ora92 SQL> @moredept.sql → 온라인 리두로그 파일이 유실되었기 때문에 에러가 발생합니다. 또는, 무한정 대기상태에 빠지게 되기도 합니다. SQL> shutdown abort → 에러가 발생하는 경우에는 오라클 서버가 자동 종료됩니다. 경우에 따라서는 무한정 대기상태에 빠지기도 하는데 이런 경우에는, 정상적인 복구작업을 수행하기 위해서 강제로 오라클 서버를 종료 시켜야 합니다. 바로 이때, SHUTDOWN 명령어의 ABORT 옵션을 이용하시면 오라클 서버를 강제 종료 시킬 수 있습니다.
	(3) 자~ 그럼, CURRENT 리두로그 파일이 유실된 경우 불완전 복구를 수행해 봅시다. 오라클 서버가 자동 종료되었거나, ABORT 옵션에 의해 강제 종료된 다음 다시 오라클 서버를 MOUNT 단계까지 만 시작한 다음 불완전 복구를 수행하기 위해 마지막 오프라인 백업 파일들 중에 모든 데이터 파일들 만 재 설치합니다. SQL> startup SQL> alter database drop logfile group 그룹번호; → 일반적으로 INACTIVE 리두로그 파일이 유실된 경우에는 관련 리두로그 파일을 제거한 후 다시 재 생성함으로써 복구작업을 완료할 수 있었습니다. 같은 방법으로 복구가 가능한지 수행해 보십시오. 하지만, CURRENT 리두로그 파일은 ALTER DATABASE DROP LOGFILE~ 명령어로는 더 이상 삭제할 수 없습니다. 왜냐하면, CURRENT 상태의 리두로그는 현재 쓰여지고 있는 파일을 의미하기 때문에 데이터베이스 관리자도 삭제할 수 없기 때문 입니다. SQL> shutdown immediate SQL> exit
	(4) 다음은 정상적인 불완전 복구를 수행하는 방법과 절차입니다. 먼저, 현재 생성되어 있는 마지막 아카이브 파일이 몇 번인지 확인해 두십시오. 다음과 같이 여러 가지 방법을 통해 확인할 수 있습니다. 첫 번째 방법은 ALERT 파일의 로그 내용을 분석해 보면 마지막 아카이브 파일의 번호를 알아 낼 수 있습니다. [C:\] cd c:\oracle\admin\ora92\bdump [C:\] dir [C:\] edit ALERT_.log → 파일의 끝부분으로 이동해서 Archiving을 실패한 기록과 Sequence 번호 확인 예를 들어, ORA-00255: error archiving log 1 of thread 1, sequence # 15 sequence # 15번이라면 마지막 아카이브 파일번호가 15번 입니다. 두 번째 방법은 아카이브 파일이 생성되어 있는 경로로 이동하여 마지막 파일 번호를 확인하는 방법입니다. [C:\] DEL C:\ORACLE\ORA92\DATABASE\ARCH [C:\] dir
	(5) 이전에 마지막으로 오프라인 백업된 파일들 중에 모든 데이터 파일들만 재설치하십시오. 컨트롤 파일과 리두로그 파일들은 재 설치할 필요가 없습니다. 모든 파일들을 재 설치하게 되면 완전복구 방법이 되며, 데이터 파일들 만 설치하면 불완전 복구가 됩니다. [C:\] cd c:\backup [C:\] copy *.dbf c:\oracle\oradata\ora92 [C:\] sqlplus "/as sysdba" SQL> startup mount SQL> recover database until cancel ORA-00279: Change 7220 generated at 02/24/97 23:51:30 needed ORA-00289: Suggestion : c:\oracle\oradata\ora92\arch\arch_1.arc ORA-00280: Change 7220 for thread 1 is in sequence #1 Specify log: {=suggested \| filename \| AUTO \| CANCEL} Enter ← 1번 아카이브 파일을 적용해 줍니다. ORA-00279: Change 7220 generated at 02/24/97 23:51:30 needed ORA-00289: Suggestion : c:\oracle\oradata\ora92\arch\arch_2.arc ORA-00280: Change 7220 for thread 1 is in sequence #2 Specify log: {=suggested \| filename \| AUTO \| CANCEL} Enter ← 2번 아카이브 파일을 적용해 줍니다. ………………………….. ORA-00279: Change 7220 generated at 02/24/97 23:51:30 needed ORA-00289: Suggestion : c:\oracle\oradata\ora92\arch\arch_15.arc ORA-00280: Change 7220 for thread 1 is in sequence #15 Specify log: {=suggested \| filename \| AUTO \| CANCEL} Enter ← 15번 아카이브 파일을 적용해 줍니다. ORA-00279: Change 7220 generated at 02/24/97 23:51:30 needed ORA-00289: Suggestion : c:\oracle\oradata\ora92\arch\arch_16.arc ORA-00280: Change 7220 for thread 1 is in sequence #16 Specify log: {=suggested \| filename \| AUTO \| CANCEL} CANCEL ← 아카이브 파일을 적용하기 전에 현재 시점까지 생성되어 있는 마지막 아카이브 파일이 15번까지 생성되어 있는 것을 확인하였습니다. 그렇다면, 16번 아카이브 파일은 존재하지 않으므로 더 이상 복구작업을 수행할 수 없습니다. CANCEL을 입력하면 복구작업은 중단됩니다. Media Complete Cancel. ← 불완전 복구작업이 완료되었습니다. SQL> alter database open resetlogs; → 불완전 복구는 데이터베이스의 모든 상태가 불 일치하기 때문에 복구작업을 완료한 후 반드시 RESETLOGS 옵션을 사용하여 OPEN 해야 합니다. 이 명령어를 실행하면 유실된 모든 리두로그 파일들이 자동으로 생성됩니다. SQL> archive log list 데이터베이스 로그모드 아카이브 모드 가장 오래된 온라인 로그순서 1 ← 모든 상태정보가 초기화 된 것을 확인하십시오. 아카이브할 다음 로그 1 현재 로그순서 1 SQL> shutdown immediate SQL> exit
	(6) 데이터베이스의 모든 상태정보가 초기화되는 불완전 복구방법이 수행되고 나면 마지막으로 백업되었던 백업파일은 더 이상 사용할 수 없으므로 반드시 오프라인 백업을 수행해야 합니다. 또한, 오프라인 백업이 수행되고 나면 이전의 모든 트레이스 파일와 로그 파일, 아카이브 파일들을 삭제하십시오. [C:\] cd c:\oracle\oradata\ora92 [C:\] copy . c:\backup [C:\] copy c:\oracle\ora92\database\init.ora c:\backup [C:\] del c:\oracle\admin\ora92\udump\.trc [C:\] del c:\oracle\admin\ora92\bdump\alert_.log [C:\] cd c:\oracle\ora92\database\arch [C:\] del .arc [C:\] dir



	사례-9
	데이터베이스의 컨트롤 파일이 존재하는 디스크에 장애가 발생하여 더 이상 입력, 수정, 삭제 작업을 수행할 수 없습니다. 모든 컨트롤이 유실된 상태이며 마지막으로 백업된 컨트롤 파일 만이 사용 가능한 상태입니다. 어떻게 복구해야 할까요 ?
	(1) 오라클 서버가 사용 가능한 상태인지 확인하고 MOREDEPT.SQL을 실행한 후 아카이브 파일들이 정상적으로 생성되는지 확인하십시오. [C:\] sqlplus "/as sysdba" SQL> startup SQL> @moredept alter system switch logfile; insert into scott.dept values(1,'Personnel','Pusan'); insert into scott.dept values(2,'Account','Pusan'); insert into scott.dept values(3,'Q.C','Pusan'); alter system switch logfile; insert into scott.dept values(4,'Personnel','Seoul'); insert into scott.dept values(5,'Account','Seoul'); insert into scott.dept values(6,'Q.C','Seoul'); alter system switch logfile; insert into scott.dept values(7,'Personnel','Daejeon'); insert into scott.dept values(8,'Account','Daejeon'); insert into scott.dept values(9,'Q.C','Daejeon'); commit; select count() from scott.dept; SQL> host dir c:\oracle\ora92\database\arch\.arc
	(2) 이번 사례는 데이터베이스의 모든 상태정보와 오라클 서버의 시작과 종료 시 반드시 필요한 컨트롤 파일에 대한 내용입니다. 여러 개의 컨트롤 파일 중 하나라도 장애가 발생하면 더 이상 오라클 서버를 사용할 수 없기 때문에 오라클 데이터베이스 구조 중에 가장 중요한 파일 중에 하나입니다. 먼저, 현재 사용하고 있는 오라클 서버에서 컨트롤 파일의 위치와 개수를 확인하십시오. 그리고, 모든 컨트롤 파일을 삭제하여 장애가 발생한 시나리오를 만들어 보시기 바랍니다. SQL> shutdown abort --> 오라클 서버가 비정상적으로 종료됩니다. SQL> exit [C:\] del c:\oracle\oradata\ora92\*.ctl ← 사용자의 실수로 인해 모든 컨트롤 파일이 삭제됩니다. (실제 기업환경에서는 임의로 컨트롤 파일을 삭제해서는 안됩니다.)
	(3) 결론적으로 모든 컨트롤 파일에 장애가 발생하면 더 이상 오라클 데이터베이스를 사용할 수 없게 됩니다. 이런 현상이 발생하는 경우에는 불완전 복구방법을 사용합니다. 마지막 오프라인 백업된 백업 파일로부터 모든 컨트롤 파일을 현재 경로로 재 설치하십시오. [C:\]copy c:\backup\.ctl c:\oracle\oradata\ora92\.ctl [C:\] sqlplus "/as sysdba" SQL> startup mount SQL> recover database using BACKUP controlfile ← 현재 환경은 컨트롤 파일 만 이전의 백업 파일이고 다른 파일들은 현재 시점의 파일들이기 때문에 컨트롤 파일 만의 복구작업을 수행하기 위해 USING BACKUP CONTROLFILE 절을 사용하여 복구작업을 수행해야 합니다. ORA-00279: Change 8050 generated at 01/20/98 15:22:26 needed for thread 1 Specify log: {=suggested \| filename \| AUTO \| CANCEL} C:\oracle\oradata\ora92\arch\arch_1.arc ← 만약, 적용해야 할 아카이브 파일이 지정되지 않으면 직접 첫 번째 아카이브 파일의 경로와 이름을 입력해야 합니다. 적용해야 할 아카이브 파일명이 출력 되는 경우에는 AUTO 키워드를 입력하여 자동으로 아카이브를 적용하시면 됩니다. ORA-00279: Change 8050 generated at 01/20/98 15:22:26 needed ORA-00280: Change 8050 for thread 1 is in sequence arch_2.arc Specify log: {=suggested \| filename \| AUTO \| CANCEL} AUTO ← 첫 번째 아카이브를 적용하면 두 번째 아카이브 파일의 이름과 경로가 출력되고 해당 파일을 적용할 것 인지가 나타납니다. ORA-00279: Change 8050 generated at 01/20/98 15:22:26 needed ORA-00280: Change 8050 for thread 1 is in sequence arch_n.arc ← 여러 개의 아카이브 파일을 적용하다 마지막 아카이브 파일을 적용하려고 했을 때 에러가 발생할 수 도 있습니다. 이런 경우는 적용해야 할 마지막 백업 데이터가 아카이브 파일로 저장되어 있는 것이 아니라, CURRENT 리두로그 파일에 저장되어 있기 때문입니다. 이러 경우에는 마지막 CURRENT 리두로그 파일의 경로와 이름을 지정해 주시면 됩니다. SQL> recover database using BACKUP controlfile 에러가 발생하면 다시 리두로그 파일을 적용해 줄 수 없으므로 RECOVER DATABASE 명령어를 재 수행하시면 됩니다. ORA-00279: Change 8050 generated at 01/20/98 15:22:26 needed ORA-00280: Change 8050 for thread 1 is in sequence arch_n.arc Specify log: {=suggested \| filename \| AUTO \| CANCEL} c:\oracle\oradata\ora92\redo01.log --> 마지막 CURRENT 리두로그 파일명을 입력하십시오 Log applied. Media recovery complete. SQL> alter database open resetlogs; ← 절차와 방법은 완전복구 방법과 같지만 결론적으로 이 방법은 불완전 복구입니다. 왜냐하면, 데이터베이스의 모든 상태정보가 저장되어 있는 컨트롤 파일이 삭제되었 기 때문에 컨트롤 파일은 복구되었지만 상태정보는 복구되지 않았기 때문입니다. SQL> select count(*) from scott.dept; --> 정상적으로 검색이 가능합니다. SQL> shutdown SQL> exit
	(4) 불완전 복구를 수행하고 나면 반드시 이전의 마지막 백업파일은 재 사용될 수 없기 때문에 다시 오프라인 백업을 수행해야 합니다. 또한, 이전의 아카이브 파일, 트레이스 파일들도 제거 하십시오. [C:\] cd c:\oracle\oradata\ora92 [C:\] copy . c:\backup [C:\] copy c:\oracle\ora92\database\init.ora c:\backup

6장 ON-Line 백업을 이용한 장애복구
	6-1 테이블스페이스 온라인 백업
	오라클 데이터베이스를 사용하는 사용자들의 기업환경은 매우 다양합니다. 아침에 출근해서 저녁에 퇴근하는 기업이 있는가 하면, 퇴근 후에도 24시간 동안 인터넷을 통해 계속해서 고객으로부터 제품에 대한 주문 또는 서비스 요청을 받는 기업들도 있습니다. 지금까지 소개되었던 대표적인 백업방법은 오라클 서버를 종료한 후 관련된 모든 파일들을 복사하는 방법인 오프라인(Off-Line) 백업이 소개되었습니다. 그리고, 오프라인 백업된 파일들을 통해 오라클 데이터베이스에 장애가 발생한 경우 복구하는 방법과 절차에 대해서도 자세히 알아 보았습니다. 만약, 24시간 동안 계속적인 기업활동을 수행하는 회사에서 오라클 데이터베이스를 백업하기 위해 반드시 오프라인 백업을 수행해야 한다면 백업을 수행하는 시간 동안에는 고객으로부터 어떤 주문 접수도 처리할 수 없는 상태가 될 수 밖에 없을 것 입니다. 기업 입장에서는 오라클 서버를 종료할 수도 없고, 주문접수도 수행할 수 없는 지경에 이르게 되어 궁극적으로는 불안한 시스템 운영을 할 수밖에 없을 것 입니다. 이런 문제점을 해결하기 위해, 오라클 사는 24시간 365일 동안 데이터베이스를 사용하는 기업환경에서 오라클 서버를 종료하지 않고도 효과적인 백업작업을 수행할 수 있도록 온라인(On-Line) 백업방법을 제공하고 있습니다. 이 백업방법은 오픈(OPEN) 백업 또는 핫(HOT) 백업방법이라고 불리어지기도 합니다. 그리고, 온라인 백업은 반드시 아카이브 모드에서 만 수행할 수 있는 백업방법 입니다. 온라인 백업에는 2가지 백업 방법이 있습니다. 첫 번째는 테이블스페이스 단위의 백업이며 두 번째는 전체 데이터베이스 온라인 백업 방법입니다. 첫 번째 방법은 오라클 10g 이전 버전에서도 제공되었으며 두 번째 방법은 10g 버전부터 제공되었습니다. 자~ 그럼, 테이블스페이스 단위의 온라인 백업 방법부터 자세히 알아 보도록 합시다. 다음은 온라인 백업의 방법과 절차에 대한 자세한 설명입니다.
	(1) 먼저, 오라클 데이터베이스는 사용 가능한 상태이어야 합니다. STARTUP 명령어에 의해 정상적으로 시작되어야 하며 사용자들의 SELECT, UPDATE, INSERT, DELETE 작업이 정상적으로 수행 가능해야 합니다. (2) 다음은, 오라클 데이터베이스가 아카이브 모드로 운영되고 있는지 확인하십시오. 온라인 백업방법은 반드시 아카이브 모드이어야 합니다. 왜냐하면, 오라클 서버가 사용자들에 의해 사용되고 있는 와중에 백업되는 방법이기 때문에 노-아카이브 모드에서는 수행될 수 없기 때문입니다. 만약, 어떤 데이터 파일을 온라인 백업하고 있는데 그 파일에 존재하는 테이블에 대해 누군가가 변경작업을 수행한다면 백업작업이 완료된 후 변경된 데이터를 해당 데이터 파일에 반드시 변경해야 하기 때문입니다. SQL> archive log list 데이터베이스 로그모드 아카이브 모드 가장 오래된 온라인 로그순서 1 아카이브할 다음 로그 1 현재 로그순서 1 (3) 다음은, 해당 테이블스페이스에 대한 온라인 백업하는 방법입니다. 온라인 백업은 테이블스페이스 단위로 관련된 데이터 파일을 복사할 수 있습니다. SQL> MKDIR C:\ONLINE_BACKUP -- SYSTEM 테이블스페이스에 대한 온라인 백업 SQL> ALTER TABLESPACE SYSTEM BEGIN BACKUP; SQL> HOST COPY c:\oracle\oradata\ora92\system01.dbf c:\online_backup SQL> ALTER TABLESPACE SYSTEM END BACKUP; --TEMP 테이블스페이스에 대한 온라인 백업 SQL> ALTER TABLESPACE TEMP BEGIN BACKUP; SQL> HOST COPY c:\oracle\oradata\ora92\temp01.dbf c:\online_backup SQL> ALTER TABLESPACE TEMP END BACKUP; -- UNDOTBS 테이블스페이스에 대한 온라인 백업 SQL> ALTER TABLESPACE UNDOTBS BEGIN BACKUP; SQL> HOST COPY c:\oracle\oradata\ora92\undotbs01.dbf c:\online_backup SQL> ALTER TABLESPACE UNDOTBS END BACKUP; -- QUERY 테이블스페이스에 대한 온라인 백업 SQL> ALTER TABLESPACE QUERY BEGIN BACKUP; SQL> HOST COPY c:\oracle\oradata\ora92\query01.dbf c:\online_backup SQL> ALTER TABLESPACE QUERY END BACKUP; < 주의 > 온라인 백업을 수행하면서 가장 주의해야 할 점은 ALTER TABLESPACE ~ BEGIN BACKUP; 명령문과 ALTER TABLESPACE ~ END BACKUP; 명령문을 수행하는 시간의 차이입니다. BEGIN BACKUP문을 실행하는 순간부터 관련 테이블스페이스의 모든 파일들에는 CHECKPOINT가 더 이상 발생하지 않게 되며 END BACKUP문을 실행하는 순간 CHECKPOINT가 다시 발생하게 됩니다.(CHECKPOINT의 기본원리에 대해서는 "2편 데이터베이스의 논리적/물리적 구조설계"를 참조 하십시오.) 오라클 서버는 이러한 원리에 의해, 해당 테이블스페이스에 대한 백업시점을 관리하게 됩니다. 결론적으로 테이블스페이스를 생성할 때 너무 큰 크기의 데이터 파일을 생성하게 되면 온라인 백업을 수행할 때 CHECKPOINT의 시점관리에 문제가 발생하여 에러가 발생할 수도 있습니다. 너무 큰 크기의 데이터 파일들은 2~3개 정도로 나누어 스트라이핑(Striping) 하시는 것이 원활한 백업과 복구작업에 도움이 될 수 있습니다. (4) 온라인 백업된 모든 데이터 파일들을 확인하십시오. [C:\] CD C:\ONLINE_BACKUP [C:\] DIR SYSTEM01.DBF UNDOTBS01.DBF TEMP01.DBF QUERY01.DBF



	6-2 데이터베이스 전체 온라인 백업
	오라클 사에서 제공하는 2가지 온라인 백업방법 중에 먼저 테이블스페이스 단위의 백업 방법을 알아 보았습니다. 온라인 백업방법은 24시간 365일 동안 오라클 데이터베이스를 종료할 수 없는 기업환경에서 매우 적절하게 수행할 수 있는 백업방법 중에 하나라는 것은 두말하면 잔소리일 것 입니다. 하지만, 이 백업방법의 가장 큰 단점은 오라클 데이터베이스를 구성하고 있는 모든 테이블스페이스에 대한 전체 백업이 요구되는 경우입니다. ALTER TABLESPACE ~ BEGIN BACKUP과 ALTER TABLESPACE ~ END BACKUP 명령어를 반복적으로 수행해야 하기 때문에 번거로울 뿐만 아니라 READ ONLY 모드의 테이블스페이스와 OFFLINE 모드의 테이블스페이스에 대해서는 수행할 수 없는 것이 단점이기도 합니다. 이러한 문제점을 개선한 백업방법이 바로 전체 데이터베이스 온라인 백업방법 입니다. 이 백업방법은 오라클 10g 버전부터 제공됩니다.
	(1) ALTER DATABASE BEGIN BACKUP과 ALTER DATABASE END BACKUP 명령어 SQL> ALTER DATABASE BEGIN BACKUP; ← 전체 DB 온라인 백업 시작 SQL> host copy c:\oracle\oradata\ora92\system01.dbf c:\full_online_backup SQL> host copy c:\oracle\oradata\ora92\undotbs01.dbf c:\full_online_backup SQL> host copy c:\oracle\oradata\ora92\temp01.dbf c:\full_online_backup SQL> host copy c:\oracle\oradata\ora92\temp02.dbf c:\full_online_backup SQL> host copy c:\oracle\oradata\ora92\users01.dbf c:\full_online_backup SQL> host copy c:\oracle\oradata\ora92\query01.dbf c:\full_online_backup SQL> ALTER DATABASE END BACKUP; ← 전체 DB 온라인 백업의 종료
	(2) 오프라인 상태의 테이블스페이스는 테이블스페이스 단위의 온라인 백업을 수행할 수 없지만, 전체 데이터베이스 온라인 백업방법으로는 가능합니다. SQL> ALTER TABLESPACE users OFFLINE IMMEDIATE; SQL> SELECT tablespace_name, status FROM dba_tablespaces; TABLESPACE_NAME STATUS ------------------------------ --------- SYSTEM ONLINE UNDOTBS ONLINE TEMP ONLINE USERS OFFLINE SQL> ALTER TABLESPACE users BEGIN BACKUP; * ERROR at line 1: ORA-01128 : cannot start online backup - file 4 is offline ORA-01110 : data file 4 : 'c:\oracle\oradata\ora92\users01.dbf' SQL> ALTER DATABASE BEGIN BACKUP; SQL> host copy c:\oracle\oradata\ora92\users01.dbf c:\full_online_backup SQL> ALTER DATABASE END BACKUP;
	(3) READ ONLY 상태의 테이블스페이스는 테이블스페이스 단위의 온라인 백업을 수행할 수 없지만, 전체 데이터베이스 온라인 백업방법으로는 가능합니다 SQL> select tablespace_name, status from dba_tablespaces; TABLESPACE_NAME STATUS ------------------------------------ QUERY READ ONLY ← READ ONLY 상태를 확인하십시오. SQL> ALTER TABLESPACE query BEGIN BACKUP; alter tablespace users begin backup 1행에 오류: ORA-01642: 읽기 전용 'USERS' 테이블스페이스에는 초기 백업이 필요하지 않습니다. SQL> ALTER DATABASE BEGIN BACKUP; SQL> host copy c:\oracle\oradata\ora92\query01.dbf c:\full_online_backup SQL> ALTER DATABASE END BACKUP;



	6-3 온라인 백업을 이용한 완전 복구
	온라인 백업파일을 이용한 오라클 데이터베이스의 복구방법에 대해서 알아 보도록 하겠습니다. 지금까지 대부분의 사례 내용들이 오프라인 백업파일을 이용한 복구 방법이었다면 이번 사례는 온라인 백업된 파일을 이용하는 방법입니다. 결론적으로 말씀 드리면, 오라클 데이터베이스의 모든 복구방법은 백업된 파일이 오프라인 백업 파일이든, 온라인 백업 파일이든 상관없이 모두 동일한 방법과 절차에 의해 수행하게 됩니다. 지금부터 설명하는 방법과 절차는 이미 소개된 완전복구 방법과 동일합니다. 다만, 복구작업을 수행할 때 온라인 백업된 파일을 이용하는 것 입니다. 위 그림에서, 현재 시점 2001년 6월 10일 오전 12시에 데이터베이스의 상태에서 온라인 백업을 통해 SCN 번호가 95인 USERS01.DBF 데이터 파일을 백업하고 있습니다. 현재, 데이터베이스는 아카이브 모드이며, 온라인 백업 이후 발생한 모든 트랜잭션 데이터들은 아카이브 파일과 리두로그 파일에 기록되어 있습니다. 첫 번째 아카이브 파일 ARC1.LOG 에는 마지막 오프라인 백업 이후부터 2001년 6월 11일 오전 12시까지의 백업 데이터들이 저장 되었다고 합니다. 그리고, 두 번째 아카이브 파일 ARC2.LOG 에는 2001년 6월 11일 오전 12시부터 2001년 6월 12일 오전 12시까지의 백업 데이터들이 저장되었으며, 2001년 6월 12일 오전 12시부터 6월 12일 오후 13시까지의 데이터들은 ARC3.LOG 파일에 기록되어 있다고 합니다. 현재시점, 2001년 6월 12일 오후 13시에 USERS01.DBF 데이터 파일이 저장되어 있는 디스크에 장애가 발생하여 더 이상 데이터베이스를 사용할 수 없다고 합니다.



	사례-9
	컨트롤 파일들이 저장되어 있는 모든 디스크에 장애가 발생하였습니다. 또한 모든 데이터 파일이 저장되어 있던 디스크에도 치명적인 문제가 발생하였습니다. 마지막, 온라인 백업 파일을 이용하여 완전 복구작업을 수행해 보도록 하겠습니다.
	(1) 오라클 서버가 사용 가능한 상태인지 확인하고 MOREDEPT.SQL을 실행한 후 아카이브 파일들이 정상적으로 생성되는지 확인하십시오 [C:\] sqlplus "/as sysdba" SQL> startup SQL> @moredept alter system switch logfile; insert into scott.dept values(1,'Personnel','Pusan'); insert into scott.dept values(2,'Account','Pusan'); insert into scott.dept values(3,'Q.C','Pusan'); alter system switch logfile; insert into scott.dept values(4,'Personnel','Seoul'); insert into scott.dept values(5,'Account','Seoul'); insert into scott.dept values(6,'Q.C','Seoul'); alter system switch logfile; insert into scott.dept values(7,'Personnel','Daejeon'); insert into scott.dept values(8,'Account','Daejeon'); insert into scott.dept values(9,'Q.C','Daejeon'); commit; select count() from scott.dept; SQL> host dir c:\oracle\ora92\database\arch\.arc
	(2) 이번 시나리오는 모든 컨트롤 파일과 데이터 파일이 함께 장애가 발생했다고 합니다. 마지막으로 온라인 백업된 파일을 이용하여 오라클 데이터베이스를 복구해 봅시다. SQL> shutdown abort ← 갑작스런 정전상태를 만들기 위해 ABORT 옵션으로 오라클 서버를 강제 종료합니다. SQL> exit [C:\] del c:\oracle\oradata\ora92\system01.dbf [C:\] del c:\oracle\oradata\ora92\undotbs01.dbf [C:\] del c:\oracle\oradata\ora92\temp01.dbf [C:\] del c:\oracle\oradata\ora92\temp02.dbf [C:\] del c:\oracle\oradata\ora92\users01.dbf [C:\] del c:\oracle\oradata\ora92\query01.dbf → 모든 데이터 파일들에 장애가 발생합니다. [C:\] del c:\oracle\oradata\ora92\*.ctl → 모든 컨트롤 파일들에 장애가 발생합니다.
	(3) 자~ 지금부터 온라인 백업파일을 이용하여 완전복구 작업을 수행해 보도록 하겠습니다. 먼저, 장애가 발생한 모든 컨트롤 파일과 데이터 파일에 대한 온라인 백업 파일들을 현재 경로로 재 설치하십시오. [C:\] cd c:\online_backup [C:\] dir [C:\] copy system01.dbf c:\oracle\oradata\ora92 [C:\] copy undotbs01.dbf c:\oracle\oradata\ora92 [C:\] copy temp01.dbf c:\oracle\oradata\ora92 [C:\] copy temp02.dbf c:\oracle\oradata\ora92 [C:\] copy users01.dbf c:\oracle\oradata\ora92 [C:\] copy query01.dbf c:\oracle\oradata\ora92 → 장애가 발생한 모든 데이터 파일들을 재 설치합니다. [C:\] copy backup_control.ctl c:\oracle\oradata\ora92\control01.ctl [C:\] copy backup_control.ctl c:\oracle\oradata\ora92\control02.ctl [C:\] copy backup_control.ctl c:\oracle\oradata\ora92\control03.ctl [C:\] copy backup_control.ctl c:\oracle\oradata\ora92\control04.ctl → 장애가 발생한 모든 컨트롤 파일들을 재 설치합니다. 만약, 컨트롤 파일의 개수가 4개이면 백업된 파일을 4번 해당 경로에 복사해야 합니다. [C:\] cd [C:\] sqlplus "/as sysdba" SQL> startup mount SQL> recover database using backup controlfile → 복구해야 할 대상 파일에 이전의 컨트롤 파일이 포함되어 있으므로 USING BACKUP CONTROLFILE 옵션절을 사용하여 복구작업을 수행해야 합니다. ORA-00279: Change 8050 generated at 01/20/98 15:22:26 needed ORA-00280: Change 8050 for thread 1 is in sequence #5 Specify log: {=suggested \| filename \| AUTO \| CANCEL} AUTO ← AUTO 키워드를 사용하여 모든 아카이브 파일을 적용합니다. ORA-00279: Change 8050 generated at 01/20/98 15:22:26 needed ORA-00280: Change 8050 for thread 1 is in sequence arch_n.arc ERROR 발생 ← AUTO 키워드를 적용하여 아카이브를 적용했지만 마지막 아카이브 파일 을 적용할 때 에러가 발생하는 경우가 있습니다. 왜냐하면, 적용해야 할 마지막 백업 데이터는 아카이브 파일에 저장되어 있지 않고 CURRENT 리두로그 파일에 존재하기 때문입니다. SQL> recover database using BACKUP controlfile; → 에러가 발생하는 경우에는 다시 RECOVER DATABASE ~ 명령어를 실행하십시오. ORA-00279: Change 8050 generated at 01/20/98 15:22:26 needed ORA-00280: Change 8050 for thread 1 is in sequence arch_n.arc Specify log: {=suggested \| filename \| AUTO \| CANCEL} c:\oracle\oradata\ora92\redo01.log ← 마지막 백업 데이터가 저장되어 있는 CURRENT 리두로그 파일을 입력해 주십시오. Log Applied. Media Complete Recovery. ← 복구작업이 완료되었습니다. SQL> alter database open resetlogs; → 백업된 컨트롤 파일을 이용한 복구작업은 수행과정과 절차는 완전복구 방법과 동일하지만, OPEN 단계에서 반드시 RESETLOGS 옵션을 사용해야 합니다. 왜냐하면, 컨트롤 파일은 현재 시점으로 복구되었지만 데이터베이스 내의 상태정보는 여전히 일치하지 않기 때문입니다. 반드시, 모든 상태정보를 초기화 해야만 OPEN 할 수 있습니다. SQL> select count(*) from scott.dept; → 정상적으로 복구된 것을 확인하십시오. SQL> shutdown SQL> exit
	(4) 불완전 복구를 수행하고 나면 반드시 이전의 마지막 백업파일은 재 사용될 수 없기 때문에 다시 오프라인 백업을 수행해야 합니다. 또한, 이전의 아카이브 파일, 트레이스 파일들도 제거 하십시오. [C:\] copy c:\oracle\oradata\ora92\. c:\backup [C:\] copy c:\oracle\admin\ora92\init.ora c:\backup [C:\] del c:\oracle\oradata\ora92\arch\*.arc



	사례-9
	데이터베이스의 컨트롤 파일이 존재하는 디스크에 장애가 발생하여 더 이상 입력, 수정, 삭제 작업을 수행할 수 없습니다. 모든 컨트롤이 유실된 상태이며 마지막으로 백업된 컨트롤 파일 만이 사용 가능한 상태입니다. 어떻게 복구해야 할까요 ?
	(1) 오라클 서버가 사용 가능한 상태인지 확인하고 MOREDEPT.SQL을 실행한 후 아카이브 파일들이 정상적으로 생성되는지 확인하십시오. [C:\] sqlplus "/as sysdba" SQL> startup SQL> @moredept alter system switch logfile; insert into scott.dept values(1,'Personnel','Pusan'); insert into scott.dept values(2,'Account','Pusan'); insert into scott.dept values(3,'Q.C','Pusan'); alter system switch logfile; insert into scott.dept values(4,'Personnel','Seoul'); insert into scott.dept values(5,'Account','Seoul'); insert into scott.dept values(6,'Q.C','Seoul'); alter system switch logfile; insert into scott.dept values(7,'Personnel','Daejeon'); insert into scott.dept values(8,'Account','Daejeon'); insert into scott.dept values(9,'Q.C','Daejeon'); commit; select count() from scott.dept; SQL> host dir c:\oracle\ora92\database\arch\.arc
	(2) 이번 사례는 데이터베이스의 모든 상태정보와 오라클 서버의 시작과 종료 시 반드시 필요한 컨트롤 파일에 대한 내용입니다. 여러 개의 컨트롤 파일 중 하나라도 장애가 발생하면 더 이상 오라클 서버를 사용할 수 없기 때문에 오라클 데이터베이스 구조 중에 가장 중요한 파일 중에 하나입니다. 먼저, 현재 사용하고 있는 오라클 서버에서 컨트롤 파일의 위치와 개수를 확인하십시오. 그리고, 모든 컨트롤 파일을 삭제하여 장애가 발생한 시나리오를 만들어 보시기 바랍니다. SQL> shutdown abort --> 오라클 서버가 비정상적으로 종료됩니다. SQL> exit [C:\] del c:\oracle\oradata\ora92\*.ctl ← 사용자의 실수로 인해 모든 컨트롤 파일이 삭제됩니다. (실제 기업환경에서는 임의로 컨트롤 파일을 삭제해서는 안됩니다.)
	(3) 결론적으로 모든 컨트롤 파일에 장애가 발생하면 더 이상 오라클 데이터베이스를 사용할 수 없게 됩니다. 이런 현상이 발생하는 경우에는 불완전 복구방법을 사용합니다. 마지막 오프라인 백업된 백업 파일로부터 모든 컨트롤 파일을 현재 경로로 재 설치하십시오. [C:\]copy c:\backup\.ctl c:\oracle\oradata\ora92\.ctl [C:\] sqlplus "/as sysdba" SQL> startup mount SQL> recover database using BACKUP controlfile ← 현재 환경은 컨트롤 파일 만 이전의 백업 파일이고 다른 파일들은 현재 시점의 파일들이기 때문에 컨트롤 파일 만의 복구작업을 수행하기 위해 USING BACKUP CONTROLFILE 절을 사용하여 복구작업을 수행해야 합니다. ORA-00279: Change 8050 generated at 01/20/98 15:22:26 needed for thread 1 Specify log: {=suggested \| filename \| AUTO \| CANCEL} C:\oracle\oradata\ora92\arch\arch_1.arc ← 만약, 적용해야 할 아카이브 파일이 지정되지 않으면 직접 첫 번째 아카 이브 파일의 경로와 이름을 입력해야 합니다. 적용해야 할 아카이브 파일 명이 출력되는 경우에는 AUTO 키워드를 입력하여 자동으로 아카이브를 적용하시면 됩니다. ORA-00279: Change 8050 generated at 01/20/98 15:22:26 needed ORA-00280: Change 8050 for thread 1 is in sequence arch_2.arc Specify log: {=suggested \| filename \| AUTO \| CANCEL} AUTO ← 첫 번째 아카이브를 적용하면 두 번째 아카이브 파일의 이름과 경로가 출력되고 해당 파일을 적용할 것 인지가 나타납니다. ORA-00279: Change 8050 generated at 01/20/98 15:22:26 needed ORA-00280: Change 8050 for thread 1 is in sequence arch_n.arc ← 여러 개의 아카이브 파일을 적용하다 마지막 아카이브 파일을 적용하려고 했을 때 에러가 발생할 수 도 있습니다. 이런 경우는 적용해야 할 마지막 백업 데이터가 아카이브 파일로 저장되어 있는 것이 아니라, CURRENT 리두 로그 파일에 저장되어 있기 때문입니다. 이러 경우에는 마지막 CURRENT 리두로그 파일의 경로와 이름을 지정해 주시면 됩니다. SQL> recover database using BACKUP controlfile 에러가 발생하면 다시 리두로그 파일을 적용해 줄 수 없으므로 RECOVER DATABASE 명령어를 재 수행하시면 됩니다. ORA-00279: Change 8050 generated at 01/20/98 15:22:26 needed ORA-00280: Change 8050 for thread 1 is in sequence arch_n.arc Specify log: {=suggested \| filename \| AUTO \| CANCEL} c:\oracle\oradata\ora92\redo01.log --> 마지막 CURRENT 리두로그 파일명을 입력하십시오 Log applied. Media recovery complete. SQL> alter database open resetlogs; ← 절차와 방법은 완전복구 방법과 같지만 결론적으로 이 방법은 불완전 복구입니다. 왜냐하면, 데이터베이스의 모든 상태정보가 저장되어 있는 컨트롤 파일이 삭제되었 기 때문에 컨트롤 파일은 복구되었지만 상태정보는 복구되지 않았기 때문입니다. SQL> select count(*) from scott.dept; --> 정상적으로 검색이 가능합니다. SQL> shutdown SQL> exit
	(4) 불완전 복구를 수행하고 나면 반드시 이전의 마지막 백업파일은 재 사용될 수 없기 때문에 다시 오프라인 백업을 수행해야 합니다. 또한, 이전의 아카이브 파일, 트레이스 파일들도 제거 하십시오. [C:\] cd c:\oracle\oradata\ora92 [C:\] copy . c:\backup [C:\] copy c:\oracle\ora92\database\init.ora c:\backup



	사례-10
	현재, 데이터베이스는 아카이브 모드입니다. 최근에 온라인 백업과 오프라인 백업도 정상적으로 수행되었습니다. 백업 작업 이후에 새로운 데이터 파일이 생성되었고 사용자의 데이터가 입력되었습니다. 하지만, 곧 해당 디스크에 장애가 발생하였습니다. 마지막 백업파일에는 존재하지 않는 새로 생성된 데이터 파일은 어떻게 복구할 수 있을까요 ?
	(1) 오라클 서버가 사용 가능한 상태인지 확인하고 MOREDEPT.SQL을 실행한 후 아카이브 파일들이 정상적으로 생성되는지 확인하십시오. [C:\] sqlplus "/as sysdba" SQL> startup SQL> @moredept alter system switch logfile; insert into scott.dept values(1,'Personnel','Pusan'); insert into scott.dept values(2,'Account','Pusan'); insert into scott.dept values(3,'Q.C','Pusan'); alter system switch logfile; insert into scott.dept values(4,'Personnel','Seoul'); insert into scott.dept values(5,'Account','Seoul'); insert into scott.dept values(6,'Q.C','Seoul'); alter system switch logfile; insert into scott.dept values(7,'Personnel','Daejeon'); insert into scott.dept values(8,'Account','Daejeon'); insert into scott.dept values(9,'Q.C','Daejeon'); commit; select count() from scott.dept; SQL> host dir c:\oracle\ora92\database\arch\.arc
	(2) 마지막 백업 이후에 NEW_DATA 테이블스페이스가 추가로 생성되었다고 합니다. 그리고, NEW_TEST 테이블을 NEW_DATA 테이블스페이스에 생성한다고 합니다. SQL> create tablespace new_data datafile 'c:\oracle\oradata\ora92\new_data.dbf' size 500k; SQL> create table scott.new_test tablespace new_data as select * from scott.dept; SQL> @moredept.sql
	(3) 갑작스런 정전이 발생하고 새로 생성한 NEW_DATA 테이블스페이스에 장애가 발생한다고 합니다. SQL> shutdown abort ← 갑작스런 정전이 발생합니다. SQL> exit [C:\] dir c:\oracle\oradata\ora92 [C:\] del c:\oracle\oradata\ora92\new_data.dbf a NEW_DATA 테이블스페이스에 장애가 발생합니다. [C:\] dir c:\oracle\oradata\ora92 (3) 그런데, 문제가 있군요 ~ NEW_DATA 테이블스페이스는 마지막 백업 시에는 존재하지 않던 데이터 파일이기 때문에 복구작업을 수행하기 위해 재 설치할 백업 파일이 존재하지 않기 때문입니다. 백업 파일이 존재하지 않는 복구는 어떻게 수행해야 할까요 ? 결론적으로 말하면, 마지막 백업 이후에 발생한 모든 작업내용은 리두로그 파일과 아카이브 파일에 남아있기 때문에 오라클 서버가 아카이브 모드라면 쉽게 복구할 수 있습니다. [C:\] sqlplus "/as sysdba" SQL> startup ORA-01157: 데이터 4 파일을 식별 또는 잠금할 수 없습니다-DBWR 추적파일 ORA-01110: data file 7: ' dir c:\oracle\oradata\ora92\new_data.dbf' SQL> alter database create datafile 'c:\oracle\oradata\ora92\new_data.dbf' as 'c:\oracle\oradata\ora92\new_data.dbf'; → 아카이브 파일에는 모든 작업에서 발생한 변경 데이터 만 존재하기 때문에 데이터 파일(NEW_DATA.DBF)에 대한 구조는 별도로 생성해 주어야 합니다. SQL> host dir c:\oracle\oradata\ora92 SQL> recover datafile 'c:\oracle\oradata\ora92\new_data.dbf' AUTO ← 새로 생성해준 NEW_DATA.DBF 파일에 아카이브 파일이 가지고 있는 백업 데이터를 적용하여 복구작업을 수행합니다. Log Applied. Media Complete Recovery. SQL> alter database open;
	(4) 백업 파일이 없는 데이터 파일은 새로운 데이터 파일을 생성한 후 아카이브 파일을 적용하면 복구작업을 수행할 수 있습니다. 데이터들이 정상적으로 복구되었는지 확인하십시오. SQL> select count(*) from scott.new_test;

[KrCERT] SQL Injection 대응 방안

2009-07-16T17:38:11Z

※ 참고SITE : http://www.krcert.or.kr/unimDocsDownload.do?fileName1=TR-2008-007-MassSQLinjection.pdf&docNo=TR2008007&docKind=2

SQL Injection 대응 방안

1) 동적 SQL사용 지양

데이터베이스와의 연동 부분에서는 동적 SQL을 더 이상 사용하지 말고 저장 프로시저를 사용해야 한다[1][2]. 지금까지도 많이 사용되고 있는 동적 SQL 완성 방식은 변수의 입력값을 연결시켜 SQL문을 완성(Concatenation of SQL)시키는 형태이므로 공격자의 SQL문 주입이 매우 용이하다. 그러나 저장 프로시저를 통해 데이터베이스 연동을 구현한다면, 이미 프로시저 내부에서 입력값에 대한 자료 형검증이 이루어진다. 또한 해당 프로시저의 내부에서만 영향을 끼치기 때문에 보안 측면에서도 더욱 더 안전하고, 성능이나 유지보수 측면에서도 대단히 효과적이다.

2) 안전한 웹 사이트 설계와 구현

SQL Injection 취약점은 입력값 검증 절차 문제에 기인하므로, 개발단계에서부터 반드시 모든 입력값에 대해 적절한 검증절차를 설계하고 구현해야 한다.

예를 들어 게시판의 이름을 처리해야 하는 페이지가 있다면 게시판 이름에 대한 입력값에 대해 다음의 예시와 같이 검증 할 수 있다. 간략히 검증과정을 요약하면, 입력값의 크기를 검사하고 특수문자가 있는 경우 위험하지 않은 문자로 치환한 후 입력값이 허용범위 내에 존재하는지 검사하는 방식이다.

■ 게시판 이름 처리용 검증 함수 예시
입력값을 전달받을 변수를 선언하고 가장 먼저 LenStr함수를 사용하여 입력값이 10자 이내인지 검증한다.

Dim bbstitle :
bbstitle = (InputFilter(ReplaceChar(LenStr(Request.QueryString("title"),10)))

■ 특수문자 치환 함수 예시

입력값에 부적절한 특수문자가 있는지 검사하여 서버나 브라우저에서 실행되지 않는 안전한 코드로 치환한다. 예를 들어 작은따옴표(') 나 부등호(<,>)를 입력 하더라도 HTML에서 표현가능한 문자 코드로 치환되므로 서버나 브라우저에서는 프로그램의 일부로써 실행되지 않고 화면에 표시만 한다. 그러므로 정상적인 접속자의 입장에서는 웹 브라우저에서 동일하게 나타내 주기 때문에 불편함이 없다.(http://www.w3.org/TR/html4/charset.html#h-5.3.2)

Function ReplaceChar(str)
ReplaceChar = ""
If str <> "" Then
str = replace(str, "<", "<")
str = replace(str, ">", ">")
str = replace(str, """, """)
str = replace(str, "|", "|")
str = replace(str, "$", "$")
str = replace(str, "%", "%")
str = replace(str, "'", "'")
str = replace(str, "/", "/")
str = replace(str, "(", "(")
str = replace(str, ")", ")")
str = replace(str, ",", ",")
End If
ReplaceChar = str
End Function

■ 허용 범위 검증 함수 예시

입력값이 적절한 허용 범위에 속하는지 확인하는 함수이다. 허용할 범위만 정의하여 그 외의 입력값은 모두 예외처리 하는 구조이므로 공격 패턴의 변화에 의존적이지 않다.

Function InputFilter(str) ' 정수, 알파벳, &, #, ; 만 허용
Dim i, ret
ret = TRUE
For i = 1 To Len(str)
If Not((Asc(Mid(str, i, 1)) >= 48 And Asc(Mid(str, i, 1)) <= 57) Or
(Asc(Mid(str, i, 1)) >= 65 And Asc(Mid(str, i, 1)) <= 90) Or
(Asc(Mid(str, i,1)) >= 97 And Asc(Mid(str, i, 1)) <= 122) Or
Asc(Mid(str, i, 1)=35 Or Asc(Mid(str, i, 1)) = 38 Or Asc(Mid(str, i, 1)) = 59) Then
ret = FALSE
End If
Next
If ret = TRUE Then titlecheck = str
Else titlecheck = 0
Response.Write ""
Response.End
End If
End Function

만약 이러한 허용범위 명시방식 또는 White List로 검증하는 Positive Filtering 방식으로 검증하지 않고, 거부나 차단 대상을 나열하는 허용불가 명시방식 또는 Black List로 검증하는 Negative Filtering 방식으로 구현 한다면 지속적으로 거부할 대상을 일일이 추가 해 주어야 하는 어려움이 발생한다.

그러므로 반드시 허용할 대상을 명시하고 그 이외의 경우는 예외처리를 해야 시간이나 비용면에서도 훨씬 효과적이다.

3) 웹 서버 보안 강화

SQL Injection에 대한 근본적인 문제 해결을 위해서는 프로그램 보완 조치가 반드시 필요하지만, 웹 서버의 보안 강화 설정을 통해서도 보완적인 효과를 볼 수 있다.

■ 자세한 오류 내용 표시 차단
IIS 웹 서버에서는 기본적으로 웹 서비스의 오류가 발생 할 때, 자세한 오류 메시지를 접속자에게 표시하게 되어 있다. 그러므로 이 설정을 변경하여 공격자가 오류 메시지를 통해 유용한 정보를 수집할 수 없도록 수정해야 한다.

일반적인 SQL Injection 공격의 경우 오류 메시지를 기반으로 정보를 추출하게 되므로, 이 설정 변경만으로도 방어효과를 볼 수 있다. 다만, Blindfolded SQL Injection[1]이나 시스템 명령어를 수행하는 SQL Injection공격은 차단할 수 없으므로 반드시 프로그램 수정의 보완조치로 활용해야 한다.

■ SQL 서버 보안 강화
웹 페이지와 MS-SQL 서버를 연동 할 때, 데이터베이스의 관리자 계정인 SA 계정을 사용하게 되면 공격자가 악용할 수 있으므로 매우 위험하다. 그러므로 반 드시 사용자 계정을 사용하고 최소 권한만을 할당하여 사용해야 한다.

또한, 앞서 분석한 공격 스크립트의 경우 시스템 테이블인 Syscolumns와 Sysobjects의 정보를 이용하고 있으므로, 반드시 필요하지 않은 경우라면 사용자 계정이나 "public"계정에 할당되어 있는 “SELECT” 권한을 제거하는 것이 안전하다.

만약 특정 사용자 계정에 대해서 Sysobjects 및 Syscolumns 시스템 테이블에 대한 "SELECT" 권한을 다시 부여하려면 아래와 같이 실행하면 된다.

use <사용자데이터베스명>
go
GRANT SELECT ON sysobjects TO userid
GRANT SELECT ON syscolumns TO userid
go

위의 명령을 실행하면 "userid"라는 사용자계정에 대해서 Sysobjects 및 Syscolumns 테이블에 대한 "SELECT" 권한을 제한하게 되며, 해당 사용자계정에서 Sysobjects나 Syscolumns 시스템 테이블 조회 시 다음과 같은 오류와 함께 실패하게 된다.

[오류메시지]
서버: 메시지 229, 수준 14, 상태 5, 줄 1
'dbo' 소유자, 'pubs' 데이터베이스, 'sysobjects' 개체에 대한 SELECT 사용 권한이
거부되었습니다.

만약 특정 사용자 계정에 대해서 Sysobjects 및 Syscolumns 시스템 테이블에 대한 “SELECT” 권한을 다시 부여하려면 아래와 같이 실행하면 된다.

use <사용자데이터베스명>
go
GRANT SELECT ON sysobjects TO userid
GRANT SELECT ON syscolumns TO userid
go

4) 웹 방화벽 활용

웹보안 취약점의 근본적인 문제 해결을 위해서는 프로그램의 보완조치가 반드시 필요하다. 하지만 운영 중인 홈페이지에서 프로그램 수정으로 인한 문제들도 검토하여 조치해야 하기 때문에, 그 시간 동안은 웹방화벽이나 부가적인 보완조치들을 통해 시간을 확보 할 수 있다.

예를 들어 윈도우즈의 IIS 환경이라면 URLScan이나 공개웹방화벽 WebKnight[2]를 활용하여 보안수준을 향상시킬 수 있다. 특히 WebKnight의 경우는 KrCERT/CC의 공개웹방화벽 안내 페이지[3]에서 각종 가이드와 표준 정책 및 기술지원도 제공 하고 있다.

참고로 이번 분석에서 언급한, 쿠키에 대한 SQL Injection공격을 차단하기 위해서는 반드시 그림과 같이 해당 기능을 활성화해야 한다.

HTTP 헤더의 특성 상 특수문자가 많이 사용 되므로, 차단 설정 후에는 일정기간 동안 로그 모니터링을 통해 서비스에 문제가 없는지 확인해야 한다.

하지만, 어디까지나 웹 방화벽은 보완 장치로 활용해야 하며, 프로그램 수정조치 등의 근본적인 원인 제거가 반드시 수행되어야 한다. 예를 들어 전쟁에 나간 병사가 아무리 튼튼한 갑옷을 입었더라도 건강하지 않거나 기본 체력이 충분치 않다면 결국 그 갑옷조차 무용지물이 될 것이다.

5) 웹보안 취약점 점검

설계와 구현에 있어서 안전한 개발 절차에 따라 개발되었더라도 존재할 수 있는 보안 문제들을 점검하고 진단하는 과정이 필요하다.

특히 SQL Injection의 경우는 프로그램 소스 상에서 입력값 검증이 적절히 이루어졌는지 점검(White box test) 해 보고 웹 취약점 점검 도구를 병행하여 점검(Black box test)해 본다면 더욱 더 안전한 웹 서비스 운영이 될 것이다.

예를 들어 마이크로소프트에서 제공하는 소스코드 검사 도구인 Microsoft Source Code Analyzer for SQL Injection[1]을 활용하거나, 윈도우즈 내장 명령어인 "findstr"을 통해 외부로부터 입력 받는 데이터가 검증 함수를 거치는 지 확인해 볼 필요가 있다.

아래의 점검 예제는 "findstr" 명령어를 사용하여 입력값을 받는 프로그램 소스부분을 검사하는 예제이다. 아래의 예시대로 검사하면 입력값 검증 함수를 동일 행에서 처리 하지 않는 경우를 찾아 볼 수 있다.

findstr /I /S /G [request객체목록] *.asp | findstr /I /V "[입력값검증함수명]"
예) findstr /I /S /G arglist.txt *.asp | findstr /I /V "inputfilter\("

arglist.txt

request.form
request.QueryString
request.ServerVariables
request.Cookies
request\(

그리고 웹 취약점 점검 도구를 사용해서 진단해 볼 수도 있는데, 웹보안 점검 도구는 sectools.org나 NIST 홈페이지 등에서 소개하고 있다. 또한, PAROS, N-Stealth, Scrawlr, Wikto 등의 무료 점검도구들을 활용하여 점검 해 볼 수 있다.

그리고 KrCERT/CC에서 제공하는 원격 웹 취약점 점검 서비스를 이용하면 웹 취약점 원격 점검 서비스를 제공 받을 수 있으며, 점검 신청은 홈페이지(http://webcheck.krcert.or.kr/) 에서 접수 받고 있다. 다만, 비영리단체나 영세기업 등 정보보호취약계층을 대상으로 제공하므로 서비스 대상에 해당 하는 경우에만 서비스 받을 수 있다.

tag : SQL injection

스트리밍 서비스

2009-07-16T15:04:33Z

스트리밍 미디어 서비스

윈도우 2003 서버만 있으면 생각보다 쉽게 스트리밍 서비스를 할 수 있다.

설정 및 원리는 굉장히 간단하다.

스티리잉 미디어 서비스에 대한 구성도를 보면서 어떻게 할 수 있는지 알아보자.

일반적으로 Windows Media Technologies를 기반으로 한 스트리밍 미디어 시스템은

인코더가 실행되는 컴퓨터, Windows Media Server 및 Player로 구성된다.

인코더 [encoder] : 라이브 및 녹화된 오디오, 비디오를 Windows Media 형식으로 변환하는
사용된다.

Windows Media Server [WMS] : 네트워크를 이용해 콘텐츠 배포가 이루어 진다.

Windows Media Player [WMP] : 콘텐트를 받고 실행한다.

일반적으로 사용자는 웹 페이지의 링크를 클릭하여 콘텐츠를 요청하며 웹 서버는 그 요청을

WMS 리다렉션하고 사용자는 컴퓨터에서 플레이어를 실행한다.

이 때에 웹서버가 스트리밍 미디어 프로세스에서 역할에 빠지며 WMS가 직접 유저 Player에게
콘텐트를 서비스 즉 스트리밍 한다.

[출처] 스트리밍 서비스|작성자 베리우스

러브하우스

통영케이블카

[퍼옴]가을을 담은 여행 찰칵! 순천만

오라클에서 자동증가칼럼(Sequence) 사용하기

오라클 전체 테이블 목록 조회하는 쿼리

오라클에서 테이블 목록 보기

ASP LoadPicture 이미지사이즈

디지털아카이빙시스템

성능향상을 위한 asp 프로그램 tips 과 정보들

동영상변환시간

오라클 백업 및 복구

1장 오라클 서버의 구조와 백업/복구원리

2장 오라클 DB의 논리적/물리적 구조의 이해

3장 노-아카이브와 아카이브 모드

4장 OFF-Line 백업을 이용한 완전복구

5장 OFF-Line 백업을 이용한 불완전 복구

6장 ON-Line 백업을 이용한 장애복구

[KrCERT] SQL Injection 대응 방안

스트리밍 서비스