Oracle History #7

Oracle Architecture........................................................................................2

개요..............................................................................................2

Database Structure.....................................................................2

File Structure...............................................................................4

Memory Architecture#1 (SGA)....................................................5

Memory Architecture#2 (PGA)....................................................6

Process Architecture....................................................................6

Oracle Architecture 모델..............................................................7

Oracle Installation for Windows......................................................................9

개요..............................................................................................9

Download 및 실행.........................................................................9

Oracle Installation.....................................................................10

Database Creation 환경.............................................................15

Database Creation 진행.............................................................17

Database 확인 및 관리................................................................31

Oracle Architecture

개요Oracle은 DBMS이다. 즉, database를 관리하는 시스템의 하나이다. 다양한

oracle10g의 특성을 설명하기에 앞서서 oracle의 기본 구성요소와 각 요소들에 대한

이해를 함으로써 초급자에게 개념에 대한 이해를 돕고 중급자에겐 “review”차원에서의

도움을 주고자 한다.

사실 쉽게 생각해 보면 oracle architecture의 기본 요소는 매우 단순하다. 예를 들어

(똑 같지는 않지만) 여러분이 지금 “notepad”를 수행했다고 하자. 이 것을

수행함으로써 notepad process가 생성되었을 것이고 관련 memory영역이

확보되었을 것이다. 또한 여러분이 작성한 내용을 저장하여 file로 그 기록을 남기게 될

것이다. 다시 정리하면 process-memory-file의 3가지 요소가 사용된다는 것이다.

물론, oracle도 이 3가지 구성요소를 가진다. “notepad”와 다른 것이 있다면 file의

종류도 많고 memory 구조도 복잡하며 여러 유형의 processes를 사용한다는 차이점

뿐(?)이다.

사실 oracle의 구성은 oracle의 각 version별로 다르고 또한 각 회사에서 사용되는

oracle의 version도 다양하기 때문에 조금씩 다를 수 있다. 여기서는 가급적

일반적으로 정의하는 구성요소를 중심으로 설명할 것이다. 따라서 이 내용을 바탕으로

본문을 읽다 보면 oracle10g에서 새로운 기능의 추가에 따른 oracle의 구성요소

변동도 이해할 수 있을 것이다.

Database Structure

먼저 아래 그림을 보자. Oracle database에 저장되는 data들은 모두 다음과 같은

체계를 가지고 저장된다.

위에서 보듯 data가 저장되는 최소 단위는 block으로 이 block안에 table등의 row

data가 저장된다. 따라서 여러분이 설정하는 block의 크기에(db_block_size

parameter의 값) 따라 저장되는 row의 수도 달라질 것이다. 이 block 단위가 oracle

의 기본 I/O단위가 된다. 다시 설명이 되겠지만 이 block에 write를 하는 것은 DBWR

process이고 이 block을 read하는 것은 client와 연결을 하고 있는 Server

processes에 의해 이루어 진다.

위 block은 차후 설명할 database buffer cache로 load되고(server process)

변경이 되면 다시 unload되어(DBWR process) 저장된다. 이 blocks이 모아져 하나의

논리적인 단위인 extent를 이루게 되고 동일 extents는 하나의 segment에 속하게

된다. 즉, segment를 생성할 때 이 extent의 크기를 작게 하면 다수의 extents가 크게

하면 소수의 extents가 하나의 segment에 속하게 되는 것이다. 다시 말해 특정한

이름을 갖는 논리적 저장구조인 segment는(table, index등과 같은) extents로

구성이 되고 각 extent는 blocks으로 구성된다.

이러한 segments가 모아져 논리적으로는 tablespace에 저장이 되고 물리적으로는

files에 저장된다. 즉, tablespace는 물리적인 files을 대표하는 논리적인 이름이다.

결국 database의 data들은 물리적인 files로(논리적인 tablespace들로) 만들어진다.

정리하면 database는 files로 이루어져 있고 이 files는 tablespace로 대표되며 data

를 가지는 segment는 tablespace에 속하게 된다. 그리고 각 segment는 extents로

