■ ALL_ROWS  - throughput 최대화를 위한 optimizing을 한다.
  - full table scan을 선호하는 경향이 있다.
  - batch 프로그램 또는 report 출력 프로그램에 사용되는게 좋다.

■ FIRST_ROWS
  - response time 최소화를 위한 optimizing을 한다.
  - index scan을 선호하는 경향이 있다.
  - index scan을 선호하는 경향이 있기에 작은 테이블로부터 데이터를 찾을 때도 index scan을 해서
    full table scan을 하는 것보다 cost가 더 걸리는 단점이 있다.
  - user interaction 즉, 화면계에 사용하면 좋다.

■ FIRST_ROWS_N
  - Oracle 9i부터 도입된 파라미터.
  - FIRST_ROWS의 단점을 보안했다.
    단점이란, FIRST_ROWS_1, FIRST_ROWS_10, FIRST_ROWS_100, FIRST_ROWS_1000 처럼
    FIRST ROWS의 범위를 지정하도록 함으로써 index scan를 해야하는 지, full table scan을 해야하는 지에
    대한 선택을 더 현명하게 하도록 했다는 것이다.

'Database > Oracle' 카테고리의 다른 글

오라클 클라이언트 가 토드에서 안될때. ㅋ  (0) 2010.06.29
update 방법들  (0) 2010.06.16
◈ DB Link (오라클 원격DB 연결)  (0) 2010.05.13
Architecture  (0) 2010.05.04
도메인 인덱스(Domain Index)  (0) 2010.04.28

현재 접속되어 있는 DB에서 원격으로 다른 곳의 DB에 연결하여 사용한다.
(난 로컬DB에 서버의 DATA를 다운로드 받을때 썼다)
기본적으로 오라클은 dblink를 사용하면 세션 연결이 지속 되기 때문에,
로컬DB의 연결을 끊거나, commit/rollback을 하여 세션을 끊어야 한다. 
 
[사용방법]
DBA권한을 가진 유저만 DBLINK를 만들수 있기 때문에 SYSTEM같은 유저로 DBLINK를 만든다
CREATE [PUBLIC] DATABASE LINK <link_name>
       CONNECT TO <user> IDENTIFIED BY <password>
       USING '<service_name>';

[예 1] tnsnames에 원격DB 설정이 되어있는 경우
- DBLINK 명 : testlink
- 원격DB의 USER명 : scott
- 원격DB의 USER PASS : tiger
- 원격DB의 host명 : testdb
create public database link testlink
  connect to scott identified by tiger
 using 'testdb';

[예 2] tnsnames에 원격DB 설정이 되어있지 않은 경우
create public database link testlink
  connect to scott identified by tiger
  using '(DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.0.2)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = TESTDB)))'; 

[DB Link 전체보기]
select * from all_db_links;

[사용 1] 단순조회
select * from emp@testlink
 
[사용 2] 로컬DB와 원격DB의 JOIN
select t.*, s.dname
  from dept s, emp@testlink t
where t.deptno = s.deptno;

[사용 3] 원격 프로시져/함수 호출
<procedure_name>@<database_link>(<parameters>);

'Database > Oracle' 카테고리의 다른 글

update 방법들  (0) 2010.06.16
Oracle optimizer goal, FIRST_ROWS 그리고 ALL_ROWS  (0) 2010.05.14
Architecture  (0) 2010.05.04
도메인 인덱스(Domain Index)  (0) 2010.04.28
비트맵 인덱스(Bitmap Index)  (0) 2010.04.28
Oracle Server
- Database + Instance = Oracle Server


Listener
- Oracle Server 의 구성요소는 아니다.
- Oracle Server 자체에 없는 기능인, 외부에서 접속을 위한 프로세스
- User process 가 접속을 시도할 때 올바른 접속인지 확인하고 서버프로세스와 직접연결을 해준다


Database 구성 파일
Data File
- 테이블 뷰등 오브젝트들의 실제 값들을 갖고있는다.
- 디스크 I/O 를 줄이기 위하여 파일을 분할
- Backup 의 대상
- 다중화의 의미가 없다 (리도로그파일과 데이터백업파일을 다중화 하므로)

- 시스템용 파일
  SYSTEM file : Data Dictionary 들의 정보 포함하는 파일
  SYSAUX file : 10g에서 추가된 테이블스페이스용 파일.
- 비시스템용 파일
  UNDO file
  TEMP file
  USER file : 일반유저들이 사용하는 파일
< 관련 View >
V$DATAFILE
V$LOGFILE
V$CONTROLFILE
V$TEMPFILE

