오라클 OCP 오라클자격증 OCP자격증 데이터베이스 DB 데이터베이스관리자 DB관리자 오라클학원 OCP학원 오라클 OCP 오라클자격증 OCP자격증 데이터베이스 DB 데이터베이스관리자 DB관리자 오라클학원 OCP학원 오라클 OCP 오라클자격증 OCP자격증 데이터베이스 DB 데이터베이스관리자 DB관리자 오라클학원 OCP학원 오라클 OCP 오라클자격증 OCP자격증 데이터베이스 DB 데이터베이스관리자 DB관리자 오라클학원 OCP학원오라클 OCP 오라클자격증 OCP자격증 데이터베이스 DB 데이터베이스관리자 DB관리자 오라클학원 OCP학원 오라클 OCP 오라클자격증 OCP자격증 데이터베이스 DB 데이터베이스관리자 DB관리자 오라클학원 OCP학원 오라클 OCP 오라클자격증 OCP자격증 데이터베이스 DB 데이터베이스관리자 DB관리자 오라클학원 OCP학원
제1장. 오라클 구조의 구성요소
1-3.목적 - 오라클 서버에 접속하는데 관련된 구조
- 질의문 처리 단계의 파악
- DML명령문 처리 단계 파악
- COMMIT처리 단계 파악
1-4.오라클 서버
1-6.데이타베이스에 접속 : host에 직접 접속, two-tierd접속, three-tired 접속
1-8.사용자 프로세스(User Process)
1-9.서버프로세스 (Server Process) : user process의 요구를 받아서 모든 작업을 한다.
: parsing, execute, fetch
1-10.오라클 인스탄스- Oralce Instance
-SGA
1) Shared Pool
(1) Shared SQL Areas
(2) Data Dictionary Cache
2) Database Buffer Cache
3)Redo Log Buffer
-백그라운드 프로세스
1) SMON : system monitor, system전반에 대한 것
(1) instance recovery : instance(SGA, BackGround 을 합한것)
(2) 더이상 사용되지 않는 temporary segment를 회수
* temporary segment는 자동적으로 사용
(3) data file의 구멍난 부분을 merge해줌
2) PMON(Process Monitor)
(1) clean up
(2) commit되지 않는 transaction을 rollback
(3) user와 관련된 작업
(4) 비정상적인 종료를 control
3) DBWR : DB Buffer Cache의 내용을 DB File에 쓴다
4) LWGR : Redo Log Buffer의 내용을 쓴다
5) CKPT
6) ARCH
7) RECO
8) SNP
* User process, Server process는 Background process에 들어가지 않는다.
1-12.오라클 데이타베이스
논리적 구조 : Database-->Table Space-->Segment-->Extent-->Block 까지의 구조
물리적 구조
.데이타파일 : select * from v$datafile;, 1개 이상
.리두로그 파일 : v$logfile, 순전히 recorvery를 위해서 필요로한다, 반드시 2개이상있어야 한다.
--> 오직 변경되는 내용만 들어간다(select문은 변경이 아니므로 기록이 안된다)
.콘트롤 파일
1) DB에 대한 물리적 구조의 정보가 들어간다
2) DB의 상태정보
3) 동기화정보
4) 1개이상
1-13.그 밖의 물리적 구조
-파라메타 파일
1) 각 영역의 size를 지정
2) initDBA01.ora
3) oracle instace에 대한 셋팅정보
-패스워드 파일
-아카이브 로그 파일(off line redo log file)
1-14.질의 문의 처리 과정
1.구문분석(Parsing)
: server process에서 user process가 던진 문장을 분석
1) syntex체크
2) semantics 체크
(1) object 유무 체크
(2) privilege 체크(권한)
(3) excution plan(실행계획)(=parsed tree) --> 옵티마이저(optimizer)가 계획을 결정
a) rule-based optimizer : 내부의 규칙에 의해서 결정
b) cost-based optimizer
2.실행(Exctution)
3.인출(Fetch) : user process에게 resultset을 출력해준다
* DML문인경우는 Fetch까지 가지 않고 Execution에서 끝이 난다.
1-15.공유풀(Shared Pool)
.SHEARED_POOL_SIZE
.라이브러리 케쉬 : 명령문, text, 구문분석 코드, 실행계획
.데이타 딕셔너리 케쉬 : 테이블과 컬럼명의 정의 사용 권한등
1-17.데이터베이스 버퍼케쉬(Database Buffer Cache)
.DB_BLOCK_SIZE : 크기
.DB_BLOCK_BUSSERS : 갯수
.Cache Miss
.Cache Hit
* 매우중요....
.LRU(Least Recently Used) 알고리즘 : 최근에 사용된 블럭을 유지 하기 하기 위해, 오래된것을 제거
--> cache hit가 자주 일어나게 한다
-LRU list
: select문장을 사용할때
1) pinned buffer
2) free buffer :비어있는 버퍼
3) dirty buffer : DB file에 Write 되지 않은 버퍼
-Dirty list : dirty buffer를 유지(DBWR)
1-18.PGA(Program Global Area) : 개개인이 사용하는 영역, SGA와 별도의 영역
.공유하여 기록 할 수 없습니다.
.다음과 같은 정보를 갖습니다
-스텍공간(Stack Space) : array가 들어감
-세션정보(User Session Data) : 사용자의 session정보
* session
* schema
* user
-커저상태(Cursor State) : resultset에 point를 준다
-정렬 영역(Sort Area)
주-MTS구성을 사용할 때는 이러한 구조중 일부가 SGA에 저장 됩니다.
* server를 구성하는 방법
1) conbined user/server process : VMS 에서
2) dedicated server configue : 100명이 접속하면 server도 100개가 생성, 메모리 낭비가 심하다
3) multi threaded server(MTS) : 한개의 server process에 여러 user가 접속
1-19.DML문장의 실행 : commit을 해야만 다른 user가 확인이 가능하다
DML(Data Manipulation Language)문은 두 단계의 처리 과정이 필요합니다
.구문분석
.실행
처리 과정(update문)-->매우중요
1.버퍼 케쉬에 Data block과 Rollback Block을 확보
2.블럭의 사본이 버퍼케쉬에 위치됩니다.
3.서버프로세스는 데이타에 Lock을 겁니다(ERL)
4.서버프로세스는 롤백블럭과 데이터 블럭에 가해긴 변경사항을 리두로그에 기록합니다.
: 리두로그 엔트리
5.서버프로세스는 데이타베이스 버퍼케쉬에서 이전 이미지(before image)를 롤랙블럭에 기록한후
데이타블록을 변경합니다. 버퍼케쉬 내의 변경된 두 블럭은 Dirty Buffer즉, 디스크의 해당 블럭과
같지 않은 버퍼로 Mark됩니다.
: commit하기전까지..
: commit을 하게되면 free buffer가 된다
주-DELETE나 INSERT명령처리도 유사한 단계를 거칩니다. DELETE의 경우 이전 이미지는 삭제된 행의
컬럼 값을 포함 하는 반면 INSERT는 록백에 행위치 정보만을 포함 합니다.
1-21.롤백(ROLLBACK)세그먼트 : 매우중요
.변경하기 전에 서버프로세스는 변경전의 값을 롤백세그 먼트에 저장합니다
: before image를 유지하는 것
.롤백세그먼트에 저장된 이미지는 다음 경우에 사용됩니다.
-트렌젝션에 롤백되어 변경 사항을 취소(UNDO)할떼
-다른 트렌젝션이 DML문에 의한 커밋 되지 않은 변경사항을 알지 못하 도록 할때(읽기 일관성)
-실패한 경우 데이타베이스를 일관성 있는 상태로 복구 할때
.테이블과 인덱스 처럼 롤백세그먼트도 데이타 파일에 존제하며 그 일부는 필요할때
데이타베이스 버퍼 케쉬로 불리워 집니다.
* RollBack Segment 의 기능
1) rollback 기능
2) recovery 기능
3) read consistancy 기능(읽기 일관성)
1-22.리두 로그 버퍼(Redo Log Buffer)
.LOG_BUFFER : size 결정
.순차적으로 사용됩니다.
.변경이 일어나면 저장됨
.컴밋하지 않았는데 다차면 overwrite --> 1/3 정도만 차도 자동적으로 write한다
1-23.DBWR(Database Writer)
.서버프로세스는 버퍼케쉬내의 롤백과 데아타 블록에 변경 사항을 기록합니다.
.DBWR은 데이타베이스 버퍼케쉬로 부터 데이타파일로 더티버퍼(Dirty Buffer)를 옮겨
적습니다.
.DBWR은 다음 이벤트중 하나가 발생할때 까지 데이타 파일 로 옮겨 적는 것을 지연 시키기 때문에
데이타 베이스 성능을 향상 시킵니다.
1) 더티버퍼 수가 임계값에 도달 했을때
2) 프로세스가 지정된 갯수의 브록을 스켄하고도 Free Buffer를 하나도 발견하지 못했을때
3) 시간이 초과 했을때 --> 3초동안 작업이 중단될때
4) DBWR 체크포인트가 데이이타베이스를 닫는 동안 등의 다양한 이벤트에 의해 발생될 수
있을때(체크포인트는 데이타베이스 버퍼케쉬와 데이타파일을 동기화 하는 방법 입니다)
* 주의 : 체크포인트가 발생시에는 LRU list뿐만아니라 Dirty list의 것도 Write한다
* 1,2,3은 Dirty buffer의 내용만 내리지만 4의 경우에는 LRU, Dirty list도 내린다
1-24.LGWR(Log Writer)
.LGWR(Log Writer)는 리두로그 버퍼로 부터 리두 로그 파일로 엔트리를 옮겨 적는 백그라운드
프로세스 입니다. LGWR은 다음과 같은 상황이 되면 리두로그 파일로 순차적으로 옮겨 적습니다.
1) 리두로그 버퍼의 1/3이 찼을때
2) 시간이 초과 됐을때(매 3초마다)
3) DBWR이 데이타베이스 버퍼케쉬에서 수정된 블럭을 데이터파일에 옮겨 적기 전에
4) 트렌젯션이 커밋 될때(commit operation)
1-25.COMMIT처리 과정
.오라클은 빠른 커멋(Fast Commit)을 사용하여 실패했을 경우에도 커밋된 변경사항을 복구
할 수 있도록 보장 합니다.
* Fast Commit : 여러 user의 commit정보를 한꺼번에 작업하는 것
* On Line Redo Log File에는 Commit되지 않은 정보도 들어간다.
.System Commit Number(일종에 시간값)
트렌제션이 커밋 될때마다 Oracle 서버는 Transaction에 커밋 SCN을 지정합니다. SCN은 데이타베이스
내에서 유일한 값이며 증가 합니다. SCN은 데이타가 데이타파이로 부터 읽혀질때 데이타를
동기화 하고 읽기 일관성(Read Consistency)을 제공 할 수 있도록 오라크 서버가 'Time stamo'로
사용합니다, SCN을 사용함으로 서 Oracle 서버는 운영체제의 날짜나. 시간에 의존하지 않고 일관성
Check를 수행 할 수 있습니다.
.COMMIT처리 단계
커밋이 실행되면 다음 단계로 수행 됩니다.
1.서버프로세스는 SCN과 함께 커밋 기록을 리두로그 버퍼에 위치 시킵니다.
2.LGWR은 모든 Redo Log Buffer 엔트리와 커밋기록을 로그 파일에 연속적으로 옮겨 적습니다
이 후 Oracle 서버는 실패하는 경우에도 변경 사항을 잃지 않게 됩니다,
3.사용자에게 COMMIT이 완료 되었다는 것을 알립니다.
--> log file에 기록했다는 의미이지 data file에 기록했다는 의미는 아니다.
* instance 복구(recovery) : SMON이 자동적으로 한다.
--> on line redo log file에는 기록이 되었으나 data file에 기록이 않되었을때 SMON이 복구를 한다.
제2장 관리 도구 : Tool
2-3.목적-Server Manager Line Mode사용
-Oracle Enterprise Manager(OEN)에서 제공하는 관리 응용프로그램
-Oracle Enterprise Manager의 구성 요소 사용
2-4.데이타베이스 관리도구 의 예
Server Manager Line Mode : SQL의 모든 작업
-->startup, shutdown
-Screen mode : mouse를 사용해서 작업
Oracle Enterprise Manager
--> window NT에서 사용
SQL*Loader : 다른 환경에서 만든 text file을 가져올때
Export, Import! 유티리티 : Backup 및 Recovery
Password file 유티리티
2-5.라인모드로 Server Manager 시작
UNIX svrmgrl
NT svrmgr30
-스크립트의 시작및 실행:
UNIX svrmgrl command=@credb.sql
svrmgrl command='CONNECT scott/tiger"
NT svrmgr30 command=@u16run.sql
2-7.Server manager명령 입력
SVRMGR>DESCRIBE \
2> scott.emp;
제 3장 오라클 인스탄스 관리
3-3.목적-운영체제와 패스 워드 파일 인증 설정
-파라메타 파일 생성
-인스탄스의 시작과 데이타베이스 오픈
-데이타베이스 종료및 인스탄트 종료
-파라메타 값 알기와 설정
-세션 관리
-ALERT!와 추적(Trace)파일 모니터링
* 인증방법
1) OS에서 인증
2) passward file에서 인증
3-4.개요
3-5.데이타베이스 관리자
두데이타베이스 관리자 SYS와 SYSTEM은
자동적으로 생성되며
DBA 롤을 부여 받습니다.
3-6.SYS와 SYATEM사용자
- SYS
암호 :change_on_install
데이터베이스 데이터 딕셔너리 소유자
-SYSTEM
암호 :manager
오라클 도구에서 사용하는 추가 내부 테이블의 소유자
3-8.인증 방식
-OS 인증
REMOTE_LOGIN_PASSWORDFILE을 NONE으로 설정 : default
CONNECT / AS SYSDBA(role), CONNECT / AS SYSOPER(role)
--> connect internal 과 같다
dba라는 UNIX 그룹의 멤버여야 함.
-Passwd File 인증
REMOTE_LOGIN_PASSWORDFILE을 EXCLUSIVE 또는 SHARED 로 설정
생성
%orapwd file = $ORACLE_HOME/dbs/orapwU15 password=admin entries=5
--> U15 (Oracle SID)
CONNECT INTERNAL / ADMIN
* entries=5 --> password file에 등록시킬 사용자 수
3-15.초기화 파라메타 파일
-Unix: $ORACLE_HOME/dbs
NT : %ORACLE_HOME%\database에 있음
-파라메타 파일은 인스탄스가 시작될때 만 읽혀 집니다. 파일이 수정되면
새 파라메타 값이 유효하도록 인스탄스를 종료하고 재시작 해야 합니다.
-반드시 지정해야 하는 파라메타
BACKGROUND_DUMP_DEST
COMPATIBLE
CONTROL_FILES
DB_BLOCK_BUFFERS
DB_NAME
SHARED_POOL_SIZE
USER_DUMP_DEST
3-19.일반적으로 수정 되는 파라메타
IFILE
LOG_BUFFER
MAX_DUMP_FILE_SIZE
PROCESSES
SQL_TRACE
TIMED_STATISTICS
3-20.시작과 종료 단계
3-23.STARTUP명령
1) init~.ora 파일을 읽어들인다(NOMOUNT)
2) control file 을 읽어들인다(MOUNT)
3) data file 을 연다(OPEN)
STARTUP PFILE=/disk1/initD15.ora --> parameter file의 위치를 가르쳐준다
STARTUP [FORCE] [RESTRICT] [PFILE=filename]
[EXCLUSIVE | PARALLEL | SHARED] --> DB에 여러개의 instance를 둘때(default : shared)
[ OPEN [RECOVER] [database] --> DB 복구
| MOUNT
| NOMOUNT ]
* OPS (Oracle Parallel System) : 하나의 DB에 여러개의 instance를 가진다
* default : STARTUP OPEN
* select * from v$option;
데이타베이스 사용 가능성 변경
ALTER DATABASE { MOUNT | OPEN }
3-26.종료 옵션
SHUTDOWN [NORMAL | TRANSACTIONAL | IMMEDIATE | ABORT]
* normal : default
-->
* transactional : oracle8
* immediate :
* abort :
3-31.동적 성능 뷰(Dynamic Performance Views)
- v$ 가 붙어있는 모든것(data dictionary)
- 오라클 서버에 의해 관리되며 계속 갱신 됩니다
- 디스크와 메모리 구조에 데이타를 저장합니다.
- 성능을 향상시키는데 유용한 데이타를 포함하고 있습니다
- 접두어 V$로 시작하는 동의어어를 가지고 있습니다.
주:V$FIXED_TABLE은 모든 동적 성능 뷰를 보여 줍니다.
X$ tables ---> v$ views
* view는 table이 있어야 한다
* NOMOUNT 상태에서 볼수 있는것 : select * from v$sga;
select * from v$parameter; select * from v$process;
* v$가 않붙는것 : data dictionary ( all_users, DBA_user, user_users )
3-32.동적성능뷰(Dynamic Performance Views)접근
3-33.예
SGA <---- V$PARAMETER
V$SGA
V$OPTION
V$PROCESS
V$SESSION
V$VERSION
V$INSTANCE
콘트롤파일<-V$THREAD : redo log file 정보 --> 최소한 MOUNT 단계에 있어야함
V$CONTROLFILE
V$DATABASE
V$DATAFILE
V$DATAFILE_HEADER
V$LOGFILE
3-36.파라메타의 동적 초기화
- 일부 초기화 파라메터 값은 인스탄스 실행 중에 수정 될 수 있습니다.
- DB를 내릴수 없는 상태에서 parameter정보를 고칠때
- DB를 내리면 다시 고쳐줘야 한다. 즉 , DB가 살아있는동안에만 유효하다
ALTER SESSION SET SQL_TRACE=true;
ALTER SYSTEM SET TIMED_STATISTICS=true;
ALTER SYSTEM SET SORT_AREA_SIZE=131072 DEFERRED;
--> sort_area_size :sort 영역의 size를 변경하는것
주 : ALTER SYSTEM DEFFERED 명령은 앞으로 데이타 베이스에 접속할
세션에 대한 값을 수정합니다.
3-38.제한된 세션(Restricted Session의 Enable및 Disable)
- STARTUP RESTRICT
- ALTER SYSTEM ENABLE RESTRICTED SESSION;
주 : SELECT logins FROM V$INSTANCE;
SELECT * FROM V$DATABASE;
* 이미 들어와 있는 user가 있는 상태에서 제한모드로 들어가면 그 user는 계속
유효하다.
3-40.세션종료
- 현재 사용중인 user를 kill 시키는 방법
SELECT sid, serial# FROM v$session
WHERE user_name='SCOTT';
ALTER SYSTEM KILL SESSION '7,15';
* session : connect 해서 종료할때까지의 상태
* 한 user가 여러개의 session을 만들수 있다
* 한번접속해서 종료한 뒤 다시 접속을 해도 같은 SID를 가지기 때문에 serial# 이 필요
* 이렇게 sid 와 serial# 을 가진 session은 unique 하다
세션종료 효과
ALTER SYSTEM KILL SESSION명령은 Background process PMON이 다음 단계를
수행 하도록 합니다.
-사용자의 현재 Transaction은 Rollback
-현제의 모든 Table,또는 Row의 잠금을 해제
-예약된 현제의 모든 자원을 해제
-세션이 Active한경우 kill된 경우
ORA-00028 :your session has kklled
-Inactive인 Session이 kill된 경우
즉시 Error 메시지가 Return되지 않고 V$SESSION의 STATUS 컬럼이
killed로 표시
주:ALTER SYSTEM DISCONNECT SESSION 'integer1.integer2'
POST_TRANSACTION;
3-42.추적(Trace)파일
1) ALERT! file : Background_dump_dest 에 존재(?/rdbms/log)
2) Trace file
* show parameter dump 로 확인
* User_Dump_Dest
-관련 Server Process에 의해..
init~.ora에
ALTER SESSION SET SQL_TRACE=true;
-관련 Background Process에 의해
* init~.ora 파일을 고치면 DB를 down시키고 다시 작동시킨다.
제4장 데이타베이스 생성
1. 목적-운영체제 준비
1) 파라메타 파일 준비
2) 데이타베이스 생성
2. 개요
1) 생성에 필요한 조건
(1) 다음중 한 방법으로 인증된 권한을 가진 계정에서 생성하십시오
(a) 운영체제에 의해
(b) 패스워드 파일을 사용하여
(2) 인스턴스를 시작할 수 있는 메모리
(3)계획된 데이타베이스에 충분한 디스크 용량 : 대략 2G 정도
2) 데이타베이스 파일의 위치계획
(1) 최소한 두개의 장치에 최소 두개의 활성화된 데이타베이스 콘트롤 파일
의 사본을 둡니다. --> 별도의 디스크에 미러링을 하라.
(2) 리두 로그 파일을 여러개 만들어 두며 그룹멤버를 서로 다른
디스크에 둡니다.
(3) 다음과 같은 데이타가 분리 되도록 데이타파일을 준비합니다.
(a) 서로 다른 물리적 디스크 자원에 걸처서 디스크 자원을 나누어서
사용할 수 있는 것들
(b) 서로 다른 수명을 갖는 것들 : 별도의 tablespace에 저장
(c) 서로 다른 관리 특성을 갖는 것들
3) 오라클 소프트웨어의 위치
(1) install 하기전에 고려
4) 오라클 데이타베이스 파일
5) 수동으로 데이타베이스 생성 : Software가 install되어있다는 가정하에
(1) 인스탄스와 데이타베이스의 고유한 이름, 그리고 데이타베이스
Character Set을 결정합니다
* 하나의 DB에 여러개의 instance가 접속이 가능하다
* instance 명칭는 다 달라야 한다
* .profile에서 셋팅(ORACLE_SID, ORACLE_HOME, ORA_NLS33)
* init.ora에서 DB의 이름을 결정
* DB_NAME, CONTROL_FILES
* Character Set : 한글을 사용하고자 할때(DB를 만들때)
주 : DB_NAME와 ORACLE_SID는 다른 것이다
이름은 같을 지라도 같은 것은 아니다
(2) 운영체제 변수를 설정합니다.
* .profile 의 변수를 설정(ORACLE_SID, ORACLE_HOME, ORA_NLS33, PATH)
* ORA_NLS33 : 국가의 언어를 path로 지정해줌
(3) 파라메타 파일을 준비 합니다.
* init~.ora
(4) 패스워드 파일을 생성합니다(권장사항)
(5) 인스턴스를 시작합니다
* NOMOUNT 상태까지 올라가야함(CREATE DATABASE 하기 위해서)
(6) 데이타베이스를 생성합니다.
(7) 스크립트를 시행하여 데이터 딕셔너리를 작성하고 생서후 단계를 수행합니다.
6) 운영체제 환경
(1)Unix에서는 다음과 같은 환경 변수를 설정합니다.
(a) ORACLE_HOME - 오라클 소프트웨어가 설치될 디렉토리
(b) ORACLE_SID - 인스탄스의 이름, 동일한 기계에서 실행될 여러 오라클 인스
탄스들은 각가 고유한 이름을 가지고 있어야 합니다.
(c) ORACLE_BASE - 필수적인 것은 아니지만 OFA를 설치의 일부로서 권장 사항 입니다
예:/u01/app/oracle
(d) ORA_NLS33 - US7ASCII와 가 아닌 다른 Character set으로 데이타베이스를
생성할 경우 필요합니다. 예($ORACLE_HOME/ocommon/admin/data) --> path를 적는다
(e) PATH - $ORACLE_HOME/bin을 포함해야 하는 검색 경로 입니다.
(2) NT에서는
(a) svrmgr30을 사용하려면 ORACLE_SID변수를 설정합니다.
(b) ORADMIN80으로 서비스와 패스워드 파일을 생성합니다.
(c) C:\>ORADMIN80 -NEW -SID u16 -intpwd password -startmode auto
-pfile ORACLE_HOME\DATABASE\initu16.ora
7) 파라메타 파일 준비
(1) DB_NMAE - 8글자 이하의 데이타베이스 식별자 입니다.
(2) CONTROL_FILES
(3) DB_BLOCK_SIZE (default : 2K)
주 : 데이타베이스 이름은 데이타베이스 생성시 데이타베이스와 관련 있으며
기존 데이타베이스 이름을 바꾸려면 CREATE CONTROLFILE 명령을 사용하여
컨트롤 파일을 재생성하십시오
8) 인스탄스 시작
(1) SYSDBA로 접속
(2) NOMOUNT단계에서 인스탄스를 시작합니다.
9) 데이타베이스 생성
SPOOL creu16.log
STARTUP NOMOUNT PFILE=initU16.ora --> U16 : ORACLE_SID
CREATE DATABASE U16 --> DB의 이름 : U16 (DB_NAME)
MAXLOGFILES 5 --> DB에 둘 최대 ON LINE REDO LOG file 수
MAXLOGMEMBERS 5 --> 한 group의 수의 최대값
MAXDATAFLES 100 --> DB에 만들 최대 DB의 수
MAXLOGHISTORY 100
LOGFILE --> on line redo log 에 대한 정보를 setting
GROUP 1('/DISK3/log1a.rdo', '/DISK4/lob1b.rdo') SIZE 1m,
GROUP 2('/DISK3/log2a.rdo', '/DISK4/log2b.rdo') SIZE 1m
DATAFLE --> system table file 을 적는다
'/DISK1/system01.dbf' SIZE 50M AUTOEXTEND ON
CHARACTER SET WE8ISO8859P1; --> 지정하지 않으면 US7ASCII, 한글 : K016KSC5601
(1) Syntax
CREATE DATABASE [database]
[CONTROLFILE REUSE]
[LOGFILE [GROUP integer ] filespec
[GROUP integer] filespec]...]
[MAXLOGFILES integer]
[MAXLOGMEMBERS integer]
[MAXLOGHISTORY integer]
[MAXDATAFILES integer]
[MAXINSTANCES integer] --> 여러개의 instance 를 사용할때
[ARCHIVELOG | NOARCHICELOG]
[CHARACTER SET characterset]
[DATAFILE filespec [autoextend_clause]
[, filespec [autoextend_caluse]...]]
filespec :== 'filename' [SIZE integer][K|M] [REUSE]
* 그 위치에 파일이 존재하면 REUSE option을 사용하고 SIZE를 적지 않고
파일이 존재하지 않으면 반드시 SIZE를 사용해야한다
주 : oracle database assistant
10) DB가 생성된후 데이타베이스는 다음을 갖습니다.
(1) SYSTEM 테이블스페이스를 구성하는 데이타파일들
(2) 콘트롤 파일과 리두로그 파일
(3) 사용자 :SYS/change_on_install
(4) 사용자 :SYSTEM/manager
(5) 롤백세그먼트 SYSTEM
(6) 내부 테이블(데이타 딕셔너리 뷰는 없음)
11) DB가 생성되면 오픈되어 sql.bsq라고 하는 Script가 성공적으로 수행.
* 내부적으로 자동적으로 Script를 수행
* initDBA05.ora 가 있는 위치에 sql.bsq 가 있어야 한다
12) V$LOGFILE, V$CONTROLFILE그리고 V$DATAFILE등의 동적 성능 뷰는 볼 수 있으나 데이타 딕셔
너리 뷰는 생성 되지 않습니다.
제5장 데이터 딕셔너리 뷰 및 표준 패키지 생성
5-3.목적 - 데이터 딕셔너리 뷰(data dictionary views)구성
데이터 딕셔너리 사용
관리용 스크립트를 사용하여 pl/sql환경 준비
저장 프로시져(Stored Procedure)와 패키지 관리
5-4.데이터 딕셔너리 사용
1. 데이타 딕셔너리는 다음과 같은 정보를 제공합니다.
--> Oracle Bible 199p참조
1) oracle server의 각 사용자 이름
2) 각 사용자에게 Grant된 oracle privileage 과 역할
3) oracle DB schema 객체들의 이름과 정의
4) 각 DB 객체에 대한 space 사용
5) DB 구조
6) 무결성 제약(Integrity Constraints)
7) DB 감사(Auditing) 정보
8) oracle DB 저장함수(Stored Procedures) 및 DB Triggers
데이터 딕셔너리는 DDL명령이 수행 될때 마다 오라클 서버가 갱신(update)
합니다, 또한 테이블을 확장시키는 결과를 낳는 DML명령도 딕셔너리를
갱신 할 수 있습니다.
5-5.기본 테이블과 데이터 딕셔너리 뷰
1. 기본테이블
1) sql.bsq스크립트로 생성됩니다.
2. 데이터 딕셔너리 뷰
1) 기본 테이블 정보를 간략하게 보여 줍니다.
5-7.데이터 딕셔너리 뷰
---> select * from dictionary;
1. DBA_xxx
1) 모든 정보를 다 볼수 있다
2) system 관리자만 볼수 있다
3) sys, system user만 볼수 있다
2. ALL_xxx
1) 모든 user가 볼수 있다
2) 자기의 schema 정보
3. USER_xxx
1) 자기 자신만의 정보를 볼수 있다
4. DICTIONARY
--> select * from dictionary; (dictionary==dict) : 모든 dictionary의 내용을 볼때
5. DICT_COLUMNS
ex>SELECT * FROM WHERE table_name LIKE '%TABLE%';
5-8.데이타딕셔너리 뷰:그 예와 범주
1. DICTIONARY
2. DICT_COLUMNS
3. DBA_TABLES
4. DBA_OBJECTS
5. DBA_LOBS
6. DBA_TAB_COLUMNS
7. DBA_CONSTRAINTS
8. DBA_USERS : DB 에 존재하는 모든 user들의 정보를 보여줌
* 9. DBA_SYS_PRIVS : DB에 존재하는 모든 권한에 대한 정보를 보여줌
10. DBA_ROLES
11. DBA_EXTENTS
12. DBA_FREE_SPACE
13. DBA_SEGMENTS
14. DBA_ROLLBACK_SEGS
15. DBA_DATA_FILES
16. DBA_TABLESPACES
17. DBA_AUDIT_TRIAL
18. DBA_AUDIT_OBJETS
19. DBA_AUDIT_OBJ_OPTS
5-11.데이터 딕셔너리 뷰 생성
1. catalog.sql - 기본 테이블 뷰, 동적 성능 뷰, 그리고 동의어
Server manager utility, Auding, Export와 Import!
Utility그리고 Partitioning, Object옵션을 위한 뷰와
오브젝트를 생성해주는 스크립트를 실행 - standard.sql
2.catproc.sql - PL/SQL기능을 사용할 수 있도록 설정하며, RDBMS기능을
수행할때 사용되는 몇개의 PL/SQL페키지 를 생성합니다.
또 Advanced queuing option, Tablespace point-in-time Recovery
그리고 LOB의사용을 위한 추가 뷰도 생성합니다.
5-15.오라클 제공 패키지
1. DBMS_LOB
2. DBMS_SESSION : ALTER SESSION 이나 SET ROLE같은 SQL명령어를 생성
3. DBMS_UTILITY
4. DBMS_SPACE
5. DBMS_ROWID : 실제적으로 위치하는 곳을 가르쳐준다
6. DBMS_SHARED_POOL : 공유풀에 정보를 저장하고 샥제
제6장 콘트롤 파일 관리
6-3.목적-콘트롤 파일의 용도 설명
1. 콘트롤 파일 내용의 검사
2. 콘트롤 파일 정보
3. 콘트롤 파일 다중화
6-5.콘트롤 파일의 내용
1. 데이타베이스 이름
2. 데이타파일의 위치
3. 리두로그 파일 위치
4. 테이블스페이스 이름
5. 현제의 로그 시퀀스 번호 --> 동기화 정보
6. 체크포인트 정보 --> 동기화 정보
7. 현재까지의 로그 기록
8. 백업 정보 : oracle 8 에만
6-6.콘트롤 파일의 크기에 영향을 주는 파라메타들 --> 새로 생성을 해야 한다
1. MAXLOGFILES
2. MAXLOGMEMBERS
3. MAXLOGHISTORY
4. MAXDATAFILES
5. MAXINSTANCES
주-콘트롤 파일의 크기를 바꾸려면 새콘트롤 파일을 생성해야 합니다.
6-7.콘트롤 파일에 대한 정보
1. V$CONTROLFILE
2. V$PARAMETER
3. V$CONTROLFILE_RECORD_SECTION
6-9.콘트롤 파일의 다중화(매우중요)
1. CONTROL_FILES초기화 파라메타에 완전한 경로로 콘트롤 파일 이름을
8개 까지 지정함으로써 다중 컨트롤 파일을 가진 데이타베이스를 생성
할 수 있습니다.
2. 오라클 서버는 데이타베이스를 생성할때 나열된 모든 파일을 생성하고
유지 합니다.
3. 오라클은 서로 다른 디스크에 최소한 두개의 콘트롤 파일을 저장할 것을
권장합니다. 한 컨트롤파일에 문제가 생기면 사본을 이용하여
인스탄스를 제시작 하십시오.
4. 컨트롤 파일 다중화(control file의 Mirroring)
1). 데이타베이스를 종료 합십시오
2). 운영체제 명령을 사용하여 기존의 Control File의 사본을 다른 장치에
만드십시오
3). 모든 컨트롤 파일이름이 포함되도록 CONTROL_FILES를 편집하십시오
4). 데이타베이스를 시작하십시오
* control_files = (---, ---, ---)
* MIRRORING : 기존의 control file을 copy해서 다른 장소에 가져다 놓고 정상적으로
shutdown 시킨후 list에 full path로 가져다 놓는 것
* Mirroring을 하더라도 file이 하나라도 깨지면 NOMOUNT상태에서 멈춘다.
* 깨어진 file을 제거하고 startup --> alert! file 을 확인 --> 깨진 file을 다시 복사
--> 다른 file이 또 깨어진것이 있는지 순차적으로 확인 --> startup
5. contro flile 다중화의 잇점
제7장 리두로그 파일 관리(매우 중요)
7-3.목적 - 온라인 리두로그 파일의 용도 설명
1. 사용자가 commit할때
2. 로그와 아카이브 정보
3. 로그 스위치와 체크포인트 제어
4. 온라인 리두 로그 파일 다중화 및 관리
5. 온라인 리두 파일 계획
6. 일반적인 리두로그 파일 문제 해결
* commit정보뿐만아니라 commit되지 않은 정보도 들어간다
* 'commit 이 완료되었습니다' 라는 message가 나오면 REDO LOG file 에
기록을 했다는 의미지 database file에 썼다는 것을 의미하지는 않는다.
7-4.리두로그 파일 사용 --> 복구(RollBack Segement와 같이)
1. 오라클 서버는 데이타베이스 내의 데이터 손실을 최소화 하기 위해
온라인 리두로그 파일을 유지 합니다.
2. 리두 로그 파일은 데이타베이스 버퍼 케쉬내의 데이터에 가해진 모든 변경사항을 기록 합니다.
3. 리두 로그 파일은 인스탄스 실패와 같은 상황에서 데이타 파일에 쓰여지지
않은 커밋된 데이타를 복구하기 위해 사용됩니다.
4 .리두로그 파일은 복구를 위해서만 사용됩니다.
7-5.리두로그 그룹과 멤버
1. 백그라운드 프로세스 LGWR은 그룹내의 모든 온라인 리두로그 파일에
동일한 정보를 기록합니다.
2. 현재의 로그시퀀스번호(Log Sequence Number)는 콘트롤 파일과
모든 데이타 파일 헤더에 저장 됩니다. --> 로그 스위치를 일으킬때
7-7.오라클 구조
1. 리두로그 버퍼와 백그라운드 프로세스 LGWR
1) 오라클 서버는 데이타베이스에 가해진 모든 변경사항을 리두로그 버퍼에
순차적으로 기록합니다.
2) 리두로그 버퍼는 원형방법(Circular manner)으로 사용됩니다.
3) 다음과 같은 상황일때 LGWR 프로세스가 리두 엔트리를 현재의
온라인 리두 로그 그룹이라 부르는 온라인 리두로그 그룹중 하나에
기록합니다.
(1) 커밋시
(2) 리두로그 버퍼풀이 3분의 1가량 찼을때
(3) LWGR 타임 아웃 발생시에(매 3초마다)
(4) DBWR이 데이타베이스 버퍼 케쉬의 수정된 블럭을 데이타 파일에 적기전
2. 로그 스위치(Log Switch)
1) 로그 스위치는 LGWR이 한 온라인 리두 로그그룹에 쓰기를 멈추고 그 다음
온라인 로그 그룹에 쓰기를 시작하는 이벤트 입니다.
2) 데이타베이스 관리자는 로그스위치를 강제로 발생 시킬 수 있습니다.
* Archive Log List 에서 Current Log Sequence 확인
* select * from v$log; 에서 sequence# 확인
* alter system switch logfile;
* select * from v$log; 에서 다시 확인
* alter system switch logfile; 을 하면 current log sequence를 바뀐다
3) 로그 스위치가 발생하고 LGWR이 새 로그 그룹에 쓰기를 시작할때
오라클 서버는 리두 엔트리들을 식별하기 위해 로그시퀀스번호를
할당합니다,
4) 로그 스위치가 발생할때 또한 체크포인트라는 이벤트가 반드시 발생됩니다.
3. 체크포인트(CheckPoint)
체크포인트 동안에 다음과 같은 작업이 이루어 집니다.
1) 체크포인트가 발생한 로그와 관련된 사용된 모든 데이타베이스 버퍼(더티 버퍼)
는 DBWR에 의해 데이타 파일로 옮겨 쓰여집니다.
2) 체크포인트 백그라운드 프로세스 CKPT는 완료된 것을 반영하여 모든 데이타파일
의 헤더와 콘트롤 파일을 갱신합니다. --> datafile을 다 내린 다음에
3) 체크포인트는 데이타베이스의모든 데이타파일에 발생할 수도 있고
특정 데이타파일에만 발생 할 수도 있습니다.
**중요** 체크포인트는 다음과 같은 상황에서 발생합니다.
1) 모든 로그 스위치때 --> 억제할수 없다.. 반드시 일어난다
2) 인스탄스가 정상종료나 트렌젝션 종료, 또는 즉시 종료 되었을때
--> shutdown normal, immediate, transactional 일때
--> abort는 제외
*3) LOG_CHECKPOINT_INTERVAL과, LOG_CHECKPOINT_TIMEOUT초기화 파라메타
의 설정에 따라(다음 절을 참조 하십시오) --> init~.ora 에서 setting
4) 데이타베이스 관리자가 수동으로 요구하였을때(다음 절을 참조하십시오)
초기화 파라메타 LOG_CHECKPOINT_ALERT!가 TRUE로 설정되어 있으면 모든
체크포인트에 대한 정보가 ALERT! 파일에 기록 됩니다. 기본값은 FALSE로
이 경우는 체크포인트 정보를 기록 하지 않습니다.
7-9.아카이브 하지 않을때(No Archive Log Mode) --> default
1. CheckPoint가 완료될때까지 체워진 RedoLog 그룹을 겹쳐쓰지 않습니다.
2. 매체 복구 불가 : file이 날라가면 복구가 불가능
3. instance 복구 가능
4. DB시점을 과거로 돌려 놓는다
5. Online BackUp 을 받을수 없다.
* BackUp
(1) Cold Backup(OffLine Backup) --> shutdown 상태에서 Backup 받는 것
(2) Hot Backup(Online Backup) --> DB 구동중에 Backup
* Archive Mode가 되어야 한다
7-9.아카이브 할때(Archive Log Mode)
1. 매체 복구 가능
2. Roll Forward --> Roll Back(RollBack Segement) --> Recovery 완료
3. Waiting 이 일어날수 있다 --> On Line Redo Log 를 추가
7-11.아카이브에 대한 정보
1. ARCHIVE LOG LIST; --> ServerManager 명령어로 Archive 정보를 볼수 있다
2. V$DATABASE
7-13.그룹에 대한 정보
1. V$THREAD
7-14.그룹과 멤버에 대한 정보
1. V$LOG
7-17.로그스위치와 체크포인트
1. ALTER SYSTEM SWITCH LOGILE;
2. LOG_CHECKPOINT_INTERVAL
3. LOG_CHECKPOINT_TIMEOUT
7-19.온라인 리두 그룹의 추가 (**매우 중요**)
1. DB가 구동중인 상태에서 실행
2. Online Redo Log Mirroring
ALTER DATABASE ADD LOGFILE ('/disk3/log3a.rdo',
'/disk4/log3b.rdo') SIZE 1M;
== syntex ==
ALTER DATABASE [database]
ADD LOGFILE [GROUP integer ] filespec
[GROUP integer] filespec]...]
7-21.온라인 리두 로그 멤버의 추가
ALTER DATABASE ADD LOGFILE MEMBER
'/disk4/log1b.rdo' TO GROUP 1,
'/disk4/log2b.rdo' TO GROUP 2;
7-22.온라인 리두 로그파일의 재배치
1.데이타베이스를 종료하십시오
2.온라인 리두로그 파일을 새로운 위치에 복사 하십시오
3.데이타베이스를 마운트 하십이오
4.ALTER DATABASE RENAME FILE 명령을 실행 하십시오
5.데이타베이스를 오픈하십시오 --> alter database open;
ALTER DATABASE [database] RENAME FILE 'filename' [,'filename']...
TO 'filename' [, 'filename']...
7-23.온라인 리두 로그 그룹의 삭제
1. ALTER DATABASE DROP LOGFILE GROUP 3;
7-25.온라인 리두 로그 멤버 삭제
1. ALTER DATABASE DROP LOGILE MEMBER 'disk4/log2b.rdo';
2. 제한 사항
1) 삭제하고자 하는 멤버가 그룹의 하나 남은 유효 멤버라면
그 멤버를 삭제 할 수 없습니다.
2) 그룹이 활성중이 라면 멤버를 삭제하기 전에 로그 스위치를
발생 켜야 합니다.(current를 변경 --> alter system switch logfile;)
3) 데이타베이스가 ARCHIVELOG모드 이고 멤버가 속한 로그 파일
그룹이 아카이브 되지 않고 있다면 그 멤버를 삭제 할 수
없습니다.
4) 온라인 리두 로그 파일이 삭제 될때 운영체제 파일까지
삭제되는 것은 아닙니다.
7-27.온라인 리두 로그 파일 정리
1. example
1) ALTER DATABASE CLEAR LOGFILE '/disk3/log2a.rdo';
2) 모든 멤버 중에서 한 리두 로그 파일이 훼손 되었다면 데이타베이스
관리자는 훼손된 로그파일을 제초기화 하여 문제를 해결할 수 있습니다.
ALTER DATABASE [database]
CLEAR [UNARCHIVED] LOGFILE
{GROUP integer | ('filename' [,'filename'], ...}}
[, {GROUP integer | ('filename' [, 'filename']...)}}...
3) 온라인 리두 로그 파일을 추가하고 삭제하는 것과 결과는 동일 합니다. 하지만
위 명령은 로그 그룹이 두개 뿐이고 각 그룹이 하나의 멤버만을 가지고
있어도 사용할수 있으며 지워진 그룹이 아카이브 되지 않아도 사용 가능합니다.
2. 제한 사항
1) 온라인 리두 로그 파일이 아카이브 되어 있든 아니든 지울 수 있습니다.
2) 하지만 아카이브되어 있지 않을때에는 UNARCHIVED키워드를 넣어야 합니다.
3) 이렇게 하면 복구시에 온라인 리두 로그파일에 필요할때 백업을 사용할 수 없게
만들 것입니다.
7-28.온라인 리두 로그 구성
1. 온라인 리두로그파일을 다중화 할때 한 그룹의 멤버를 서로 다른 디스크에
놓으십시오 이렇게 하면 멤버 하나를 사용할 수 없더라도 다른 멤버를
사용할 수 있어 인스탄스가 종료되지 않습니다.
2. 아카이브로그 파일과 온라인 리두로그 파일을 서로 다른 디스크에 분리시켜
ARCH와 LGWR백그라운드 프로세스 간의 경합(contention)을 감소
시켜야 합니다.
3. 온라인 리두로그 파일의 최소크기는 500K이고 최대크기는 운영제제에
따라 다릅니다.
4. 그룹이 다른 멤버 끼리는 크기가 서로 다르게 할 수 있지만 실익은
없습니다.(그룹 내의 크기는 같아야 한다)
5. 다음 상황의 경우 온라인 리두로그 파일의 구성에 영향을 줄 수도
있습니다.
(1) 로그 스위치와 체크포인트 횟수
(2) 리두 엔트리의 갯수와 총량
(3) 아카이브가 가능한 테이프등의 저장매체상의 공간
제8장.테이블스페이스와 데이타파일 관리 -->210P
8-3.목적
1. 테이블스페이스의 논리적 기술
2. 테이블스페이스 생성
3. 여러방법으로 테이블스페이스의 크기변경
4. 테이블스페이스의 상태와 스토리지설정(storage settings)변경
5. 테이블스페이스 재배치
6. 필요한 테이블스페이스 준비
8-4.개요
1. 데이타베이스 구조는 데이타를 구성하는 논리적, 물리적 구조(file)를 포함합니다.
8-5.데이타베이스의 구조
데이타베이스
|
테이블스페이스 -- 데이타파일
|
세그먼트
|
익스텐트
|
오라클 블록
1. 테이블스페이스
1) 한 테이블스페이스는 오직 한개의 데이타베이스에만 속합니다.
2) 각 테이블스페이스는 하나 이상의 데이타파일로 구성됩니다.
3) 테이블스페이스는 데이타베이스가 실행중인 동안 온라인 상태가 될 수
있습니다.
4) SYSTEM 테이블스페이스나 활성 롤백세그먼트를 가진 테이블스페이스를 제외한
테이블스페이스는 데이타베이스가 실행중인 동안에도 OFFLINE상태가
될 수 있습니다.
* system tablespace는 어떠한 경우에도 offline이 될수 없다
* Rollback정보를 획득할수 없기 때문
5) 테이블스페이스는 읽기쓰기 상태거나 읽기전용상태가 될수 있습니다.
* Read Only Tablespace 특성
(1) Backup, Recovery가 매우 용이 --> 별도의 복구 작업이 필요없다, copy만 하면된다
2. 테이블스페이스이용
* I/O 경합을 감소 분배
* Fragmentation 최소화
* 사용용도에 따라서 배분
* data의 특성을 고려해야 한다
1) 영역할당을 제어하고 사용자에게 공간 할당량(quotas)지정
2) 개별적인 테이블스페이스를 온라인, 또는 오프라인으로 하여 데이타의
가용성(availability)제어
3) I/O성능을 향상시키고 한 디스크에 대한 I/O경합을 감소시키기 위해
장치간에 데이타스토리지(data storage)분배
* 특히 index와 table 은 다른 곳에 배분
4) 부분 Backup과 Recovery 작업 수행
3. 데이타파일
1) 오라클 데이타베이스의 각 테이블스페이스는 데이타파일이라 불리는 하나,
또는 그 이상의 파일로 이루어 집니다. 오라클 서버가 실행중인
운영 체제에 따르는 물리적 구조 입니다.
2) 한데이타는 오직 한 데이블스페이스에만 속합니다.(partitioning option을 사용 안할때에만)
3) 오라클 서버는 테이블스페이스에 대해 지정된 디스크양에 약간의
오버헤드를 더하여 데이타파일을 생성합니다.
4) 데이터피일이 생성된 후에 그 크기를 변경할 수도 있고 테이블스페이스
내의 오브젝트가 커짐에 따라 데이타파일을 동적으로 증가(grow)하도록
지정할 수 도 있습니다.
5) 데이타베이스의 테이블스페이스 당 적은 수의 데이타파일로 구성될 수
있도록 하여 데이탑이스 관리가가 MAXDATSFILES값에 제한 받지 않도록 합니다.
4. 세그먼트, 익스텐트, 데이터블록 간의 관계
1) 세그먼트는 테이블스페이스에 특정 유형의 논리적 저장구조로 할당된 영역입니다.
* 단편화 경향이 적은 것부터 순서데로
(1) 테이블세그먼트
(2) 인덱스 세그먼트
(3) 임시세그먼트
(4) 롤백세그먼트
2)데이타세그먼트 같은 세그먼트는 하나의 테이블스페이스에 속한 여러 파일에 걸쳐 있을
수 있습니다.(partitioning option)
5. 익스텐트
1) 다음 레벨의 논리적 데이타베이스 저장 공간은 익스텐트 입니다. 익스텐트는 연속되는
블록의 집합입니다. 각 유형의 세그먼트는 하나이상의 익스텐트로 구성됩니다.
2) 익스텐트는 여러 데이타파일에 걸처 있을 수 없고 반드시 한파일내에 존재해야 합니다.
6. 데이타블록
1) 가장 작은 단위로서 오라클데이타베이스의 데이타는 데이타블록에 저장 됩니다.
2) 하나의 데이타 블록은 기존의 데이타 피일로 부터 할당된 하나이상의 물리적 파일블록
에 해당 됩니다.
3) 데이타블록의 크기는 데이타베이스가 생성될때 초기화 파라메타 DB_BLOCK_SIZE
에 의해 각 오라클 데이타베이스 마다 지정 됩니다. 데이타베이스 블록은
입출력의 가장 작은 단위 입니다.
8-8.SYSTEM과 비 SYSTEM 테이블스페이스(**중요**)
SYSTEM 테이블스페이스가 비 SYSTEM 테이블스페이스가
포함하고 있는것 포함하고 있는것
-데이타 딕셔너리 정보 -롤백세그먼트
-SYSTEM 롤백세그먼트 -임시세그먼트
-응용프로그램 데이타
-응용프로그램 인덱스
1. SYSTEM 테이블스페이스
1) 데이타베이스 작업을 위해 항상 데이타베이스에 있어야 합니다.
2) 데이타딕셔너리 정보와 저장 프로시져(Stored procedure), 페키지,그리고
데이타베이스 트리거(Trigger)의 정의를 포함하고 있습니다.
3) SYSTEM 롤백세그먼트를 포함하고 있습니다.
4) 사용자의 데이타를 포함 할 수 있지만 그렇게 되지 않도록 해야 합니다.
2. 비 SYSTEM 테이블스페이스
1) 데이타베이스 관리의 유용성을 부여 합니다.
2) 롤백세그먼트,임시세그먼트,응용프로그렘 데이타,그리고 응용프로그렘 인덱스
를 저장 할 수 있습니다.
8-10.테이블스페이스의 생성(**매우중요**)
1. 예
CREATE TABLESPACE app_data
DATAFILE '/disk4/app01.dbf' SIZE 100M, --> os상에 파일이 있다면 [REUSE]를 쓴다
'/disk5/app02.dbf' SIZE 100M file_name 적고 size는 적지 않는다
MINIMUM EXTENT 500K
DEFAULT STORAGE (INITIAL 500K
NEXT 500K
MAXEXTENTS 500
PCTINCREASE 0); --> 비율
2. CREATE TABLESPACE명령으로 테이블 스페이스를 생성합니다.
CREATE TABLESPACE tablespace
DATAFILE filespec [autoextend_clause]
[, filespec [autoextend_clause] ] ...
[MINIMUM EXTENT integer [K|M] ]
[DEFAULT storage_clause]
[PERFORMENT | TEMPORARY]
[ONLINE | OFFLINE] --> default : online
storage_clause :==
STORAGE( [INITIAL integer [K|M]
[MINEXTENTS integer ]
[MAXENTENTS (integer | UNLIMITED) ]
[PCTINCREASE integer]
구문에서
MINIMUM EXTENT 테이블스페이스에 사용된 모든 익그텐트 크기가
지정한 정수값의 배수가 되게 합니다.
주:MINIMUM EXTENT옵션(oracle8에만)을 설정하여 데이타베이스 관리자는 테이블 스페이스
의 단편화를 제어 할 수 있습니다.
테이블스페이스에 대해서만 지정할 수 있는 옵션입니다.개개의 오브젝트 에 대해서는
지정할 수
없습니다.
8-13.스토리지 파라메타(Storage Parameters)
세그먼트 스토리지 할당(allocation)에 영향을 주는 파라메타입니다.
INITIAL
NEXT
MAXEXTENTS
MINEXTENTS
PCTINCREASE
.INITIAL은 첫 익스텐트의 크기를 지정합니다.
.첫 익스텐트이 최소 크기는 두 블록 입니다. 즉(2*DB_BLOCK_SIZE)입니다.
.NEXT는 두번째 익스텐트의 크기를 지정합니다.
다음 익스텐트의 최소 크기는 한 블록 입니다.
기본값은 5블록 입니다.(5*DB_BLOCK_SIZE)입니다.
8-15.임시테이블스페이스(**매우중요**)
.정렬 작업에 사용 됩니다.
.영구 오브젝트(Permanent object)를 포함 할 수 없습니다.
CREATE TABLESPACE sort
DATAFILE '/disk2/sort01.dbf' SIZE 50M
MINIMUN EXTENT 1M
DEFAULT STORAGE (INITIAL 2M
NEXT 2M
MAXEXTENTS 500
PCTINCREASE 0)`````
TEMPORARY; --> 생략하면 Permanent
. Temporary Segment : SMON 이 자동으로 만들고 소멸시킨다
* 어느 TableSpace에도 들어갈수 있다
* sort 작업시 공간의 allocation을 한번만하고 처음에만 format을 하고 그다음
부터는 data만 날리고 그 자리에 다시 사용할 수 있다.
* Permanent 와의 차이
* Permanent 가 Performance가 떨어진다
* Sort시 자주 사용
. Permanent는 sort시 allocate하고 다시 지우고 다시 allocate한다(속도가 떨어짐)
* 일반 Table에 사용
8-16.테이블스페이스에 데이타파일 추가
예
ALTER TABLESPACE app_data
ADD DATAFILE '/disk5/app03.dbf' SIZE 300M;
-테이블 스페이스는 다음 두가지 방법으로 확대(enlarge)할 수 있습니다.
.테이블스페이스에 데이타파일 추가
.데이타파일 크기변경
테이블스페이스에 데이타파일 추가
테이블스페이스에 할당된 디스크 공간의 총량을 증가 시키려면 ALTER TABLESPACE ADD
DATAFILE 명령으로 테이블스페이스에 데이타파일을 추가 할 수 있습니다.
ALTER TABLESPACE tablespace
ADD DATAFILE filespec [autoextent_clause]
[, filespec [autoextent_clause] ]...
8-18.데이타파일 자동확장(Automatic Extention)
예
ALTER TABLESPACE app_data
ADD DATAFILE '/disk6/app04.dbf' SIZE 200M
AUTOEXTENDED ON NEXT 10M
MAXSIZE 500M;
데이타파일의 크기를 다음 두가지 방법으로 바꿀 수 있습니다.
.AUTOEXTEND옵션을 사용하여 자동으로
.ALTER DATABASE명령을 사용하여 수동으로
데이타파일의 크기의 자동재조정
AUTOEXTEND 옵션은 데이타파일의 자동확장을 enable하거나 disable할 수 있습니다.
.CREATE DATABASE
.CREATE TABLESPACE DATAFILE
.ALTER TABLESPACE ADD DATAFILE
파일 생성시 AUTOEXTEND설정
8-20.수동으로 데이타파일 크기 변경
예
ALTER DATABASE DATAFILE
'/disk5/app02.dbf' RESIZE 200M;
8-21.스토리지 설정(Storage Settings)
예
ALTER TABLESPACE app_data
MINIMUM EXTENT 2M;
ALTER TABLESPACE app_data
DEFAULT STORAGE(INITIAL 2M
NEXT 2M
MAXEXTENTS 999);
8-22.오프라인 테이블스페이스
.오프라인 상태인 테이블스페이스의 데이타에는 접근 할 수 없습니다.
.SYSTEM 테이블스페이스와 활성화된 롤백세그먼들 가진 모든 테이블스페이스는 오프라인
상태가 될 수 없습니다.
예
ALTER TABLESPACE app_data OFFLINE;
-테이블스페이스가 온라인 일때만 접근할 수 있습니다.다음의 경우 테이블스페이스를
오프라인 으로 변경합니다.
.데이타베이스의 나머지 부분은 정상접근이 가능하도록 하지만 , 일부분은 뫏謀?수 없게 만들때
.데이타파일을 재배치하는 동안 테이블이나 응용프로그렘을 사용할 수 없도록 할때
-오프라인 테이블 스페이스
오라클 서버는 SQL문이 오프라인 상태의 테이블스페이스에 포함된 오브젝트를 참조하도록
허용하지 않습니다.
-오라클 서버는 테이블스페이스가 오프라인디 되기 전에 그 테이블스페이스의 모든 데이타파일에ㅓ
대에 체크포인트를 수행합니다.
-테이블스페이스가 오프라인이 되거나 온라인이 되는 이벤트는 데이터 딕셔너리와 콘트롤 파일에
기록됩니다. 데이타베이스를 종료할때 테이블스페이스가 오프라인상태였다면 테이블스페스는
오프라인으로 남아 있을 것이고 데이타베이스가 다음에 마운트되고 다시 오픈될때 검사하지 않
을 것입니다.
-테이블스페이스를 오프라인으로 만들기
데이타베이스가 오픈되어 있다면 데이타베이스 관리자는 SYSTEM 테이블스페이스나 활성 롤백세그먼트나
임시세그먼트를 가진 테이블스페이스를 제외한 어떤 테이블 스페이스든지 오프라인 상태로 만들 수
있습니다. 테이블스페이스가 오프라인상태가 됐을때 오라클 서버는 모든 관련된 모든 데이타파일을
오프라인 상태 로 만듭니다.
ALTER TABLESPACE tablespace
{ONLINE | OFILINE [NORMAL|TEMPORARY|IMMEDIATE]}
테이블스페이스는 세가지 모드로 오프라인 상태가 될 수 있습니다.
* default : normal
* immediate : table을 복구 할때, CheckPoint를 수행하지 않는다
8-24.데이타파일 이동 : ALTER TABLESPACE (**작업순서 주의**)
.테이블스페이스 APP_DATA는 오프라인 상태 이어야 합니다.
.대상 데이타피일이 존재해야 합니다.
예
ALTER TABBLESPACE app_data RENAME DATAFILE
'/disk4/app01.dbf' TO '/disk5/app01.dbf';
* TO 이하의 file은 이미 존재 해야 한다
ALTER TABLESPACE명령
ALTER TALESPACE명령은 활성화된 롤백세그먼트나 임시세그먼트를 포함하지 않는 비 SYSTEM 테이블스페
이스
의 데이타파일에만 적용됩니다.
ALTER TABLESPACE tablespace
RENAME DATAFILE 'filename' [, 'filename'],...
TO 'filename', [, 'filename'],...
다음과정에 따라 데이타파일 이름을 바꾸십시오
1.테이블스페이스를 오프라인 상태로 바꾸십시오
2.운영체제 명령을 사용하여 파일을 옮기거나(move) 복사(copy)하십시오
3.ALTER TABLESPACE RENAME DATAFILE명령을 수행 하십시오
4.테이블스페이스를 온라인 상태로 만드십시오
5.필요하다면 운영체제 명령을 사용하여 파일을 삭제하십시오
주
원본 파일이름은 콘트롤 파일에 저장된 이름과 일치해야 합니다.
8-25.데이타파일 이동 : ALTER DATABASE RENAME
.데이타베이스가 마운트 되어 있어야 만 합니다.
.대상 데이타파일이 존재해야 합니다.
예
ALTER DATABASE RENAME FILE '/disk1/system01.dbf' TO
'/disk2/system01.dbf';
ALTER DATABASE명령
ALTER DATABASE명령("리두로그파일 관리를 참조하십시오")은 모든 유형의 데이타파일을 옮길때
사용할 수 있습니다.
ALTER DATABASE [database]
RENAME FILE 'filename' [, 'filename'] ...
TO 'filename' [, 'filename'] ...
다음과정에 따라 오프라인 상태가 될 수 있는 테이블스페이스에 들어 있는 파일 이름을
바꾸십시오
1.데이타베이스를 종료하십시오
2.운영체제 명령을 사용하여 파일을 이동하십시오
3.데이타베이스를 마운트하십시오.
4.ALTER DATABASCE RENAME FILE명령을 수행하십시오
5.데이타베이스를 OPEN하십시오
8-27.READ-ONLY테이블스페이스
예
ALTER TABBLESPACE app_data READ ONLY;
* 테이블스페이스 app_data는 읽기(read)작업만 가능합니다.
* DML 작업이 불가능
* TableSpace는 ONLINE상태이어야 한다
ALTER TABLESPACE tablespace READ {ONLY| WRITE}
8-29.읽기 전용테이블스페이스로 변경
.테이블스페이스는 온라인상태 이어야 합니다.
.활성 트렌젝션을 담고 있지 말아야 합니다.(DML작업)
.테이블스페이스에 활성 롤벡세그먼트가 포함되어 있지 않아야 합니다.
.테이블스페이스는 현재 온라인 백업에 포함되지 않아야 합니다.
테이블스페이스를 읽기전용으로 만들려면 몇가지 조건이 충족되어야 합니다.
사항을 충족시키기 위해 권장하는 방법은 제한된 모드(restricted mode)로 인스탄스를 시작하는 것입니다.
읽기전용 매체상에 읽기 전용 테이블스페이스 생성(CD롬)
.테이블스페이스를 읽기 전용으로 변경하십시오
.파일을 읽기 전용매체로 복사하십시오
.새위치를 가리키도록 데이타파일 이름을 변경하십시오
8-30.테이블스페이스 삭제
다음 명령문은 app_data 테이블스페이스와 그 내용을 전부 제거해 주는 명령문 입니다.
예
DROP TABLESPACE app_data INCLUDING CONTENTS;
테이블스페이스와 그내용이 더 이상 필요하지 않을때 DROP TABLESPACE SQL명령으로 데이타베이스에서
테이블스페이스를를 제거 할 수 있습니다.
DROP TABLESPACE tablespace
INCLUDING CONTENTS [CASCADE CONSTRAINTS]
* Including Contents : TableSpace에 Data가 이미들어있을 경우
* 들어있는 내용을 포함해서 모두 지워라는 option
* Casecade Constraints : primary key가 설정되어 있는 경우에 child가 존재
* child 의 foriegn key가 삭제되고 tablespace를 삭제
지침사항
1).데이타를 가지고 있는 테이블스페이스는 INCLUDING CONTENTS옵션 없이는 삭제할 수 없습니다.
2).TableSpace가 일단 삭제되면 그 데이타는 데이타베이스에 더 이상 존재하지 않게 됩니다.
**(중요)**
3).TableSpace가 삭제될때는 관련 데이타베이스의 콘트롤 파일내에 들어 있는 파일 포인터만이
삭제 됩니다. 데이타베이스 파일은 여전히 존재하므로 운영체제 레벨에서 명시적으로 삭제되여야
만 합니다.
**(중요)**
4).TableSpace가 READ ONLY로 변경 되더라도 세그먼트와 함께 삭제 될 수 있습니다. 이것은 DROP
명령이 TableSpace를 구성하고 있는 물리적 파일이 아닌 데이터딕셔너리(read write이어야 합니다)
만 갱신하기 때문에 가능한 일입니다.
5).TableSpace를 삭제 하기 전에 TableSpace의 어떤 세그먼트에 어느 트렌젝션도
접근하지 못하도록 테이블스페이스는 오프라인상태로 놓을 것을 권장합니다.
8-32.TableSpace 정보
DBA_TABBLESPACES
SVRMGR>SELECT tablespace_name, initial_extent, next_extent,
2>max_extents,pct_increase, min_extlen
3>FROM dba_tablespaces;
8-34.데이타파일 정보
DBA_DATA_FILES
SVRMGR> SELECT file_name, tablespace_name,bytes,
2> autoextensible, maxbytes, increment_by
3> FROM dba_data_files;
8-35.콘트롤파일의 데이타파일 정보와 테이블스페이스 정보
SVRMGR> SELECT file#,rfile#, d.name, status,enabled,
2> bytes, create_bytes, t.name
3> FROM v$datafile d, v$tablespace t
4> WHERE t.ts#=d.ts#;
8-37.지침사항
.여러 테이블스페이스(multiple tablespace)를 사용하십시오
.테이블스페이스에 대한 스토리지 파라메타(storage parameter)를 지정하십시오
.사용자에게 테이블스페이스 할당량을 지정해 주십시오.
제9장 스토리지 구조(Storage Strusture)및 상관 관계(Relaationships)
9-3.목적
.서로 다른 세그먼트 유형과 용도
.세그먼트 별로 익스텐트 사용을 제어
.오브젝트 별로 익스텐트 사용을 제어
.오브젝트 블록 공간 활용 파라메타의 사용
.데이터딕셔너리에서 스토리지구조(Storage Strusture)
에 대한 정보 출력
.단편화(Fragmentation)와 수명(Life-spaNS)
고려한 세그먼트 배치
9-4.데이타베이스 스토리지 계층 구조
데이타베이스
|
테이블스페이스 ----<-테이블 스페이스
|
세그먼트
|
익스텐트
|
오라클블럭 ----<- o/s 블럭
.데이타베이스는 TableSpace로 논리적으로 그룹지워집니다.
.테이블스페이스는 하나이상의 세그머트로 구성됩니다.
.세그먼트는 생성될때 최소한 하나의 익스텐트를 갖습니다.
익스텐트는 블록의 연속된 집합입니다. 세그먼트가 증가하면
익스텐트가 세그먼트에 추가 됩니다.
.논리적블록, 또는 오라클 블록이라고도 불리는 블록은 읽고 쓰는
작업에 사용되는 가장 작은 단위입니다.
9-5.세그먼트 유형
.테이블 .테이블 파티션(Table Partition)
.클러스터 .인덱스
세그먼트는 데이타베이스에서 공간을 차지하는 오브젝트 입니다.
본절에서는 다양한 유형의 세그먼트에 대해 설명합니다.
테이블
테이블 즉, 클러스터되지 않았거나(unclustered) 분할 되지 않은(nonpartitioned)
테이블은 데이타베이스내에서 데이타를 저장하는 가장 일반적인 수단입니다, 테이를
내의 데이타는 특별한 순서 없이 저장되며 데이타베이스 관리자는 테이블의 블록내의
행의 위치에 대해 거의 할 수 없습니다, 분할되지 않은 테이블내의 모든 데이타는
한테이블 스페이스내에 저장되어야 만 합니다.
테이블 파티션(Table partiiton)
동시에 많이 사용하는 테이블에 대해서는 주로 크기 조절 가능성(scalability)과 유용성
을 고려해야 합니다. 이러한 경우 테이블내의 데이타는 여러 파티션에 저장 될 수 있으며
그 파티션 각각은 서로다른 테이블스페이스에 상주 할 수 있습니다, 현재 오라클 서버는
키값의 범위에 따른 분할(Partiontin)을 지원합니다. 테이블이 분할(partition) 되면
각파티션은 하나의 세그먼트 이며 스토리지 파라메타를 지정하여 독립적으로 제어 할 수 있습니다.
테이블 파티션은 세그먼트를 사용하려면 Oracle8 Enterprise Edition에 들어 있는
Partitioning옵션이 필요합니다,
클러스터
클러스터내의 행은 키 칼럼값에 기초하여 지정됩니다, 클러스터는 하나 이상의 테이블을 저장할 수
있으며 데이터세그먼트의 한 유형입니다, 클러스터 내의 테이블은 같은 세그먼트에 속하며 같은
스토리지 특성을 갖습니다.
인덱스
특정 인데스에 대한 모든 엔트리는 한 인덱스 세그먼트 내에 저장되어 있습니다. 테이블이
세 인덱스를 가지고 있으면 세 인덱스 세그먼트가 사용됩니다. 인덱스 세그먼트의 용도는
지정한 키값을 가지고 테이블 내에서 행의 위치를 조회하는 것입니다.
9-7.세그먼트의 유형
Index-Oragnized 테이블 인덱스 파티션
롤백세그먼트 임시 세그먼트
Index-Oragnized 테이블
Index-Oragnized 테이블에서 데이타 값은 키값에 기초하여 인덱스 내에 저장됩니다,
Index-Oragnized 테이블은 모든 데이타를 인덱스 트리로부터 직접 읽어 올수 있으 므로
테이블을 참조할 필요가 없습니다.
인덱스 파티션
인덱스는 여러 테이블스페이스에 걸쳐 분할(Partition)되어 나뉘어 질 수 있습니다.
이 경우 인덱스의 각 파티션은 하나의 세그먼트 이며 여러 테이블스페이스에 걸쳐 있을 수
없습니다. 분할 된 인덱스는 I/O를 분산시켜 경합을 줄이는데 주로 사용합니다.
인덱스 파티션 세그먼트를 사용하려면 Oracle8 Enterprise Edition의 Partitioning옵션이
필요합니다.
롤백세그먼트
롤백세그먼트는 데이타베이스에 변겨을 가하는 트렌젝션에 의해 사용됩니다.
데이타나 인덱스 블록을 변경하기전에 이전값은 롤백세그먼트에 저장됩니다.
이로써 사용자는 변경을 취소(undo)할 수 있습니다.
임시세그먼트
CREATE INDEX, SELECT DISTINCTM 그리고 SELECT GROUP BY등의 명령을 수행할때 오라클
은
최대한 메모리에서 정렬을 수행하려 하나 크기가 큰 테이블의 인덱스를 생성할때처럼
공간이 많이 필요한 정렬을 수핼 할때는 중간 결과가ㅏ 디스크에 쓰여지기도 합니다.
이러한 경우에 임시세그먼트가 생성 됩니다.
9-9.세그먼트의 유형
LOB세그먼트 LOB인덱스
중첩 테이블(Nested Table) 부트스트렙 세그먼트
LOB세그먼트
테이블에 하나이상의 컬럼을 테스트 문서나, 이미지, 또는 비디오 같은 큰 오브젝트
(LOB, Large object)를 저장하는데 사용할 수 있습니다. 컬럼이 크면 오라클서버는
이값들을 LOB세그먼트라고 불리우는 별도의 세그먼트에 저장합니다. 테이블은 단지
해당 LOB데이타의 위치에대한 위치자(Locator)나 포이터만을 갖고 있습니다.
LOB인덱스
LOB 세그먼터가 생성될때 LOB인덱스 세그먼트도 암시적으로 생성됩니다. LOB인덱스의
스토리지 특성은 데이타베이스 관리자가 지정할 수 있습니다.
LOB인데스 세그먼트의 용도는 특정 LOB칼럼 값을 참조 할 수 있도록 하는 것입니다.
중첩 터ㅔ이블(Nested Table)
테이블의 칼럼은 Order하나의 주문에 대한 품목의 경우 처럼 사용장 정의 테이블로 구성될 수
있습니다. 이러한 경우 중첩테이블잏라 불리는 내부테이블은 별도의 세그먼트에 저장 됩니다.
중첩테이블을 사용하려면 Oracle8 Enterprise Object옵션이 필요합니다.
부트스트렙 세그먼트(Bootstratp Segment)
케쉬세그먼트라고도 불리우는 부트스트렙 세그먼트는 데이타베이스를 생성할때 sql.bsq스크립트
에 의해 생성되며 인스턴스가 데이타베이스를 온픈할때 데이타딕셔너리 초기화를 돕습니다.
부트스트렙 세그먼트를 질의 하거나 갱신 할 수 없으며 데이타베이스 관리자가 관리 할 필요도
없습니다.
주
여러 종류의 세그먼트를 관리하는 명령들과 지침 사항은 뒷장에서 자세히 다루어 질 것입니다.
9-11.Storage 절 우선 순위(Storage Clause Precedence)(**매우중요**)
1. Storage 절은 Segment에 Extent를 할당하는 방법을 제어하도록 Segment 레벨에서 지정할 수
있습니다.
1) Segment 레벨에서 지정한 Storage Parameter는 TableSpace 레벨에서 지정한 설정을 무효화
할 수 있습니다. MINIMUM EXTENT TableSpace Parameter는 예외입니다.
2) Storage Parameter를 Segment 레벨에서 명시적으로 지정하지 않으면 TableSpace 레벨에서
지정한 값이 기본값이 됩니다.
3) Storage Parameter를 TableSpace 레벨에서 명시적으로 설정하지 않으면 오라클 서버는
시스템 기본값을 적용합니다.
2. 그밖의 고려사항
1) Storage가 변경될 경우 새 옵션은 그 이후에 할당되는 Extent에만 적용됩니다.
2) 일부 Parameter는 TableSpace 레벨에서 지정 될 수 없습니다. 이들 Parameter는 Segment
레벨에서만 지정 되어야 합나다.
3) Extent의 최소 크기가 TableSpace에 대해 지정되지 않으면 이후에 TableSpace
의 Segment에 대해 할당되는 모든 Extent에 적용됩니다.
9-12.익스텐트의 할당(Allocation)과 할당 해제(Deallocation)(**매우중요**)
1. 세그먼트가 다음과 같을때 익스텐트가 할당됩니다.
1) +생성될때
2) +확장될때
3) +변경될때
2. 세그먼트가 다음과 같을때 익스텐트가 할당 해제 됩니다.
1) +삭제될때
2) +변경될때
3) +절삭될때(Truncated)
4) +자동적으로 크기가 재조정 될때(롤백세그먼트이 경우에만)
9-13.사용중인(Used) 익스텐트와 사용가능한(Free)익스텐트
1. 테이블스페이스가 생성될때 테이블스페이스의 데이타 파일은 다음 구성요소를 포함합니다.
1) 파일의 첫번째 블록인 헤더블록
2) 데이타 파일의 나머지 부분으로 이루어 지는 사용가능한(Free) 익스텐트 하나
2. 세그먼트는 생성될때 테이블스페이스의 사용가능한 익스텐트로부터 공간을 할당 받습니다.
3. 세그먼트가 사용하는 연속된 공간은 사용중인 공간(Used extent)이라 부릅니다.
4. 세그먼트가 공간을 해제(Release)할때 해제된 익스텐트는 테이블스페이스의 데이타파일 공간의
단편화를 초래 할 수 있습니다.
9-14.사용가능한 영역의 결합(Coalsing Free Space)
ALTER TABLESPACE data01 COALESCE;
일부 익스텐트가 테이블스페이스 내에서 할당해제 될때 연속적인 공간이 해제 될 수 도
있습니다. 예를 들어 테이블 두개가 삭제 될때가 이런 경우 입니다. 공간이 항당 해제 될때
연속공간이 두개 존제할 수 도 있습니다. 이러한 익스텐트는 다음 조건 하에서 하나의
익스텑트로 결합 할 수 있습니다.
.SMON이 인접한 사용가능한 익스텐트를 병합하려고 공간 트렌젝션(space transacion)을
시작할때
.오라클 서버가 하나의 인접 사용 가능 익스텐트보다 더 큰 공간을 팔요로 하는 익스텐트를
할 당해야 할때
.데이타베이스 관리자가 요구 했을때
주
SMON은 PCTINCREASE가 0보가 큰 테이블스페이스에서만 익스텐트를 결합합니다.
사용자 오브젝트를 포함하는 테이블스페이스에 대한 디폴트 스토리지 절의 PCTINCREASE=1설정하여
사용가능한 공간을 자동적으로 결합 할 수 있도록 하십시오
익스덴트 결합
DBA_FREE_SPACE_COALESED뷰에 다음 질의를 사용하여 결합 할 수있는 익스텐트를 가진
테이블스페이스가 있는지 찾아 낼 수 있습니다.
SVRMGR> SELECT tablespace_name, total_extents,
2> percent_extents_coalesced
3> FROM dba_free_space_coalesced
4> WHERE percent_extents_coalesced <> 100;
TABLESPACE_NAME TOTAL_EXTE PERCENT_EX
------------------------------ ---------- ----------
RBS 2 33
DATA01 9 22
9-16.데이타베이스 블록 : 복습
.I/O의 최소 단위
.하나이상의 OS블록 으로 구성
.DB_BLOCK_SIZE로 설정
.데이타베이스 생성시 설정
9-17.데이타베이스 블록 구조
오라클 블럭의 구성 요소는 다음과 같습니다.
.블록헤더:헤더는 데이이타 블록 주소, 테이블 디렉토리, 그리고 트렌젝션이 블록내의 행을
변경 시킬때 사용하는 트렌젝션 슬롯을 포함 합니다. 블록헤더는 윘쪽에서 아래쪽
으로 자랍니다.
.데이타 공간:행 데이타는 블록의 바닥에서 부터 윗쪽으로 삽입 됩니다.
.사용 가능 영역:헤더와 행 데이터가 각 각의 방향으로 필요한 만큼 차지하고 남은 중간
영역 입니다. 블록내의 사용가능영역은 처음에는 연속적입니다. 하지만
삭제와 갱신을 거듭하다 보면 블록내의 사용가능영역의 단편화를 초래
합니다. 블록내의 사용가능 영역은 필요한 경우 오라클 서버가 결합합니다.
9-18.블록 공간 활용 파라메타
INITRANS
MAXTRANS
PCTFREE
PCTUSED
블록 공간 활용 파라메타는 데이타와 인덱스 세그먼트의 공간 사용을 제어하는데 사용할
수 있습니다.
동시성 제어 파라메타
INITRANS와 MAXTRANS는 인덱스, 또는 데이타블록에 생성되는 트렌젝션 슬롯의초기 갯수와
최대 갯수를 지정합니다. 트렌젝션 슬롯은 어느 한 순가 블록에 변경을 일으키는 트렌젝션
에 대한 정보를 저장하는데 사용됩니다. 한 트렌젝션은 비럭 하나이상의 행이나 인덱스
엔트리를 변경하는 경우에도 오직 하나의 트렌젝션 슬롯 만을 사용합니다.
데이타 세그먼트의 경우 기본 값이 1이고 인덱스 세그먼트의 경우는 기본값이 2인 INITRANS
는 최소수준의 동시서을 보장합니다. 예를 들어 INITRANS가 3으로 설정되면 최소 3개의
트렌젝션이 동시에 블록을 변경 할 수 있습니다. 필요하다면 블록의 사용가능 영역에 추가
트렌젝션 슬롯을 할당하여 좀더 많은 트렌젝션이 블록내의 행을 동시에 수정 할 수 있게 허용
할 수 도 있습니다.
기본값이 255인 MAXTRANS는 데이타나 인덱스 블록에 동시에 변경을 가 할 수 있는 트렌젝션의
수를 제한 합니다. 트렌젝션 슬롯을 위한 공간 사용을 MAXTRANS값 만큼으로 제한 하게 되어
행이나 인덱스 데이타가 사용하기에 충분한 블록내의 공간을 보장하게 됩니다.
데이타 공간 사용을 제어하는 파라메타
PCTFREE는 블록내의 행을 갱신 할때 생기는 증가분(growth)에 대비하는 각 데이타 블록의
공간 백분율로서 데이타 세그먼트에 대해 지정됩니다. PCTFREE의 기본값은 10퍼센트입니다
PCTUSED는 오라클 서버가 테이블의 각 데이타블록에 대해 유지하려는 사용공간의 최소
백분률로서 데이타 세그먼트에 대해 지정합니다, 블록의 사용중인 공간이 PCTUSED이하로
떨어지게 되면 그 블록은 사용가능한 블록 목록은 차후에 삽입에 사용될 큰 블록 목록입니다.
기본값으로 한 세그먼트는 사용가능한 목록하나를 가진체 생성됩니다.
스토리지 절의 FREELISTS파라메타를 설정하여 더 많은 수의 사용가능 목록을 가진
세그먼트를 생성할 수 도 있습니다. PCTUSED의 기본값은 40퍼센트 입니다.
PCTFREE와 PCTUSED는 둘 다 사용가능한 데이타 공간 즉 총블록 공간에서
헤더 공간을 뺀 나머지 블록 공간의 백분률로 계산 됩니다.
블록 공간 활용파라메타는 세그먼트 레벨에서 만 지정 할 수 있습니다.
테이블스페이스 레벨에서는 지정 할 수 없습니다.
주
인덱스에 대한 이들 파라메타의 사용법은 "인덱스 관리" 장에서 자세히
다루어 집니다.
FREELISTS지정하기는 Orcle8:Performance Tunning과정에서 자세히
다루어 집니다.
9-20.블록 공간 사용법
PCTFREE=20 PCTUSED=40
다음 단계는 블록내의 공간이 PCFREE=20이고 PCTUSED=40인 테이블 같은
데이터 세그먼트에서 사용되는 방식을 설명해 줍니다.
1.활용률이 80%, 또는 (100-PCTFREE)에 도달 할때까지 행이 블록에
삽입됩니다. 행이 블록 내의 사용 가능한 데이타 공간의 80%를
차지 하게 되면 더 이상 삽입을 할 수 없게 됩니다.
2.나머지 20%는 행의 크기를 증가시키면 사용할 수 있습니다. 예를들어
원래는 NULL이었던 컬럼이 값을 할당 받아 갱신되는 경우 입니다.
그 결과로 블록읠 활용률이 80%를 초과 하게 될 것입니다.
3.블록내의 행이 삭제되거나 갱신 결과로 행의 크기가 감소하게 되면
블록 활용률이 80%이하로 떨어 질 수 있습니다. 하지만 활용률이
PCTUSED이하(위의 경우 40%)로 떨어 지기 전에는 블록에 삽입이
이루어 지지 않습니다.
4.활용률이 PCTUSED이하로 떨어 지면 블록에 삽입이 가능합니다.
블록에 행이 삽입됨에 따랄 블록의 활용률은 증가하게 되고
1단계부터 다시 시작하게 됩니다.
주
PCTFREE와 PCTUSED설정에 대한 지침 사항은 테이블과 인덱스에 대한
장인 "테이블 관리"와 "인덱스 관리"에서 각각 다루어 집니다.
9-21.데이타 딕셔너리 뷰
사용중인 익그텐트 사용가능한 익스텐트
DBA_EXTENTS DBA_FREE_SPACE
세그먼트 데이타 파일
DBA_SEGMENTS DBA_DATA_FILES
테이블 스페이스
DBA_TABLESPACES
테이블스페이스, 데이타 파일, 세그먼트 그리고 익스텐트
(사용중인 것과 사용가능 한것 모두)간의 관계는
데이타 딕셔너리를 조회하면 알 수 있습니다.
하나이상의 파일을 가진 테이블스페이스가 생성 되면
DBA_TABLESPACES에 한 행이 추가 됩니다. 데이타베이스의 각 파일에 대해 DBA_DATA_FILES에
한 행이 추가 됩니다. 동시에 파일 헤더를 제외한 각 데이터 파일 공간은
DBA_FREE_SPACE에 하나의 사용가능한 익스텐트로 보여 집니다.
세그먼트가 생성되면 DBA_SEGMENTS에서 관련된 행을 볼 수 있습니다.
세그먼트의 익스텐트에 할당된 공간은 DBA_EXTENTS에서 볼 수 있습니다.
반면 DBA_FREE_SPACE는 세그먼트에 할당된 익스텐트가 있는 파일의 사용 가능 영역이
줄어 든 것으로 조정 됩니다. 파일내의 모든 공간(헤더 블럭을 제외한)은
DBA_FREE_SPACE나 DBA_EXTENTS에 기록 되어 있어야만 합니다.
9-22.세그먼트 정보
DBA_SEGMENTS
-일반 적인 정보
OWNER
SEGMENT_NAME
SEGMENT_TYPE
TABLESPACE_NAME
-크기 -스토리지 설정
EXTENTS INITIAL_EXNTENT
BOLOKS NEXT_EXTENT
MIN_EXNTENTS
MAX_EXNTENTS
PCTINCREASE
세그먼트에 현제 할당된 익스텐트와 블록의 수를 보려면 DBA_SEGMENTS를 질의 하십시오
SVRMGR>SELECT segment_name, tablespace_name, extents, blocks
2>FROM dba_segments
3>WHERE owner='SCOTT';
SEGMENT_NAME TABLESPACE_NAME EXTENTS BLOCKS
-------------------- ----------------------- ----------- ----------
BIG_EMP USERS 8 195
EMP USERS 1 5
DEPT USERS 1 5
BONUS USERS 1 5
SALGRADE USERS 1 5
DUMMY USERS 1 5
BIG_DEPT USERS 1 5
BIG_EMP_PRIMARY_KEY USERS
5 55
BIG_DEPT_PRIMARY_KEY USERS 1 5
9 rows selected.
9-23.사용중인 익스텐트 정보
DBA_EXTENTS
-식별
OWNER
SEGMENT_NAME
EXTENT_ID
-위치와 크기
TABLESPACE_NAME
RELATIVE_FNO
FILE_ID
BLOCK_ID
BLOCKS
주어진 세그먼트에 대한 익스텐를 보려면 DBA_EXTENTS를 질의 하십시오
SVRMGR> SELECT extent_id, file_id, block_id, blocks
2> FROM dba_extents
3> WHERE owner='SCOTT'
4> AND segment_name='EMP';
EXTENT_ID FILE_ID BLOCK_ID BLOCKS
---------- ---------- ---------- ----------
0 4 12 5
1 4 287 5
2 4 292 10
3 4 302 15
4 4 317 20
5 4 337 30
6 4 367 45
7 4 412 65
8 rows selected.
9-24.사용 가능한 익스텐트 정보
DBMS_FREE_SPACE
-위치와 크기
TABLESPACE_NAME
RELATIVIE_FNO
FILE_ID
BLOCK_ID
BLOCKS
주어진 세그먼트에 대한 정보를 보려먼 DBA_FREE_SPACE를 이용하십시오
SVRMGR>SELECT tablespace_name, count(*), max(blocks), sum(blocks)
2>FROM dba_free_space
3>GROUP BY tablespace_name;
TABLESPACE_NAME COUNT(*) MAX(BLOCKS) SUM(BLOCKS)
-------------------- ----------- ----------- -----------
RBS 1 1259 1259
SYSTEM 8 736 1081
TEMP 1 511 511
USERS 1 1060 1060
9-25.단편화 경향에 따른 테이블스페이스 구성
테이블스페이스 사용 단편화
SYSTEM 데이타딕셔너리 0
TOOLS 응용프로그렘 매우 낮음
DATA 데이타세그먼트 낮음
INDEX 인덱스세그먼트 낮음
RBS 롤백세그먼트 높음
TEMP 임시세그먼트 매우 높음
서로 다른 유형의 세그먼트는 단편화 경향도 서로 다릅니다. 공간 낭비를 최소화 하기 위해
서로 다른 유형의 세그먼트는 서로 다른 테이블스페이스에 배치할 것을 권장합니다.
오브젝트 유형과 단편화
테이블스페이스, 그 사용 , 그리고 단편화 경향에 대한 권장 구조가 테이블에 나타나 있습니다
다음은 단편화 경향이 낮은 순서 대로 나열한 여러 유형의 오브젝트 입니다.
.감사(audit)테이블을 제외한 데이타 딕셔너리 오브젝트는 결코 삭제되거나, 절삭(truncate)
되지 않습니다. 따라서 테이블 스페이스는 거의 단편화 되지 않습니다.
.Oracle Enterprise Manager나 Desigener/2000같은 응용프로그렘의 저장소로 사용되는 공간
공간은 이들 구조를 재조직 할때만 할당 해제 됩니다. 이들 테이블은 재구성 되는 일이
드물기 때문에 단편화 경향이 매우 낮습니다.
.사용자 쓰기 응용프로그렘에 사용되는 데이타 세그먼트와 인덱스 세그먼트는 저장소 보다는
조금 자주 재구성 될 필요가 있습니다. 따라서 응용프로그렘 저장소보다는 조금
더 높은 단편화 경향을 갖습니다.
.롤백세그먼트는 자옫으로 익스텐트를 할당 해제 할 수 있으므로 갱신작업이 잦은 시스템에서
는 단편화를 일으킬 가능성이 있습니다.
.영구 테이블스페이스의 임시 세그먼트는 매우 자주 공간 할당을 해제 할 수 있습니다.
그러므로 이들은 별개의 테이블스페이스에 위채해야만 합니다.
임시 세그먼트는 다음장에서 다루어 집니다.
세그먼트 수명에 따른 구성
세그먼트는 데이타베이스에서 서로 다른 수명을 갖습니다. 예를 들어 소프트웨어 하우스 같은
프로젝트 기반(project-based)환경에서는 시스템 개발이 완료 되었을때 응용프로그렘에 관련된
모든 데이타를 지워야 할 필요가 있습니다. 별도의 테이블스페이스를 사용하여 이 세그먼트를
배치 했다면 지울때 도움이 될 것 입니다. 프로젝트가 끝나면 전체 테이블스페이스를
백업하고 삭제하여 다른 응용프로그렘이 데이타베이스를 사용할 공간을 마련해 줄 수 있을
것입니다.
제10장 롤백세그먼트 관리(Rollback Segments)
10-3.목적
.롤백세그먼트의 갯수와 크기 계획
.적절한 스토리지 설정(storage settings)을 사용하여 롤백세그 먼트 생성
.롤밳그먼트 관리
.데이터딕셔너리의 롤백정보
.롤백 세그먼트 문제해결
10-4.롤백 세그먼트(Rollback Segmet)
* 관리자가 만들어 놓으면 Oracle이 자동적으로 관리한다
* 롤백세그먼트는 프로세스가 데이타베이스의 데이타 변경을 가할때 이전값을
저장하는데 사용됩니다.
* 롤백세그먼트는 수정되기 전의 파일, 블록 id 같은 블럭 정보및 데이타를
저장합니다.
* 롤백세그먼트는의 헤더는 현재 세그먼트를 사용하고 있는 트렌젝션에 대한 정보
를 저장하고 있는 트렌젝션 테이블을 포함하고 있습니다.
* 트렌젝션은 단 하나의 롤백 세그먼트에 롤백(실행 취소)기록 전부를 기록합니다.
많은 트렌젝션이 동시에 하나의 롤백세그먼트에 쓰기를 할 수 있습니다.
10-5.롤백세그먼트의 용도
1. 트렌젝션 롤백
트렌젝션이 테이블 내의 행을 변경할때 구 이미지(before image)는 롤백세그
먼트에 저장 됩니다. 트렌젝션이 롤백되면 롤백세그먼트의 값을 다시 해응로
옮겨 적어 원래 값을 복원합니다.
2. 트렌젝션 복구
트렌젝션이 수행되고 있을때 인스탄스가 비정상적으로 종료되면 오라클 서버는
데이타베이스를 다시 오픈 할때 커밋 되지 않은 변경 사항을 롤백해야 합니다.
트렌젝션 복구 라고 불리는 이와 같은 롤백은 롤백세그먼트에 가해진 변경사항
역시 리두 로그파일에 의해서 보호되어야 만 가능합니다.
3. 읽기 일관성(Read consistency)
트렌젝션이 수행되고 있을때 데이타베이스의 다른 사용자는 이트렌젝션이 커밋
하지 않은 변경 사항은 볼 수가 없습니다, 또한 일단 명령문이 실행된 후 커밋
된 변경사항도 볼수 없어야 합니다. 롤백세그먼트는 옛값은 주어진 명령문에
대한 일관된 이미지를 질의자에게 제공하는데 사용됩니다.
10-6.롤백 세그먼트의 유형
.SYSTEM
.비 system
-전용(privite)
-공용(public)
1. SYSTEM 롤백세그먼트
1) SYSTEM 롤백세그먼트는 데이타베이스가 생성될때 SYSTEM 테이블스페이스내에
생성됩니다.
2) SYSTEM 테이블스페이스내의 오브젝트에 가해진 변경사항 만을 기록합니다.
2. 비 SYSTEM 롤백 세그먼트
- 여러개의 테이블스페이스를 갖는 데이타베이스는 최소한 하나의 비 SYSTEM롤백
세그먼트를 필요로 합니다.
- 데이타베이스 관리자가 생성하는 비 SYSTEM 롤백세그먼트는 비 SYSTEM
테이블스페이스 내의 오브젝트에 가해진 변경사항을 기록합니다.
1) 전용(Private)
전용 롤백세그먼트는 파라메타 파일에 명명하거나 온라인 상태로 바꾸는 명령어
를 실행한 인스턴스만 사용하는 세그먼트 입니다.
2) 공용(Public)
(1) 공용 롤백 세그먼트는 데이타베이스에서 사용 가능한 롤백 세그먼트 풀의 일부
분 입니다.
(2) 공용 롤백 세그먼트는 오라클 병렬서버(Oracle Parallel Server)에서 사용 할
수 있습니다.
3. 주
공용 롤백 세그먼트 사용은 Oracle Parallel SERver Concepts and Administrati
on 설명서를 참조 하십시오
10-8.트렌젝션과 롤백세그먼트
1. 롤백세그먼트의 할당
트렌젝션이 시작되려면 롤벡세그먼트가 할당 되어야 합니다. 트렌젝션은 다음
명령을 사용하여 특정 롤백 세그먼트를 요구 할 수 있습니다.
SET TRANSACTION USE ROLLBACK SEGMENT rollback_segment
이러한 명령이 없으면 오라클 서버는 가장 적은 수의 트렌젝션이 지정된 롤백
세그먼트를 선택하여 할당해 줍니다.
2. 익스텐트의 사용
트렌젝션은 현제의 익스텐트가 꽉 차면 다음 익스템트롤 옯겨 적는 순서 지정
원형 방식(ordered circular fashion)으로 롤백 세그먼트의 익스텐트를 사용합니다
트렌젝션은 롤백세그먼트의 현 위치에 레코드를 기록하고 레코드 크기 만큼 포인
터를 이동 시켜 나갑니다.
3. 예
위의 예에서 두개의 트렌젝션, 트렌젝션1과 트렌젝션2는 4개의 익스텐트를 갖는
롤백세그먼트에 할당 되었습니다.
1) 트렌제션이 시작 되면 롤백세그먼트의 익스텐트 3에 쓰기를 시작합니다.
2) 두 트렌젝션이 롤백정보를 만들어 내어 익스텐트 3에 쓰기를 계속합니다.
3) 익스텐트 3이 가득차면 트렌젝션은 원형의 다음 익스텐트인 익스텐트 4에
쓰기를 시작합니다.
트렌젝션이 새 익스텐트에 쓰기 시작하는 이 단계를 wrap이라고 부릅니다
4) 롤백 세그먼트의 마지막 익스텐트(익스텐트4)도 가득 차게 되면 트렌젝션
은 원형의 맨앞이 사용가능 또는 비활성화 상태이면 그 부분을 사용할 수
있습니다. 현재 익스텐트를 사용하는 활성 트렌젝션이 없는 익스텐트만이
사용가능 또는 비 할성 상태인 것입니다. 즉,그 익스텐트에 기록했던 모든
트렌젝션이 종료된 상태인 경우입니다.
롤백그먼트의 한 익스텐트에 하나 이상의 트렌젝션이 쓰기를 할수 있다는 것을 기억해
주십시오, 하지만 롤백 세그먼트의 각 블록은 오직 하나의 트렌젝션에서 나온 정보만을
기록 할 수 있읍니다.
10-10.롤백세그먼트의 성장(Growth)
현제의 익스텐트가 가득 차게 되면 롤백세그먼트의 포인터 또는 헤드는 다음 익스텐트로 이동
합니다. 현제 사용가능한 마지막 익스텐트가 가득 차게 되었을때 첫 익스텐트가 비어 있을
경우에만 포인터가 첫 익스텐트의 앞부분으로 이동 할 수 있습니다. 포인터는 익스텐트를
건너 뛰어 두번째 , 또는 그 외의 익스텐트로 이동 할 수 없습니다. .첫 익스텐트가 사용중
일 경우 트렌젝션은 롤백세그먼트에 추가 익스텐트를 할당 할 것입니다. 이것을 확장(extend)
라고 부릅니다. 마찬가지로 헤드가 활성 익스텐트로 이동하려 할때도 롤백세그먼트는
추가 익스텐트를 할당할 것입니다. 롤백세그먼트는 이러한 방식으로 MAXEXTENTS파라메타에
지정된 익스텐트의 최대 갯수에 도달 할때 까지 성장(Growth)할 것입니다.
10-11.롤백 세그먼트의 감소(Shrinkage)
OPTIMAL파라메타
OPTIMAL파라메타는 롤백세그먼트가 감소하는 것이 가능할때 감소한 결과의 크기를 바이트
단위로 지정합니다. OPTIMAL을 지정하면 롤백세그먼트내의 공간 낭비를 최소화 할 수
있습니다. OPTIMAL파라메타를 지정하면 롤백세그먼트는 성장(Growth)원인인 트렌젝션이
완료 되었을때 공간 할당을 해제 할 수 있습니다.
익스텐트 할당 해제가 트렌젝션이 완료되자 마자 행해지는 것은 아닙니다. 익스텐트 할당
해제 과정은 헤드가 한 익스텐트에서 다른 익스텐트로 옮겨 갈때에만 수행 됩니다.
익스텐트가 할당해제되는 경우는 다음과 같습니다.
.롤백세그먼트의 현재크기사 OPTIMAL을 초과 앴을때
.연속적인 비 활성 익스텐트가 있을때
오라클 서버는 OPTIMAL값과 롤백세그먼트의 크기가 같아 질때 까지 롤백세그먼트의 할당을
해제 하려고 합니다. 하지만 할당 해제 하려 하는 다음 익스텐트가 사용중 이라면 즉시 멈추
어야 합니다.
오라클 서버는 항상 읽기 일관성을 위해 사용될 가능성이 적어 보이는 가장 오래된 비활성
익스텐트의 할당을 해제 합니다.
10-12.읽기 일관성(Read-Consistency)
오라클 서버는 문장 수행도중 데이터가 어느 트렌젝션에 의해 수행되었을 경우라도 일관된
시점의 데이타를 볼 수 있도록 보장 합니다.
오라클 서버는 Select문을 실행할때 현 SCN을 결정하고 결정한 SCN 이전의 커밋되지 않은
변경 사항들은 Select문을 수행한 결과고 표시 하지 않습니다. 실행시간이 긴 질의
SELECT first_name, dept_id, salary
FROM s_emp a
WHERE salary > (SELECT AVG(salary) FROM s_emp b
WHERE b.dept_id=a.dept_id);
가 수행되고 있는 동안 몇건의 변경이 이루어지는 예를 생각해 봅시다. 어떤 블록이
질의가 시작될때 커밋되지 않은 변경사항을 가지고 있다면 오라클 서버는 롤백세그먼트에서
변경이전 이미지를 읽어 들이고 변경 사향을 메모리 내의 블록 사본에 적용시켜 읽기
일관성 이미지를 구축합니다.
읽기 일관성은 트렌젝션 앞 부분에 다음 명령을 넣어 줌으로써 트렌젝션내의 여러명령문에서
동일한 읽기 일관성을 요구 할 수 있습니다.
SET TRANSACTION READ ONLY
이경우 오라클 서버는 트렌젝션 도중 필요할 때마다 구 이미지(Before image)를 읽어 들이기
위해 롤백세그먼트를 읽을 것입니다.
오라클 서버가 명령문에 대해, 또는 read-only트렌젝션에서 데이타의 시간 일관성을 이미지를
제공할 수 없다면 사용자는 ORA-1555 Snapshot too old 에라를 만나게 될 것입니다.
뒷 절에서 자세히 다루어 집니다.
10-13.롤백세그먼트 계획:갯수
OLTP
-크기는 작지만 많은 수의 세그먼트
-트렌제션 4개 당 RBS 한개
Batch
-크기는 크지만 적은 수
롤백세그 먼트의 헤더는 각 트렌젝션의 상태를 정의하는 트렌젝션 테이블 엔트리를
포함하고 있습니다. 롤백세그먼트를 사용하는 모든 트렌젝션은 트렌젝션 테이블을 자주 갱신
할 필요가 있습니다. 이 경우 특히 OLTP환경에서는 헤더에 경합이 발생할 수 있습니다.
대체적으로 OLTP가 짤막한 트렌젝션을 사용하는 경우이므로 크기는 작지만 많은 수의
롤백세그먼트가 권장됩니다. 가능하다면 동시에 진행되는 4개의 트렌젝션마다 롤백세그먼트
하나씩을 생성하십시오
일괄처리(batch)환경에서는 일반적으로 많은 변경을 할 필요가 있는 비교적 적은 수의
작업을 수행하므로 큰 롤백세그먼드를 필요로합니다. 그러므로 일괄처리 환경에서는
큰 테이블스페이스내에 롤백세그먼트를 생성하여 성장(growth)해 나갈 수 있도록 합니다.
10-15.롤백세그먼트 생성
예
CREATE ROLLBACK SEGMENT rbs01
TABLESPACE rbs
STORAGE(INITIAL 100K
NEXT 100K
OPTIMAL 4M
MINEXTENTS 20
MAXEXTENTS 100);
구문
CREATE [PUBLIC] ROLLBACK SEGMENT rollback_segment
[TABLESPACE tablespace]
[STORAGE ([INITIAL integer [K|M] ]
[NEXT integer [K|M] ]
[MINEXTENTS integer]
[MAXEXTENTS {integer | UNLIMITED} ]
[OPTIMAL {integer [K|M] NULL} ]
)
제한사항
.롤벡세그먼트는 생성시 PUBLIC이나 PRIVIATE(기본값)로 지정할 수 있습니아,
이후에는 변경할수 없습니다.
.롤벡세그먼트의 경우 MAXEXTENTS는 2보다 크거나 같아야 합니다.
.롤벡세그먼트의 경우 PCTINCREASE값은 설정할 수 없으며 항상 0으로
설정됩니다.
.OPTIMAL을 지 듖狗존?최소한 롤백세그먼트의 초기크기 MINEXTENS로 정의 한
갯수의 익스텐트 만큼의 공간 크기와 같아야 합니다.
지침사항
.롤벡세그먼트의 경우 항상 INITIAL=NEXT로하여 모든 익스텐트가 동일한 크기를 갖도록
하십시오
.OPTIMAL값을 평균트렌젝션에 필요한 공간에 기초하여 설정하십시오.
적당한 데이타가 없으면 초기크기로 설정하고 나눙에 튜닝하십시오
.MAXEXTENTS를 UNLIMITED로 성정하지 마십시오, 프로그렘에러시 이렇게 설정하면
롤벡세그먼트와 데이타파일에 불필요한 확장을 유발 할 수 도 잇습니다.
경합과 단편화를 피할 수 잇도록 롤벡세그먼트를 할상 별개의 배타적 테이블스페이스에
위치시키십시오
10-17.온라인 롤백세그먼트로 만들기
.롤벡세그먼트를 사용가능하게 만들려면 다음명령을 사용하십시오.
ALTER ROLLBACK SEGMENT rbs01 ONLINE;
.STARTUP시 롤벡세그먼트가 온라인 상태가 되도록 하려면 다음초기화 파라메타를 시정하십시오
ROLLBACK_SEGMENTS=(rbs01)
롤벡세그먼트는 생성될때 항상 오프라인 상채이며 사용할 수 없는 상태입니다.
트렌젝션이 롤벡세그먼트를 사용할 수있게 만들려면 ALTER ROLLACK SEGMENT명령을 사용하여
롤벡세그먼트를 온라인으로 만드싲시오
구문
롤벡세그먼트를사용가능하게 만들 려면 다음 명령을 사용하십시오
ALTER ROLLBACK SEGMENT rollback_segment ONLINE;
인스타스가 온라인 상태로 할 수 있는 롤백세그먼트 갯수는 MAX_ROLLBACK_SEGMENT파라메타로
제한 됩니다. 인스탄스에 필요한 비 system롤백세그먼트의 갯수 보다 하나더 많도록
설정하십시오.
롤백세그먼트는 인스탄스가 종료될때까지 온라인 상태입니다. 인스탄스가 롤백세그먼트를항상
온라인 상태가 되도록 하려면 아애 예제와 같이 파라메타 파일에서 롤백세그면트이름을
지정하십시오
ROLLBACK_SEGMENTS=(rbs01)
1-19.인스타스가 롤백세그먼트를 획득하는 방법
다음 단계는 데이타베이스가 오픈 될때 인스탄스가 롤백세그 먼트를 획득하는 방법입니다.
1.인스탄스는 초기화 파라메타 ROLLBACK_SEGMENTS에 명명된 모든 롤백세그먼트를 획득합니다.
2.인스탄스에 필요한 롤백세그먼트의 갯수를 계산하는데는
TRANSACTIONS와 TRANSACTIONS_PER_ROLLBACK_SEGMENT를 사용합니다.
n = T / TPR
n 필요한 롤백세그먼트 갯수
T TRANSACTIONS파라메타 값
TPR TRANSACTIONS_PER_ROLLBACK_SEGMENT파라메타 값트
필요한 롤백세그먼 개수를 파악하기 위해 인스탄스가 그저 하나의 기준으로
이들 파라메타들을 사용할 뿐이라는 것을 명심하십시오
어떤방법으로도 인스탄스내 또는 롤백세그먼트당 트렌젝션을 제한 하지 않습니다.
3.전 단계에서 구해진 값 n이 이미 획득한 비 SYSTEM롤백세그먼트의
갯수보다 작거나 같다면 인스탄스는 더이상 롤백 세그면트를 필요로 하지 않습니다.
4.n값이 이미 인스탄스가 사용 가능한 비 시스템 롤백세그먼트 보다 크다면
추가 공용롤백세그 먼트를 획득하여 부족분을 보충할 것입니다. 공용
롤백세그먼트가 충분하지 않더라도 데이타베이스는 여전히 사용자에게
오픈되어 사용가능하며, 어떤 에러도 발생하지 않습니다.
5.롤벡세그먼트 스토리지 설정 변경
ALTER ROLLBACK SEGEMT를 사용
ALTER ROLLBACK SEGMENT rbs01
STORAGE(MAXEXTENTS 200);
롤백세그먼트 스토리지 파라메타는 애에 주어진 ALTER ROLLBACK SEGMENT명령
을 사용하여 변경할 수 있습니다.
ALTER ROLLBACK SEGMENT rollback_segment
[STORAGE ( [NEXT integer [K|M] ]
[MINEXTENTS integer]
[maxextents {integer | UNLIMITED} }
[OPTIMAL {integer [K|M] | NULL } ]
)
]
OPTIMAL 또는 MAXEXTENTS VKFKAPXK를 제정의하는데 위 윔명어를 사용하십시오
10-22.롤벡 세그먼트의 공간 하\할당 해제
ALTER ROLLBACK SEGMETN rbs01
SHRINK TO 4M;
롤벡세그먼트에 OPTIMAL 이 지정 되어 있으면 오라클 서버는 OPTIMAL크기이상의
공간을 해제 하기 위해 익스텐트 할당을 해제 하려 할 것입니다.
구분
롭백세그먼트에서 수동으로 공간 할당을 해제히려면 다음 명령을 사용하십시오
ALTER ROLLBACK SEGMENT rollback_segment
SHRINK [ TO integer [K|M]];
.롤백세그먼트의 크기를 지정한 크기로 줄이려 시도합니다. 하지만
익스텐트가 활성화 되어 있어 할당을 해배 할 수 없을 경우는 즉시 중단 할 것입니다.
.integer를 지정하지 않으면 오라클 서버는 롤백세그먼트가 optimal과
같아질때까지 익스텐트를 할당해제 하려고 할것입니다.
.지정된 integer가 현재의 롤백세그면트 크기보다 크다면 이명령은 무기
됩니다.
10-24.오프라인 롤백세그먼트
롤백세그먼트를 사용할 수 없게 만들려면 오프라인 상태로 만듭니다.
ALTER ROLLBACK SEGMENT rbs01 OFFLINE;
다음 경우 롤백세그먼트를 오프라인 상태로 만드십시오
.새트렌젝션이 롤백세그먼트를 사용하는 것을 막으려 할때
.롤백세그먼트를 삭제해야 할때
구문
다음 명령을 사용하여 롤백세그먼트를 오프라인 상태로 만드시오
ALTER ROLLBACK SEGMENT rollback_segment OFFLINE;
트렌젝션이 사용중인 롤밳그먼트에 대해 위 명령을 실행하면, 동적
성능뷰 V$ROLLSTATㅔ서 볼 수 있듯이 롬벡세그면트의 상태는 PENDING OFFLINE
으로 설정 됩니다. 그리고 현재의 진행중인 모든 트렌젝션이 완료되자 마자
에스먼트는 오프라인 상태가 될것입니다.
10-25.롤벡세그먼트의 삭제
롤백세그먼트는 오프라인 상태에서만 삭제 할 수 있습니다.
DROP ROLLBACK SEGMENT rbs01;
구문
롤백세그먼트를 삭제하려면 다음 명령을 사용하십시오
DROP ROLLBACK SEGMENT rollback_segment;
롤백세그먼트는 더 이상 필요가 없거나 INITIAL, NEXT, MINEXTENTS등을
다른 스토리지 설정으로 재생성할 필요가 있을때 삭제 되어야 합니다.
롤백세그먼트를 삭게하려면 오프라인 상태이어야 합니다.
10-26,데이타베이스의 롤백세그먼트
DBA_ROLLBACK_SEGS
SVRMGR> SELECT segment_name, tablespace_name, owner, status
2> FROM dba_rollback_segs;
SEGMENT_NAME TABLESPACE_NAME OWNER STATUS
------------------------------ ------------------------------ ------ ----------------
SYSTEM SYSTEM SYS ONLINE
RBS01 RBS PUBLIC ONLINE
RBS02 RBS PUBLIC ONLINE
3 rows selected.
롤백 세그먼트 RBS3이 오프라인인 것을 주목하십시오. 오프라인인 롤백 세그
먼트에 대한 정보는 DBA_ROLLBACK_SEGS에서만 볼 수 있으며, 현재 인스턴트가
사용하고 있는 롤백 세그먼트만을 보여주는 동적 성능 뷰에서는 볼수 없습니다.
OWNER 컬럼은 롤백 세그먼트 유형을 지정합니다.
.SYS는 전용 롤백 세그먼트를 뜻합니다.
.PUBLIC은 공용 롤백 세그먼트를 뜻합니다.
10-27 롤백 세그먼트 통계
V$ROLLNAME V$ROLLSTAT
USN <--------> USN
NAME EXTENTS
RSSIZE
XACTS
OPTSIZE
HWMSIZE
AVEACTIVE
STATUS
CUREXT
CURBLK
현재 인스턴스가 사용하고 있는 롤백 세그먼트에 대한 통계를 얻으려면 V$ROLLSTAT와
V$ROLLNAME 뷰를 조인 하십시오.
예
SVRMGR> SELECT n.name, s.extents, s.rssize, s.optsize,
2> s.hwmsize, s.xacts, s.status
3> FROM v$rollname n, v$rollstat s
4> WHERE n.usn = s.usn;
NAME EXTENTS RSSIZE OPTSIZE HWMSIZE XACTS STATUS
----- --------- -------- ----------- ---------- ------- ---------
SYSTEM 43 2199552 2199552 0 ONLINE
RBS1 20 202752 204800 417792 0 ONLINE
RBS2 4 38912 38912 0 PENDING
OFFLINE
3 ROWS selected
v$ROLLSTAT의 컬럼은 다음과 같습니다.
컬럼 설명
USN 롤백 (실행 취소) 세그먼트 번호,세그먼트의 이름을 알려면 V$ROLLNAME.USN과
조인하십시오.
EXTENTS 롤백 세그먼트의 익스텐트 갯수
RSSIZE 바이트 단위로 나타낸 세그먼트 현재 크기
XACTS 세그먼트를 사용중인 트랜잭션 갯수
OPTSIZE 롤백 세그먼트의 OPTMAL 값
HWMSIZE Hight water mark, 세그먼트가 사용된 이후 최대로 많이 사요하였던
크기를 바이트 단위로 나타냅니다.
AVEACTIVE 시간에 대해 평균한 현재 활성 익스텐트의 크기
STATUS 롤백 세그먼트의 상태. (ONLINE은 롤백 세그먼트가 사용 가능함을
의미합니다. PENDING OFFLINE은 롤백 세그먼트를 오프라인으로 만드는
명령이 수행되었으나 아직 세그먼트를 사용하는 활성 트랜잭션이 있음을
의미하며 롤백 세그먼트를 사용하는 트랜잭션이 전부 완료되자마자 오프라인
상태가 될 것입니다)
CUREXT 롤백 세그먼트 헤드의 현재 위치(익스텐트와 블록의 번호)
CURBLK
주
. 롤백 세그먼트에 대한 OPTMAL 값은 V$ROLLSTAT 뷰에서만 얻어질 수 있습니다.
. 롤백 세그먼트가 PENDING OFFLINE 일때 DBA_ROLLBACK_SEGS에서는 ONLINE으로 나타납니다.
10-28 사용중인 롤백 세그먼트
V$SESSION V$TRANSACTION
SDDR <----------> SES_ADDR
USENAME XIDUSN
SID UBAFIL
SERIAL# UBABLK
UBASQN
UBAREC
STATUS
USED_UBLK
USED UREC
현재 활성중인 트랜잭션이 사용하고 있는 롤백 세그먼트를 점검해 보려면
V$TRANSACTION과 V$SESSION 뷰를 조인하십시오.
예
SVRMGR> SELECT s.username, t.xidusn, t.uafil,
2> t.ubablk, t.used_ublk
3> FROM v$session s, v$transaction t
4> WHERE s.saddr = t.ses_addr;
USERNAME XIDUSN UBAFIL UBABLK USED_DBLK
----------- ----------- ------------ ------------ --------------
SYSTEM 2 2 7 1
SCOTT 1 2 163 1
2 rows selected
V$TRANSACTION의 관련 컬럼과 설명은 다음과 같습니다.
컬럼 설명
SES_ADDR 세션 주소, V$SESSION.SADDR 과 조인될 수 있음.
SIDUSN 트랜잭션이 사용하는 롤백 세그먼트 번호, 트랜잭션 ID의 일부로 사용됨.
UBAFIL UBAFIL, UBABLK, UBASQN , 그리고 UBAREC 컬럼은 트랜잭션이 기록중인 롤백
UBASQN 세그먼트의 현 위치 지정
UBAREC
USED_UBLK 트랜잭션이 만들어 내는 실행 취소 블록의 개수
START_UEXT 트랜잭션이 쓰기 시작할 롤백 세그먼트 익스텐트
START_UBAFIL 트랜잭션이 쓰기 시작할 롤백 세그먼트 파일번호
START_UBABLK 트랜잭션이 쓰기 시작할 롤백 세그먼트 블록 번호
10-29 롤백 세그먼트 문제
.트랜잭션에 불충분한 공간
.읽기 일관성 에러
.Blocking 트랜잭션
.테이블스페이스를 오프라인 상태로 만들 때 발생하는 에러
10-30 트랜잭션에 불충분한 공간
.테이블스페이스에 공간이 없을 때
- 데이터 파일 확장
- 데이터 파일의 자동 확장 허가
- 데이터 파일 추가
.세그먼트가 MAXEXTENTS에 도달했을 때
- MAXEXTENTS를 증가
- 더 큰 크기의 익스텐트를 갖는 세그먼트 재생성
@ 가능한 원인
트랜잭션이 여러 롤백 세그먼트를 사용할 수 없기 때문에 롤백 세그먼트에
충분한 공간이 없으면(ORA-01562) 트랜잭션이 실패할 수 있습니다. 그 원인으로
다음중의 하나가 될 수 있습니다.
. 테이블스페이스에 충분한 공간이 없을 때
. 롤백 세그먼트의 익스텐트 수가 MAXEXTENTS에 도달하여 추가 익스텐트를 할당
할 수 없을 때
@ 해결책
테이블스페이스가 빈 공간을 가지고 있지 못하다면 다음 방법으로 테이블스페이스가
사용할 수 있는 공간을 증가시키십시오.
. 테이블스페이스 내의 데이터 파일 확장
. 데이터 파일에 AUTOEXTEND 허용
. 테이블스페이스에 파일 추가
롤백 세그먼트가 MAXEXTENTS에 의한 한계에 도달하여 더 이상 익스텐트를 할당할 수
없다면 다음과 같이 하십시오.
. 롤백 세그먼트에 대한 MAXEXTENTS를 증가
. 롤백 세그먼트를 삭제하고 더 큰 크기의 익스텐트를 갖는 롤백 세그먼트를 재성성
하여 문제 재발을 방지
10-31 읽기 일관성 에러
@ 가능한 원인
읽기 일관성 절에서 설명했듯이 오라클 서버는 명령문을 수행하는 순간에 커밋되어 있는
데이터만 처리하도록 보장합니다. 명령문이 시작될 때 커밋되지 않은 변경 사항이나 명령문이
수행되지 시작한 후에 가해진 변경 사항은 해당 명령문을 통햇서는 볼 수 없습니다. 오라클 서버가
데이터의 읽기 일관성 이미지를 구성할 수 없다면 사용자는 ORA-01555 SNAPSHOT TOO OLD 에러를
받게 될 것입니다. 이 에러는 변경을 일으킨 트랜잭션이 이미 커밋하고 다음과 같이 되었을 때
발생할 수 있습니다.
. 롤백 헤더의 트랜잭션 슬롯이 재사용되었을 때
. 롤백 세그먼트의 이전 이미지(BEFORE IMAGE)가 다른 트랜잭션에 의해 겹쳐 쓰여졌을 때
@ 해결책
읽기 일관성 에러는 롤백 세그먼트를 다음과 같이 생성함으로써 최소화시킬 수 있습니다.
. 보다 높은 MINEXTENTS
. 보다 큰 익스텐트 크기
. 보다 높은 OPTMAL 값
MAXEXTENTS를 증가시켜서는 회피할 수 없음을 명심하십시오.
10-32 Blocking 세션
@ 가능한 원인
롤백 세그먼트의 한 익스텐트가 가득 차게 되면 오라클 서버는 원형 내의 다음 익스텐트를 재사용하려 합니다.
다음 익스텐트가 단 하나의 활성화된 엔트리라도 갖고 있다면(즉, 아직도 활성화 상태인 트랜잭션이 기록한 엔트
리가
있다면) 재사용될 수 없습니다. 이런 경우 롤백 세그먼트는 추가 익스텐트를 할당합니다. 트랜잭션은 고리 내의
한 익스텐트를 건너 뛰어 그 다음 대기하는 트랜잭션은 많은 빈 익스텐트에 쓰기를 계속할 수는 없습니다. 변경
은 거의
하지않고 오랜 시간을 대기하는 트랜잭션은 많은 빈 익스텐트가 있음에도 불구하고 롤백 세그먼트를 성장하게
만들 수
있습니다. 이러한 상화에서는 많은 공간이 낭비되게 되므로 데이터베이스 관리자는 롤백 세그먼트가 과다하게
성장하지 않도록
개입해야 합니다.
Blocking 세션 검출하기
Blocking 트랜잭션을 찾아내려면 v$ROLLSTAT, V$SESSION, 그리고 V$TRNASACTION 뷰를 질의하십시오.
10-32 테이블스페이스를 오프라인 상태로 만들 때 발생하는 에러
활성 RBS를 포함하고 있는 테이블스페이스는 오프라인 상태로 만들 수 없습니다.
.테이블스페이스의 롤백 세그멘트를 점검하십시오.
.롤백 세그먼트를 사용하고 있는 활성 트랜잭션을 찾으십시오.
.세션 ID와 일련 번호(SERIAL NUMBER)를 찾으십시오.
.
필요하다면 세션을 종료시키십시오.
@문제 진단과 해결
테이블스페이스가 하나 이상의 활성 롤백 세그먼트를 포함하고 있다면 오프라인이 될 수 없으면
오프라인이 될 수 없으며 오프라인을 수행하려고 하는 세션은 ORA-01546에러를 받게 될 것입니다.
이런 상황이 발생하면 다음 단계를 수행하십시오.
1. DBA_ROLLBACK_SEGS를 질의하여 테이블스페이스 내에 어떤 롤백 세그먼트가 있는지 찾아 보십시오.
2. 테이블스페이스의 모든 롤백 세그먼트를 오프라인 상태로 만드십시오.
3. V$TRANSACTION을 검사하여 현재 어떤 트랜잭션이 이를 롤백 세그먼트를 사용하고 있는지 확인하십시
오.
4. V$SESSION 을 사용하여 사용자 이름과 세션 정보를 얻으십시오.
5. 테이블스페이스를 오프라인 상태로 만드십시오.
11장 임시 세그먼트( Temporary Segments)
목적 - 서로 다른 유형의 임시 세그먼트 구별
- 데이터베이스 내에 임시 세그먼트용 공간 할당
- 데이터베이스나 인스턴스를 위한 임시 세그먼트 정보
11-1 임시 세그먼트
@ 임시 세그먼트 사용
임시 세그먼트는 다음과 같은 명령문이 수행되거나 오라클 서버가 메모리에서 필요한 정렬을 수행할
수 없을 때 사용됩니다.
SELECT... ORDER BY
. CREATE INDEX
. SELECT DISTINCT
. SELECT... GROUP BY
. SELECT... UNION
프로세스가 정렬에 사용하는 메모리의 총량은 초기화 파라미터 SORT_AREA_SIZE에 의해 결정됩니다.
정렬에 필요한 공간이 이 크기를 초과하게 되면 정렬을 여러번에 나누어 수행하며 중간 결과는 디스크에
저장됩니다. 임시 세그먼트는 정렬을 위해 사용자에게 할당된 테이블스페이스 내에 오라클 서버가
생성하여 사용합니다.
주
. SORT_AREA_SIZE는 각 세션이 사용하는 메모리에 영향을 끼치므로 이 값을 증가시키면 메모리 요구량이
현저히 증가될 수 있습니다.
. 정렬에 사용하는 테이블스페이스를 할당하는 것은 "사용자 관리"장에서 다루어 집니다.
.SORT_AREA_SIZE 지정하기는 ORACLE 8: PERFORMANCE TUNING 과정에서 다루어 집니다.
@ 임시 세그먼트의 유형
임시 세그먼트는 PERMANENT 테이블스페이스나 TEMPORARY 테이블스페이스 모두에 생성될 수 있습니다.
정렬을 위해서 사용자는 이 중 한가지 유형의 테이블스페이스를 할당받을 것입니다.
임시 테이블스페이스
TEMPORARY테이블스페이스는 임시 시그먼트용으로만 사용되며 다른 유형의 세그먼트를 가질 수 없습니다.
TEMPORARY 테이블스페이스를 생성하는 명령은 다음과 같습니다.
CREATE TABLESPACE tablespace_name TEMPORARY
DATAFILE filespec [autoextent_clause]
[ , filespec [autoextend_clause] ]...
PERMANENT 테이블스페이스는 다음명령을 사용하여 TEMPORARY테이블스페이스로 바뀔 수 있습니다.
ALTER TABLESPACE tablespace_name TEMPORARY
이 명령이 수행되면 TEMPORARY테이블스페이스는 다음 명령을 사용하여 PERMANENT 테이블스페이스로 전
환될 수 있습니다.
ALTER TABLESPACE tablespace_name PERMANENT
@영구 테이블스페이스내의 임시 세그먼트
.트랜잭션 단위의 필요할때마다 생성
.명령문의 수행이 끝났을때 SMON에 의해 회수
오라클 서버는 다음조건이 충족되면 임시 세그먼트를 PERMANENT테이블스페이스에 생성할 수 있습니다.
. 사용자가 디스크상의 정렬 공간을 필요로 하는 명령문을 실행할때
. 명령문을 수행하는 사용자가 정렬을 위해 PERMANENT테이블스페이스를 할당받았을때
PERMANENT테이블스페이스가 정렬을 위해 사용되면 인스턴스는 테이블스페이스에 하나 이상의 임시 세그먼트
를 가질수 있습니다.
명령문이 완료되면 임시 세그먼트는 SMON에 의해 삭제되 공간은 다른 오브젝트가 사용할 수 있도록 해제됩니
다.
PERMANENT테이블스페이스가 정렬을 위해 사용되면 테이블스페이스내의 빈 공간은 심하게 단편화 될 수 있습
니다.
따라서 정렬만을 위한 테이블스페이스로 사용할 것을 권합니다.
@임시 테이블스페이스내의 임시세그먼트
.정렬 세그먼트라 알려져 있습니다.
.인스턴스, 테이블스페이스당 하나의 세그먼트
.인스턴스가 시작된 후 첫번째 디스크 정렬이 발생하면 생성됩니다.
.정렬 인스텐트 풀(Sort Extent Pool)내의 정보에 따라 여러 트랜잭션에 의해 재사용됩니다.
.인스턴스가 종료될 때 해제됩니다.
TEMPORARY테이블스페이스가 임시 세그먼트를 위해 사용되면 인스턴스는
테이블스페이스에 단 하나의 정렬 세그먼트만을 생성합니다. 디스크 정렬을
요구하는 여러 트랜잭션이 한 세그먼트를 사용할 수 있습니다. 익스텐트는 여러개의
트랜잭션이 공유할 수 있습니다.
정렬 세그먼트 사용
정렬 세그먼트는 시작 후 정렬을 위해 TEMPORARY 테이블스페이스를
사용하는 첫 명령문에 의해 생성됩니다. TEMPORARY테이블스페이스에
생성된 정렬 세그먼트는 종료시에만 해제됩니다. 이렇게 함으로써 정렬을
필요로 하는 작업에 의해 익스텐트의 할당, 해제가 너무 자주 발생하는 것을
감소시켜 주어 성능 향상에 도움이 됩니다. TEMPORARY테이블스페이스에
생성되는 정렬 세그먼트를 위한 익스텐트의 갯수에는 제한이 없습니다.
정렬 익스텐트 풀(Sort Extent Pool)
오라클 서버는 SGA의 정렬 익스텐트 풀이라는 영역에 정렬 세그먼트를 위한
상세 정보를 유지하며 테이블스페이스내에서 정렬을 위한 공간을 할당받고자
하는 명령문은 사용 가능한 익스텐트를 찾기 위해 이 공통 풀을 검사합니다.
@임시 세그먼트에 대한 지침 사항
.필요한 정렬에 따라 서로 다른 TEMPORARY 테이블스페이스를 설정하십시오.
.임시테이블스페이스는 다음과 같이 DEFAULT STORAGE를 지정하십시오.
- INITIAL=NEXT=(multiple of SORT_AREA_SIZE)+DB_BLOCK_SIZE
- PCTINCREASE=0
정렬의 동시성을 향상시키고 공간의 자자은 할당, 해제를 감소시키려면 TEMPORARY
테이블스페이스를 생성하고 사용하십시오. 임시 세그먼트가 사용하는 익스텐트의
크기는 테이블스페이스에 대해 지정되는 DEFAULT STORAGE절에 의해 지정됩니다.
DEFAULT STORAGE 지정하기
다음 지침 사항을 따라 DEFAULT STORAGE를 지정하십시오.
.INITIAL=NEXT로 설정하십시오. 프로세스는 항상 SORT_AREA_SIZE만큼의
데이터를 임시세그먼트에 쓰므로 익스텐트 크기로 적당한 값은 (n*s+b)입니다.
여기서:
n은 양수
s는 SORT_AREA_SIZE 초기화 파라미터의 값
b는 DB_BLOCK_SIZE 초기화 파라미터의 값
이 값을 사용하면 헤더 블록과 각 익스텐트마다의 데이터에 대한 여러 정렬에 충분한
공간을 허락하게 되어 임시 세그먼트 사용을 최적화하게 됩니다.
.모든 익스텐트가 같은 크기를 갖도록 PCTINCREASE의 값을 0으로 지정하십시오.
.테이블스페이스가 PERMANENT테이블스페이스이면 MAXEXTENTS는
임시세그먼트에만 영향을 줍니다.
주
서로 다른 디폴트 스토리지절을 갖는 테이블스페이스를 여러개 생성하여
사용자의 정렬 요구에 맞춰 할당하십시오.
@ 데이터베이스 인스턴스에 대한 정보
임시세그먼트와 그 사용에 대한 정보를 얻을 수 있는 뷰는 다음과 같습니다.
. DBA_SEGMENTS
두 유형의 임시세그먼트 정보를 얻고자 할 때 사용하십시오.
. V$SORT_SEGMENT
인스턴스가 사용하는 정렬 익스텐트 풀의 상태를 보여 줍니다.
. V$SORT_USAGE
현재 인스턴스에 할성화되어 있는 정렬만을 보여 줍니다.
@정렬 세그먼트의 통계
V$SORT_SEGMENT
.TABLESPACE_NAME
.EXTENT_SIZE
.TOTAL_EXTENTS
.TOTAL_BLOCKS
.USED_EXTENTS
.USED_BLOCKS
.FREE_EXTENTS
.FREE_BLOCKS
.MAX_SORT_SIZE
.MAX_SORT_BLOCKS
정렬 세그먼트와 그 사용 통계를 포함하고 있는 TEMPORARY 테이블스페이스를 검사해
보려면 V$SORT_SEGMENT뷰를 질의하십시오.
예
SVRMGR> SELECT tablespace_name, extent_size,
total_extents, max_sort_blocks
FROM v$sort_segment;
TABLESPACE_NAME EXTENTS_SIZ TOTAL_EXTE MAX_SORT_B
--------------- ----------- ---------- ----------
TEMP 128 1 128
1 row selected.
MAX_SORT_SIZE와 MAX_SORT_BLOCKS 컬럼은 해당 세그먼트를 사용한 가장 큰 정렬
작업에 의해 사용된 익스텐트와 블록의 갯수를 보여 줍니다. 이 정보는 TEMPORARY
테이블스페이스의 크기를 정하는데 유용합니다.
@임시 세그먼트 작업 내용
V$SESSION V$SORT_USAGE
SADDR SESSION_ADDR
USERNAME TABLESPACE
SID CONTENTS
EXTENTS
BLOCKS
인스턴스에서 현재 작업중인 정렬에 대한 정보를 얻으려면 V$SESSION과 V$SORT_USAGE
뷰를 조인하십시오.
예
SVRMGR> SELECT s.username, u."USER", u.tablespace,
u.contents, u.extents, u.blocks
FROM v$session s, v$sort_usage u
WHERE s.saddr=u.session_addr;
USERNAME USER TABLESPACE CONTENTS EXTENTS BLOCKS
-------- ---- ---------- --------- ------- ------
SYSTEM SYS TEMP TEMPORARY 1 128
1 row selected.
V$SORT_USAGE의 USER 컬럼은 항상 정렬을 수행하고 있는 사용자가 아닌 이 뷰를
질의하고 있는 사용자를 나타냅니다. 정렬을 수행하고 있는 사용자의 이름은 V$SESSION
뷰에서 얻으십시오. CONTENTS컬럼은 임시 세그먼트가 PERMANENT테이블스페이스에
생성되었는지 TEMPORARY 테이블스페이스에 생성되었는지를 보여 줍니다.
제12장 테이블 관리
12-3.목적
.서로 다른 오라클 데이타 유형
.적절한 스토리지 설정을 이용하여 테이블 생성
.테이블이 사용하는 공간제어
.테이블을 분석하여 무결성(intergrity)과 이전 Migration체크
.데이터 딕셔너리의 테이블에 대한 정보
.서로 다른 형식의 ROWID간의 변환
12-4.사용자 데이터 저장
오라클 데이타베이스에서 사용자 데이타는 다음중 한가지 방법으로 저장할수 있습니다.
.정규테이블
.분할 테이블(Partioned Table)
.Index-oragainized 테이블(Index-Organized tables)
.클러스트 테이블(Clustered Tables)
정규테이블
분할 테이블
분할 테이블은 크기가 바뀌는 응용프로그렘을 구축할 수 있도록 해주며
다음과 같은 특성을 갖습니다.
.분할 테이블은 하나이상의 Partion을 가지며 각 파티션은 지정된 범위의 키 값을 갖는 행들을 저장
합니다.
.분할 테이블의 각파티션은 세그먼트이며 서로다른 테이블스페이스에 위치할 수 있습니다.
.여러프로세스가 동시에 질의 하고 조작하는 큰 테이블에 유용합니다.
.테이블 내의 파티션을 관리하기 위한 특별한 명령어 들이 있습니다.
행(Row)의 구조
행 데이터는 다양한 길이의 레코드 단위로 데이타베이스에 저장됩니다. 정의된 순서롤 저장되며
후행하는(Trailing) NULL컬럼은 저장되지 않습니다. 테이블의 각행은 다음을 갖습니다.
.행헤더:행의 컬럼 수와 행연결 정보, 그리고 행의 Lock상태를 저장하는데 사용됩니다.
.행데이터:각 컬럼에 대해 오라클 서버는 컬럼의 길이와 그 값을 저장합니다.
(컬럼이 250바이트를 넘지 않는다면 컬럼길이를 저장하는데 한바이트가 필요합니다. 긴 컬럼은
3바이트로 길이를 나타낼 수 있습니다. 컬럼값은 컬럼길이 바이트 바로 뒤에 저장됩니다.)
인접한 행사이에 공간을 둘 필요가 없습니다. 블록내의 각 행들은 행 디렉토리 내에 슬롯을 갖습니다.
디렉토리 슬롯은 각 행의 시작점을 가리킵니다.
12-7
오라클 데이타 유형
스칼라:CHAR, NVARCHAR(n),
VARCHAR2(n)
NVARCHAR2(n)
NUMBER(p,S)
DATE
RAW(n)
BLOB, CBLOB
NCLOB,BFILE
LONG, LONG RAW
ROWID
Collection
:VARRAY
TABLE
12-9.크기가 큰 오브젝트를 저장하기 위한 데이타 유형
LONG,LONG RAW LOB
테이블당 한 칼럼 테이블당 여러개
2GB까지 4GB까지
SELECT는 데이타를 리턴 SELECT는 locator를 리턴
데이타를 직접 저장 데이타를 직접 또는 간접 저장
오브젝트 유형을 지원하지 않음 오브젝트 유형 지원
chunks에 순차적 접근 chunck에 random접근
오라클은 LOB을 저장하기 위한 6가지 데이타 유형을 제공합니다.
.큰 고정 폭 문자 데이타를 위한 CLOB과 LONG
.큰 고정폭 국가 데이타를 저장하기 위한 NCLOB
.구조화 되지 않은 데이타를 저장하기 위한 NCLOB
.구조화 되지 않은 데이타를 운영제게 파일에 저장 하기 위한 BFILE
LOMG과 LONG RAW는 예전에는 이진 이미지나 문서 또는 지리학적 정보따위의 구조화 되지 않은
데이타에 사용 되었으며 현재는 주로 역 호환성을 위해 제공 되고 있습니다. 데이터 유형은
LOB데이터 유형으로 대체 되었습니다. 이데이터 유형은 LOB데이터유형은 LONG과 LONG RAW와는
다르며 상호 호환이 불가능합니다. LOB은 LONG API(Application programing interface)를 지원하지
않으며 LONG API도 LOB을 지원하지 않습니다.
LONG과 LOB데이터 유형 비교
LOB기능을 이전 유형들과 비교해보는 것은 유익합니다. 앞으로 나오는 LONG은 LONG과 LONG RAW
를 뜻하는 것이며 LOB은 모든 LOB데이터 유형을 뜻하는 것입니다.
LOB은 테이블 마다 또는 오브젝트 유형의 속성마다 여러개의 LOB컬럼을 둘 수 있습니다. 반면 LONG은
단 하나 만이 가능합니다.
LONG의 최대 크기는 2기가 바이트 지만 LOB은 4 기가 바이트까지
가능합니다.
읽어 들일때 LOB은 취치자(locator)를 리터하고 LONG은 모든데이타를 테이블에 저장합니다.
게다가 LOB은 데이타가 별개의 세그먼트와 테이블스페이스, 또는 호스트 파일에 저장되는 것을
허용합니다.
LOB은 오브젝트 유형 속성을 지원합니다. (단 NCLOB은 제외) 하지만 long은 지원하지 않습니다.
LONG은 주로 연결된 행조각(chained row pieces)으로 저장 됩니다. 한 블록의 한 행조각은 다른 블록
에 저장된 다음번 행조각을 가리킵니다. 이와는 반대로 LOB은 파일 같은 인터페이스를 통해
데이터에의 임의 구분접근(random piece-wise access)를 지원합니다.
ROW데이타 유형
.행의 고유한 식별자
.행의 위치를 파악하는데 사용
ROWID형식
OOOOOO FFF BBBBBB RRR
데이터 오브젝트 번호 상대적 파일 번호 블록번호 행번호
ROWID데이터 유형
ROWID는 테이블 내의 다른 칼럼과 같이 질의 될 수 있는 의사 칼럼(pseudo-column)으로 다음과 같은 특성
을 갖습니다.
.ROWID는 데이타베이스의 각행에 대한 고유한 식별자 입니다.
.ROWID는 칼럼 값처럼 명시적으로 저장 되지 않습니다.
.ROWID가 지접 행의 물리적 주소를 주지 않지만 행의 위치를 알아 내는데 사용할 수 있습니다.
.ROWID는 테이블내의 행에 접근하는 가장 빠른 수단을 제공합니다.
.ROWID는 주어진 키값으로 해을 지정할 수 있도록 인덱스에 저장됩니다.
ROWID형식
ROWID는 디스크 상에서 10바이트를 차지 하며 18문자를 사용하여 출력 됩니다. 다음과 같은 구성 요소
를 가지고 있습니다.
.데이타 오브젝트 번호는 테이블이나 인덱스 같은 각 데이터 오브젝트의 생성시 할당되며 데이타베이스
에서 유일합니다.
.상대적 파일 번호(Relative File Number)는 테이블스페이스내에서 각파일 마다 유일합니다
.블록번호는 파일내에서 행을 포함하고 있는 블록 위치를 나타 냅니다.
.행번호느 블록헤더 내의 행 디릭토리 슬롯의 위치를 나타냅니다.
내부적으로 데이터 오브젝트 번호는 32비트가 필요하고, 상대적 파일 번호는 10비트, 블록 번호는
22비트 그리고 행번호는 16비트를 필요로 하여 모두 80비트 즉 10 바이트가 필요 합니다.
ROWID는 데이타 오브젝트 번호에 6자리, 상대적 파일 번호에 3자리 블록 번호에 여섯자리, 그리고
행번호에 세자리를 사용하는 64진법 암호화 계획(base-64 encoding scheme)을 사용하여 출력됩니다.
64진법 암호화 계획은 아래와 같이 'A-Z','a-z', '0-9'. '+',/'의 총 64문자을 사용합니다.
SQL> SELECT deptno, rowid FROM DEPT;
2
DEPTNO ROWID
---------- ------------------
10 AAAAeQAAEAAAAADAAA
20 AAAAeQAAEAAAAADAAB
30 AAAAeQAAEAAAAADAAC
40 AAAAeQAAEAAAAADAAD
ROWID를 사용하여 위치 파악
한 세그먼트는 반드시 한 테이블스페이스에 상주해야 하므로 오라클 서버는 데이터 오브젝트 번호
를 사용하여 행를 포함 하고 있는 테이블스페이스를 결정할 수 있습니다.
테이블스페이스내의 상대적 파일 번호는 파일 위치를 파악하는데 사용되며 행번호는 행에 대한
행 디렉토리 엔트리 위치를 파악하는데 사용됩니다.
행디렉토리 엔트리는 행의 시작점을 가리키는데 사용됩니다.
따라서 ROWID는 데이타베이스내의 모든 행의 위치를 파악하는데 사용 될 수 있습니다.
제한된 ROWID
.세그먼트내의 행식별 가능
.보다 적은 공간 만 필요
BBBBBBB . RRRR . FFFF
블록 넘버 행넘버 파일넘버
오라클 초기 버젼은 제한된 ROWID형식을 사용 했습니다. 제한된 ROWID는 내부적으로 6바이트를 사용하며
데이타베이스 오브젝트 번호를 포함 하지 않았습니다. 제한된 ROWID형식은 파일 번호가 데이타베이스에서
고유한 ORACLE7이나 그 이전 릴리즈에서 사용할 수 있었습니다.
Oracle8이 테이블스페이스 상대적 파일번호를 사요하여 이 제한을 없앳을 지라도 제한된 ROWID는
모든 인덱스 엔트리 같은 세그먼트 내의 행을 참조하는 분할 되지 않은 테이블상의 분할되지 않은
인데스에 여전히 사용됩니다.
모음(Collections)
.모음은 오브젝트를 포함한 오브젝트입니다.
.VARRAY는 갯수와 제한을 갖는 구성요소의 순서 집합입니다.
.중첩테이블은 칼럼, 또는 TABLE데이터 유형의 변수를 가진 테이블 입니다.
모음
주어진 행에 반복되는 데이터를 테이블에 저장하는데 사용 가능한 모음데이터 유형이 두가지있습니다.
모음을 정의하고 사용하려면 오브젝트 옵션이 필요합니다. 앞으로 이러한 유형에 대해 짤막하게
다룰 것입니다.
VARRAY(Varying Arrays)
Varying Arrays는 소비자의 전화 번호와 같은 적은 갯수의 구서요소를 저장할때 유용합니다.
VARRAY는 다음과 같은 특성을 갖습니다
.배열은 데이타 구성요소의 순서집합입니다.
.주어진 배열의 모든 구성요소는 동일한 데이터 유형을 갖습니다.
.각 구성요소는 배열내의 구성요소의 위치에 해당하는 숫자인 인덱스를 갖습니다.
.배열내의 구성 요소 갯수가 배열의 크기 입니다.
.오라클은 다양한 크기의 배열으 허용합니다. 그렇기 때문에 VARRAY라 불리 웁니다. 하지만
배열 유형을 지정할때 최대크기가 지정되어야 합니다.
중첩테이블
중첩테이블은 테이블내의 컬럼에 테이블을 정의하는 방법을 제공합니다. 중첩 테이블은 주문항목 같이
많은 수읜 레코드를 갖는 집합을 저장하는데 사용될 수 있습니다.
ORDERS가 모 테이블(parent table)이고 ITEMS가 중첩된 테이블입니다.
중첩 테이블은 일반적으로 다음과 같은 특성을 갖습니다.
.중첩 테이블은 레코드 혹은 행의 순서 없는 집합입니다.
.중첩 테이블의 행은 동일한 구조을 갖습니다.
.첩 테이블의 행은 모 테이블내의 대응 행의 포인터를 이용하여 모 테이블과 별도로
저장될 수 있습니다
.중첩 테이블의 저장 특성은 데이타베이스 관리자가 정의 할 수 있습니다.
.중첩 테이블에 대해 미리 지정된 최대 크기는 없습니다.
관계유형(REF)
관계유형은 데이타베이스에서 포인터로 사용됩니다. 이유형은 Object옵션을 필요로 합니다.
예를 들어 주문된 각 아이템은 제품 코드를 저장하지 않고 PRODUCTS테이블의 행을 가리키거나
테이블내의 해을 참조할 수 있습니다.
사용자 정의 유형
오라클은 사용자가 추심데이터 유형을 정의하여 응용프로그렘 내의 행을 참조 할 수 있도록
해줍니다. 이특성을 사용하려면 Object옵션이 필요 합니다.
12-16.테이블 생성
CREATE TABLE employee(
empno NUMBER(4),
last_name VARCHAR2(4),
deptno NUMBER(2))
PCTFREE 20
PCTUSED 50
STORAGE(INITIAL 200K
NEXT 20K
PCTINCREASE 0
MAXEXTNETS 50)
TABLESPACE data01;
CREATE TABLE [schema.] table(
column dtatyoe [, column datatype ]...)
[TABLESPACE tablespace]
[PCTFREE integer]
[PCTUSED integer]
[INITRANS integer]
[MAXTRANS integer]
[STORAGE storage-caluse]
[ LOGGING NOLOGGING]
[CACHE | NOCACHE]]
구문에서
PCTFREE 행의 길이가 커질 경우를 위해 각 블록에 예약된 공간의 총량(총 공간에서
블록헤더를 뺀양을 백분율로)
PCTUSED 행 삽입시 사용될 수 없는(PCTFREE에 도달 한후)블록이 사용된 공간의 최저 한계
를 결정
INITRANS 각 블록에 미리 할당된 트렌젝션 엔트리의 갯수를 지정(기본값은 1)
MAXTRANS 각블록에 할당 할 수 있는 트렌젝션 엔트리의 갯수를 제한(기본값는 255)
LOGGING 리두로그 파일내에 기록될 테이블의 생성을 기록할 것을 지정(테이블에 대해
이루 모든 작업이 기록되도록 지정하는 것이기도 합니다-default)
NOLOGGING 리두 로그 파일에 테이블의 생성과 특정 유형의 데이타 로드를 기록하지 않도록 지정
CACHE 전체 테이블 스켄(full table scan)이 수핻될때 읽어 들인 블록이 버퍼케쉬내의
LRU 리스트의 가장 최근에 사용된 것의 자리에 위치하도록 지정
NOCACHE 전체 테이블 스켄(full table scan)이 수핻될때 읽어 들인 블록이 버퍼케쉬내의
LRU 리스트의 가장 최근에 사용되지 않은 것의 자리에 오도록 지정
주
.일반적으로 테이블은 생성될때 기본키(Primary key)도 정의 되어야 합니다.제약 조건을 관리하는 것은
뒤에서 다룹니다.
.테이블스페이스에 대해 MINIMUM EXTENT가 정의 되면 테이블에 대한 익스텐트 크기는 MINMUM, EXTENT
값의 배수로 반올림된 것이어야 합니다.
.[NO]LOGGING절이 생략되면 테이블의 기록속성(logging attrubute)은 테이블이 들어 있는
테이블스페이스와 같게 됩니다.
.MINEXTNETS가 1보다 큰 값으로 지정되고 테이블스페이스가 하나이상의 데이타파일을 포함하면
익스텐트들은 테이블스페이스내의 여러 파일에 만들어 지게 될 것입니다.
12-30.테이블 생성:지침사항
.테이블스패이스 단편하를 줄이려면 몇개의 표준익스텐트 크기를 정하십시오
.자주사용되는 갖작은 테이블에 대해서는 CACHE절을 사용허십시오
.롤백세그먼트, 임시세그먼트그리고 인덱스를 갖고 있는 테이블스페이스가 아닌
별도의 테이블스페이스에 테이블을 위치시키십시오
.단편화를 최소화 하기 위해 5*DB_BLOCK_SIZE의 정수배의 크기를 갖는 몇개의
표준 익스텐트 크기를 사용하십시오
.전체테이블스켄(full table scan)의 성능을 향상시키려면
DB_FILE_MULTIBLOCK_READ_COUNT에 따라 익스텐트의 크기를 지정하십시오. 이초기화
파라메타는 너체 테이블 을 읽는 동안 각 읽기 호출마다 서버프로세스가 운영체제로 얼마나
많은 블록을 요구하는지 를 정의합니다.
.매우 자준 접근하는 작은 테이블에 대해서는 CACHE절을 사용하십시오.
12-21.PCTFREE와 PCTUSED설정
.PCTFREE계산
(평균행의 크기 - 초기 행의 크기) * 100
--------------------------------------
평균행의 크기
.PCTUSED크기계산
평균행의 크기 *100
100 - PCTFREE - ------------------------------
사용가능한 데이터 공간
.PCTFREE설정
PCTFREE를 높개 설정 할 수록 데이터베이스 블록내에 갱신을 위햔 공강을 더 많이
제공합니다.
.초기엔 NULL이지만 이후에는 어떤 값으오 갱신되는 칼럼
.갱신 결과 크기가 증가알 것 같은 칼럼
PCTFREE을 높게 설정 할 수록 블록 밀도는 낮아져 각 블록은 적은수의 행만을 수용
할 수 있게 됩니다.
위에 명시된 공식은 행의 성장을 위해 블록내에 충분한 공간을 보장해 줍니다.
PCTUSED설정
블록이 평균적인 행을 수용하기에 충분한 공간을 가질때만 Free list에 들 수 있도록
PCTUSED를 설정하십시오, free list상의 블록이 행을 삽입할 만한 공간을 갖고 있지 못
하면 오라클 서버는 free list에서 다음 블록을 찾습니다. 이러한 선형 검색은
충분한 공간을 가진 블록이 발견되거나 list가 끝날때 까지 계속됩니다. 주어진 공식
을 사용하여 필요한 사용가능 영역을 가진 블록을 발견할 가능성을 증가 시켜 free lisT
를 겁색하는데 걸리는 시간을 줄이 십시오
주
평균적인 행의 크기는 뒷절에서 다루어 지는 ANALYZE TABLE명령을 사용하여
계산 할 수 있습니다.
12-22. 행이전(Row Migration)과 연결(Chaining)
행이전
PCTFREE가 작은 값을 가지면 블로내에 갱신 결과로 자라난 행을 수용할 만한
공간이 붋충분하게 될 수 도 있습니다. 이런일이 발생하면 오라클 서버는 전체
행을 새블록으로 옮기고 새 위치ㅡㄹ 가리키는 포인터를 남겨 놓을 것입니다.
이 과정을 행 이전이라 합니다. 오라클 서버가 이넞된 행을 읽어 들이 려면
두 데이터블을 검색해야 하므로 i?o성은 감소합니다.
행연경
행이 너무 커서 어떤 블록에도 맞지 않을 때 행연결이 발생합니다. 행이 매누
긴 칼럼을 가지고 있을때 발생할 수 있습니다. 각 행조각은 전체 행을 읽어들여
취합할때 필요한 포인터와 함께 블록내에 저장됩니다. 가능하다면
블록의 크기를 크게하거나 적은 수의 칼럼을 가닌 여러개의 테이블로
테이블을 나눔으로써 행연결을 최소화 할 수 있습니다.
기존테이블 븕사
CREATE TABLE new_emp
SOTRAGE(INITIAL 200K NEXT 200K)
PCTINCREASE 0
MXEXTENTS 50
NOLOGGING
TABLESPACE data01
AS
SELECT * FROM scott.emp;
기존 테익블을 부분, 또는 완전히 보사 할때는 서브쿼리를
가진 create table명령을 사용하십시오
CREATE TABLE [schema.]table
[LOGGING | NOLOGGING]
...
AS
subquery
TABLE STORAGE 그리고 블록 활용 등의 절들은 다른 테이블에 기초한 테이블을
생성하는 동안에도 지정할 수 있습니다.
NOLOGGING절을 사용하여 리두 로그 엔트리 의 생성을 억제하고
테이블 생성 속도를 높이십시오
제약조건 , 트리거, 그리고 테이블 권한은 이러한 방법으로 생성된
새로운 테이블로 복사되지 않습니다. 칼럼이 원래 테이블에서
NOT NULL로 정의 됭엇다면 새로운 테이블의 대응 칼럼 또한 NOT NULL
로 정의 될 것입니다.
12024.스토리지와 블록활굥 파라메타 변경
ALTER TBLE scott.emp
PCTFREE 30
PCTUSED 50
STORAGE(NEXT 500K
MINEZTENTS 2
MAXEXTENTS 100);
스토리지 파라메타의 변경효과
수정될 수 있는 파라메타와 그 수정의 의미는 다음과 같습니다.
.NEXT
올라믈 서버가 테이블에 또다른 익스텐트를 할당 할때
새값이 사용될 것입니다. 이후의 익스텐트의 크기는
PCTINCREASE만큼씩 증가 될 것입니다.
.PCTINCREASE
PCTINCREASE의 변경 사항은 데이터 딕셔너리에 기록 될
것이며 오라클 서버가 다음 익스텐트를 할당 할때 NEXT를
재계산하기위해 사용될 것입니다.
NEXT=10 이고 PCTINCREASE=0 이며 두 익스텐트를 가진 테이블를
생각해 봅시다. PCTINCREASE가 100으로 변경되면 할당될 세번째
익스 텐트는 10K가 될 것이며 네번째 익스텐트는 20K,
이널식이 될 것입니다.
MINEXTENTS
MINEXTENTS값은 테이블의 현재 익스텐트 수보가 적거나
같은 값이면 어느 값으로든지 변경 될 수 있습니다. 테이블에
즉각적인 형향은 없지만 테이블이 잘라질때(truncate)사용될
것입니다.
MAXEXTENTTS
MAXEXTENTS의 값은 테이블의 현재 익스텐트의 수보다 크거나
같은 값으오 설정 될 수 있습니다.
제한 사항
INITIAL 값은 테이블에 대해 수정 될 수 없습니다.
지정된 NEXT값은 지정된 값보다 크거나 같돌고 블록크기의
정수배 값으로 반올릴 될 것입니다.
블록 공간 활용 파라메타
블록 공간 활용파라매타가 변경되면
.공간 활용을 향상시킬 수 있습니다.
.행 이전(row migration)ㅏ가능성을 최소화 할 수 있습니다.
1 블록 공간 활용파러메타의 변경 효과는 다으미과 같습니다.
.PCTFREE
PCTFREE의 변경은 차후에 삽입에 영향을 줍니다. (100-PCTFREE)에
이미 도달 하여 삽입에 사용되지 않는 블록은 프리리스트로 돌려
질때까지 영향을 받지 않을 것입니다. 블록이 pctused미만으로 떨어
졌을 경우에만 프리리스트로 돌려 질 수 있습니다.
.PCTUSED
PCTUSED의 변화는 테이블의 몾든 블록에 영향을 줄 것입니다. 해이
갱신 되거나 삭제 되면 그 해을 포함하고 있는 블록은 그 사용을 겁사
받게 될 섟입니다.
INITRANS
INITRANS의 변경은 새블록에만 영향을 줍니다.
MAXTRANS
MAXTRANS의 변경은 테이블의 모든 블록에 영햫을 줍니다.
제13장 인덱스 관리
13-3.목적
- 인덱스의 유형 및 사용에 대한 설명
- B-트리 및 비트맵(Bitmap) 인덱스 생성
- 인덱스 재구축
- 인덱스 삭제
- 데이터 딕셔너리의 인덱스 관련정보
13-4.인덱스의 분류
1. 논리적
. 단일 열 또는 연결(concatenated)열
. unique 또는 nonunique(중복허용)
2. 물리적
. 분할된 또는 분할되지 않은
. B-트리 또는 비트맵(bitmap)
- 정상 또는 reverse 키(B-트리의 경우)
- 트리구조인 인덱스를 사용하여 테이블 내의 행에 직접 접근할 수 있습니다.
- 인덱스는 논리적설계나 물리적 구현에 기초하여 분류할 수 있습니다.
- 논리적 분류는 응용 프로그램의 시각에서 인덱스를 분류하는 반면 물리적 분류는
인덱스를 저장하는 방식에 따라 나눕니다.
3. 단일열과 연결 인덱스
- 단일 열 인덱스는 인덱스 키에 오직 하나만의 열을 갖습니다.
- 예를 들자면 사원 테이블의 사원 번호 열에 지정한 인덱스가 있습니다.
- 조합 인덱스(composite index)라고도 불리우는 연결 인덱스는 테이블의 여러
개의 열에 대해 지정됩니다.
- 연결 인덱스 방식의 열은 테이블의 열과 같은 순서일 필요가 없으며 인접해
있을 조합 키 인덱스의 열의 최대 수는 32입니다.
- 하지만, 모든 열을 합한 크기가 대략 데이터 블록크기의 1/3을 초과할 수
없습니다.
13-5.unique 인덱스와 nonunique 인덱스
- Unique인덱스는 인덱스로 정의된 테이블의 열에 중복된 값을 갖는 행들이 있을
수 없도록 합니다.
- Unique인덱스의 인덱스 키는 테이블의 한 행만을 가리킬 수 있습니다.
- Nonunique 인덱스는 하나의 키에 여러 행이 관련되어 있습니다.
1. 분할 인덱스와 분할되지 않은 인덱스
- 분할 인덱스는 큰 테이블의 인덱스 엔트리를 저장하는데 사용하는 방법으로
인덱스 값에 따라 여러 세그먼트에 나누어 저장합니다.
- 한 인덱스를 여러 테이블스페이스에 나누어 저장하여 인덱스 조회시 경합을
감소시켜 주고 관리성을 증가시켜 줍니다.
- 분할 인덱스는 크기 조절성과 관리성을 향상시키기 위해 분할 테이블과 함께
자주 사용됩니다.
- 인덱스 파티션은 각 테이블 파티션마다 생성될 수 있습니다.
- 본 장은 분할되지 않은 B-트리와 비트맵(bitmap)인덱스의 생성과 유지보수에
대해 다룰 것입니다.
13-6.B-트리 인덱스
- 모든 인덱스가 B-트리 구조에 연관되어 있듯이 B-트리 인덱스는 보통 각 키에
대해 ROWID값들을 저장하는 인덱스와 연관되어 있습니다.
1. B-트리 인덱스 구조
- 인덱스 제일 위는 root로 인덱스의 다음 레벨을 가리키는 엔트리를 포함하고
있습니다.
- 다음 레벨은 branch 블록으로 마찬가지로 다음 레벨의 인덱스 블록을
가리킵니다.
- 최하층 레벨은 leaf노드로 테이블의 행을 가리키는 인덱스 엔트리를
포함하고 있습니다.
- leaf블록은 키 값의 내림차순은 물론 오름차순의 키 값으로 인덱스를 검색하는데
편리하도록 양방향(doubling)으로 연결(link)되어 있습니다.
2. 인덱스 Leaf 엔트리의 형식
. 열 수와 잠금(locking)정보를 저장하는 엔트리 헤더
. 키의 열 길이와 열 값이 차례로 정의된 쌍(pair)으로 된 값(이들 쌍의 갯수가
인덱스에 들어갈 수 있는 열의 최대치입니다.)
. 키값을 포함하는 행의 ROWID
. Leaf Block에만 ROWID Bolck이 있다
13-7.인덱스 Leaf 엔트리 특성
- 분할되지 않은 테이블의 B-트리 인덱스는 다음과 같습니다.
. 같은 키 값을 갖는 행이 여러개 있으면서 키 값이 반복됩니다.
. 모든 키 열의 값이 NULL인 행에 대응되는 인덱스 엔트리는 없습니다.
. 모든 행이 같은 세그먼트에 속하므로 제한된 ROWID가 테이블의 행을
가리키는데 사용됩니다.
1. 인덱스에의 DML 작업의 효과
- 오라클 서버는 테이블에 DML 작업이 수행될 때 모든 인덱스도 유지 보수합니다.
- 인텍스에의 DML 명령의 효과는 다음과 같습니다.
. 삽입(insert)작업은 적절한 블록에 인덱스 엔트리를 삽입합니다.
. 행 삭제(delete)는 인덱스 엔트리의 논리적 삭제만을 하게 됩니다. 삭제된 행에
의해 사용되는 공간은 블록 내의 모든 엔트리가 삭제될 때까지 새 엔트리를
저장하는데 사용할 수 없습니다.
.키 열에 대한 갱신(update)은 인덱스에 논리적 삭제와 삽입을 하게 됩니다.
- PCTFREE설정은 생성시를 제외하면 인덱스에 아무런 영향을 주지 않습니다.
- 인덱스 블록이 PCTFREE에 의해 지정된 것보다 작은 공간을 가지고 있더라도
새 엔트리가 추가될 수 있습니다.
13-8.Reverse키 인덱스(Reverse Key Index)
- 보통 B-트리 인덱스와는 반대로 Reverse 키 인덱스는 열 순서를 따라 인덱스가
지정되어(ROWID제외)있는 각 열의 바이트를 역으로 뒤집습니다.
- 시스템이 생성한 고용자 번호 같은 오름차순 키고 레코드를 삽입할 때 인덱스
트리의 한 곳에 모든 인덱스 갱신이 발생하게 되어 I/O 병목현상이 발생할 수
있습니다.
- Reverse키 인덱스는 인덱스 키의 데이터 값을 뒤집어 주어 인덱스 트리에 인덱스
갱신 분포를 분산시켜 줍니다.
- 예를 들자면 테이블에 사원번호 7698를 삽입하면 8967의 키 값이 인덱스에
저장됩니다.
- 다음 사원번호7782가 입력되면 인덱스 엔트리는 2877이 되어 작업 부하(load)를
여러개의 인덱스 블록으로 분산시켜 줍니다.
- 이러한 배열은 오라클 병렬 서버 환경에서 인덱스의 성능저하를 막는데 매우
유용할 수 있습니다.
- Reverse키 인덱스는 동등 속성(equality predicate)을 갖는 질의에 대해서만
유용합니다.
- 사전적 의미로는 인접한 키가 reverse키 인덱스에서는 서로 인접하여 저장되는
것이 아니기 때문에 이러한 인덱스를 사용하여 범위 검색(range search)을
수행할 수는 없을 것입니다.
13-9.비트맵 인덱스
- 비트맵 인덱스는 다음과 같은 경우에 B-트리 인덱스보다 더 유용합니다.
. 테이블이 많은 행을 가지며 키 열은 적은 분포도(cardinality)를 가질 때,
즉 열이 갖는 서로 다른 값이 몇 개 안 될 때, 예를 들어 여권기록을 포함하고
있는 테이블의 성별 열이나 결혼 여부 열의 경우에는 B-트리 인덱스보다는
비트맵 인덱스가 더 유리할 것입니다.
. 질의문이 OR 연산자를 포함하는 여러 개의 WHERE 조건을 자주 사용할 때
. 키 열이 읽기 전용이거나 갱신 작업을 적게 할 때
- 비트맵 인덱스의 구조
. 비트맵도 B-트리처럼 조직되어 있습니다.
. 하지만 leaf노드는 ROWID 값 들 대신 각 키값에 대한 비트맵을 저장합니다.
. 비트맵의 각 비트는 가능한 ROWID에 대응되며 비트가 1이 되면(set), 대응되는
ROWID를 가진 행이 키 값을 가진다는 것을 의미합니다.
13-10.비트맵 인덱스의 leaf노드는 다음을 포함하고 있습니다.
. 엔트리 헤더 : 열 수와 잠금(lock)정보를 포함하고 있습니다.
. 키값 : 각 키 열에 대해 길이와 같이 쌍(value pair)으로 구성되어 있습니다.
(예를 들어 키는 오직 하나의 열로 구성되어 있으며 첫번째 엔트리는 Blue의 키
값을 가집니다.)
. 시작 ROWID : 이 예에서는 파일 번호3, 블록번호 10, 그리고 행 번호 0을
포함하고 있습니다.
. 끝 ROWID : 이 예에서는 블록번호 12, 그리고 행번호 8을 포함하고 있습니다.
. 비트맵 세그먼트 : 비트(bit)의 문자열을 가지고 있습니다.(대응되는 행이
키 값을 가질 때 비트가 1이 되고 행이 키 값을 갖지 않을때 0이 됩니다.
오라클 서버는 비트맵 세그먼트를 저장할 때 특허받은 압축 기술을 사용합니다.)
- 시작 ROWID는 비트맵의 비트맵 세그먼트가 가리키고 있는 첫번째 행의 ROWID입니다.
- 즉, 비트맵의 첫번째 비트는 그 ROWID에 대응되며 두번째 비트는 블록의 다음
행에 대응됩니다.
- 끝 ROWID는 비트맵 세그먼트가 담당하는 테이블의 마지막 행을 가리킵니다.
- 비트맵 인덱스는 제한된 ROWID를 사용합니다.
- 비트맵 인덱스 사용
. B-트리를 사용하여 주어진 키 값을 갖는 비트맵 세그먼트를 포함하는 leaf노드의
위치를 찾습니다.
. 시작 ROWID와 비트맵 세그먼트는 키 값을 가진 행의 위치를 찾는데 사용됩니다.
. 테이블의 키 열이 변경되면 비트맵이 수정되어야 하며, 이 결과 관련된 비트맵
세그먼트가 잠게게(locking)됩니다.
. 이때 모든 비트맵 세그먼트가 잠기게 되므로 이 비트맵이 담당하는 행은 첫번째
트랜잭션이 끝날때까지 다른 트랜잭션이 갱신할 수 없게 됩니다.
13-11.B-트리와 비트맵 인덱스 비교
------------------------------------------------------------------
B-트리 비트맵
------------------------------------------------------------------
큰 분포도(cardinality)를 적은 분포도를 갖는 테이블에 적합
갖는 테이블에 적합
비교적 키으 갱신비용이 적음 갱신 비용이 매우 큼
OR사용 질의문에 비효율적 OR사용 질의문에 효율적
OLTP에 유용 DSS에 유용
------------------------------------------------------------------
- 슬라이드의 표는 B-트리 인덱스와 비트맵 인덱스를 비교한 것입니다.
- 비트맵 인덱스는 적은 분포도를 갖는 열에 사용될 때 B-트리 인덱스보다
간결합니다.
- 비트맵은 비트맵 세그먼트 레벨의 잠금(locking)을 사용하므로 비트맵 인덱스에서
키 열을 갱신하는 비용이 매우 큽니다.
- 반면 B-트리 인덱스에서는 잠금이 테이블의 각 행에 대응되는 엔트리에 걸립니다.
- 비트맵 인덱스는 Bitmap OR 등의 작업을 수행하는데 사용될 수 있습니다.
- 즉, 오라클 서버는 두개의 비트맵 세그먼트를 사용하여 비트 방식 OR를 수행하여
결과 비트맵을 얻어낼 수 있습니다.
- 이 방식은 OR을 사용하는 질의문에서 비트맵을 효율적으로 사용할 수 있게 해
줍니다.
- 요약하자면 B-트리 인덱스는 동적 테이블을 인덱스하는 OLTP환경에 더 적합합니다.
- 반면 비트맵 인덱스는 크고 정적인 테이블에 복잡한 질의문이 사용되는 DSS
환경에 유용합니다.
13-12.정규 B-트리 인덱스 생성
CREATE INDEX scott.emp_lname_idx
ON scott.employees(last_name)
PCTFREE 30
STORAGE(INITIAL 200K NEXT 200K
PCTINCREASE 0 MAXEXTENTS 50)
TABLESPACE indx01;
- 인덱스는 테이블을 소유하고 있는 사용자 계정에서 생성할 수도 있고 다른
계정에서 생성할 수도 있습니다.
- 하지만 테이블과 같은 계정에서 생성하는 것이 일반적입니다.
- 구문
. 다음 명령을 사용하여 B-트리 인덱스를 생성하십시오.
CREATE [UNIQUE] INDEX [schema.]index
ON [schema.]table
(column [ ASC | DESC ] [ , column [ ASC | DESC ] ] . . .)
[ TABLESPACE tablespace ]
[ PCTFREE integer ]
[ INITRANS integer ]
[ MAXTRANS integer ]
[ storage-clause ]
[ LOGGING | NOLOGGING ]
[ NOSORT ]
- 구문에서 :
. UNIQUE unique 인덱스를 지정하는데 사용합니다.(NONUNIQUE가 기본값입니다.)
. schema 인덱스/테이블의 소유자입니다.
. index 인덱스 이름입니다.
. table 테이블 이름입니다.
. column 열 이름입니다.
. ASC/DESC 다른 데이터베이스와의 구문 호환성을 위해 제공됩니다.
. TABLESPACE 인덱스가 생성될 테이블스페이스를 나타냅니다.
. PCTFREE 생성시 새 인텓스 엔트리를 수용하기 위해 각 블록에 예약된
공간의 총량입니다.(총 공간에서 블록 헤더를 뺀 것을 백분율로)
. INITRANS 각 블록에 미리 할당된 트랜잭션 엔트리의 수를 지정합니다.
(기본값은 최소값인 2입니다.)
. MAXTRANS
. STORAGE 익스텐트가 인덱스에 할당되는 방법을 결정하는 스토리지 절을
나타냅니다.
. LOGGING 인덱스의 생성과 이후의 인덱스에 대한 작업이 리두로그파일에
기록되지 않도록 명시합니다.(기본값입니다)
. NOLOGGING 인덱스 생성과 특정 유형의 데이터 로드가 리두 로그 파일에
기록되지 않도록 명시합니다.
. NOSORT 행이 데이터베이
스에 오름차순으로 저장되어 있음을 명시합니다.
이 경우 오라클 서버는 생성시 행을 정렬하지 않습니다.
13-14.
- 주
.테이블 스페이스에 MINIMUM EXTENT가 정의되어 있다면 인덱스에 대한
익스텐트 크기는 다음으로 큰 MINIMUM EXTENT값의 정수배로 반올림 될 것입니다.
.[NO]LOGGING 절이 생략되면 인덱스의 기록(logging)속성은 인덱스가
상주하고 있는 테이블스페이스의 기록 속성을 따르게 됩니다.
.인덱스에는 PCTUSED가 지정될 수 없습니다. 왜냐하면 엔트리가 올바른
순서대로 저장되어 있어야만 하기 때문에 사용자는 인덱스 블록이 삽입에
사용될 때 제어할 수 없습니다.
.데이터가 키에 대해 정렬되지 않은 상태에서 NOSORT키워드를 사용하면 명령문은
에러를 출력하고 종료하게 됩니다.
.오라클 서버는 가능하다면 기존 인덱스를 사용하여 새 인덱스를 생성합니다.
이러한 일은 새 인덱스에 대한 키가 기존 인덱스의 키의 주요 부분에 대응할 때
발생합니다.
13-15.
- 인덱스 생성시 지침사항
.질의문 또는 DML 요구에 따라 생성을 해야할지 결정하십시오.
.별도의 테이블스페이스에 위치시키십시오.
.익스텐트 크기를 균일하게 하십시오 :
다섯 블록의 배수 또는 테이블스페이스의 MINIMUM EXTENT 크기의 정수배가
되도록 하십시오.
.큰 인덱스에 대해서는 NOLOGGING을 고려하십시오.
.새 키 값이 현재있는 키 값의 범위 내에 들 것 같으면 PCTFREE를 높게
설정하십시오.
- 인덱스를 생성할 때 다음을 고려하십시오.
.인덱스는 질의문을 성능을 향상시켜주고 DML 작업을 느리게 합니다. 자주
변하는 테이블에 필요한 인덱스 숫자는 항상 최소화 하십시오.
.인덱스를 롤백 세그먼트, 임시 세그먼트, 그리고 테이블과는 별도의
테이블스페이스에 위치시키십시오
.단편화를 최소화하려면 5*DB_BLOCK_SIZE의 정수배인 표준 익스텐트 크기를
사용하십시오.
.리두 생성을 피함으로써 큰 인덱스에 대해 현저한 성능 향상이 있을 것입니다.
큰 인덱스를 생성할 때는 NOLOGGING절을 사용하는 것을 고려해 보십시오.
.인덱스 엔트리는 그들이 인덱스하는 행에 비교해 볼때 작기 때문에 인덱스
블록이 블록당 더 많은 엔트리를 가질 수 있습니다. 이런 이유로 INITRANS는
일반적으로 대응되는 테이블에서 보다는 인덱스에서 더 커야합니다.
13-16. 인덱스와 PCTFREE
- 인덱스에 대한 PCTFREE는 테이블에 대한PCTFREE와는 달라서 동일 인덱스블록에
삽입되어야 할 인덱스에 대비한 공간을 예비해 두도록 인덱스생성시에만
사용됩니다.
- 인덱스 엔트리는 갱신되지 않습니다.
- 키 열이 갱신될 때는 인데스 엔트리가 논리적으로 삭제된 후 삽입됩니다.
- 시스템 생성 송장 번호(system-generated invoice number)같이 차례대로 증가하는
열에 대한 인덱스에는 PCTFREE를 낮게 잡으십시오. 이 경우 새인데스 엔트리는
항상 기존 엔트리에 추가되며 기존의 두 인덱스 첸트리간에 새 엔트리를 삽입할
필요는 없습니다.
- 삽입될 행의 인데스 열 값이 어떤 값이라도 가질 수 있다면, 즉 현재 가지고
있는 값의 범위 내의 어느 값이라도 가질 수 있다면 높은 값의 PCTFREE를
제공해야만 합니다. 높은 PCTFREE값을 요구하는 인덱스의 한 예는 송장
테이블의 소비자 코드 열에 대한 인데스입니다. 이 경우 다음 식이 가리키는
대로 PCTFREE값을 지정하는 것이 유리 합니다.
최대 행의 갯수. 초기 행의 갯수
------------------------------- X 100
최대행의 갯수
- 최대값은 일년 같은 특정 기간에 맞춘 값일 수 있습니다.
13-17. Reverse키 인덱스 생성
CRERATE UNIQUE INDEX scott.ord_ord_no_idx
ON scott.ord(ord_no) REVERSE
STORAGE(INITIAL 200K
NEXT 200K
PCTINCREASE 0
MAXEXTENTS 50)
TABLESPACE indx01;
- 구문
Reverse키 인데그를 사용하려면 다음명령을 사용하십시오
CREATE [UNIQUE] INDEX [scheme.]index
ON [scheme.]table
(column [ACS|DESC],column [scheme.],(column [ACS|DESC] ] ...)
[TABLESPACE tqablespace ]
[PCINCREASE integer ]
[INITRANS integer ]
[MAXTRANS integer ]
[storage-caluse]
[LOGGING | NOLOGGING]
REVERSE
Reverse키 인덱스의 생성을 위한 명령은 REVERSE키워드가 사용된다는 점을
제외하고는 정규 인덱스를 생성하는 것과 비슷합니다. Reverse키 인덱스에는
NOSORT 키워드가 사용될 수 없다는 것을 명심하십이오
13-18.비트멥 인댁스 생성
CREATE BITMAP INDEX scott.ord_region_id_idx
ON scott.ord(region_id)
PCTFREE 30
STORAGE(INITIAL 200K
NEXT 200K
PCTINCREASE 0
MAXEXTENTS 50)
TABLESPACE indx01;
- 구문
* 비트멥 인덱스를 생성하려면 다음 명령을 사용하십시오
CREATE BITMAP INDEX [schema.]index
ON [schema.]table
(column [ASC|DESC], column[ASC|DESC]...]
[TABLESPACE tablespace]
[PCTINCREASE integer]
[INITRANS integer]
[MAXTRANS integer]
[ storage-caluse]
[LOGGING | NOLOGGING]
[NOSORT]
* 비트멥 인덱스는 Unique인덱스가 될 수 없을 을 명심하십오.
CREATE_BIT_MAP_AREA_SIZE
초기화 파라메타 CREATE_BIT_MAP_AREA_SIZE는 메모리내에 비트멥 세그먼트를
저장하기 위해 사용될 공간의 총량을 결정합니다.
기본 값은 8MB입니다. 이값을 크게 하면 더 빨리 인덱스를 생성할 수 있습니다.
분포도가 매우 적다면 작은 값으로 설정 될 수 있습니다.
예를 들어 분포도(cardinality)가 2라면 파라메타 값은 메기 바이트 단위 보다는
킬로 바이트 단위가 될 수 있습니다.
일반적인 규칙대로 분포도가 커질 수록 최적화된 성능을 위해서는 더 많은
메모리가 필요합니다.
13-20.인덱스에 대한 스토리지 파라메타 변경
ALTER INDEX scott.emp_lname_idx
STORAGE(NEXT 400K
MAXEXTENTS 100);
스토리지 파라메타와 공간 활용파라메타 일부는 ALTER INDEX명령을 사용하여
수정할 수 있습니다.
ALTER INDEX [scheme.]index
storage-caluse
[INITRANS integer]
[MAXTRANS integer]
인덱스에 대한 스토리지 파라메타의 변경 의미는 테이블에 대한 이 파라메타들
이 변경되는 것과 마찬입니다.
일반적으로 인덱스에 대한 변경은 MAXEXTENTS를 증가 시키는 것입니다.
공간 활용파라메타는 인덱스 블록에 대한 높은 수준의 동시성을 보장하기 위해
변경 될 수 있습니다.
13-22.인덱스 공간할당과 해제
ALTER INDEX scott.ord_regin_idx
ALLOCATE EXTENT (SIZE 200K DATAFILE '/disk5/indx01.dbf');
ALTER INDEX scott.ord_ord_no_idx DEALLOCATE UNUSED;
1. 인덱스에 대한 수동 공간 할당
- 테이블에 많은 데이타를 미리 추가 하면 수행중의 인덱스의 동적확장과 그로
인한 성능 저하를 막아 줍니다.
2. 인덱스로 부터 공간 수동해제
- 인덱스의 high water mark 이상의 사용되지 않는 공간을 해제 하려면 ALTER
INDEX 명령의 DEALLLOCATE절을 사용하십시오
- 구문
ALTER INDEX [scheme.]index
{ALLOCATE EXTENT ( [SIZE integer [K|M] ]
DATAFILE 'filename' ])
| DEALLOCATE UNUSED [KEEP integer [K|M] ] }
3. 인덱스에 수동으로 공간을 할당하거나 해제하는 것은 테이블에 대해 이러한
명령을 사용 할때와 같습니다.
- 주
* 인덱스 공간은 인덱스가 구축된 테이블이 잘려질(truncate)때 해제 됩니다.
* 테이블이 잘려지면 관련 인덱스도 잘려집니다.
13-23.인덱스 재구축
다음 명령을 사용하여
1. 인덱스를 다른 테이블스페이스로 옮기고
2. 삭제된 엔트리를 제거하여 공간활용을 향상시키고
3. Reverse 키 인덱스를 보통의 B-트리 인덱스로도, 그 반대로도 변경 하십시오
ex) ALTER INDEX scott.ord_region_id_idx
REBUILD
TABLESPACE indx02;
※ 인덱스 재구축은 다음 특성을 갖습니다.
- 새 인덱스는 기조 인덱스를 데이터 소스로 사용하여 구축됩니다.
- 기존 인덱스를 사용하여 더 나은 성능을 얻기 위해 인덱스를 구축할
때는 정렬이 필요없습니다.
- 이전 인덱스는 새 인덱스가 구축된 후 삭제됩니다. 재구축하는 동안
이전 인덱스와 새 인덱스 모두를 각각의 테이블스페이스에 수용할
충분한 공간이 필요합니다.
- 재구축된 인덱스는 삭제된 엔트리는 전혀 포함하고 있지 않게 됩니
다. 따라서 인덱스는 보다 효율적으로 공간을 사용하고 있습니다.
- 새 인덱스가 구축되고 있는 동안 질의문은 기존 인덱스를 계속 사용
할 수 있습니다.
※ 재구축이 필요한 상황
- 다음 상황이 발생하면 인덱스를 재구축하십시오
. 기존 인덱스를 다른 테이블스페이스로 이동해야 할 때, 인덱스가
테이블과 같은 테이블스페이스에 있거나 오브젝트를 여러 디스크에
걸쳐 재분배되어야 할때 이러한 일이 발생할 수 있습니다.
. 인덱스가 삭제된 엔트리를 많이 포함하고 있을때, 이것이 처리된
주문이 삭제되고 더 큰 주문번호를 가진 새로운 주문이 테이블에
추가되는 주문 테이블의 주문번호에 대한 인덱스 같이 계속 변화
하는 인덱스의 경우 대표적인 문제입니다. 일부 옛 주문이 남아
있다면 엔트리가 없거나 몇개 정도만 가진 인덱스 leaf블록일 수
있습니다.
. 기존의 정규 인덱스가 reverse 키 인덱스로 변환되어야 할때, 이런
경우는 오라클 서버의 이전 release에서 응용 프로그램을 이전
(migrating)때 발생할 수 있습니다.
- 구 문
인덱스를 재구축하려면 다음 명령을 사용하십시오
ALTER INDEX [schema.] index REBUILD
[ TABLESPACE tablespace ]
[ PCTFREE integer ]
[ INITRANS integer ]
[ MAXTRANS integer ]
[ storage-clause ]
[ LOGGING | NOLOGGING ]
[ REVERSE | NOREVERSE ]
ALTER INDEX -- REBUILD 명령은 비트맵 인덱스를 B-트리 인덱스로
바꾸거나 B-트리 인덱스를 비트맵 인덱스로 바꾸는데 사용할 수
없습니다. REVERSE나 NOREVERSE 키워드는 B-트리 인덱스에만 지정될
수 있습니다.
13-25.인덱스 유효성 검사
ANALYZE INDEX scott.ord_region_id_idx VALIDATE STRUCTURE;
1. 다음을 수행하려면 인덱스를 분석하십시오.
- 모든 인덱스 블록을 검사하여 블록 훼손을 조사합니다. 인덱스
엔트리가 테이블의 데이터에 대응되는지 여부는 검증하지 않는다는
것을 명심하십시오.
- 인덱스에 대한 정보를 가지고 있는 INDEX_STATS뷰에 기록합니다.
- 구문
ANALYZE INDEX [schema.] index VALIDATE STRUCTURE
위 명령을 수행한 후 INDEX_STATS를 질의하여 다음 예에 보여지는 것처럼
인덱스에 대한 정보를 얻으십시오
SVRMGR> SELECT blocks, pct_used,
2> lf_rows, del_lf_rows
3> from index_stats;
BLOCKS PCT_USED LF_ROWS DEF_LF_ROWS
------ -------- ------- -----------
25 11 14 0
1 row selected.
인덱스가 삭제된 행이 많이 가지고 있다면 인덱스를 재구축하십시오.
예를 들어 LF_ROW에 대한 DEL_LF_ROWS의 비가 30%를 초과하면 인덱스를
재구축하십시오
13-26.인덱스 삭제
1. 대량으로 로드하기 전에 인덱스를 삭제하고 재생성하십시오
2. 별 필요없는 인덱스를 삭제하고 필요할때 구축하십시오
3. 쓸모없는 인덱스를 삭제하고 재생성하십시오
예> DROP INDEX scott.dept_dname_ids;
다음과 같은 경우 인덱스를 삭제할 필요가 있습니다.
- 응용프로그램에서 더 이상 필요하지 않는 인덱스는 제거할 수
있습니다.
- 대량으로 로드하기 전에 인덱스를 삭제할 수도 있습니다. 큰 데이터를
로드하기 전에 인덱스를 삭제하고 로드한 후 재생성하여:
1) 로드 성능을 향상시키십시오
2) 인덱스 공간을 보다 호율적으로 사용하십시오
- 정기적으로만 사용되는 인덱스는 불필요하게 유지보수될 필요는 없습니다.
특히 잠깐씩 사용하는(volatile) 테이블에 기초한 경우에는 더욱 그렇습니다.
일반적으로 회의용 자료를 모으기 위해 연말, 또는 분기 말에 질의문이 만들
어지는 OLTP 시스템의 경우가 그렇습니다.
- 인덱스는 로드 같은 특정 유형의 작업 중 인스턴스가 비정상적으로 종료할때
인덱스가 INVALID라고 표시될 수도 있습니다. 이경우 인덱스는 삭제되거나
재생성되어야 합니다.
- 인덱스가 훼손되었을때
- 구 문
다음 명령을 사용하여 인덱스를 삭제하십시오
DROP INDEX [schema.]index
13-28.인 덱 스 정 보 얻 기
DBA_INDEXES DBA_IND_COLUMS
OWNER - - INDEX_OWNER
INDEX_NAME ㅏㅓ INDEX_NAME
INDEX_TYPE - - TABLE_OWNER
TABLE_OWNER TABLE_NAME
TABLE_NAME COLUMN_NAME
UNIQUENESS COLUMN_POSITION
TABLESPACE_NAME COLUMN_LENGTH
LOGGING
STATUS
데이터 딕셔너리 뷰 DBA_INDEXES와 DBA_IND_COLUMNS은 인덱스와 인덱스된 열에
대한 정보를 제공합니다.
1. 인덱스와 그 유효성 검사
다음 명령을 이용하여 사용자 SCOTT이 소유한 인덱스의 이름, 유형 그리고 상태를
확인하십시오
SVRMGR> SELECT index_name, tablespace_name, index_type,
2> uniqueness, status
3> FROM dba_indexes
4> WHERE owner = 'SCOTT';
INDEX_NAME TABLESPACE_NAME INDEX_TYPE UNIQUENESS STATUS
----------------- --------------- ---------- ---------- ------
EMP_LNAME_IDX INDX01 NORMAL NONUNIQUE VALID
ORD_ORD_NO_IDX INDX01 NORMAL UNIQUE VALID
ORD_REGION_ID_IDX INDX02 BITMAP NONUNIQUE VALID
2. INDEX_TYPE 열은 인덱스가 비트맵인지 보통 인덱스인지를 가리킵니다. 모든
reverse키 인덱스의 이름을 보고자 할 때는 다음 질의문을 사용하십시오.
SVRMGR> SELECT o.object_name
2>FROM dba_objects o
3>WHERE owner = 'SCOTT'
4>AND o.object_id IN (select I.obj#
5> FROM ind$ I
6> WHERE BITAND (I.property, 4) = 4);
OBJECT_NAME
----------------------
ORD_ORD_NO_IDX
1 row selected.
3. 인덱스가 정의 된 열 찾기
다음 질의문은 사용자 SCOTT이 소유한 인덱스 전부를 보여주며 인덱스가
구축된 테이블과 열을 보여 줍니다.
SVRMGR> SELECT index_name, table_owner, table_name, column_name
2>FROM dba_ind_columns
3>WHERE index_owner = 'SCOTT'
4>ORDER BY index_name, column_position;
INDEX_NAME TABLE_OWNER TABLE_NAME COLUMN_NAME
---------------- ------------ ---------- ----------
EMP_LNAME_IDX SCOTT EMP LAST_NAME
ORD_ORD_NO_IDX SCOTT ORD ORD_NO
ORD_REGION_ID_IDX SCOTT ORD REGION_ID
3 rows selected.
13-29
요약
* 여러 유형의 인덱스 생성
* 인덱스 재구축
13-30
요약 참조
관련내용: 참조
초기화 파라미터: CREATE_BITMAP_AREA_SIZE
동적 성능 뷰: 없슴
데이터 딕셔너리 테이블/뷰: DBA_INDEXES
DBA_IND_COLUMNS
IND$
INDEX_STATS
명령어: CREATE INDEX
CREATE UNIQUE INDEX
CREATE BITMAP INDEX
CREATE INDEX … REVERSE
ALTER INDEX … STORAGE
ALTER INDEX … INITRANS .. MAXTRANS
ALTER INDEX … ALLOCATE EXTENT
ALTER INDEX DEALLOCATE UNUSED
ALTER INDEX … REBUILD
ALTER INDEX … REBUILD … REVERSE
ALTER INDEX … REBUILD … NOREVERSE
ANALYZE INDEX … VALIDATE STRUCTURE
DROP INDEX
제 14 장 데이터 무결성 관리
14-3 목적
1. 데이터 무결성 제약 조건과 트리거 구현
2. 무결성 제약 조건과 트리거 관리
3. 데이터 딕셔너리의 제약 조건과 트리거 관련 정보
14-4 데이터 무결성
1. 데이터 무결성은 데이터베이스 내의 데이터가 업무 규칙을 잘 따른다는 것을
확인해 줍니다.
2. 데이터 무결성을 유지하는데 사용하는 주요 방법이 세 가지 있습니다.
1) 응용 프로그램 코드
2) 데이터베이스 트리거
3) 선언 무결성 제약 조건
3. 세 가지 방법 중 하나를 사용하여 업무 규칙을 대응시키는 것이 바로 디자이너가
내리는 디자인 결정입니다.
4. 데이터베이스 관리자는 디자이너가 선택한 방법을 구현하고 무결성 요구와 필요한
성능간의 균형을 잡아 주는데 관여합니다.
5. 응용 프로그램 코드는 데이터베이스 내의 저장 프로시저, 또는 클라이언트에서
수행되는 응용 프로그램으로 구현될 수 있습니다.
6. 본 장은 데이터베이스 트리거와 무결성 제약 조건을 사용하는데 초점을 두고 있습니다.
14-5 데이터베이스 트리거
1. 데이터베이스 트리거는 테이블에서 열을 삽입하거나 갱신하는 등의 이벤트가
발생할 때 수행되는 PL/SQL 프로그램입니다.
2. 트리거는 enable될 수도 disable될 수도 있습니다. 즉, 이벤트가 발생했을 때 실행되
도록 설정할 수도 있고, 비록 정의는 되었더라도 실행되지 않도록 설정할 수도
있습니다.
3. 데이터베이스 트리거는 보통 무결성 제약 조건으로 정의될 수 없는 복잡한 업무
규칙을 적용할 대 주로 생성됩니다.
# 무결성 제약 조건
무결성 제약 조건은 업무 규칙을 적용할 때 주로 사용하는 방법으로 다음과 같은
특징을 갖습니다.
1) 향상된 성능 제공
2) 선언과 수정이 용이. 즉, 확장 코딩할 필요가 없습니다.
3) 규칙의 중앙 집중화
4) 융통성 제공(enalble/disable)
5) 데이터 딕셔너리에 완전히 기록됨
4. 다음 절에서는 무결성 제약 조건의 수행 방식과 오라클 서버에 의해 구현되는
방법에 대해 다룰 것입니다.
14-6. 제약 조건의 유형
1. NOT NULL - 열이 null값을 가질 수 없도록 지정
2. UNIQUE - 열 또는 열 결합(combination of columns)이 유일하도록 지정
3. PRIMARY KEY - 열 또는 열 결합을 테이블의 기본 키로 지정
4. FOREIGN KEY - 열 또는 열 결합을 테이블의 제약 조건에서의 외래 키로 지정
5. CHECK - 테이블의 각 행이 만족시켜야만 하는 조건을 지정
14-7. 제약 조건 상태
1. 무결성 제약 조건은 다음 상태 중 하나일 수 있습니다.
1) Disabled
2) Enabled novalidate, 또는 enforced
3) Enabled validate
# Disabled
1) 제약 조건이 disabled 되어 있다면 제약 조건 정의가 데이터 딕셔너리에 저장되어
있을지라도 검사하지 않습니다.
2) 입력되거나 갱신된 새 데이터 뿐만 아니라 테이블의 데이터도 제약 조건에 의해
정의된 규칙을 따르지 않을 수도 있습니다.
# Enabled Novalidate(Enforced)
1) 제약 조건이 enable novalidate라면 제약 조건에 위배되는 새로운 데이터는
입력될 수 없습니다.
2) 하지만 테이블에 부적합(invalid)한 데이터(즉, 제약 조건에 위배되는 데이터)를
포함할 수도 있습니다.
3) 이 상태는 보통 테이블에 입력되기 전의 모든 새로운 데이터를 검사하는 중간
단계입니다.
# Enabled Validate
1) 테이블의 모든 데이터가 제약 조건을 따르도록 하며 모든 부적합한 데이터가
입력되는 것을 막아 줍니다.
2) 이 상태는 온라인 트랜잭션 처리시 제약 조건의 정상 작업 상태입니다.
2. 제약 조건이 disabled 상태에서 enabled validate 상태가 될 때 테이블은
잠겨지고(locked) 테이블의 모든 데이터가 이 상태에 일치하는지 여부를 검사합니다.
3. 이 때 데이터 로드 등 DML작업의 대기를 발생시킬 수 있습니다.
4. 그렇기 때문에 disabled 상태를 enable novalidate 상태를 거쳐 enable validate
상태로 옮겨 가는 것이 현명합니다.
14-9. 지연된 제약 조건(Deferred Constraints)
1. 트랜잭션 시 제약 조건을 검사할 시점은 제약 조건을 적절히 정의하여 제어할 수
있습니다.
# 지연되지 않은 제약 조건, 또는 즉시 제약 조건
1) 즉시 제약 조건이라고도 불리우는 지연되지 않은 제약 조건은 모든 DML문 끝에
적용됩니다.
2) 제약 조건에 위배되면 명령문을 롤백시키게 됩니다.
3) 제약 조건이 연쇄 삭제(delete cascade)같은 작업을 발생시키면 연쇄 작업은
그 작업을 발생시킨 명령문의 일부로 취급됩니다.
# 지연된 제약 조건
1) 지연된 제약 조건은 트랜잭션 커밋 시에만 검사하는 제약 조건입니다. 커밋시
어떠한 제약 조건이라도 위배되면 전체 트랜잭션이 룰백됩니다.
2) 외래키 관계인 부모 행과 자식 행이 동시에 입력될 때 유용합니다.
3) 예를 들어 주문 입력 시스템의 경우에는 주문과 주문에 따른 품목이 동시에
입력되는 경우입니다.
4) 제약 조건이 지연되려면 생성시 지연 가능한 제약 조건으로 정의되어야만 합니다.
5) 지연될 수 있도록 정의된 제약 조건은 다음 중 하나로서 지정될 수 있습니다.
2. initially immediate는 명시적으로 다르게 설정되지 않은 한 즉시 제약조건으로써
작동하도록 기본값으로 지정합니다.
3. Initially deferred는 트랜잭션이 끝날 때에만 제약 조건이 적용되도록 기본값으로
지정합니다.
4. 지연 가능한 제약 조건의 적용 기본 모드로 정의되어 데이터 딕셔너리에 저장되더라도
응용 프로그램은 제약 조건을 지연된, 또는 즉시 제약 조건 방식으로 동작하도록
수정할 수 있습니다.
5. 이러한 일은 아래에 보여지는 ALTER SESSION 명령이나 SET CONSTRAINT 명령을
사용하여 이룰 수 있습니다.
ALTER SESSION
SET CONSTRAIOT [S] =
(IMMEDIATE | DEFERRED | DEFAULT)
SET CONSTRAINT[S]
{constraint [, constraint ] . . .
| ALL }
{IMMEDIATE | DEFERRED}
14-11. 기본/유일키 적용 (Primary /Unique Key Enforcement)
1. 기본 키와 유일키를 적용하는데 인덱스를 사용하면, 이때 인덱스의 위치와 유형을
제어할수 있습니다.
2. 오라클 서버는 유일키와 기본키 제약조건을 구현하기 위해 다음절차를 따릅니다.
1) 제약조건이 disable이면 인덱스가 필요치 않습니다.
2) 제약조건이 enable 이면 제약조건이 지정된 열이 인덱스의 선행부분에 해당하면
제약조건을 적용하는데 그 인덱스가 사용될 것입니다.
3) 제약조건이 enable이고 제약조건이 지정된 열을 인덱스의 선행부분으로 사용하는
인덱스가 없다면 제약조건과 같은 이름을 가진 인덱스가 다음 규칙을 따라 생성됩니다.
3. 키가 지연 가능하면 키 열에 대해 Nonunique 인덱스가 생성됩니다.
4. 키가 지연 가능하지 않다면 Unique 인덱스가 생성됩니다.
14-12. 외래키 고려사항 (Foreign Key Considerations)
---------------------------+----------------------------------
* 고려시기 * | * 수행 *
---------------------------+----------------------------------
부모테이블 삭제 | 제약조건 전달(cascade)
---------------------------+----------------------------------
부모테이블 절단(truncate) | 외래키 disable또는 삭제
---------------------------+----------------------------------
부모테이블을 포함하는 | CASCADE CONSTRAINTS절 사용
테이블스페이스 삭제 |
---------------------------+----------------------------------
부모 테이블에 DML수행시 | 외래키 상에 인덱스 생성
자식테이블에의 잠금(LOCK) |
---------------------------+----------------------------------
자식테이블에 DML수행 | 부모키 인덱스를 포함하고 있는
| 테이
블스페이스를 온라인 상태로
---------------------------+----------------------------------
1. Foreign Key 관계인 테이블들을 유지하려면 여러 가지 요인들을 고려해야 합니다.
# 부모테이블에 관련된 DDL
1) 부모 테이블을 삭제하기 전에 Foreign Key가 먼저 삭제되어야 합니다. 다음명령을
사용하여 한 문장으로 두 작업을 수행하십시오.
DROP TABLE DEPT CASCADE CONSTRAINTS
* Foreign Key를 삭제시키고 ParentTable를 삭제시킨다.
2) 부모 테이블은 Foreign Key를 삭제하거나 disable시키지 않고는 잘라 버려질
수 없습니다.
3) 부모 테이블을 포함하고 있는 TableSpace를 삭제하기 전에 Foreign Key가
먼저 삭제되어야 합니다. 다음명령을 사용하십시오.
DROP TABLESPACE tablespace INCLUDING CONTENTS
CASCADE CONSTRAINTS
2. Foreign Key 관계인 테이블상의 DML(**매우중요**)
- 부모테이블에서 행이 삭제될 때 DELETE CASCADE 옵션이 사용되지 않으면 오라클
서버는 외래 키에 대응되는 자식테이블에 행이 없는지 확인해야만 합니다.
- 마찬가지로 변경하려는 키 값을 가진 자식 행이 없어야만 부모 키에 대한 갱신이
이루어집니다.
- 자식테이블의 외래 키 상에 인덱스가 없으면 오라클 서버는 자식테이블을
잠그고 (LOCK)참조 무결성을 위해 변경을 막습니다.
- 자식 테이블에 인덱스가 있으면 인덱스 엔트리를 잠그고 자식테이블에 더 이상의
제한적인 잠금을 하지 않게 하면서 참조 무결성을 유지합니다.
- 부모테이블과 자식테이블이 서로 다른 트랜잭션에 의해 동시에 갱신되어야
한다면 외 래키 열에 인덱스를 생성하십시오.
- 자식 테이블에 데이터가 삽입되거나 외래키 열이 갱신될 때 오라클 서버는 참조키를
적용하는데 사용되는 부모테이블상의 인덱스를 검사합니다.
- 그러므로 인덱스를 포함하고 있는 테이블스페이스가 온라인 상태일 때만 작업이
성공적으로 수행됩니다.
- 자식테이블에 대한 DML작업을 수행하기 위해 부모테이블을 포함하고 있는
테이블스페이스가 온라인상태가 될 필요는 없음을 명심하시오.
주)위에 언급된 장점 외의 성능에 대한 다른 장점들이 있으므로 외래 키 열에 인덱스를
생성할 것을 권장합니다.
14-14. 데이터베이스 트리거
- 데이터베이스 트리거는 연관된 테이블에 DML문이 수행될 때 암시적으로 수행되는
PL/SQL 프로그램입니다.
# 트리거 유형
- 트리거에 대해 지정할 수 있는 다음 세 가지 특성에 기초하여 테이블에 정의 될 수
있는 트리거 조합은 12가지입니다.
# DML 문
- INSERT나 UPDATE 또는 DELETE 또는 이 명령문들의 조합이 테이블에 실행될 때
트리거가 실행되도록 설정할 수 있습니다.
- 갱신 트리거를 정의할 때 열 이름을 지정하면 트리거는 지정된 열이 갱신될 때만
수행됩니다,
# 시점(TIMING)
- 트리거는 트리거문 이전 또는 이후에 실행되도록 정의될 수 있습니다.
* Before Trigger, After Trigger
# 빈도(Frequency)
- 주어진 DML문장에 대해 트리거가 몇 번 수행되도록 할 것인지 제어할 수 있습니다.
- ROW 트리거는 영향을 받는 매 행마다 한번씩 실행되고 STATEMENT 트리거는 영향을
받는 행의 수와는 관계없이 명령문에 대해 단 한번 실행됩니다.
# 트리거 상태
- 트리거는 enable 또는 disable될 수 있습니다. Disable된 트리거는 대응되는
DML작업이 테이블에 수행될 때 실행되지 않습니다.
- Enable된 트리거는 대응되는 DML명령 수행시 실행됩니다. 트리거가 사건에 의해
실행되므로 트리거가 enable 될 때 기존 데이터에 작업을 수행하지는 않습니다.
# 트리거 생성의 예
- 다음 트리거는 사원의 이름을 저장하기 전에 INITCAP 함수를 사용하여 변환합니다.
CREATE TRIGGER scott.emp_conv_ln
BEFORE INSERT OR UPDATE OF last_name ON scott.employees
FOR EACH ROW
BEGIN
:NEW.last_name ;= INITCAP(:NEW.last_name);
END;
주) 트리거는 PL/SQL Program Units과정에서 더 자세히 다루어집니다.
14-16. 테이블 생성시 제약조건 정의
- 제약조건은 테이블이 생성되거나 제약조건을 추가하기 위해 테이블을 수정할 때
정의될 수 있습니다.
* column Level, Table Level 제약조건
* NOT NULL 은 Column Level에서만 가능
# 예(**중요**)
CREATE TABLE emp
(empno NUMBER(4) CONSTRAINT emp_pk PRIMARY KEY DEFERRABLE
USING INDEX
STORAGE(INITIAL 100K
NEXT 100K)
TABLESPACE index01, --> INDEX가 들어갈 TABLESPACE, COLUMN LEVEL
last_name VARCHAR2(20) CONSTRAINT emp_ln_nn NOT NULL, --> COLUMN LEVEL
deptno NUMBER(2), --> TABLE LEVEL
CONSTRAINT emp_deptno_fk FOREIGN KEY (deptno) REFERENCES dep(deptno))
TABLESPACE USERS;
# 구문 : In-Line 제약조건(Column Level)
- 테이블에 생성될 때 제약조건은 라인 내에 열을 정의하는 다음 구문을 사용하여
생성 할 수 있습니다.
column datatype [CONSTRAINT constraint]
in_line_constraint
[defer_spec]
in_line_constraint :==
{ [NOT] NULL
|PRIMARY KEY [USING INDEX index_clause]
|UNIQUE [USING INDEX index_clause]
|REFERENCES [schema.]table [(column)]
[ON DELETE CASCADE]
|CHECK (condition)
}
defer_spec :==
[NOT DEFERRAABLE
|DEFERRABLE [INITIALLY {IMMEDIATE|DEFERRED} ] ]
[DISABLE|ENABLE [VALIDATE|NOVALIDATE]]
- 구문에서
1) CONSTRAINT : 데이터 딕셔너리에 CONSTRAINT 라는 이름으로 저장된는 무결성
제약조건을 나타냄
2) USING INDEX : 유일키, 기본키 제약조건의 경우 오라클 서버가 사용하는 인덱스를
위해 사용되어야 하는 파라메터를 index_clause 절에 지정합니다.
(인덱스 이름은 제약조건이름과 동일)
3) DEFERRABLE : SET CONSTRAINT(S) 명령을 사용하여 트랜잭션이 끝날 때 까지
제약조건 검사를 지연할수 있도록 합니다.
4) NOT DEFERRABLE : 매 DML문이 끝날때마다 제약조건이 검사되도록 합니다.
(NOT DEFERRABLE 제약조건은 세션이나 트랜잭션에 의해 지연될
수 없습니다. NOT DEFERRABLE이 기본값임)
5) INITIALLY IMMEDIATE : 매 트랜잭션이 시작될때 각 DML문이 끝날 때마다
이 제약조건을 검사하는 것을 기본값으로 합니다.
(INITIALLY 절이 지정되지 않으면 INITIALLY IMMEDIATE가 기본값입니다.)
6) INITIALLY DEFERRED : 제약조건은 : DEFERRABLE상태이며 기본값으로 매 트랜잭션이
끝날때에만 제약조건을 검사하도록 지정합니다.
7) DISABLE : 무결성 제약조건을 disable합니다. 무결성 제약 조건이 disable되면
오라클 서버는 적용하지않습니다.
* DISABLE 상태이지만 부모TABLE이 SETTING이 되고 CHILD TABLE도 SETTING이 되어
있어야 한다
- 구문 : Out-of-Line 제약조건(Table Level)
제약조건은 다음 구문을 사용하여 라인 밖에서 생성될 수도 있습니다.
[CONSTRAINT constraint ]
out_of_line_constraint
out_of_lin_constraint :==
{PRIMARY KEY(column[, column]...)
[USING INDEX index_clause]
|UNIQE (column[, column]...)
[USING INDEX index_clause]
|FOREIGN KEY (column[,column]...)
REFERENCES [schema.]table[(column[,column]...)]
[ON DELETE CASCADE]
|CHECK (condition)
}
[defer_spec]
- 주
1) 제약조건에 대한 표준 명명 규약을 채택하는 것이 좋습니다. CHECK 제약조건의
경우 동일한 제약조건이 다른 이름으로 여러번 생성될 수 있기 때문에 특별히
더 그렇습니다.
2) out-of-line제약조건은 다음 경우에 필요합니다.
(1) 제약조건이 둘 이상의 열을 포함할 때
(2) 테이블에 NOT NULL제약조건외의 다른 제약 조건이 추가되어 고쳐질때
- 테이블 생성한 후 제약조건 정의의 예
ALTER TABLE scott.employees
ADD (CONSTRAINT emp_dep_fk FOREIGN KEY (deptno)
REFERENCES scott.departments(deptno)
DEFERRABLE INITIALLY DEFERRED);
- table 생성한후 제약조건 예
SQL> alter table emp add constraint
2 emp_dmpno_pk primary key(empno);
- 주
본장의 "제약조건 Enable(Enabling Constriants)"에서 다루어질 EXCEPTIONS 절은
ALTER TABLE 명령을 사용하여 추가된 제약조건에 위배되는 행을 찾아 내는데
사용할 수 있습니다.
** 제약조건 정의시 지침사항
. 기본과 유일 제약조건:
- 인덱스를 별개의 테이블스페이스에 위치시키십시오
- 자주 대량으로 로드한다면 nonunique 인덱스를 사용하십시오.
. 자기참조 외래키:
- 먼저 로드한 후 외래키를 정의하거나 enable 하십시오
- 제약조건 검사를 연기하십시오
- 제약조건을 정의할 때 다음 지침 사항이 유용할 것입니다.
1) 기본키와 유일제약 조건을 적용하는데 사용하는 인덱스를 테이블과는 별도의
테이블스페이스에 위치시키십시오.
USING INDEX절을 지정하거나 테이블을 생성하고 인덱스를 생성한 후 테이블을 고쳐서
제약조건을 추가하거나 enable시키면 됩니다.
(**매우중요**)
2) 데이터가 테이블로 자주 대량 로드되면 제약 조건을 disable시킨후 로드를
수행하고 제약조건을 enable시키는 것이 더 나을 것입니다.
(*)기본키나 유일제약 조건을 적용하기 위해 unique 인덱스가 사용되면 이 인덱스는
제약조건이 disable될때 삭제되어야 합니다.
(*)이러한 상황에서 기본키나 유일 제약 조건을 적용하기 위해 nonunique 인덱스를
사용함으로써 성능이 향상될 수 있습니다.
지연가능하도록 키를 생성하거나 또는 키를 정의하거나 enable하기전에 인덱스를
생성하면 됩니다.
3) 테이블이 자기 참조 외래키를 가지고 있으면 데이터를 로드할 때 다음 중 한가지
방법을 사용하세요
(1) 처음 로드한 후 외래키를 정의하거나 enable시킴
(2) 제약조건을 지연 가능하도록 정의
* 데이터가 자주 로드될 경우 두번째 방법이 유용합니다.
** 제약조건 Disable
. 특히 자기참조 외래키의 경우 대량으로 로드하기 전에 disable하십시오.
. 부모키를 disable하기전에 외래 키 참조를 disable하십시오
ALTER TABLE scott.departments
DISABLE CONSTRAINT dept_pk CASCADE; --> CHILD의 FK를 DISABLE시킨다.(CASCADE)
. Unique 인덱스는 삭제됩니다만 nonunique 인덱스는 삭제되지 않습니다.
- 구문
다음 명령을 사용하여 제약조건을 disable하십시오.
ALTER TABLE [schema.] table
DISABLE {CONSTRAINT constraint
| PRIMARY KEY
| UNIQUE {column[, column ]....)}
[ CASCADE ]
- 제한사항
. 기본키, 또는 유일제약 조건을 제외한 모든 제약조건은 이름이 지정되어야 합니다.
. 기본키나 유일제약 조건이 외래키에 의해 참조되면 기본키나 유일제약조건을
disableE하기전에 CASCADE키워드를 사용하여 외래키를 disable 시키시라
**제약조건 Enable
Enable novalidate => *테이블 잠그지 않음
*기본/유일 키는 반드시 nonunique인덱스를 사용해야 함.
┌──────────────────────┐
│ALTER TABLE scott.departments │
│ENABLE NOVALIDATE CONSTRAINT dept_pk; │
└──────────────────────┘
현재 disable 된 제약 조건은 다음 두 가지 방법 중 하나로 enable될 수 있습니다.
¤Enable NOVALIATE : 새로운 DATA만 체크
¤Enable VALIDATE
ENABLE NOVALIDATE(특징만)
제약조건을 NOVALIDATE로 하는 것이 제약 조건을 validate 로 enable하는것 보다
더 빠릅니다.
왜냐하면 지연 가능하다면 기존 데이터가 제약 조건에 위배되는지 검사하지 않기
때문입니다.
제약조건을 enable할 때 이 옵션을 사용하면 테이블이 잠기지도 않습니다
OLTP환경처럼 테이블에 DML작업이 맣이 가해질 때는 이 방법이 적절합니다.
구문
제약 조건을 novalidate로 enable하려면 다음 명령을 사용하십시오.
ALTER TABLE [schema.] table
ENABLE NOVALIDATE {CONSTRAINT constraint
| PRIMARY KEY
| UNIQUE {column [ ,column] . . .)]
[USING INDEX index_clause]
제한 사항
USING INDEX 절은 기본 키나 유일 제약 조건이 지연 가능으로 생성되고 다음 중
하나가 참일 경우에만 적용 가능합니다.
- 제약조건이 disable로 생성되었는가 (인덱스가 있는 경우)
- 제약 조건이 disable되어 있고 인덱스가 삭제되었는가?
하지만, 인덱스가 생성되어야 할 때 제약조건을 enable 하기 위해 이 방법을 사용하는
것은 오라클 서버가 인덱스를 구축하기 위해 테이블을 잠가(LOCk)버리기 때문에
vaildate로 enable하는 것 보다 현저한 장점을 제공하지는 못합니다.
Enable validate => *테이블 잠금(주의)
*unique, 또는 nounique 인덱스 사용가능
*적합(vaild)한 테이블 데이터 필요
┌──────────────────────┐
│ALTER TABLE scott.empliyees │
│ENABLE VALIDATE CONSTRAINT emp_dept_fk; │
└──────────────────────┘
Enable VAILDATE
제약조건을 vaildate로 enable하면 기존 데이터도 제약 조건에 위배되지 않는지
검사합니다.
제약조건이 enable될 때는 이것이 기본값입니다.
Disable된 제약조건에 수행되면 다음과 같은 효과를 갖습니다.
¤테이블이 잠겨서 기존데이터에 대한 적합성 여부 판정이 완료될 때까지는 테이블에
대한 변경이 금지 됩니다.
¤오라클 서버는 인덱스 열에 인덱스가 존재하지 않으면 하나 생성합니다.
지연 가능하지 않은 기본 키나 유일 제한 조건을 enable할 때 인덱스를 생성합니다.
지연가능한 기본키나 유일제한조건에 대해서느느 유일하지 않은 인덱스가 구축됩니다.
제약조건이 적용되고 있을 때 이 명령이 실행되면 적합성 여부를 판정하는 동안 어느
테이블도 잠기지 않습니다.
시행된 제약 조건은 적합성 여부를 판정하는 동안 어더한 위배 사항도 받아들여지지
않도록 합니다.
이 방법은 다음과 같은 장점을 가집니다.
¤모든 제약조건이 동시에 enable됩니다.
¤가가 제약 조건들은 내부적으로 병렬화되어 있습니다.
¤테이블에 동시 작업이 허용됩니다.
- 구문
다음 명령을 사용하여 제약조건을 vaildate로 enable하십시오.
ALTER TABLE [schema.] table
ENABLE [VALIDATE] {CONSTRAINT constraint
| PRIMARY KEY
| UNIQUE (column [ ,column] . . .)]
[USING INDEX index_clause]
[EXCEPTIONS INTO [schema.] table]
* 주
- VALIDATE 옵션이 기본값이므로 disable된 제약조건을 enable할 때 지정하지 않아도
됩니다.
- 테이블 내의 데이터가 제약 조건을 위배하면 명령문은 롤백되고 제약조건은 disable인
채로 남아있게 됩니다.
- EXCEPTIONS절의 사용법은 다음 절에서 다루어 집니다.
(**매우중요**)
┌─────────────────────────────────────┐
│ EXCEPTIONS 테이블 사용 │
│1.EXCEPTIONS 테이블을 생성하십시오.(utlexcpt.sql). │
│2.EXCEPTIONS 절을 가진 ALTER TABLE을 실행시
키십시오. │
│3.EXCEPTIONS에 질의하는 서브쿼리를 이용하여 부적합한 데이터를 가진 행을 찾│
│ 아 내십시오. │
│4. 에러를 교정하십시오. │
│5. ALTER TABLE을 재실행하여 제약조건을 enable시키십시오. │
└─────────────────────────────────────┘
EXCEPT 절은 현재 enable하려는 제약 조건을 위배하는 행을 찾아내는데 도움을 줍니다.
제약 조건에 위배된 것을 검출해 내고 교정한 후 제약 조건을 다시 enable시키려면
다음 절차에 따르십시오.
1. exceptions 테이블이 생성되어 있지 않으면 관리 디렉토리 내의 utlexcpt.sql스크립트를
실행시켜 exception테이블을 생성하십시오.
SVRMGR>@?/rdbms/admin/utlexcpt
starement processed.
SVRMGR> DESCRIBE execptions
Name Null? Type
------------------- ----------------- ------------------------------
ROW_ID UNDEFINED
OWNER VARCHAR2(30)
TABLE_NAME VARCHAR2(30)
CONSTRAINT VARCHAR2(30)
Win NT의 경우에는 %ORACLE_HOME%\RDBMS80\ADMIN디렉토리에 있습니다.
2. EXCPTIONS 절을 포함하는 ALTER TABLE명령을 실행하십시오.
SVRMGR> ALTER TABLE scott.employees
2> ENABLE VALIDATE CONSTRAINTS emp_dept_fk
3> EXCEPTIONS INTO system.exceptions;
ALTER TABLE scott.employees
*
ORA-02298: cannot enable (SCOTT.EMP-EMPT_FK) - parent keys not found
SVRMGR>
EXCEPTIONS 테이블의 소유자는 이름을 지정하지 않았을 경우 변경하는 테이블의
소유자로 간주합니다.
행들이 EXCEPTIONS 테이블에 삽입됩니다.
명령을 재실행할 경우 EXCEPTIONS 테이블을 잘라버려(truncate) 기존 행을
제거하십시오.
3. EXCEPTIONS테이블에 서브쿼리를 사용하여 부적합한 데이터를 가려 내십시오.
SVRMGR>SELECT rowid, empno, last_name, deptno
2>FROM scott.employees
3>WHERE ROWID in (SELECT row_id
4>FOR UPDATE;
Rowid EMPNO DEPTNO
------------------- ---------- ------------------------
AAAAeyAADAAAAA1AAA 1003 50
1 row processed.
4.데이터 내의 에러를 바로 잡으십시오.
SVRMGR>UPDATE scott.employees
2>SET deptno=10
3>WHERE rowid='AAAAeyAADAAAAA1AAA';
1 row processed.
SVRMGR>COMMIT;
statment processed.
5. EXCEPTIONS 테이블을 잘라 버리고 제약 조걱능 다시 enable하십시오.
SVRMGR>TRUNCATE TABLE exceptions;
statemnt processed.
SVRMGR> ALTER TABLE scott.employees
2> ENABLE VALIDATE CONSTRAINT emp_dept_fk
3> EXCEPTIONS INTO system.exceptions;
statement processed.
┌─ ─────────────────────────────── ───┐
│ ◆트리거 Disable, Enable │
│ │
│*트리거 하나를 disable하거나 enable하려면 ALTER TRIGGER를 사용하십시오 │
│┌──────────────────────────────┐ │
││ ALTER TRIGGER scott,emp_copy_ln DISABLES; │ │
│└──────────────────────────────┘ │
│*트리거 전부를 disable하거나 enable하려면 ALTER TABLE을 사용하십시오 │
│┌──────────────────────────────┐ │
││ ALTER TABLE scott,emp_employees ENABLE DISABLES; │ │
│└──────────────────────────────┘ │
└────────────────────────────────────┘
트리거 disable하기
다음경우 트리거를 disable해야 할 필요가 있습니다.
▶ 트리거가 참조하는 오브젝트가 사용 가능하지 않은데 테이블에의 작업을 멈출 수
없을때
▶ 트리거를 가진 테이블에의 다량의 데이터 로드 속
도를 높일 때 트리거를 disable
하려면 다음 명령을 사용 하십시오.
ALTER TRIGGER [schema .] trigger DISABLE
- 트리거 Enable하기
. 트리거를 enable하려면 다음 명령을 사용하십시오.
ALTER TRIGGER [schema .] trigger ENABLE
. 테이블의 모든 트리거를 enable하거나 disable하려면 다음 구문을 사용하십시오.
ALTER TABLE [schema .] TABLE
{DISABLE | ENABLE } ALL TRIGGERS
┌───────────────────────────┐
│ ◆트리거 Disable, Enable │
│ │
│*다음 명령을 사용하여 제약조건을 삭제하십시오. │
│┌─────────────────────────┐│
││ ALTER TABLE scott,employees ││DROP CONSTRANINT emp_ln_uk;
│└─────────────────────────┘│
│*다음 명령을 사용하여 테이블과 그 테이블을 참조하는 │
│ 외래키를 동시에 삭제하십시오. │
│┌─ ─────────────────-- ─────┐│
││ DROP TABLE departments ││CASCADE CONSTRAINTS;
│└─────────────────────────┘│
└───────────────────────────┘
다음과 같은 때 제약 조건이 삭제할 수 있습니다.
▶ 제약 조건이 더 이상 필요하지 않을때
▶ 제약 조건이 수정되어야 하는데 직접 수정할 수 없고 삭제한 후 추가해야만 할때
구문
제약 조건을 삭제하려면 다음 명령을 사용하십시오.
ALTER TABEL [schema .] table
DROP {CONSTRAINT constraint
| PRIMARY KEY
| UNIQUE {colum [ , colums ] . . . ) )
[ CASCADE ]
주
▶ 외래 키가 참조하는 제약 조건을 삭제하려면 CASCADE옵션을 사용하십시오.
▶ 기본키나 유일 제약 조건이 nonunique인덱스를 사용하여 구현되었다면 관련된
인덱스는 삭제되지 않습니다. 따라서 더 이상 필요치 않으면 수동으로 삭제해야 합니다.
부모 테이블 삭제
외래 키에 의해 참조되는 테이블은 외래 키가 삭제되어야만 삭제할 수 있습니다.
다음 명령을 사용하십시오.
DROP [schema .]table
CASCADE constraints
부모 테이블이 재구성될 때 이것이 필수적일 수도 있습니다.
┌─────────────────────────────────────┐
│▶ 트리거 삭제 |
│┌──────────────────────────────────┐ │
││DROP TRIGGER scott.audit_dept │ │
│└──────────────────────────────────┘ │
└─────────────────────────────────────┘
다음 명령을 사용하여 더 이상 필요하지 않은 트리거를 삭제하십시오.
DROP TRIGGER [schema .] trigger
14-31.
제약 조건 정보
______________________ _______________________
| DBA_CONSTRAINTS |_ _| DBA_CONS_COLUMNS |
| OWNER | |__| | OWNER |
| CONSTRAINT_NAME |_| |_| CONSTRAINT_NAME |
| CONSTRAINT_TYPE | | TABLE_NAME |
| TABLE_NAME | | COLUMN_NAME |
| SEARCH_CONDITION | | POSITION |
| R_OWNER | | |
| R_CONSTRAINT_NAME | |_______________________|
| DELETE_RULE |
| STATUS |
| DEFERRABLE |
| DEFERRED |
| VALIDATED |
| GENERATED |
| BAD |
| LAST_CHANGE |
|______________________|
제약 조건과 그 상태
scott의 emp테이블에 대한 모든 제약 조건의 이름, 유형, 그리고 상태를 알고 싶으면
다음 질의문을 사용하십시오.
SVRMGR> SECLECT constraint_name, constraint_type, deferrable,
2> deferred, validated
3> FROM dba_constraints
4> WHERE owner='SCOTT'
5> AND table_name='EMPLOYEES';
CONSTRAINT_NAME C DEFERRABLE DEFERRED VALIDATED
---------------- - -------------- ---------- --------------
EMP_DEPT_FK R DEFERRABLE DEFERRED VALIDATED
EMP_PK P DEFERRABLE IMMEDIATE VALIDATED
SYS_C00565 C NOT DEFERRABLE IMMEDIATE VALIDATED
3 rows selected.
14-32.
다음 표는 DBA_CONSTRAINTS뷰 내의 일부 열들에 대한 설명입니다.
+--------------------+--------------------------------------------------------+
| 이름 | 설명 |
+--------------------+--------------------------------------------------------+
| CONSTRAINT_TYPE | 제약 조건의 유형은 기본 키이면 P, 유일 키이면 U, 외래 |
| | 키이면 R, 검사(Check)이면 C입니다. NOT NULL 제약조건은 |
| | 검사 제약조건으로 저장됩니다. |
+--------------------+--------------------------------------------------------+
| SEATCH_CONDITION | 검사 제약 조건으로 지정된 조건을 보여 줍니다. |
+--------------------+--------------------------------------------------------+
| R_OWNER | 외래 키가 참조하는 제약 조건의 소유자와 이름을 정의 |
| R_CONSTRAINT_NAME | 입니다. |
+--------------------+--------------------------------------------------------+
| GENERATED | 제약 조건의 이름이 시스템에 의해 생성되었는지 여부를 |
| | 보여 줍니다.(가능한 값은 'USER NAME'과 'GENARATED NAME'|
| | 입니다.) |
+--------------------+--------------------------------------------------------+
| BAD | 제약 조건이 Y2K문제 같은 것들을 피할 수 있도록 쓰여졌 |
| | 는지를 보여 줍니다.(오라클 이전 버전에서 검사 제약조건 |
| | 에 두 자리수로 년도를 지정할 수 있게 허용했기 때문에 |
| | 발생할 수 있습니다.) |
+--------------------+--------------------------------------------------------+
| LAST_CHANGE | 제약 조건이 마지막으로 enable되거나 disable된 날짜 |
| | 입니다. |
+-----------------
---+--------------------------------------------------------+
제약 조건의 열
SCOTT의 EMP테이블에 대한 제약 조건의 열을 알고 싶으면 다음 질의문을 사용하십시오.
SVRMGR> SELECT c.constraint_name, c.constraint_type, cc.column_name
2> FROM dba_constraints c, dba_cons_columns cc
3> WHERE c.owner='SCOTT'
4> AND c.table_name='EMPLOYEES'
5> AND c.owner = cc.owner
6> AND c.constraint_name = cc.constraint_name
7> ORDER BY cc.position;
CONSTRAINT_NAME C COLUMN_NAME
---------------------- - --------------
EMP_DEPT_FK R DEPTNO
EMP_PK P EMPNO
SYS_C00565 C LAST_NAME
3 rows selected.
14-33.
기본 키 - 외래 키 관계 찾기
SCOTT의 EMP테이블의 외래 키와 부모 제약 조건을 찾으려면 다음 질의문을 사용하십시오.
SVRMGR> SELECT c.constraint_name AS "Foreign Key",
2> p.constraint_name AS "Referenced Key",
3> p.constraint_type, p.owner, p.table_name
4> FROM dba_constraints c, dba_constraints p
5> WHERE c.owner='SCOTT'
6> AND c.table_name='EMPLOYEES'
7> AND c.constraint_type='R'
8> AND c.r_owner=p.owner
9> AND c.r_constraint_name = p.constraint_name;
Foreign Key Referenced Key C OWNER TABLE_NAME
------------ -------------- - --------- --------------
EMP_DEPT_FK DEPT_PK P SCOTT DEPARTMENTS
1 row selected.
14-34.
트리거에 대한 정보
____________________ ___________________
| DBA_TRIGGERS | | DBA_TRIGGER_COLS |
| OWNER |_ _| TRIGGER_OWNER |
| TRIGGER_NAME | |_____| | TRIGGER_NAME |
| TRIGGER_TYPE |_| | |_| TABLE_OWNER |
| TRIGGERING_EVENT | | | TABLE_NAME |
| TABLE_OWNER | | | COLUMN_NAME |
| TABLE_NAME | | +-------------------+
| STATUS | | _+-------------------+
| DESCRIPTION | |__| | DBA_OBJECTS |
| TRIGGER_BODY | |_| OWNER |
+--------------------+ | OBJECT_NAME |
| OBJECT_TYPE |
| STATUS |
+-------------------+
14-35.
트리거와 트리거 열
SCOTT의 EMP테이브레 대한 모든 트리거의 이름과 UPDATE OF절의 열을 알고 싶다면
다음 질의문을 사용하십시오.
SVRMGR> SELECT t.owner, t.trigger_name, t.trigger_type,
2> t.triggering_event, t.status,
3> c.column_name, o.status as "VALIDITY"
4> FROM dba_triggers t, dba_trigger_cols c,
5> dba_objects o
6> WHERE t.owner = c.trigger_owner (+)
7> AND t.trigger_name = c.trigger_name (+)
8> AND t.owner = o.owner
9> AND t.trigger_name = o.object_name
10> AND o.object_type = 'TRIGGER'
11> AND t.table_owner = 'SCOTT'
12> AND t.table_name = 'EMPLOYEES';
OWNER TRIGGER_NAME TRIGGER_TYPE TRIGGERING_EVENT STATUS
----------- ------------- ------------ ---------------- ------
COLUMN_NAME VALIDITY
----------- -------------
SCOTT EMP_CONV_LN BEFORE STATEMENT INSERT OR UPDATE ENABLED
LAST_NAME VALID
SCOTT T1 BEFORE STATEMENT UPDATE ENABLED
EMPNO INVALID
2 rows selected.
14-36.
요약
. 제약 조건과 트리거 구현
. 제약 조건을 생성하고 유지할 적절한 전략사용
14-37.
요약 참조
+-------------------------+----------------------------------------+
| 관련 내용 | 참조 |
+-------------------------+----------------------------------------+
| 초기화 파라미터 | 없음 |
+-------------------------+----------------------------------------+
| 동적 성능 뷰 | 없음 |
+-------------------------+----------------------------------------+
| 데이터 딕셔너리 뷰 | DBA_CONSTRAINTS |
| | DBA_TRIGGERS |
| | DBA_TRIGGER_COLS |
+-------------------------+----------------------------------------+
| 명령어 | CREATE TABLE...CONSTRAINT
|
| | ALTER TABLE ADD CONSTRAINT... |
| | EXCEPTIONS INTO |
| | CREATE OR REPLACE TRIGGER |
| | ALTER TABLE...DISABLE CONSTRAINT |
| | ALTER TABLE...ENABLE NOVALIDATE |
| | CONSTRAINT |
| | ALTER TABLE...ENABLE VALIDATE |
| | CONSTRAINT...EXCEPTIONS INTO |
| | ALTER TRIGGER...DISABLE |
| | ALTER TABLE...DISABLE ALL TRIGGERS |
| | ALTER TRIGGER...ENABLE |
| | ALTER TABLE...ENABLE AL
L TRIGGERS |
| | ALTER TRIGGER...COMPILE |
| | ALTER TABLE...DROP CONSTRAINT |
| | DROP TABLE...CASCADE CONSTRAINTS |
| | DROP TRIGGER |
+-------------------------+----------------------------------------+
| 패키지 프로시저와 함수 | 없음 |
+-------------------------+----------------------------------------+
제 15 장 Cluster와 INDEX-Organized테이블
15-3.
- 목적
. Cluster 생성과 관리
. Index-Organized Table 사용
. Data Dictionary에서 Cluster와 Table에 대한 정보 검색
15-4.
- Table 내의 행 분포
Table Cluster Index-Organized
Table
--------------- 행의 순서 -------------------->
임의(Random) 그룹(Grouped) 순서(Ordered)
정규 테이블의 데이터 분포 방식에 대해서 극히 제한된 제어만을 가할 수 있습니다.
테이블이 처음 생성될 때 행은 일반적으로 세그먼트의 첫 익스텐트의 첫 블록부터
삽입됩니다. 하지만, 일단 한번 DML작업이 수행되면 프리 리스트(free list)내에서의
블록의 순서와 행 이전(row nigration)같은 여러 가지 요인들이 테이블 내의 행 데이터의
순서를 조절하기 어렵게 만듭니다.
클러스터는 행이 저장되는 방식에 어느 정도의 제어할 수 있도록 합니다. 클러스터를
사용하면 오라클 서버는 가능하다면 동일한 키 값을 찾는 행들을 전부 한 블록에
저장합니다.
Index-Organized 테이블을 사용하면 데이터의 순서에 상당한 제어를 할 수 있습니다.
Index-Organized 테이블의 데이터는 지정된 키 순서로 저장되어 있습니다.
본 장은 뒤의 두 가지 데이터 저장 방식에 대해 중점을 두고 있습니다.
15-5.클러스터
클러스터는 관계된 일련의 행들을 한 오라클 서버 블록에 저장하는데 사용할 수
있습니다. 위 슬라이드는 주문 테이블인 ORD와 주문 품목 테이블인 ITEM이 클러스터에
저장되어 있는 주문 처리 시스템(order processing system)의 예를 보여줍니다.
클러스트된 테이블과 클러스터 되지 않은 테이블의 차이
정규 테이블로 저장될 경우 ORD와 ITEM은 서로 다른 세그먼트에 위치하게 됩니다.
이말은 테이블이 자싱들 고유의 블록을 사용한다는 뜻입니다. 즉, ORD테이블의 행을
저장하는데 사용된 블록은 ITEM테이블의 데이버를 저장하지 않는다는 말입니다.
그 반대의 경우도 마찬가지입니다.
테이블ORD와 ITEM이 클러스터로 저장되면 동일 클러스터 세그먼트를 공유하게
됩니다. 이 세그먼트의 블록은 양 테이블의 행을 모두 저장할 수 있습니다. 테이블이
클러스터로 저장되면 클러스터는 물리적 저장 단위가 되고 테이블은 논리적 엔티티
(즉,클러스터의 일부분)가 됩니다.
클러스터의 특성(**매우중요**)
클러스터는 다음 특성을 갖습니다.
. 클러스터는 함께 저장되어야하는 행들을 구분하는데 사용되는 클러스터 키를
갖습니다.
. 클러스터는 키값에 의해서 들어간다.
. 클러스터 키는 하나 이상의 열로 구성될 수 있습니다.
. 클러스터의 테이블은 클러스터 키에 대응되는 열을 갖습니다.
. 클러스터하는것(clustering)은 테이블을 사용하는 응용프로그램에게 투명한
처리방법입니다.
클러스터된 테이블의 테이터는 마치 정규 테이블에 저장된 것처럼 조작할 수
있습니다.
. 클러스터 키의 열 중 하나를 갱신하면 물리적으로 행을 재배치하는 일을
발생할 수 있습니다.
. 클러스터 키는 기본 키와는 독립적입니다. 클러스터의 테이블은 클러스터 키를
기본키로 가질 수도 있고 다른 열을 기본키로 가질 수도 있습니다.
. 클러스터는 보통 성능향상을 목적으로 합니다.
클러스터된 데이터에의 임의 접근(random access)은 보다 빨라질 수 있습니다.
하지만 일반적으로 클러스터된 테이블을 전체 테이블 스캔(full table scan)하는
속도는 느려집니다.(*)
15-7. 클러스터 유형
클러스터에는 두 가지 유형이 있습니다.
. 인덱스 클러스터
. 해쉬 클러스터
인덱스 클러스터
인덱스 클러스터는 클러스터 내의 데이터를 유지하기 위해 클러스터 인덱스라는
인덱스를 사용합니다.
. 클러스터 인덱스는 인덱스 클러스터 내의 데이터를 저장하거나 접근하거나
유지할 때 사용가능해야만 합니다.
. 클러스터 인덱스의 구조는 보통 인덱스의 구조와 비슷합니다.
보통 인덱스가 NULL키 값을 저장하지 않지만 클러스터 인덱스는 NULL키를 저장합니다.
클러스터인덱스에는 각 키 값에 해단하는 엔트리가 하나 밖에 없습니다.
그러므로 클러스터 인덱스SIZE는 동일한 키 값을 갖는 보통 인덱스보다 더 작습니다.
. 클러스터로부터 행을 저장하고 읽어 들이기 위해 오라클 서버는 주어진
키 값을 갖는 첫 행을 가리키는 클러스터 인덱스를 사용합니다.
. 인덱스 클러스터의 몇몇 행이 동일한 클러스터 키를 가지더라도 클러스터
키가 각 행마다 되풀이되지 않습니다.
키 값 당 행 수가 많은 테이블에서는 인덱스 클러스터를 사용하는 것아 데이터를
저장하는데 필요한 공간을 줄여줄 수 있습니다.
Hash Cluster
Hash Cluster는 행의 위치를 계산해 주는 함수를 사용합니다.
Hash 함수는 Cluster Key를 사용하며 사용자가 정의하거나 시스템이 생성할 수
있습니다.
Hash Cluster의 테이블에 행이 삽입될 때:
. Hash 값을 계산하는데 Hash Key 열이 사용됩니다.
. Hash 값에 기초하여 행이 저장됩니다.
Hash 함수는 Hash Table로부터 데이터를 읽어 들일 때 행의 위치를 찾기 위해
사용됩니다.
적용 가능한 경우 Hash Cluster는 Index Cluster보다 더 뛰어나 성능을 제공해
줍니다.
15-9 Index Cluster 생성(**순서 중요**)
* Cluster Key : 두개의 테이블에 공통적으로 들어있는 column
1. Cluster 생성 : 큰 통을 만든다는 의미
CREATE CLUSTER scott.ord_clu
(ord_no NUMBER(3)) --> Cluster Key를 적는다, type,length반드시 같아야
SIZE 200 TABLESPACE data01
STORAGE (INITIAL 5M NEXT 5M PCTINCREASE 0);
2. Cluster Index 생성
CREATE INDEX scott.ord_clu_idx
ON CLUSTER scott.ord_clu
TABLESPACE index01
STORAGE(INITIAL 1M NEXT 1M PCTINCREASE 0);
* Cluster Index에는 null도 들어간다
3. Cluster에 Table 생성
CREATE TABLE scott.ord
(ord_no NUMBER(3)
CONSTRAINT ord_pk PRIMARY KEY,
ord_dt DATE, cust_cd VARCHAR2(3))
CLUSTER scott.ord_clu(ord_no);
CREATE TABLE scott.item
(ord_no NUMBER(3) CONSTRAINT ord_fk
REFERENCES scott.ord,
prod VARCHAR2(5), qty NUMBER(3),
CONSTRAINT item_pk PRIMARY KEY(ord_no, prod)
CLUSTER scott.ord_clu(ord_no);
다음 단계에 따라 Index를 Cluster에 Table을 생성하십시오.(**중요**)
1. Cluster를 생성합니다.
2. Cluster Index를 생성합니다.
3. Cluster에 Table을 생성합니다.
(*) Index를 생성하기 전에 Cluster에 Table을 생성할 수도 있습니다.
(*) Table에 Data를 삽입하기전에 위 세 단계가 반드시 완료되어야 합니다.
Cluster 생성
Cluster를 생성하려면 다음 명령을 사용하십시오.
CREATE CLUSTER [schma.]cluster (column datatype [ , column
datatype] . . .)
[PCTINCREASE integer]
[PCTUSED integer]
[INITRANS integer]
[MAXTRANS integer]
[SIZE integer [ K | M ]
[storage-clause]
[TABLESPACE tablespace]
[INDEX]
구문에서:
schema Cluster의 소유자
clustrer Cluster 이름
column 키 열 이름
data type 키 열의 데이터 유형과 크기
SIZE 키 값을 갖는 모든 행에 필요한 공간을 바이트나
킬로바이트, 또는 메가바이트 단위로 지정
INDEX Index Cluster로 지정
주
SIZE가 정의되지 않으면 기본값은 한 블록 크기가 됩니다.
오라클 서버는 SIZE에 정의된 값을 사용하여 Cluster 한 블럭에 수용될수 있는
키 값의 최대 수를 산정합니다.
예를 들어 SIZE가 200일 경우 블록 크기가 2048이고 헤더를 허용하면 한 블록에
데이터를 저장하기 위해 사용가능한 공간은 1900바이트 정도가 됩니다.
그러므로 한 블록은 최대9개의 키 값을 가질 수 있습니다.
Cluster Index 생성
Cluster Index를 생성하려면 다음 명령을 사용하십시오.
CREATE INDEX [schema.]index
ON CLUSTER [schema.]cluster
[PCTINCREASE integer]
[INITRANS integer]
[MAXTRANS integer]
[TABLESPACE tablespace]
[storage-clause]
Cluster가 생성될 때 이미 키 열이 정의되므로 Cluster Index의 경우 키 열을 지정할
필요가 없습니다. Cluster Index를 Cluster 생성에 사용한 Table Space와는 다른
Table Space에 위치시키십시오.
Cluster에 Table 생성
Cluster에 Table을 생성하려면 Cluster 이름을 지정하십시오.
CREATE TABLE [schems.]table
(column_definition
[ , column_definition] . . .
[ , [CONSTRAINT constraint] out_of _line_constraint] . . .
)
CLUSTER [schema.]cluster (column [ , column] . . .)
CLUSTER절은 Cluster에 위치해야 하는 Table을 지정합니다.
주
Cluster에 위치한 Table은 그 자체는 Segment가 아니고 Cluster의 일부분이기
때문에 Table만의 물리적 속성을 가질 수 없습니다.
15-12 Hash Cluster 생성
1. Cluster 생성
CREATE CLUSTER scott.off_clu
(country VARCHAR2(2), postcode VARCHAR2(8))-->두개를 묶어서 key값으로함
(*)SIZE 500 HASHKEYS 1000 --> 1000은 충돌이 일어날 가능성을 제어
TABLESPACE data01
STORAGE (INITIAL 5M
NEXT 5M
PCTINCREASE 0);
* 이 Hash 안에 들어갈 것은 적어도 1000개이다.
* SIZE : 같은 값을 갖는 것을 모을려고 한다
2. Cluster에 Table 생성
CREATE TABLE scott.office
(office_cd NUMBER(3), cost_ctr NUMBER(3),
country VARCHAR2(2), postcode VARCHAR2(8))
CLUSTER scott.off_clu(country, postcode);
다음 단계에 따라 Hash Cluster를 생성하고 Table을 위치 시키십시오.
1. Cluster를 생성합니다.
2. Table을 생성합니다.
구문
Hash Cluster를 생성하는 명령은 Index Cluster를 생성하는 명령과 비슷하다.
CREATE CLUSTER [schma.]cluster (column datatype [ , column
datatype] . . .)
HASHKEYS integer
[HASH IS integer]
[PCTINCREASE integer]
[PCTUSED integer]
[INITRANS integer]
[MAXTRANS integer]
[SIZE integer [ K | M ]
[storage-clause]
[TABLESPACE tablespace]
15- 13
HASHKEYS 절은 Cluster가 Hash Cluster임을 나타냅니다.
오라클 서버는 가능한 Cluster Key 값의 갯수로 HASHKEYS에서 지정한 값보다
큰 솟수(PRIME NUMBER)를 사용합니다.
옵션 절 HASH IS는 사용자 정의 Hash 함수, expression!을 지정하는데 사용할 수
있습니다.
15-14
Cluster의 size정의
-주어진 Key를 갖는 행들이 사용할 공간을 정의합니다.
-두가지 유형의 Cluster에서 사용되며 다음 값들을 계산해낼 수 있습니다.
Index Cluster에서 블록 당 Key 값의 최대 갯수
Hash Cluster어서 블록 당 Key 값의 정확한 갯수
SIZE Parameter
Cluster에서 SIZE 파라미터는 주어진 Cluster Key 값을 갖는 행 전부에 의해
사용되는 공간을 정의합니다.
예를 들어 각 주문(order)이 10개의 아이템을 갖고 ORD 테이블의 행 크기가
20바이트이며 ITEM테이블의 행이 18바이트라면 SIZE는 다음 공식으로 정의됩니다.
1 ORD 행 * 20 바이트/행 +10 ITEM 행 * 18바이트/행 = 200바이트
뒤에서 설명되겠지만, 해쉬 클러스터에서 SIZE의 값을 결정할 때는 충돌
가능성을 줄일 수 있도록 다소 높은 값을 지정하는 것이 현명합니다.
15-15
해쉬 클러스터만의 파라미터
- HASHKEYS: 키 값의 갯수
- HASH IS key_column : 사용자 정의 옵션 해쉬 합수
- 사용자정의 함수
HASHKEYS(식은 보기만 할것)
키워드 HASYKEYS는 해쉬 클러스터에서 예상되는 키 값의 갯수를 지정합니다.
SIZE와 함께 오라클 서버가 클러스터의 초기 크기를 산정하는데 사용합니다.
생성시 클러스터에 할당되는 공간은 다음 공식으로 정의됩니다.
* 충돌을 방지하기 위해서 설정을 잘해야한다.
HASHKEYS
CEIL(----------------------------------)
TRUNC(사용 가능한 블록 공간/SIZE)
* CEIL : 반내림 절삭 함수
여기서:
PCTFREE
사용 가능한 블록 공간=(DB_BLOCK_SIZE-헤더)*(1- --------------)
100
15-16
익스텐트는 할당된 익스텐트의 총 크기가 계산된 값과 같거나 그보다 커질 때까지
스토리지 절에 정의된 대로 할당됩니다.
HASH IS
해쉬함수는 사용자가 정의할 수도 있습니다.
함수 선택은 키 분포를 고려하여야 하며 다음과 같아야 합니다.
- 해쉬 값들 사이에 행에 최대 분포가 있도록 합니다.
- 예상하지 않았던 충돌(collisions)횟수를 최소화해야 합니다.
(여러 키 값이 해쉬 함수를 적용했을 때 같은 결과를 낳을 경우 충돌이
발생합니다. 충돌이 발생하고 모든 행을 수용할 만한 충분한 공간이
없으면 새 행은 오버플로우블록에 위치하게 되고 그 행을 가리키는
포인터는 블록에 위치하게 됩니다.)
- 해쉬 함수를 적용한 결과는 양수이어야 합니다.
해쉬 함수는 SYSDATE와 USER 같이 적용할 때마다 결과값이 변하지 않는 적합한
SQL 수식을 포함할 수 있습니다.
사용자 정의 함수를 해쉬 함수의 일부로 사용할 수는 없습니다.
15-17
클러스터 수정
- 스토리지와 블록 공간 사용 파라미터 변경
- 인덱스 클러스터의 SIZE 변경
- 공간 할당과 해제
ALTER CLUSTER scott.ord_clu
SIZE 300 STORAGE (NEXT 2M);
* 해쉬 클러스터의 경우 SIZE 나 HASH IS,또는 HASHKEYS는 수정될 수 없습니다.
다음 표는 인덱스와 해쉬 클러스터에 대해 수행될 수 있는
유지 보수 작업을 요약해 줍니다.
---------------------------------------------------------------------------------
명령 작업 인덱스 클러스터 해쉬클러스터
---------------------------------------------------------------------------------
ALTER 공간 활용 파라미터 변경 YES YES
CLUSTER INITIAL을 제외한 스토리지 설정 변경 YES YES
익스텐트 할당 YES YES
사용되지 않는 공간 할당 해제 YES YES
SIZE 변경 YES NO
HASHKEYS 및 HASH IS 변경 N/A NO
---------------------------------------------------------------------------------
TRUNCATE 공간 해제 YES
NO
CLUSTER 공간 재사용 YES NO
---------------------------------------------------------------------------------
ALTER CLUSTER, TRUNCATE CLUSTER, 그리고 ANALYZE CLUSTER 명령은 테이블에 대해
쓰이는 명령들과 사용방법이 같습니다.
15-18
클러스터 삭제
INCLUDING TABLES를 사용하여 테이블과 클러스터를 삭제하십시오.
DROP CLUSTER scott.ord_clu
INCLUDING TABLES;
또는 클러스터를 삭제하기 전에 테이블을 삭제하십시오.
DROP TABLE scott.ord;
DROP TABLE scott.item;
DROP CLUSTER scott.ord_clu;
클러스터는 클러스터 내의 모든 테이블이 삭제된 후에야 삭제될 수 있습니다.
DROP CLUSTER 명령의 INCLUDING TABLES옵션을 사용하든지 클러스터를 삭제하기
전에 테이블을 삭제하는 방법을 쓰십시오.
구문
클러스터를 삭제하려면 다음 명령을 사용하십시오.
DROP CLUSTER [schema.] cluster
[ INCLUDING TABLES [ CASCADE CONSTRAINTS ] ]
만약 클러스터내의 어느 테이블이라고 클러스터에 속하지 않는 테이블의 외래 키
제약 조건에 의해 참조되고 있다면 CASCADE CONSTRAINTS 절이 사용되어야만 합니다.
*****클러스터가 유용한 상황*****
클러스터를 구현할 때는 케이블에 대한 작업 뿐만 아니라 데이터의 특성도 주의깊게
고려해봐야 합니다.
데이터의 특성
다음 두 문단은 클러스터 데이터의 특성에 대해 설명합니다.
키 값의 분포
클러스터는 일반적으로 키 값의 발생 빈도가 균일한 상황에 더 적합합니다.
주문 처리의 경우 주문이 거의 동일한 수의 아이템을 가지고 있다면 클러스터가
유용합니다. 어떤 주문은 오직 하나, 또는 두개의 아이템만을 가지고 있는데 다른
주문은 수백 개의 아이템을 가지고 있다면 클러스터가 적합하지 않을 것입니다.
키 값의 범위와 그분포
어떤 범위에 걸쳐 산재한 키 값은 클러스터 내의 많은 공간을 낭비할 것이므로 해쉬 키
구현에 적합하지 않습니다.
신중하게 설계된 해쉬 알고리즘이 이 문제를 극복할 수 있을지라고 이런 경우 적절한
해쉬 함수를 개발해 내는 것은 매우 어려울 것입니다.
테이블의 데이터에 대한 작업
클러스터를 구현할 대는 데이터를 어떤 방식으로 사용할 것인지 고려해 봐야만 합니다.
키 열 갱신 빈도
클러스터의 키 값이 갱신되면 행은 다른 블록으로 물리적으로 이동되어져야만 할 수 있습니다.
이 경우 성능 저하가 일어날 수 있습니다.
그러므로 자주 갱신되는 열은 블록 수를 줄여줄 수 있기 때문입니다.
어떠한 상황에서는 클러스터에 디테일 테이블만을 위치시키는 것이 유용합니다.
사원 정보가 항상 부서(department)에서만 접근되고 부서 테이블을 전체 테이블
스캔(full table scan)하는 경우가 잦은 경우라면 클러스터에 사원 테니블만을
위치시키십시오.
키 값의 수 산정
해쉬 클러스터에서는 해쉬 함수는 생성시 사용자에 의해 지정된 파라미터에 기초합니다.
데이터의 변동성때문에 키 값이나 그 크기를 정확히 예측하는 것이 어려워
HASHKEYS나 SIZE를 잘못 선택하면 오버플로우가 너무 많이 발생하거나 공간을
낭비하게 만드는 비효율적인 해쉬 함수를 낳을 수도 있습니다.
그러므로 해쉬는 SIZE와 HASHKEYS가 예측가능할 경웅만 유용합니다.
질의 조건
해쉬 함수는 키 값을 알때만 데이터를 읽어 들이는데 사용할 수 있습니다.
따라서 범위 검색(range search)은 해쉬 함수를 사용할 수 없습니다.
질의가 클러스터키에 동일한 조건을 갖고 있다면 해쉬 함수를 사용할 수 없습니다.
질의가 클러스터 키에 동일한 조건을 갖고 있다면 해쉬의 득을 볼 수 있습니다.
하지만 많은 질의가 해쉬 클러스터 키 열에 대해 범위 검색을 사용한다면
해쉬 클러스터에 인덱스를 생성할 수도 있습니다.
*****클러스터 정보*****
클러스터와 클러스터 키 열
SCOTT이 소유한 인덱스 클러스터의 이름과 클러스터 키 열을 알아내려면 다음 질의를
사용하십시오.
SVRMGR> SELECT c.cluster_name, c.cluster_type, c.key_size,
2> cc.column_name, cc.data_type,
3> decode(cc.data_type, 'NUMBER',
4> decode(cc.data_precision, NULL, NULL,
5> cc.data_precision || ',' || cc.data_scale),
6> 'DATA', NULL, cc.data_length) AS "COLSIZE"
7> FROM dba_clusters c, dba_tap_columns cc
8> WHERE c.owner = cc.owner
9> AND c.clusters_name = cc.owner
10> AND c.owner = 'SCOOT';
CLUSTER_NAME CLUSTER KEY_SIZE COLUMN_NAME DATA_TYPE COLSIZE
------------ ------- -------- ----------- --------- -------
OFF_CLU HASH 500 COUNTRY VARCHAR2 2
OFF_CLU HASH 500 COUNTRY VARCHAR2 8
OFF_CLU HASH 500 COUNTRY VARCHAR2 3, 0
3 rows selected.
클러스터 기 열과 테이블의 열 이치
클러스터, 클러스터의 테이블, 가가의 애등하는 열 이름 리스트를 보고 싶으면
DBA_CLU_COLUMNS를 질의 하십시오.
SVRMGR> SELECT *
2> FROM dba_clu_columns
3> WHERE owner = 'SCOTT'
4> ORDER BY cluster_name, table_name;
OWNER CLUSTER_NAME CLU_COLUMN_NA TABLE_NAME TAB_COLUMN_NA
----- ------------ ------------- ---------- --------------
SCOTT OFF_CLU COUNTRY DFFICE COUNTRY
SCOTT OFF_CLU POSTCODE DFFICE POSTCODE
SCOTT OFF_CLU ORD_NO ITEM ORD_NO
SCOTT OFF_CLU ORD_NO ORD ORD_NO
4rows selected.
해쉬 클러스터에 대한 추가 정보 얻기
사용된 해쉬 키의 수와 해쉬 함수의 유형을 알고 싶으면 다음 질의를 사용하십시오.
SVRMGR> SELECT c.cluster_name, c.hashkeys, c.funcion, h.hash_espression
2> FROM dba_clusters c, dba_cluster_hash_expression!s h
3> WHERE c.owner = h.owner(+)
4> AND c.cluster_name = h.cluster_name(+)
5> AND c.owner = 'SCOTT'
6> AND c.cluster_type = 'HASH'
CLUSTER_NAME HASHKETS FUNGTION HASH_EXPRESSION!
------------- ---------- ---------- -----------------
DFF_CLU 1009 DEFAULT2
1 row selected.
DBA_CLUSTERS의 해쉬 클러스터에 대한 FUNCTION 열은 다음 중 하나의 값을
가질 수 있습니다.
DEFAULT2 오라클 서버 내부 함수가 사용되는 경우
COLUMN 키 열 자체가 HACH IS절에 사용되는 경우
HASH_EXPRESSION! 사용자 정의 수식인 함수 해쉬에 대해
주
셋 이상의 데이터 딕셔너리 뷰를 조인해서 사용해야 한다면 뷰에 기초하여 임시
테이블을 정의한 후 조인에 그 테이블을 사용하는 것이 좋을 것입니다.
15-24
Index-Organized 테이블
스토리지 구조
Index-Organized 테이블은 모든 테이블 데이터를 B-트리 구조로 저장합니다.
테이블의 기본키(Primary Key)에 기초한 B-트리 인덱스는 인덱스처럼 조직되어
있습니다. (*)
이 구조의 leaf 블록은 인덱스 leaf엔트리의 두번째 구성요소에 ROWID대신
nonkey열(Key값)을 포함하고 있습니다. (*)
그러므로 Index-Organized테이블을 사용하면 테이블과 인덱스라는 별도의
두 세그먼트를 가질 필요가 없습니다.
Index-Organized 테이블 접근
정규 테이블에 인덱스 접근하려면 하나 이상의 인덱스 블록을 읽어 ROWID를 읽어
들이고 ROWID에 기초하여 테이블에 대한 I/O를 해야 합니다.
이와는 대조적으로 Index-Organized 테이블을 읽이려면 모든 행이 leaf 노드에
있으므로 인덱스 블록만 읽으면 됩니다.
* Index를 두면 안된다
Index-Organized 테이블은 기본 키나 기본키의 주요 부분을 구성하는 열의 조합을
사용하여 접근할 수 있습니다. (Primary Key 있어야 만들수 있다)
새 행 추가, 행 갱신, 또는 행 삭제 등의 테이블 데이터에 대한 변경은 인덱스만을
갱신할 뿐입니다. (*)
15-25. 정규 테이블과 비교한 Index-Organized 테이블
---------------------------------------------------------------------------------
정규 테이블 Index-Organized 테이블
---------------------------------------------------------------------------------
유일 식별자(identifier)-- ROWID 기본 키로 식별
암시적 ROWID ROWID 없음
여러 인덱스 지원 보조 인덱스 없음
FTS는 지정된 순서 없이 행 리턴 전체 인덱스 스캔(Full index scans)은
PK(기본키) 순서로 행 리턴
유일 제약 조건 허용 유일 제약 조건 허용하지 않음
분산(distribution) 복사(replication) 분산, 복사, 분할 지원하지 않음
분산(partitioning) 지원
---------------------------------------------------------------------------------
Index-Organized 이 정규 테이블과 같은 점은 다음과 같습니다.
. ROWID는 정규 테이블에서는 행을 고유하게 식별할 수 있습니다.
하지만 Index-Organized 테이블의 행은 기본 키로 식별할 수 있습니다.
. 정규 테이블은 인덱스 키 값에 대응하는 ROWID를 저장하는 많은 인덱스를
가질 수 있습니다. Index-Organized 테이블은 ROWID를 읽어 들이려는 시도를
하는 SQL문은 다음과 같은 에러를 받게 될 것입니다.
ORA-02031 : no ROWID for fixed tables or for index_organized tables
. 정규 테이블에 전체 테이블 스캔(full table scan)을 할 때 행이 리턴되는
순서는 예측할 수 없습니다.
Index-Organized 테이블에 대한 전체 스캔은 기본 키 순서로 행을 리턴합니다.
. Index-Organized 테이블은 유일 제약 조건을 제외한 모든 제약 조건을 지원합니다.
. Index-Organized 데이블은 분산 트랜잭션(distributed transaction)에 사용될 수
없으며 분할되거나 복사될 수도 없습니다.
15-26. Index-Organized 테이블 생성
CREATE TABLE scott.sales
( office_cd NUMBER(3),
qtr_end DATE,
revenue NUMBER(10,2),
review VARCHAR2(1000),
CONSTRAINT sales_pk
PRIMARY KEY(office_cd, qtr_end))
ORGANIZATION INDEX TABLESPACE data01
PCTTHRESHOLD 20
OVERFLOW TABLESPACE data02;
+Index-Organized테이블은 다음의 경우 유용합니다.(**중요**)
. 정보 검색 응용 프로그램
. 공간 응용 프로그램 (Spatial applications)
. 온라인 분석 처리(OLAP) 응용 프로그램
인덱스 조직은 기본 키를 사용하여 자주 접근되며 키가 아닌(nonkey) 열이
비교적 짧고 적은 테이블에 유용합니다.
구분
Index-Organized 테이블을 정의하려면 다음 명령을 사용하십시오.
CREATE TABLE [schema.] table
(column-definition [, cloumn-definition] ...
[, out-of-line-constraint [, out-of-line-constraint]...])
ORGANIZATION INDEX
[ PCTFREE integer]
[INITRANS integer]
[MAXTRANS integer]
[storage-clause]
[TABLESPACE tablespace]
[PCTTHRESHOLD integer
[INCLUDING column] ]
[OVERFLOW segment_attributes_clause]
구문에서 :
schema 클러스터의 소유자
table 테이블의 이름
ORGANIZATION INDEX Index-Organized 테이블로 지정
(*)PCTTHRESHOLD 인덱스 블록 내에 Index-Organized 테이블을 위해
예약된 공간의 백분율을 지정(행이 이 값에 기초
하여 게산된 크기를 초과하면 INCLUDING절에 지정된
열 이후의 열들은 모두 오버플로우 세그먼트로
이동됩니다. OVERFLOW가 지정되지 않으면
임계값(threshold)를 초과한 행들은
거부(reject)됩니다.
PCTTHRESHOLD 기본값은 50이며 이 값은 0에서
50사이에 들어야만 합니다.)
INCLUDING column Index-Organized 테이블 행을 인덱스와 오버플로우
구역으로 나눌 열을 지정 (이후의 열은 모두 오
버플로우 데이터세그먼트에 저장됩니다. 이것이
지정되지 않았는데 행 크기가 PCTTHRESHOLD를 초과
하면 기본 키 열을 제외한 모든 열이 오버플로우
구역으로 옮겨집니다. 이 열은 마지막 기본 키의
마지막 열의 이름이거나 기본 키가 아닌 열 입니다.)
OVERFLOW 지정된 임계값을 초과한 Index-Organized 테이블
데이터 행이 테이블스페이스, 스토리지와 블록 활
용 파라미터를 지정하는 segment_attributes_clause에
의해 지정된 데이터세그먼트내에 위치하도록
명시
제한사항
Index-Organized 테이블의 경우 기본 키를 반드시 지정해야 합니다.
기본 키 없이 Index-Organized 테이블을 생성하려 하면 다음과 같은
에러가 발생할 것입니다.
ORA-25175 : no PRIMARY KEY constraint found
PCTTHRESHOLD가 정의되고 오버플로우 세그먼트가 지정되지 않으면 임계값을
초과한 행은 다음과 같은 에러와 함께 거부됩니다.
ORA-01429 : Index-Organized Table : no data segment to store overflow
row-piece
15-29. 행 오버플로우
-------------------------------------------------------------------
IOT 테이블 스페이스 오버플로우 테이블 스페이스
-------------------------------------------------------------------
세그먼트 = PK Name 세그먼트 = SYS_IOT_OVER_n
유형 = Index 유형 = Table
-------------------------------------------------------------------
Index-Organized 테이블의 큰 행은 인덱스 내에 행이 높은 밀도로 저장되는
것을 방해할 수 있습니다. 이 문제는 오버플로우 구역을 사용하여 해결할
수 있습니다.
Index-Organized 테이블을 위해 생성되는 세그먼트
+Index-Organized 테이블이 생성될 때 OVERFLOW절을 지정하면 다음이 생성됩니다.
. CREATE TABLE절에 정의된 이름을 가진 "논리적" 테이블, 모든 행이 인덱스에
저장되므로 이 테이블에 대응되는 세그먼트는 없습니다.
. 지정된 스토리지와 공간 활용 파라미터를 사용하여 CREATE TABLE문에
정의된 테이블 스페이스 내에 기본 키 제약 조건과 같은 이름을 가진 인덱스
. 오버플로우 행 조각을 수용할 테이블, 이 테이블의 이름은
SYS_IOT_OVER_n입니다. 단, n은 DBA_OBJECTS에서 볼 수 있는
Index-Organized 테이블의 OBJECT_ID입니다.
Index-Organized 테이블에의 수행
+ Index-Organized테이블도 다른 테이블처럼 사용할 수 있습니다.
Index-Organized테이블에도 ALTER TABLE, ANALYZE TABLE,
TRUNCATE TABLE, 그리고 DROP TABLE 등의 명령어와 모든 DML명령어가
지원됩니다.
15-31.데이터 딕셔너리의 IOT 정보(*)
DBA_TABLES DBA_INDEXES
OWNER OWNER
TABLE_NAME TABLE_NAEM
IOT_TYPE INEDX_NAME
IOT_NAME INDEX_TYPE
TABLESPACE_NAME INCLUPDE_COLUMN
index-Oravized 테이블과 그 구조에 관련된 정보를 보려면 다음 질의를
사용하십시오.
svrmgrl>SELECT t.table_name AS "IOT", o.table_name AS "Overflow",
2>i.index_name AS "Inedex",
3>o.tablespace_name AS "Overflow TS"
4> o.tablespace_name AS "Index TS", I.pct_threshold
5>FROM dba_tables t,dab_tables o,dba_indexes I
6>WHERE t.owner=o.owner
7>AND t.table_nama=o.iot_name
8>AND t.owner=I.owner
9>AND t.table_name=I.table_name
10>AND T.OWNER='SCOTT';
IOT Overflow Index Overflow TS Index TS PCT_THRESHOLD
--- -------------- ------------- --------------- ---------- ---------------
SALES SYS_IOT_OVER_2049 SALES_PK DATA02 DATA01 20
요약
클러스터가 필요한 경우 파악
Index-Organized 테이믈 사용
요약참조
관련내용 Reference
초기화 파라미터 없음
동적 성능 뷰 없음
(*) 데이터 딕셔너리 뷰 DBA_CLUSTERS
DBA_TAB_COLUMNS
DBA_SLU_COLUMNS
DBA_CLUSTER_HASH_EXPRESSION!S
DBA_TABLES
DBA_INDEXES
명령어 CREATE CLUSTER
CTEATE INDEW..ON CLUSTER
CTEATE CLUSTER ..HASHKEYS..HASH IS
ALTER CLUSTER
CTEATE TABLE...ORGANIXATION INDEX
16장 데이터 로드와 재구성
목적
Direct-load 삽입 사용하여 데이터 로드
SOL*Loader의 conventional과 direct path방식을 사용하여 오라클 테이블로
데이터 로드
Export와 Import! 사용하여 데이터 재구성
오라클 데이버베이스의 테이블로 데이터를 로드하는 여러가지 방법에 대한
설명입니다.
로드하는 방법은 다음과 같습니다.
. Direct-loda삽입
. SQL*Loader
. Export와 Import! 유틸리티
Direct-Load삽입
Direct-load삽입은 데이터베이스 내의 한 테이블에서 다른 테이블로 데이터를
복사할때 사용할수 있습니다. 버퍼 캐쉬를 쓰지 않고 직접 데이터 파일에 데이터를
쓰기 때분에 삽입작업의 속도를 증가시켜줍니다.
SQL*Loader
SQL*Loader는 외부파일에서 오라클 테이블로 데이터를 로드할때 사용하는
유틸리티입니다.
다른 시스템으로 오라클로 이전(imgration)할때 사용할수 있습니다.
Export와 Import!유틸리티
Export유틸리티는 오라클 데이터베이스로부터 딕셔너리 정보와 데이터를 발췌하여
오라클 이진형식에 맞춰 운영 체제 파일로 옮길 수 있게 해줍니다. Export에 의해
만들어진 파일은 Import!유틸리티를 사용하여 오라클 데이터베이스나 다른
데이터베이스로 읽어 들여질 수 있습니다.
본 장에서는 Export와 Import!유틸리티가 가진 여러가지 사용법에 대해 다룰 것입니다.
16-6.Direct-Load 삽입 사용
INSERT /*+APPEND */ INTO scott.emp
NOLOGGING
SELECT * FROM scott.old_emp;
구문
Direct-load삽입은 아래 명령에서 처럼 APPLEND 힌트를 사용하여 실행될수 있습니다.
INSER /*+APPEN */ INTO [schema.]table
[ [NO]LOGGING]
sub-query;
구문에서;
schema 데이블의 소유자
table 데이블 이름
wub-query 삽입할 열과 행을 선택하는데 사용되는 서브쿼리
Direct-load삽입은 INSERT INTO SELECT명령이 사용되었을때에만 사용가능합니다.
이 옵션은INSERT INTO VALUES명령이 사용되었을 때는 사용할 수 없습니다.
Direct-load삽입은 분할되지 않는 테이블과 분활된 테이블 모두에 사용할 수 있으며
인덱스를 유지라고 모든 enable된 제약 조건을 적용합니다.
또한 다른 사용자가 동시에 테이블의 다른 행을 수정할수 있도록해줍니다.
Logging 모드
기본깂인 LOGGING 옵션을 사용하여 삽입하면 실패했을 경우 완전히 복구할 수
있도록 리두 로그 엔트리를 만듭니다.
NOLOGGING 옵션이 사용되면 데이터에 대한 변경 사항이 리두 로그 버퍼에
기록되지 않스빈다. 하지만, 이경우에도 익스텐트 할당 같은 작업의 경우에는
최소한의 로그 기록이 이루어집니다. 테이블에 대해 이 속성으로 설정되어 있으면
NOLOGGING 모드가 사용됩니다.
테이블의 데이터에 대한 온라인 수정이 여러 개 계속해서 발생할 것 같으면 로드하기
전에 NOLOGGING속성으로 설정하고 로드가 완료된 후 LOGGING으로 재설정할
것이 나을 수도 있습니다.
다른 고려 사항
Direct - load 삽입은 다른 트랜잭션이 동시에 테이블에 변경을 가할 수 있고록
허용합니다.
Direct - load 삽입을 사용하여 삽입된 데이터는 모두 high water mark 위로 로드됩니다.
만약 테이블이 행이 삭제된 블록을 가지고 있다면 공간이 낭비될 수 있으며 전체
테이블 스캔(full table scan)이 느려질 수 있습니다.
SQL*LOADER는 외부 파일로부터 오라클 데이터 베이스의 테이블로 데이터를 로드합니다.
SQL*LOADER의 특징
SQL*LOADER는 다음 특징을 갖습니다.
* 하나이상의 입력 파일이 사용될수 있습니다.
* 로드를 위해 여러개의 입력 레코드가 하나의 논리적인 레코드로 결합될 수 있습니다.
* 입력 필드는 고정된 길이를 가질 수도, 다양한 길이를 가질 수도 있습니다.
* 입력 데이터는 고정된 길이를 가질 수도, 다양한 길이를 가질 수도 있습니다.
* 입역 데이터는 문자, 이진, 팩 십진수(packed decimal), 날짜, 그리고
존 십진수(zoned decimal)등의 어떤 유형일 수도 있습니다.
* 데이터는 디스크나, 테이프, 또는 명몀된 파이프 등 여러 유형의 매개체로 부터
로드될 수 있습니다.
* 데이터는 한번에 여러 테이블로 로드 될수 있습니다.
* 테이블에 있는 기존 데이터를 대체하거나 추가하는데 사용 가능한 옵션이 있습니다.
* 행이 데이터 베이스에 저장되기 전에 SQL함수가 입력 데이터에 적용될 수 있습니다.
SQL*LOADER는 데이터를 로드하기 우한 두 가지 방법을 제공합니다.
* Conventional path
* Direct path
Conventional Path 로드.
Conventional path 로드는 삽입될 행의 배열을 구축하고 데이터를 로드하는데
SQL INSERT 문을 사용합니다. CONVENTONAL path로드 동안 필드 지정에 따라
입력 레코드가 구문 분석되고 레코드이 배열이 구축되어 콘트롤 파일에 지정된
테이블로 삽입됩니다. 필드 지정을 따르지 않는 레코드는 거부 (reject)되고 선택
조건을 충족시키지 않는 레코드는 버려집니다.( discard ).
Convential path 로드는 클러스터된 테이블과 클러스터되지 않은 테이블
모두로 데이터를 로드하는데 사용될 수 있습니다.리두 로그 생성 여부는
로드되고 있는 테이블의 로그 기록(logging)속성을 따릅니다.
DIRECT PATH 로드와 CONVEVTIONAL PATH 로드 비교.
conventional 로드 DIRECT PATH 로드
변경을 영구화하려면 data saves 사용
COMMIT사용
지정된 조건하에서만 리두 생성
리두 로그 엔트리가 항상
생성됨 기본 키와 유일, 그리고 NOT NULL인 제약 조건만 적용.
모든 제약 조건을 적용 INSERT 트리거 실행 안됨.
INSERT 트리거 실행 클러스터 된 테이블로 로드 불가
클러스트된 테이블로 로드가능 다른 사용자가 테이블에 변경을 가할 수 없음.
다른 사용자가 테이블에
변경을 가할 수 있음.
데이터 저장 방법
Convential path로드는 데이터를 저장하기 위해 SQL처리와 데이터 베이스 COMMIT를
사용합니다. 레코드 배열을 삽입한 후에는 커밋 작업이 뒤따릅니다. 각 데이터 로드는
여러 트랜잭션을 포함 할 수 있스빈다.
Direct path로드는 오라클 데이터 파일로 데이터 블록을 쓰기 위해 data saves를
사용합니다. 커밋과 data saves의 차이점은 다음과 같습니다.
* data saves동안에는 완전히 채워진 데이터 베이스 블록만이 데이터 베이스에
쓰여집니다.
* 테이블의 high water mark이후에 쓰여지고 data saves 이후에는 high water mark가
이동됩니다.
* data saves 후에는 내부 지원이 해재되지 않습니다.
* data saves마다 인덱스가 갱신되지 않습니다.
변경 사항의 기록
Conventiaonal path로드는 DML문처럼 리두 로그 엔트리를 생성합니다.
Direct path로드를 사용할 때, 다음과 같은 경우는 로드 리두 엔트리가 생성되지
않습니다.
* 데이터베이스가 NOARCHIVELOG모드일 때
* 데이터베이스가 ARCHIVELOG모드에 있더라도 로그 기록이 disable 되어 있을 때
(테이블의 NOLOG속성을 설정하거나 콘트롤 파일의 UNRECOVERABLE절을 사용하여
로그 기록을 disable할 수 있습니다.)
병렬direct로드를 사용하면 동시에 여러개의 direct로드 세션이 한 테이블로 데이터를
로드합니다.
작업 순서
각각의 병렬 로드 세션에 서로 다른 입력 데이터 파일을 사용하십시요. 여러 병렬
direct로드세션이 시작될 때 로드는 다음 단계를 따라 실행됩니다.
1 각 세션은 입력 데이터 파일로 부터 데이터를 로드하기 위해 임시 세그먼트를
사용합니다.
이들 임시 세그먼트는 로드되고 있는 테이블을 포함하는 테이블스페이스에 생성된다.
그 테이블수페이스가 여러 데이터 파일을 포함하고 있다면 사용자는 각 세션에 대해
임시 세그먼트가 생성될 파일을 지정할수 있습니다. 세그먼트에 대한 스토리지
파라미터는 사용자가 지정할 수도 있습니다. 디폴트로 이들 세그먼트는 로드되고
있는 테이블과 동일한 스토리지 속성을 사용합니다.
2 각 임시 세그먼트의 마지막 익스텐트는 세션이 종료될 때 사용되지 않은 공간을
해제하기 위해 잘려(trim)집니다.
Export사용
$exp scott/tiger table = (dept,emp)
file = emp.dmp log=exp.log compress=n
direct = y recordlength=32768
emp.dmp
DEPT, EMP ------- Export
exp.log
export는 다음중 한가지 방법으로 실행될수있다.
. 명령라인
. 대화식 모드
. 가능한 경우, 그래픽 인터페이스
대화식 모드는 기본적으로 기존의 것들과의 호환을 위해 제공되는 것이어서 명령
라인의 제공하는 모든 옵션을 제공하지 않습니다. 따라서 명령라인 모드를 사용할
것을 권장합니다
UNIX : 명령라인
유닉스 시스템상에서 익스포트를 수행하려면 다음 명령을 사용하십시요
$exp [keyword=] {value, value, ...)}
[ [ [ , ] keyword=] {value | (value, value,...)}]...
구문에서
keyword 다음절에서 설명되는 키워드 중의 하나
value 키워드에 지정되는 값
주
. 키워드를 명시하지 않으면 키워드에 지정하는 값을 올바른 순서대로 지정해야합니다.
일반적으로 키워드를 사용할 것을 권장합니다.
. 예에서 보듯이 처음 몇 값을 키워드 없이 저정한 후 다른값들은 키워드와 함께
지정할 수도 있습니다.
. 유닉스같은 일부 운영체제는 괄호 같은 특별한 문자 앞에 escape문자를 사용하여
그 문자가 특별한 문자로 다루어지지 않도록 합니다.
Windows NT : 명령라인
Windows NT에서 Export를 수행하려면 다음 명령을 사용하십시오.
c:\> exp80 [keyword=] {value, value, ...)}
[ [ [ , ] keyword=] {value | (value, value,...)}]...
명령 라인 파라미터
일반적으로사용되는 파라미터는 다음과 같습니다.
.USERID
오라클 사용자 이름과 암호(암호를 지정하지 않으면 사용자가 암호를 입력해야 합니다.)
.BUFFER
기본값(os지정)
익스포트 파일에 쓰여지기 전 인출된 행을 저장하는데 사용할 버퍼의 크기
.COMPRESS
기본값(y)
Y값은 임포트 될 때 초기 익스턴트 크기가 현재의 세그먼트 크기와 동일하게
설정되도록 지정.
N값은 현재의 익스턴트 크기를 사용하도록 합니다.
정보가 익스포트 파일에 쓰여지므로 익스포트시에 해야 합니다. LOB세그먼트는압축되지
않습니다.
.CONSISTENT
기본값(N)
Y값은 전체 익스포트 작업이 한번의 읽기 전용 트랜잭션으로 수행되도록 지정합니다.
익스포트는 익스포트되는 모든 오브젝트의 읽기 일관성 이미지를 얻으려 할 것입니다.
N값은 테이블 레벨 일관성만 유지될 필요가 있도록 지정합니다
.CONSTRINT
기본값(y)
Y값은 제약 조건이 테이블과 함께 익스포트 도도록 지정합니다.
N값은 제약조건이 익스포트 되지 않도록 합니다.
.DIRECT
기본값(N)
Y값은 익스포트할 때 direct path가 사용되도록 지정합니다.
N 값은 conventional path를 사용합니다.
.FEEDBACK
n행이 익스포트될 때 점(.)이 표시도도록 정수 n을 지정.
.FILE
기본값(exodat.dmp)
출력파일 이름
.FULL
기본값(N)
Y값은 저체 데이터베이스 익스포트지정
.GRANTS
기본값(y)
Y값은 익스포트되는 오브젝트의 모든부여가 임포트시 틀림없이 보존죄도록 지정
.HELP
기본값(N)
Y값은 파라미터와 그 의미를 출력합니다. 다른 파라미터와 같이 사용할 수 없습니다.
.INDEXES
기본값(y)
Y값은 인뎃스가 익스포트 되도록 합니다.
.LOG
기본값(Null)
모든 익스포트 메세지를 저장할 파일이름.
.OWNER
사용자 레벨 익스포트를 위한 사용자의 이름
.PARFILE
익스포트 파라미터의 리스트를 포함하고 있는 파일의 이름을 지정
.RECORDLENGTH
기본값(os지정)
출력 레코드의 크기
.ROWS
기본값(y)
Y값은 데이터가 익스포트되도록 지정
.STATISTICS
기본값(ESTIMATE)
임포트 시 사용될 분석 방법지정
.TABLES
테이블 모드 익스포트를 위한 schema.table
주
. FULL=Y 나 OWNER=user, 또는 TABLES = schema.table 파라미터는 같이 사용할 수
없습니다.
. direct path가 지정되면(DIRECT=Y)CONSYSTENT파리미터는 Y로 설정될수 없습니다.
. 모든파라미터가 설멸된 것으 아닙니다. 지세한 것은 Oracle8 Server Utilities
메뉴얼의 "Export"장을 참조하십시오.
16-39. IMPORT!
IMPORT!는 다음 중 한가지 방법으로 실행될 수 있습니다.
- 명령 라인
- 대화식 모드
- 가능한 경우 , 그래픽 인터페이스
대화식 모드는 기본적으로 기존의 것들과의 호환을 위해 제공되는 것이어서 명령
라인이 제공하는 모든 옵션을 제공하지 않습니다. 따라서 명령 라인 모드를 사용할
것을 권장합니다.
UNIX 시스템에서 IMPORT!를 수행하려면 다음 명령을 사용하십시오.
$imp [keyword =] {value | (value, value.....) }
[ [ [ , ] keyword= ] {value| (value, value . . .)}]...
keyword : 다음 절에서 다루어지는 키워드 중의 하나
value : 키워드에 지정되는 값
< window NT 명령라인 >
c:\ import! [ keyword=] {value|(value,value....)}
[ [ [ , ] keyword=] {value | {value,value ....)}] ...
OEM
1. data mmanagement를 사용하십시요.
2. data->import!를 선택하십시오.
3. data manager wizard의 introduction 페이지에 기계 이름과 경로를 포함한 파일
이름을 입력하십시오.
4. Data manager wizard의 object selection페이지에서 임포트될 관련 오브젝트를
선택하십시오.
5. associate object 페이지에서 인덱스와 행 같은 임포트될 관련 오브젝트와 생성
에러를 무시할 것인지의 여부를 지정하십시오.
6. wizard의 tuning과 advanced options페이지에서 다른 파라미터를 선택하십시오.
7. 3단계에서 원격 기계와 지연 처리를 지정했다면 scheduling 페이징서 스케쥴을
지정하십시오.
8. summary페이지에서 모드와 오브젝트를 확인하고 finish를 클릭하십시오.
9. 3단계에서 원격 기계를 선택했다면 다이얼로그 박스에서 대상을 지정하십시오.
<명령라인 파라미터>
일반적으로 사용되는 파라미터는 다음과 같습니다.
userid - 오라클 사용자 이름과 암호(암호를 지정하지 않으면 사용자가 암호를
입력해야 합니다.
buffer - 데이터 행이 통과할 버퍼의 크기로 바이트 단위(o/s지정-default)
commit - Y값은 각 배열이 삽입된 후 커밋 되도록 지정.
N값은 테이블에 행을 삽입한후 명시적으로 커밋하지 않고 다음 DDL명령이
import!에 의해 수행될 때 오라클 서버가 암시적으로 커밋을 수행합니다.
롤백 세그먼트가 과도하게 많아지는 것을 막으려면 commit = Y로 지정.
feedback - n행이 임포트될 때 점(.)이 출력되도록 정수 n을 지정
file - 입력파일 이름(expdat.dmp - default)
fromuser - 임포트되는 오브젝트의 소유자 리스트
full - Y값은 전체 데이터베이스 임포트 지정 (N-default)
grants - Y값은 임포트 되는 오브젝트에 대한 모든 부여(grant)도 틀림없이 임포드
되도록 지정 (Y-default)
help - Y값은 파라미터와 그의미를 출력. 다른 파라미터와 같이 사용할 수
없습니다.
ignore - default(N) Y로 설정되면 데이터베이스 오브젝트를 생성하려 할 때 발생하는
오브젝트 생성 에러를 무시해 줍니다. 임포트는 에러를 출력
하지 않고
계속됩니다. 테이블의 경우 ignore=Y이면 행이 기존 테이블로 임포트됩니다.
아무런 메시지도 나오지 않습니다.
ignore = N이면 레러가 출력되며 이미 존재하는 테이블은 건너 뜁니다.
오브젝트 생성 에러만 무시된다는 것을 명심하십시오. 운영체제, 데이터
베이스, 그리고 SQL 에러 등의 에러는 무시되지 않으며 처리를중단시킬
것입니다.
indexes - Y값은 인텍스가 임포트 되도록 합니다.
indexfile - 피일이 인덱스 생성 명령을 받는 파일을 지정합니다. 해당 모드의 인덱스
생성 명령은 데이터베이스에 인덱스를 생성하도록 사용되기보다는 지정된
파일에 쓰여집니다.
테이블과 다른 데이터베이스 오브젝트는 임포트ㅗ디지 않습니다.
파일은 편집될 수 있으며(예를 들어 스토리지 절을 변경) 인텍스를
생성하는 SQL스크립트로 사용될 수 있습니다.
log - 모든 임포트 메시지를 저장할 파일이름(null-default)
parfile - 임포트파라미터의 리스트를 가지고 있는 파일 이름을 지정합니다.
recordlength - 입력 레코드의크기, 데이터가 다를 레코드 크기를 가진 운영체제로
익스포트되었을 경우에만 필요합니다.(os지정-default)
rows - Y 값은 데이터가 임포트되도록 지정합니다.
show - Y 값이면 익스포트 파일의 내용은 출력되고 임포트되지 않습니다.
익스포트에 포함된 SQL문은 임포트가 실행할 순서로 출력됩니다.
show = Y 이면 fromuser, trouser, full 그리고 tables파라미터만이
설정될수 있습니다.
tables - 임포트될 테이블의 이름
touser - 테이블을 임포트할 사용자 이름의 리스트. IMP_FULL_DATABASE롤을 가진
사용자만이 이 파라미터를 사용하여 오브젝트를 다른 사용자의 계정으로
임포트할 수 있습니다.
<주>
- FULL = Y 나 OWNER=user 또는 TABLE=schema.table 파라미터는 같이 사용될 수 없다.
- IMP_FULL_DATABASE 롤은 "롤관리"장에서 다루어 집니다.
- 모든 파라미터가 설명된 것은 아닙니다.
16-43. 임포트 작업 방식
임포트순서
- 테이블 -> 데이터 -> B-트리 인덱스 -> 제약조건, 트리거,비트맵 인덱스
오브젝트에 사용되는 테이블스페이스
- 가능하다면 원본 데이터베이스에서와 같은 테이블 스페이스
-사용자의 디폴트 테이블스페이스
<임포트 순서>
테이블 오브젝트는 익스포트 파일에서 앍혀진 대로 임포트됩니다. 임포트
파일은 다음 순서로 오브젝트를 포함합니다.
1 테이블정의
2 테이블 데이터
3 테이블의 인덱스
4 무결성 제약조건, 트리거, 그리고 비트맵 인덱스
위 순서는 테이블이 임포트되는 순서 때문에 데이터가 거부당하는 것을
막아 주며 또한 동일한 데이터에 대해 과다한 트리거가 두번 씩 (처음 삽입될 때
한 번 그리고 임포트되는 동안 또 한번) 실행되는 것도 막아 줍니다.
하지만 프러시저 같은 오브젝트는 그들이 참조하는 오브젝트보다 빨리 임포트되기
때문에 임포트시 무효화 될수도 있습니다. status = invalid인 오브젝트를 검사하고
다시 컴파일 하십시오.
기존 테이블로 임포트 할때 고려사항
데이터가 기존 테이블로 임포트될때 임포트되는 순서가 참조 무결성 실패를 발생
시킬수 있습니다. 임포트가 끝날 때 테이블의 참조 무결성 제약 조건이 자기
자신을 참조 할 때도 비슷한 상황이 발생합니다.
앞에 언급되는 이유 때문에 기존 테이블로 임포트할 떄는 참조 제약 조건을 disable
하는 것이 좋습니다. 제약조건은 임포트가 완료된후 다시 enable할수 있습니다.
오브젝트에 사용되는 테이블스페이스
사용자가 필요한 할당량을 가지고 있다면 테이블은 익스포트되었던 것과 같은
테이블스페이스에 임포트됩니다. 하지만, 테이블스페이스가 더 이상 존재하지
않거나 사용자가 충분한 할당량을 가지고 있지 못하다면 임포트는 사용자의
디폴트 테이블스페이스에 테이블을 생성합니다. 기본 테이블스페이스에 접근
할수 없다면 테이블은 임포트될 수 없습니다.
lob세그먼트는 익스포트되었던 것과 같은 테이블 스페이스로만 임포트될수
있습니다. 따라서 테이블 소유자가 lob세그먼트가 익스포트된 테이블스페이스에
오브젝트를 생성할수 없다면 lob을 포함한 테이블은 생성되지 않았을 것입니다.
<주>
- lob을 포함하지 않은 테이블은 위의 임포트 작업 방식을 활용하여 한 테이블
스페이스로 부터 다른 테이블스페이스로 옯겨질 수 있습니다.
Export와 Import!의 사용에 대한 지침 사항
1) 공통적으로 사용하는 명령 라인 옵션은 파라미터 파일에 지정하십시오.
2) 작은 양의 데이터를 익스포트할 때에만 CONSISTENT = Y를 사용하십시오.
3) 삭제된 행이 많을때에는 COMPRESS = Y를 사용하지 마십시오.
4) 다음 방법으로 성능을 향상시키십시오.
- 크기가 큰 버퍼 할당
- 7.3.3 이상을 사용할때는 direct path 사용
파라미터 파일에 공통적으로 사용하는 라인 파라미터를 저장하십시오.
이렇게 함으로써 에러를 최소화하고 명령 라인을 짧게 유지할 수 있습니다.
익스포트되고 있는 테이블에 많은 갱신 작업이 이루어지는 경우 CONSISTENT = Y를
사용하면 SNAPSHOP TOO OLD 에러가 발생할 수 있습니다. 일반적으로 작업량이
적을 때 규모가 큰 익스포트를 수행하는 것이 좋습니다. 아니면 큰 롤백 세그먼트를
생성하고 다른 것들을 모두 오프라인으로 만든후 임포트를 수행하십시오.
익스포트 옵션 COMPRESS=Y는 현재 오브젝트에 할당된 익스텐트 전부의 크기와 같은
하나의 초기(initial) 익스텐트를 생성한는 코드를 만들어 낼 것입니다. 오브젝트가
삭제된 행을 많이 가지고 있거나 마지막 익스턴트가 사용되지 않은 블록을 많이
가지고 있으며 오브젝트에 불필요하게 많은 공간을 할당하게 될 것입니다.
기계상의 운영체제와 자원이 허락하는 한 최대한의 버퍼를 할당하십시오. 테이터가
오라클7 릴리스 7.3.3이상의 데이터베이스로 임포트될 경우 direct path익스포트를
사용하십시오.
Export 와 Character set변환
Conventional path익스포트는 사용자 세션에 지정된 character set을 사용하여 익스포트
파일에 씁니다. 예를 들자면, 7 비트 ASCII, 또는 IBM CODE page 5000(EBCDIC)등입니다.
Direct path익스포트는 데이터베이스 character set만으로 익스포트합니다. Export세션의
character set이 익스포트가 시작된 때의 데이터베이스 character set과 같지 않으며
익스포트는 경고를 출력하고 중지합니다. 익스포트를 재시도하기 전에 세션 character set을
데이터베이스 Character set과 같은 것으로 지정하고 익스포트를 재시도 하십시오.
익스포트 파일은 파일의 문자 데이터에 사용된 문자 암호화 계획(character encoding scheme)
을 보여주는 프래그를 가지고 있습니다.
Improt 와 Character set 변환
임포트 세션과 대상 데이터베이스 character set은 원본 데이터베이스 character set과
다를수 있습니다. 이런 경우 한번 또는 여러번 character set변환 작업이 필요합니다.
필요하다면 익스포트 파일 데이터는 우선 임포트 시 사용자 세션에 지정된 문자 암호화
계획으로 변환된 후 테이터베이스 character set으로 변환됩니다.
변환할때 대상 character set 에서 동일한 문자를 가지지 못한 익스포트 파일의 문자들은
대상 character set에 정의된 기본 문자로 대치됩니다. 100%변환을 보장하려면 대상
character set원본 character set을 포함하거나 같아야 합니다.
지침사항
Character set변환이 임포트에 걸리는 처리 시간을 길게 하기 때문에 character set 변환을
가능한 최소로 제한하십시오. 이상적인 것은 임포트 세션과 대상 데이터베이스
character set은 원본 character set과 같아 변환이 필요 없는 것입니다.
주
세션 레벨에서 character set을 설정하는 것과 다양한 데이터베이스 작업에의 character
set이 미치는 영향은 "국가별 언어 지원" 장에서 자세히 다루어 집니다.
요약
1) Direct-Load 삽입을 사용하여 테이블 복사
2) SQL*Loader를 사용하여 다른 응용프로그램으로부터 이전(migrate)
3) Export 와 Import! 유틸리티를 사용하여 데이터 재구성
요약참조
관련내용 : 참조
초기화 파라미터 : 없슴
동적 성능뷰 : 없슴
데이터 딕셔너리 뷰 : 없슴
명령어:UNIX, Window NT : sqlldr 또는 sqlload
Exp
Imp
EXP8.0EXE
IMP8.0EXE
SQLLDR80.EXE
패키지 프로시저와 함수 : 없슴
제 17 장 사용자 관리
17-3 목적
- 새 데이터 베이스 사용자 생성
- 기존 데이터베이스 사용자 수정, 삭제
- 기존 사용자에 대한 정보 모니터링
17-4 사용자와 보안
- 보안 도메인
; 데어터베이스 관리자는 데이터베이스에 접근할 수 있는 사용자의 이름을
정의합니다. 보안도메인은 사용자에 적용되는 설정을 정의합니다.
- 인증방법
; 데이터베이스에 접근하고자 하는 사용자는 다음 중 한 가지 방법으로
인증될 수 있습니다.
= 데이터베이스 인증(*) --> scott
= 운영체제 인증(*) --> level이 scott와 같은 user
= 네트워크 인증
; 인증 방법은 사용자가 데이터베이스에 정의될 때 지정되며 후에 수정
될 수 있습니다. 본 장은 데이터베이스와 운영체제에 의한 인증만을
다룹니다.
; 주
= 롤을 사용한 O/S 인증은 "오라클 인스턴스 관리"장을 참조하십시오.
= 네트워크를 통한 인증은 오라클8: Network administration과정에서
다루어 집니다.
- 테이블스페이스 할당량(**매우중요**)
; 테이블스페이스 할당량은 데이터베이스의 사용자에게 할당된 테이블스
페이스의 물리적 저장의 총량을 제어합니다.
- 디폴트 테이블스페이스
; 디폴트 세그먼트를 생성할 때 테이블스페이스를 명시적으로 지정하지
않은 경우 생성된 세그멘트가 저장될 위치를 정의합
니다.
- 임시 데이블스페이스
; 디스크에 정렬데이터를 써야할 작업을 수행하는 경우 오라클 서버에
의해 익스텐트가 할당될 곳을 정의합니다.
- 계정 잠금
; 계정은 사용자가 데이터베이스에 로그인하지 못하도록 잠겨질 수
있습니다. 자동적으로 잠기도록 할 수도 있고 데이터 베이스 관리자가
수동으로 잠그거나 풀 수도 있습니다.
- 자원제한
; CPU이용시간, 논리적I/O, 그리고 사용자가 오픈할 수 있는 세션의 수
같은 자원의 사용에 제한이 가해질 수 있습니다. 자원 제한은 "프로파일
관리"장에서 다루어집니다.
- 직접권한
; 권한은 사용자가 데이터베이스에서 수행할 수 있는 작업을 제어하는데
사용됩니다.
- 롤 권한
; 롤을 사용하여 간접적으로 권한으 부여 받을 수 있습니다. 직접 부여
받는 권한과 롤을 통해 부여 받눈 권한은 "권한 관리"장과 "롤 관리"
장에서 다루어 집니다.
본 장은 적절한 인증처리방식으로 사용자를 정의하는 것과 시스템 내에
사용자의 공간사용을 제한하는 것, 그리고 수동으로 계정 잠금을 제어
하는 것을 다룹니다.
17-6 데이터베이스 스키마 OBJECT
- 테이블
; 트리거
; 제약조건
- 인덱스
- 뷰 --> Segment라고 하지 않는다 (가짜 이기 때문에)
- 시퀀스 --> " "
- 저장 프로그램 유니트
- 동의어
- 사용자 정의 데이터 유형
- 데이터베이스 링크
=====> 위내용은 사용자가 오라클 데이터베이스 내에 소요할 수 있는 일부
오브젝트들을 보여줍니다.
* Session : Connect해서 나갈때까지
* 스키마 OBJECT
; 스키마는 테이블, 뷰, 클러스터, 프로시저, 그리고 패키지 같은 특정
사용자와 관련된 오브젝트의 명명된 모음입니다. 데이터베이스 사용
자가 생성될 때 동일한 이름을 가진 대응되는 스카마가 해당 사용자에
대해 생성됩니다. 사용자는 동일한 이름을 가진 스키마와만 관련될 수
있습니다. 그러므로 사용자 이름과 스키마는 종종 서로 바뀌어 스이기도
합니다.
17-7 사용자 생성시 점검 사항
- 사용자 이름과 인증 방식 선택
- 사용자가 오브젝트를 저장할 테이블스페이스 선택
- 각 테이블스페이스에 대한 할당량(Quota) 결정
- 디폴트 테이블스페이스와 임시 테이블스페이스 지정
- 사용자 생성
- 사용자에게 권한과 롤 부여
17-8 새로운 사용자 생성 : 서버 인증
- 초기 암호 설정
CREATE USER peter
IDENTIFIED BY my1stson
DEFAULT TABLESPACE data01
TEMPOPARY TABLESPACE temp
QUOTA 15m ON data01
PASSWORD EXPIRE;
- 구문
; 새로운 사용자를 생성하려면 다음 명령을 사용하십시오.
CREATE USER user
IDENTIFIED [BY password | EXTERNALLY]
[ DEFAULT TABLESPACE tablespace ]
[ TEMPORARY TABLESPACE tablespace ]
[ QUOT {integer [ K | M ] | UNLIMITIED } ON tablespace
[ QUOT {integer [ K | M ] | UNLIMITIED } ON tablespace ] . . . ]
[ PASSWORD EXPIRE ]
[ ACCOUNT { LOCK | UNLOCK} ]
[ PROFILE { profile | DEFAULT } ]
- 구문에서
user
= 사용자 이름
BY password
= 사용자가 데이터베이스에 의해 인증되도록 지저하며 로그온시
password를 입력해야 합니다.
EXTERNALLY
= 사용자가 운영체제에의해 인증되도록 지정합니다.
DEFAULT/TEMPORARY TABLESPACE
= 사용자에 대한 디폴트/ 임시 테이블스페이스 식별
QUOTA
= 테이블스페이스 tablespace네애 사용자가 소유한 오브젝트에 할당
되는 최대공간을 지정 (QUOTA는 정수 바이트나 킬로바이트, 또는
메가바이트로 정의될 수 있습니다. 사용자가 소유한 오브젝트가
테이블스페이스에서 사용 가능한 공간을 전부 사용할 수 있도록
지정하려면 키워드 UNLIMITED가 사용됩니다. 디폴트값으로는 사용
자는 어떠한 테이블스페이스에도 할당을 받지 못합니다. )
PASSWORD EXPIRE
= 사용자가 SQL*PLUS를 사용하여 데이터베이스에 로그인 할 때 암호를
재설정하도록 합니다. (사용자가 데이텁이스에 의해 인증될 경우
에만 적합한 옵션입니다.)
ACCOUNT LOCK/UNLOCK
= 사용자 계정을 명시적으로 잠그거나 풀 때 사용할 수 있습니다.
(UNLOCK이 기본값입니다. )
PROFILE
= 자원 사용을 제어하고 사용자에게 사용되는 암호 제어 처리 방식을
지정하는데 사용됩니다.
1) Password에 대한 복잡성을 요구하는 것을 제어
2) Resource대한 자원을 제한
주
프로파일은 "프로파일 관리"장에서 다루어 집니다.
암호 인증 방법은 의무입니다. 암호가 지정되면 오라클 서버에 의해
데이터 디셔너리 안에 유지됩니다. 오라클 서버가 제공하는 암호 제어
처리 방식은 사용자가 서버에 의해 인증될 때 사용됩니다.
암호 만료가 설종되면 사용자가 SQL*PLUS를 사용하여 로그인 할 때
다음과 같은 메시지를 받게 되면 새 암호를 입력해야 합니다.
ERROR :
ORA-28001 : the accout has expired
Changing password for PETER
Old password:
New password:
Retype new password:
password changed
사용자를 선택하고 User->Create Like를 선택하면 기존의 데이터
베이스 사용자와 똑같은 할당량과 권한을 가진 사용자를 생성할
수 도 있습니다.
17-11 새로운 생성자 생성; 운영 체제 인증
- OS_AUTHENT_PREFIX 사용
예; O/S 사용자 = user15
----------------------------------------------------------------------
OS_AUTHENT_PREFIX 데이터베이스 사용자 원격로그인 가능여부
----------------------------------------------------------------------
OS_ OS_USER15 불가
empty string " " USER15 불가
OPS$(기본값) OPS$USER15(기본값) 가능
; 트리거
----------------------------------------------------------------------
사용자가 운영체제에 의해 인증을 받아야만 하도록 지정하려면
CREATE USER 명령의 IDENTIFIED EXTERNALLY 절을 사용하십시요.
일반적으로 이 옵션은 사용자가 오라클서바가 수행되고 있는 기계에
직접 로그인할 때 유용합니다.
- 운영체제 인증을 위한 사용자 이름
; 초기화 파라미터 os_authent_prefix가 운영체제 인증을 위한 사용자
이름의형식을 지정하는데 사용됩니다. 기본값 OPS$은 오라클 서버의
초기 릴리스와의 호환을 위한 것입니다. 접두어를 NULL갑승로 설정
하려면 초가화 파라미터를 다음과 같이 지정하십시오:
OS_AUTHENT_PREFIX = ""
슬라이드의 예는 사용자 USER15가 어떻게 데이터베이스에 정의되는지
보여 줍니다. 이로써 운영체제 사용자 user15는 오라클 서버에 의한
어떠한 검증도 거치지않고 데이터베이스에 접근하도록 허용합니다.
따라서 UNIX사용자 user15가 SQL*PLUS를 사용하여 시스템에 로그인
하려면 그저 운영체제에서 다음 명령을 입력하기만 하면 됩니다.
$ sqlplus /
주
= OS_AUTHENT_PREFIX=OPS$로 사용하면 사용자가 운영체제나 오라클 중
아무것에 의해서든 인증될 수 있도록 통용성을 제공해 줍니다. 이
경우 DBA는 다음 형식의 명령을 입력하여 사용자를 생성할 수 있습니다.
CREATE USER ops$user
IDENTIFIED BY password...
오라클 서버가 수행되고 있는 기게에 로그인하는 사용자는 암호를 입력
할 필요가 없습니
다. 사용자가 원격 클라이언트에서 접속할 경우 사용
자는 암호를 입력하여 접속할 수 있습니다.
= 다른 초기화 파라미터 설정:
REMOTE_OS_AUTHENT = TRUE 는 사용자가 원격 운영체제에 의해 인증될
수 있도록 지정합니다. 디폴트 값인 FALSE는 사용자가오라클 서버가
수행되고 있는 기계에 의해서만 인증될 수 있도록 지정합니다. 보안에
잠재적 문제가 있을 수 있으므로 이 파라미터는 주의 깊게 사용하십니오.
= 데이터베이스 내에 운영 체제에 의해 인증된 사용자가 있을 경우 OS_
AUTHENT_PREFIX를 변경하면 이들 사용자들이 데이터베이스에 로그인
하지 못할 수 있습니다.
* 새로운 사용자 생성 : 지침사항 *
- 초기에는 표준 암호를 선택하고 O/S인증은 되도록 삼가하십시오.
- 사용자가 암호를 재설정하도록 하려면 EXPIRE키워드를 사용하십시요.
* EXPIRE : Password 재설정시 사용
- 항상 임시 테이블 스페이스를 할당하십시오.
- 소수 사용자에게로 할당량을 제한하십시오. QUPTA UNLIMITED는 주의깊게
사용하십시오.
- 사용자에게 다음을 교육 시키십시오. (접속하는법, 암호 변경하는법)
* 계정 잠금과 암호 제어 *
ALTER USER명령을 사용하여 암호를 변경하고 계정을 잠글 수 있습니다.
이와같은 작업이 필요한 경우는 다음과 같습니다.
- 사용자가 암호를 잃어버려서 암호를 재설정하고자 할때
- 시스템에 의해 잠겨진 사용자 계정을 풀때
- 계정을 명시적으로 잠글때
- 수동으로 암호를 만료되게 할때, 사용자 암호를 재설정 할 때 유용합니다.
구문
위의 상황에서 다음 명령을 사용하십시오.
ALTER USER user
[IDENTIFIED {BY password | EXTERNALLY}]
[PASSWORD EXPIRE]
[ACCOUNT {LOCK | UNLOCK}];
사용자가 로그인한 상태라면 암호변경, 만료, 잠금은 현재의 셰션에는 영향을
주지 않습니다. 다음셰션에만 유효할 것입니다.
사용자 계정이 잠겨져 있는데 접속하려 하면 다음 메시지가 출력됩니다.
ERROR:
ORA-18000: the account is locked
Warning: You are no longer connected to ORACLE.
*테이블 스페이스에 대한 사용자 할당량 변경*(**중요**)
다음과 같은 상황의 경우 테이블 스페이스 할당량을 수정해야 할지도 모릅니다.
- 사용자가 소유한 테이블이 예기치 못하게 커질때
- 응용프로그램이 향상되어 추가 테이블이나 인덱스를 요구할때
- 오브젝트가 재구성되어 다른 테이블 스페이스에 위치하게 될때
구문
테이블스페이스 할당량을 수정하거나 테이블 스페이스를 재지정하려면 다음명령을
사용하십시오.
ALTER USER user
[DEFAULT TABLESPACE tablespace]
[TEMPORARY TABLESPACE tablespace]
[QUOTA {integer [K | M] | UNLIMITED} ON tablespace
[QUOTA {integer [K | M] | unlimited} on tablespace] ...]
일단 할당량이 0으로 할당되면 사용자가 소유한 오브젝트는 할당이 취소된 테이블
스페이스에 남아있지만 새공간을 할당받지 못합니다.
예를들어 10MB인 테이블이 테이블스페이스data01에 있는데 테이블스페이스
data01할당량이 0으로 변경되면 그 테이블에는 더이상의 새로운 익스텐트가 할당될
수 없습니다.
변경되지 않은 옵션은 그대로 남아있게 됩니다.
*사용자 삭제*
구문
DROP USER user [CASCADE]
지침사항
- CASCADE옵션은 사용자를 삭제하기 전에 스키마의 모든 오브젝트를 삭제합니다.
스키마가 오브젝트를 포함하고 있는경우 반드시 지정되어야 합니다.
- 현재 오라클 서버에 접속하고 있는 사용자는 삭제할 수 없습니다.
*사용자 모니터링*
테이블스페이스 할당량
사용자SCOTT에 주어진 테이블스페이스 할당량을 확인해 보려면 다음의 질의를
사용하십시오.
SVRMGR> SELECT tablespace_name, blocks, max_blocks, bytes, max_bytes
2>FROM dba_ts_quotas
3>WHERE username = 'SCOTT';
TABLESPACE_NAME BLOCKS MAX_BLOCKS BYTES MAX_BYTES
--------------------- --------- ------------ -------- -------------
DATA01 10 -1 20480 -1
1 row selected.
MAX_BLOCKS 나 MAX_BYTES열의 값이 -1인 것은 사용자가 테이블스페이스의 할당량에
제한이 없다는 것을 의미합니다.(UNLIMITED설정)
사용자 계정상태
다음 질의는 모든사용자, 그들의 계정상태, 그리고 임시 테이블스페이스를 보여줍니다.
SVRMGR> SELECT username, account_status, temporary_tablespace
2> FROM DBA_USERS;
USERNAME ACCOUNT_STATUS TEMPORARY_TABLESPACE
------------------ --------------------- ------------------------
SYS OPEN TEMP
SYSTEM OPEN TEMP
DBSNMP OPEN TEMP
SCOTT OPEN TEMP
4 rows selected.
*요약*
- 적절한 암호처리 방식을 지정하여 사용자 생성
- 사용자의 공간 사용 제어
요약 참조
---------------------------+------------------------------------
관련 내용 | 참 조
---------------------------|------------------------------------
초기화 파라메터 | OS_AUTHENT_PREPIX
| REMOTE_OSOS_AUTHENT
---------------------------|------------------------------------
데이터 딕셔너리 뷰 | DBA_USERS
| DBA_TS_QUOTAS
---------------------------|------------------------------------
명령어 | CREATE USER
| ALTER USER
| DROP USER
---------------------------+------------------------------------
제18장 프로파일 관리(**중요)
목적
.프로파일을 생성하여 사용자에게 지정
.프로파일로 자원 사용제어
.프로파일의 수정과 삭제
.프로파일을 사용하여 암호관리
.프로파일, 할당 한계, 그리고 암호에 대한 정보 얻기
프로파일
.자원과 암호 제한의 집합이며 이름을 지정합니다.
.CREATE/ALTER USER명령에서 사용자에게 지정됩니다.
.ENABLE되거나 DISABLE될 수 있습니다.
.DEFAULT 프로파일과 관련이 있을수 있습니다.
.세션, 또는 콜(CALL)레벨로 시스템 자원을 제한할 수 있습니다.
프로파일은 다음과 같은 시스템 자원과 암호 제한의 집합에 이름을 지정한 것입니다.
.CPU 이용시간
.I/O작업
.휴지시간(IDLE TIME)
.접속시간(CONNECT TIME)
.메모리공간(MTS의 경우에서 프라이 비크SQL영역)
.동시세션
.암호 AGING과 기간 만료
.암호 이력
.암호 복잡성 검증
.계정 잠금
프로파일이 생성된 후 데이터베이스 관리자는 프로파일을 각 사용자에게 지정할 수
있습니다.
자원 제한이 ENABLE되어 있으면 오라클 서버는 데이터베이스 사용과 자원을 각 사
용자에게 지정된 프로파일에 따라 제한합니다.
DEFAULT프로파일
오라클 서버는 데이터베이스가 생성될때 자동적으로 DEFAULT프로파일을 생성합니다.
명시적으로 특정 프로파일을 지정받지 못한 사용자는 DEFAULT 프로파일의 모든 제
한을 따르게 됩니다.
DEFAULT프로파일의 모든 제한은 처음에는 무제한으로 되어 있습니다. 하지만 데이터
베이스 관리자가 그 값을 변경하여 변경된 값이 모든 사용자에게 기본으로 적용될
수 있도록 할 수 있습니다.
콜(CALL)과 세션 레벨 제한
프로파일 제한은 세션레벨이나 콜레벨, 또는 양쪽 모두에서 시행될 수 있습니다.
세션레벨 제한은 각 접속마다 시행됩니다.
세션레벨제한이 초과되면
.예를 들어 다음과 같은 에러메시지가 리턴됩니다.
ORA-02391: exceed simultaneous SESSIONS_PER_USER limit
.오라클 서버가 사용자의 접속을 차단합니다.
콜 레벨 제한은 sql문을 수행할 때 만들어진 각 콜마다 시행됩니다.
콜레벨 제한이 초과되면:
.명령문의 처리가 중지됩니다.
.명령문이 롤백됩니다.
.이미 수행된 명령문은 유효하게 남아 있습니다.
.사용자의 세션은 연결된 채로 남아 있습니다.
프로파일 사용
.사용자가 과중한 자원 사용을 요하는 작업을 수행하는 것을 제한 합니다.
.사용자가 자신의 세션을 일정 시간 동안 휴지상태로 둘 때은 데이터베이스를 로그
아웃시키도록 합니다.
.비슷한 사용자들에게 그룹차원의 자원 제한을 가능하게 합니다.
.사용자에게 자원 제한을 쉽게 할당합니다.
.크고 복잡하며 많은 사용자가 사용하는 데이터베이스 시스템에서 자원 사용을 관리
합니다.
.암호 사용을 제어합니다.
프로파일로 자원관리
1.프로파일 생성
2.사용자에게 프로파일 지정
3.자원제한 enable
프로파일로 자원사용을 제어하려면 다음 단계를 따르십시오(**중요**)
1. CREATE PORFILE명령으로 프로파일을 생성하고 자원과 암호제한을 결정하십시오.
2. CREATE USER또는 ALTER USER 명령으로 프로파일을 지정하십시오.
3. ALTER SYSTEM 명령을 사용하거나, 또는 초기화 파라미터 파일을 편집하여 자원
제한을 시행하십시오.
(그리고 인스턴스를 중지한 후 재시작하십시오)
주 의:오라클 암호 관리를 enable하기 우해 자원 제힌을 시행할 필요는 없습니다.
프로파일 생성: 자원제한
CREATE PROFILE developer_prof LIMIT
sessions_per_user 2 --> 접속할수 있는 사람수
CPU_PER_SESSION 10000 --> CPU 사용시간(1/100초)
IDLE_TIME 60 --> connect time 내에 있는 시간(분)
CONNECT_TIME 480; --> (분)
다음의 CREATE PROFILE 명령을 사용하여 프로파일을 생성하십시오.
CREATE PROFILE profile LIMIT
[SESSIONS_PER_USER max_value]
[CPU_PER_SESSION max_value]
[CPU_PER_CALL max_value]
[CONNTECT_TIME max_value]
[IDLE_TIME max_value]
[LOGICAL_READS_PER_SESSION max_value]
[LOGICAL_READS_PER_CALL max_value]
[COMPOSITE_LIMIT max_value]
[PRIVATE_SGA max_value]
max_value :== {integer | UNLIMITED |DEFAULT}
max_value :== {integer [ K | M] | UNLIMITIED | DEFAULT}
구문에서:
PROFILE 프로파일 이름
DEFAULT 지정받은 사용자는 해당 자원을 무제한으로 사용할 수 있다는
것을 나타냅니다.
COMPOSITE_LIMIT 서비스 단위(service unit)로 나타낸, 세션 당 총 자원 소비의
제한합니다.
(*)오라클은 다음에 대한 가중치 함으로써 총 자원 소비를 계산합니다.
CPU_PER_SESSION
CONNECT_TIME
LOGICAL_READS_PER_SESSION
PRIVATE_SGA
주
데이터 딕셔너리 뷰 RESORCE_COST는 여러 가지 자원에 대한 가중치를 제공합니다.
ALTER RESOURCE COST 명령을 보십시오.
세션 레벨의 자원 제한 설정
자원 설명
CPU_PER_SESSION 1/100초 단위로 측정한 총 CPU 이용시간
SESSIONS_PER_USER 각 사용자마다 허용된 동시세션의 수
CONNECT_TIME 분 단위로 측정한, 경과된 접속 시간
IDLE_TIME 분 단위로 측정한 비활동 시간
LOGICAL_READS_PER_SESSION 데이터 블록 수 (물리적,논리적으로 읽은)
PRIVATE_SGA 바이트 단위로 측정한 SGA내의 전용(PRIVATE)공간(MTS만)
콜레벨의 자원 제한 설정
자원 설명
CPU_PER_CALL 1/100초 단위로 나타낸 콜 당 CPU이용시간
LOGICAL_READS_PER_CALL 데이터 블록 수
지침사항
. 서버 프로세스에 대해서만 IDLE_TIME이 계산됩니다. 응용프로그램 작업은 포함되지
않습니다.
IDLE_TIME은 오랜시간 수행되는 질의나 다른 작업들은 포함하지 않습니다.
. LOGICAL_READS_PER_SESSION은 메모리와 디스크 모두에게서 읽는 총 횟수를 제한합니다.
이것을 쓰는 이유는 I/O집중명령문이 메모리와 디스크를 독차지하지 못하도록 하기
위해서입니다.
. PRIVATE_SGA는 다중 스레드 서버(MTS)구성 일때만 적용되며 M, 또는 K로 지정될 수
있습니다.
주
MTS구조는 Oracle8: Network Administration 과정에서 다루어집니다.
18-11 사용자에게 프로파일 지정
CREATE USER user3 IDENTIFIED BY user 3
DEFAULT TABLESPACE data01
TEMPORARY TABLESPACE temp
QUOTA unlimited ON data01
PROFILE developer_prof;
ALTER USER scott
PROFILE developer_prof;
프로파일 지정
CREATE USER 명령이나 ALTER USER 명령으로 프로파일을 지정할 수 있습니다.
각 사용자는 한번에 하나의 프로파일만을 지정받을 수 있습니다.(*)
프로파일 특성
- 프로파일 지정이 현재의 세션에는 영향을 주지 않습니다.
- 프로파일은 롤이나 다른 프로파일에는 지정할 수 없고 사용자에게만 지정
할 수 있습니다.
- 사용자를 생성할 때 프로파일을 지정하지 않으면 자동적으로 DEFAULT 프로
파일을 지정받게 됩니다.
18-13 자원 제한 Enable
- 초기화 파라미터 RESOURCE_LIMIT를 TRUE설정 또는 ALER SYSTEM 명령으로
파라미터를 enable하여 자원 제한 시행(DB를 Shutdown 시킬수 있을때)
ALTER SYSTEM SET RESOURCE_LIMIT = TRUE;
- RESOURCE_LIMIT 초기화 파라미터를 수정하거나 ALTER SYSTEM명령을 사용하여
자원 제한 시행을 enable하거나 disable합니다.(DB를 내릴수 없을때)
RESOURCE_LIMIT초기화 파라미터
- 자원 제한 시행을 enable하거나 disable하려면 초기화 파일에 들어있는
RESOURCE_LIMIT파라미터를 수정한 후 인스턴스를 재시작하십시오.
- TRUE값은 시행을 enable합니다.
- FALSE값은 시행을 disable합니다. (기본값)
- 데이터 베이스를 종료할 수 있을 때 사용하십시오.
ALTER SYSTEM명령
- 인스턴스에 대해 자원 제한 시행을 enable하거나 disable하려면 ALTERSYSTEM
명령을 사용하십시오.
- ALTER SYSTEM을 사용하여 지정된 설정은 또다시 수정되거나 테이터 베이스가
종료될 때까지 유효하게 남아 있습니다.
- 데이터 베이스를 종료할 수 없을 때 사용하십시오.
18-14 프로파일 수정
ALTER PROFILE default LIMIT
SESSIONS_PER_USER 5
CPU_PER_CALL 3600
IDLE_TIME 30;
프로파일 수정
프로파일에 지정된 자원제한을 변경하려면 ALTER PROFILE명령을 사용하십시오.
ALTER PROFILE profile LIMIT
[SESSION_PER_USER max_value]
[CPU_PER_SESSION max_value]
[CPU_PER_CALL max_value]
[CONNECT_TIME max_value]
[IDLE_TIME max_value]
[LOGICAL_READS_PER_SESSION max_value]
[LOGICAL_READS_PER_CALL max_value]
[COMPOSITE_LIMIT max_value]
[PRIVATE_SGA max_value]
지침 사항
- 프로파일을 변경한 것은 현재의 세션에 영향을 주지는 않습니다. 변경 사항은
그 이후의 세션에서만 적용됩니다.
- CONNECT_TIME,LOGICAL_READS_PER_SESSION, 그리고
LOGICAL_READS_PER_CALL에 대한 현재까지의 기록 정보를 보려면
AUDIT SESSION 옵션을 사용하십시오.("감사(Auditing)"장을 참조하십시오.)
18-16 프로파일 삭제
DROP PROFILE developer_PROF;
DROP PROFILE developer_PROF
CASCADE;
프로파일 삭제
DROP PROFILE 명령을 사용하여 프로파일을 삭제하십시오.
DROP PORFILEprofile [CASCADE]
구문에서:
profile 삭제할 프로파일 이름
CASCADE 삭제할 프로파일이 지정된 사용자로부터 프로파일을 무효화
합니다. (오라클 서버는 이런 사용자에게 자동적으로 DEFAULT
프로파일을 지정합니다. 현재 사용자에게 지정되어 있는
프로파일을 삭제하려면 이 옵션을 지정하십시오
지침 사항
- DEFAULT프로파일은 삭제할 수 없습니다.
- 프로파일이 삭제되는 경우, 이러한 변경은 이후에 생성되는 세션에만 적용되고
현재의 세션에는 적용되지 않습니다.
18-19
사용자 SCOTT에 대한 자원 재한을 보려면 데이터 딕션어리 뷰 DBA_USERS와
DBA_PROFILES를 조인하십시오.
SVRMGRL1 >SELECT p.profile,p.resource_name,p.limitt
2>FROM dba_uses u,dba_profiles p
3>WHERE p.profile=u.profile AND username='SCOTT' AND
4>p.resource_type='KERNEL'
PROFILE RESORCE_NAME LIMIT
------------------ ----------------------------------------------
DEVELOPER_PROF COMPOSITE_LIMIT DEFAULT
DEVELOPER_PROF SESSIONS_PER_USER 2
DEVELOPER_PROF CPU_PER_SESSION 10000
DEVELOPER_PROF CPU_PER_CALL DEFAULT
DEVLEOPER_PROF LOGICAL_READW_PER_SESSION DEFAULT
DEVLEOPER_PROF LOGICAL_READS_PER_CALL DEFAULT
DEVLEOPER_PROF IDLE_TIME 60
DEVLEOPER_PROF CONNECT_TIME 480
DEVLEOPER_PROF PRIVATE_SGA DEFAULT
9 rows selected.
18-20 암호 관리
더 나은 데이테 베이스 보안을 위해 데이터베이스 관리자는 오라클 암호
관리를 제어합니다
다음 절은 사용 가능한 암호 광리 기능을 설명합니다
* 계정 잠금: 사용자가 지정된 시도 횟수내에 시스템에 로그인하지 못했들
경우 자동으로 계정을 잠그도록 합니다.('사용자 관리 ' 장에서 서용자의
명시적 잠금은 이미 소개했습니다.)
* 암호의 aging 과 기간 만료:암호가 수명을 갖도록 하여 그 기간 니 지나면
변경해다만 하도록 합니다
* 암호위 현재까지의 기옥: 암호를 검사하여 지정된 시간 동안이나 지정된
횟수이상 사용되지 않도록 합니다
* 암호의 복잡성 검증 : 암호를 추축하여 시스템에 적당치 암ㅎ게 들어오려
하면 침입자를 막기에 암호가 18-20. 암호관리충분히 복잡한지를
검증합니다
18-21 암호관리 enable
*프로파일을 사용자에게 지정하여 암호 관리를 설정하십시오
*CREATE USER, 또는 ALTER USER 명령을 사용하여 계정을 잠그거나
잠금을 해제하고 기간 만료시키십시오
*인스턴스의 RESOURCE_LIMIT가 FALSE로 설정되어 있더라도 암호
제한은 항상 시행됩니다
자원제한 설정돠 비슷하게 CREATE나 ALTER USER 명령을 사용하여
설정을 제한하도롯 프로파일을 생성하여 서용자에게 지정할수 있습니다.
SESSION_PER_USER같은 다른 제한들은 초기화 파라미터나 ALTER
SYSTEM 명령으로 자원 제한이 enable되어 있을 때에만 시행되느
반면 ,프로파일의 암호 설정은 항상 시행됩니다
암호관리가 enable 되면 사용자 계정은 CREATE USER나 ALTER USER
명령을 사용하여 잠그거나 잠금을 해제할수 있습니다.
18-22 프로파일 생성:암호 설정
CREATE PROFILE GRACE_5 LIMIT
FAILED_LOGIN_ATTEMPS 3 --> 접속시 3번까지 시도 가능
PASSWORD_LIFE_TIME 30 --> Password를 30일만 사용
PASSWORD_REUSE_TIME 30
PASSWORD_VERIFY_FUNCTION verify_function
PASSWORD_GRACE_TIME 5; --> Password에 대한 경고를 5일전에 알림
암호를 관리하려면 CREATE PROFILE 명령을 사용하십시오
CREATE PROFILE profile LIMIT
[FAILED_LOGIN_ATTEMPTS max_value]
[PASSWORD_LIFE_TIME max_value]
[ {PASSWORD_REUSE_TIME
| PASSWORD_REUSE_MAX} max_value]
[ACCOUNT_LOCKC-TIME max_value]
[PASSWORD_GRACE_TIME max_value]
[PASSWORD_VERIFT_FUNCTION
{function | NULL | DEFAULT} ]
18-23 암호 설정
파라미터 설명
FAILED_LOGIN_ATTEMPTS 계정을 잠그기 전까지 로그인 시도하다
실패한 횟수
PASSWORD_LOKE_TIME 암호가 기간 만료되어 계정이 잠겨진 채로
남아 있었던 날수
PASSWORD_LIFR_TIME 날 수로 표시한 암호의 수명으로 이 기간이
지나면 기간 만료됨
PASSWORD_GRACE_TIME 암호가 기간동암 만료된 후 첫번빼 성공적인
로그인부터 암호변경 할때가지의 유예 기간
암호 설정
파라미터 설명
PASSWORD_REUSE_TIME 암호가 재사용될수 있게 될 때까지의 날수
PASSWORD_REUSE_MAX 암호가 재사용될 수 있는 최대 횟수
(*)PASSWORD_VERIFY_FUNCTION 암호를 할당하기 전 복잡성 검사를 수행할
PL/SQL 함수
18-24 * 계정 잠금
오라클 서버는 FAILE_LOGIN_ATTEMPTS 값에 도달하면 자동적으로 계정을 잠금니다.
계정은 지정된 시간(PASSWORD_LOCK_TIME)이 지난 후 자동적으로 잠금이 해제됩니다.
데이타 베이스 관리자가 ALTER USER명령으로 잠금을 해제해야 합니다.
데이터 베이스 계정은 ALTER USER 명령을 사용하여 명시적으로 잠글 수도 있습니다.
이렇게 하면 계정은 자동적으로 잠금 해제되지 않습니다.
* 암호 Aging 과 기간 만료
PASSWORD_LIFE_TIME 파라미터는 수명을 설정합니다. 이 기간이 지나면 암호를 변경
해야 합니다.
데이터 베이스 관리자는 유예기간(PASSWORD_GRACE)를 지정할 수 있습니다. 이 기간
은 암호가 기간 만료된 후 데이타베이스에 처음 접속한 때부터 시작됩니다. 유예
기간이 긑날 때 까지는 사용자가 매번 접속하려 할 대마다 경고 메시지가 발생됩니다.
사용자는 유예 기간내에 암호를 변경해야 함니다
암호가 변경되지 않으면 계정은 잠가집니다.
암호를 기간 만료된 것으로 명시적으로 설정하면 사용자의 계정상태는 EXPIRED로
변경 됩니다. 이렇게 되면, 사용자가 로그인 할 때 계정은 유예기간으로 넘어갑니다
예를 들자면, 새로운 계정을 생성할때 유용합니다
* 암호의 현재까지의 기록
암호의 현재까지의 기록은 사용자가 지정된 기간동안 암호를 재사용하지 못하게 합니다
이것은 다음중 한 가지 방법으로 구현할 수 있습니다.
. PASSWORD_REUSE_TIME : 주어진 날수 동안 암호를 재사용 할 수 없도록 지정
. PASSWORD_REUSE_MAX : 예전에 사용한 암호와 동일한 것을 사용하지 못하도록 시행
이들 파라미터 중 하나가 DEFAULT 나 UNLIMITED 가 아닌 다른 값으로 설정되면 나머지
파라미터는 UNLIMITED로 설정되어야만 합니다.
18-25 * 사용자 정의 암호 함수
함수는 반드시 SYS 스키마에서 생성되어야 하며 다음 사양을 따라야 합니다
function_name(
userid_parameter IN VARCHAR2(30),
password_parameter IN VARCHAR2(30),
old_password_parameter IN VARCHAR2(30))
RETURN BOOLEAN
새로운 암호 검증 함수를 추가할 때 데이타 베이스 관리자는 다음 제한 사항을
고려해야만 합니다
. 프로시져는 슬라이드에 보여진 형식에 따라야 합니다.
. 프로시져는 성공시 TRUE 값을 실패했을 시 FALUSE 값을 리턴 합니다.
. 암호 함수에 예외가 생기면 에러가 리턴되고 ALTER USER 또는 CREATE USER 명령은
종료됩니다.
. 암호 함수는 SYS가 소유합니다.
. 암호 함수가 부적절 하게 되면 에러 메시지가 리턴되고, ALTER USER 또는 CREATE
USER 명령은 종료됩니다.
18-26 * 암호 검증 함수 VERIFY_FUNCTION
. 암호의 최소 길이는 네문자 입니다.
. 암호는 사용자 이름과 같아서는 안됩니다
. 암호는 최소한 하나의 알파벳, 하나의 숫자, 그리고 하나의 특수문자를
가져야 합니다.
. 암호는 에전에 사용했던 암호와 최소한 세 문자는 달라야 합니다.
오라클은 복잡성 검증 함수를 제공합니다 utlpwdmg.sql 스크립트에 의해
VERIFY_FUNCTION 이라는 디폴트 PL/SQL 함수 형태로 제공되며 반드시 SYS스키마네서
실행되어야 합니다.
Utlpwdmng.sql 스크립트가 실행되는 동안 오라클 서버는 VERIFY_FUNCTION 을 생성하며
DEFAULT 프로파일을 다음 ALTER PROFILE 명령을 사용하여 변경합니다.
ALTER PROFILE DEFAULT LIMIT
PASSWORD_LIFE_TIME 60
PASSWORD_GRACE_TIME 10
PASSWORD_REUSE_TIME 1800
PASSWORD_REUSE_MAX UNLIMITED
FAILED_LOGIN_ATTEMPS 3
PASSWORD_LOCK_TIME 1/1440
PASSWORD_VERIFY_FUNCTION verify_function;
18-27 암호 정보 보기
. DBA_USERS
- profil
- username
- account_status
- lock_date
- expiry_date
. DBA_PROFILES
- profile
- resource_name
- resource_type (PASSWORD)
- limit
기간 만료와 잠금 날짜, 그리고 계정 상태에 대한 정보를 얻고 싶으면 DBA_USERS를
사용하십시요
SVRMCR> SELECT username, password, account_status,
2> lock_data, expiry_data
3> FROM dba_users;
USENAME PASSWORD ACCOUNT_STATUS LOCK_DATE EXPIRY_DA
-------- ----------- ---------------- ---------- -----------
SYS D4C5016086B2DC6 OPEN 19-DEC-97
SYSTEM D4DF7931AB130E3 OPEN 19-DEC-97
TEST 7AOF2B316C212D6 OPEN 31-JAN-98
SCOTT F894844C34402B5 OPEN 19-DEC-97
DBSNMP E066D214D5421CC OPEN 19-DEC-97
USER3 94152F9F5B35B10 OPEN
12-FEB-98
6 rows selected
암호 프로파일 정보를 출력하려면 DBA_PROFILE 뷰를 질의 하십시오
SVRMGRL> SELECT * FROM dba_profiles
2> WHERE resource_type='PASSWORD';
PROFILE RESOURCE_NAME LIMIT
----------------- ----------------------------- -----------
DEFAULT FAILED_LOGIN_ATTEMPTS 3
DEVELOPER_PROF FAILED_LOGIN_ATTEMPTS DEFAULT
DEFAULT PASSWORD_LIFE_TIME 60
DEVELOPER_PROF PASSWORD_LIFE_TIME DEFAULT
DEFAULT PASSWORD_REUSE_TIME 1800
DEVELOPER_PROF PASSWORD_REUSE_TIME DEFAULT
DEFAULT PASSWORD_REUSE_MAX UNLIMITED
DEVELOPER_PROF PASSWORD_REUSE_MAX DEFAULT
DEFAULT PASSWORD_VERIFY_FUNCTION VERIFY_FUNCTION
DEVELOPER_PROF PASSWORD_VERIFY_FUNCTION DEFAULT
DEFAULT PASSWORD_LOCK_TIME .0006
DEVELOPER_PROF PASSWORD_LOCK_TIME DEFAULT
DEFAULT PASSWORD_GRACE_TIME 10
DEVELOPER_PROF PASSWORD_GRACE_TIME DEFAULT
14 rows selected.
18-29.
요약
. 자원 사용 제어
. 암호 관리
요약참조
+-----------------------------+--------------------------+
| 관련내용 | 참조 |
+-----------------------------+--------------------------+
| 초기화 파라미터 | RESOURCE_LIMIT |
+-----------------------------+--------------------------+
| 동적 성능 뷰 | |
+-----------------------------+--------------------------+
| 데이터 딕셔너리 뷰 | DBA_PROFILES |
| | DBA_USERS |
+-----------------------------+--------------------------+
| 명령어 | CREATE PPROFILE |
| | ALTER PROFILE |
| | DROP PROFILE |
| | CREATE USER |
| | ALTER USER |
+-----------------------------+--------------------------+
| 저장 프로시저와 함수 | VERIFY_FUNCTION |
+-----------------------------+--------------------------+
19장 권한관리(**중요**)
목적
. 시스템과 오브젝트 권한 식별
. 권한 부여와 철회
. 운영 체제 인증, 또는 패스워드 파일 인증 제어
권한관리 : 두가지 유형의 권한이 있습니다.
. SYSTEM : 사용자가 데이터베이스에 특별한 작업을 수행하는 것을 가능하게 해 줍니다.
. OBJECT : 사용자가 특정 오브젝트에 접근하고 조작하는 것을 가능하게 해 줍니다.
시스템 권한
각 시스템 권한은 특별한 데이터베이스 작업이나 데이터베이스 작업 클래스를 수행하는
것을 가능하게 해 줍니다. 이들 작업에는 테이블, 뷰, 롤백 세그먼트, 그리고 프로시저의
생성, 삭제, 수정이 해당됩니다.
오브젝트 권한
각 오브젝트 권한은 테이블이나 뷰, 시퀀스, 프로시저, 함수, 또는 패키지 중 지정된 한
오브젝트에 특별한 작업을 수행하는 것을 가능하게 해 줍니다.
시스템 권한
.80개 정도의 시스템 권한이 있습니다.
.권한의 ANY키워드는 모든 스키마에 대해 권한을 가짐을 의미합니다.
.GRANT 명령은 사용자, 또는 사용자 그룹에서 권한을 추가해 줍니다.
.REVOKE명령은 권한을 삭제해 줍니다.
.대략 80개 정도의 시스템 권한이 있으며, 그 수는 계속 증가하고 있습니다.
.권한은 다음과 같이 분류될 수 있습니다.
-전 시스템에 걸친 작업을 가능하게 해주는 권한:예, CREATE SESSION, CREATE TABLESPACE
-사용자 자신의 스키마 내의 오브젝트에 대한 관리를 가능하게 해주는 권한:
예: CREATE TABLE
-모든 스키마에 있는 오브젝트에 대한 관리를 가능하게 해주는 권한
예: CREATE ANY TABLE
.권한은 사용자나 롤에게 시스템 권한을 주거나 철회하는 DDL 명령 GRANT와 REVOKE로
제어할 수 있습니다.("롤관리"장을 보십시오)
주
ANY권한을 가진 사용자는 접두어가 USER나 ALL인 것을 제외한 모든 딕셔너리 테이블과
PUBLIC에게 부여된 권한 상의 모든 뷰에 접근할 수 있습니다.
시스템 권한 : 예
범주 예
-------------------------------------------------
인덱스 CREATE ANY INDEX
ALTER ANY INDEX
DROP ANY INDEX
-------------------------------------------------
테이블 CREATE TABLE
CREATE ANY TABLE
ALTER ANY TABLE
DROP ANY TABLE
SELECT ANY TABLE
UPDATE ANY TABLE
DELETE ANY TABLE
-------------------------------------------------
세션 CREATE SESSION
ALTER SESSION
RESTRICTED SESSION
-------------------------------------------------
데이
블스페이스 CREATE TABLESPACE
ALTER TABLESPACE
DROP TABLESPACE
UNLIMITED TABLESPACE
-------------------------------------------------
. CREATE INDEX 권한은 없습니다.
. CREATE TABLE나 CREATE PROCEDURE, 또는 CREATE CLUSTER 같은 권한은 해당 오브젝트를
삭제하는 권한도 포함합니다.
. CREATE TABLE은 CREATE INDEX와 ANALYZE 명령을 포함합니다. 사용자는 테이블
스페이스에 할당량을 가지고 있거나 UNLIMITED TABLESSPACE를 부여 받았어야만 합니다.
. UNLIMITED TABLESPACE는 롤에 부여될 수 없습니다.
. 테이블을 잘라 버리려면(TRUNCATE) DROP ANY TABLE 권한이 필요합니다.
주
전체 권한 목록을 보고 싶으면 ORACLE SEVER ADMINISTATOR'S GUIDE RELEASE 8.0의
21장 "사용자 권한 관리"를 참조하거나 SYSTEM_PRIVILEGE_MAP뷰를 질의 하십시요.
시스템 권한 부여
GRANT CREATE SESSION, CREATE TABLE TO user1;
GRANT CREATE SESSION TO scott WITH ADMIN OPTION;
구문
시스템 권한을 부여하려면 다음 명령을 사용하십시오.
GRANT { system_priv | role }
[, { system_priv | role } ] ...
TO { user | role | PUBLIC }
[, { user | role | PUBLIC } ] ...
[WITH ADMIN OPTION]
구문에서:
system_priv 부여될 시스템 권한
role 부여될 롤 이름
PUBLIC 시스템 권한을 모든 사용자에게 부여
WITH ADMIN OPTION 권한을 부여받는 사용자가 다른 사용자나 롤에게
부여받은 권한이나 롤을 부여할 수 있도록 해 줍니다.
지침사항
. 시스템 권한을 부여하려면 WITH ADMON OPTION 권한을 부여받아야 합니다.
. ADMIN OPTION 과 함께 권한을 부여 받은 사용자는 시스템 권한이나 롤을 ADMIM
OPTION과 함께 다시 부여할 수 있습니다.
. GRANT ANY ROLE 시스템 권한을 가진 사용자는 데이터베이스의 모든 롤을 부여할
수 있습니다.
. ADMIN OPTION과 함께 권한을 부여 받은 사용자는 데이터베이스의 모든 사용자나
롤에게 시스템 권한을 부여하거나 철회할 수 있습니다.
SYSDBA와 SYSOPER 권한
-------------------------------------------------------------
범주 예
-------------------------------------------------------------
SYSOPER STARTUP
SHUTDOWN
ALTER DATABASE OPEN | MOUNT
ALTER DATABASE BACKUP CONTROLFILE
ALTER TABLESPACE BEGIN/END BACKUP
RECOVER DATABASE,
ALTER DATABASE ARCHIVELOG
RESTRICTED SESSION
-------------------------------------------------------------
SYSDBA SYSOPRE privileges WITH ADMIN OPTION
CREATE DATABASE
RECOVER DATABASE UNTIL
---------------------------------------------------
-----------
"오라클 인스턴스 관리"자으이 패스춰드 파일을 사용한 인증ㅇ르 지정하는 데에서
시스템 권한 SYSDBA와 SYSOPER를 소개했었습니다.
데이터베이스 관리자만이 관리자 권한을 가지고 데이터베이스에 접속할 수 있어야
합니다.
SYSDBA로 접속한 사용자는 데이터베이스나 데이터베이스 내으 오브젝트에 어떠한
작업도 수행할 수 있는 무제한의 권한을 갖게 됩니다.
19-11. 패스워드 파일 인증
1. 패스워드 파일 생성하고 REMOTE_LOGIN_PASSWORD_FILE 파라미터 설정
2. REMOTE_LOGIN_PASSWORD_FILE = EXCLUSIVE로 설정
3. SYSOPER와 SYSDBA 권한을 사용자에게 부여
4. 패스워드 파일 멤버를 확인하려면 V$PWFILE_USERS를 질의
패스워드 유틸리티로 패스워드 파일을 생성한후 초기화 파라미터
MOTE_LOGIN_PASSWORD_FILE을 EXCLUSIVE 로 설정하여 데이터베이스
관리자는 SYSOPER와 SYSDBA 시스템 권한을 부여하여 사용하여
패스워드 파일에 추가할 수 있습니다.
이들 권한을 부여할 때는 WITH ADMIN OPTION이 사용 될 수 없습니다.
현재 SYSDBA로 접속한 사용자만이 SYSDBA나 SYSOPER 시스템 권한을
다른 사용자에게 부여할 수 있습니다.
데이터베이스가 시작되기 전에는 롤을 사용할 수 없으므로 이들
권한은 롤에는 부여될수 없습니다.
SYSDBA나 SYSOPER 권한을 부여받은 사용자를 알고 싶으면
V$PWFILE_USERS를 보십시오.
SVRVGR> SELECT * FROM V$pwfile_users;
USERNAME SYSDB SYSOP
---------------------------- ----- -----
INTERNAL TRUE TRUE
SYS TRUE TRUE
2 rows selected.
19-13 시스템 권한 출력
데이터베이스 레벨 세션 레벨
DBA_SYS_PRIVS SESSION PRIVS
* GRANTEE * PRIVILEGE
* PRIVILEGE
* ADMIN OPTION
사용자와 롤에 부여된 시스템 권한을 보려면 DBA_SYS_PRIVS를 질의 하십시오.
SVRMGR> SELECT * FROM DBA_SYS_PRIVS;
GRANTEE PRIVILEGE ADM
--------------- ------------------------------------ -----
...
SCOTT SELECT ANY TABLE NO
SYS DELETE ANY TABLE NO
SYS EXECUTE ANY TYPE NO
SYS INSERT ANY TABLE NO
SYS SELECT ANY SEQUENCE NO
SYS SELECT ANY TABLE YES
SYS UPDATA ANY TABLE NO
SYSTEM UNLIMITED TABLESPACE YES
뷰 SESSION_PRIVS 는 현재 세션에서 사용자에게 가능한 권한을 보여 줍니다.
사용자 SCOTT을 예로 들어 봅시다.
SVRMGR> SELECT * FROM session_privs;
PRIVILEGE
--------------------------------------------------------------
CREATE SESSION
ALTER SESSION
CREATE TABLE
SELECT ANY TABLE
CREATE CLUSTER
CREATE SYNONYM
CREATE VIEW
CREATE SEQUENCE
CREATE DATABASE LINK
CREATE PROCEDURE
CREATE TRIGGER
CREATE TYPE
12 rows selected.
주
DBA_SYS_PRIVS 뷰는 데이터베이스 레벨에서 롤과 사용자에게 부여된
모든 시스템 권한을 보여줍니다.
반면 SESSION_PRIVS는 세션에 대한 현재에 권한을 보여 주는데, 직접 부여된
권한과 enable된 롤을 모두 보여 줍니다.("롤 관리 " 장을 참조하십시오.)
19-15. 시스템 권한 제한 사항
07_DICTIONARY_ACCESSIBILITY = TRUE
* Oracle7 방식으로 되돌아 갑니다.
* ANY 키워드를 가진 시스템 권한 상의 제한 사항을 제거해 줍니다.
* 기본 값은 TRUE 입니다.
Oracle8의 딕셔너리 보호방식은 허가받지 않은 사용자가 딕셔너리 오브젝트에
접근 하는것을 막아 줍니다.
딕셔너리 오브젝트에 접근하는 것은 시스템 권한 SYSDBA와 SYSOPER를 가진 사용자로
제한됩니다.
다른 스키마의 오브젝트에 접근할 수 있는 시스템 권한 일지라도 딕셔너리 오브젝트에
접근할 수는 없습니다.
예를 들어 SELECT ANY TABLE 권한은 다른 스키마의 뷰와 테이블에 접근할 수 있게
해주지만 딕셔너리 오브젝트를 검색할 수 있게 해 주지는 않습니다.
기본값인 TRUE로 파라미터가 설정되면 SYS 스키마의 오브젝트에 접근하는 것이
가능해 집니다.
(Oracle7 방식)
FALSE로 파라미터가 설정되면 다른 스키마의 오브젝트에 접근할 수 있는 시스템
권한일지라도 딕셔너리 스키마의 오브젝트에는 접근할 수 없습니다.
예를 들어 07_DICTIONARY_ACCESSIBILITY=FALSE라면 SELECT ANY TABLE 명령문은
SYS 스키마를 제외한 모든 스키마의 뷰나 테이블로의 접근을 가능하게 해줍니다.
시스템 권한 EXECUTE ANY PROCEDURE도 SYS 스키마를 제외한 모든 스키마의
프로시저에 접근할 수 있게 해 줍니다.
19-17. 시스템 권한 철회
REVOKE CREATE TABLE FROM user1;
REVOKE CREATE SESSION FROM scott;
구문
시스템 권한을 철회하려면 다음 명령을 사용하십시오.
REVOKE {system_priv | role}
[ , {system_priv | role} ] ...
FROM {user | role | PUBLIC}
[ , {user | role | PUBLIC} ] ...
주
* REVOKE 명령은 GRANT 명령으로 직접 부여되었던 권한만을 철회 할수 있습니다.
* 시스템 권한을 철회하면 일부 종속된 오브젝트에 영향을 줄 수 있습니다.
예를들어 SELECT ANY TABLE 권한이 부여된 사용자가 다른 스키마의 테이블을
사용하는 프로시저나 뷰를 작성했을 경우 SELECT ANY TABLE 권한을 철회하면
프로시저나 뷰가 부적합(invalid)해지게 됩니다.
19-19
with ADMIN OPTION을 사용했는지의 여부와 상관없이 시스템 권한이 철회될 때는
연쇄(cascade)효과가 없습니다.
다음 시나리오가 이것을 설명하고 있습니다.
1.DBA가 ADMIN OPTION과 함께 CREATE TABLE시스템 권한을 USER1에게 부여합니다.
2.USER1이 테이블을 생성합니다.
3.USER1이 SCOTT에게 CREATE TABLE SYSTEM PRIVILEGE를 부여합니다.
4.SCOTT이 테이블을 생성합니다.
5.DBA가 USER1으로부터 CREATE TABLE SYSTEM PRIVILEGE 를 철회합니다.
6.USER1의 테이블은 계속 존재하지만 더 이상 새로운 테이블을 생성할수 없습니다.
7.SCOTT은 계속 테이블과 CREATE TABLE SYSTEM PRIVILEGE를 가지고 있습니다.
주) 위의 3단계에서 USER1이 ADMIN OPTION과 함께 SCOTT에게 권한을 부여했다면 SCOTT은
USER1에게 권한을 철회할수도 있습니다.
19-20
오브젝트 권한
오브젝트 권한 테이블 뷰 시퀀스 프로시저
ALTER * *
DELETE * *
EXECUTE *
INDEX *
INSERT * *
REFERENCES *
SELECT * * *
UPDATE * *
주)각 오브젝트 권한은 부여받은 사용자가 오브젝트에 작업을 수행할 수 있도록
허가 합니다.
위의 표는 각 유형의 오브젝트에 부여될수 있는 오브젝트 권한을 요약한 것입니다.
19-21
오브젝트 권한 부여
GRANT EXECUTE ON dbms_pipe TO PUBLIC;
GRANT UPDATE(ename, sal) ON emp TO user1 WITH GRANT OPTION;
구문
오브젝트 권한을 부여하려면 다음 명령을 사용하십시오.
GRANT {object_priv [ (column_list) ]
[, object_priv [(column_list)]... | ALL [PRIVILEGES] }
ON [schema.]object
TO {user | role | PUBLIC}
[, {user | sole | PUBLIC} ] ...
[WITH GRANT OPTION]
구문에서
object_priv 부여될 오브젝트 권한
colum_list 테이블이나 뷰의 열(INSERT, REFERENCE, UPDATE권한을
부여할때만 지정할 수 있습니다.)
ALL WITH GRANT OPTION으로 부여된 오브젝트에 대한 모든
권한 부여
ON object 권한이 부여될 오브젝트 지정
WITH GRANT OPTION 부여받은 사용자가 다른 사용자나 롤에게 오브젝트
권한을 부여할 수 있게 합니다.
지침사항)
* 권한을 부여하려면 오브젝트가 자신의 스키마에 있거나 WITH GRANT OPTION 권한을
가지고 있어야한다.
* 기본적으로 소유한 오브젝트에 대한 모든 권한이 자동적으로 획득됩니다.
* 보안을 고려해야 한다면 자신의 오브젝트에 대한 권한을 다른 사용자에게 부여할때
주의하십시오.
* WITH GRANT OPTION은 롤에 권한을 부여할때는 사용할수 없습니다.
19-23
오브젝트 권한 출력
DBA_TAB_PRIVS DBA_COL_PRIVS
GRANT GRNATEE
OWNER OWNER
TABLE_NAME TABLE_NAME
GRANTOR COLUMN_NAME
PRIVILEG PRIVILEG
GRANTABLE GRANTABLE
특정 사용자에게 부여된 모든 오브젝트 권한을 보고 싶으면 DBA_TAB_PRIVS를 질의하세요.
SVRMGR> SELECT * FROM dba_tab_privs
2> WHERE GRANTEE='SCOTT'
GRANTEE OWNER TABLE_NAME GRA PRIVILEG GRA
----------- ----- ----------- ----- --------- -----
SCOTT SYS RESUMES SYS READ NO
부여된 열 지정 권한을 모두 보려면 다음 질의를 사용하십시오.
SVRMGR> SELECT * FROM dba_col_privs;
GRANTEE OWNER TABLE_NAME COLUMN_NAME GRANTOR PRIVILEGE
GRA
-------- ------- ----------- ----------- ------- --------- ----
SYSTEM SCOTT EMP EMPNO SCOTT INSERT NO
SYSTEM SCOTT EMP SAL SCOTT UPDATE NO
2 rows selected.
19-25
오브젝트 권한 철회
REVOKE execute ON dbms_pipe
FROM scott;
구문)
오브젝트 권한을 철회하려면 다음 명령을 실행하시오.
REVOKE { object_priv
[, object_priv ]...
|ALL [PRIVILEGES] }
ON [schema.]object
FROM {user | role | PUBILC}
[, {user | role | PUBLIC} ] ...
구문에서
object_priv 철회할 오브젝트 권한
ALL 사용자에게 부여된 모든 오브젝트권한 철회
ON 오브젝트 권한을 철회할 오브젝트
FROM 오브젝트 권한이 철회될 사용자나 룰
CASCADE CONSTRAINTS REFERENCES나 ALL 권한 철회시 관련 참조 무결성
제약조건을 삭제합니다.
제한사항
권한 부여자는 자신이 권한을 부여했던 사용자로부터만 권한을 철회할수있다.
19-28
WITH GRANT OPTION으로 부여된 오브젝트 권한을 청회하면 연쇄적(cascade)으로 철회됩니다.
다음 시나리오가 이것을 설명하고 있습니다.
시나리오
1 USER1이GRANT OPTION과 함께 SELECT 오브젝트 권한을 부여 받습니다.
2 USER1이 USER2에게 EMP상의 SELECT 권한을 부여합니다.
결과는 다음과 같습니다.
3 USER1에게서 SELECT 권한이 철회될때 USER2도 연쇄적으로 권한이 철회됩니다.
19-29 요약
시스템 권한과 오브젝트 권한 제어
요약참조
==========================================================
관련내용 | 참조
----------------------------------------------------------
초기화 파라미터 | 07_DICTIONARY_ACCESSIBILITY
동적 성능 뷰 | 없음
데이터 딕셔너리 뷰 | DBA_SYS_PRIVS
| SESSION_PRIVS
| DBA_TAB_PRIVS
| DBA_COL_PRIVS
명령어 | GRANT
| REVOKE
패키지 프로시저와 함수 |
==========================================================
20-1 롤 관리(**중요**)
20-3 목적
. 롤 생성과 수정
. 롤의 가용성 제어
. 롤 제거
. 미리 정의된 롤 사용
. 데이터 딕셔너리의 롤 정보 출력
20-4
오라클의 롤을 이용하면 권한 관리가 쉽고 간편해 집니다. 롤은 사용자나 다른 롤에
부여되는 관련 권한들의 명명된 그룹입니다. 롤은 데이터베이스 내에서 권한을
관리하기 쉽도록 설계되었습니다.
+롤의 특성+
. 시스템 권한을 부여하고 철회할때 사용되는 것과 동일한 명령으로 사용자에게 부여하고
철회할 수 있습니다.
. 롤 자신(간접적으로도 불가능)을 제외한 모든 사용자와 롤에게 부여할 수 있습니다.
. 시스템 권한과 오브젝트 권한으로 이루어 집니다.
. 각 사용자가 부여받은 롤을 enable하거나 disable할 수 있습니다.
. 암호를 요구하도록 할 수도 있습니다.
. 각 롤 이름은 기존의 사용자 이름과 롤 이름과는 다른 유일한 것이어야 합니다.
. 누군가가 고요하는 것도 아니고 어느 스키마에 속하는 것도 아닙니다.
. 데이터 딕셔너리에 설명되어져 있습니다.
20-5롤의 장점
권한 부여 작업 감소
동적 권한 관리
권한의 선택적 사용
OS를 통해 부여
연쇄적으로 철회되지 않음
연쇄적으로 철회되지 않음
향상된 성능
권한부여 작업 감소
롤을 사용하면 권한 관리가 간단해 집니다.
일련의 권한을 여러 사용자에게 부여하기 보다는 권한들을 하나의 롤에 부여한 후
그 롤을 각 사용자에게 부여하십시오
동적 권한 관리
롤과 관련된 권한이 수정되면 해단 롤을 부여받은 모든 사용자는
자동적으로 죽시 수정된 권한을 갖게 됩니다.
권한의 선택적 사용
롤은 enable 되거나 disable되어 임시로 권한을 on,off할 수 있습니다.
롤을 enable하는 것은 사용자가 그 롤을 부여받았는지 검증하는데도 사용될 수 있습니다.
OS를 통해 부여
운영 체제 명령이나 유틸리티가 데이터베이스의 사용자에게 롤을 할당하는데 사용될수
있습니다.
20-6
연쇄적으로 철회하지 않음
연쇄 철회를 발생시키지 않고 오브젝트 권한을 철회할 수 있습니다.
향상된 성능
롤을 disable하여 실행 중 검증해야 할 권한을 줄일 수 있습니다.
롤을 사용하면 데이타 딕셔너리에 저장된 부여에 대한 정보가 줄어들게 됩니다.
20-7
롤생성
CREATE ROLE sales_clerk;
CREATE ROLE hr_clerk
IDENTIFIED by bonus;
CREATE ROLE hr_manager
IDENTIFIED EXTERNALLY;
구문
롤을 생성하려면 다음 명령을 사용하십시오
CREATE ROLE role [NOT IDENTIFIED | IDENTIFIED
{BY password | EXTERNALLY } ]
구문에서
role 롤 이름
NOT IDENTIFIED 롤을 enable할때 아무런 검증도 필요하지 않음을 의미
BY password 롤을 enable할때 사용자가 입력해야만 하는 암호 제공
EXTERNALLY 사용자가 롤을 enable하기전에 외부 서비스(운영 체제나 협력
업체서비스 같은)에 의해 인증을 받아햐만 함을 의미
20-8
주 CREATE ROLE IDENTIFIED GLOBALLY 명령은 Oracle Security Server를 통해 롤 검증이
이루어져만 하도록 지정합니다.
20-9
미리 정의된 롤 사용
롤 명 설 명
-------------------------------------------------------------------
CONNECT | 이전 버전과의 호환을 위해서 제공됩니다
RESOURCE | 이전 버전과의 호환을 위해서 제공됩니다
DBA | 모든 시스템 권한과 WITH ADMIN OPTION
EXP_FULL_DATABASE | DB를 익스포트할 권한
IMP_FULL_DATABASE | DB를 임포트할 권한
DELETE_CATALOG_ROLE | DB 테이블에 대한 DELETE 권한
EXECUTE_CATALOG_ROLE | DD 패키지에 대한 EXECUTE권한
SELECT_CATALOG_ROLE | DD 테이블에 대한 SELECT 권한
--------------------------------------------------------------------
위의 롤들은 오라클 데이터베이스에 자동적으로 정의됩니다.Connect Resouse롤은
오라클 이전 버전과의 역 호환을 위해 제공되며 오라클 데이터베이스의 다른
롤과 같은 방법으로 수정할수 있습니다.
EXP_FULL_DATABASE와 IMP_FULL_DATABASE 롤이 임포트와 익스포트 유틸리티를 사용할
때의 편의를 위해 제공됩니다
DELETE_CATALOG_ROLE,EXECUTE_CARLOG_ROLE, 그리고 SELECT_CATALOG_ROLE
롤은 데이터 딕셔너리 뷰와 패키지에의접근을 위해 제공됩니다.이들 롤은 DBA 롤은
가지고 있지 않지만 데이터 딕셔너리의 뷰와 테이블에 접근해야만 하는 사용자들에게
부여될 수 있습니다.
다른 특별한 롤들
오라클은 또한 데이터베이스를 관리할 수 있도록 허가해주는 롤도 생성합니다. 여러 운영
체제에서 이러한 롤들은 OSOPER 와OSDBA라 불리웁니다.이름은 우영 체제에 따라 다를 수
있습니다.
22-10
다른 롤은 데이터베이스와 함께 제공되는 SQL 스크립트로 정의됩니다.예를 들어
AQ_ADMINSRTATOR_ROLE 과 AQ_USER_ROLE 은 dbmsaqsd.sql의 스크립트로 생성됩니다.이들
롤은 Advanced Queuing기능과 함께 사용됩니다.
주
-미리 정의된 롤에만 의지할 필요는 없습니다. 오히려 데이터베이스 보안을 위해 자신만의
고유 롤을 설계하도록 권장하는 바입니다. 미리 정의된 롤은 앞으로의 오라클 버전에서는
자동적으로 생성되지 않을 수 도 있습니다.
-Solaris 같은 플랫폼에서는 RESOUCE 롤을 부여받은 사용자는 UNLIMITED
TABLESPACE 권한이 롤에 할당되어 있지 않더라도 명시적으로 함께 받게 됩니다.
20-11
롤 수정
ALTER ROLE sales_clerk
IDENTIFIED BY commission;
ALTER ROLE hr_clerk
IDENTIFIED EXTERNALLY;
ALTER ROLE hr_manager
NOT IDENTIFIED;
롤은 그 인증 방식을 변경하기 위해서만 수정될 수 있습니다.
구문
룰을 수정하려면 다음 명령을 사용하십시요.
ALTER ROLE role (NOT IDENTIFIED) | IDENTIFIED
(BY password | externally));
구문에서:
role 롤의 이름
NOT IDENTIFIED 롤을 enable할 때 검증이 필요없음을 의미
IDENTIFIED 롤을 enable할 때 검증이 필요함을 의미
BY password 를을 enable할 때 사용될 암호 제공
EXTERNALLY 롤을 enable하기 전에 사용자가 외부 서비스
(운영체제나 협력 업체(third-party)
서비스)에 의해 허가를 받아야만 함을 의미
20-13
롤 지정
GRANT sales_clerd TO scott;
GRANT hr_clerk,
TO hr_manager;
GRANT hr_manager TO scott
WITH ADMIN OPTION;
구문
사용자에게 롤을 부여하려면 사용자에게 시스템 권한을 부여할 때 사용했던 것과
동일한 구문의 명령을 사용하십시요.
GRANT role[ , role] . . .
TO {user | role | PUBLIC}
[, {user | role | PUBLIC}]
[WITH ADMIN OPTION]
구문에서:
role 부여될 롤, 또는 롤을 부여받을 롤
user 롤을 받을 사용자
role 롤을 받을 롤
PUBLIC 모든 사용자에게 롤을 부여
WITH ADMIN OPTION 부여받은 롤을 다른 사용자나 롤에게 부여하는 것을
가능하게 합니다.
(이 옵션으로 롤을 부여하면 롤을 받은 사용자는 다른
사용자에게 받은 롤을 부여하거나 철회할 수 있으며
롤을 수정하거나 삭제할 수 있습니다.)
20-14
롤을 생성한 사용자는 암시적으로 ADMIN OPTION과 함께 생성한 롤이 지정된 것입니다.
ADMIN OPTION을 가진 롤을 부여받지 못한 사용자가 다른 사용자에게 롤을 부여하거나
철회하려면 GRANT ANY ROLE 시스템 권한이 필요합니다.
20-15
기본 롤 설정
ALTER USER SCOTT
DEFAULT ROLE hr_clerk, sales_clerk;
ALTER USER scott DEFAULT ROLE ALL;
ALTER USER scott DEFAULT ROLE ALL
EXCEPT hr_clerk;
ALTER USER scott DEFAULT ROLE NONE;
사용자는 많은 롤을 할당받을 수 있습니다. default role은 사용자가 로그인 할 때
자동적으로 enable 되는 할당된 롤의 부분 집합입니다. 디폴트로 사용자에게 할당된
모든 롤이 로그인 시 enable됩니다.
ALTER USER 명령으로 사용자에 대한 기본 롤을 제한하십시요.
구문
사용자에게 기본 롤을 할당하려면 다음 구문을 사용하십시요.
ALTER USER user DEFAULT ROLE
{role, [,role]...|ALL [EXCEPT role [,role]...] | NONE}
구문에서:
user 롤을 부여받을 사용자 이름
role 사용자에게 기본 롤이 될 롤
ALL 사용자에게 부여된 롤 중 EXCEPT절에 나열된것을 제외한 모든
롤을 기본 롤로 만듭니다.(기본값입니다.)
EXCEPT 기본 롤에 포함되지 않는 롤을 나타냅니다.
20-16
NONE 기본 롤로 아무것도 부여하지 않습니다. (로그인 시 사용자가
갖는 권한은 사용자에게 직접 할당된 권한 뿐입니다.)
기본 롤이 되려면 반드시 사전에 부여되어 있어야 합니다. 따라서 CREATE USER 명령으로
기본 암호로 인증되는 롤의 경우 기본 롤로 만들 때에는 암호가 필요하지 않습니다.
0-(17~18) ROLE Enable과 Disable
. 사용자로부터 임시로 롤을 철회하려면 그롤을 disable하십시요.
. 임시로 롤을 부여하려면 그 롤을 enable하십시요.
. SET ROLE 명령은 롤을 enable하고 disable합니다.
. 로그인 시 기본 롤이 enable됩니다.
. 롤을 enable할 때 암호가 필요할 수도 있습니다.
롤에 관련된 권한을 임시로 활성화시키려면 롤을 enable하거나 disable
하십시오. 롤을 enable하려면 먼저 해당 롤이 사용자에게 부여되어 있어야 합니다.
롤이 enable되면 사용자는 그 롤에 부여된 권한을 사용할 수 있습니다. 롤이 disable되면
권한이 사용자에게 직접 부여되거나 그 권한을 사용 가능하게 해주는 다른 롤이
enable되지 않는 한 사용자는 disable된 롤에 관련된 권한을 사용할 수 없습니다.
세션동안 여러 롤들이 enable될수있습니다.
세션을 시작하면 다시 기본 롤들만 enable되어 있게 됩니다.
.롤이 enable 되도록 지정
SET ROLE 명령과 DBMS_SESSION.SET_ROLE 프로시저는 명령에 포함된 모든 롤을 enable 하며
포함되지 않은 롤은 모두 disable합니다. 롤은 PL/SQL 명령을 허용하는 어떤 도구나
프로그램에서 enable될 수 있습니다. 세션을 시작하면 다시 기본 롤들만
enable되어 있게 됩니다.
ALTER USER...DEFAULT ROLE 명령을 사용하여 사용자가 로그인할 때 어떤 롤이 ebable되게
할 것인지 지정할 수 있습니다. 다른 롤은 모두 disable됩니다.
롤을 enable하는데 암호가 필요할 수도 있습니다. 롤을 enable하려면 암호가 SET ROLE
명령에 포함되어 있어야 합니다.
사용자에게 할당된 기본 롤은 암호가 필요하지 않습니다. 암호가 없는 롤들과 마찬가지로
로그인 시 enable됩니다.
제한사항
롤은 저장 프로시저로부터는 enable될 수 없습니다. 왜냐하면 무엇보다도 이 작업이
프로시저를 호출한 보안 도메인(권한 집합)을 변경할 수도 있기 때문입니다.
그러므로 PL/SQL에서는 롤이 익명의 블록(anonymous block)이나 응용 프로그램
프로시저 (예를 들자면 oracle Forms 프로시저)에서만 enable되고 disable될 수있고
저장 프로시저에서는 안 됩니다.
저장 프로시저가 SET ROLE에 댜한 명령을 포함하고 있다면 실행시 다음 에러가 발생될
것입니다.
ORA-06565: cannot execute SET ROLE from with stored procedure
20-(19~20) ROLE Enable과 Disable: 예
SET ROLE sales_clerk
IDENTIFIED BY commission;
SET ROLE hr_clerk;
SET ROLE ALL EXECPT
sales_clerk;
SET ROLE NONE;
구문
롤을 enable하거나 disable하려면 다음 명령을 사용하십시오.
SET ROLE {role [IDENTIFIED BY PASSWORD]
[, role [IDENTIFIED BY PASSWORD] ] ...
| ALL [EXCEPT role [ , role] ... ]
| NONE }
SET ROLE 명령은 사용자에게 부여된 그 밖의 롤은 turn off 시킵니다.
구문에서 :
role 롤 이름
IDENTIFIED
BY password 롤을 enable할때 필요한 암호 제공
ALL EXCEPT 절에 나열된 롤을 제외한, 현재 사용자에게 부여된 모든 롤을
enable(암호를 가진 롤을 enable할 때는 사용할수 없습니다.)
EXCEPT role enable 하지 않은 롤
NONE 현재세션에서 모든 롤 disable(사용자에게 직접 부여된 권한만 활성
상태가 됩니다.)
EXCEPT 절 없는 ALL옵션은 enable된느 모든 롤이 암호를 갖지 않을 때에만 작동합니다.
20-(21~22) 사용자에게서 롤 제거
REVOKE sales_clerk FROM scott;
REVOKE hr_manager FROM PUBLIC;
구문
사용자에게서 롤을 철회하려면 시스템 권한을 철회할 때 사용하는 것과 동일한 구문을
사용하십시오.
REVOKE role [, role]...
FROM {user|role|PUBLIC}
[, {user|role|PUBLIC} ]...
구문에서 :
role 철회될 롤, 또는 롤이 철회될 롤
user 롤이 철회될 사용자
PUBLIC 모든 사용자로부터 권한이나 롤 철회
롤제거
구문
데이터베이스로부터 룰을 제거하려면 다음 구문을 사용하십시오.
DROP ROLE role
구문에서:
role 제거할 롤
롤을 삭제할 때 오라클 서버는 삭제할 롤이 부여되었던 모든 사용자와
롤로부터 철회한 후 데이터베이스로부터 제거합니다.
ADMIN OPTION과 함께 삭제할 롤을 부여받았거나 DROP ANY ROLE시스템
권한을 가지고 있어야 롤을 삭제할 수 있습니다.
롤 생성시 지침사항
롤이 임무를 수행하는데 필요한 권한을 포함하고 있기 때문에 이름은
보통 응용 프로그램 작업이나 직무 이름입니다. 위의 예는 롤 이름으로
응용 프로그램 작업과 직무 이름을 모두 사용하고 있습니다.
1. 각 응용 프로그램 작업을 위한 롤을 생성합니다. 응용 프로그램
롤의 이름은 payroll같이 응용 프로그램 작업데 대응됩니다.
2. 응용 프로그램 롤에 작업을 수행하는데 필요한 권한을 할당합니다.
3. 각 유형의 사용자를 위한 롤을 생성합니다. 사용자 롤의 이름은
pay_clerk같이 직무 이름에 대응됩니다.
4. 사용자의 롤을 개개의 권한이 아닌 응용 프로그램 롤을 부여합니다.
5. 사용자에게 사용자 롤과 응용 프로그램 롤을 부여합니다.
응용 프로그램을 수정한 결과 payroll작업을 수행하기 위해 새로운
권한이 필요하다면 DBA는 새 권한을 응용 프로그램 롤,PATROLL에 할당
하기만 하면 됩니다. 현재 이 작업을 수행하고 있는 사용자는 새 권한을
받게 될 것입니다.
page: 20-23,24
암호와 기본 롤을 사용할 때 지침 사항
암호사용
. 롤을 enable할 때 암호는 추가 레벨의 보안을 제공합니다. 응용 프로그램은
수표를 발행하는데 필요한 PAY_CLERK롤을 enable할 때 사용자가 암호를
입력하도록 요구할 수도 있습니다.
. 암호는 롤이 응용 르로그램을 통해서만 enable되도록 합니다. 이 기술은
위의 예에 나타나 있습니다.
- DBA가 사용자에게 두 롤 PAY_CLERK와 PAY_CLERK_RO를 부여했습니다.
- PAY_CLERK는 payroll clerk 작업을 수행하는데 필요한 모든 권한을
부여 받았습니다.
- PAY_CLERK_RO(RO는 읽기 전용(read only)를 의미)는 payroll clerk
작업을 수행하는데 필요한 테이블 예의 SELECT권한을 부여 받았습니다.
- 사용자는 질의를 수행하기 위해 SQL*Plus에 로그인 할 수 있습니다.
하지만 PAY_CLERK이 기본 롤이 아니고 PAY_CLERK의 암호를 알지
못하므로 데이터를 수정할 수는 없습니다.
- 사용자가 payroll응용 프로그램에 로그인할 때 응용 프로그램은 암호를
제공하여 PAY_CLERK을 enable 합니다. 암호는 프로그램 내에 코당 되어
있어 사용자가 암호를 입력하지 않습니다.
page 20-25,26
롤 정보 출력
많은 데이터 딕셔너리 뷰가 사용자와 롤에 부여된 권한에 대한 정보를 가지고
있습니다.
SVRMGR> SELECT role, password_required FROM dba_roles;
ROLE PASSWORD
----------------------------------- --------------
CONNECT NO
RESOURCE NO
DBA NO
AQ_USER_ROLE NO
SELECT_CATALOG_ROLE NO
EXECUTE_CATALOG_ROLE NO
AQ_ADMINISTRATOR_ROLE NO
RECOVERY_CATALOG_OWNER NO
IMP_FULL_DATABASE NO
EXP_FULL_DATABSE NO
SNMPAGENT NO
SALES_CLERK YES
HR_CLERK EXTERNAL
14 row
s selectd.
요약
. 롤 생성
. 롤에 권한 지정
. 사용자나 롤에게 롤 지정
. 기본 롤 설정
요약참조
관련내용 참조
초기화 파라미터 없음
동적 성능 뷰 없음
데이터 딕셔너리 뷰 DBA_ROLES
DBA_ROLE_PRIV
DBA_SYS_PRIV
ROLE_ROLE_PRIVS
ROLE_SYS_PRIVS
ROLE_TAB_PRIVS
SESSION_ROLES
명령어 CREATE_ROLE
ALTER_ROLE
DROP_ROLE
SET_ROLE
ALTER USER....DEFAULT ROLES
GRANT
REVOKE
저장 프로시저와 함수 DBMS_SESSION.SET_ROLE
제21장 감사(Auditing)
21-3.목적
.데이터베이스 감사(auditing)와 값에 따른(value-based)감사 구별
.데이터베이스 감사 사용
.Enable된 감사 옵션 보기
.감사 정보 읽어 들이고 관리
21-4.감사 범주
.권한 작업 감사
-항상 수행됨
-시작, 종료, 그리고 SYSDBA 접속 시 감사
.데이터베이스 감사
-DBA가 enable함
-열 값을 기록할 수 없음
.값에 따른, 또는 응용 프로그램 감사
-코드로 구현됨
-열값을 기록할 수 있음
-테이블의 변경 사항을 추적할 때 사용
권한 작업 감사
오라클 서버는 항상 다음과 같은 데이터베이스 관련 작업들을 감사하여 시스템 감사
기록(audit trail)에 기록합니다.
.인스턴스 시작 : 인스턴스를 시작한 OS사용자, 사용한 터미널 식별자(identifier),
날짜와 시간스탬프(stamp), 그리고 데이터베이스 감사가 활성화되거나 비활성화
되었는지의 여부를 상세히 기록한 감사기록이 생성됩니다.
.인스턴스 종료 : 인스턴스를 종료한 OS사용자, 사용한 터미널 식별자, 그리고
날짜와 시간 스탬프를 상세히 기록한 감사 기록이 생성됩니다.
.관리자 권한을 가지고 데이터베이스 접속 : 관리권한인 SYSOPER나 SYSDBA로
오라클에 접속한 OS사용자에 대해 상세히 기록한 감사 기록이 생성됩니다.
데이터베이스 감사
데이터베이스 감사는 선택된 사용자 데이터베이스 작업을 모니터하고 기록합니다.
이벤트에 대한 정보는 감사 기록에 저장됩니다.
21-5. 감사 기록은 미심쩍은 작업을 조사하는데 사용할 수 있습니다.
예를 들어 허가받지 않은 사용자가 테이블로부터 데이터를 삭제하면 데이터베이스
관리자는 데이터베이스의 테이블로부터 행을 삭제했든 못했든 관련된 모든 접속을
감사하도록 결정할 수도 있을 것입니다.
감사는 특정 데이터베이스 작업을 모니터하고 관련 데이터를 얻는데 사용할 수도
있습니다.
예를 들어 데이터베이스 관리자는 어느 테이블이 갱신되었는지, 얼마나 많은 논리적
I/O가 수행되었는지, 그리고 피크 타임 떄 동시에 접속한 사용자의 수는 얼마인지에
대한 통계를 얻을 수도 있습니다.
값에 따른 감사
데이터베이스 감사는 열 값을 기록할 수 없습니다. 데이터베이스 열에 대한 변경사항을
추적해야 하고 열 값이 변경될때마다 저정되어야 한다면 응용 프로그램 감사를
이용하십시오. 응용프로그램 감사는 클라이언트 코드나 저장 프로시저, 또는
데이터베이스 트리거를 통해 구현될 수 있습니다.
21-6. 값에 따른 감사
예
CREATE TRIGGER scott.audit_employee
AFTER INSERT OR DELETE OR UPDATE
ON scott.emp
FOR EACH ROW
BEGIN
INSERT INTO scott.audit_employee
VALUES( :OLD.empno, :OLD.name, ... ,
:NEW.empno, :NEW.name,...,
USER, SYSDATE);
END;
트리거를 사용한 값에 따른 감사의 예
슬라이드는 값에 따른 감사를 수행하기 위한 트리거를 생성하는데 사용되는 스크립트의
예를 보여 줍니다.
Employee테이블에 변경이 가해질 떄마다 신구 열 값, 변경한 사용자 이름, 그리고 시간
스탬프를 저장하는 트리거입니다.
테이터베이스 감사는 데이터베이스 관리자의 임무입니다. 따라서 본 장에서 주로 다룰
것입니다.
21-7
데이터베이스 관리자에게는 명확히 정의된 감사 목적이 있어야 합니다.
그것이 없다면 생성된 감사 정보는 무의미한 정보이며 감사 기록이 제어가
불가능하도록 커질 수 있습니다.
데이터베이스 감사 enable
감사하기로 결정했다면 AUDIT_TRAIL초기화 파라미터를 설정하여 인스턴스에대한
감사를 enable하십시오.
감사 기록이 데이터베이스 테이블에 쓰여질 것인지 운영 체제 감사 기록에 쓰여질
것인지를 나타내는 파라미터입니다.
감사 옵션 지정
다음으로 AUDIT 명령을 사용하여 특정 감사 옵션을 설정하십시오.
AUDIT명령으로 어느 명령이나 사용자, 오브젝트, 또는 권한을 감사할 것인지 지정하게
됩니다. 또한 감사 기록이 매번 생성될 것인지 세션 당 한 번만 생성될 것인지를
결정할 수도 있습니다. 더 이상 감사 옵션이 필요하지 않다면 NOAUDIT명령으로 옵션을
끌 수도 있습니다.
21-8
명령문의 실행
PL/SQL과 SQL문이 실행될 때 서버 프로세스는 감사 옵션을 검사하여 실행 중인
명령문이 감사 기록을 생성할 것인지의 여부를 결정합니다. PL/SQL프로그램
유니트(unit)가 실행될 때 필요하다면 프로그램 유니트 내의 개개의 SQL문을
감사합니다. 뷰와 프로시저는 다른 데이터베이스 오브젝트를 참조할 수도 있으므로
명령문 하나를 실행한 결과 여러 개의 감사 기록이 생성될 수도 있습니다.
감사 데이터 생성
감사 기록의 생성과 삽입은 사용자의 트랜잭션과는 독립적입니다.
그러므로 사용자의 트랜잭션이 롤백되더라도 감사 기록은 그대로 남아 있습니다.
수행 단계(phase)에서 감사 기록이 생성되므로 구문 분석 단계에서 발생한 구문
에러는 감사 기록을 생성하지 않을 것입니다.
감사 정보 검도
감사 기록을 보려면 감사 기록 데이터 딕셔너리 뷰를 검색하거나 운영 체제
유틸리티를 사용하여 운영체제 감사기록을 검사하십시오.
검색된 정보는 미심쩍은 작업을 조사하고 데이터베이스 작업을 모니터하는데
사용됩니다.
21-9
데이터베이스 관리자는 AUDIT_TRAIL초기화 파라미터를 설정하여 인스턴스 내의
감사를 enable합니다.
구문
AUDIT_TRAIL = value
구문에서:
value는 다음 중 한 가지일 수 있습니다.
DB 감사를 enable하고 모든 감사 기록을 데이터베이스 감사 기록(sys.aud$)으로
보냅니다.
OS 감사를 enable하고 감사 기록을 운영 체제 감사 기록으로 보낸니다.
(운영 체제에서 허용했을 경우에만)
NONE 감사를 disable합니다.(기본값입니다.)
DBA가 AUDIT_TRAIL파라미터를 DB나 OS로 설정하지 않으면 감사
기록(audit records)은 감사 기록(audit trail)에 쓰여지지 않을 것입니다.
SQL문 AUDIT와 NOAUDIT를 언제든지 사용할 수 있지만 DBA가 초기화 파일 내의
AUDIT_TRAIL파라미터를 설정해야지만 기록이 감사 기록에 쓰여질 것입니다.
21-10
주
이전 버전과의 역 호환을 위해 AUDIT_TRAIL은 TRUE(DB와 동등)나 FALSE(NONE과 동등)로
설정될 수 있습니다.
감사 기록을 OS감사 기록에 쓰는 것에 대한 정보는 Installation and Configuration
Guide에서 제공됩니다.
UNIX:운영 체제 감사 기록
대부분의 UNIX 시스템은 감사 정보를 운영 체제 감사 기록에 쓰는 것을
지원하지 않습니다. AUDIT_TRAIL=OS로 설정하면 초기화 파라미터 AUDIT_FILE_DEST에
의해 지정된 디렉토리에 텍스트 파일이 생성됩니다.
디폴트로 $ORACLE_HOME/rdbms/audit가 지정되어 있습니다.
WINDOWS NT: 운영 체제 감사 기록
Windows NT는 오라틀 감사 정보를 기록하는 운영 체제 감사 기록을 허용합니다.
이들 엔트리는 Event Viewer를 사용하여 검토할 수 있습니다.
21-11
감사 옵션 Enable
·명령문 감사
----------------
| AUDIT user ;|
----------------
·권한 감사
--------------------------
| AUDIT select any table |
| BY scott BY ACCESS ; |
--------------------------
·스키마 오브젝트 감사
--------------------------------------
| AUDIT LOCK ON scott.emp |
| BY ACCESS WHENEVER SUCCESSFUL ; |
--------------------------------------
< 그림 21 - 11 >
요청에 따른 이벤트 감사
AUDIT명령을 사용하여 감사 옵션을 지정할 수 있습니다. 이들 감사 기록은 사용자
SYS나 INTERNAL로 접속하여 설정한 세션에 의해서는 생성되지 않습니다.
이들 사용자에 의한 접속은 특정 오라클 내부 특성을 무시하므로 데이터베이스
시작, 종료, 그리고 복구 같은 관리용 작업이 가능합니다.
명령문 감사
SQL문의 유형에 따라 또는 오브젝트의 유형에 따라 감사할 수 있습니다.
예를 들자면 위 명령문 감사는 모든 사용자에 대해 모든 CREATE, ALTER,그리고
DROP USER문을 감사합니다. 명령문 감사 옵션은 대체적으로 폭이 넓어 옵션 당
사용된 여러 가지 유형의 관련 작업을 감사합니다. 예를 들어 AUDIT TABLE은
DDL명령문이 발효된 테이블에 상관없이 여러 DDL명령문을 추적합니다. 데이터베이스
내의 특정 사용자나 모든 사용자에 대해 명령문 감사를 할 수 있습니다.
21-12
권한 감사
권한 감사는 시스템 권한의 사용을 감사합니다.
예를 들어 SCOTT이 SELECT ANY TABLE권한을 사용할 때마다 감사 엔트리가 생성됩니다.
또 SCOTT이 SELECT권한을 받지 못했기 때문에 SCOTT이 다른 사용자에게 속한
테이블을 질의할 때만 엔트리가 생성될 것입니다. 감사할 때는 소유자 권한이 먼저
검사된 후 오브젝트 권한이 검사되고, 그리고 나서 시스템 권한이 검사됩니다.
그러므로 사용자의 SELECT ANY TABLE권한이 감사되고 있고 그 사용자가 자신의
테이블에서 select하면 SELECT ANY TALBE권한은 감사 기록을 발생시키지 않을
것입니다.왜냐하면 소유자 권한을 사용하여 테이블로부터 SELECT할 수 있기 때문입니다.
스키마 오브젝트 감사
스키마 오브젝트 감사는 특정 스키마 오브젝트에서 수행되는 명령문을 감사합니다.
예를 들면 사용자가 SCOTT.EMP오브젝트에 LOCK 명령을 성공적으로 실행했을 때
기록 엔트리가 생성됩니다.
구문
감사 옵션을 enable하려면 다음 명령을 사용하십시오.
권한 감사, 또는 명령문 감사
AUDIT {statement | system_priv}
[, {statement | system_priv} ] ...
[ BY user [, user ]... ]
[ BY {SESSION | ACCESS} ]
[ WHENEVER [NOT] SUCCESSFUL ]
오브젝트 감사
AUDIT statement [, statement ]...
ON {[ schema. ] object | DEFAULT }
[ BY { SESSION | ACCESS }]
---------
[ WHENEVER [NOT] SUCCESSFUL ]
구문에서:
statement 감사할 SQL문 유형, 또는 스키마 오브젝트
system_priv 감사할 시스템 권한
schema.schema-object 감사를 위해 선택된 오브젝트
DEFAULT 지정한 오브젝트 옵션을 이후에 생성될 오브젝트에 대한
디폴트오브젝트 옵션으로 설정
21-13
user 리스트내의 사용자만 감사하도록 지정(이 절이 생략되면 모든
사용자의 작업이 감사됩니다.)
BY SESSION 동일한 유형의 SQL문이 아무리 많이 나오든 상관없이 오라클이 각
세션에 대해 데이타베이스오브젝트당 하나의 레코드만을 감사기록에
삽입하도록 합니다.
(DDL은 제외하고,기본값입니다.)
BY ACCESS 감사할 명령문이 나올때마다 레코드를 삼사 기록으로 삽입하도록 합니다.
(DDL문의 경우 오라클은 접근할 때마다 감사합니다.)
WHENEVER SQL문의 수행이 성공했을때만 감사할 것인지,실패했을때만
감사할것인지를 지정 (기본값은 성공과 실패모두의 경우 감사하는 것입니다.)
주
* 감사기록은 실행단계(pharse)동안 생성되므로 TABLE OR VIEW DOES NOT EXIST 같은
구문분석 에러는 WHENEVER UNSUCCESFUL 절을 사용하여 발견해낼 수 없습니다.
* AUDIT 명령으로 지정된 명령문감사와 권한 감사 옵션은 이후 세션에만 적용될 뿐
현재의 세션에는 적용되지 않습니다.
이와는 대조적으로 스키마 오브젝트에 대해 변경을 하면 감사옵션은 즉시 현재의
세션에 영향을 주게 됩니다.
스키마 오브젝트 감사는 특정 스키마 오브젝트에 대해 수행되는 명령문을 선택적으로
감사합니다.
ALL은 해당 오브젝트의 유형에 적용가능한 모든 옵션을 감사하도록 스키마오브젝트
감사 옵션으로 사용될 수 있습니다.
테이블 ,뷰,시퀀스,독립저장프로시저와 함수,패키지,스냅샷,라이브러리,그리고
디렉토리를 참조하는 명령문을 감사할 수도 있습니다.
패키지내의 프로시저는 개별적으로 감사할 수 없습니다.위의 표는 오브젝트유형단위로
사용가능한 감사옵션을 보여줍니다.
클러스터나 데이타베이스 링크,인덱스,또는 동의어를 참조하는 명령문은 직접감사할
수 없습니다.
하지만 기본 테이블에 영향을 주는 작업을 감사하여 이들 스키마 오브젝트를
간접적으로 접근 감사할 수 있습니다.
스키마 오브젝트 감사옵션은 데이타베이스의 모든 사용자에 대해 항상 설정됩니다.
특정 사용자들에 대해 설정될 수 없습니다.
감사하기 위해 선택한 오브젝트는 반드시 자신의 스키마에 있거나 AUDIT ANY
시스템권한을 가지고 있어야만 합니다.
21-15
스키마 오브젝트 감사옵션 DEFAULT
AUDIT명령의 DEFAULT옵션을 사용하여 아직 생성되지 않은 스키마 오브젝트에 대한
감사 옵션을 지정할 수 있습니다.
일단 이들 디폴트감사 옵션을 설정하면 이후에 생성되는 모든 스키마오브젝트는
자동적으로 이 옵션으로 감사를 받게 됩니다.
뷰에 대한 디폴트감사옵션은 항상 뷰의 기본테이블들에 대한 감사옵션의
합집합이라는 사실을 명심하십시요.
디폴트감사옵션을 변경하더라도 이미 생성된 스키마 오브젝트에 대한 감사 옵션은
그대로 남아 있습니다.
기존 스키마 오브젝트에 대한 감사 옵션을 변경하려면 AUDIT명령의 0N절에
오브젝트를 지정하는 방법밖에 없습니다.
DEFAULT 감사 옵션을 설정하려면 AUDIT STSTEM 권한이 있어야 합니다.
감사옵션보기
데이타딕셔너리뷰 설명
ALL_DEF_AUDIT_OPTS 디폴트감사 옵션
DBA_STMT_AUDIT_OPTS 명령문 감사 옵션
DBA_PRIV_AUDIT_OPTS 권한 감사 옵션
DBA_OBJ_AUDIT_OPTS 스키마오브젝트감사 옵션
위의 나열된 데이타 딕셔너리뷰는 감사 옵션에 대한 정보를 가지고 있습니다.
감사중인 것을 알아보려면 이들 뷰를 질의합니다.
예를 들어 다음질의는 설정되어 있는 권한 감사 옵션을 보여줍니다.
SVRMGR>SELECT * FROM DBA_PRIV_AUDIT_OPTS;
USER_NAME PRIVILEGE SUCCESS FAILURE
----------- ---------------- ------------- ----------
SCOTT CREATE TABLE BY ACCESS BY ACCESS
SYSTEM ALTER ANY TABLE BY ACCESS NOT SET
SCOTT ALTER ANY TABLE BY ACCESS NOT SET
SYSTEM ALTER ANY PROCEDURE BY ACCESS NOT SET
SCOTT ALTER ANY PROCEDURE BY ACCESS NOT SET
GRANT ANY PRIVILEGE BY ACCESS BY ACCESS
6 ROW SELECTED.
감사 옵션 Disable
NOAUDIT user WHENEVER SUCCESSFUL;
NOAUDIT create tabel BY scott;
NOAUDIT LOCK ON emp;
구문
AUDIT 명령으로 선택한 감사를 중지시키려면 NOAUDIT 문을 사용하십시요.
NOAUDIT { statement | system_priv}
[,{tatement | system_priv}]...
[BY user [,user]...]
[WHENEVER [NOT]SUCCESSFUL]
NOAUDIT statement [,statement]...
ON {[schema.]object |DEFAULT}
[WHENEVER [NOT] SUCCESSFUL]
주
NOAUDIT 문은 AUDIT문의 효과를 없애줍니다.NOAUDIT문이 AUDIT 문과 동일한 구문을
가져야 한다는 것과 특정문장의 효과를 없앨뿐이라는 사실을 명심하십시요.
그러므로 한 AUDIT문(문장A)이 특정 사용자에 대한 감사를 enable 하고 두번째 문
(문장B)이 모든 문장 B의 효과만을 없애줍니다.
하지만 문장A 는 여전히 효과를 가지고있어 문장 A 가 지정한 사용자를 계속 감사합니다.
감사기록 (AUDIT TRAIL)
*명령문 감사 ,권한 감사, 그리고 오브젝트 감사에 의해 생성
된 기록을 저장합니다.
* 감사 기록은 SYS.AUD$ 데이타딕셔너리
테이블이나 OS 감사기록에 저장됩니다.
*감사 기록의 각 레코드는 다음을 포함합니다.
-명령문을 실행한 사용자
-발효된 명령문(작업코드)
-명령문에서 참조한 오브젝트
-명령문이 발효된 날짜와 시간
감사기록은 명령문감사,권한 감사,그리고 스키마오브젝트감사에 의해 생성된 레코드를
저장합니다.
데이터베이스관리자는 감사 기록과 관련된 데이타딕셔너리뷰 중 하나로부터
SELECT하여 감사중에 생성된 정보를 검사합니다.
이정보는 미심쩍은 작업을 조사하거나 데이타베이스 작업을 모니터하는데 사용됩니다.
--감사 기록 (AUDIT TRAIL)의 위치
감사 기록 (AUDIT RECORDS)은 데이타베이스 감사 기록 이라불리는 데이타딕셔너리
테이블이나 운영체제감사기록 에 저장될수 있습니다.
데이타베이스감사 기록은 SYS.AUD$ 데이타딕셔너리테이블입니다.
이 테이블의 정보를 사용하는데 도움이 되도록 몇몇 뷰가 미리 정의되어 제공됩니다.
감사기록의 내용
감사기록의 각 레코드는 다음을 포함합니다.
*사용자 이름
*세션 식별자
*터미널 식별자
*접근한 스키마오브젝트의 이름
*수행되거나 시도한 작업(작업코드)
*작업의 결과코드
*날짜와 시간스탬프(STAMP)
*사용된 시스템권한
감사결과 보기
-----------------------------------------------------------
DBA_AUDIT_TRAIL | 모든 감사 기록 엔트리
-----------------------------------------------------------
DBA_AUDIT_EXISTS | AUDIT EXISTS/NOT EXISTS에 대한
| 기록
-----------------------------------------------------------
DBA_AUDIT_OBJECT | 스키마 오브젝트와 관련된 기록
-----------------------------------------------------------
DBA_AUDIT_SESSION | 모든 접속과 접속 해제 엔트리
-----------------------------------------------------------
DBA_AUDIT_STATEMENT | 명령문 감사 기록
-----------------------------------------------------------
위의 표는 감사 기록으로 부터 얻을 수 있는 정보를 보여 줍니다. 다음은 명령문들이
실행될 때 생성되는 감사 기록을 봉여 주는 예입니다.
SVRMGR> select username, obj_name, action_name, priv_used
FROM sys.dba_audit_object
WHERE owner = 'SCOTT'
and obj_name ='EMP';
USERNAME OBJ_NAME ACTION_NAME PRIV_USED
------------- -------------- --------------- --------------
SCOTT EMP SESSION REC
ADAMS EMP SESSION REC
SYSTEM EMP SESSION REC DELETE ANY TABLE
3 row selected.
이런 결과는 데이터 베이스에서 특정 이벤트가 발생할 때에만 얻어 집니다.
감사 지침 사항
. 핵심 감사
- 가능한 경우 오브젝트 감사
- 지정된 사용자만
- 세션 단위로
- 성공적인 경우에만, 또는 실폐한 경우에만
. 감사 기록 유지
- 감사 기록의 성장 모니터
- 허가 받지 ㅇ않은 접근으로부터 감사 기록 보호
- OS 감사 파일 정리
핵심 감사
우선 감사 요구 사항을 식별하고 요구 사항에 부응하도록 최소 감사 옵션을 설정하여
감사를 제한 하십시오.
발생되는 엔트리 수를 줄이는 것이 가능하다면 오브젝트 감사가 사용되어야 합니다.
명령문감사, 또는 권한 감사가 사용되어야 한다면 다음 설정이 감사 발생을
최소화 할 수 있습니다.
. 감사할 사용자 지정
. 접근 단위가 아닌 세션 단위로 감사
. 성공한 경우나 실패한 경우 중 어느 한쪽만 감사
시스템 테이블 스페이스 밖으로 감사 기록 이동
새로운 레코드가 데이터베이스 감사 기록에 삽입됨에 따라 AUD$테이블이 한없이 커질수
있습니다.
AUD$테이블을 삭제할 수는 없다 할 지라도 테이블 내의 행이 오라클이 실행되는데
필요한 것이 아니라 정보를 위한 것이므로 테이블에서 삭제를 하거나 잘라 버릴
수는 있습니다.
AUD$ 테이블은 자라난 후 줄어들기 때문에 시스템 테이블스페이스 밖에 저장 되어야
합니다.
AUD$를 AUDIT_TAB테이블스페이스로 이동하려면 다음과 같이 하십시오.
1. 감사가 현재 disable 되어 있는지 확인 합니다.
2. CREATE TABLE aud$_temp
TABLESPACE AUDIT_TAB
AS SELECT * FROM AUD$ WHERE 1=2;
3. DROP TABLE AUD$;
CREATE INDEX I_aud1 ON AUD$(sessionid, ses$tid)
TABLESPACE AUDIT_IDX;
6 GRANT delete ON aud$ TO DELETE_CATALOG_ROLE
7 인스턴스에 대한 감사를 enable합니다.
감사기록의 성장 모니터
감사 기록이 꽉 차면 더 이상의 감사 기록이 삽입도리 수 없어 감사되는 명령문이
성공적으로 수행되지 않을 것입니다.
감사 되어야 할 명령문을 실행한 모든 사용자에게 에러가 리턴될 것입니다.
이들 명령문들이 수행될 수 있으려면 감사 기록 내의 일부 공간을 비워야 합니다.
잘 제어한 스키마 오브젝트 감사는 감사 기록의 성장을 제어하기에 효과적인 방법입니다.
감사 기록이 너무 빨리 자라나지 않도록 하려면;
. 필요할 때만 감사를 enable하십시오.
. 어떤 감사 옵션을 지정할 것이닞 주의 깊게 선택하십시오.
. 스키마 오브젝트 감사를 잘 제어 하십시오. 사용자는 자신이 소유한 오브젝트에
대한 감사를 켤 수 있습니다.
. audit any 권한도 사용자로 하여금 감사를 켤 수 있게 해 줍니다. 그러무로 되도록
audit any 권한을 GRANT한는 것을 삼가하십시오.
DELETE나 TRUNCATE명령으로 감사 기록(audit records)을 주기적으로 제거하십시오.
감사 기록 보호
감사 정보가 추가되거나 수정, 또는 삭제되지 않도록 감사 기록을 보호해야 할 경우라면
다음 명령을 사용하십시오.
AUDIT delete ON sys.aud$ BY ACCESS;
허가받지 않은 삭제로부터 감사 기록을 보호하려면 DBA만이 DELETE_CATALOG_ROLE롤을
갖도록 하십시오.
22.국가 지원별 언어(NLS:National Language Support)
목적
. 데이타베이스에 대한 Character Set과 국가 Character Set 선택
. 초기화 파라미터, 환경변수, 그리고 ALTER SESSION 명령을 사용하여 언어종속
(language-dependent) 작업 방식을 지정
. 여러 유형의 NLS파라미터 사용
. 언어 종속 응용 프로그램 작업 방식에의 영향 설명
. NLS 사용에 대한 정보 얻기
22-1 NLS 특성
. 언어지원
. 데리토리 지원
. Character Set 지원
. 언어 정렬
. 메시지 기원
. 날짜와 시간 형식
. 숫자 형식
. 통화 형식
NLS(National Language Support)는 데이타베이스 유틸리티와 에러 메시지,정렬 순서,
날짜, 시간, 통화, 숫자, 그리고 달력 규약이 해당 국가의 언어에 맞게 자동적으로 변경
되도록 합니다. 오라클은 현재 45개 언어, 60개 테리토리, 60개 언어 정렬, 그리고 많은
암호화도니 character Set을 지원합니다.
언어 종속 작업은 클라이언트와 서버 양측의 많은 수의 파라미터와 환경 변수에 의해
제어됩니다. 서버와 클라이언트는 같은 위치, 또는 다른 위치에서 수행될 수 있습니다.
클라이언트와 서버가 서로 다른 character Set 을 사용하는 경우 오라클은 자동적으로
character set변환을 처리합니다.
NLS(National Language Support)
.서유럽,동유럽,중유럽,동아시아, 그리고 동남아시아 언어를 포함하는 사용자의 언어의
데이터와 상호 작용하고, 저장하고,처리하고, 읽어 들입니다.
.서로 다른 나라와 지역은 데이터 형식에 직접적인 영향을 주는 서로 다른 문화적 규약을
만들어 냅니다.
.단일 바이트, 다중 바이트 , 그리고 고정 폭(fixed-width) 암호화 character set을
포함하는 많은 문자 암호화 체계가 지원됩니다.
.오라클은 언어에 따른 정확한 정렬을 위해 많은 언어 정렬을 제공합니다.
.데이터베이스 유틸리티와 에러 메시지는 지원되는 해당 언어로 표시됩니다. 오라클
제품은 26개 언어로 번역되고 있습니다.
.날짜와 시간 형식은 시, 일, 월 그리고 년을 위한 ISO규약을 따라 표현될 수 있습니다.
.Gregorian,Japanese,Imperial,그리고 Thai Buddha 등의 국가별 달력이 지원됩니다.
.수치 데이터는 적절한 지역 형식에 따라 표현됩니다.
.통화 기호는 지역 경제와 ISO규약을 반영합니다. 대변(credit)과 차변(debit)기호도
지역에 따라 다릅니다.
22-2 여러가지 유형의 암호화 체계
오라클은 여러 클래스의 문자 암호화 체계를 지원합니다.
. 단일 바이트 Character set
- 7-비트
- 8-비트
-가변 폭(Varying-width) 다중 바이트
character set
- 고정 폭(Fixed-width) 다중 바이트
character set
- 유니코드(UTF8, AL24UTFFSS)
문자 암호화 체계는 컴퓨터나 터미널이 출력하고 받아들일 수 있도록 문자에 대응하는
숫자코드를 지정합니다.
문자 암호화 체계는 데이터를 의미를 가진 기호로 번역해 터미널에서 호스트 기계로
보낼 때 사용됩니다.
오라클은 여러가지 클래스의 암호화 체계를 제공합니다.
. 단일 바이트
. 가변 폭
. 고정 폭
. 유니코드
단일 바이트 Character Set
단일 바이트 character set 에서 각 문자는 한 바이트를 차지합니다. 단일 바이트
7비트 암호화체계는 128 문자를 정의할 수 있으며 단일 바이트 8비트 암호화 체계는
256를 정의할 수 있습니다.
22-7. 단일 바이트 체계의 예
7비트 character set :
ASCII 7비트 미국어(US7ASCII)
8비트 character set :
. ISO8859-1 서유럽어(WE8ISO8859PI)
. EBCDIC 코드 페이지 500 8 비트 서유럽어(WE8EBCDIC500)
. DEC 8 비트 서유럽어(WE8CDIC)
가변폭 다중 바이트 character set
다중 바이트 character set은 문자 하나를 한 바이트 이상을 써서 표현한다.
다중 바이트 character set은 일반적으로 아시아 언어를 지원하기 위해 사용됩니다.
일부 다중 바이트 암호화 체계는 단일 바이트인지 한 문자를 표현하는 일련의
바이트 중의 일부인지를 나타내기 위해 최상위 비트 값을 사용합니다.
또 다른 문자 암호화 체계는 단일 바이트 문자와 다중 바이트 문자를 구별합니다.
디바이스(device)가 보낸 shift-in 코드를 만날 때까지의 바이트가 2바이트
문자라는 것을 표시합니다.
가변 폭 다중 바이트 체계의 예 :
. Japanese Extended UNIX 코드(JEUC)
. Chinese GB2312-80(CGB2312-80)
고정 폭 다중 바이트 character set
고정 폭 character set은 각 문자에 바이트 수가 고정된 형식이라는 것을 제외하면
다중 바이트 character set과 비슷한 지원을 제공합니다.
이것은 각 문자를 균일한 바이트 크기로 표현한다는 장점을 제공합니다.
고정 폭 다중 바이트 character set의 예 :
. JA16EUCFIXED, 16비트 일본어(JA16EUC의 고정 폭 부분 집합)
. JA16SJISFIXED, 16비트 일본어(JA16SIJS의 고정 폭 부분 집합)
유니코드 character set
유니코드는 전세계적인 문자 암호화 표준으로 기술 용어와 출판에 사용되는 문자를
포함하여 컴퓨터 사용을 위한 모든 문자를 표현할 수 있습니다.
유니코드 버전 2.0은 총 38,885문자를 표현할 수 있습니다.
유니코드 문자 목록은 많은 다른 암호화 형식으로 표현할 수 있습니다.
UCS2(Universial Character Set;2바이트 형)는 2바이트, 고정 폭 형식이고,
UTF8(Universial Character Set Transformation Format)은 다중 바이트,
가변 폭 형식입니다.
UCS2와 UTF8은 유니코드 1.1 또는 유니코드 2.0의 같은 문자 목록을 암호화 합니다.
(Unicode 1.1 또는 Unicode 2.0)
오라클 7은 UTF8(character set: AL24UTFFSS)로 암호화 된 유니코드 1.1을 사용합니다.
오라클 8은 UTF8(character set: UTF8)로 암호화된 유니코드 2.0을 추가 제공합니다.
UTF8의 장점은 같은 단일 바이트 암호화를 사용하는 ASCII를 포함하고 있다는 것입니다.
22-9. 데이터베이스의 Character Set과 국가 Character Set
데이터베이스 character set 국가 character set
=================================================================================
생성시 정의 생성시 정의
---------------------------------------------------------------------------------
재생성하지 않고는 변경할 수 없다. 재생성하지 않고는 변경할 수 없다.
---------------------------------------------------------------------------------
CHAR,VARCHR2,CLOB,LONG 유형의 데이터 열 NOCHAR,NVARCHAR2,NCLOB 유형의 데이터 열
저장 저장 고정 폭과 가변 폭 다중 바이트
---------------------------------------------------------------------------------
가변 폭 character set을 저장할 수 있다. character set을 저장할 수 있다.
---------------------------------------------------------------------------------
CREAT DATABASE문은 CHARACTER SET절과 추가 옵션 절 NATIONAL CHARACTER SET을
가지고 있어 데이터베이스 character set을 선언할 수 있습니다.
두 character set은 데이터베이스가 생성된 후 변령할 수 없습니다.
NATIONAL CHAR SET절이 없으면 국가 character set은 디폴트로 데이터베이스
character set과 동일 하게 설정이 됩니다.
데이터베이스 character set이 SQL과 PL/SQL 원본 코드를 식별하고 보관하는데
사용되므로 플랫폼의 고유언어가 무엇이든 간에 그 안에 EBCDIC이나 7비트 ASCII를
포함하고 있어야만 한다. 그러므로 고정 폭 다중 바이트 character set을
데이터베이스 character set으로 사용하는 것이 불가능하며 국가 character set으로
사용할 수 있을 뿐입니다.
데이터 유형 NCHAR, NAARCHAR2, 그리고 NCLOB은 기본 유형인 CHAR, VARCHR2
그리고 CLOB의 변형으로서 열을 선언할 때 사요되도록 제공됩니다.
이들이 데이터 베이스 character set이 아니라 국가 character set을 사용하여
저장된다는 것을 알아 두십시오.
. 국가 character set을 사용하는 고정길이 문자 이이템을 선언하려면 데이터 유형사양
NCHR[size]를 사용
. 국가 character set을 사용하는 가변길이 문자 아이템을 선언하려면 데이터 유형사양
NVARCHAR2(size)를 사용
. 국가 character set을 사용하는 고정 폭 다중 바이트 문자를 포함하는 큰 문자
오브젝트(CLOB)를 선언 하려면 데이터 유현 사양 NCLOB(size)를 사용
주>
. 오라클은 LONG데이터 유형에 대해서는 국가 character set을 지원하지 않는다.
. character set암호화에서 고정 폭이냐, 가변 폭이냐 하는 문제는 CHAR,VARCHAR2유형의
고정 길이이냐,가변길이이냐 하는 것은 다른 문제이다.
전자는 문자열의 각 문자가 필요로 하는 바이트 수를 말하고 후자는 문자열에
할당되는 총 공간을 말합니다. 고정 폭, 또는 가변 폭 character set은 고정길이
유형(CHAR 나NCHAR)의 열에도 사용될 수 있고 가변 길이 유형 (VARCHAR2나 NVARCHAR2)
에도 사용될 수 있다.
지침 사항
.밀접하게 관련된 데이터베이스 charater set과 국가 character set을 선택하십시오.
.고정 폭 character set을 사용하면 문자열 작업이 더 빨라질 수 있습니다.
.가변 폭 character set은 공간을 더 효율적으로 사용합니다.
데이터베이스 character set 과 국가 character set은 서로 밀접한 관련을 가져야만 한다.
예를 들어 일본 소비자는 JA16EUC를 데이터베이스 character set으로, JA16EUCFIXED를
국가Character set 으로 선택할 것입니다.
22-12. 언어 종속 기능 지정
NLS 파라미터를 지정하는데는 세가지 방법이 있습니다.
. 서버 측의 초기화 파라미터로 디폴트 서버NLS 환경 지정(이 디폴트 설정은 클라이언트
측에 영향을 주지 않습니다.)
. 클라이언트에 대한 환경 변수로 서버의 디폴트 설정을 무효화하는 지역 종속 기능을
지정
. ALTER SESSION 파라미터로 세션, 또는 서버에 대한 디폴트 설정 무효화
22-13
.서버에 대한 언어 종속 기능 지정
- 메시지 용 언어
- 일과 월 이름
- AD, BC, AM, PM 용 기호
- 기본 정렬 방식
. NLS_TERRITORY 는 다음을 지정합니다.
- 날짜와 주 셈하는 방식
- 기본 날짜 형식, 십진 문자, 자릿수 구문자
(group separator), 그리고 기본 ISO 와 지역 통화 기호
.초기화 파라미터 NSL_LANGUAGE는 다음과 같은 언어 조옥 규약에 대한
값들을 정의 합니다.
- 오라클 메시지에 사용될 언어
- 날과 달의 이름과 그 약칭에 사용될 언어
- am, pm, AD, BC 과 같은 뜻을 가진 해당 언어의 기호
- 문자 데이터의 기본 정렬 시퀀스
.초기화 파라미터 NSL_TERRITORY는 다음과 같은 테리토리 종속 규약에
대한 값들을 정의 합니다.
- 기본 날짜 형식
- 십진 문자와 자릿수 구분자
- 해당 지역 통화 기호
- ISO 통화 심볼
- ISO 주 계산법
- 주(week)의 시작일
주
the Netherlands처럼 테리토리 이름에 공간이 포함되어 있으면 테리토리
이름은 "The Nehterlands" 처럼 이중 인용표를 사용해야 합니다.
22-14
종속 언어와 테리토리 기본 값
---------------------------------
파라미터 값
---------------------------------
NLS_LANGUAGE AMERICAN
NLS_DATE_LANGUAGE AMERICAN
NLS_SORT BINARY
---------------------------------
NLS-TERRITORY AMERICA
NLS_CURRENCY $
NLS_ISO_CURRENCY AMERICA
NLS_DATE_FORMT DD-MON-YY
NLS_NUMBERIC_CHARACTERS ,.
---------------------------------
초기화 파라미터 NSL_LANGUAGE는 다음 파라미터의 기본값을 결정
합니다.
----------------------------------------------------------------
컬럼 설명
----------------------------------------------------------------
NSL_DATE_LANGUAGE 날과 달 이름과 그 약칭, 그리고 다른 날짜
형식 구성 요서의 철자에 대한 언어를 명시
적으로 변경합니다.
----------------------------------------------------------------
NSL_SORT 오라클 서버가 문자 값을 정력할 때 사용하
는 언어 정렬 시퀀스를 변경합니다. (정렬값
BINARY나 언어 정력 시퀀스 이름이어야 합니
다
----------------------------------------------------------------
22-15
NLS_TERRITORY는 다음 파라미터의 기본값을 결정합니다.
---------------------------------------------------------------
컬럼 설명
---------------------------------------------------------------
NLS_CURRENCY 새로운 지역 통화 심볼을 명시적으로 지정
합니다.
---------------------------------------------------------------
NLS_ISO_CURRENCY ISO 통화 기호를 사용해야만 하는 테리토리
를 명시적으로 지정합니다.
---------------------------------------------------------------
NLS_NUMBERIC_CHARCTERS 새 십진 문자와 자릿수 구분자를 명시적으로
지정합니다.
----------------------------------------------------------------
22-16
세션에 대한 언어 종속 기능 지정
.환경 변수:
- NLS_LANG=_.
.추가 환경 변수:
- NLS_DATE_FORMAT
- NLS_DATE_LANGUAGE
- NLS_SORT
- NLS_NUMBERIC_CHARACTERS
- NLS_CURRENCY
- NLS_ISO_CURRENCY
- NLS_CALENDAR
22-17
환경 변수 NLS_LANG
NLS_LANG 환경변수로 각 사용자에 대한 기본 NLS 기능을 무효화 할수
있습니다.
NLS_LANG 의 값은 NLS초기화 파라미터의 값을 모두 무효화 합니다.
각 구성 요소는 NLS 기능의 부분을 제어합니다.
NLS_LANG=.
예:
NSL_LANG=GREMAN_GERMANY.WE8ISO8859P1
여기서:
language NLS_LANGGUAGE 값을 무효화하고 NLS_LANGUAGE와 똑같은
특성들을 제어합니다.
territory NLS_TERRITORY 값을 무효화하고 NLS_TERRITORY와 똑같은
특성들을 제어합니다.
characterset 클라이언트 응용프로그램(보통 사용자의 터미널에 있는)
이 사용하는 문자 암호화 체계를 지정합니다.
NLS_LANG은 클라이언트 터미널의 문자 암호화 체계를 정의 합니다.
서로 다른 클라이언트는 서로 다른 암호화 체계를 사용할 수 있습니다. 클
라이언트와 서버간에 전달되는 데이터는 자동적으로 두 암호화 체게 간에
서 변환됩니다. 데이터베이스 암호화 체계는 클라이언트 암호화 체계 전부
를 포함해야 합니다. 이때의 변환은 클라이언트 응용 프로그램에게는 투명
하게(TRANSPARENT)수행됩니다.
추가 환경 변수
모든 nls 초기화 파라미터가 환경 변수로 사용 가능하여 각 클라이언트마다
각각 NLS 특성을 지정하는 것이 가능합니다.
Gregorian,Persian,Thai Buddha 같은 오라클이 사용하는 달려 시스템을 지정
하기 위해 NLS_CALENDAR를 사용할 수 있습니다.
다음 변수는 클라이언트 환경에서만 설정될 수 있습니다.
NLS_CRENDIT,NLS_DEBIT,NLS_DISPLAY,NLS_LANG,NLS_LIST_SEPARATOR,NLS_MONETARY
,NLS_NCHAR
22-18
주
. 이들 파라미터에 대한 자세한 설명은 오라클 Manual을 참조
. 환경 변수 ORA_NLS33("데이터베이스 생성" 장을 참조하십시오.)이 설정되지
않으면 데이터베이스를 디폴트 character set 인 US7ASCII로 생성할 수 밖에
없습니다. UNIX 에서는 ORA_NLS가 다음과 같이 설정되어 있어야 합니다.
. Windows NT 에서는 NLS_LANG 와 ORA_NLS33과 같은 파라미터는 설치시 자동으로
성정되어 HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE 폴더의 레지스트리에 저장됩
니다.
<22-19>
세션에 대한 언어 종속 기능 지정
. ALTER SESSION SET
. NLS_DATE_FORMAT='DD.MM.YYYY';
. DBMS_SESSION.SET_NLS("NLS_DATE_FORMAT',
'''DD.MM.YYYY''');
주) 세션에 대한 각 NLS특성은 ALTER SESSION
명령으로 변경할 수 있습니다. 클라이언트와 서버 양측에서
모두 설정할 수 있는 환경 변수들은 ALTER SESSION명령으로
수정할 수 도 있습니다. 위의 예에서는 날짜 형식이 세션에
대해 변경됩니다.
SQL*Plus같은 도구는 환경 변수를 읽어 대응되는 ALTER SESSION
명령 뿐만 아니라 파라미터의 이름과 값을 취하는 데이터베이스
패키지 DBMS_SESSION.SET_NLS도 있습니다.
<22-20>
정렬
. 오라클은 언어 정렬을 제공함
. NLS_SORT은 정렬 유형을 지정
. NLSSORT 함수는 언어 비교를 반영
ALTER SESSION SET NLS_SORT=GERMAN;
SELECT letter FROM letters ORDER BY letter;
letter
......
a
z
주) 이진 정렬은 문자를 암호화하는데 사용된 이진값으로 정렬하는
전형적인 정렬방식임. 문자의 알파벳 위치는 언어에 따라 다를 것임.
예 : 독일어에서 이진 정렬을 하면"a(위에 점 두개있는 a)"는
"b"보다는 앞이지겠지만 "z"보다는 뒤로 정렬된다.
이진 정렬의 한계를 극복하기 위해 오라클은 NLS_SORT 파라미터로
설정하는 언어 정렬을 제공함.
다음예는 언어정렬기능을 보여줌.
SQL> ALTER SESSION SET NLS_SORT=BINARY;
Session altered.
SQL> SELECT letter FROM letters ORDER BY letter;
L
-
a
b
c
z
u ( 위에 점 두개있는 u)
a ( 위에 점 두개있는 a)
6 rows selected.
<22-21>
SQL> ALTER SESSION SET NLS_SORT=GERMAN;
Session altered.
SQL> SELECT letter FROM LETTERS ORDER BY 1;
L
-
a ( 위에 점 두개있는 a)
u ( 위에 점 두개있는 u)
a
b
c
z
6 rows selected.
이진 값이 아닌 언어 규약에 따라 비교하려면 NLSSORT 함수를 사용할
수 있다.
SQL> SELECT letter FROM letters WHERE letter < 'z';
L
-
a
b
c
SQL> SELECT letter FROM letters
2>WHERE NLSSORT(letter) < NLSSORT ('z');
L
-
a
b
a ( 위에 점 두개있는 a)
c
u ( 위에 점 두개있는 u)
<22-22>
SQL 함수에서의 NLS 파라미터 사용
SELECT TO_CHAR(hiredate, 'DD.MM.YYYY'
'NLS_DATE_LANGUAGE=GERMAN') FROM emp;
SELECT ename, TO_CHAR(sal, '9G999D99',
'NLS_NUMERIC_CHARACTERS=GERMAN') FROM emp;
주) SQL 문자 함수는 단일 바이트와 다중 바이트 문자를 지원합니다.
일부 SQL 함수는 명시적으로 NLS파라미터가 자신의 파라미터 리스트의
일부로 지정되는 것을 허용합니다. 그러므로 SQL 함수는 NLS 환경에
의해 지정된 기능을 무효화할 수 있습니다.
<22-23>
SQL 함수에서 NLS파라미터를 사용하는 예
SVRMGR> SELECT TO_CHAR(hiredate, 'dd.mm.yyyy',
2> 'NLS_DATE_LANGUAGE=GERMAN')
3> FROM emp;
TO_CHAR(HIR
-----------
17.dez.1980
20.feb.1981
22.feb.1981
02.apr.1981
28.sep.1981
01.mai.1981
09.jun.1981
19.apr.1987
17.nov.1981
08.sep.1981
23.mai.1987
03.dez.1981
03.dez.1981
23.jan.1982
14 rows selected.
<22-24>
SQL 함수에서 NLS파라미터를 사용하는 예(계속)
SVRMGR> SELECT ename,
2> TO_CHAR'sal, '99G999D99', 'NLS_NUMERIC_CHARACTERS='',.''')
3> FROM emp;
ENAME TO_CHAR(SA
------- ----------
SMITH 800,00
ALLEN 1.600,00
WARD 1.250,00
JONES 2.975,00
MARTIN 1.250,00
BLAKE 2.850,00
CLARK 2.450,00
SCOTT 3.000,00
KING 5.000,00
TURNER 1.500,00
ADAMS 1.100,00
JAMES 950,00
FORD 3.000,00
MILLER 1.300,00
14 rows selected.
22-25 다음 SQL 함수는 NLS 파라미터를 사용합시다.
함수 NLS 파라미터
-----------------------------------------------
TO_DATE NLS_DATA_LANGUATE
NLS_CALENDAR
TO_NUMBER NLS_NUMBERICCHARACTERS
NLS_CURRENCY
NLS_ISO_CURRENCY
TO_CHAR NLS_DATE_LANGUATE
NLS_NUMERIC_CHARACTERS
NLS_CURRENCY
NLS_ISO_CURRENCY
NLS_CALENDAR
NLS_UPPER, NLS_LOWER, NLS_SORT
NLS_INITCAP, NLSSORT
여러 형식 마스크 구성 요소가 TO_CHAR, TO_DATE, 그리고 TO_NUMBER 등의 함수에
대해 정의되어 있습니다.
숫자 형식 마스크 구성 요소
. "D"는 십진 구분자
. "G"는 자릿수(천) 구분자
. "L"은 지역 통화 심볼
. "C"는 지역 ISO 통화 심볼
. "RM, rm"은 로마식 달 번호
. "IW"는 ISO 주 번호
. "IYYY,IYY,IY"와 "I"는 ISO 년
22-26 NLS를 사용한 임포트와 데이터 로
. 데이터는 임포트되는 동안 NLS_LANG으로부터 데이터베이스 character set으로
변환됩니다.
. LOADER:
- Conventional : 데이터는 NLS_LANG으로 지정된 세션 character set으로 변환됩니다.
- DIRECT : 데이터는 직접 데이터베이스 character set으로 변환됩니다.
임포트 동안 데이터는 자동적으로 NLS_LANG 파라미터에 의해 결정된 대로 지정된 세션에
대한 character set으로 변환됩니다. 데이터는 세션 character set으로 변환된 후
데이터베이스 character set 으로 다시 변환됩니다.
이 말은 NLS_LANG이 익스포트 파일의 character set으로 설정되어야만 한다는
EMT입니다. SQL*Loader도 데이터를 데이터 파일 character set 으로부터 데이터베이스
character set으로 변환할 수 있습니다.
Conventional path를 사용하면 데이터는 그 세션에 대해 NLS_LANG파라미터가 지정한 세션
character set 으로 변환됩니다. Direct path의 경우에는 데이터가 직접 데이터베이스
character set 으로 변환됩니다. SQL*Loader의 콘트롤 파일은 데이터 파일이 번역되는
방법을 보여줍니다.
Character set파라미터는 각 데이터 파일에 어떤 character set이 사용되고 있는지를
알려 줍니다.
예) $sqlldr contron=utllcase.c시 characterset=We8ISO9959p1
22-27 Character Set에 대한 정보 얻기
NLS_DATABASE_PARAMETERS
- PARAMETER
(NLS_CHARACTER,
NLS_NCHAR_CHARACTERSET)
- VALUE
다음 질문을 사용하여 데이터베이스 character set과 국가 character set을 보십시오
SVGMEG> SELECT parameter, value FROM nls_database_parameters
2> WHERE parameter LIKE '%CHARACTERSET%';
PARAMETER VALUE
------------------------- ----------------------------
NLS_CHARACTERSET WE8ISO8859p1
NLS_NCHAR_CHARACTERSET US7ASCII
2 rows selected.
22-28 NLS 설정에 대한 정보 얻기
. NLS_INSTANCE_PARAMETERS
- PARAMETER (명시적으로 설정된 NLS 초기화 파라미터)
- VALUE
. NLS_SESSION_PARAMETERS
- PARAMETRE (NLS 세션 파라미터)
- VALUE
init.ora 파일에 명식적으로 설정된 파라미터의 값만을 나타내는 뷰입니다.
SVRMGR> SELECT * FROM nls_instance_parameters;
PARAMETER VALUE
------------------------- ----------------------------
NLS_NALGUAGE AMERICAN
NLS_TERRITORY AMERICA
NLS_SORT
NLS_DATE_LANGUAGE
NLS_DATE_FORMAT
NLS_CURRENCY
NLS_NUMERIC_CHARACTERS
NLS_ISO_CURRENCY
8 row selected.
세션 파라미터를 보여주는 뷰입니다.
SVRMGR> SELECT * FROM nls_session_parameters;
PARAMETER VALUE
------------------------- ----------------------------
NLS_NALGUAGE AMERICAN
NLS_TERRITORY AMERICA
NLS_CURRENCY $
NLS_ISO_CURRENCY AMERICA
NLS_NUMERIC_CHARACTERS . ,
NLS_CALENDAR GREGORIAN
NLS_DATE_FORMAT DD-MON-YY
NLS_DATE_LANGUAGE AMERICAL
NLS_SORT BINARY
9 row selected.
22-30 NLS 설정에 대한 정보 얻기
. V$NLS_VALID_VALUES
- PARAMETER
(LANGUAGE, SORT, TERRITORY, CHARACTERSET)
- VALUE
. V$NLS_PARAMETERS
- PARAMETER(NLS 세션 파라미터, NLS_CHARACTERSET)
- VALUE
NLS 파라미터에 지정할 수 있는 모든 값을 보여 줍니다.
SVRMGR> SELECT * FROM v$nls_valid_values
WHERE parameter='LANGUAGE';
PARAMETER VALUE
------------------- -------------------
LANGUAGE AMERICAN
LANGUAGE GERMAN
LANGUAGE FRENCH
LANGUAGE CANADIAN FRENCH
LANGUAGE SPANISH
LANGUAGE ITALIAN
LANGUAGE DUTCH
LANGUAGE SWEDISH
LANGUAGE DANISH
...
NLS 파라미터의 현재 값을 보여 줍니다.
SVRMGR> SELECT * FROM v$nls_parameters;
PARAMETER VALUE
------------------------- ----------------------------
NLS_NALGUAGE AMERICAN
NLS_TERRITORY AMERICA
NLS_CURRENCY $
NLS_ISO_CURRENCY AMERICA
NLS_NUMERIC_CHARACTERS . ,
NLS_CALENDAR GREGORIAN
NLS_DATE_FORMAT DD-MON-YY
NLS_DATE_LANGUAGE AMERICAL
NLS_CHARACTERSET WE8ISO8859p1
NLS_SORT BINARY
10 row selected.
주)
Character set의 이름을 보여주는 새로운 열 CHARACTER_SET_NAME이
여러 뷰에 포함되어 있을 것입니다. CHAR_CS는 데이터베이스 character set이고
NCHAR_CS는 국가 character set입니다.
예를들어, DBA_COLUMNS는 COl$로부터 이 열을 가져옵니다.
22-32 요약
. 데이터베이스에 대한 데이터베이스 character set과 국가 character set 선택
. 서버와 세션에 대한, 그리고 세션마다의 여러 유형의 NLS 파라미터 사용
- 요약참조
관련내용 참조
--------------------------------------------
초기화 파라미터 NLS_LANGUAGE
NLS_TERRITORY
NLS_DATE_FORMAT
NLS_DATE_FANGUAGE
NLS_CURRENCY
NLS_ISO_CURRENCY
NLS_SORT
NLS_NUMERIC_CHARACTERS
NLS_CALENDAR
동적 성능 뷰 V$NLS_VALID_VALUES
V$NLS_PARAMETERS
데이터 딕셔너리 뷰 NLS_DATABASE_PARAMETERS
NLS_INSTANCE_PARAMETERS
NLS_SESSION_PARAMETERS
명령어
ALTER SESSION SET
패키지 프로시저와 함수 DBMS_SESSION.SET_NLS
--------------------------------------------------------------------------------
＊ 교육 담당 & 관리자 : 김 윤 석
＊ 교육 문의 & 예약 접수 : 02) 6255-8046
＊ 홈페이지 http://www.itmoya.net/ocp/main_1.htm
- 오라클지정 교육원, 본원 시험실시, 40%바우쳐제공
