웹 개발과 관련된 모든 것들

제품별로 등록해야지만 업데이트가 실시됨 !

운영 하는 시스템의 날짜 정보를 변경하여도 오라클의 SYSDATE 값은 변경되지 않습니다.

그 이유는 동적으로 초기화되는 FIXED_DATE를 사용하기 때문입니다.

1. SYSDATE 값을 2009년 11월 18일 오후 3시로 반환하고 싶다면

ALTER SYSTEM SET fixed_date='2009-11-18-15:00:00';

2. 원래되로 반환하고 싶다면

10g R2 이상 버전 이라면

ALTER SYSTEM RESET fixed_date = NONE;

10g R2 미만이라면

ALTER SYSTEM SET fixed_daet SCOPE=SPFILE SID='*';

Settings were not able to be saved successfully.

설정 저장을 누르면 위와 같이 오류가 발생하며 저장이 성공적이지 않다는

오류 메시지를 만나게 된다...

아래와 같이 registery 내용을 수정하면 된다.. (첨부된 파일의 내용)

메모장을 열어 아래의 내용을 복사하고 확장자를 .reg 형태로 저장한다.

Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Internet Explorer\Infodelivery\Restrictions] "NoSearchBox"=dword:00000001

원래되로 돌리고 싶다면

Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Internet Explorer\Infodelivery\Restrictions] "NoSearchBox"=dword:00000000

인터넷을 검색하다가 우연히

핸드폰에 걸린 암호를 걸려주는 프로그램을 찾았다

빙고 ~

1. 시스템 서비스 적용 여부

/etc/inetd.conf

#shell   stream  tcp6    nowait  root    /usr/sbin/rshd         rshd
#login   stream  tcp6    nowait  root    /usr/sbin/rlogind      rlogind

다시실행 1(비추)

ps -ef | grep inetd 나온 PID 값을 kill -9 <PID> 다시 실행

다시실행(환경파일 다시 읽어오기 inetd에 관해)

refresh -s inetd