Redo Log FIle
- Online Redo Log File + Offline Redo Log File(Archived Redo Log File) [Archive Log Mode시]
- 모든 행위의 흔적을 코드화하여 저장 (원문그대로가 아니다)
- 백업된 파일의 시점 이후의 값을복원하기위해 사용된다
- 최소 2개이상의 파일(멤버)필요
- 안정성을 위해 2개 이상의 그룹으로 다중화의 대상이 된다.
- Online Redo Log File 의 집단을 Thread
< 관련 View >
V$LOG
V$THREAD
V$ARCHIVED_FILE

Control File
- Instance 와 연결된 파일(Data File, On/Offline Redo Log File)들의 위치등의 정보 포함
- 때문에 Control File 에러시 Startup 이 제대로되지 않는다. (치명적)
- Startup 시 ORACLE_HOME/dbs/매개변수 파일안에 Control File 의 위치를 참조한다
- 다중화의 대상
< 관련 View >
V$CONTROL_FILE


Instance
- 도구, 수단의 역할
- SGA
- BGP

cf.
 Instance 도 이름이 있고, Database 도 이름이 있으나 일반적으로같게 한다
.


SGA 구성
- Shared Pool
- Data Dictionary Cache (Row Cache) : Database Buffer Cache 에 블럭단위복사된 것중 사용되는 값을 Row 단위로 저장
- Library Cache : 파싱된 SQL 문들이 체인으로 연결디어 저장되어있음. (해시값으로 우선 체인을 택하고 이름으로 동일문장 존재여부 확인)
< 관련 View >
V$BH
V$SQLAREA

- Database Buffer Cache : Meta Data Buffer 와 User Data Buffer 이 존재
- Redo Log Buffer
< 관련 View >
V$SGA
V$SGASTAT


BGP (Background Process) 구성
- DBWn : Data Buffer Cache 의 내용을 내려쓴다
사용가능 메모리를 확보하기위해, 혹은 다양한 발생에 의해
Database Buffer Cache의 Dirty Buffer 를 Data FIle 로 내려쓴다
모아쓰기, 내려쓰기 지원

- LGWR : Redo Log Buffer 의 내용을 내려쓴다
사용가능 메모리를 확보하기위해, 혹은 다양한 발생에 의해
Redo Log Buffer 를 Redo Log File 에 기록한다
모아쓰기, 내려쓰기 지원

- CKPT : Control File 과 Data File 을 업데이트
Checkpoint 란 DBWR 가 Dirty Buffer 를 내려쓰는 행위 (CKPT라는 Process 명과는 다른 의미)
DBWR 이 내려쓰기를 수행해야 할 때를 알려준다
Control File 과 Data File 의 Header 에 표시

- PMON : 프로세스의 비정상 종료시 처리
- SMON : 에러가 났을 경우 인스턴스의 복구
- ARCn : Online Redo Log FIle 을 복사(백업)한다
cf.
필수 Process 의 경우 하나라도 Kill 당할 경우 강제 종료된다.


cf.
FGP (Foreground Process)= Server Process = Shadow Process


접속방법
- 내부접속
export ORACLE_SID=instance_name
sqlplus ID/PASSWD

- 외부접속
sqlplus ID/PASSWD@listener_addr/instance_name



Structure
- Storage
- Logical : Tablespace, Segment, Extents, Block
- Physical
- Database File : Control File, Data File, Offline Redo Log File
- Other Key File : Parameter FIle, Diagnostic File,
- Process
- User Process
- Server Process (Foreground Process)
- Background Process
- 기타 : Listener, iSQL*Plus, DBConsle
- Memory
- PGA
- SGA


Logical and Physical Database Structure


DATABASE : 하나의 단위로 취급된다
TABLESPACE : Container. 하나이상의 Data File 로 구성된다.
SEGMENT : 공간을 차지하는 Object (TABLE, INDEX..) cf. VIEW, SYNONYM Objec 이지만 Segment 는 아니다
EXTENT : 연속된 Block 의 집합
DATA BLOCK : 저장소 및 I/O 의 최소단위

< 관련 View >
DBA_TABLESPACES
DBA_FREE_SPACE // 사용가능한(사용되지않은) Extents
DBA_EXTENTS      // 사용한 Extents
DBA_SEGMENTS
DBA_DATA_FILES
DBA_TEMP_FILES

cf 1.
두개의 파일로 구성된 Tablespace를 만들고 어떤 작업도하지 않았을 경우 Segment 의 개수는 0, Extent 의 개수는 2개이다