구성이 되고 각 extent는 oracle의 I/O단위인 blocks으로 이루어져 있다.

그림 0-1

Data 저장구조

CF. 이들 tablespace는 가장 일반적인 사용자의 data를 담는 tablespace외에 oracle

이 스스로 운영을 위해 각종 system 정보를 관리하는 “SYSTEM” tablespace, 변경된

data를 복구하기 위한 “UNDO” tablespace, 그리고 sort등의 작업을 위해 임시로

할당하여 사용하는 공간을 제공하는 “TEMPORARY” tablespace가있다. 또한

oracle10g부터는 “SYSAUX” tablespace가 추가되었는데 이는 나중에 본문에서

설명된다.

다음의 그림은 위 내용을 바탕으로 한 database의 tablespace구성이다.

File Structure

1. datafiles : 앞서 설명한 data들 즉, segment가 물리적으로 저장되는 file로

tablespace의 구성요소가 된다. DBWR process에 의해 memory에서 datafile로

write된다.

2. control files : 모든 database는 하나 이상의 control file을 가지는데 이 file에는

database 이름, datafiles 및 redo log files의 이름과 위치정보, log 및 checkpoint

관련 각종정보, database 생성 timestamp 정보 등을 가지고 있다. 이런 정보들에

변경이 생기면 CKPT process에 의해 그 변경내역이 write된다.

3. redo log files : data의 모든 변경사항을 기록하는 file로 이 file의 존재는 어떠한

경우에도 변경시점 이전의 data를 복구할 수 있도록 보장해 준다. 모든 database는

최소 두 개 이상의 redo log set(group)을 가져야 하며 안정성을 위해 각 group을 두

개 이상의 files로 구성하는 것을 권고한다. LGWR process에 의해 write된다.

4. archive log files : 위 redo log files는 계속적으로 switch 즉, 한 file이 다 차면

다른 file로 write가 되는 circular fashion을 가지고 있기 때문에 한 circle이 지나면

overwrite가 발생할 수 밖에 없다. 따라서 overwrite가 되도 상관없도록 redo log file

그림 0-2

Tablespace 종류

이 다 차면 archive log file로 copy해서 보관하게 설정할 수 있다. 이 때는 database

가 archive log mode로 운영 중 이어야 한다. ARCH process에 의해 write된다.

5. parameter files : database instance 즉, database를 시작할 때 database의

memory 및 processes를 구성하기 위한(instance를 생성하기 위한) 각종

parameter와 그 값에 대한 정보를 담고 있다. 따라서 최초 database의 nomount

시점에 한번 read되고 DBA가 수정하기 전 까지는 변경되지 않는다. 다만 oracle9i

에서 소개된 spfile을 사용하는 경우에는 DBA가 database command로 변경된 값을

spfile에 바로 반영할 수는 있다.

6. other files : 그 밖에 database의 log를 날짜 및 시간대로 누적하여 기록하는 alert

log file과 각종 oracle processes에 의해 감지된 error등의 정보를 기록하는 trace

file이 있다.

Memory Architecture#1 (SGA)

Oracle database server의 memory 구조는 server 쪽의 SGA와 client쪽의 PGA가

있다. 먼저 SGA를 살펴보자. SGA는 system global area라고 하여 각종 data와

server 운영과 관련된 정보를 담고 있는 공유 memory영역으로 shared global area

라고도 불린다. 다음은 그 구성요소 이다.

1. database buffer cache : datafile로부터 read된 oracle data blocks이 load

되는 영역이다. 그 크기는 parameter “DB_CACHE_SIZE”의 값으로 결정되며 운영

database의 크기보다는 실제로 운영되는 data의 양에 따라 그 크기를 조절하게 된다.

이 buffers가 변경되면 datafiles에 write된다.

2. redo log buffer : database의 모든 변경사항을 기록한다. 여기에 기록된 redo

entries가 redo log file로 write된다. 이 buffer의 크기는 parameter

“LOG_BUFFER”에 의해 결정된다.

3. shared pool : 이 buffer에는 shared SQL area등을 저장하는 library cache와

tables, views등의 reference정보를 담고 있는 data dictionary cache로 구성되어