동작 여부(#은 주석처리됨...)

2. root 계정에서 .rhosts 여부
+ (아무나)

3. /etc/hosts
연결될 IP 정보 존재여부

 

박중수 | 엔커블루 기술본부 대표 컨설턴트

기업에서의 데이터 증가는 기하급수적으로 늘어나고 있으며 그에 따른 데이터베이스 성능도 대용량을 처리할 수 있도록 발전하고 있다. 따라서 데이터베이스 관리자는 예전과 달리 데이터베이스의 운영을 매뉴얼하게 할 수 있는 상태에 직면해 있으며, 자동화된 모니터링 및 Alerts로 안정적인 서비스에 대응할 수 있는 툴을 원하고 있다. 이러한 요구사항을 위한 토드의 GUI 환경에서의 데이터베이스 모니터링 기능을 살펴보자.

데이터베이스 개발에 있어 토드(Toad)를 사용하는 사람들은 일반적으로 “토드는 개발자들을 위한 개발 툴”이란 생각을 많이 한다. 즉 단순히 SQL 문장이나 PL/SQL 문장을 빠르고 쉽게 개발할 수 있고, 데이터베이스 객체의 생성 및 변경 작업을 GUI 환경에서 간단하게 수행하며 소스코드 상의 문제점들을 자동으로 찾아주고, 디버깅 기능을 통해 개발자들의 수고를 덜어 줄 수 있는 툴 정도로만 인식하고 있는 것이다. 하지만 토드를 좀 더 세밀하게 들여다보면 개발자만을 위한 툴이 아닌 데이터베이스를 관리(management)하는 DBA(Database Administrator)가 사용할 수 있는 다양한 기능들이 숨겨져 있다. 이 글에서는 토드에 숨겨진 유용한 기능에 대해 소개하고자 한다.

DBA의 역할은 무엇일까?

DBA는 현재 운영되고 있는 시스템, 데이터베이스, 애플리케이션, 네트워크, 서비스 등의 다양한 환경을 구성하고 설치, 보안, 운영 및 설계나 개발 단계에 직, 간접적으로 참여해 전체 구성이 원활하게 유지되도록 하는 업무를 담당하고 있다.
이러한 업무를 수행하다 보면 원하는 서비스가 제대로 동작하지 못하고 특정 부분에 대한 장애가 발생하거나 알 수 없는 그 무엇인가에 의해 성능이 원하는 만큼 나오지 않을 경우도 있다. 특히 DBA에게 내·외적 요소에 의한 뜻하지 않는 돌발상황으로 인해 소비되는 시간이나 노력은 가장 큰 부담이다. 이럴 경우 DBA는 누군가가 현재의 시스템이나 데이터베이스의 부하 없이 효율적으로 문제점을 찾아내어 원인 파악을 해주고 문제점을 해결할 방법을 제시해 준다면 하늘로 날아갈 것 같은 기분을 느낄 것이다.
실제 DBA들은 이로 인해 발생하는 비용을 최소화하기 위해 툴을 사용한다. 하지만 문제점을 감지하는 툴, 문제점을 분석하는 툴, 문제점을 해결하는 툴에 이르기까지 다양한 툴 도입에 따라 발생하는 비용 부담과 함께 툴을 효과적으로 사용하고 있는가를 생각해보면 힘이 빠질 수밖에 없다.
이 글에서는 툴을 효과적으로 사용할 수 있는 정보를 제공하기 위해 가장 널리 사용되는 토드라는 데이터베이스 개발 툴을 선택했다. 특히 토드는 개발 툴 위주로 개발이 됐지만 ‘DBA 모듈’이라는 옵션 기능이 있어 토드 하나만 갖고도 데이터베이스를 최적의 상태로 유지할 수 있는 기능이 있다. 물론 전문적으로 감지·분석·해결에 초점을 맞춘 방대한 툴과의 비교는 어렵겠지만 그래도 적은 비용으로 문제를 해결할 수 있는 솔루션이 있다면 좋지 않겠는가.

DB의 문제점을 발견하라!

토드를 구입했다고 해서 DBA 기능을 전부 사용할 수 있는 것은 아니다(‘토드 DBA 모듈’은 옵션 제품이다). 제품을 구입할 당시에 DBA 모듈이라는 제품을 추가적으로 구입해야 사용이 가능하다. 하지만 개발 위주의 작업이 아닌 전사적인 방법으로 토드를 사용할 것이라면 추천할 만한 사항이라고 생각한다. 그러면 자신이 사용하고 있는 토드를 갖고 이 DBA 기능을 어떻게 사용할 수 있을까?
확인할 수 있는 가장 간단한 방법은 토드의 메인 메뉴 중에서 DBA 메뉴를 클릭해 보면 그 아래 리스트가 길게 나와 있느냐 짧게 나와 있느냐에 따라 확인할 수 있다. <화면 1>처럼 길게 리스트가 나온다면 DBA의 기능을 최적의 상태에서 사용할 수 있다는 뜻이다. 그럼 토드의 DBA 기능을 Detect, Diagnostic, Resolve라는 3개의 단계에 초점을 맞추어 살펴보자.

<화면 1> DBA 메뉴


데이터베이스에 문제가 발생하면 DBA는 일단 원인부터 파악한다. 하지만 어느 부분이 문제가 있는지를 감지하기란 사막에서 모래알을 찾는 것만큼 어려운 일이다. 토드에서 지원하고 있는 DBA 기능 중에서 데이터베이스 모니터(Database Monitor), 헬쓰 체크(Health Check), 인스턴스 매니저(Instance Manager)를 통해 현재의 데이터베이스 상태를 감지할 수 있다.

데이터베이스 모니터

우선 데이터베이스 운영자는 데이터베이스의 성능을 높이기 위해 물리적인 I/O의 병목현상을 제거함으로써 시스템의 메모리와 CPU 자원의 경합을 줄이며 안정적인 서비스를 제공할 수 있다. 그리고 데이터베이스 운영자는 각 세션들에서 발생되는 Wait Event(네트워크 통신이나 I/O 요청 또는 데이터베이스의 특정 자원을 여러 프로세스가 동시에 액세스할 때 발생하는 경합에 의한 대기)의 원인을 제거함으로써 원활한 응답속도를 유지해야 한다.
데이터베이스 모니터 기능은 데이터베이스의 Data Dictionary (V$SYSSTAT, V$SYSTEM_EVENT)를 이용해 메모리, I/O, Latch, 세션 그룹으로 나눠 관련 정보를 추출해 <화면 2>와 같이 9가지 그룹으로 사용자가 Refresh Rate(Interval)를 적용해 주어진 시간에 따라 변화되는 모습을 한 화면에서 볼 수 있다. 이에 성능과 관련된 문제점을 쉽게 파악할 수 있으며, 성능에 지장을 초래한 SQL의 진단 또는 초기 파라미터를 조정할 수 있다.

<화면 2> 데이터베이스 모니터

◆ 데이터베이스 모니터의 주요 기능
① Auto Refresh 설정 기능
② Refresh Rate 설정 기능
③ Alerts에 대한 Propagation 기능
④ 데이터베이스의 Data Dictionary(V$) 정보 그래픽 디스플레이 기능

이터베이스 모니터의 그래프 정보
① Logical I/O : 논리적인 I/O는 SGA(메모리)에 존재하는 데이터베이스 블럭의 Change, Current, Consistent Read들에 대한 통계 추이의 정보
② Physical I/O : 물리적인 I/O는 데이터파일(디스크)의 해당 블럭을 읽어 SGA(메모리)로 올리거나 또는 메모리에서 변경된 블럭을 데이터파일(디스크)로 작성, 그리고 LGWR에 의해서 온라인 리두(redo) 로그 파일로 작성되는 통계 추이의 정보
③ Event Wait : 데이터베이스는 시스템 또는 세션별로 발생하는 Wait 이벤트 통계 정보를 누적해 기록하는데 풀 스캔(Full Scan)시 I/O를 요청하고 대기하는 ‘Mulit-block Read’, 인덱스 스캔시 I/O를 요청하고 대기하는 ‘Single-block Read’, 테이블 스캔시 버퍼 캐시를 거치지 않는 ‘Direct Patch Read’ 등의 통계 추이의 정보
④ Sessions : Sessions는 데이터베이스에 접속한 모든 세션들을 활동 세션(active), 백그라운드 세션(system), 아이들(Idle) 세션으로 분류해 표현한 정보
⑤ all Rates : 사용자가 요청한 SQL에 대한 구문 분석(parse), 실행(execute), 변경 정보 영구저장(commit), 변경 정보 취소(rollback) 정보
⑥ Miss Rates : 데이터베이스의 대표적인 성능 지표인 버퍼 캐시(Buffer Cache) 미스율, 라이브러리/딕셔너리 미스율(SQL Area), 래치 미스율(Latch)의 정보
⑦ SGA Memory Usage : SGA에 할당된 메모리의 사용률에 대한 정보(Shared Pool, 버퍼 캐스, 로그 버퍼)
⑧ Shared Pool : SGA에 할당된 메모리 중 SQL에 대한 공유 메모리의 Detail 사용률에 대한 정보(라이브러리 캐시, 딕셔너리 캐시, Misc Area 등)
⑨ Index Query % : 데이터베이스에서 사용된 SQL 중 쿼리에 대해 인덱스 사용(Indexed %)과 미사용(Non-Indexed %)에 대한 정보

데이터베이스 모니터의 Alert
그렇다면 DBA는 현재 데이터베이스가 문제점이 있는지의 여부를 판단하기 위해 항상 데이터베이스 모니터링 툴을 보고만 있어야 하는가? 그렇다면 진정한 탐지 툴(Detection Tool)이라고 할 수가 없을 것이다. 이를 위해 Alert 기능을 제공한다. 토드 옵션의 데이터베이스 모니터를 찾아보면 모니터링하고자 하는 앞의 9가지 항목들에 대해 임계치(Thresholds)를 설정해 해당 임계치에 도달하면 Alert를 DBA에게 보여줄 수 있도록 지정할 수도 있다. 그러면 토드가 설치되어 있는 PC의 맨 아래에 Toad Database Monitor라는 아이콘이 나타나서 DBA에게 신호를 보내준다.

헬쓰 체크

데이터베이스 구축 후 시간이 지남에 따라 데이터의 크기는 현저하게 증가하게 되고 또한 다양한 문제점들이 나타나게 되는데, 인스턴스에서 발생하는 문제점들을 DBA가 찾아서 조치하기에는 시간과 비용이 만만치 않다. 이에 DBA는 C 검사를 원하는 항목(SGA, Analyze, Extent, JOB……)들에 대해 조건을 설정한다. 해당 조건을 만족하는 내용에 대해 자동으로 체크해 결과를 보여준다면 DBA의 역할은 그만큼 줄어들 것이며, 이를 통해 데이터베이스에 지장을 초래할 수 있는 원인들을 미연에 방지할 수 있다.

◆ 헬쓰 체크의 주요 기능
① 전체의 아이템을 수행하거나 특정한 아이템만 선택해 체크할 수 있다.
② 분석 결과에 대한 리포트
③ SGA 사용 내역
④ Unanalyzed Segments(테이블, 인덱스, 파티션 테이블/인덱스)
⑤ 100개가 넘는 Extent를 소유한 세그먼트
⑥ JOB의 Broken, Sysdate보다 이전의 JOB, Long running JOB 등

<화면 3>은 토드의 헬쓰 체크 기능을 수행한 화면이다. 여기에는 Checks and Options, Other Settings, Report Output 등 3가지 탭으로 구성되어 있는데, Check and Options 탭에서 이미 지정되어 있는 다양한 인스턴스 체크 사항 중에서 원하는 항목을 지정하고 그에 따른 값을 입력하고 실행하면 Report Output 탭에 Health Check를 수행한 결과를 보여준다.

<화면 3> 데이터베이스 헬쓰 체크

인스턴스 매니저

이 기능은 현재 동작 중인 데이터베이스의 인스턴스에 커넥션을 자동으로 수행해 Startup 상태인지 Shutdown 상태인지를 체크할 수 있으며, 토드에서 직접 Startup/Shutdown 명령을 수행하거나 Init 파라미터 파일을 빌딩(building)할 수도 있다.

<화면 4> 인스턴스 메니저

DB의 문제점을 분석하라!

데이터베이스의 문제점을 파악했으면 과연 이 문제점의 원인은 무엇이며, 현재 데이터베이스 성능에서 병목현상(Bottleneck)이 발생하는 영역은 어디인지에 대해 자세하게 분석해야 한다.
분석 작업은 시작해야 하는 포인트가 중요하다. 예를 들어, 오라클 데이터베이스에서 현재 심각하게 성능이 다운되는 현상이 발생하고 있다면 과연 이 문제가 메모리 쪽인지, I/O 쪽인지, I/O라면 데이터파일인지 리두 로그 파일인지를 파악해야 한다. 메모리라면 Shared Pool인지 데이터베이스 버퍼 캐시인지 리두 로그인지 판단해야 한다. DBA 입장에서 특정 문제점이 발생한 영역을 알 수 있다면 그 부분을 집중적으로 분석해 문제점을 해결해야 하는데, 토드는 이러한 분석을 쉽게 할 수 있는 다양한 기능들을 갖고 있다.

Database Probe

데이터베이스의 구성은 크게 메모리(SGA), 프로세스, 데이터파일(Online Redo Logfile, User Datafile)로 구성되며 서버 프로세스와 백그라운드 프로세스에 의해 자동적으로 운영된다. Database Probe는 <화면 5>와 같이 3개의 그룹으로 나뉘어 각 그룹별로 중요한 정보를 보여주게 된다.

<화면 5> Database Probe


먼저 프로세스 부분은 전용 서버 프로세스와 공유 서버 프로세스의 수 및 병렬 처리 내용과 데이터베이스 서버 프로세스가 사용하는 독점 메모리인 PGA 메모리의 사용 현황의 관계를 보여주고 있으며, 메모리(SGA) 부분은 서버 프로세스가 데이터를 처리하는 버퍼 캐시, SQL과 PL/SQL 문장을 저장하기 위한 Shared Pool, 공유 서버의 세션 정보를 저장하는 Large Pool, 데이터 블럭의 변경된 정보(Before/After)를 저장하는 리두 로그 버퍼, 자바 프로그램을 이용하는 영역의 Java Pool의 사용률을 보여주며, 마지막으로 데이터파일 부분은 파일의 크기와 현재까지의 사용률을 그래픽하게 처리하고 있어 데이터베이스의 전반적인 리소스를 얼마나 사용하고 있는지를 시각적으로 판단해 데이터베이스의 초기 파라미터 및 데이터파일의 크기 또는 리두 로그 파일의 크기 및 개수 등을 조정하는 데 필요한 정보를 제공한다.

◆ Database Probe의 주요 기능
① SGA 각 영역의 Hit Ratio 및 사용률 및 Wait/Retry 정보
② 전용 서버 프로세스 및 공유 서버 프로세스의 수 및 PGA 정보
③ 데이터파일의 전체 크기 및 사용률

Top Session Finder
현재 시스템에서 특정 리소스를 많이 사용하는 오라클 세션들을 발췌해 탑 리스트(Top List)로 보여준다. 앞의 Database Probe를 이용해 현재 데이터베이스 측면을 분석했으면, 그 내부에서 작업 중인 세션들에 대한 자세한 정보를 분석해야 할 것이다. 하지만 그 많은 세션들을 일일이 분석하기란 여간 힘든 일이 아니다. 그 중에서 시스템의 리소스를 많이 사용하는 세션이 문제점을 갖고 있기 때문에, 그에 따른 이벤트 정보를 토대로 탑 세션을 발췌한다. 예를 들어 CPU를 많이 사용하는 탑 세션, I/O를 많이 발생시키는 탑 세션처럼 DBA가 원하는 시스템 리소스 측면을 강조한 기능이라고 할 수 있다. <화면 6>에서는 세션들 중에서 ‘session logical reads’, 즉 논리적인 읽기가 큰 세션부터 내림차순으로 정렬된 정보를 Dataset 형태로 제공하고 있다.

<화면 6> Top Session Finder

◆ Top Session Finder의 주요 기능
① CPU, 메모리, 커서(CURSORS) 등과 같은 자원 그룹별로 문제 세션을 검색
② 데이터베이스 세션 정보의 결과를 Dataset 형태나 Pie Chart 형식으로 제공

세션 브라우저
세션 브라우저 기능은 데이터베이스에 접속 중인 모든 세션들에 대해 총괄적으로 세션 액티비티(Session Activity)를 분석하기 위해 제공된 기능이다. <화면 7>은 특정 세션의 Wait Event에 대한 상세 정보를 ‘Current Waits’와 ‘Total Waits’로 분리해 제공하고 있다. 특정 세션을 선택하면 다음과 같은 상세정보를 동적으로 추출할 수 있다.

<화면 7> 세션브라우저

- 세션 : 선택한 세션의 ID, 프로그램, 모듈, Machine, OS 유저, DB 유저 등의 정보를 제공
- 프로세스 : 선택한 세션의 프로세스 정보 제공
- I/O : 선택한 세션이 발생시킨 I/O 정보인 읽기/쓰기 정보 제공
- Waits : 선택한 세션에서 발생한 Wait Event 정보 제공
- Current Statement : 선택한 세션에서 수행 중인 SQL 문장 정보 제공
- Open Cursors : 선택한 세션이 오픈한 커서 정보 제공
- Access : 선택한 세션이 액세스한 객체 정보 제공
- Locks : 세션 잠금 정보 제공
- RBS Usage : 선택한 세션이 사용한 롤백 세그먼트(Rollback Segment) 정보 제공
- Long Ops : 선택한 세션이 배치(Batch)성 작업을 수행했을 경우 현재까지 진행된 상황에 대한 정보 제공
- Statistics : 선택한 세션에 대한 통계 정보 제공

OS 유틸리티
이 기능은 데이터베이스 측면이 아닌 데이터베이스가 동작 중인 시스템(OS) 부분의 정보를 분석하고자 할 경우 사용한다. 유닉스나 윈도우 계열의 OS를 사용할 경우 또는 해당 OS에 해당되는 정보를 분석하고자 할 경우 유용하게 사용할 수 있다. <화면 8>은 CPU의 사용률을 시스템, 사용자를 구분해 사용되고 있는 정보와 프로세스 정보 및 디스크 I/O에 대한 정보를 그래프로 제공하고 있어, 시스템의 전반적인 자원 사용율을 나타내고 있다.

<화면 8> OS 유틸리티 메뉴


<화면 9> 유닉스 모니터

DB상의 문제점을 어떻게 해결할 것인가?

데이터베이스의 문제점을 감지(detect)하고 분석(diagnostic)했으면, 그에 따른 행동을 취해야 한다. 일반적으로 제시하는 해결방안은 시스템 튜닝, 데이터베이스 튜닝, 애플리케이션 튜닝, SQL Statement 튜닝으로 구분할 수 있는 데, 토드에서는 문제점을 해결하기 위한 다양한 기능이 존재한다.

테이블 스페이스와 테이블 스페이스 맵

이는 데이터베이스의 논리적 구조를 이루는 가장 핵심적인 요소이다. 데이터베이스의 데이터가 존재하는 물리적인 데이터파일과 연결되어 있으며, 그 안에 세그먼트, 익스턴트(Extent), 블럭이라는 구조가 존재하고 있다. 만약 테이블 스페이스의 공간이 부족하거나, 데이터파일에 Fragmentation이 발생해 장애가 발생한 경우라면 해당 테이블 스페이스의 공간을 늘려주는 작업과 그 안에 존재하는 Fragmentation을 Coalesce하는 작업을 수행해 다시 재구성하는 문제를 생각해야 할 것이다. 또한 이로 인해 I/O Wait가 발생해 성능이 떨어지는 원인이 된다면 해당 데이터파일도 다시 재구성하거나 재구축하는 절차를 수행해야 한다. 이러한 과정을 손쉽게 수행할 수 있도록 하는 기능이 바로 테이블 스페이스 기능이다.
토드에서 테이블 스페이스와 데이터파일에 대한 정보를 변경할 수 있으며, 프리 스페이스(Free Space)와 해당 테이블 스페이스에 존재하는 객체 정보를 확인할 수 있다.
그리고 뒤에 있는 Space History와 I/O History 탭에서는 특정 테이블 스페이스나 데이터파일에 대한 Capacity Plan 정보를 확인할 수 있다. <화면 10>은 데이터베이스의 각 테이블 스페이스에 대해 할당된 크기와 가장 큰 연속된 공간 및 프리 스페이스를 보여주고 있다. 만약에 특정 세그먼트의 크기가 부족해 확장될 때 ‘MAX Mb’의 값보다 크다면 확장하지 못하고 에러가 발생하게 된다. 따라서 DBA는 이러한 정보로 각 테이블 스페이스에 속한 오브젝트 중 MAX 값보다 큰 테이블이나 인덱스가 존재한다면 해당 테이블 스페이스에 데이터파일을 추가한다거나 다음 익스턴트의 크기를 줄이기 위해 테이블과 인덱스의 NEXT 옵션을 변경해야 할 것이다.

<화면 10> 테이블 스페이스 예


또한 특정 테이블 스페이스의 물리적인 구조 중에서 가장 작은 단위인 블럭들을 그래픽하게 보여줘 해당 테이블 스페이스의 객체가 차지하고 있는 블럭의 갯수나 세그먼트 정보를 자세하게 확인할 수도 있으며, 데이터파일에 존재하는 Fragmentation도 분석해 Coalesce 과정을 수행할 수 있는데, 이 기능은 <화면 11>의 테이블 스페이스 맵을 활용해 수행할 수 있다.

<화면 11> 테이블 스페이스 예

　　　　 컨트롤 파일과 리두 로그 매니저
물리적인 데이터베이스 구조인 컨트롤 파일(Control File)과 리두 로그 파일(Redo Log File)에 대한 정보를 확인할 수 있으며, 로그 스위치(Log Switch), 리두 로그 파일 변경 작업, 아카이브 스타트/스톱(Archive Start/Stop)과 같은 특정 작업을 직접 수행할 수 있다. 컨트롤 파일은 데이터베이스의 물리적인 구조에 대한 정보를 저장하고 있으며 각 타입별로 레코드 세션(Record Section)을 사용하게 된다. <화면 12>에서의 컨트롤 파일의 상세내용을 보면 각 세션(“REDO LOG”, “DATAFILE”…)별로 최대 레코드를 갖고, 또한 사용량을 표시하는데, 만약 각 세션의 토탈 레코드들과 사용된 레코드가 동일하게 되면 더 이상 해당 세션에 대한 자원 할당을 할 수 없게 되므로 컨트롤 파일을 재생성해야 된다. 그리고 이러한 정보를 미리 확인해 대처할 수 있다.

<화면 12> 컨트롤 파일 관리


<화면 13> 칸트롤 파일과 리두 로그 매니저

Log Switch Frequency Map
<화면 14>는 하루를 1시간 그룹으로 구분해 각 시간대별로 로그 스위치의 발생 정도를 나타내어 트랜잭션 양을 파악할 수 있으며, 또한 하루 중에 가장 트랜잭션이 많은 시간대를 파악해 그 시간대에 발생할 수 있는 작업(Batch Job) 등을 다른 시간대로 변경해 수행할 수 있도록 하고 있다. Log Switch Frequency Map 기능은 현재 데이터베이스에서 발생하는 로그 스위치의 회수를 체크해 보여준다.

<화면 14> Log Switch Frequency Map


시간대별로 몇 번의 로그 스위치가 발생했는지 파악할 수 있으며 가장 많은 로그 스위치가 발생한 시간이 언제인지를 확인해 DBA로 하여금 로그 파일의 재구성과 리두 로그 버퍼의 크기에 대한 어드바이스를 받을 수 있도록 정보를 제공하고 있으며, 이를 통해 인스턴스에서 체크포인트의 발생 빈도를 예측할 수 있도록 해준다. DBA는 이 정보를 토대로 SGA 메모리의 최적화 상태를 점검할 수 있다.

Rebuild Objects
테이블 스페이스에 대한 문제를 해결하다 보면 그 안에 존재하는 특정 객체에 대해 다시 재구성해야 하는 경우가 발생한다. 테이블 스페이스 레벨에서만 문제가 해결되면 가장 좋겠지만 실제로는 데이터가 존재하는 테이블이나 인덱스 쪽에 더 무게를 둘 수밖에 없게 된다. 이 기능을 이용해 특정 테이블이나 인덱스 또는 특정 유저, 테이블 스페이스에 해당하는 객체에 대해 일괄적으로 또는 개별적으로 Rebuild 과정을 진행할 수 있다.

　　 Repair Chained Rows
데이터베이스의 block_size가 적거나 특정 테이블의 Row가 데이터베이스 블럭의 크기보다 큰 경우에 UPDATE 문장이 발생하는 테이블에 종종 발생되는 Chaining이나 마이그레이션이 일어나게 되는데, 이렇게 하나의 Row가 여러 블럭에 걸쳐 있으면 데이터베이스의 성능이 떨어지기 마련이다. 이 기능은 데이터베이스의 특정 테이블에서 Chaining이나 마이그레이션이 발생할 경우 해당 테이블을 분석해 Chained Row를 해결하고자 제공하는 기능이다. <화면 15>는 ‘CHAIN_TEST’ 테이블에 Chain된 Row가 약 3만 건 정도가 발생한 것인데, 화면 오른쪽에 ‘Repair’ 버튼을 누르면 Chained Row를 제거할 수 있게 된다.

<화면 15> Repair Chanined Rows

Export/Import Utility Wizard와 SQL*Loader Wizard
Export/Import Utility Wizard와 SQL*Loader Wizard는 오라클의 Export/Import 명령과 SQL*Loader를 Wizard 를 통해 쉽게 구현할 수 있도록 제공하는 기능이다. Export/Import를 이용해 일반적으로 해당 객체를 재구성하는 과정을 거치게 되는데 GUI 환경에서 누구나 손쉽게 사용할 수 있도록 제공하고 있으며, 테이블, 유저, 테이블 스페이스, 데이터베이스 모드를 모두 지원한다. 또한 SQL*Loader의 모든 기능을 지원해 컨트롤 파일을 구성할 경우 이미 지정되어 있는 많은 옵션들을 간단하게 설정할 수 있다.

Server Statistics
이 기능은 현재 인스턴스에 대해 통계 정보를 분석해 보여주며, 인스턴스 내부에 발생하는 다양한 항목들을 DBA가 확인할 수 있다.
Analysis, Waits, Latched, Session, Instance Summary 등의 5가지 탭을 통해 전체 데이터베이스의 통계 정보를 파악한다. 또한 데이터베이스에서 통계치의 값이 어떠한지에 대해 분석해 DBA에게 제시해 준다. 이를 통해 현재 통계정보의 부정확한 값들에 대한 어드바이스를 제시해 DBA로 하여금 최적의 인스턴스 상태를 유지할 수 있는 방향을 제시한다. DBA는 <화면 16>에서 빨간색으로 표시되어 있는 값들에 대해 체크해 인스턴스 환경을 수정할 수 있다.

<화면 16> Server Statistics, 데이터베이스의 대표적인 성능 지수들의 현재 값


이 외에 토드에서 지원되는 문제를 해결할 수 있는 기능을 보면 다음과 같다.

◆ Oracle Parameter and NLS Parameter : Server Statistics 기능에서 제시한 내용을 기준으로 특정 데이터베이스 파라미터를 수정할 경우, 이 기능을 사용해 쉽게 변경할 수 있다.

◆ New Database Wizard : 이 기능은 새로운 데이터베이스를 생성하기 위해 Create Database 명령을 수행하도록 하는 기능이다. DBA가 새로운 데이터베이스를 생성(create)하고자 할 경우 쉽게 GUI 환경에서 생성할 수 있도록 도와주는 위저드 기능이다.

◆ Compare Schema and Compare Database : 서로 다른 데이터베이스끼리 비교를 하거나 특정 스키마들끼리의 비교처럼 DBA가 특정 작업을 수행하기 이전과 이후에 대한 비교 작업을 수행할 경우 적용한다.

데이터베이스 브라우저 기능이란?

지금까지 DBA 기능에 대해 각 기능별로 소개를 했다. 하지만 DBA가 이 모든 기능들을 일일이 하나씩 확인한다면 이것 또한 너무 불편할 것이다.
이를 위해 토드에서는 데이터베이스 관리를 위해 필요한 내용들을 종합적으로 구성해 하나의 화면에서 확인하고 설정할 수 있도록 통합관리 체제로 관리하고 있다. 이 기능이 바로 데이터베이스 브라우저(Database Browser)이다. <화면 17>처럼 데이터베이스 브라우저는 하나의 데이터베이스를 기준으로 정보를 제공하는 것이 아니라 현재 네트워크 상에 존재하는 모든 데이터베이스를 한눈에 확인할 수 있도록 중앙집중 방식을 선택하고 있다. DBA가 A DB, B DB 등을 분산해 관리한다면 업무 효율성도 떨어질 뿐만 아니라 그로 인해 발생하는 시간과 노력에 대한 비용도 한이 없을 것이다. 데이터베이스 브라우저는 다음의 다양한 탭을 갖고 있다.

<화면 17> 데이터베이스 브라우저

◆ 데이터베이스 브라우저의 다양한 탭
- 오버뷰(Overview) : SGA 크기, Shared Pool의 크기, Hit Ratio, Event Wait 정보 확인
- 인스턴스 : 인스턴스 정보 확인
- 데이터베이스 : 데이터베이스 정보 확인
- Options : 해당 데이터베이스에 설정되어 있는 제품의 옵션 리스트 확인
- 파라미터 : 데이터베이스 파라미터 정보 확인
- 세션 : 현재 데이터베이스에 연결되어 있는 세션 정보 확인
- 탑 세션 : 현재 연결되어 있는 세션 중에서 탑 세션 리스트 확인
- RBS 액티비티 : 롤백 세그먼트의 액티비티 정보 확인
- Space Usage : 각 테이블 스페이스의 스토리지 파라미터 정보와 스페이스 정보 확인
- 데이터파일 I/O : 각 데이터파일의 토탈 사이즈, 프리 사이즈(Free Size)와 내부 블럭마다의 읽기/쓰기 회수 등에 대한 정보 확인

SQL 튜닝 엑스퍼트

SQL 튜닝 엑스퍼트는 토드의 DBA 모듈에 포함되어 있는 기능은 아니며, 토드의 엑스퍼트 튜닝 모듈(Xpert Tuning Module)에 있는 기능이다.
DBA가 시스템 퍼포먼스 튜닝만 수행하는 것이 아니라 그 안에서 동작하는 애플리케이션 튜닝에 더욱 많은 시간을 소비할 것이기 때문에 토드를 이용해 이 부분을 해결할 수 있는 방법을 제시하고자 한다. 데이터베이스를 운영하다 많이 접하게 되는 문제는 바로 잘못 작성된 SQL 문장이 될 것이다. 토드의 엑스퍼트 에디션은 현재 데이터베이스에서 잘못 작성되어 성능이 다운되는 요인이 되고 있는 SQL 문장을 찾아 가장 최적의 SQL 문장으로 바꿔주는 기능을 갖고 있다.
SQL 튜닝 엑스퍼트 기능은 SQL 에디터나 프로시저 에디터(Procedure Editor)에서 SQL 문장이나 PL/SQL 문장을 대상으로 개발시에 최적의 SQL과 PL/SQL을 만들고 싶을 경우이거나, 실행했으나 반응 시간(Response Time)이 너무 높게 나타나서 현재 환경에 맞는 최적의 문장을 만들고 싶을 경우 사용한다. 일단 SQL 에디터와 프로시저 에디터 아이콘 버튼을 실행하면 SQL 튜닝 엑스퍼트라는 화면으로 이동할 수 있다. SQL 튜닝 엑스퍼트 화면의 왼쪽에는 네비게이터 패널(Navigator Panel)이라는 것이 있는데, 이 네비게이터 패널의 순서에 따라 SQL 튜닝 과정을 진행하면 된다. 다음은 SQL 튜닝 엑스퍼트에서 SQL 튜닝 과정을 진행하는 절차이다.

1단계, SQL Detail

여기서는 SQL 에디터나 프로시저 에디터에서 수행 중인 SQL 문장을 드래그해 Execution Plan과 해당 SQL 문장에 나타난 객체의 정보를 확인할 수 있다. Execution Plan을 통해 현재 SQL 문장이 어떻게 수행될 것이지 예측할 수 있으며, 해당 테이블에 생성되어 있는 인덱스나 컬럼의 정보를 확인할 수 있다.

<화면 18> SQL Detail Window

2단계, View Advice

이 부분은 현재의 SQL 문장에 대해 Execution Plan의 정보만 갖고 튜닝 액션을 결정할 수가 없을 경우 개발자나 DBA에게 현재 환경에 적합한 가장 최적의 SQL 솔루션을 제공한다.

<화면 19> View Advice Window

- Auto Tune : 이는 오라클 옵티마이저가 판단한 근거를 기준으로 자동으로 현재 SQL 문장에 맞는 최적의 솔루션 리스트를 제공한다. 이는 튜닝 초보자에게 적합한 것으로 SQL 튜닝에 대한 지식이 없더라도 튜닝 솔루션을 찾을 수 있게 한다.

- Advice : 이는 현재 환경에 적합한 Advice List를 보여줌으로써 어느 정도 숙련된 튜너가 자기가 생각한 튜닝 솔루션과 일치하는 사항을 찾아 수행할 수 있도록 정보를 제공한다.

- Manual Tune : 토드의 SQL 튜닝 엑스퍼트에게 의존하지 않고 직접 SQL 문장을 코딩하는 경우 사용한다.

3단계, Compare Scenario

Advice에서 선택한 사항을 토대로 Original SQL 문장과 Advice SQL 문장의 Explain Plan과 SQL 문장을 기준으로 비교할 수 있도록 정보를 제공한다.

<화면 20> Compare Scenario Window

4단계, Execution Scenario

Compare Scenario 스텝까지는 직접 SQL 문장을 실행하지 않은 상태에서 간접적으로 비교를 수행한 것에 반해 이 부분은 직접 Original SQL 문장과 Advice SQL 문장을 실행해 비교할 수 있는 정보를 제공한다. 만약 Trace 정보를 만들고 싶다면 옵션으로 지정할 수도 있다.
실행 과정이 끝나면 Original SQL과 Advice SQL에 대해 그래픽하게 비교할 수 있는 그림이 나타나며 이를 통해 시각적으로 최적의 솔루션을 찾을 수 있다.

<화면 21> Advice 적용 후 성능 향상 기대치 비교

- Index Advice : 만약 View Advice 단계에서 선택한 Advice가 인덱스를 추가·삭제·변경하는 작업이었다면 이번 단계에서는 인덱스에 대한 DDL 명령을 수행해야 한다. 하지만 이를 적용했을 경우 다른 SQL 문장이 영향을 받을 수 있기 때문에 조심스럽게 접근해야 할 것이다. 따라서 실제로는 실행시에 인덱스에 대한 DDL 명령을 수행하지 않고 버추얼하게 수행해 현재 데이터베이스에 영향을 주지 않는 선에서 비교할 수 있도록 정보를 제공한다.

- Rewrite : View Advice 단계에서 선택한 Advice가 문장을 바꾸는 선에서 제공되고 있다면, 현재 Original SQL문장을 대신할 수 있는 대체 SQL 문장을 선택한 경우이다. 이를 통해 현재 과정을 진행하면 Original SQL과 Advice SQL을 전부 실제로 실행하는 과정을 거치게 된다.

- Other Advice : DDL Advice나 SQL Rewrite가 아닌 다른 내용들을 제시한 것을 선택한 경우가 해당된다.

5단계, Execution Results

실행한 내용을 토대로 그 결과를 보여주며 실행시에 생성된 통계 정보를 비교할 수 있다. 토탈 CPU, Elapsed Time, Logical Read, Physical Read 등의 많은 통계 정보를 서로 비교할 수 있다.

6단계, Best Practice

앞의 Advice에서 선택한 사항을 토대로 실제 실행과정을 거친다. 예를 들어, 인덱스 생성 Advice를 선택했다면 4번 단계에서는 가상적으로 생성해 비교를 수행했는데, 이를 비교 검토 후 적용하는 과정이라고 생각하면 된다. 또한 추가적으로 수행할 때 더 적합한 내용들이 있다면, 예를 들어 분석 작업 같은 내용이 여기에 포함될 수 있는데 최적의 상태가 될 수 있는 리스트를 제시하면 튜너는 여기에서 원하는 내용을 선택할 수 있다.

7단계, Tuning Resolution

지금까지 진행해온 모든 사항을 기본으로 해 Original SQL과 Advice SQL에 대해 어느 정도 성능 효과를 보였는지를 확인할 수 있다.

토드의 다양한 기능을 습득하기 바라며

지금까지 토드에서 제공하는 DBA 모듈에 대한 일부 기능을 소개했다. 토드라는 툴은 너무나 많은 기능들을 갖고 있기 때문에 사용자의 입장에서 어떤 기능들이 토드에 있는지조차 모르는 경우가 다반사라고 생각한다. 이렇게 토드에는 숨겨진 많은 기능들이 독자의 업무에 도움이 될 수 있으면 하는 바람이다.

제공 : DB포탈사이트 DBguide.net

공략 포인트

 

앞의 두 과목을 무사히 통과했다면 이제 기본은 완성되었으므로 약간 긴장을 늦추고 공부 해도 좋다. 네트워크 과목은 좀 다르지만 백업과 복구, 퍼포먼스 튜닝은 기존의 지식을 바탕으로 풀어가는 것이므로 수험자의 체감 부담이 적다.

 

DBA의 가장 중요한 업무에 대해서 설문 조사를 한다면 십 중 팔구 백업이 일순위로 꼽힐 것이다. DBA의 책임 영역은 데이터를 안전하게 보호하고 데이터를 필요로 하는 사람에게 원활한 공급이 이루어 지도록 하는 것이다. 따라서 데이터를 손실 위험으로부터 지키기 위하여 백업을 받고 매끄러운 공급을 위해서 크고 작은 관리작업과 튜닝을 수행한다.

 

백업을 제외한 다른 업무는 제대로 수행하지 못했더라도 얼마든지 만회할 기회가 있다. 데이터베이스의 구조가 잘못 되었다면 추석 연휴를 반납하고라도 뜯어 고치면 되고 기대 이하의 성능에는 다소의 예산을 투입해서 튜닝 진단을 받으면 된다. 또한 디스크가 엉망으로 얽혀버렸는데 복구에 익숙치 않다면 오라클에서 지원을 받을 수도 있다. 데이터베이스가 다운된 후 복구 되기 까지 걸리는 평균 시간(Mean Time To Recovery)이 DBA의 평가 요소에서 큰 부분을 차지하므로 이렇게 자꾸 외부의 힘을 빌리는 것은 곤란하지만 자신의 능력을 넘어서는 일에 대해서는 지체 없이 도움을 받는 것이 현명한 선택일 것이다.

 

그러나 백업은 절대적으로 DBA의 몫이다. 백업 플랜을 작성하고 계획한 절차대로 수행하는 것은 어려운 일이 아니지만 여기서 실수가 발생하면 DBA로서의 자질과 성실성에 큰 손상을 입는다. 또한 백업이 잘못되면 장애 발생시 입게 되는 시간적 금전적 피해 규모는 비교할 상대가 없다.

 

백업은 생명보험과도 같다. 백업을 위해서 들이는 시간과 비싼 저장 장치가 아깝게 느껴지겠지만 만약의 사태가 발생했을 때 믿을 것은 백업밖에 없는 것이다. 백업만 제대로 받아 두면 복구는 시간문제지만 제대로 된 백업이 없을 때에는 별의 별 편법을 동원하여 복구를 해야 할 경우도 생기고 그나마 복구를 하더라도 데이터베이스는 만신창이가 되기도 한다.

 

본 과목은 오라클 아키텍쳐를 충실히 이해하고 있다면 별 어려움을 느끼지 않을 것이다. 다만 지금까지 쌓아온 지식을 보강하고 RMAN 유틸리티의 사용법을 익히는 것으로 훌륭한 준비가 될 것으로 믿는다. 문제 분포를 보면 개별 단원으로는 물리적 백업에 관한 문제가 8문제로 가장 많지만 RMAN과 관련된 부분에서 그보다 두 배 이상이 출제되므로 합격을 결정 짓는 다크호스다. 강좌 초반에 다루는 개념적인 부분과 아카이브에 대한 기본적인 이해도를 묻는 문제도 그에 못지않은 비중을 차지한다. 그리고 가장 마지막에 다룰 스탠바이 데이터베이스에서도 5문제가 나오므로 끝가지 최선을 다해주기 바란다.

 

데이터 복구를 위한 오라클 구조

 

1-1. 데이터베이스를 사용하던 중 실수로 전원 스위치를 내려버렸다. 이와 같은 경우는 어떤 유형의 장애에 해당되는가?

 

a. User Error

b. Statement Error

c. Process Failure

d. Instance Failure

e. Media Failure

 

 

<해설>

 

모든 학문의 시작은 사물과 현상을 분류하는 것에서 비롯되듯이 데이터베이스와 관련된 장애도 성격에 따라서 보기와 같은 다섯 가지로 구분 지을 수 있다.

 

User Error는 유저가 실수로 데이터를 삭제한 것과 같은 경우를 말하는데 이 때에는 백업을 이용해서 원상태로 복구를 시켜주면 되고 만약 백업 받은 것이 없다면 복구를 할 수 없다는 간단한 논리의 적용이 가능하므로 문제 파악이 쉽다.

 

Statement Error는 SQL문을 잘못 작성하였거나 미들웨어와 오라클간의 호환성 결여 로 인한 문제 등을 가리킨다. 예를 들어 TP 모니터와 오라클의 버전이 맞지 않아서 발생하는 까다롭고 미묘한 문제들을 떠올려 볼 수 있다.

 

Process Failure는 유저 프로세스가 비정상적으로 종료된 경우로 유저가 고의로 직접 중단시켰거나 또는 네트워크 회선의 불량으로 접속이 단절된 경우 등이 해당된다.

 

Instance Failure는 정전이나 오라클 백그라운드 프로세스의 정지 등으로 오라클 인스턴스가 다운되는 것을 말하며 본 문제가 여기에 속한다. Instance Failure가 발생하면 다음에 인스턴스를 기동할 때 오라클이 자동으로 복구를 수행하기 때문에 DBA가 직접 관여할 문제는 아니다.

 

Media Failure는 데이터파일과 같이 오라클 데이터베이스를 구성하고 있는 파일이 삭제되거나 손상된 경우를 말하며 심각한 복구 문제는 모두 이 카테고리에서 발생하므로 앞으로 우리가 중점적으로 다룰 분야이다.

 

정답 : (d) (<- 마우스로 정답 부분을 선택하세요)

 

 

1-2. 유저가 실수로 중요한 테이블을 삭제하였다. 다행히 아카이브 모드로 운영중이었는데 어떤 복구 방법을 선택해야 삭제된 테이블을 되살릴 수 있는가?

 

a. Complete Recovery

b. Incomplete Recovery

 

 

<해설>

 

완전 복구(Complete Recovery)는 보관중인 백업을 리스토어 한 다음에 백업 이후에 생성된 모든 리두 로그 파일을 적용하는 복구 방법을 말한다. 모든 리두 로그 파일의 정보를 사용하므로 가장 최신의 상태로 복구가 되지만 본 문제에서는 완전 복구를 수행하면 다시 테이블이 삭제된 상태가 되어버리므로 복구하는 의미가 없다.

 

이런 때에는 데이터베이스를 테이블이 삭제 되기 이전의 시점으로 돌려 놓아야 하므로 백업 받은 이후에 생성된 모든 리두 로그 파일을 적용해선 안 되고 복구를 하던 중간에 작업을 중단하고 데이터베이스를 오픈 시켜야 하는데 이를 일컬어 불완전 복구(Incomplete Recovery)라고 부른다.

 

백업 계획을 수립한 다음에는 반드시 백업 받은 것을 이용해서 복구가 제대로 되는지 테스트 해 보아야 한다.

 

오래 전에 운영 체제를 업그레이드하는 사이트로부터 백업을 어떻게 받아야 하는지를 문의 받은 적이 있었다. 필자는 관리자의 시간을 벌어준답시고 익스포트와 임포트 보다는 간편한 콜드 백업을 받으라고 조언해 주었다.

 

그런데 결국 다음날 일이 터지고 말았다. 운영 체제를 업그레이드 하는 것은 맞기는 한데 단순한 버전 업이 아니라 SunOS에서 Solaris로 전환하는 것이었기 때문에 두 운영 체제 사이의 이진 호환성이 없는 관계로 콜드 백업이 무용지물이 되고 만 것이다. 운영 체제가 다르더라도 익스포트 받은 덤프 파일은 임포트 유틸리티에서 읽을 수 있지만 데이터 파일은 플랫폼간의 호환성이 없기 때문이다.

 

결국 SunOS 재설치 -> 오라클 인스톨 -> 백업 리스토어 -> 익스포트 -> Solaris 재설치 -> 오라클 인스톨 -> 임포트와 같은 과정을 거쳐서 겨우 업그레이드 작업을 마칠 수 있었다. 아무리 완벽하게 백업을 받았더라도 예상치 못한 변수가 터지지 않는다고 보장할 수 없으므로 반드시 실전테스트를 거쳐서 검증해 보아야 한다.

 

정답 : (b) (<- 마우스로 정답 부분을 선택하세요)

 

1-3. 불완전 복구의 유형에 해당되는 것을 모두 선택하시오(정답은 세 가지).

 

a. Point-based recovery

b. Time-based recovery

c. Change-based recovery

d. Transaction-based recovery

e. Cancel-based recovery

 

 

<해설>

 

불완전 복구(Incomplete Recovery)는 완전 복구와는 달리 복구하는 중간에 작업을 중단해야 하며 그 시점에 대한 결정은 DBA의 몫이다.

 

Time-based recovery는 데이터베이스를 특정한 시점까지만 복구하는 방법을 말한다. 2번 문제에서처럼 사용자가 테이블을 삭제한 시간을 알고 있다면 테이블이 삭제되기 직전의 시간을 지정하여 복구를 수행하면 되므로 자주 이용되는 방법이다.

 

Change-based recovery는 SCN을 직접 사용해서 복구를 하는 방법이고 Cancel-based recovery는 로그 파일을 하나씩 적용하면서 복구를 진행해 가다가 원하는 위치에서 CANCEL 명령으로 복구를 중단하고 오픈하는 방법을 말한다. 자세한 내용은 차차 다루기로 하겠다.

 

정답 : (b),(c),(e) (<- 마우스로 정답 부분을 선택하세요)

 

Archive vs. Noarchive

 

2-1. 수동 아카이빙(Manual Archiving) 상태에서 데이터베이스를 셧다운하지 않고 아카이브를 받을 수 있는 명령은? (정답은 세 가지)

 

a. ARCHIVE LOG NEXT;

b. ARCHIVE LOG NEW;

c. ALTER SYSTEM ARCHIVE LOG START;

d. ALTER SYSTEM ARCHIVE LOG ALL;

e. ALTER SYSTEM SWITCH LOGFILE;

 

 

<해설>

 

아키이브로그 모드란 온라인 리두 로그 파일이 순환되어 재사용되기 전에 다른 곳으로 백업해 둠으로써 차후에 복구에 사용할 수 있도록 하는 데이터베이스 운영 방식을 말한다. 시스템 환경이 별로 넉넉하지 못했던 시절에는 아카이브로그 모드가 유발하는 프로세서의 부하와 디스크 I/O의 증가 및 여유 공간의 부족, 그리고 관리자의 미숙 등으로 인해서 다양한 장점에도 불구하고 그다지 좋지 않은 인상을 남겨주는 경우가 있었다.

 

24시간 운영을 하는 곳에서는 백업을 받기 위해서 아카이브로그 모드가 필수적인데 디스크가 넉넉하지 않아서 궁여지책으로 테이프로 직접 아카이브를 받는 곳도 있었다. 그러다 보니 트랜잭션이 몰리는 시간에는 아카이브 받는 속도가 발생되는 트랜잭션의 크기를 따라가지 못해서 데이터베이스가 때때로 멈칫거리는 부작용이 발생하기도 하였다.

 

현재는 컴퓨터 시스템의 중요성에 대한 마인드가 많이 개선되었고 하드웨어의 성능 향상과 가격 인하로 소규모 데이터베이스라고 해도 아카이브로그 모드로 운영하지 않을만한 뚜렷한 이유를 찾기 어렵다.

 

아카이브로그 모드로 처음 운영하기 시작하는 사이트에서 가장 자주 일어나는 실수 가운데 하나는 어떤 이유로든 아카이브가 제대로 수행되지 않음으로써 데이터베이스가 모든 동작을 멈추는 것이다. 구체적인 원인으로는 아카이브로그 파일이 저장되는 디스크에 여유 공간이 부족하거나 아카이브 프로세서를 띄워서 자동으로 아카이브가 수행되도록 설정하는 단계를 건너 뛴 것이 대표적이다.

 

수동으로 아카이브를 시키는 명령은 여러 가지가 있는데 보기 중에서는 (a), (d)가 있으며 (c) 명령을 실행시키면 아카이브 프로세스가 기동되어 자동 아카이브 모드로 운영된다. 단, 인스턴스를 셧다운 하면 그 효력은 상실되므로 계속 자동 아카이브 모드를 유지하려면 파라미터 파일에 LOG_ARCHIVE_START=TRUE 라고 추가해야 한다.

 

정답 : (a), (c), (d) (<- 마우스로 정답 부분을 선택하세요)

 

 

2-2. 아카이브로그 파일의 멀티플렉싱과 아카이브 프로세스는 각각 최대 몇 개 까지 가능한가?

 

a. 2, 2

b. 3, 5

c. 5, 3

d. 5, 5

e. 5, 10

 

 

<해설>

 

“아카이브로그 파일을 굳이 멀티플렉싱할 필요가 있을까?” 하는 의문을 던지는 분들도 있을 것이다. 아카이브로그 모드로 운영하다 보면 생성되는 파일의 개수가 굉장히 많기 때문에 조금의 부주의로 한 두개의 아카이브로그 파일이 없어지는 경우가 심심찮게 발생한다.. 아카이브로그 파일의 특성상 모든 파일을 철저하게 보관하고 있더라도 중간 시점에 생성된 하나만 잃어버리면 그 이후의 아카이브로그 파일은 쓸모가 없기 때문에 전체를 완전하게 보존해야 한다. 그래서 디스크의 가격이 별 문제가 되지 않는 요즘에는 아카이브로그 파일의 멀티플렉싱이 매우 설득력 있는 장애 대비 방법의 하나라고 말할 수 있다.

 

오라클 8.0 버전에서는 아카이브로그 파일의 멀티플렉싱이 두 곳으로만 가능했지만 오라클 8i부터는 최대 다섯 개로 확장되었다. 즉, 이전의 방법은 LOG_ARCHIVE_DEST와 LOG_ARCHIVE_DUPLEX_DEST 파라미터를 사용하여 두 개의 디렉토리를 지정하는 것이었는데 지금은 LOG_ARCHIVE_DEST_1, LOG_ARCHIVE_DEST_2, …, LOG_ARCHIVE_DEST_5와 같은 다섯 개의 파라미터를 이용하여 아카이브로그 파일을 저장하는 디렉토리를 지정할 수 있다. 오라클 8i 에서는 이 두 가지 방법을 모두 사용할 수 있지만 서로 배타적이므로 어느 하나만을 선택해서 이용해야 한다.

 

이렇게 아카이브로그 파일을 여러 곳에 생성하다 보니 자연히 하나의 ARCn 프로세스만으로는 작업을 감당하기 벅차기 때문에 필요에 따라서 최대 10개의 ARCn 프로세스가 떠서 작업을 할 수 있다. 단, 실제로 사용되는 ARCn 프로세스의 개수는 오라클에서 자동으로 결정하며 LOG_ARCHIVE_MAX_PROCESSES 파라미터는 단지 인스턴스 기동시에 뜨는 ARCn 프로세스의 개수를 의미할 뿐이다.

 

정답 : (e) (<- 마우스로 정답 부분을 선택하세요)

 

물리적 백업

 

3-1. 데이터파일이 백업 모드 상태인지를 확인할 수 있는 딕셔너리는? (두 가지)

 

a. V$DATAFILE

b. V$DBFILE

c. V$DATAFILE_HEADER

d. V$BACKUP

e. V$DATABASE

 

 

<해설>

 

백업 모드란 해당 데이터파일이 핫 백업을 받는 상태에 놓여있다는 것을 말한다.

 

ALTER TABLESPACE 테이블스페이스명 BEGIN BACKUP;

 

명령으로 특정 테이블스페이스를 백업하겠다고 지정하면 그 테이블스페이스를 구성하고 있는 모든 데이터파일이 백업 모드로 변경된다.

 

백업 모드에서는 데이터파일의 헤더에 기록되는 SCN은 갱신되지 않지만 해당 테이블스페이스에 대한 SELECT, INSERT 등의 작업이 모두 가능하므로 사용자는 백업 모드라는 것을 의식하지 않고 그대로 사용할 수 있다.

 

그러나 백업 모드에서는 리두로그 파일에 추가적인 정보가 기록되므로 사용자가 적은 시간대를 선택해서 작업을 해야 퍼포먼스 저하를 방지할 수 있다.

 

데이터가 변경되거나 추가될 때 백업 모드 상태의 데이터파일에는 직접 기록되지 않고 리두로그 파일에만 저장되었다가 나중에 백업 모드에서 빠져나오면 리두로그 파일의 정보를 데이터파일에 반영하는 것으로 오해할 소지도 있다. 그러나 실제로는 평상시와 마찬가지로 백업 모드에서도 데이터파일에 변경 사항이 기록되며 단지 헤더에 저장되는 SCN이 갱신되지 않는 것이다.

 

데이터파일이 백업 모드인지를 확인할 때에는 보통 V$BACKUP을 이용한다. V$BACKUP의 STATUS 컬럼의 값이 ACTIVE 라면 해당 데이터파일이 백업 모드임을 의미한다.

 

또한 V$DATAFILE_HEADER의 FUZZY 컬럼의 값이 YES일 때에도 백업 모드라고 판단할 수 있다.

 

여러 개의 테이블스페이스를 한 번에 백업 모드로 전환시켜서 작업하면 어떤 테이블스페이스가 백업 모드 상태인지 혼란스럽고 리두로그 데이터의 생성이 과도하게 늘어날 뿐 아니라 미처 백업 모드를 종료하지 않은 상태에서 데이터베이스가 다운될 경우 복구가 번거로우므로 한 번에 하나씩 백업 모드로 전환해서 작업하는 것이 정석이다.

 

 

정답 : (c),(d) (<- 마우스로 정답 부분을 선택하세요)

 

 

3-2. 다음 명령을 실행했을 때 컨트롤 파일이 백업되는 디렉토리는 어떤 초기화 파라미터에 의해서 결정되는가?

 

ALTER DATABASE BACKUP CONTROLFILE TO TRACE;

 

a. BACKGROUND_DUMP_DEST

b. LOG_ARCHIVE_DEST

c. CORE_DUMP_DEST

d. STANDBY_ARCHIVE_DEST

e. USER_DUMP_DEST

 

 

<해설>

 

컨트롤 파일을 백업하는 명령은 두 가지가 있다. 먼저 위의 명령을 실행하면 USER_DUMP_DEST 파라미터에 지정된 위치로 텍스트 포맷의 트레이스 파일이 생성되는데 이 파일은 약간의 편집을 거치면 직접 실행해서 컨트롤 파일을 만들 수 있도록 SQL 스크립트 형식으로 되어 있다.

 

그리고 다음 명령으로도 컨트롤 파일을 백업할 수 있다.

 

ALTER DATABASE BACKUP CONTROLFILE TO ‘/disk1/backup/backup1.ctl’;

 

이 명령을 실행하면 /disk/backup/backup1.ctl 이라는 이름으로 컨트롤 파일이 백업되는데 이 파일은 원래의 컨트롤 파일과 동일한 바이너리 포맷이라는 점이 앞의 명령과 차이가 있다.

 

정답 : (e) (<- 마우스로 정답 부분을 선택하세요)

 

3-3. 다음 두 명령을 실행할 때 각각 어느 시점에 관련된 테이블스페이스를 백업하는 것이 바람직한가?

 

ALTER TABLESPACE users READ ONLY;

 

CREATE TABLE newemp

AS SELECT * FROM emp UNRECOVERABLE;

 

a. 명령 전, 명령 전

b. 명령 전, 명령 후

c. 명령 후, 명령 전

d. 명령 후, 명령 후

e. 필요 없음

 

 

<해설>

 

테이블스페이스를 읽기전용(read-only) 상태로 전환한 다음에는 백업을 받아두는 습관을 기르는 것이 좋다. 읽기전용 상태로 변경하기 전에 백업을 받으면 장애가 발생했을 때 백업을 리스토어 하고 나서 다시 리두로그 파일을 이용한 복구작업을 수행해야 한다. 그러나 읽기전용 상태로 전환한 다음에 백업을 해 주면 단순히 백업을 리스토어 하는 것으로 복구가 끝나므로 복구 시간을 단축할 수 있다..

 

다음의 명령도 비슷한 맥락에서 생각해 볼 수 있다. 이와 같은 Nologging 명령은 리두로그 정보를 발생하지 않기 때문에 실행 속도가 빠르다는 장점은 있지만 대신 장애가 발생했을 때 리두로그 파일을 이용한 복구가 불가능하다. 따라서 Nologging 명령을 수행한 다음에는 바로 백업을 실시하는 것이 좋다. Nologging 명령을 수행하기 전에 받은 백업은 별 의미가 없다.

 

정답 : (d) (<- 마우스로 정답 부분을 선택하세요)

 

완전복구 (Complete Recovery)

 

4-1. 다음은 아카이브로그 모드로 운영중인 데이터베이스의 작업 및 장애 내용을 기록한 것이다.

 

03:00 데이터베이스 전체 백업

09:00 트랜잭션 A 실행

09:10 트랜잭션 B 실행

10:00 트랜잭션 B 커밋

10:10 트랜잭션 A 커밋

11:00 트랜잭션 C 실행

11:05 SYSTEM 데이터 파일이 손상되면서 데이터베이스 다운

 

데이터베이스를 완전히 복구했을 때 복구되는 트랜잭션은?

 

a. 트랜잭션 A

b. 트랜잭션 A,B

c. 트랜잭션 B,C

d. 트랜잭션 A,C

e. 트랜잭션 A,B,C

 

 

<해설>

 

아카이브로그 모드의 장점을 얘기할 때에는 장애가 발생해도 데이터의 손실 없이 완전한 복구가 가능하다는 말이 결코 빠지지 않는다.

 

그러나 아카이브로그 모드도 커밋되지 않은 트랜잭션은 복구시키지 않으므로 완벽하게 장애가 발생하기 직전으로 돌아가는 것은 아니다. 롤 포워드(roll forward)로 복구를 한 후에 커밋되지 않은 트랜잭션은 다시 롤백시키기 때문인데 문서 작업을 하다가 PC가 다운되면 이전에 저장하고 난 다음의 내용은 날아가 버리는 것과 비슷한 이치라고 하겠다.

 

결론적으로 트랜잭션 A, B는 커밋을 했지만 트랜잭션 C는 커밋하기 전에 데이터베이스가 다운되었으므로 트랜잭션 C는 복구 후에 다시 작업해야 한다.

 

 

 

정답 : (b) (<- 마우스로 정답 부분을 선택하세요)

 

 

4-2. 노아카이브로그 모드로 운영중인 데이터베이스에서 USERS 테이블스페이스의 데이터 파일을 실수로 삭제하였다. 전날 콜드 백업을 받아두었다면 어떤 복구 방법을 사용하는 것이 가장 적절한가?

 

a. 삭제된 데이터 파일만 리스토어 하면 된다.

b. 삭제된 데이터 파일만 리스토어 하고 복구한다.

c. 콜드 백업 전체를 리스토어 한다.

d. 콜드 백업에서 모든 데이터 파일만 리스토어 하고 복구를 실시한다.

 

 

<해설>

 

노아카이브로그 모드로 운영할 때에는 복구 방법이 매우 제한적이다. 99.9%의 경우 백업 전체를 내리는 조치밖에는 별다른 대안이 없기 때문에 사실 복구보다는 단순한 리스토어에 가깝다고 할 수 있다.

 

극히 예외적인 경우로 백업을 받은 이후에 온라인 리두로그 파일이 순환되어 덮어씌워지지 않은 상태에서 데이터 파일이 없어졌다면 백업 이후의 작업 내용이 온라인 리두로그 파일에 그대로 살아있으므로 (b)나 (d)와 같은 방법도 가능하다. 그러나 실제 상황에서 이런 행운은 기대하지 않는 편이 좋으므로 정답과는 거리가 있다고 하겠다.

 

일반적으로 콜드 백업을 리스토어 할 때에는 없어진 데이터 파일을 포함하여 나머지도 모두 함께 리스토어 해야 한다. 그렇지 않으면 데이터베이스의 일관성을 유지할 수 없기 때문에 사용할 수 없다.

 

정답 : (c) (<- 마우스로 정답 부분을 선택하세요)

 

4-3. 디스크 에러가 발생하여 백업을 리스토어 하고 데이터베이스를 마운트 시켰다. 복구가 필요한 파일을 알려면 어떤 딕셔너리를 참조하면 되는가?

 

a. v$log_history

b. v$recover_file

c. v$recovery_log

d. v$filestat

e. v$datafile

 

 

<해설>

 

미디어 복구가 필요한 데이터 파일이 있다면 데이터베이스를 오픈할 때 “이러이러한 파일이 미디어 복구가 필요하다”는 에러 메시지가 나오므로 힘들이지 않고도 복구할 파일을 알 수 있다. 그러나 에러가 나오기 전에 미리 문제의 데이터 파일을 알고 싶다면 v$recover_file를 참조하면 된다.

 

v$log_history에는 리두로그 파일이 스위치 되면서 발생하는 과거 기록이 담겨 있다. 아카이브로그 모드가 아니더라도 상관없으며 컨트롤 파일에 들어있는 리두로그 히스토리를 보여준다.

 

 

 

정답 : (c),(d) (<- 마우스로 정답 부분을 선택하세요)

 

 

3-2. 다음 명령을 실행했을 때 컨트롤 파일이 백업되는 디렉토리는 어떤 초기화 파라미터에 의해서 결정되는가?

 

ALTER DATABASE BACKUP CONTROLFILE TO TRACE;

 

a. BACKGROUND_DUMP_DEST

b. LOG_ARCHIVE_DEST

c. CORE_DUMP_DEST

d. STANDBY_ARCHIVE_DEST

e. USER_DUMP_DEST

 

 

<해설>

 

컨트롤 파일을 백업하는 명령은 두 가지가 있다. 먼저 위의 명령을 실행하면 USER_DUMP_DEST 파라미터에 지정된 위치로 텍스트 포맷의 트레이스 파일이 생성되는데 이 파일은 약간의 편집을 거치면 직접 실행해서 컨트롤 파일을 만들 수 있도록 SQL 스크립트 형식으로 되어 있다.

 

그리고 다음 명령으로도 컨트롤 파일을 백업할 수 있다.

 

ALTER DATABASE BACKUP CONTROLFILE TO ‘/disk1/backup/backup1.ctl’;

 

이 명령을 실행하면 /disk/backup/backup1.ctl 이라는 이름으로 컨트롤 파일이 백업되는데 이 파일은 원래의 컨트롤 파일과 동일한 바이너리 포맷이라는 점이 앞의 명령과 차이가 있다.

 

정답 : (b) (<- 마우스로 정답 부분을 선택하세요)

 

불완전 복구 (Incomplete Recovery)

 

5-1. Cancel-based recovery의 최소 복구 단위는?

 

a. 초(second)

b. SCN

c. 트랜잭션

d. 리두로그 파일

e. 오라클 블록

 

 

<해설>

 

불완전 복구(Incomplete Recovery)에는 Time-based, Cancel-based, Change-based 이상 세 가지 종류가 있다. 최소 복구 단위라면 얼마나 세밀하게 복구 간격을 조절할 수 있는가를 물어보는 것인데 정밀한 복구가 가능한 방법일수록 좀 더 높은 조작 기술과 상세한 정보를 필요로한다.

 

Time-based 방법의 예를 들면 다음과 같다.

 

RECOVER DATABASE UNTIL TIME ‘2001-03-01:15:24:30’;

 

이 명령을 실행하면 데이터베이스를 2001년 3월 1일 오후 3시 24분 30초의 상태로 만들어 준다. 이 때 지정하는 시간은 초(second) 단위 까지 설정할 수 있으며 SCN이나 로그 시퀀스 번호 보다는 시간이 쉽게 인지할 수 있는 개념이기 때문에 즐겨 이용된다.

 

Cancel-based 방법의 최소 단위는 리두로그 파일이다. 리두로그 파일의 중간 쯤에서 복구를 멈추고 싶다면 이 방법을 사용할 수 없으며 대신 Change-based 방법을 이용해야 한다.

 

Change-based 방법은 SCN 단위로 복구할 수 있기 때문에 가장 섬세한 컨트롤이 가능하다.

 

SCN은 트랜잭션 단위인데 1초 안에 여러 개의 트랜잭션이 발생할 수도 있으므로 Time-based 방법보다 Change-based 방법의 정밀도가 높다고 볼 수 있다. Time-based 방법의 정밀도는 중간 정도이고 Cancel-based 방법은 가장 사용하기 쉬운 반면 또한 가장 정밀도가 떨어진다.

 

 

 

정답 : (d) (<- 마우스로 정답 부분을 선택하세요)

 

 

5-2. 다음 중 불완전 복구를 수행해야 하는 경우가 아닌 것은?

 

a. 테이블을 삭제하기 이전의 상태로 돌아갈 때

b. 블록 손상(corruption)이 발생하기 이전으로 돌아갈 때

c. 커런트(current) 리두로그 파일이 손상되었을 때

d. 정전으로 시스템이 다운되었을 때

 

 

<해설>

 

불완전 복구는 완전 복구를 할 수 없기 때문에 불가피하게 선택하는 수도 있지만 데이터베이스를 과거의 시점으로 돌리기 위해서 일부러 불완전 복구를 하는 고의적인 상황도 있다.

 

대표적인 예가 a)와 b) 같은 경우이다. 특히 b)처럼 블록 손상이 발생하면 마치 하드디스크의 배드 섹터가 발생했을 때의 찜찜한 느낌처럼 문제가 생긴 곳 뿐 아니라 데이터베이스 전체에 대한 불신이 싹트게 된다. 그래서 성격이 깔끔한 사람은 약간의 데이터 손실을 감수하고서라도 블록 손상이 발생하기 이전으로 돌아가는 것을 선호하는 경우도 있다.

 