cf 2.
PGA와 SGA 의 크기 설정은 작업의 종류에 따라 달라진다 (어느쪽이 크거나 작아야 할 필요가 없다)
예를들어, OLTP 와 OLAP 환경 의 시스템 셋팅은 서로 다를 것 이다.




Buffer
- Database Buffecr Cache 의 단위
<Buffer 의 종류>
FREE
: 한번도 쓴적이 없는 Buffer (FREE 와 CLEAN Buffer 를 합쳐서 사용하기도한다)
PINNED : 사용(R,W)하고 있는 Buffer (다른 사람이 사용 못하게 Lock 을 생성한다)
CLEAN : SELECT 의 내용을 담은 Buffer, 재사용 가능 (다른사람이 사용 할 수 있다), CR Buffer 도 포함
DIRTY : 읽은 후 수정된 Buffer, 원본과 내용이 다른 Buffer 재사용 불가능

cf 1.
SELECT : PINNED->CLEAN
Non-SELECT : PINNED->DIRTY->CLEAN

cf 2.
Fast Commit
확정짓고, 락을 푼 후 Redo Log 를 내려쓴다. 실제로 데이터가 내려쓰여지는 것은 아니다.

Commit 시 바로 Data File 에 내려쓰지 않고 Redo Log 를 우선수행하는 이유는 I/O를 줄이기 위해서다


Instance Recovery
  1. Startup
  2. ORACLE_SID 확인
  3. spfileSID.ora
  4. Instance 구성
  5. Control File Read
  6. Datafile, Redo log file read
  7. INSTANCE RECOVERY
  8. Open


SQL (SELECT) 문의 처리 방식
1. PARSE
- 동일문장찾기
SQL 문을 ASCII 값으로 변환 후
해싱함수를 적용하여 해시키값을 생성한다
해시키값이 같은 체인에 대하여 같은 해싱값들을 체이닝 한다 [라이브러리캐시에서 일어남]
이때 각 해시값들의 이름은 SELECT 문의경우 문장전체를, PROCEDURE 의 경우 프로시저의 이름을 사용한다
후에, 다음의 SQL 문이 사용될때 해시값을 이용해 같은 해시값이 존재하는지 검색한 후
같은 해시값이 존재한다면 다음단계로 이름을 비교하여 해당 SQL이 메모리에 존재하는지 판별한다.
이때 대소문자와 스페이스등을 다른문자로 취급하기떄문(ASCII 값이 다름) 다른문장으로 인식한다.
그러므로 코딩 규약을 지키는게 필요하다

- Syntax 검사
키워드의 오타검사

- Sementics 검사
권한, 객체유무 검사
이러한 검사를위해 오라클에 의한 Data Dictionary Cache 에 대하여 Recursive SQL 자동 발생
이때 자주 사용되는 Data Dictionary Table 의 경우 Database Buffer Cache에 블럭단위로 저장되고
검색의 내용에 해당하는 블럭은 Database Buffer Cache 에만 저장된다
또한 이 중 사용된 Data Dictionary Table 의 Row는 Dictionary Cache(Row Cache) 에 저장된다

- Execution Plan
여러 경우의 실행 계획들의 Cost 를 산출하고
옵티마이저에 의해 Cost 가 가장낮은 실행 계획을 선택한다

2. EXECUTE
Memory(Logical) Read : Cache Hit
File(Physical) Read : Cache Miss

3. FETCH
SELECT 에서만 일어나는 작업
메모리(혹은 디스크)에 올려진 결과를 PGA 로 가져와서 정렬등의 작업을 수행


SQL (UPDATE,DELETE) 문의 처리 방식
- Undo Table : Rollback 과 읽기 일관성을 위한 영역
- Redo : 현재과정들을 백업해놓는것뿐이다
1. PARSE
SELECT 문의 PARSE 단계와 동일하다

2. EXECUTE
1. 변경될 Data Block 및 빈(여유)Undo Block 을 Database Buffer Cache(메모리) 로 Read
2. 읽어올린 Block 을 Row Level Lock 을 설정한다
3. PGA에 저장된 Change Vector 들을사용해서  Online Redo Log File 에 Redo Entry 를 만든다 (안전을위해)
4. Undo Data(Block) 에 변경될 내용 기록 (안전을위해)
5. User Data(Block) 수정
===> 결과 출력 : 1 Row Updated.
===> 업데이트 과정에서 조회된 변경데이터는 CR Block 을 조회한다.


cf.
WAL (Write Ahead Log)
1. 버퍼에서의 자료 변경전 항상 리도버퍼에 먼저 기록을하고
2. DBWR에의해 data file 로 내려쓰기 전에 LGWR 에 의해 항상 내려쓰여지므로
모든 데이터는 항상 로그기록을 먼저 남기게 된다


