Oracle Database 11g：Ch.04 Managing the Oracle Instance.pptx
4장. Database instance 관리
학습 목표
- Oracle Database 및 컴포넌트들의 기동과 종료
- Oracle Enterprise Manager 사용
- SQL*Plus를 이용한 Database 액세스
- Database 초기화 Parameter 수정
- Database 기동 단계 설명
- Database 종료 옵션 설명
- 경보 로그 확인
- 동적 성능 View 확인
관리 프레임워크
그림 4-1
Oracle Database 관리 프레임워크는 3가지 주요 구성요소들로 구성되어 있다.
- 관리 될 Database instance
- Database로의 접속을 허용하는 Listener
- 관리 인터페이스. Database 서버가 실행 중인 노드에서 실행 중인 관리 에이전트(관리 에이전트는 Database
서버를 Oracle Enterprise Manager Grid Control에 연결한다) 또는 단독 Oracle Enterprise Manager Database Control이
될 수 있다. 이것을 Database Console이라고 부르기도 한다.
각각의 컴포넌트들이 기동된 후에만 해당 컴포넌트의 서비스를 사용 할 수 있으며, Oracle Database를 호스팅하는
서버를 종료하는 경우, 반드시 해당 컴포넌트를 정상적으로 종료시켜야 한다.
Database 컨트롤의 기동 및 종료
그림 4-2
Oracle Database는 Database Control을 제공하며, Database 컨트롤은 그리드 컨트롤 프레임워크에 접속하지 않는
Database를 위한 단독 관리 콘솔이다. Database 컨트롤에 의해 관리되는 각 Database는 별도의 Database 컨트롤이
설치된다. 하나의 Database 컨트롤은 오직 하나의 Database만 관리 할 수 있다. Database 컨트롤을 사용하기 전에
dbconsole 프로세스가 기동되어 있는지 확인하여야 한다.
dbconsole 프로세스를 기동하는 명령은 다음과 같다.
emctl start dbconsole
dbconsole 프로세스를 종료하는 명령은 다음과 같다.
emctl stop dbconsole
dbconsole 프로세스의 상태를 확인하는 명령은 다음과 같다.
emctl status dbconsole
참고 : $ORACLE_HOME/bin 디렉터리가 운영체제의 경로(path)에 포함되어 있지 않으면, 이 디렉터리를 검색하여야 할 수도 있다.
만약, Grid Infrastructure가 설치되어 있다면, 두 개의 $ORACLE_HOME이 존재하며 둘 다 emctl 유틸리티를 포함하고
있다. emctl 유틸리티는 언제나 Oracle Database의 $ORACLE_HOME을 이용하여 실행하여야 하며, Grid Infrastructure의
$ORACLE_HOME에 있는 유틸리티를 사용하면 안된다. Database 컨트롤은 서버측 에이전트 프로세스를 사용한다. 이 에이전트
프로세스는 dbconsole 프로세스가 기동 및 종료 되면 자동으로 기동 및 종료된다.
Oracle Enterprise Manager
그림 4-3
Oracle Database 소프트웨어를 설치하면, OUI는 Oracle Enterprise Manager도 설치한다. EM의 웹 기반 Database 컨트롤은
Oracle Database 관리를 위한 주요 도구로서 사용된다. EM은 DBA로서 수행하여야 하는 대부분의 태스크를 수행하기 위한
그래픽 인터페이스를 제공한다. 경보 요약 보기, 성능 그래프, 객체 생성 및 수정, 백업과 복구 수행은 EM에서 수행 할 수
있는 작업들의 일부이다. 대부분의 경우, EM의 링크를 클릭하여, 좀 더 구체적인 정보를 얻을 수 있다.
참고 : Oracle Database 11g Release 2에서 EM에 액세스하는 URL은 보안 접속을 사용하는 프로토콜인 HTTPS(HTTP 대신)를 사용한다.
EM의 dbconsole에 접근하기 위해서는 다음과 같은 형식의 URL을 입력하여야 한다.
머신에 생성한 첫 번째 Database의 경우, EM의 Database 컨트롤에 액세스하는 디폴트 포트 번호는 1158이다. 동일한
호스트에 여러 개의 Database가 존재하는 경우 특별히 다른 번호를 사용 할 수도 있다. 포트 번호를 확인하려면
portlist.ini 파일을 확인한다. portlist.ini 파일에는 Oracle Database 애플리케이션을 위한 포트 번호들이 포함되어 있으며,
이 파일은 $ORACLE_HOME/install 디렉터리에 저장되어 있다. EM에 접속하기 위해 URL을 입력하면, Database의 상태에
따라 표시되는 내용은 달라진다.
- 만약, Database가 기동 중이라면, EM은 Database 컨트롤 로그인 페이지를 표시한다. Database 컨트롤에 액세스가
허가 된 사용자 이름을 이용하여 Database에 로그인한다. 최초에는 SYS, SYSMAN, SYSTEM 사용자로 로그인 할 수 있다.
Database를 설치 할 때 계정에 지정한 암호를 사용한다. Connect As 옵션에는 Normal을 선택하거나, 특별한 Database
관리자 권한을 가지고 로그인 할 경우에는 SYSDBA를 선택한다.
- 만약, Database가 종료된 상태라면, EM은 Startup/Shutdown and Perform Recovery 페이지를 표시한다. 만약 이러한
경우라면 Startup/Shutdown 버튼을 클릭한다. 그러면, 호스트와 대상 Database의 로그인 사용자 이름 및 암호를
입력하도록 요구되며, 해당 사항을 입력하면 된다.
참고 : 만약, EM을 기동하는데 문제가 발생하면, Listener가 기동되었는지를 확인한다.
Database 홈 페이지
그림 4-4
Database Home 페이지는 Database의 전체 상태를 나타내는 일련의 메트릭을 표시하여 Database의 현재 상태를
표시한다. 속성 페이지 (탭이라고 표현하기도 함)를 이용하면, Database 관리를 위한 Performance, Availability, Server,
Schema, Data Movement, Software and Support 페이지에 액세스 할 수 있다.
Database Home 페이지에서 Database instance에 대한 다음과 같은 성능 및 상태 정보를 확인 할 수 있다.
① instance 이름, Database 버전, Oracle 홈 위치, 미디어 복구 옵션, 그 외 관련 instance 데이터
② 현재 instance 가용성
③ 특출한 경보
④ 세션 관련 및 SQL 관련 성능 정보
⑤ 주요 공간 사용량 메트릭
⑥ 구체적인 정보를 제공하는 드릴 다운 링크(예를 들어, LISTENER_<host_name>)
그 외 Oracle 도구
EM에 추가하여 SQL 문장을 실행하기 위해 SQL*Plus와 SQL Developer를 사용 할 수 있다. 이 도구들은
사용자들이 많은 Database 관리 작업 뿐만 아니라 Database 내 데이터의 읽기, 변경, 삭제를 수행 할
수 있도록 해준다. SQL*Plus는 Oracle Database에 SQL과 PL/SQL 문장을 제출하는데 사용하는 명령
줄 프로그램이다. 문장들을 인터렉티브하게 또는 SQL*Plus 스크립트로 실행 할 수 있다. SQL*Plus는
Database와 함께 설치되며 $ORACLE_HOME/bin 디렉터리에 저장되어 있다. 명령 줄에서 SQL*Plus를
실행 할 수 있으며, 윈도우 클라이언트의 경우, 시작 메뉴에서 실행 할 수 있다.
SQL Developer는 Oracle Database의 instance에 액세스하는 그래픽 사용자 인터페이스이다.
SQL Developer는 SQL 및 PL/SQL 언어를 이용한 개발을 지원한다. Oracle Database가 디폴트로
설치되면 사용 할 수 있다. SQL Developer를 이용하면 Database 객체를 브라우징 할 수 있으며, SQL
문장과 스크립트를 실행하고 PL/SQL 문장을 편집 및 디버그 할 수 있다. 또한, 다수의 제공된 리포트를
실행 할 수 있을 뿐만 아니라 자신의 리포트를 생성하거나 저장 할 수 있다.
참고 : 이 과정은 EM과 SQL*Plus를 사용한다.
SQL*Plus의 사용
그림 4-5
SQL*Plus, SQL, PL/SQL 명령으로 다음과 같은 작업을 수행하려면 SQL*Plus의 명령 줄 인터페이스 를 사용하면 된다.
- SQL 명령과 PL/SQL 블록을 입력, 편집, 실행, 저장, 불러오기, 저장한다.
- 쿼리 결과를 포맷팅, 계산, 저장, 인쇄한다.
- 모든 테이블의 컬럼 정의를 나열한다.
- 말단 사용자에게 메시지를 보내고 응답을 받는다.
- 데이터베이스 관리를 수행한다.
SQL*Plus를 기동하는 방법은 다음과 같다.
1. 터미널 윈도우를 오픈한다.
2. 명령 줄 프롬프트에서 다음과 같은 형식으로 SQL*Plus 명령을 입력한다.
$ sqlplus <userid>/<pwd> 또는 /nolog
3. NOLOG 옵션을 사용하였다면, CONNECT 명령 뒤에 접속 할 사용자 이름을 지정한다.
SQL> connect <username>
4. 프롬프트가 표시되면 사용자의 암호를 입력한다. SQL*Plus가 기동되고 디폴트 데이터베이 스에 접속된다.
쉘 스크립트로부터 SQL*Plus 호출
그림 4-6
쉘 스크립트 또는 BAT 파일에서 sqlplus를 호출하고 운영체제에서 파라미터를 전달하는 스크립트 문법을
사용하여 SQL*Plus를 호출 할 수 있다. 이 예제에서는 SQL*Plus가 운영 체제에 제어권을 돌려주기 전에
SELECT, UPDATE, COMMIT 문장을 실행한다.
SQL*Plus에서 SQL 스크립트 호출
그림 4-7
SQL*Plus 내에서 이전에 작성해 둔 SQL 스크립트 파일을 호출 할 수도 있다. 위 그림에서는 SQL*Plus를
최초로 실행 할 때, 명령줄에서 이러한 작업을 수행하였다. 단순히 @ 연산자를 사용하여 SQL*Plus
세션 내에서 이러한 작업을 수행 할 수도 있다.
예를 들어, 기존에 수립된 SQL*Plus 세션 내에서 해당 스크립트를 실행 할 수 있다.
SQL> @script.sql
참고 : 스크립트 파일의 디폴트 파일 확장자는 .sql 이다. save 명령을 이용하여 SQL*Plus 내에서
스크립트를 저장하면, 이 확장자가 자동으로 제공된다. 이 확장자를 가진 스크립트는 다음과 같이
실행 시에 확장자를 제공하지 않아도 실행이 가능하다.
SQL> @script
초기화 파라미터 파일들
그림 4-8
인스턴스를 기동 할 때, 초기화 파라미터 파일이 읽혀진다. 파라미터 파일은 두 종류의 타입이 있다.
- 서버 파라미터 파일(SPFILE) : 이 형식이 초기화 파라미터 파일 중에서 가장 선호되는 방식이다.
데이터베이스 서버에 의해 읽혀지고 기록되는 이진 파일이며, 절대 직접 편집해서는 안 된다. 오라클
인스턴스가 실행 중인 서버에 위치하며, 데이터베이스가 시작 되서 종료 될 때까지 계속 사용된다. 이
파일의 디폴트 이름은 spfile<SID>.ora이며 데이터베이스 기동 시에 자동으로 검색된다.
- 텍스트 초기화 파라미터 파일 : 데이터베이스 서버에 의해 읽혀 질 수 있는 초기화 파라미터
형식이지만, 서버에 의해 기록되지 않는다. 초기화 파라미터 설정은 데이터베이스가 기동되어 종료될
때까지 계속 사용되며, 텍스트 편집기를 사용하여 초기화 파라미터 설정을 직접 변경하여야 한다. 이
파일의 디폴트 이름은 init<SID>.ora이다(만약, 데이터베이스 기동 시에 SPFILE이 발견되지 않으면
이 파일이 자동으로 검색된다).
초기화 파라미터를 유지 관리하려면 동적인 방법으로 SPFILE을 생성하도록 한다.
참고 : 오라클 데이터베이스는 초기화 파일들을 검색하기 위해 리눅스의 경우 $ORACLE_HOME/ dbs를
검색한다. ASM을 사용하는 경우, 때때로 ASM 디스크 그룹에 저장되는 경우도 있다. 이러한 경우,
init<SID>.ora 파일이 $ORACLE_HOME/dbs에 존재하여, SPFILE의 위치를 나타내어야 한다.
초기화 파라메터 값의 유형
오라클 데이터베이스 서버는 초기화 파라미터 값으로 다음과 같은 유형을 가지고 있다.
① Boolean
② String
③ Integer
④ Parameter file
⑤ Reserved
⑥ Big Integer
파생된 파라미터 값
일부 초기화 파라미터는 다른 파라미터의 값으로부터 계산된 값이다. 보통, 파생 파라메터의 값은
변경하지 않는다. 만약, 변경한다면 계산된 값이 무시되고 지정된 값이 사용된다. 예를 들어, SESSIONS
파라미터의 디폴트 값은 PROCESSES 파라미터의 값으로부터 계산된다. 만약, PROCESSES 값이 변경되면,
SESSIONS 디폴트 값은 특정 값을 지정하지 않는 한, 변경된다.
운영 체제 의존 파라미터 값
일부 초기화 파라미터의 유효 값 또는 값의 범위는 호스트 운영 체제에 의존한다. 예를 들어,
DB_FILE_MULTIBLOCK_READ_COUNT 파라미터는 순차 스캔 (Sequential scan)이 수행되는 동안, 한 번의
I/O 작업에서 읽어온 블록의 최대 개수를 지정하는데, 이 파라미터는 플랫폼에 따라 달라진다. 이러한
블록들의 크기는 DB_BLOCK_SIZE로 지정되며, 운영 체제에 따라 디폴트 값이 달라진다.
파라미터 값 설정
초기화 파라미터는 시스템 성능을 향상시킬 수 있는 가장 큰 잠재력을 제공한다. 일부 파라미터는 성능에
영향을 미치지 않는 제한 값을 설정한다. 예를 들어, OPEN_CURSORS를 10으로 설정하면, 11번째 커서를
오픈하려고 시도하는 유저 프로세스는 오류가 발생한다. 일부 파라미터는 성능에 영향을 미치지만
절대적인 제한값을 지정하지 않는다. 예를 들어, OPEN_CURSORS 값을 낮추면 성능을 떨어뜨리기는
하지만 작업을 방해하지는 않는다.
파라미터 값의 증가는 시스템의 성능을 증가시킬 수도 있지만, 증가시킨 대부분의 파라미터는 SGA의
크기를 증가시킨다. 증가된 SGA는 데이터베이스 성능을 향상 시킬 수 있다. 가상 메모리 운영 체제에서
SGA가 너무 크면 메모리의 내부 및 외부로 Swap이 발생하므로 성능을 저하시킬 수 있다. 가상 메모리
작업 영역을 제어하는 운영 체제 파라미터는 반드시 SGA 크기로 설정해야 함을 기억해야 한다. 또한,
운영 체제의 설정은 SGA의 최대 크기를 제한한다.
간단해진 초기화 파라미터
그림 4-9
초기화 파라미터는 기본(basic)과 고급(advanced)의 두 종류가 있다. 대부분의 경우에 Database로
부터 적절한 성능을 얻으려면 오직 30개의 기본 파라미터만 튜닝 하면 된다. 드문 경우에서 최적의
성능을 얻기 위해 고급 파라미터를 수정 할 필요가 있다. 약 314개의 고급 파라미터가 존재한다.
기본 파라미터는 Database를 우수한 성능으로 운영하기 위해 설정 할 가능성이 높은 것들로 정의
된다. 그 외의 모든 파라미터들은 고급 파라미터라고 생각하면 된다.
기본 파라미터의 예는 다음과 같다.
① 전역 Database 이름 정의 : DB_NAME과 DB_DOMAIN
② 고속 복구 영역의 위치와 크기 : DB_RECOVERY_FILE_DEST와 DB_RECOVERY_FILE_DEST_ SIZE
③ 모든 SGA 구성요소의 전체 크기 : SGA_TARGET
④ 언두 공간 관리 방식과 테이블스페이스 : UNDO_TABLESPACE
⑤ COMPATIBLE 초기화 파리미터와 역호환성
초기화 파라미터 : 예
CONTROL_FILES 파라미터 : 하나 이상의 컨트롤 파일 이름을 지정한다. 오라클은 컨트롤 파일을 이중화
또는 미러링 할 것을 강력히 권장한다.
이 값의 범위 : 1~8개의 파일명(경로명 포함).
디폴트 값 : OS에 따라 다름.
DB_FILES 파라미터 : Database가 오픈 할 수 있는 Database 파일들의 최대 개수를 지정 한다.
값의 범위 : OS에 따라 다름.
디폴트 값 : 200
PROCESS 파라미터 : 오라클 서버에 동시에 접속 할 수 있는 OS 유저 프로세스의 최대 개수를 지정한다.
이 값은 모든 백그라운드 프로세스들과 유저 프로세스들을 포함한다.
이 값의 범위 : 6~OS에 따라 다름.
디폴트 값 : 100
DB_BLOCK_SIZE 파라미터 : 오라클 Database 블록의 크기(바이트)를 지정. 이 값은 Database
생성시에 설정되고, 변경될 수 없다. 이 값은 Database의 표준 블록 크기가 된다. 모든 테이블스페이스는
디폴트로 이 크기를 사용한다.
값의 범위 : 2048~32768(OS에 따라 다름).
디폴 트 값 : 8192
DB_CACHE_SIZE 파라미터 : 표준 블록 버퍼 캐시의 크기를 지정.
값의 범위 : 최소 16MB.
디폴트 값 : SGA_TARGET이 설정되면 0, 그렇지 않으면 48MB 또는 4MB * cpu_count 값 중에서 큰 값.
그림 4-10
SGA_TARGET은 모든 SGA 구성요소들의 전체 크기를 지정한다. SGA_TARGET이 지정되지 않으면 다음
메모리 풀은 자동으로 설정된다.
① Buffer cache(DB_CACHE_SIZE)
② Shared pool(SHARED_POOL_SIZE)
③ Large pool(LARGE_POOL_SIZE)
④ Java pool(JAVA_POOL_SIZE)
⑤ Streams pool(STREAMS_POOL_SIZE)
만약, 이러한 자동 튜닝 메모리 풀이 0이 아닌 값으로 설정되면, 해당 값이 ASMM(Automatic Shared
Memory Management)에 의해 최소값으로 사용된다. 만약, 애플리케이션 구성요소가 적절히 동작하기
위해서 최소한의 메모리를 필요로 한다면 최소값을 지정하도록 한다.
다음 풀은 직접 크기를 설정하는 구성요소이며 ASMM에 의해 영향을 받지 않는다.
① 로그 버퍼
② 그 외 버퍼 캐시(예를 들어, KEEP과 RECYCLE) 및 다른 블록 크기의 버퍼 캐시
③ 고정 SGA 할당 공간 및 그 외 내부 할당 공간
이러한 풀들에 할당된 메모리는 ASMM이 활성화되면 SGA_TARGET에 설정된 사용 가능한 전체
메모리에서 차감된다.
참고: MMON 프로세스는 ASMM을 지원하기 위해 자동 튜닝 메모리 풀의 값을 계산한다.
MEMORY_TARGET은 오라클 시스템 전체의 사용 가능 메모리를 지정한다. 데이터베이스는 SGA와 PGA
공간을 필요한 때에 적절히 확장 및 축소하여 MEMORY_TARGET 값으로 메모리를 조정한다.
텍스트 기반 초기화 파라미터 파일에서 MEMORY_MAX_TARGET을 지정하지 않고 MEMORY_TARGET을
지정하면, 데이터베이스는 자동으로 MEMORY_MAX_TARGET을 MEMORY_TARGET값으로 설정한다. 만약,
MEMORY_TARGET 파라미터를 지정하지 않고 MEMORY_MAX_TARGET을 지정 하면, MEMORY_TARGET
파라미터는 디폴트로 0이 지정된다. 데이터베이스가 기동된 다음, MEMORY_MAX_TARGET의 값을
초과하지 않는 범위 내에서 동적으로 MEMORY_TARGET 파라미터를 0이 아닌 값으로 변경 할 수 있다.
이 값의 범위는 152MB에서 MEMORY_MAX_TARGET이다.
PGA_AGGREGATE_TARGET 파라미터: 인스턴스에 연결된 모든 서버 프로세스들에게 할당된
PGA(Program Global Area) 메모리의 전체 크기를 지정한다. 이 메모리는 SGA(System Global Area)에
포함되지 않는다. 데이터베이스는 PGA 메모리의 목표값으로 이 파라미터를 사용한다. 이 파라미터를
설정하여야 하는 경우, 오라클 인스턴스에서 사용 가능한 시스템의 전체 메모리에서 SGA 크기를 뺀
값으로 지정한다. 이 값은 정수와 K, M, G(각각, 킬로바이트, 메가바이트, 기가바이트)를 결합하여
설정한다. 최소값은 10MB이며 최대값은 4096GB-1이다. 디폴트는 10MB 또는 SGA 크기의 20% 중에서 큰 값이다.
SHARED_POOL_SIZE 파라미터 : shared pool의 크기를 바이트로 지정한다. shared pool은 공유 커서,
저장 프로시저, 제어 구조, 병렬 실행 메시지 버퍼와 같은 객체를 포함한다.
이 값의 범위 : OS에 따라 다르다.
디폴트 값 : SGA_TARGET이 설정되면, 0이고, 그렇지 않으면 64비트 시스템에 서는 128MB, 32비트
시스템에서는 48MB이다.
UNDO_MANAGEMENT 파라미터 : 시스템이 사용 할 언두 공간 관리 모드를 지정한다. AUTO가 지정되면,
인스턴스는 AUM(Automatic Undo Management) 모드로 기동된다. 그렇지 않으면, RBU(Rollback Undo)
모드로 시작된다. RBU 모드에서 언두 공간은 외부에 롤백 세그먼트로 할당된다. AUM 모드에서 언두
공간은 외부에 언두 테이블스페이스에 할당된다.
값의 범위 : AUTO 또는 MANUAL.
만약, 인스턴스를 최초에 기동 했을 때, UNDO_MANAGEMENT 파라미터를 설정하지 않으면, 디폴트 값인
AUTO가 사용된다.
파라미터 확인을 위해 SQL*Plus 사용
그림 4-11
위 그림은 Parameter 확인을 위해 SQL*Plus를 사용하는 예를 보여준다. 다양한 Parameter의 값을
찾으려면 V$PARAMETER 딕셔너리 뷰에서 데이터를 검색한다. V$PARAMETER는 현재 세션에서 현재
Parameter 값을 표시한다. 또한, SHOW PARAMETER 명령을 문자열과 함께 사용하면, 해당 문자 열이
포함된 Parameter를 확인 할 수 있다. 다음 예제의 쿼리는 Parameter의 이름과 값을 보여준다. WHERE
절에 특정 Parameter의 이름을 지정하여 사용한다.
SQL> SELECT name, value FROM V$PARAMETER WHERE name LIKE '%pool%';
NAME TYPE VALUE
------------------------- ---------- ----------
shared_pool_size 6 0
large_pool_size 6 0
java_pool_size 6 0
streams_pool_size 6 0
shared_pool_reserved_size 6 6710886
buffer_pool_keep 2
뷰의 정의는 다음과 같다.
SQL> desc V$parameter
Name Null? Type
---------------------------------------- ------- -------------
NUM NUMBER
NAME VARCHAR2(80)
TYPE NUMBER
VALUE VARCHAR2(4000)
DISPLAY_VALUE VARCHAR2(4000)
ISDEFAULT VARCHAR2(9)
ISSES_MODIFIABLE VARCHAR2(5)
ISSYS_MODIFIABLE VARCHAR2(9)
ISINSTANCE_MODIFIABLE VARCHAR2(5)
ISMODIFIED VARCHAR2(10)
ISADJUSTED VARCHAR2(5)
ISDEPRECATED VARCHAR2(5)
ISBASIC VARCHAR2(5)
DESCRIPTION VARCHAR2(255)
UPDATE_COMMENT VARCHAR2(255)
HASH NUMBER
두 번째 예제는 Parameter 설정을 확인하기 위해 SQL*Plus에서 SHOW PARAMETER 명령을 사용하는
방법을 보여준다. 텍스트 문자열이 포함된 모든 Parameter를 찾기 위해 이 명령을 사용 할 수 있다.
예를 들어, 다음 명령을 사용하여 문자열 db가 포함된 모든 Parameter를 검색 할 수 있다.
SQL> show parameter db
NAME TYPE VALUE
------------------------------------ ----------- ---------------
…
db_8k_cache_size big integer 0
db_block_buffers integer 0
db_block_checking string FALSE
db_block_checksum string TYPICAL
db_block_size integer 8192
db_cache_advice string ON
db_cache_size big integer 0
db_create_file_dest string
그 외에 Parameter와 관련된 정보를 포함하는 뷰는 다음과 같다.
- V$SPPARAMETER : 서버 Parameter 파일의 내용에 관련된 정보를 표시한다. 만약, Instance를 기동
할 때, 서버 Parameter 파일이 사용되지 않으면, 해당 뷰의 각 행은 ISSPECIFIED 컬럼에 FALSE가 표시된다.
- V$PARAMETER2 : 세션에서 현재 유효한 초기화 Parameter에 대한 정보를 표시한다. 각 Parameter 값은
뷰의 행에 표시된다. 새로운 세션은 V$SYSTEM_PARAMETER2 뷰에 표시된 Instance 수준 값을 상속 받는다.
- V$SYSTEM_PARAMETER : Instance에 대해 현재 유효한 초기화 Parameter에 관련된 정보를 표시한다.
초기화 Parameter 값 변경
초기화 Parameter는 두 종류로 분류된다.
정적 Parameter : Instance 또는 전체 Database에 영향을 주며, init.ora 또는 SPFILE의 내용을 변경해야지만 수정 할 수 있다.
정적 Parameter는 Database를 종료한 다음, 다시 기동하여야지만 반영된다. 이 Parameter는 현재 Instance에서 변경 될 수 없다.
동적 Parameter : Database가 온라인 상태에서도 변경 할 수 있다. 두 종류가 존재한다.
- 세션 수준 Parameter는 사용자 세션에만 영향을 미친다. 정렬, 날짜 Parameter 등에 대한 국가 언어
설정을 지정하기 위해 사용 될 수 있는 NLS(National Language Support) Parameter가 그 예이다.
- 시스템 수준 Parameter는 전체 Database와 모든 세션에 영향을 미친다. SGA_TARGET 값과
아카이브 로그 위치 변경이 그 예이다. 이 Parameter들은 SCOPE 지정에 따라 설정이 유지되는 기간이
달라진다. 해당 Parameter을 영구적으로 설정하려면 이 Parameter를 SCOPE=both로 지정하여 SPFILE에
추가하든지, 직접 PFILE을 편집한다.
동적 Parameter는 ALTER SESSION 및 ALTER SYSTEM 명령을 사용하여 변경 할 수 있다.
초기화 Parameter 값을 설정하거나 변경하려면 ALTER SYSTEM 문장의 SET 구문을 사용한다.
SCOPE 구문은 다음과 같이 변경의 범위를 지정한다.
- SCOPE=SPFILE : 변경 사항이 서버 Parameter 파일에만 적용된다. 현재 Instance에는 어떠한 변경도
적용되지 않는다.
동적 및 정적 Parameter 모두 해당 변경 사항은 Database를 다시 시작했을 때만 적용되며, 변경
사항은 영구적이다.
정적 Parameter의 경우에만 허용되는 SCOPE 설정이다.
- SCOPE=MEMORY : 메모리에만 변경 사항이 적용된다. 변경 사항은 현재 Instance에만 반영되고 즉시
영향을 미친다. 동적 Parameter의 경우, 즉시 반영되지만 서버 Parameter 파일을 변경하지 않기 때문에
영구적이지는 않다. 정적 Parameter의 경우, 이 설정은 허용되지 않는다.
- SCOPE=BOTH : 서버 Parameter 파일과 메모리 모두에 변경 사항이 적용된다. 변경 사항은 현재의
Instance에 반영되고 즉시 적용된다. 동적 Parameter의 경우, 서버 Parameter 파일이 변경되므로 설정
사항은 영구적이다. 정적 Parameter의 경우, 이 설정은 허용되지 않는다.
Instance가 서버 Parameter 파일로 시작되지 않은 경우에 SCOPE=SPFILE 또는 SCOPE=BOTH를
지정하면 오류가 발생한다. 만약, 서버 Parameter 파일이 Instance를 기동하는데 사용되었다면, 디폴트는
SCOPE=BOTH이다. 만약, 텍스트 초기화 Parameter 파일을 사용하여 Instance를 기동하였다면 디폴트는 메모리이다.
일부 동적 Parameter의 경우, DEFERRED를 지정 할 수도 있다. 이 값이 지정되면, 변경 사항은 다음
세션부터 반영된다. 이 값은 다음 Parameter에서만 유효하다.
① backup_tape_io_slaves
② recyclebin
③ audit_file_dest
④ object_cache_optimal_size
⑤ object_cache_max_size_percent
⑥ sort_area_size
⑦ sort_area_retained_size
⑧ olap_page_pool_size
SCOPE에 SPFILE 또는 BOTH를 지정하는 경우, COMMENT 구문을 지정하여 Parameter 변경에 따른
텍스트 문자열을 연관 시킬 수 있다. 주석은 서버 Parameter 파일에 기록된다.
Parameter 값 변경 : 예
그림 4-12
위 그림의 첫 번째 예제는 세션 수준 Parameter를 변경하는 것이다. 사용자는 세션의 날짜 형식을
mon dd yyyy로 변경하였다. 그 결과, 날짜에 대한 모든 쿼리는 날짜를 지정된 형식으로 표시 할 것이다.
또한, 세션 수준 Parameter는 PL/SQL을 사용하여 애플리케이션에서 설정 할 수도 있다.
두 번째 문장은 연결을 제거하기 전에 실패한 로그인 시도 횟수의 최대값을 변경하는 것이다.
여기에는 주석이 포함되었고 변경 사항은 오직 서버 Parameter 파일에만 반영된다. 실패한 로그인
시도가 지정된 횟수를 초과하면 연결은 서버 프로세스에 의해 자동적으로 제거된다. 이 Parameter는
동적 Parameter가 아니며, 이 변경 사항이 반영되려면 오라클 Database Instance를 재 시작
하여야 한다.
퀴즈
EM Database 컨트롤은 맋은 Database를 동시에 관리하기 위해 사용 될 수 있다.
1. True
2. False
퀴즈
대부분의 Database Parameter는 동적이고 Database Instance를 종료하지 않고 변경 할 수 있다.
1. True
2. False
Database 기동과 종료 : 인증
그림 4-13
Startup 또는 Shutdown을 클릭하면 호스트(Database가 설치된 컴퓨터)와 Database에 각각
로그온하기 위한 사용자 계정을 요구한다. 여기서, 반드시 SYSDBA 권한을 가진 Database 사용자
계정을 입력하여야 한다.
인증이 완료되면, 기동 또는 종료 방법이 요청되며, Advanced Options를 클릭하여 필요한 기동 또는
종료 옵션을 선택한다. 또한, 기동 또는 종료에 사용될 SQL 문장을 확인하기 위해 Show SQL을 클릭
할 수도 있다.
참고 : EM을 이용하여 Database를 종료하는 경우, 디폴트 옵션은 IMMEDIATE이다. SQL*Plus에서
SHUTDOWN 명령을 실행하는 경우에는 디폴트 옵션이 NORMAL이다.
오라클 Database Instance 기동
그림 4-14
만약, EM의 Database 컨트롤 페이지로 이동한 경우, Database가 현재 시작되어 있지 않았다면
Startup을 클릭한다. 그 다음, 호스트 계정을 입력하고 필요에 따라 시작 모드를 선택한다. 만약, 오라클
Database가 Oracle Restart에 등록되어 있다면, 별도의 대화상자가 나타나서 Database Instance를
기동하기 위해 SRVCTL(Server Control) 유틸리티를 사용 할 것인지 SQL*Plus를 사용 할 것인지를
결정하도록 요청한다. Oracle Restart는 필요에 따라 의존 자원들을 시작 할 수 있는 능력을 가지고
있기 때문에 Oracle Restart를 사용 중이라면 SRVCTL 유틸리티를 사용하도록 한다.
오라클 Database Instance 시작 : NOMOUNT
그림 4-15
Database Instance를 시작 할 때, 시작할 상태를 선택한다. 다음 시나리오는 Instance 기동의
여러 단계를 설명하고 있다. Database 생성, 컨트롤 파일 재생성, 특정 백업 및 복구 시나리오 진행하는
경우에는 Instance는 보통 NOMOUNT로만 기동시킨다.
Instance를 기동하면 다음과 같은 작업이 수행된다.
- $ORACLE_HOME/dbs에서 다음 순서에 따라 특별한 이름의 파일을 찾는다.
1. spfile<SID>.ora를 찾는다.
2. spfile<SID>.ora가 발견되지 않으면, spfile.ora를 찾는다.
3. spfile.ora가 발견되지 않으면, init<SID>.ora를 찾는다.
이 파일들은 Instance에 대한 초기화 Parameter를 포함하고 있다. STARTUP 명령에서 PFILE Parameter를
지정하여 디폴트 동작 특성을 무시 할 수 있다.
- SGA 할당
- 백그라운드 프로세스 기동
- alert_<SID>.log 파일 및 트레이스 파일 오픈
참고 : SID는 시스템 ID이며, Instance 이름을 식별한다(예를 들어, ORCL).
오라클 Database Instance 시작 : MOUNT
그림 4-16
Database 마운트는 다음과 같은 작업을 포함한다.
- Database를 기동된 Instance에 연관시킨다.
- Parameter 파일에 지정된 모든 컨트롤 파일을 찾아서 오픈한다.
- 데이터 파일과 온라인 리두 로그 파일의 이름과 상태를 얻기 위해 컨트롤 파일을 읽는다
(그러나, 이 단계에서는 데이터 파일과 온라인 리두 로그 파일의 존재 여부를 확인하지는 않는다).
특별한 유지 관리 작업을 수행하려면, Instance를 시작하고 Database를 마운트한 다음, 오픈 하지 않는다.
예를 들어, 다음과 같은 작업을 수행하는 경우에 Database를 오픈하지 않고 마운트한다.
- 데이터 파일 이름 변경(오프라인 테이블스페이스에 대한 데이터 파일들은 Database가 오픈되어 있어도
이름을 변경 할 수 있다.)
- 온라인 리두 로그 파일의 아카이브 옵션 활성 및 비활성화
- 전체 Database 복구 수행
참고 : Database에 대하여 OPEN을 요구했지만 MOUNT 상태가 되는 경우가 발생 할 수 있다. 그 이유는
Database가 어떤 방식으로든 복구되어야 하기 때문이다. 만약, MOUNT 상태에서 복구를 수행한다면
복구에 필요한 블록들을 읽기 위해 리두 로그를 오픈하고 블록을 기록하기 위해 데이터 파일을 오픈 하여야 한다.
오라클 Database Instance 시작 : OPEN
그림 4-17
정상 Database 작업이란 Instance가 기동되고 Database가 마운트되어 오픈되어 있음을 의미한다.
정상 Database 작업에서는 모든 유효 사용자가 Database에 접속하고 전형적인 데이터 액세스 작업을 수행한다.
Database를 오픈 하면 다음과 같은 작업이 수행된다.
- 데이터 파일 오픈
- 온라인 리두 로그 파일 오픈
만약, Database를 오픈 하려고 했을 때, 데이터 파일들 또는 온라인 리두 파일들 중의 어느 하나라도
존재하지 않으면 오라클 서버는 오류를 리턴한다.
이 마지막 단계가 진행되는 동안, 오라클 서버는 모든 데이터 파일들과 온라인 리두 로그 파일들 이 오픈
될 수 있는지 검증하고 Database의 일관성을 체크한다. 필요하다면 SMON(System Monitor)
백그라운드 프로세스가 Instance 복구를 수행한다.
관리 권한을 가진 사용자들만 Database에 접속하도록 하려면 Database Instance를 제한된 모드 (restricted mode)로 시작하면 된다.
Instance를 제한된 모드로 시작하려면 Advanced Startup Options 페이지에서 Restrict access to database 옵션을 선택한다.
시작 옵션 : 예
그림 4-18
위 그림은 Database를 기동하기 위한 SQL*Plus 구문을 보여준다.
1. 이 명령은 Instance를 시작하고, Database 파일들을 Instance에 연관시키고, 마운트 및 오픈한다.
2. 이 명령은 Instance를 시작하고 Database를 마운트하지 않는다.
3. 이 명령은 NOMOUNT 상태에서 Database를 마운트한다.
4. 이 명령은 MOUNT 상태에서 Database를 오픈한다.
Database가 Oracle Restart를 사용하도록 활성화 되어 있으면, srvctl 유틸리티를 사용하여 Database
Instance를 기동 할 수 있다. srvctl 유틸리티는 ASM Instance, ASM 디스크 그룹, 리스너와 같은 모든
필요한 의존 자원도 기동 시킬 수 있는 장점을 가지고 있다.
참고 : srvtl 유틸리티는 Grid Infrastructure 소프트웨어의 $ORACLE_HOME/bin 디렉터리에 저장되어
있고, 오라클 Database 소프트웨어의 $ORACLE_HOME/bin 디렉터리에도 저장되어 있다. 오라클
Database를 시작 할 때는 오라클 Database 소프트웨어의 srvctl 유틸리티를 사용 하여야 한다. ASM
Instance 또는 리스너를 기동 할 때는 Grid Infrastructure 소프트웨어 srvctl 유틸리티를 사용하여야 한다.
오라클 Database Instance 종료
그림 4-19
만약, EM Database 컨트롤 페이지로 이동했을 때, Instance가 이미 기동되어 있다면, Instance를 종료하기
위해 Shutdown 버튼을 클릭한다. 호스트 및 Database 계정을 입력하도록 요구한다. Startup/Shutdown
확인 대화상자에서 OK를 클릭한다. 만약, Advanced Option 버튼을 클릭하면, NORMAL,
TRANSACTIONAL, IMMEDIATE, ABORT의 종료 모드를 선택 할 수 있다.
종료 모드
그림 4-20
종료 모드는 다음과 같이 현재의 세션들을 제한한다.
- ABORT : 종료 전에 최소한의 작업을 수행한다. 이 모드는 다음 번 Database 시작 시 복구를 필요로
하기 때문에 필요한 경우에만 사용하여야 한다. 이 모드는 다른 형태의 종료가 불가능하거나, Instance를
시작 할 때 문제가 발생했거나, 갑작스런 상황으로 즉시 Database를 종료해야 하는 경우(예를 들어,
수초 이내에 정전이 발생한다는 공지)에 보통 사용한다.
- IMMEDIATE : 가장 일반적인 옵션이다. 커밋되지 않은 트랜잭션은 롤백된다.
- TRANSACTIONAL : 기존 트랜잭션이 종료될 때까지 대기한다. 그러나, 새로운 트랜잭션은 시작 할 수 없다.
- NORMAL : 세션이 접속을 끊을 때까지 대기한다.
만약, Database를 종료하는데 소요되는 시간을 고려해야 한다면, ABORT가 가장 빠르고 NORMAL이 가장
느리다. NORMAL과 TRANSACTIONAL은 세션 및 트랜잭션의 수에 따라 소요되는 시간이 길어질 수 있다.
종료 옵션
SHUTDOWN NORMAL
NORMAL은 아무런 모드가 지정되지 않았을 때 사용되는 디폴트 종료 모드이다. 이 모드의 Database의 종료는
다음과 같은 조건하에서 진행된다.
① 새로운 접속은 허용되지 않는다.
② Database 종료를 완료하기 전에 모든 사용자가 접속을 해제 할 때까지 오라클 서버는 대기한다.
③ Database와 리두 버퍼는 디스크에 기록된다.
④ 백그라운드 프로세스는 종료되고 SGA는 메모리에서 제거된다.
⑤ 오라클 서버는 닫히고 Instance를 종료하기 젂에 Database를 마운트 해제 한다.
⑥ 다음 번 Database 기동시에는 Instance 복구를 필요로 하지 않는다.
SHUTDOWN TRANSACTIONAL
TRANSACTIONAL 모드의 종료는 클라이언트가 현재 활동의 결과를 포함하는 데이터를 잃어버리지 않는다.
이 모드의 Database 종료는 다음과 같은 조건하에서 진행된다.
① 클라이언트의 새로운 트랜잭션을 시작 할 수 없다.
② 클라이언트가 트랜잭션을 종료하면, 클라이언트의 접속이 해제된다.
③ 모든 트랜잭션이 완료되면, Database 종료가 즉시 진행된다.
④ 다음 번 Database 기동시에는 Instance 복구를 필요로 하지 않는다.
SHUTDOWN IMMEDIATE
IMMEDIATE 모드의 Database 종료는 다음과 같은 조건하에서 진행된다.
① 오라클 Database에 의해 처리 중인 현재의 SQL 문장들은 완료되지 않는다.
② 오라클 서버는 현재 접속된 사용자가 접속을 해제 할 때까지 대기하지 않는다.
③ 오라클 서버는 활성화 된 트랜잭션을 롤백하고 모든 접속된 사용자의 연결을 해제한다.
④ 다음 번 Database 기동 시에 Instance 복구를 필요로 하지 않는다.
참고 : IMMEDIATE는 EM을 사용하는 경우, 디폴트 종료 모드이다. SHUTDOWN ABORT
만약, NORMAL, TRANSACTIONAL, IMMEDIATE 모드가 동작하지 않는다면, 이 모드를 사용하여 현재
Database Instance를 종료 시킬 수 있다.
이 모드의 Database 종료는 다음과 같은 조건하에서 진행된다.
① 오라클 서버에 의해 처리중인 현재의 SQL 문장들은 즉시 종료된다.
② 오라클 서버는 현재 Database에 접속되어 있는 사용자가 연결을 해제 할 때까지 대기하지 않는다.
③ Database와 리두 버퍼는 디스크에 기록되지 않는다.
④ 커밋되지 않는 트랜잭션은 롤백되지 않는다.
⑤ 해당 파일을 닫지 않고 Instance를 종료한다.
⑥ Database는 닫히지 않고, 마운트가 해제 되지 않는다.
⑦ 다음 번 Database 기동시 Instance 복구가 필요하며 자동적으로 수행된다.
참고 : 이 모드로 Database가 종료되면, 해당 Database는 일관성이 없는 상태(inconsistent state)이므로
이 상태의 Database를 백업하는 것은 권장하지 않는다.
종료 옵션 : 예
그림 4-21
위 그림의 예제는 Database를 종료하기 위해 SQL*Plus와 SRVCTL 유틸리티를 사용하는 방법이다.
1. 이 명령은 NORMAL 모드의 종료를 시작한다. Database는 모든 사용자가 로그 아웃 할 때까지
종료 작업을 진행하지 않는다.
2. 이 명령은 TRANSACTIONAL 모드의 종료를 시작한다. Database는 모든 기존의 트랜잭션이 완료될
때까지 종료 작업을 진행하지 않는다.
3. 이 명령은 IMMEDIATE 모드의 종료를 시작한다. 커밋되지 않는 트랜잭션은 롤백된다.
4. 이 명령은 ABORT 모드의 종료를 시작한다.
Database가 Oracle Restart를 사용 할 수 있도록 활성화 되어 있다면, SRVCTL 유틸리티를 사용하여
Database Instance를 종료 할 수 있다.
참고 : srvctl 유틸리티는 Grid Infrastructure 소프트웨어의 $ORACLE_HOME/bin 디렉터리에 저장되어
있고, 오라클 Database 소프트웨어의 $ORACLE_HOME/bin 디렉터리에도 저장되어 있다. 오라클
Database를 시작 할 때는 오라클 Database 소프트웨어의 srvctl 유틸리티를 사용하여야 한다. ASM
Instance 또는 리스너를 기동 할 때는 Grid Infrastructure 소프트웨어 srvctl 유틸리티를 사용하여야 한다.
경보 로그 확인
그림 4-22
각 Database는 alert_<sid>.log 파일을 가지고 있다. 이 파일은 Database가 설치된 서버에 저장되어
있으며, $ORACLE_BASE가 설정되어 있으면 기본적으로
$ORACLE_BASE/diag/rdbms/<db_name>/<SID>/trace에 위치한다.
Database의 경보 파일은 다음과 같이 메시지가 시갂 순으로 기록되어 있다.
① 기동 시에 사용된 디폴트가 아닌 초기화 Parameter
② 발생 된 모든 내부 오류(ORA-600), 블록 소손 오류(ORA-1578), 데드락 오류(ORA-60)
③ CREATE, ALTER, DROP DATABASE 또는 TABLESPACE와 같은 관리 작업, EM 또는 STARTUP, SHUTDOWN, ARCHIVE LOG, RECOVER와 같은 SQL*Plus 문장
④ 공유 서버 및 디스패처 프로세스의 기능과 관련된 여러 메시지 및 오류들
오라클 Database는 운영자의 콘솔에 이러한 정보를 표시하는 대신, 이러한 이벤트의 기록을 유지하기
위해 경보 로그를 사용한다(많은 시스템들이 콘솔에 이러한 정보를 표시하기도 한다). 만약, 관리 작업이
성공적으로 완료되면, 해당 완료 시간과 함께 “completed”라는 메시지가 경보 로그에 기록된다.
EM은 경보 로그를 모니터링하고 치명적인 오류는 사용자에게 통보한다. 또한, 치명적이지 않은 오류와
정보 메시지를 확인하기 위해 경보 로그를 확인 할 수도 있다. 이 파일은 관리가 불가능 할 정도로
용량이 늘어나기 때문에 경보 로그를 주기적으로 백업하고, 현재의 경보 파일을 삭제하여야 한다.
Database가 경보 파일을 다시 기록하기 위해 시도하면 새로운 파일을 다시 생성한다.
참고 : 경보 로그의 XML 버전은 $ORACLE_BASE/diag/rdbms/<db_name>/<SID>/alert 디렉터리에 저장된다.
SQL*Plus에서 경보 로그의 위치를 확인하는 방법
① Database에 SQL*Plus로 접속한다(SQL Developer와 같은 쿼리 도구를 사용 할 수도 있음).
② V$DIAG_INFO 뷰를 쿼리한다.
XML 태그 없이 경보 로그의 텍스트만 보는 방법
① V$DIAG_INFO 쿼리 결과에서 Diag Trace 엔트리에 해당하는 경로를 확인한다. 해당 경로의 디렉터리로 이동한다.
② alert_SID.log 파일을 텍스트 편집기로 오픈한다.
XML 형식의 경보 로그를 확인하는 방법
① V$DIAG_INFO 쿼리 결과에서 Diag Alert 엔트리에 해당하는 경로를 확인한다. 해당 경로의 디렉터리로 이동한다.
② log.xml 파일을 텍스트 편집기로 오픈한다.
Trace 파일 사용
각 서버와 백그라운드 프로세스는 관련 Trace 파일에 기록이 가능하다. 프로세스가 내부 오류를
감지하면, 해당 오류에 대한 정보를 Trace 파일에 덤프한다. 만약, 내부 오류가 발생하고 Trace
파일에 해당 정보가 기록되면, 관리자는 Oracle Support Services에 연락하여야 한다.
백그라운드 프로세스와 연관된 Trace 파일들의 파일명은 Trace 파일을 발생시킨 프로세스의
이름을 포함한다. 유일한 예외는 job queue 프로세스(Jnnn)에 의해 작성된 Trace 파일이다.
Trace 파일 내의 추가 정보는 애플리케이션 또는 Instance 튜닝에 대한 지침을 제공 할 수 있다.
필요하다면 백그라운드 프로세스는 언제나 이런 정보를 Trace 파일에 기록한다.
Oracle Database 11g부터 문제점들을 방지, 감지, 분석, 해결하기 위해 향상된 장애 분석 인프라
(advanced fault diagnosability infrastructure)가 포함되었다. 특별히 이러한 대상이 되는 문제점들에는
Database 코드 버그, Meta data 소손, 고객 데이터 소손과 같은 치명적인 오류가 포함된다. 치명적인
오류가 발생하면, 해당 오류에 대하여 사고 번호가 부여된다. 즉, 해당 오류에 대한 분석 데이터(Trace
파일과 같은)가 즉시 수집되고, 사고 번호가 부여된다. 그 다음, 해당 데이터 는 Database 외부의 파일
기반 Repository ADR(Automatic Diagnostic Repository)에 저장되며, 나중에 사고 번호에 의해 검색 및
분석 될 수 있다. ADR은 Trace, 경보 로그, Database 상태 모니터 리포트 등과 같은 Database 진단
데이터를 위해 시스템 전체에서 Trace 및 기록되는 중앙 Repository이다.
ADR 루트 디렉터리는 ADR base라고 알려져 있다. 이 위치는 DIAGNOSTIC_DEST 초기화 Parameter에
의해 설정된다. 만약, 이 Parameter를 생략하거나 null로 남겨두면, Database가 기동 될 때, 다음과 같은
순서로 DIAGNOSTIC_DEST를 설정한다.
① 만약, ORACLE_BASE 환경 변수가 설정되면, DIAGNOSTIC_DEST에는 ORACLE_BASE에 지정된 디렉터리가 설정된다.
② 만약, ORACLE_BASE 환경 변수가 설정되지 않으면, DIAGNOSTIC_DEST에는 ORACLE_ HOME/log에 지정된 디렉터리가 설정된다.
ADR 홈의 위치는 다음과 같이 설정되며, ADR base 디렉터리로 Database가 기동된다.
/diag/product_type/db_id/instance_id
동적 성능 뷰
그림 4-23
오라클 Database는 Database Instance의 작업과 성능에 관련된 데이터의 많은 동적인 집합을 유지
관리한다. 이러한 동적 성능 뷰들은 Database 서버 내부의 메모리 구조에 구축된 가상 테이블을
기반으로 한다. 즉, 이러한 가상 테이블들은 Database에 저장되지 않는다. 그러므로, 이러한 가상
테이블들의 일부는 Database가 마운트 또는 오픈 되기 전까지는 사용 할 수 없다.
동적 성능 뷰는 다음과 같은 정보를 포함한다.
① 세션
② 파일 상태
③ 작업 및 태스크의 진행
④ 잠금
⑤ 백업 상태
⑥ 메모리 사용량 및 할당
⑦ 시스템 및 세션 Parameter
⑧ SQL 실행
⑨ 통계 및 메트릭
참고 : DICT 및 DICT_COLUMNS 뷰는 이러한 동적 성능 뷰의 이름을 포함하고 있다. 동적 성능 뷰는
접두사 v$로 시작되며 590개 이상이 존재한다.
동적 성능 뷰 : 사용 예
그림 4-24
이 뷰의 주된 사용자는 EM이지만, 사용자들도 필요에 따라 이러한 뷰를 검색 할 수 있다.
위 그림의 세가지 예제는 다음과 같은 질의에 대한 결과를 보여준다.
1. CPU 시간을 200,000 마이크로초 이상 소비하는 SQL 문장과 해당 문장의 실행 횟수는?
2. 어제 이후부터 EDRSR9P1 컴퓨터에 로그인한 현재 세션은?
3. 현재 다른 세션을 블록킹 중인 잠금을 소유한 세션의 ID와 이 잠금이 얼마나 오랫동안 지속되고 있는가?
동적 성능 뷰 : 고려 사항
일부 동적 뷰는 Instance 또는 Database의 모든 상태를 포함하지 않는다. 예를 들어, Instance가
시작되었지만 Database가 마운트되어 있지 않다면, V$BGPROCESS를 쿼리하여 현재 실행 중인
백그라운드 프로세스의 목록을 확인 할 수 있다. 그러나, V$DATAFILE을 쿼리해서는 Database 데이터
파일들의 상태를 확인 할 수는 없는데, 그 이유는 Database를 마운트하는 것은 컨트롤 파일에서 해당
Database와 관련된 데이터 파일에 대한 정보만 검색하기 때문이다.
일부 V$ 뷰는 DBA_ 뷰의 정보와 유사한 정보를 포함한다. 예를 들어, V$DATAFILE은 DBA_DATA_FILES와
유사하다. 또한, V$ 뷰 이름은 일반적으로 단수형이고, DBA_ 뷰 이름은 복수형이다.
데이터 딕셔너리 : 개요
그림 4-25
오라클 데이터 딕셔너리는 Database의 메타 데이터이며, 해당 Database 내의 모든 객체들에 대한
이름과 속성을 포함하고 있다. 임의 객체에 대한 생성 또는 수정은 해당 변경을 반영하기 위한 데이터
딕셔너리의 갱신을 유발시킨다. 이러한 정보는 오라클 Database에 의해 유지 관리되는 기본 테이블에
저장되지만, 이러한 기본 테이블을 직접 읽는 대신 사전에 정의된 뷰를 이용하여 이러한 테이블에
액세스한다.
데이터 딕셔너리의 특징은 다음과 같다.
① 데이터 딕셔너리는 사용자, 객체, 제약조건, 저장 장소와 관련된 정보를 검색하기 위해 오라클 Database에 의해 사용된다.
② 데이터 딕셔너리는 객체 구조 또는 정의가 변경되면, 오라클 Database 서버에 의해 유지 관리된다.
③ 데이터 딕셔너리는 Database에 관련된 정보를 검색하는 모든 사용자들에 의해 사용 가능하다.
④ 데이터 딕셔너리는 SYS 사용자가 소유한다.
⑤ SQL을 이용하여 절대 직접 변경될 수 없다.
참고 : DICTIONARY 데이터 딕셔너리 뷰(또는 DICT 동의어)는 데이터 딕셔너리 테이블과 뷰에 대한 이름
및 설명을 포함한다. 뷰의 컬럼과 정의를 확인하기 위해 DICT_COLUMNS 뷰를 사용 할 수 있다. 각 뷰에
대한 완전한 정의는 오라클 Database 레퍼런스를 확인해야 하며, 수 백개의 베이스 테이블을 참조하는 1000개 이상의 뷰가 존재한다.
데이터 딕셔너리 뷰
그림 4-26
뷰의 접두사는 주어진 사용자가 접근 할 수 있는 데이터를 의미한다. 모든 것들에 대한 전역 뷰는 DBA_
접두사를 사용하며, DBA 권한을 가진 사용자들만 액세스 할 수 있다. 다음 수준의 권한은 ALL_
접두사이며, 쿼리하는 사용자가 검색 할 수 있도록 권한을 부여 받은 모든 객체를 의미한다. 여기서, 해당
객체의 사용자 소유 여부는 상관 없다. 예를 들어, USER_A가 USER_B가 소유한 테이블에 액세스 할 수
있는 권한을 부여 받았다면, USER_A는 모든 ALL_ 뷰에 서 해당 테이블의 이름을 확인 할 수 있다. USER_
접두사는 가장 작은 범위의 가시성을 나타낸다. 이 유형의 뷰는 자신이 소유한 객체들만 볼 수 있다(즉,
사용자 소유의 스키마에 존재하는 객체들만). 일반적으로 각 뷰 집합은 더 상위의 권한을 갖는 뷰 집합의
부분집합이다. 모든 뷰가 위의 모든 접두사를 갖는 뷰를 제공하는 것은 아니며, 뷰 내의 정보에 따라
달라진다. 예를 들어, DBA_LOCK 뷰는 ALL_LOCK 뷰가 존재하지 않는다. 사용자가 필요로 하는 적절한
뷰를 선택하여야 한다. 만약, DBA 뷰에 액세스 할 수 있는 권한을 부여 받았더라도, USER 버전의 뷰만을
검색할 필요가 있다. 그 이유는 해당 결과에 자신이 소유한 객체에 대한 정보만을 표시하고, 다른 객체는
결과에 포함 시키고 싶지 않은 경우가 있기 때문이다. SYSDBA 또는 SELECT ANY DICTIONARY 권한을
가진 사용자는 DBA_ 뷰를 검색 할 수 있다. 모든 딕셔너리 뷰가 DBA_, ALL_, USER_ 접두사로 시작하지는
않는다. 다음 뷰 또는 뷰에 대한 동의어는 이러한 예외를 보여준다.
1. AUDIT_ACTIONS
2. CAT
3. CHANGE_PROPAGATIONS
4. CHANGE_PROPAGATION_SETS
5. CHANGE_SETS
6. CHANGE_SOURCES
7. CHANGE_TABLES
8. CLIENT_RESULT_CACHE_STATS$
9. CLU
10. COLS
11. COLUMN_PRIVILEGES
12. DATABASE_COMPATIBLE_LEVEL
13. DBMS_ALERT_INFO
14. DBMS_LOCK_ALLOCATED
15. DICT
16. DICTIONARY
17. DICT_COLUMNS
18. DUAL
19. GLOBAL_NAME
20. IND
21. INDEX_HISTOGRAM
22. INDEX_STATS
23. LOGSTDBY_UNSUPPORTED_TABLES
24. NLS_DATABASE_PARAMETERS
25. NLS_INSTANCE_PARAMETERS
26. NLS_SESSION_PARAMETERS
27. OBJ
28. RECYCLEBIN
29. RESOURCE_COST
30. ROLE_ROLE_PRIVS
31. ROLE_SYS_PRIVS
32. ROLE_TAB_PRIVS
33. SEQ
34. SESSION_PRIVS
35. SESSION_ROLES
36. SM$VERSION
37. SYN
38. TABLE_PRIVILEGES
39. TABS
데이터 딕셔너리 : 사용 예
그림 4-27
예제의 쿼리는 다음과 같은 질의에 대한 결과를 보여준다.
1. 자신의 스키마에 생성된 테이블의 이름(테이블이 저장된 테이블스페이스 이름도 함께)은 무엇인가?
2. 사용자가 접근 할 수 있는 Database 내의 시퀀스에 대한 주요 정보는 무엇인가?
3. 이 Database에 현재 로그인 할 수 있는 사용자는 누구인가?
4. DBA_INDEXES 뷰의 컬럼은 무엇인가? Database 내의 모든 인덱스에 대하여 볼 수 있는 정보가
무엇인지를 보여준다.
다음은 이 명령의 결과 일부이다.
SQL> DESCRIBE dba_indexes
Name Null? Type
--------------- -------- ------------
OWNER NOT NULL VARCHAR2(30)
INDEX_NAME NOT NULL VARCHAR2(30)
INDEX_TYPE VARCHAR2(27)
TABLE_OWNER NOT NULL VARCHAR2(30)
TABLE_NAME NOT NULL VARCHAR2(30)
퀴즈
Oracle Restart를 사용하는 경우, Database Instance를 기동 및 종료하기 위해 반드시 srvctl 유틸리티를 사용하여야 한다.
1. True
2. False
퀴즈
Database 내 모든 테이블의 이름을 검색하는데 사용 할 수 있는 데이터 딕셔너리 뷰는 무엇 인가?
1. USER_TABLES
2. ALL_TABLES
3. DBA_TABLES
4. ANY_TABLES
'oracle11R2 > Workshop I' 카테고리의 다른 글
| 05장. Configuring the Oracle Network Environment (0) | 2011.07.16 |
|---|---|
| Oracle Database 11g：Administration Workshop I (0) | 2011.07.09 |
| 03장. DBCA를 이용한 오라클 데이터베이스 생성 (0) | 2011.06.26 |
| 02장. 오라클 소프트웨어 설치 (0) | 2011.06.24 |
| 01장. 오라클 데이터베이스 아키텍처 (0) | 2011.06.24 |