c)와 같이 현재 LGWR가 기록중인 커런트 리두로그 파일이 깨졌다면 이 파일의 내용은 아카이브되지 않은 상태이기 때문에 데이터의 손실은 불가피하다.

 

d)의 정전에 의한 시스템 다운은 미디어 복구가 아닌 인스턴스 복구만 하면 되므로 데이터의 손상 없이 완전 복구가 이루어진다.

 

정답 : (d) (<- 마우스로 정답 부분을 선택하세요)

 

5-3. 불완전 복구 작업을 완료하고 데이터베이스를 오픈하려고 한다. 다음 중에서 옳은 방법은?

 

a. ALTER DATABASE OPEN;

b. ALTER DATABASE OPEN NORESETLOGS;

c. ALTER DATABASE OPEN RESETLOGS;

d. ALTER DATABASE OPEN READ WRITE;

e. ALTER DATABASE OPEN READ ONLY;

 

<해설>

불완전 복구를 수행한 다음에 데이터베이스를 오픈할 때에는 반드시 RESETLOGS 옵션을 사용해야 한다.

 

RESETLOGS를 이용해서 컨트롤 파일과 데이터 파일의 시퀀스 번호를 초기화 시키고 온라인 리두로그 파일을 깨끗하게 만들어 주는 이유는 과거의 리두로그 파일들이 실수로 적용되는 것을 미연에 방지하기 위한 것이다. RESETLOGS를 사용하면 모든 데이터파일에 새로운 RESETLOGS SCN과 타임스탬프가 기록되는데 이 정보가 일치하지 않는 리두로그 파일은 복구에 사용되지 않기 때문에 잘못된 리두로그 파일이 적용되는 것을 원천적으로 차단할 수 있다.

 