http://wiki.ex-em.com/index.php/Transaction
http://www.urbantree.wo.tc/46
1.개요
 
B*Tree 인덱스에 대한 연구가 발표되면서 대부분의 RDBMS에서는 B*Tree 인덱스를 주 인덱싱 기법으로 도입하기 시작하였다. B*Tree는 과거 어느 Tree 구조보다 대용량RDBMS에 적합한 구조를 가지고 있어 많은 사용자를 확보하게 된다. 이러한 B*Tree 인덱스는 많은 장점에도 불구하고 일부 단점으로 인하여 사용자들은 새로운 인덱스의 출현을 지속적으로 요구하게 되었다.
 
BITMAP index, Reverse Index 그리고 Function based Index는 B*Tree Index의 단점을 보완하기 위해 만들어진 Index들이다. 그러나 이러한 인덱스들은 특수한 목적을 가지고 만들어진 인덱스이므로 B*Tree 인덱스의 단점을 어느 정도 보완할 수 있을지 몰라도 사용자에 대한 새로운 인덱스의 요구를 종식시킬 수는 없었다.
 
가능한 모든 종류의 인덱스를 만들 수는 없지만 사용자가 원하는 형태의 인덱스를 스스로 만들 수 있다면 모든 종류의 인덱스를 만들지 않고도 우리가 원하는 목적을 달성할 수 있을 것이다. 이러한 목적을 가지고 탄생한 것이 DOMAIN index 다.
 
DOMAIN Index는 오라클8i에서부터 새롭게 도입된 개념으로 개발자가 자신이 원하는 인덱스 타입을 생성할 수 있게 함으로써 오라클의 인덱스 시스템에 많은 확장을 가져다 주었다.
 
즉, 데이터베이스에는 아직 존재하지도 않는 새로운 인덱스 타입을 자신이 스스로 정의하여 오라클에서 지원하는 인덱스 처럼 사용할 수가 있다는 것이다. 현재 오라클에서 사용하고 있는 Domain index의 좋은 사례로는 interMedia text index 나 오라클 9i부터 지원되는 Context 타입 인덱스와 Catalog 타입 인덱스등으로 모두 비정형 Text를 빠르게 검색하게 위해 도입되었다.
 
2. Extensible indexing framework
 
Domain index는 다음과 같은 네가지 구성요소로 이루어져 있다.
 
1) Indextype
 
Schema object indextype는 인덱스의 정의, 관리, 스캔등 새로운 인덱스 타입이 가질수 있는 모든 경향을 관리할 수 있는 루틴을 캡술화 하여 사용자가 보다 쉽게 사용자 정의 인덱스를 생성할 수 있게 한다.
 
2) Domain index
 
도메인 인덱스는 인덱스 타입에서 제공되는 루틴에 의하여 생성, 관리, 액세스 되는 인덱스의 한 종류로 application-specific domains에 대한 데이터를 indexing하는데 사용하기 때문에 domain index라고 한다.
 
3) Operators
 
이전의 관계형 데이터베이스에서는 내부 정의 Operator를 효과적으로 적용하기 위해 B*TREE 인덱스를 사용하였다.
 
그러나 기존의 B*Tree 인덱스는 일부 데이터 타입(숫자, 문자열)에 대하여만 인덱스를 생성할 수 있어 다른 데이터 타입(Text, spatial, image, video and audio)에 대하여 새로운 특화된 인덱스 기법을 필요하게 되었다. 이렇게 하여 탄생한 것이 사용자 정의 도메인 인덱스다.
 
사용자 정의 도메인 인덱스도 기존 인덱스처럼 인덱스를 검색하기 위한 사용자 정의 Operator를 가지게 되는데, 이 사용자 정의 Operator는 사용자 정의 도메인 인덱스를 검색하기 위한 함수로 indextype 정의시에 정의된다.
 
4) Index-organized table
 
사용자 정의 도메인 인덱스의 자기 자신의 물리적 구조에 정보는 데이터베이스 내부에 IOT로 저장되거나 외부 파일로 저장이 된다
 
<example>
Oracle text 에서 지원하는 도메인 인덱스에 대한 예제
 

'Database > Oracle' 카테고리의 다른 글

◈ DB Link (오라클 원격DB 연결)  (0) 2010.05.13
Architecture  (0) 2010.05.04
비트맵 인덱스(Bitmap Index)  (0) 2010.04.28
함수기반 (Function Based) 인덱스의 활용  (0) 2010.04.28
비-트리 인덱스(B-Tree Index)  (0) 2010.04.27

+ Recent posts