SlideShare une entreprise Scribd logo
1  sur  35
Oracle Architecture...................................................................................................................2
                     개요......................................................................................................................2
                     Database Structure.............................................................................................2
                     File Structure......................................................................................................4
                     Memory Architecture#1 (SGA)........................................................................5
                     Memory Architecture#2 (PGA)........................................................................5
                     Process Architecture..........................................................................................6
                     Oracle Architecture 모델...................................................................................7
Oracle Installation for Windows............................................................................................10
                     개요....................................................................................................................10
                     Download 및 실행...........................................................................................10
                     Oracle Installation............................................................................................11
                     Database Creation 환경...................................................................................16
                     Database Creation 진행...................................................................................18
                     Database 확인 및 관리....................................................................................32
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들은 모두 다음과 같은 체계를
가지고 저장된다.
그림 0-1

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으로 이루어져 있다.


         CF. 이들 tablespace는 가장 일반적인 사용자의 data를 담는 tablespace외에 oracle이 스
스로 운영을 위해 각종 system 정보를 관리하는 “SYSTEM” tablespace, 변경된 data를
           복구하기 위한 “UNDO” tablespace, 그리고 sort등의 작업을 위해 임시로 할당하여 사
           용하는 공간을 제공하는 “TEMPORARY” tablespace가있다. 또한 oracle10g부터는
           “SYSAUX” tablespace가 추가되었는데 이는 나중에 본문에서 설명된다.


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

Tablespa
ce 종류




           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이 다 차면
           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)
않는다. 그러나 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
Architect
ure
참조
===============================================================
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를 확인할 수 있을 것이다. 그러나 이것이 문제되지
는 않을 것임으로 여러분은 헛갈리지 않도록 하자.
그림 0-4

Oracle
Install




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


          먼저 위 화면에서 “Install/Deinstall Pr”을 선택한다. 그러면 다음과 같은 화면이 나타
          난다. 여기서는 oracle을 install할 위치와 유형만을 선택하여 진행한다. 여러분은 각자
          여러분의 취향에 맞게 변경하면 된다.
그림 0-5

Oracle
Install




          이제 “다음(N)”을 선택하면 설치 준비화면을 거쳐 잠시 후 다음과 같이 설치환경에 대
          한 검사결과 화면을 볼 수 있다.
그림 0-6

Oracle
Install




          별 이상이 없거나 이상이 있다 하더라도 직접관련이 없다면 역시 “다음(N)”을 선택하
          여 설치화면으로 이동한다.
그림 0-7

Oracle
Install




          이제 설치할 내역들을 살펴본 후 최종적으로 “설치(I)”를 통해 설치 작업을 진행한다.
          다음과 같은 화면에서 진행률을 확인할 수 있다.
그림 0-8

Oracle
Install




          설치가 완료되면 다음의 화면에서 그 결과를 확인한다. 결과에 대한 설명은 차후 본문
          에서 다시 살펴볼 것이다. 여기서는 그 과정만 이해하면 되겠다.
그림 0-9