RESETLOGS로 데이터베이스가 오픈되면 기존의 백업이 무의미해지므로 다시 전체 데이터베이스를 꼭 백업해 주어야 한다.

 

 

정답 : (c) (<- 마우스로 정답 부분을 선택하세요)

 

익스포트와 임포트

 

6-1. 다음과 같이 데이터베이스 작업과 백업을 수행하였다.

 

INCTYPE=COMPLETE 백업

BOOKS 테이블 생성

BOOKS 테이블에 10건의 데이터 입력

INCTYPE=INCREMENTAL 백업(a)

BOOKS 테이블에 20건의 데이터 입력

INCTYPE=CUMULATIVE 백업(b)

BOOKS 테이블에 40건의 데이터 입력

INCTYPE=INCREMENTAL 백업(c)

INCTYPE=CUMULATIVE 백업(d)

 

(a),(b),(c),(d) 단계에서 익스포트되는 BOOKS 테이블의 레코드 건수의 총 합은?

 

a. 50

b. 70

c. 90

d. 110

e. 130

 

 

<해설>

 

인크리멘탈(incremental) 익스포트는 증분 익스포트라고도 번역하지만 다소 어색하므로 그냥 소리나는 대로 쓰기로 한다.

 

인크리멘탈 익스포트는 백업 시간을 단축해 보자는 취지로 등장하였다. 익스포트를 받을 때 마다 매번 전부 다 백업하는 것은 비효율적이므로 이전에 익스포트 받은 다음에 변경된 부분만 백업할 수 있다면 시간을 크게 절감할 수 있지 않겠느냐는 것이었다.

 