있다. 이 buffer의 크기는 parameter “SHARED_POOL_SIZE”에 의해 결정된다.

4. large pool : large pool은 option이다. 필요하지 않다면 설정하지 않아도 되지만

RMAN을 통한 backup 및 recovery작업, shared server나 oracle XA환경에서의

session memory, I/O server processes를 위한 memory를 제공함으로 시스템의

구성환경에 따라 다르게 설정할 필요가 있다. 이 buffer의 크기는 parameter

“LARGE_POOL_SIZE”에 의해 결정된다.

5. java pool : 이 영역은 모든 session의 java code 나 JVM에서 사용하는data를

위해 사용된다. 이 buffer의 크기는 parameter “JAVA_POOL_SIZE”에 의해 결정된다.

6. streams pool : 이 영역은 single database환경에서 설정이 가능하며 oracle

stream기법을(database간 stream을 통한 정보공유) 위해 사용된다. 이 영역의

크기가 “0”인 경우에 stream을 위한 공간이 필요하게 되면 oracle은 shared pool의

10%까지 할당하여 사용한다. 이 buffer의 크기는 parameter

“STREAMS_POOL_SIZE”에 의해 결정된다.

Memory Architecture#2 (PGA)

PGA는 program global area라고 하여 server process를 위해 data 및 각종 정보를

담고 있다. 따라서 이 영역은 shared가 아닌 private 영역으로 다른 process와 함께

공유하지 않는다. 그러나 shared server 환경 즉, client와 1:1로 연결되는 일반적인

dedicated server환경이 아니면 이 PGA의 내용 중 session memory와 관련한

부분은 SGA로 옮겨가게 된다. 또한 large pool을 설정했다면 이 정보는 large pool로

옮겨진다.

1. private SQL area : 이 영역은 bind 정보 및 SQL 수행 중 사용되는 runtime

memory로 구성된다. 만일 shared server 환경을 구성하고 있다면 runtime

memory를 제외한 나머지 정보는 SGA에 위치하게 된다.

2. session memory : 이 영역은 logon 정보와 같은 session과 관련한 정보를

가진다. 따라서 dedicated server환경에서는 각 client가 하나의 server process를

통해 session을 맺게 되고 당연히 각 session의 정보가 PGA에 위치하지만 shared

server환경에서는 server process를 여러 client가 공유함으로 이 session 정보를

SGA에 위치시킨다.

Process Architecture

작업자 즉, client가 oracle에 접속하기 위하여 SQL*Plus와 같은 application이나

tool을 구동하면 oracle에 접속과 동시에 session이 생성되면서 이 session과 연결된

process가 생성되고 이 process는 client의 request를 처리하는 역할을 담당하게

된다. 이를 server process라 한다. 그 외에 oracle이 start되면 여러 가지의

processes가 start되는데 이들은 각자의 고유한 역할을 담당하며 background

process라 부른다. 여기서는 가장 일반적인 processes와 그 역할을 다룬다.

1. Server Process : client의 request를 처리하는 process로서 SQL을 parsing하고

수행하는 역할을 담당한다. 따라서 SQL을 처리하기 위해 필요한 data blocks을

datafile에서 read하여 SGA로 load하는 역할을 수행하고 SQL의 처리결과를 client에

통보하게 된다. 이는 client와 1:1로 연결하는 dedicated server환경에서의 역할이며

shared server환경에서는 여러 client가 shared server process를 공유하고 client

의 request를 받는 dispatcher process가 이 shared server process와 연결된다.

2. DBWR(Database Writer Process) : database buffer cache의 변경된 buffer를

datafile로 write하는 역할을 담당한다. 일반적으로 현재 database buffer cache에서

사용할 수 있는 buffer를 찾지 못하거나 checkpoint가 발생하면 write작업을

수행한다.

3. LGWR(Log Writer Process) : redo log buffer의 내용을 redo log file로 write

하는 역할을 수행한다. 보통 매 3초마다 write가 작동하지만 사용자가 commit을

수행하거나 redo log buffer의 1/3이상이 차는 경우 그리고 필요하다면 DBWR가