Oracle
Install




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


          Database Creation 환경
          다음은 windows환경에서 database를 생성하는 과정이다. 먼저 oracle database를 위한
          추가적인    directory설정을   다음과   같이하자. 차후   생성될   database의   이름을
          “WINORA”로 표기할 것임으로 여러분은 각자 환경에 맞추면 될 것이다. 아래 그림은
          필자가 data가 저장될 위치로 “oradata”를 그리고 database를 관리할 directory 구조로
          “admin/*”의 구성을 했음을 보여준다.
그림 0-10

Oracle
Admin
Directory




            위 설정은 기본적인 oracle 환경변수인 “ORACLE_BASE”를 “C:oracle”로 설정했음을
            말해준다. 다음과 같이 registry정보를 확인하여 여러분 각자의 oracle환경을 제대로 설
            정한 후 database생성 작업을 계속 진행해 보자.
그림 0-11

Windows
실행창




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

Windows
실행창




           다음은 registry 화면이다.
그림 0-13

Registry
편집기




           위와 같이 “HKEY_LOCAL_MACHINESOFTWARE”를 선택한 후 다음과 같이
           ORACLE관련 내역을 확인하여 필요한 부분이 있으면 각자 추가하거나 설정을 변경하
           도록 한다. 여기서는 ORACLE_BASE를 눈 여겨 보도록 한다.
그림 0-14

Registry
편집기




           Database Creation 진행
           현재 install이 완료된 위치에서 “C:oracleproduct10.2.0BIN dbca.bat”를 수행하
           면 다음과 같은 화면을 볼 수 있다.
그림 0-15

DBCA 실
행창




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

DBCA 실
행창
여기서 “데이터베이스 생성”을 선택한 후 “다음(N)”을 click한다.
그림 0-17

DBCA 실
행창




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

DBCA 실
행창




          여기서 여러분이 생성하고자 하는 database의 이름을 설정한다. 필자는 “WINORA”라
          고 명명하였다. 다시 “다음(N)”을 선택한다.
그림 0-19

DBCA 실
행창




          위 화면에서 데이터베이스를 관리할 option을 설정한 후 “다음(N)”을 진행한다. 여러분
          은 위 설정을 그대로 따라 하자. 관련 내용들은 차후 본문에서도 다시 설명된다. 다시 “
          다음(N)”을 선택한다.
그림 0-20

DBCA 실
행창




          여기서는 생성할 데이터베이스를 위해 암호를 설정한다. 현재 작업상 편의를 위해 모든
          기본 암호를 “xmanager”로 설정한 상태이다. 다시 “다음(N)”을 선택한다.
그림 0-21

DBCA 실
행창




          이제 생성할 데이터베이스의 storage관련 option이다. 역시 나중에 다시 설명이 되겠지
          만 여러분은 기본 선택인 “파일 시스템”을 그대로 설정하고 “다음(N)”을 선택하도록
          하자.
그림 0-22

DBCA 실
행창




          필자는 OMF를 사용하기 위하여 위와 같이 설정하였다. “다음(N)”을 통해 oracle10g의
          특징인 flash recovery area관련 설정을 해보자. 자세한 내용은 나중에 본문에서 다룬다.
그림 0-23

DBCA 실
행창




          다음은 스키마를 선택하는 화면이다.
그림 0-24

DBCA 실
행창
다음은 database관련 설정을 하는 부분이다.
그림 0-25

DBCA 실
행창




          다음은 현재까지 선택한 내용을 기반으로 만들어질 database 구성 files에 대한 조절을
          할 수 있는 화면이다. 그대로 “다음(N)”을 진행하자.
그림 0-26

DBCA 실
행창




          이제 마지막 단계로 이동하기 위하여 “다음(N)”을 선택하자. 그러면 다음과 같은 최종
          선택 화면이 나타난다. 필자는 database의 생성과 더불어 나중에 활용할 가능성을 염두
          에 두고 그 script까지 기록을 남기도록 하였다. 이제 “완료(F)”를 선택하여 생성작업을
          수행해 보자.
그림 0-20

DBCA 실
행창




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

DBCA 실
행창




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

DBCA 실
행창




          작업이 완료되면 다음과 같이 최종적으로 작업내용을 확인하는 popup창이 나타난다.
          여기서 “종료”버튼을 클릭하면 모든 작업이 완료된다.
그림 0-30

DBCA 실
행창




          Database 확인 및 관리
          이제 아래와 같이 command 창을 열어서 접속 테스트를 진행하여 이상유무를 확인하
          고 database 작업이 정상적으로 이루어졌음을 검증하자.
그림 0-31

SQL*Plus
접속화면




           이제 windows환경에서 작업을 하고 싶은 사람들을 위한 준비가 완료되었다. 이런 분들
           은 앞으로 본문에서 설명하는 내용들을 그대로 진행하되 OS관련 부분의 directory 구조
           를 windows환경에 맞게 변경하면 될 것이다.


           CF.   기본적으로     생성되는      database의   parameter   file은   spfile의   형태로
           “ORACLE_HOMEdbs SPFILEWINORA.ORA”로 생성된다. 따라서 현재 필자가 만
           든 database에서는 “C:oracleproduct10.2.0 dbs SPFILEWINORA.ORA”가 된다.


           이렇게 생성된 database관련 서비스는 최초 windows의 시작과 함께 자동으로 시작되
           도록 설정이 되어 있다. 자동화를 원치 않고 여러분이 직접 해당 서비스를 조절하고 싶
           다면 아래와 같이 “제어판          관리도구      서비스”를 선택한 후 시작유형을 변경하도
           록 한다.
그림 0-32

Windows
서비스창
참조
===============================================================
database 생성 : ob 14p
spfile : o9i 153, 540p

Contenu connexe

Tendances

MS 빅데이터 서비스 및 게임사 PoC 사례 소개
MS 빅데이터 서비스 및 게임사 PoC 사례 소개MS 빅데이터 서비스 및 게임사 PoC 사례 소개
MS 빅데이터 서비스 및 게임사 PoC 사례 소개I Goo Lee
 
[2015 07-06-윤석준] Oracle 성능 최적화 및 품질 고도화 4
[2015 07-06-윤석준] Oracle 성능 최적화 및 품질 고도화 4[2015 07-06-윤석준] Oracle 성능 최적화 및 품질 고도화 4
[2015 07-06-윤석준] Oracle 성능 최적화 및 품질 고도화 4Seok-joon Yun
 
MySQL 상태 메시지 분석 및 활용
MySQL 상태 메시지 분석 및 활용MySQL 상태 메시지 분석 및 활용
MySQL 상태 메시지 분석 및 활용I Goo Lee
 
오라클 DB 아키텍처와 튜닝
오라클 DB 아키텍처와 튜닝오라클 DB 아키텍처와 튜닝
오라클 DB 아키텍처와 튜닝철민 권
 
Ots2014 arcus-collection-open source
Ots2014 arcus-collection-open sourceOts2014 arcus-collection-open source
Ots2014 arcus-collection-open sourceNAVER D2
 
DBMS 아키텍처
DBMS 아키텍처DBMS 아키텍처
DBMS 아키텍처HaksunLEE6
 
Windows 성능모니터를 이용한 SQL Server 성능 분석
Windows 성능모니터를 이용한 SQL Server 성능 분석Windows 성능모니터를 이용한 SQL Server 성능 분석
Windows 성능모니터를 이용한 SQL Server 성능 분석Sung wook Kang
 
MySQL Deep dive with FusionIO
MySQL Deep dive with FusionIOMySQL Deep dive with FusionIO
MySQL Deep dive with FusionIOI Goo Lee
 
Maxscale 소개 1.1.1
Maxscale 소개 1.1.1Maxscale 소개 1.1.1
Maxscale 소개 1.1.1NeoClova
 
ARCUS offline meeting 2015. 05. 20 1회
ARCUS offline meeting 2015. 05. 20 1회ARCUS offline meeting 2015. 05. 20 1회
ARCUS offline meeting 2015. 05. 20 1회JaM2in
 
From MSSQL to MySQL
From MSSQL to MySQLFrom MSSQL to MySQL
From MSSQL to MySQLI Goo Lee
 
Gluster fs guide(v1.0)
Gluster fs guide(v1.0)Gluster fs guide(v1.0)
Gluster fs guide(v1.0)sprdd
 
Oracle 세미나 1차 과제 V1 0
Oracle 세미나 1차 과제 V1 0Oracle 세미나 1차 과제 V1 0
Oracle 세미나 1차 과제 V1 0guest468e16
 
Oracle Server Architecture
Oracle Server ArchitectureOracle Server Architecture
Oracle Server Architectureguest468e16
 
Tungsten 을활용한 MySQL / Hadoop 동기화
Tungsten 을활용한 MySQL / Hadoop 동기화Tungsten 을활용한 MySQL / Hadoop 동기화
Tungsten 을활용한 MySQL / Hadoop 동기화I Goo Lee
 
KEEP BUFFER 활용 방안_Wh oracle
KEEP BUFFER 활용 방안_Wh oracleKEEP BUFFER 활용 방안_Wh oracle
KEEP BUFFER 활용 방안_Wh oracle엑셈
 
From MSSQL to MariaDB
From MSSQL to MariaDBFrom MSSQL to MariaDB
From MSSQL to MariaDBI Goo Lee
 
[2015 05-29] Oracle Lock
[2015 05-29] Oracle Lock[2015 05-29] Oracle Lock
[2015 05-29] Oracle LockSeok-joon Yun
 
Federated Engine 실무적용사례
Federated Engine 실무적용사례Federated Engine 실무적용사례
Federated Engine 실무적용사례I Goo Lee
 

Tendances (20)

MS 빅데이터 서비스 및 게임사 PoC 사례 소개
MS 빅데이터 서비스 및 게임사 PoC 사례 소개MS 빅데이터 서비스 및 게임사 PoC 사례 소개
MS 빅데이터 서비스 및 게임사 PoC 사례 소개
 
[2015 07-06-윤석준] Oracle 성능 최적화 및 품질 고도화 4
[2015 07-06-윤석준] Oracle 성능 최적화 및 품질 고도화 4[2015 07-06-윤석준] Oracle 성능 최적화 및 품질 고도화 4
[2015 07-06-윤석준] Oracle 성능 최적화 및 품질 고도화 4
 
MySQL 상태 메시지 분석 및 활용
MySQL 상태 메시지 분석 및 활용MySQL 상태 메시지 분석 및 활용
MySQL 상태 메시지 분석 및 활용
 
오라클 DB 아키텍처와 튜닝
오라클 DB 아키텍처와 튜닝오라클 DB 아키텍처와 튜닝
오라클 DB 아키텍처와 튜닝
 
Ots2014 arcus-collection-open source
Ots2014 arcus-collection-open sourceOts2014 arcus-collection-open source
Ots2014 arcus-collection-open source
 
DBMS 아키텍처
DBMS 아키텍처DBMS 아키텍처
DBMS 아키텍처
 
Windows 성능모니터를 이용한 SQL Server 성능 분석
Windows 성능모니터를 이용한 SQL Server 성능 분석Windows 성능모니터를 이용한 SQL Server 성능 분석
Windows 성능모니터를 이용한 SQL Server 성능 분석
 
MySQL Deep dive with FusionIO
MySQL Deep dive with FusionIOMySQL Deep dive with FusionIO
MySQL Deep dive with FusionIO
 
Maxscale 소개 1.1.1
Maxscale 소개 1.1.1Maxscale 소개 1.1.1
Maxscale 소개 1.1.1
 
ARCUS offline meeting 2015. 05. 20 1회
ARCUS offline meeting 2015. 05. 20 1회ARCUS offline meeting 2015. 05. 20 1회
ARCUS offline meeting 2015. 05. 20 1회
 
From MSSQL to MySQL
From MSSQL to MySQLFrom MSSQL to MySQL
From MSSQL to MySQL
 
Gluster fs guide(v1.0)
Gluster fs guide(v1.0)Gluster fs guide(v1.0)
Gluster fs guide(v1.0)
 
Oracle 세미나 1차 과제 V1 0
Oracle 세미나 1차 과제 V1 0Oracle 세미나 1차 과제 V1 0
Oracle 세미나 1차 과제 V1 0
 
Oracle Server Architecture
Oracle Server ArchitectureOracle Server Architecture
Oracle Server Architecture
 
Tungsten 을활용한 MySQL / Hadoop 동기화
Tungsten 을활용한 MySQL / Hadoop 동기화Tungsten 을활용한 MySQL / Hadoop 동기화
Tungsten 을활용한 MySQL / Hadoop 동기화
 
KEEP BUFFER 활용 방안_Wh oracle
KEEP BUFFER 활용 방안_Wh oracleKEEP BUFFER 활용 방안_Wh oracle
KEEP BUFFER 활용 방안_Wh oracle
 
Arcus
ArcusArcus
Arcus
 
From MSSQL to MariaDB
From MSSQL to MariaDBFrom MSSQL to MariaDB
From MSSQL to MariaDB
 
[2015 05-29] Oracle Lock
[2015 05-29] Oracle Lock[2015 05-29] Oracle Lock
[2015 05-29] Oracle Lock
 
Federated Engine 실무적용사례
Federated Engine 실무적용사례Federated Engine 실무적용사례
Federated Engine 실무적용사례
 

Similaire à Oracle History #7

[pgday.Seoul 2022] PostgreSQL구조 - 윤성재
[pgday.Seoul 2022] PostgreSQL구조 - 윤성재[pgday.Seoul 2022] PostgreSQL구조 - 윤성재
[pgday.Seoul 2022] PostgreSQL구조 - 윤성재PgDay.Seoul
 
그림으로 공부하는 오라클 구조
그림으로 공부하는 오라클 구조그림으로 공부하는 오라클 구조
그림으로 공부하는 오라클 구조Choonghyun Yang
 
Memcached의 확장성 개선
Memcached의 확장성 개선Memcached의 확장성 개선
Memcached의 확장성 개선NAVER D2
 
부적절한 DDL 수행에 의한 성능 저하 분석 사례_Maxgauge case study
부적절한 DDL 수행에 의한 성능 저하 분석 사례_Maxgauge case study부적절한 DDL 수행에 의한 성능 저하 분석 사례_Maxgauge case study
부적절한 DDL 수행에 의한 성능 저하 분석 사례_Maxgauge case study엑셈
 
log-monitoring-architecture.pdf
log-monitoring-architecture.pdflog-monitoring-architecture.pdf
log-monitoring-architecture.pdfSungkyun Kim
 
[2015-06-12] Oracle 성능 최적화 및 품질 고도화 1
[2015-06-12] Oracle 성능 최적화 및 품질 고도화 1[2015-06-12] Oracle 성능 최적화 및 품질 고도화 1
[2015-06-12] Oracle 성능 최적화 및 품질 고도화 1Seok-joon Yun
 
AWS CLOUD 2018- Amazon Aurora  신규 서비스 알아보기 (최유정 솔루션즈 아키텍트)
AWS CLOUD 2018- Amazon Aurora  신규 서비스 알아보기 (최유정 솔루션즈 아키텍트)AWS CLOUD 2018- Amazon Aurora  신규 서비스 알아보기 (최유정 솔루션즈 아키텍트)
AWS CLOUD 2018- Amazon Aurora  신규 서비스 알아보기 (최유정 솔루션즈 아키텍트)Amazon Web Services Korea
 
손쉬운 데이터 연결 방법(라이브바인딩 활용)
손쉬운 데이터 연결 방법(라이브바인딩 활용)손쉬운 데이터 연결 방법(라이브바인딩 활용)
손쉬운 데이터 연결 방법(라이브바인딩 활용)Devgear
 
이디스커버리 솔루션의 구조
이디스커버리 솔루션의 구조이디스커버리 솔루션의 구조
이디스커버리 솔루션의 구조Park Youngsoo
 
Rankwave MOMENT™ (Korean)
Rankwave MOMENT™ (Korean)Rankwave MOMENT™ (Korean)
Rankwave MOMENT™ (Korean)HyoungEun Kim
 
Mongodb2.2와 2.4의 신 기능 소개
Mongodb2.2와 2.4의 신 기능 소개Mongodb2.2와 2.4의 신 기능 소개
Mongodb2.2와 2.4의 신 기능 소개흥배 최
 
Scalable web architecture and distributed systems
Scalable web architecture and distributed systemsScalable web architecture and distributed systems
Scalable web architecture and distributed systemseva
 
Scalable web architecture and distributed systems
Scalable web architecture and distributed systemsScalable web architecture and distributed systems
Scalable web architecture and distributed systems현종 김
 
AWS 9월 웨비나 | Amazon Aurora Deep Dive
AWS 9월 웨비나 | Amazon Aurora Deep DiveAWS 9월 웨비나 | Amazon Aurora Deep Dive
AWS 9월 웨비나 | Amazon Aurora Deep DiveAmazon Web Services Korea
 
오라클 커서(Cursor) 개념 및 오라클 메모리 구조_PL/SQL,오라클커서강좌,SGA, PGA, UGA, Shared Pool, Sha...
오라클 커서(Cursor) 개념 및 오라클 메모리 구조_PL/SQL,오라클커서강좌,SGA, PGA, UGA, Shared Pool, Sha...오라클 커서(Cursor) 개념 및 오라클 메모리 구조_PL/SQL,오라클커서강좌,SGA, PGA, UGA, Shared Pool, Sha...
오라클 커서(Cursor) 개념 및 오라클 메모리 구조_PL/SQL,오라클커서강좌,SGA, PGA, UGA, Shared Pool, Sha...탑크리에듀(구로디지털단지역3번출구 2분거리)
 

Similaire à Oracle History #7 (20)

[pgday.Seoul 2022] PostgreSQL구조 - 윤성재
[pgday.Seoul 2022] PostgreSQL구조 - 윤성재[pgday.Seoul 2022] PostgreSQL구조 - 윤성재
[pgday.Seoul 2022] PostgreSQL구조 - 윤성재
 
그림으로 공부하는 오라클 구조
그림으로 공부하는 오라클 구조그림으로 공부하는 오라클 구조
그림으로 공부하는 오라클 구조
 
Memcached의 확장성 개선
Memcached의 확장성 개선Memcached의 확장성 개선
Memcached의 확장성 개선
 
부적절한 DDL 수행에 의한 성능 저하 분석 사례_Maxgauge case study
부적절한 DDL 수행에 의한 성능 저하 분석 사례_Maxgauge case study부적절한 DDL 수행에 의한 성능 저하 분석 사례_Maxgauge case study
부적절한 DDL 수행에 의한 성능 저하 분석 사례_Maxgauge case study
 
log-monitoring-architecture.pdf
log-monitoring-architecture.pdflog-monitoring-architecture.pdf
log-monitoring-architecture.pdf
 
[2015-06-12] Oracle 성능 최적화 및 품질 고도화 1
[2015-06-12] Oracle 성능 최적화 및 품질 고도화 1[2015-06-12] Oracle 성능 최적화 및 품질 고도화 1
[2015-06-12] Oracle 성능 최적화 및 품질 고도화 1
 
AWS CLOUD 2018- Amazon Aurora  신규 서비스 알아보기 (최유정 솔루션즈 아키텍트)
AWS CLOUD 2018- Amazon Aurora  신규 서비스 알아보기 (최유정 솔루션즈 아키텍트)AWS CLOUD 2018- Amazon Aurora  신규 서비스 알아보기 (최유정 솔루션즈 아키텍트)
AWS CLOUD 2018- Amazon Aurora  신규 서비스 알아보기 (최유정 솔루션즈 아키텍트)
 
OracleHistory2
OracleHistory2OracleHistory2
OracleHistory2
 
손쉬운 데이터 연결 방법(라이브바인딩 활용)
손쉬운 데이터 연결 방법(라이브바인딩 활용)손쉬운 데이터 연결 방법(라이브바인딩 활용)
손쉬운 데이터 연결 방법(라이브바인딩 활용)
 
이디스커버리 솔루션의 구조
이디스커버리 솔루션의 구조이디스커버리 솔루션의 구조
이디스커버리 솔루션의 구조
 
Oracle History #9
Oracle History #9Oracle History #9
Oracle History #9
 
Rankwave MOMENT™ (Korean)
Rankwave MOMENT™ (Korean)Rankwave MOMENT™ (Korean)
Rankwave MOMENT™ (Korean)
 
Mongodb2.2와 2.4의 신 기능 소개
Mongodb2.2와 2.4의 신 기능 소개Mongodb2.2와 2.4의 신 기능 소개
Mongodb2.2와 2.4의 신 기능 소개
 
Scalable web architecture and distributed systems
Scalable web architecture and distributed systemsScalable web architecture and distributed systems
Scalable web architecture and distributed systems
 
Scalable web architecture and distributed systems
Scalable web architecture and distributed systemsScalable web architecture and distributed systems
Scalable web architecture and distributed systems
 
1.2 cursor&oracle memory
1.2 cursor&oracle memory1.2 cursor&oracle memory
1.2 cursor&oracle memory
 
AWS 9월 웨비나 | Amazon Aurora Deep Dive
AWS 9월 웨비나 | Amazon Aurora Deep DiveAWS 9월 웨비나 | Amazon Aurora Deep Dive
AWS 9월 웨비나 | Amazon Aurora Deep Dive
 
오라클 커서(Cursor) 개념 및 오라클 메모리 구조_PL/SQL,오라클커서강좌,SGA, PGA, UGA, Shared Pool, Sha...
오라클 커서(Cursor) 개념 및 오라클 메모리 구조_PL/SQL,오라클커서강좌,SGA, PGA, UGA, Shared Pool, Sha...오라클 커서(Cursor) 개념 및 오라클 메모리 구조_PL/SQL,오라클커서강좌,SGA, PGA, UGA, Shared Pool, Sha...
오라클 커서(Cursor) 개념 및 오라클 메모리 구조_PL/SQL,오라클커서강좌,SGA, PGA, UGA, Shared Pool, Sha...
 
steeleye Replication
steeleye Replication steeleye Replication
steeleye Replication
 
Oracle History #8
Oracle History #8Oracle History #8
Oracle History #8
 

Plus de Kyung Sang Jang (15)

Oracle History #14
Oracle History #14Oracle History #14
Oracle History #14
 
O10g miscellaneous 17
O10g miscellaneous 17O10g miscellaneous 17
O10g miscellaneous 17
 
O10g flashback 13
O10g flashback 13O10g flashback 13
O10g flashback 13
 
O10g data control_10
O10g data control_10O10g data control_10
O10g data control_10
 
O10g bak rec_15
O10g bak rec_15O10g bak rec_15
O10g bak rec_15
 
O10g asm 16
O10g asm 16O10g asm 16
O10g asm 16
 
O10g app support_11
O10g app support_11O10g app support_11
O10g app support_11
 
O10g security 12
O10g security 12O10g security 12
O10g security 12
 
Oracle History #6
Oracle History #6Oracle History #6
Oracle History #6
 
Oracle History #5
Oracle History #5Oracle History #5
Oracle History #5
 
Oracle History #4
Oracle History #4Oracle History #4
Oracle History #4
 
OracleHistory3
OracleHistory3OracleHistory3
OracleHistory3
 
DB와암호화 패턴
DB와암호화 패턴DB와암호화 패턴
DB와암호화 패턴
 
NO PARALLEL DML
NO PARALLEL DMLNO PARALLEL DML
NO PARALLEL DML
 
11g nf sql_anlz
11g nf sql_anlz11g nf sql_anlz
11g nf sql_anlz
 

Oracle History #7

  • 1. Oracle Architecture...................................................................................................................2 개요......................................................................................................................2 Database Structure.............................................................................................2 File Structure......................................................................................................4 Memory Architecture#1 (SGA)........................................................................5 Memory Architecture#2 (PGA)........................................................................5 Process Architecture..........................................................................................6 Oracle Architecture 모델...................................................................................7 Oracle Installation for Windows............................................................................................10 개요....................................................................................................................10 Download 및 실행...........................................................................................10 Oracle Installation............................................................................................11 Database Creation 환경...................................................................................16 Database Creation 진행...................................................................................18 Database 확인 및 관리....................................................................................32
  • 2. 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들은 모두 다음과 같은 체계를 가지고 저장된다.
  • 3. 그림 0-1 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으로 이루어져 있다. CF. 이들 tablespace는 가장 일반적인 사용자의 data를 담는 tablespace외에 oracle이 스
  • 4. 스로 운영을 위해 각종 system 정보를 관리하는 “SYSTEM” tablespace, 변경된 data를 복구하기 위한 “UNDO” tablespace, 그리고 sort등의 작업을 위해 임시로 할당하여 사 용하는 공간을 제공하는 “TEMPORARY” tablespace가있다. 또한 oracle10g부터는 “SYSAUX” tablespace가 추가되었는데 이는 나중에 본문에서 설명된다. 다음의 그림은 위 내용을 바탕으로 한 database의 tablespace구성이다. 그림 0-2 Tablespa ce 종류 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이 다 차면 archive log file로 copy해서 보관하게 설정할 수 있다. 이 때는 database가 archive log mode로 운영 중 이어야 한다. ARCH process에 의해 write된다. 5. parameter files : database instance 즉, database를 시작할 때 database의 memory 및 processes를 구성하기 위한(instance를 생성하기 위한) 각종 parameter와 그 값에 대한
  • 5. 정보를 담고 있다. 따라서 최초 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) 않는다. 그러나 shared server 환경 즉, client와 1:1로 연결되는 일반적인 dedicated server환경이 아니면 이 PGA의 내용 중 session memory와 관련한 부분은 SGA로 옮겨
  • 6. 가게 된다. 또한 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가 문제
  • 7. 를 감지하여 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 모델
  • 8. 아래의 그림은 위에서 언급한 내용들을 바탕으로 각 process와 memory 그리고 file간 의 관계를 도식화한 것이다. 아래 그림을 이해한다면 잠시 이 책을 덮고 빈 종이에 여러 분 나름대로 oracle의 기본 구성에 대하여 그림을 그려보도록 하자. 그림 0-3 Oracle Architect ure
  • 9. 참조 =============================================================== 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
  • 10. 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를 확인할 수 있을 것이다. 그러나 이것이 문제되지 는 않을 것임으로 여러분은 헛갈리지 않도록 하자.
  • 11. 그림 0-4 Oracle Install Oracle Installation 다음의 과정은 실제로 oracle10g database를 install하는 부분이다. 먼저 위 화면에서 “Install/Deinstall Pr”을 선택한다. 그러면 다음과 같은 화면이 나타 난다. 여기서는 oracle을 install할 위치와 유형만을 선택하여 진행한다. 여러분은 각자 여러분의 취향에 맞게 변경하면 된다.
  • 12. 그림 0-5 Oracle Install 이제 “다음(N)”을 선택하면 설치 준비화면을 거쳐 잠시 후 다음과 같이 설치환경에 대 한 검사결과 화면을 볼 수 있다.
  • 13. 그림 0-6 Oracle Install 별 이상이 없거나 이상이 있다 하더라도 직접관련이 없다면 역시 “다음(N)”을 선택하 여 설치화면으로 이동한다.
  • 14. 그림 0-7 Oracle Install 이제 설치할 내역들을 살펴본 후 최종적으로 “설치(I)”를 통해 설치 작업을 진행한다. 다음과 같은 화면에서 진행률을 확인할 수 있다.
  • 15. 그림 0-8 Oracle Install 설치가 완료되면 다음의 화면에서 그 결과를 확인한다. 결과에 대한 설명은 차후 본문 에서 다시 살펴볼 것이다. 여기서는 그 과정만 이해하면 되겠다.
  • 16. 그림 0-9 Oracle Install 이제 종료를 선택하여 작업을 완료한다. Database Creation 환경 다음은 windows환경에서 database를 생성하는 과정이다. 먼저 oracle database를 위한 추가적인 directory설정을 다음과 같이하자. 차후 생성될 database의 이름을 “WINORA”로 표기할 것임으로 여러분은 각자 환경에 맞추면 될 것이다. 아래 그림은 필자가 data가 저장될 위치로 “oradata”를 그리고 database를 관리할 directory 구조로 “admin/*”의 구성을 했음을 보여준다.
  • 17. 그림 0-10 Oracle Admin Directory 위 설정은 기본적인 oracle 환경변수인 “ORACLE_BASE”를 “C:oracle”로 설정했음을 말해준다. 다음과 같이 registry정보를 확인하여 여러분 각자의 oracle환경을 제대로 설 정한 후 database생성 작업을 계속 진행해 보자. 그림 0-11 Windows 실행창 이제 registry를 확인하기 위해 다음과 같이 실행을 해보자.
  • 18. 그림 0-12 Windows 실행창 다음은 registry 화면이다. 그림 0-13 Registry 편집기 위와 같이 “HKEY_LOCAL_MACHINESOFTWARE”를 선택한 후 다음과 같이 ORACLE관련 내역을 확인하여 필요한 부분이 있으면 각자 추가하거나 설정을 변경하 도록 한다. 여기서는 ORACLE_BASE를 눈 여겨 보도록 한다. 그림 0-14 Registry 편집기 Database Creation 진행 현재 install이 완료된 위치에서 “C:oracleproduct10.2.0BIN dbca.bat”를 수행하 면 다음과 같은 화면을 볼 수 있다.
  • 19. 그림 0-15 DBCA 실 행창 “다음(N)”을 선택하여 작업 선택화면으로 이동한다. 그림 0-16 DBCA 실 행창
  • 20. 여기서 “데이터베이스 생성”을 선택한 후 “다음(N)”을 click한다. 그림 0-17 DBCA 실 행창 생성할 데이터베이스의 유형을 선택한 후 역시 “다음(N)”을 진행한다.
  • 21. 그림 0-18 DBCA 실 행창 여기서 여러분이 생성하고자 하는 database의 이름을 설정한다. 필자는 “WINORA”라 고 명명하였다. 다시 “다음(N)”을 선택한다.
  • 22. 그림 0-19 DBCA 실 행창 위 화면에서 데이터베이스를 관리할 option을 설정한 후 “다음(N)”을 진행한다. 여러분 은 위 설정을 그대로 따라 하자. 관련 내용들은 차후 본문에서도 다시 설명된다. 다시 “ 다음(N)”을 선택한다.
  • 23. 그림 0-20 DBCA 실 행창 여기서는 생성할 데이터베이스를 위해 암호를 설정한다. 현재 작업상 편의를 위해 모든 기본 암호를 “xmanager”로 설정한 상태이다. 다시 “다음(N)”을 선택한다.
  • 24. 그림 0-21 DBCA 실 행창 이제 생성할 데이터베이스의 storage관련 option이다. 역시 나중에 다시 설명이 되겠지 만 여러분은 기본 선택인 “파일 시스템”을 그대로 설정하고 “다음(N)”을 선택하도록 하자.
  • 25. 그림 0-22 DBCA 실 행창 필자는 OMF를 사용하기 위하여 위와 같이 설정하였다. “다음(N)”을 통해 oracle10g의 특징인 flash recovery area관련 설정을 해보자. 자세한 내용은 나중에 본문에서 다룬다.
  • 26. 그림 0-23 DBCA 실 행창 다음은 스키마를 선택하는 화면이다. 그림 0-24 DBCA 실 행창
  • 27. 다음은 database관련 설정을 하는 부분이다. 그림 0-25 DBCA 실 행창 다음은 현재까지 선택한 내용을 기반으로 만들어질 database 구성 files에 대한 조절을 할 수 있는 화면이다. 그대로 “다음(N)”을 진행하자.
  • 28. 그림 0-26 DBCA 실 행창 이제 마지막 단계로 이동하기 위하여 “다음(N)”을 선택하자. 그러면 다음과 같은 최종 선택 화면이 나타난다. 필자는 database의 생성과 더불어 나중에 활용할 가능성을 염두 에 두고 그 script까지 기록을 남기도록 하였다. 이제 “완료(F)”를 선택하여 생성작업을 수행해 보자.
  • 29. 그림 0-20 DBCA 실 행창 이제 최종 화면인 현재의 설정을 점검하는 popup창을 확인할 수 있다.
  • 30. 그림 0-28 DBCA 실 행창 “확인”을 선택하면 실제 작업이 시작됨과 동시에 작업현황을 볼 수 있다.
  • 31. 그림 0-29 DBCA 실 행창 작업이 완료되면 다음과 같이 최종적으로 작업내용을 확인하는 popup창이 나타난다. 여기서 “종료”버튼을 클릭하면 모든 작업이 완료된다.
  • 32. 그림 0-30 DBCA 실 행창 Database 확인 및 관리 이제 아래와 같이 command 창을 열어서 접속 테스트를 진행하여 이상유무를 확인하 고 database 작업이 정상적으로 이루어졌음을 검증하자.
  • 33. 그림 0-31 SQL*Plus 접속화면 이제 windows환경에서 작업을 하고 싶은 사람들을 위한 준비가 완료되었다. 이런 분들 은 앞으로 본문에서 설명하는 내용들을 그대로 진행하되 OS관련 부분의 directory 구조 를 windows환경에 맞게 변경하면 될 것이다. CF. 기본적으로 생성되는 database의 parameter file은 spfile의 형태로 “ORACLE_HOMEdbs SPFILEWINORA.ORA”로 생성된다. 따라서 현재 필자가 만 든 database에서는 “C:oracleproduct10.2.0 dbs SPFILEWINORA.ORA”가 된다. 이렇게 생성된 database관련 서비스는 최초 windows의 시작과 함께 자동으로 시작되 도록 설정이 되어 있다. 자동화를 원치 않고 여러분이 직접 해당 서비스를 조절하고 싶 다면 아래와 같이 “제어판 관리도구 서비스”를 선택한 후 시작유형을 변경하도 록 한다.