그러나 결과는 절반의 성공에 그치고 말았다. 분명 이전의 백업 이후에 변경된 부분만 백업되므로 시간을 단축할 수는 있었지만 문제는 기존 테이블에 한 건만 데이터가 추가되어도 테이블 전체를 다시 백업해야 하는 특성 때문이었다.

 

결국 수 많은 테이블이 빈번하게 생성되는 시스템에서는 큰 재미를 보았지만 주로 기존 테이블에 대한 DML 작업이 많은 환경에서는 불필요하게 덤프파일의 개수만 늘어나므로 환영을 받지 못했다.

 

인크리멘탈 익스포트에는 세 가지 타입이 있다.

 

COMPLETE는 데이터베이스 전체를 백업 받는 것이고 CUMULATIVE는 이전의 COMPLETE 또는 CUMULATIVE 백업 이후의 내용을 익스포트 한다. INCREMENTAL은 이전의 COMPLETE, CUMULATIVE 또는 INCREMENTAL 익스포트 이후의 변경 사항을 백업한다.

 

이렇게 여러 레벨로 나누어 놓은 이유는 파일 관리를 좀 더 수월하게 하기 위해서이다. 인크리멘탈 익스포트의 단점 중의 하나가 관리할 덤프 파일이 갈수록 늘어난다는 점인데 여러 차레 인크리멘탈 익스포트를 수행한 다음에 그보다 상위의 모드로 익스포트를 수행하면 이전의 자잘한 덤프파일을 대체할 수 있다.

 