write할 때도 LGWR의 write작업이 수행된다.

4. CKPT(Checkpoint Process) : checkpoint가 발생할 때 모든 datafiles의 header

를 update하는 역할을 한다.

5. SMON(System Monitor Process) : instance 가 start 될 때 recovery 를 담당한다.

(그러나 recovery 대상 datafile이 offline된 상태에 있다면 이 datafile은 online되는

시점에 recovery된다) 그리고 주기적으로 조각난 tablespace의 공간을 coalescing

하는 역할 및 더 이상 사용하지 않는 temporary segment를 삭제하는 등의 system과

관련한 작업을 담당한다. 물론 주기적으로 스스로 check하여 작업을 진행하지만 다른

process가 문제를 감지하여 SMON을 call할 수도 있다.

6. PMON(Process Monitor Process) : 이 process는 비정상적으로 종료된 user

process의 recovery를 담당한다. 즉, 비정상적으로 종료된 user process가 사용하고

있던 buffer cache, transaction reset, lock 해제 등의 resource반환 작업을

수행하게 된다. 물론, 주기적으로 필요한 작업을 check하여 작업을 진행하지만 다른

process가 문제를 감지하여 PMON을 call할 수도 있다.

7. RECO(Recover Process) : 이 process는 분산환경에서 다른 database와

연결하여 분산 transaction의 문제를 감지한 우 이를 해결하는 역할을 한다.

8. ARCn(Archiver Processes) : redo log file이 switch될 때 이를 다른 장치로 copy

하는 역할을 한다. 물론, database를 archive log mode로 운영할 때에만 활성화

된다.

9. Dnnn(Dispatcher Processes) : shared server환경에서 여러 client가 공유하는

shared server와의 연결을 담당한다. 즉, client의 request를 받아 shared server와

연결하고 처리결과를 client로 보내주는 역할을 한다.

Oracle Architecture 모델

아래의 그림은 위에서 언급한 내용들을 바탕으로 각 process와 memory 그리고 file

간의 관계를 도식화한 것이다. 아래 그림을 이해한다면 잠시 이 책을 덮고 빈 종이에

여러분 나름대로 oracle의 기본 구성에 대하여 그림을 그려보도록 하자.

그림 0-3

Oracle Architecture

참조

==============================================

=================

Oracle architecture : ob 2p

SGA : ob 3p, o9i 334p

PGA : ob 21p, o8i 128p, o9i 326p

Checkpoint : ob 24p

instance가 start될 때 recovery : ob 5p, o9i 74p

Oracle Installation for Windows

개요앞으로 이 책에서 설명하는 모든 내용들은 기본적으로 OS를 linux로 설정하여 사용할

것이다. 그것이 일반적인 database 운영자에게 실질적인 효과가 있을 것으로

판단되었기 때문이다. 그러나 어떤 사용자들은 windows환경에서 자기 역할을

수행하는 사람도 있을 것이고 더구나 oracle초심자 혹은 이제 막 공부를 시작하는

사람들에게는 windows환경이 더욱 익숙할 것이라는 점을 간과할 수는 없었다.

여기서 다루는 내용은 차후 본문의 linux환경에서 다시 설명하게 되겠지만 여러분이

windows환경에서 이런 작업을 굳이 할 필요가 없다면 이 부분은 건너 띄어도 좋다.

하지만 앞으로 windows환경에서 작업을 진행하려는 사람이라면 그리고 windows

환경이 더욱 익숙한 사람이라면 반드시 이 부분을 자세히 살펴본 후 앞으로 본문에서

설명하는 모든 부분의 linux directory구조를 windows 구조로 변환하여 학습을 하면

될 것이다.

Download 및 실행현재 필자가 보여주는 내용들은 oracle OTN homepage