본 문제에서는 인크리멘탈 익스포트를 수행할 때 마다 테이블의 내용이 변경되었기 때문에 (a)=10건, (b)=10+20=30건, (c)=10+20+40=70건이 각각 익스포트 된다. (d)에서는 BOOKS 테이블에 변경 사항이 없으므로 0건이 익스포트 된다. 따라서 모두 합치면 110건이 정답이다.

 

 

 

 

정답 : (d) (<- 마우스로 정답 부분을 선택하세요)

 

 

6-2. 임포트 되는 순서를 올바르게 나열하시오(주관식).

 

a. 테이블 데이터

b. 테이블 정의(definition)

c. 제약 조건, 뷰, 프로시저, 트리거

d. 테이블 인덱스

e. 타입(type) 정의

 

 

 

<해설>

 

객체에 따라서 다른 객체를 참조하지 않는 완전 독립형인 경우도 있지만 대부분 여러 객체가 서로 얽혀 있는 것이 일반적이다. 그래서 임포트될 때 최고의 효율을 꾀하고 의존 관계에 의한 에러를 방지하기 위해서 매우 정교하게 순서가 설정되어 있는데 힘들여 암기할 필요 없이 아래처럼 논리적으로 따져보면 대략 순서를 유추할 수 있다.

 

먼저 테이블을 만들 때 타입 정의를 사용할 수도 있으므로 테이블보다는 타입이 먼저 만들어져야 함을 알 수 있다..

 

그리고 인덱스가 있는 상태에서 데이터를 넣는 것보다 데이터를 먼저 넣은 다음에 인덱스를 생성하는 것이 속도가 빠르기 때문에 데이터와 인덱스의 임포트 순서가 결정된다.

 

그 밖에 제약조건은 특히 레퍼런스 때문에 자연스럽게 뒤로 밀리게 되고 트리거는 테이블의 데이터보다 먼저 만들면 나중에 데이터가 임포트 될 때 불필요하게 실행되므로 이를 방지하기 위해서 역시 우선순위가 낮게 설정된다.

 

이런 관계를 종합해 보면 큰 어려움 없이 정답을 찾아낼 수 있을 것이다.

 

정답 : (f),(c),(b),(e),(d) (<- 마우스로 정답 부분을 선택하세요)

 

6-3. TSPITR(Tablespace Point-In-Time Recovery)와 관련된 초기화 파라미터가 아닌 것은?

 

a. LOCK_NAME_SPACE

b. DB_FILE_NAME_CONVERT

c. LOG_FILE_NAME_CONVERT

d. CONTROL_FILE_NAME_CONVERT

 

<해설>

 

실수로 테이블을 하나 삭제한 후에 이 테이블을 살려내야 한다면?

 

전통적인 복구 전략에 따르면 백업 전체를 리스토어 한 다음에 불완전 복구를 수행하거나 별도의 장소에 백업을 리스토어 한 다음 익스포트/임포트를 이용하여 테이블을 받아와야 할 것이다.

 

TSPITR은 이런 문제에 대한 업그레이드된 해결 방법이다. 전체적인 개념은 두 번째의 익스포트/임포트 방법과 유사하지만 TSPITR은 익스포트/임포트를 통해서는 메타데이터만 전송하고 실제의 데이터 복구는 운영체제 상의 데이터 파일을 복사하는 것으로 대신하기 때문에 속도가 매우 빠르다. 테이블이 아닌 테이블스페이스를 기본 단위로 한다는 특징이 있고 작업 과정이 비교적 복잡한 편이지만 삭제된 테이블의 크기가 클수록 그 가치가 더욱 빛나는 기능이다.

 

LOCK_NAME_SPACE는 클론 데이터베이스(TSPITR을 위해서 생성한 데이터베이스)가 원래의 데이터베이스와 이름이 같아도 기동할 수 있도록 하는 역할을 하므로 데이터베이스 이름을 바꿀 필요가 없도록 해 준다.

 

클론 데이터베이스를 기동할 때 기존 데이터베이스의 컨트롤 파일 백업본을 이용하는데 파일들의 위치가 기존 데이터베이스와 달라지기 때문에 새로운 위치에 있는 파일을 찾을 수 있도록 디렉토리 이름을 바꿔주는 파라미터가 제공된다.

 

데이터 파일은 DB_FILE_NAME_CONVERT, 리두로그 파일은 LOG_FILE_NAME_CONVERT를 이용해서 위치를 변환한다. 파일 이름이 아닌 디렉토리를 지정하는 것임을 주의하기 바란다. 예를 들면 다음과 같다.

 

DB_FILE_NAME_CONVERT = ‘/disk1/oracle/orig’,’/disk1/oracle/clone’

 

정답 : (d) (<- 마우스로 정답 부분을 선택하세요)

Oracle Database 10g: DBA를 위한 20가지 주요 기능

Arup Nanda

한층 강화된 엑스포트/임포트: Oracle Data Pump  

Oracle Database 10g 유틸리티로 크게 향상된 데이타 이동 기능

지금까지 엑스포트/임포트 툴세트는 열악한 속도에 대한 불만에도 불구하고 최소한의 노력으로 여러 플랫폼에 데이타를 전송하기 위해사용해 온 유틸리티였습니다. 임포트는 단순히 엑스포트 덤프 파일에서 각 레코드를 읽고 이를 일반적인 INSERT INTO 명령을사용해 대상 테이블에 삽입하기만 하므로 임포트 프로세스가 느린 것은 그리 놀랄만한 일이 아닙니다.
이제 프로세스 속도가월등히 향상된 Oracle Database 10g의 보다 새롭고 빠른 엑스포트/임포트 툴킷인 Oracle Data Pump,the newer and faster sibling of the export/import toolkit in OracleDatabase 10g를 사용해 보십시오.

Data Pump는 엑스포트/임포트 프로세스의 전체 구성을나타냅니다. 일반적인 SQL 문을 사용하는 대신 독점 API로 데이타를 현저하게 빠른 속도로 로드 및 언로드합니다. 제가테스트해본 결과, 직접 모드의 엑스포트보다 병�?10-15배 향상되었으며, 임포트 프로세스 성능도 5배 이상 증가했습니다. 또한엑스포트 유틸리티와 달리 프로시저 같은 특정 유형의 객체만 추출할 수 있습니다.

Data Pump Export

이새로운 유틸리티는 원래의 엑스포트인 exp와 구분하기 위해 expdp라고 합니다. 이 예에서는 Data Pump를 사용해 약3GB 크기의 대형 테이블인 CASES를 엑스포트합니다. Data Pump는 서버 측에서 파일 조작을 사용하여 파일을 생성하고읽으므로 디렉토리를 위치로 사용합니다. 여기서는 filesystem /u02/dpdata1을 사용해 덤프 파일을 유지할예정입니다.

create directory dpdata1 as '/u02/dpdata1';
grant read, write on directory dpdata1 to ananda;


그리고 다음과 같이 데이타를 엑스포트합니다.

expdp ananda/abc123 tables=CASES directory=DPDATA1 dumpfile=expCASES.dmp job_name=CASES_EXPORT
이제 이 명령의 각 부분을 분석해 보겠습니다. 사용자 ID/암호 조합, 테이블 및 덤프 파일 매개변수는 말 그대로이므로 설명이필요 없습니다. 원래의 엑스포트와 달리 파일이 클라이언트가 아닌 서버에 생성됩니다. 위치는 디렉토리 매개변수 값 DPDATA1로지정되며, 이는 이전에 생성된 /u02/dpdata1을 가리킵니다. 또한 프로세스를 실행하면 서버의 디렉토리 매개변수로 지정된위치에 로그 파일이 생성됩니다. 이 프로세스에는 기본적으로 DPUMP_DIR로 명명된 디렉토리가 사용되므로 DPDATA1 대신생성할 수 있습니다.

위의 job_name 매개변수를 보면 원래의 엑스포트에 없는 특별한 항목이 하나 있습니다.모든 Data Pump 작업은 작업(job)을 통해 이뤄집니다. Data Pump 작업은 DBMS 작업과 달리 주 프로세스를대신해 데이타를 처리하는 단순한 서버 프로세스입니다. 마스터 제어 프로세스라고 하는 이 주 프로세스는 AdvancedQueuing을 통해 이러한 작업 노력을 조정하는데, 이는 마스터 테이블이라고 하는 런타임 시 생성된 특수 테이블을 통해이뤄집니다. 제시한 예에서 expdp를 실행하면서 사용자 ANANDA의 스키마를 검사하면 job_name 매개변수에 해당되는CASES_EXPORT 테이블이 있음을 알 수 있습니다. expdp가 종료되면 이 테이블은 삭제됩니다.

엑스포트 모니터링

DPE(DataPump Export)를 실행하면서 Control-C를 누르면 화면상에 메시지 표시를 중지하지만 프로세스 자체를 엑스포트하지는않습니다. 대신 다음과 같이 DPE 프롬프트를 표시합니다. 이제 프로세스는 소위 “대화식” 모드에 들어갑니다.

Export>

이 접근방법에서는 DPE 작업에 여러 명령을 입력할 수 있습니다. 요약을 확인하려면 다음과 같이 프롬프트에 STATUS 명령을 사용합니다.

Export>status Job: CASES_EXPORT Operation: EXPORT Mode: TABLE State: EXECUTINGDegree: 1 Job Error Count: 0 Dump file: /u02/dpdata1/expCASES.dmp byteswritten = 2048 Worker 1 Status: State: EXECUTING Object Schema: DWOWNERObject Name: CASES Object Type:TABLE_EXPORT/TBL_TABLE_DATA/TABLE/TABLE_DATA Completed Objects: 1 TotalObjects: 1 Completed Rows: 4687818
하지만 이것은 상태 표시일 뿐이며 엑스포트는 백그라운드에서 실행되고 있습니다. 화면의 메시지를 계속 확인하려면 Export> 프롬프트에서 CONTINUE_CLIENT 명령을 사용합니다.

병렬 작업

PARALLEL매개변수를 통해 엑스포트시 하나 이상의 스레드를 사용하면 작업 속도를 크게 개선할 수 있습니다. 스레드마다 개별 덤프 파일을생성하므로 매개변수 dumpfile은 병렬화 만큼 많은 여러 항목을 갖게 됩니다. 또한 하나씩 명시적으로 입력하는 대신 다음과같이 대체 문자를 파일 이름으로 지정할 수 있습니다.

expdp ananda/abc123 tables=CASES directory=DPDATA1 dumpfile=expCASES_%U.dmp parallel=4 job_name=Cases_Export
여기서 dumpfile 매개변수에 어떻게 대체 문자 %U가 생기는지 주목합니다. 이 대체 문자는 파일이 필요에 따라 생성되고형식은 expCASES_nn.dmp이 됨을 나타내는데, 여기서 nn은 01에서 시작하며 필요에 따라 증가하게 됩니다.

병렬 모드에서는 상태 화면에 네 개의 작업자 프로세스가 표시됩니다. (기본 모드에서는 프로세스가 한 개만 표시됩니다.) 모든 작업자 프로세스가 데이타를 동시에 추출하며 진행률을 상태 화면에 표시합니다.

데이타베이스 파일 및 덤프 파일 디렉토리 파일 시스템에 액세스하려면 I/O 채널을 반드시 구분해야 합니다. 그렇지 않으면 DataPump 작업의 유지와 관련된 오버헤드가 병렬 스레드의 이점을 뛰어넘어 성능을 저하시킬 수 있습니다. 병렬화는 테이블 수가 병렬값보다 크고 테이블이 대규모인 경우에만 적용됩니다.

데이타베이스 모니터링

데이타베이스 뷰에서실행되는 Data Pump 작업에 관해서도 자세한 정보를 확인할 수 있습니다. 작업을 모니터링하는 기본 뷰는DBA_DATAPUMP_JOBS로 작업에서 실행되는 작업자 프로세스(DEGREE 열)의 수를 알려줍니다. 그 밖의 중요한 뷰에는DBA_DATAPUMP_SESSIONS가 있는데, 이전 뷰 및 V$SESSION과 조인하면 주 포그라운드(Foreground)프로세스 세션의 SID를 확인할 수 있습니다.

select sid, serial# from v$session s, dba_datapump_sessions d where s.saddr = d.saddr;

이 명령에는 포그라운드 프로세스의 세션이 표시됩니다. 경고 로그에서는 보다 유용한 정보를 얻을 수 있습니다. 프로세스가 시작되면 MCP 및 작업자 프로세스가 다음과 같이 경고 로그에 나타납니다.