(http://www.oracle.com/technology/global/kr/index.html)를 통해 download 한

후 이를 수행한 것이다. 먼저 download한 file의 압축을 해제한 후 이를 CD copy

본으로 만들면 이후 해당 CD를 넣을 때 마다 자동으로 다음과 같은 화면을 볼 수 있다.

물론, 이렇게 CD를 사용할 것이 아니라면 해제한 file들 중 “autorun” directory로

이동하여 그 아래에 있는 “autorun.exe”을 실행시켜도 동일한 작업을 할 수 있다.

CF. 본문의 내용들은 모두 oracle10g release 1을 기준으로 하고 있다. 그러나 여기서

보여주는 windows기반의 install 과정은 현재 책이 출간되는 시점에 출시된

oracle10g release 2를 기준으로 하였기 때문에 전체적으로 차이는 없으나

세부항목에 대한 version 표시에서 oracle10g release 2를 확인할 수 있을 것이다.

그러나 이것이 문제되지는 않을 것임으로 여러분은 헛갈리지 않도록 하자.

Oracle Installation

다음의 과정은 실제로 oracle10g database를 install하는 부분이다.

먼저 위 화면에서 “Install/Deinstall Pr”을 선택한다. 그러면 다음과 같은 화면이

나타난다. 여기서는 oracle을 install할 위치와 유형만을 선택하여 진행한다. 여러분은

각자 여러분의 취향에 맞게 변경하면 된다.

그림 0-4

Oracle Install

이제 “다음(N)”을 선택하면 설치 준비화면을 거쳐 잠시 후 다음과 같이 설치환경에

대한 검사결과 화면을 볼 수 있다.

그림 0-5

Oracle Install

별 이상이 없거나 이상이 있다 하더라도 직접관련이 없다면 역시 “다음(N)”을 선택하여

설치화면으로 이동한다.

그림 0-6

Oracle Install

이제 설치할 내역들을 살펴본 후 최종적으로 “설치(I)”를 통해 설치 작업을 진행한다.

다음과 같은 화면에서 진행률을 확인할 수 있다.

그림 0-7

Oracle Install

설치가 완료되면 다음의 화면에서 그 결과를 확인한다. 결과에 대한 설명은 차후

본문에서 다시 살펴볼 것이다. 여기서는 그 과정만 이해하면 되겠다.

그림 0-8

Oracle Install

이제 종료를 선택하여 작업을 완료한다.

Database Creation 환경다음은 windows환경에서 database를 생성하는 과정이다. 먼저 oracle database를

위한 추가적인 directory설정을 다음과 같이하자. 차후 생성될 database의 이름을

“WINORA”로 표기할 것임으로 여러분은 각자 환경에 맞추면 될 것이다. 아래 그림은

필자가 data가 저장될 위치로 “oradata”를 그리고 database를 관리할 directory

구조로 “admin/*”의 구성을 했음을 보여준다.

그림 0-9

Oracle Install

위 설정은 기본적인 oracle 환경변수인 “ORACLE_BASE”를 “C:\oracle”로 설정했음을

말해준다. 다음과 같이 registry정보를 확인하여 여러분 각자의 oracle환경을 제대로

설정한 후 database생성 작업을 계속 진행해 보자.

이제 registry를 확인하기 위해 다음과 같이 실행을 해보자.

그림 0-10

Oracle Admin Directory

그림 0-11

Windows 실행창

다음은 registry 화면이다.

위와 같이 “HKEY_LOCAL_MACHINE\SOFTWARE”를 선택한 후 다음과 같이 ORACLE

관련 내역을 확인하여 필요한 부분이 있으면 각자 추가하거나 설정을 변경하도록 한다.

여기서는 ORACLE_BASE를 눈 여겨 보도록 한다.

Database Creation 진행현재 install이 완료된 위치에서 “C:\oracle\product\10.2.0\BIN\ dbca.bat”를

수행하면 다음과 같은 화면을 볼 수 있다.

그림 0-14

Registry 편집기

그림 0-13

Registry 편집기

그림 0-12

Windows 실행창

“다음(N)”을 선택하여 작업 선택화면으로 이동한다.

그림 0-15

DBCA 실행창

그림 0-16

DBCA 실행창

여기서 “데이터베이스 생성”을 선택한 후 “다음(N)”을 click한다.

생성할 데이터베이스의 유형을 선택한 후 역시 “다음(N)”을 진행한다.

그림 0-17

DBCA 실행창

여기서 여러분이 생성하고자 하는 database의 이름을 설정한다. 필자는 “WINORA”

라고 명명하였다. 다시 “다음(N)”을 선택한다.

그림 0-18

DBCA 실행창

위 화면에서 데이터베이스를 관리할 option을 설정한 후 “다음(N)”을 진행한다.

여러분은 위 설정을 그대로 따라 하자. 관련 내용들은 차후 본문에서도 다시 설명된다.

다시 “다음(N)”을 선택한다.

그림 0-19

DBCA 실행창

여기서는 생성할 데이터베이스를 위해 암호를 설정한다. 현재 작업상 편의를 위해 모든

기본 암호를 “xmanager”로 설정한 상태이다. 다시 “다음(N)”을 선택한다.

그림 0-20

DBCA 실행창

이제 생성할 데이터베이스의 storage관련 option이다. 역시 나중에 다시 설명이

되겠지만 여러분은 기본 선택인 “파일 시스템”을 그대로 설정하고 “다음(N)”을

선택하도록 하자.

그림 0-21

DBCA 실행창

필자는 OMF를 사용하기 위하여 위와 같이 설정하였다. “다음(N)”을 통해 oracle10g

의 특징인 flash recovery area관련 설정을 해보자. 자세한 내용은 나중에 본문에서

다룬다.

그림 0-22

DBCA 실행창

다음은 스키마를 선택하는 화면이다.

그림 0-23

DBCA 실행창

다음은 database관련 설정을 하는 부분이다.

그림 0-24

DBCA 실행창

다음은 현재까지 선택한 내용을 기반으로 만들어질 database 구성 files에 대한

조절을 할 수 있는 화면이다. 그대로 “다음(N)”을 진행하자.

그림 0-25

DBCA 실행창

이제 마지막 단계로 이동하기 위하여 “다음(N)”을 선택하자. 그러면 다음과 같은

최종선택 화면이 나타난다. 필자는 database의 생성과 더불어 나중에 활용할

가능성을 염두에 두고 그 script까지 기록을 남기도록 하였다. 이제 “완료(F)”를

선택하여 생성작업을 수행해 보자.

그림 0-26

DBCA 실행창

이제 최종 화면인 현재의 설정을 점검하는 popup창을 확인할 수 있다.

그림 0-20

DBCA 실행창

“확인”을 선택하면 실제 작업이 시작됨과 동시에 작업현황을 볼 수 있다.

그림 0-28

DBCA 실행창

작업이 완료되면 다음과 같이 최종적으로 작업내용을 확인하는 popup창이 나타난다.

여기서 “종료”버튼을 클릭하면 모든 작업이 완료된다.

그림 0-29

DBCA 실행창

Database 확인 및 관리이제 아래와 같이 command 창을 열어서 접속 테스트를 진행하여 이상유무를

확인하고 database 작업이 정상적으로 이루어졌음을 검증하자.

그림 0-30

DBCA 실행창

이제 windows환경에서 작업을 하고 싶은 사람들을 위한 준비가 완료되었다. 이런

분들은 앞으로 본문에서 설명하는 내용들을 그대로 진행하되 OS관련 부분의 directory

구조를 windows환경에 맞게 변경하면 될 것이다.

CF. 기본적으로 생성되는 database의 parameter file은 spfile의 형태로

“ORACLE_HOME\dbs\ SPFILEWINORA.ORA”로 생성된다. 따라서 현재 필자가 만든

database에서는 “C:\oracle\product\10.2.0\ dbs\ SPFILEWINORA.ORA”가 된다.

이렇게 생성된 database관련 서비스는 최초 windows의 시작과 함께 자동으로

시작되도록 설정이 되어 있다. 자동화를 원치 않고 여러분이 직접 해당 서비스를

조절하고 싶다면 아래와 같이 “제어판 관리도구 서비스”를 선택한 후 시작유형을

변경하도록 한다.

그림 0-31

SQL*Plus 접속화면

그림 0-32

Windows 서비스창

참조

==============================================

=================

database 생성 : ob 14p

spfile : o9i 153, 540p