kupprdp:master process DM00 started with pid=23, OS id=20530 to execute -SYS.KUPM$MCP.MAIN('CASES_EXPORT', 'ANANDA'); kupprdp: worker processDW01 started with worker id=1, pid=24, OS id=20532 to execute -SYS.KUPW$WORKER.MAIN('CASES_EXPORT', 'ANANDA'); kupprdp: worker processDW03 started with worker id=2, pid=25, OS id=20534 to execute -SYS.KUPW$WORKER.MAIN('CASES_EXPORT', 'ANANDA');
경고 로그에는 Data Pump 작업을 위해 시작된 세션의 PID가 표시됩니다. 실제 SID는 이 질의를 사용해 확인합니다.

select sid, program from v$session where paddr in (select addr from v$process where pid in (23,24,25));
PROGRAM열에는 경고 로그 파일의 이름에 해당되는 프로세스 DM(마스터 프로세스) 또는 DW(작업자 프로세스)가 표시됩니다. SID 23같은 작업자 프로세스에서 병렬 질의를 사용하는 경우, V$PX_SESSION 뷰에서 확인할 수 있습니다. 이 뷰에는 SID23으로 표시된 작업자 프로세스에서 실행되는 모든 병렬 질의 세션이 나타납니다.

select sid from v$px_session where qcsid = 23;

V$SESSION_LONGOPS 뷰에서는 작업 완료에 걸리는 시간을 예측하는 또 다른 유용한 정보를 얻을 수 있습니다.

select sid, serial#, sofar, totalwork from v$session_longops where opname = 'CASES_EXPORT' and sofar != totalwork;

totalwork 열에는 총 작업량이 표시되는데, 이 중 현재까지 sofar 작업량을 완료했으므로 이를 통해 얼마나 더 시간이 걸릴지 예측할 수 있습니다.

Data Pump Import

하지만 Data Pump에서 가장 눈에 잘 띄는 부분은 데이타 임포트 성능입니다. 이전에 엑스포트된 데이타를 임포트하려면 다음을 사용합니다.

impdp ananda/abc123 directory=dpdata1 dumpfile=expCASES.dmp job_name=cases_import

임포트 프로세스의 기본 작업 방식은 테이블 및 연관된 모든 객체를 생성하고 테이블이 있는 상태에서 오류를 만들어 내는 것입니다.기존 테이블에 데이타를 추가해야 하는 경우 위의 명령행에 TABLE_EXISTS_ACTION=APPEND를 사용할 수 있습니다.

DPE와 마찬가지로 프로세스 도중 Control-C를 누르면 DPI(Date Pump Import)의 대화식 모드를 표시하며 Import>가 프롬프트됩니다.

특정 객체 작업

한사용자에서 특정 프로시저만 엑스포트하여 다른 데이타베이스나 사용자에 다시 생성해야 했던 경험이 있습니까? 기존의 엑스포트유틸리티와 달리 Data Pump는 특정 유형의 객체만 엑스포트할 수 있습니다. 예를 들어, 다음 명령을 실행하면 테이블, 뷰또는 함수 등은 제외하고 오로지 프로시저만 엑스포트할 수 있습니다.

expdp ananda/iclaimdirectory=DPDATA1 dumpfile=expprocs.dmp include=PROCEDURE To exportonly a few specific objects--say, function FUNC1 and procedurePROC1--you could use expdp ananda/iclaim directory=DPDATA1dumpfile=expprocs.dmp include=PROCEDURE:"='PROC1'",FUNCTION:"='FUNC1'"
이 덤프 파일은 소스의 백업으로 사용됩니다. 때로는 이를 사용해 DDL 스크립트를 생성하여 나중에 사용할 수도 있습니다. DDL 스크립트 파일을 생성하려면 SQLFILE이라고 하는 특수 매개변수를 사용합니다.

impdp ananda/iclaim directory=DPDATA1 dumpfile=expprocs.dmp sqlfile=procs.sql

이 명령은 DPDATA1로 지정된 디렉토리에 procs.sql로 명명된 파일을 생성하며 엑스포트 덤프 파일 내의 객체 스크립트가 들어 있습니다. 이 접근방법을 사용하면 다른 스키마에 원본을 보다 신속하게 생성할 수 있습니다.

INCLUDE매개변수를 사용하면 객체가 덤프 파일에서 포함 또는 제외되도록 정의할 수 있습니다. 예를 들어,INCLUDE=TABLE:"LIKE 'TAB%'" 절을 사용하면 이름이 TAB로 시작하는 테이블만 엑스포트할 수 있습니다.마찬가지로 INCLUDE=TABLE:"NOT LIKE 'TAB%'" 구문을 사용하면 TAB으로 시작하는 모든 테이블을 제외시킬수 있습니다. 아니면 EXCLUDE 매개변수를 사용해 특정 객체를 제외시킬 수 있습니다.

Data Pump를사용하면 외부 테이블로 테이블스페이스를 이동할 수도 있는데, 이렇게 하면 진행 중인 병렬화를 다시 정의하고 기존 프로세스에테이블을 추가하는 등의 작업에 매우 효과적입니다. 다음 명령을 실행하면 Data Pump 엑스포트 유틸리티에서 사용 가능한매개변수 목록이 생성됩니다.

expdp help=y

마찬가지로 impdp help=y 명령을 실행하면 DPI의 모든 매개변수가 표시됩니다.

DataPump 작업을 실행하는 동안 DPE 또는 DPI 프롬프트에 STOP_JOB을 실행하여 작업을 일시 중지한 다음START_JOB으로 다시 시작할 수 있습니다. 이 기능은 공간이 부족하여 계속하기 전에 정정해야 하는 경우 유용하게 사용할 수있습니다.

제공 : DB포탈사이트 DBguide.net

SYSMAN의 패스워드를 수정하게 되면 OEM(Oracle Enterprise Manager)관련 설정도 바뀐다는 것을 미쳐 몰랐기에 결국 OEM을 재구축하는 상황을 맞이하였습니다.

과거 OEM의 재구축에 관련해서 포스팅한 적이 있으나 RAC환경에 특화된 내용인데다 당시 지식이 부족했던 탓에 여러가지 잡다한 설정이 많았습니만 이번에는 RAC가 아닌 일반적인 싱글 DB환경에서 최소한 간략한 커맨드 구성으로 OEM을 재구축해 보았습니다.

기본적으로 OEM 재구축은 EMCA를 이용해서 다음의 2줄로 끝납니다.

emca -deconfig dbcontrol db -repos drop << 기존 OEM관련 삭제
emca -config dbcontrol db -repos create << OEM 작성

다만 언제나 오라클 관련 작업이 그렇듯 예상치 못했던 트러블이 이번에도 발생했는데요. 이번 작업 내용을 쭉 보면서 그부분도 설명해 보겠습니다.

1. 기존 OEM관련 삭제

[oracle@HostName log]$ emca -deconfig dbcontrol db -repos drop

EMCAの開始: 2008/03/14 14:04:23
EMコンフィギュレーション・アシスタント, リリース10.2.0.1.0 Production
Copyright (c) 2003, 2005, Oracle. All rights reserved.

次の情報を入力してください:
データベースのSID: orcl
リスナーのポート番号: 1521
SYSユーザーのパスワード:
SYSMANユーザーのパスワード:

続行しますか。 [はい(Y)/いいえ(N)]: y
2008/03/14 14:04:43 oracle.sysman.emcp.EMConfig perform
情報: この操作は/opt/app/oracle/product/10.2.0/db/cfgtoollogs/emca/orcl/emca_2008-03-14_02-04-23-午後.logでロギングされています。
2008/03/14 14:04:43 oracle.sysman.emcp.util.DBControlUtil stopOMS
情報: Database Controlの停止中(少し時間がかかります)...
2008/03/14 14:04:45 oracle.sysman.emcp.EMReposConfig stopDBMSJobs
警告: SQL接続の初期化中にエラーが発生しました。SQL操作を実行できません
2008/03/14 14:04:45 oracle.sysman.emcp.EMReposConfig invoke
警告: DBMSジョブを削除できません。
2008/03/14 14:04:45 oracle.sysman.emcp.EMReposConfig dropRepository
情報: EMリポジトリの削除中(少し時間がかかります)...
2008/03/14 14:05:29 oracle.sysman.emcp.EMReposConfig invoke
情報: リポジトリは正常に削除されました
Enterprise Managerの構成が正常に完了しました
EMCAの終了: 2008/03/14 14:05:29

각 시스템 유저의 패스워드만 잘 기억하고 계시다면 이부분은 별 문제가 없습니다. 메일 관련해서는 그냥 엔터치고 넘어가시면 됩니다.


2. OEM 작성

[oracle@HostName log]$ emca -config dbcontrol db -repos create
shell-init: error retrieving current directory: getcwd: cannot access parent directories: そのようなファイルやディレクトリはありません
Error occurred during initialization of VM
java.lang.Error: Properties init: Could not determine current working directory.

트러블은 이곳에서 발생했는데 위 메세지에서 보이는 getcwd에러는 과거에 오라클과 관련이 없는 부분에서도 본 기억이 있던 내용이었습니다. 즉 오라클 문제가 아니라는 것이죠. 구글신께 2시간 가까이 제사를 드린 결과 다음과 같은 신탁을 얻을 수 있었습니다.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=45511

영어공부를 소홀히 해온 것에 대한 반성의 시간을 가지며 해석을 위해 악전고투한 결과 간신히 bash 버그 문제같다는 뜻을 읽을 수 있었는데요, 언제나 그렇듯 문제점만 확인이 되면 대처는 간단했지요. bash대신 csh을 사용해서 문제를 우회했습니다.

[oracle@HostName log]$ /bin/csh

[oracle@HostName ~]$ emca -config dbcontrol db -repos create

EMCAの開始: 2008/03/14 14:16:42
EMコンフィギュレーション・アシスタント, リリース10.2.0.1.0 Production
Copyright (c) 2003, 2005, Oracle. All rights reserved.

次の情報を入力してください:
データベースのSID: orcl
リスナーのポート番号: 1521
SYSユーザーのパスワード:
DBSNMPユーザーのパスワード:
SYSMANユーザーのパスワード:
通知用の電子メール・アドレス (オプション):
通知用の送信メール(SMTP)サーバー (オプション):
-----------------------------------------------------------------

次の設定が指定されています

データベースのORACLE_HOME ................ /opt/app/oracle/product/10.2.0/db

データベース・ホスト名 ................ HostName
リスナーのポート番号 ................ 1521
データベースのSID ................ orcl
通知用の電子メール・アドレス ...............
通知用の送信メール(SMTP)サーバー ...............

-----------------------------------------------------------------
続行しますか。 [はい(Y)/いいえ(N)]: y
2008/03/14 14:17:02 oracle.sysman.emcp.EMConfig perform
情報: この操作は/opt/app/oracle/product/10.2.0/db/cfgtoollogs/emca/orcl/emca_2008-03-14_02-16-42-午後.logでロギングされています。
2008/03/14 14:17:03 oracle.sysman.emcp.EMReposConfig createRepository
情報: EMリポジトリの作成中(少し時間がかかります)...
2008/03/14 14:18:22 oracle.sysman.emcp.EMReposConfig invoke
情報: リポジトリは正常に作成されました
2008/03/14 14:18:24 oracle.sysman.emcp.util.DBControlUtil startOMS
情報: Database Controlの起動中(少し時間がかかります)...
2008/03/14 14:19:58 oracle.sysman.emcp.EMDBPostConfig performConfiguration
情報: Database Controlは正常に起動されました
2008/03/14 14:19:58 oracle.sysman.emcp.EMDBPostConfig performConfiguration
情報: >>>>>>>>>>> Database ControlのURLはhttp://HostName:1158/emです <<<<<<<<<<<
Enterprise Managerの構成が正常に完了しました
EMCAの終了: 2008/03/14 14:19:58

재구축작업은 DBSNMP유저의 패스워드 입력이 추가되는것 이외에는 삭제작업과 별 다를 것이 없습니다. 이후 OEM을 기동해서 다시 정상적으로 서비스가 사용가능한 것을 확인했습니다.

이번에 새로 얻은 경험은 sysman유저정보 변경의 위험성과 getcwd관련 에러의 테크니컬 트러블 슈팅이었습니다.

이상.

출처 : http://elflord.egloos.com/3660588