오라클 구성요소의 개요

Part1 오라클서버

1. 오라클 구성요소의 개요

- 오라클 주요 구성요소 : 서버, 인스턴스, 데이터베이스

 

* 인스턴스 :  오라클 인스턴스는 백그라운드 프로세스와 메모리 구조로 구성됩니다. 
                      인스턴스는 사용자가 데이터베이스의 데이터에 접근하기 위해서 반드시

                      시작되어 있어야 합니다

          인스턴스가 시작할 때 System Global Area(SGA)가 할당되고 오라클 
          백그라운드 프로세스들이 시작됩니다.

* 데이타베이스 : 오라클 데이터베이스는 데이터베이스 정보를 위한 실제 물리적인 저장을 
                           제공하는 운영체제 파일들로 구성됩니다 데이터베이스 파일들은 데이터가 
                           일관되게 유지되고 인스턴스 실패 시에 복구될 수 있도록 하는데 사용됩니다

 

1) 오라클 서버

- 데이터베이스 서버는 정보 관리에 아주 중요한 부분입니다. 일반적으로 많은 사용자가 동일한 데이터를 동시에 접근하는 환경에서 서버는 상당한 양의 데이터를 관리합니다. 또한 데이터베이스 서버는 권한이 없는 접근을 금지해야 하며 장애 시에 효과적인 복구를 제공해야 합니다

- 오라클 서버는 오픈되고 포괄적이고 통합된 접근을 제공하는 데이터베이스 관리 시스템

- 오라클 서버는 오라클 인스턴스와 오라클 데이터베이스로 구성

 

2) 오라클 인스턴스

- 오라클 인스턴스는 아래 그림과 같이 System Global Area(SGA) 메모리 구조와 데이터베이스 관리 에 필요한 백그라운드 프로세스들로 구성

  - 하나의 인스턴스는 각각의 운영체제에서 지정하는 방법에 따라 확인되며, 한번에 하나의 데이터베이스에 대해서 오픈되고 사용

- 오라클 인스턴스는 오라클 데이터베이스에 접근할 수 있는 방법

- 오라클 인스턴스는 하나의 데이터베이스에만 오픈

- 오라클 인스턴스는 메모리와 백그라운드 프로세스들로 구성

 

3) 접속과 세션

- 사용자는 오라클 데이터베이스에서 SQL 문장을 수행하기 전에 인스턴스에 접속해야만 합니다

- 인스턴스에 접속하는 과정

  . 사용자가 SQL*Plus를 시작하면 사용자 프로세스가 시작됩니다.

  . 사용자가 오라클 서버에 로그온 하면 서버에는 서버 프로세스가 시작됩니다

  . 서버 프로세스는 사용자 프로세스를 대신하여 인스턴스와 통신합니다

 

-  접속 : 접속은 사용자 프로세스와 서버 프로세스간의 통신 수단입니다. 데이터베이스 사용자는

             다음의 세가지 방법 중에 하나로 오라클 서버에 접속합니다

  . 오라클 인스턴스가 수행되고 있는 시스템에 로그온하여 SQL*Plus를 수행

  . 오라클 인스턴스가 수행되고 있는 시스템과 네트워크로 연결된 컴퓨터에서 프로그램을 수행

  . 사용자 컴퓨터는 오라클 인스턴스와 네트워크로 연결되어 있는 응용프로그램 서버나 네트워크

    서버에 연결되어 있음

- 세션 : 세션은 사용자가 오라클 서버에 접속할 때 시작하여 로그아웃 할 때 끝납니다

※ Dedicated Server 환경에서는 한 개의 사용자 프로세스와 한 개의 서버 프로세스가 통신합니다

※ Shared Server 환경에서는 여러 사용자 프로세스가 한 개의 서버 프로세스를 공유합니다

 

4) 오라클 데이타베이스

 

- 물리적 구조

  . 물리적인 구조는 운영체제 파일들로서 데이터 파일, 리두 로그 파일, 컨트롤 파일로 구성되어 있음

 

 

  . 리두로그파일: 에러 시에 데이터들을 복구하기 위해 데이터베이스에서 만들어진 변경 정보들을

                           갖고 있음

  . 데이터파일 : 실제데이터를 갖고 있음

  . 컨트롤파일 : 데이터베이스의 무결성을 보장하기 위해 필요한 정보들을 갖고 있음

  . 오라클 서버는 데이터베이스를 구성하는 파일들은 아니지만 다른 파일들도 사용합니다

     @ 파라미터 파일 : 오라클 인스턴스의 특징을 정의하는 파라미터들을 갖고 있음

     @ 패스워드 파일 : 오라클 인스턴스를 시작하고 종료할 수 있는 권한이 있는 사용자를 인증

     @ 아카이브 파일 : 복구할 때 필요한 리두 로그 파일을 복사한 파일

 

- 물리적 구조

  . 논리적인 구조는 테이블스페이스, 세그먼트, 익스텐트, 블럭으로 구성되어 있으며 데이터베이스의

    물리적인 공간이 어떻게 사용되어 지는지를 나타냅니다

 

  . 테이블 스페이스 : 오라클 데이터베이스는 한 개 이상의 테이블 스페이스를 갖고 있음 

                               한 개의 테이블 스페이스는 한 개 이상의 세그먼트를 갖고 있음

  . 세그먼트 : 한 개의 세그먼트는 익스텐트들로 만들어짐

  . 익스텐트 : 한 개의 익스텐트는 논리적인 블럭들로 만들어 짐

  . 블럭 : 한 개의 블럭은 읽고 쓰기 위한 가장 작은 단위

 

 

2. 메모리 구조

- 오라클 메모리 구조는 System Global Area(SGA)와 Program Global Area(PGA)로

   구성되어 있습니다. SGA는 인스턴스가 시작할 때 할당되며 오라클 인스턴스의

   기본 구성요소입니다. PGA는 서버 프로세스가 시작할 때 할당됩니다 

 

1) System Global Area

- SGA는 Shared Global Area라고도 부릅니다. SGA에는 데이터베이스 프로세스들에 의해

   공유되는  데이터베이스 정보와 오라클 서버를 위한 데이터와 제어 정보가 저장되며, 오라클이

   설치된 컴퓨터의 가상 메모리에 할당됩니다

- SGA의 종류

  . Shared Pool

  . Database Buffer Cache

  . Redo Log Buffer

  . Large Pool

  . Java Pool

- 동적SGA

  . 오라클 9i부터, 동적 SGA는 인스턴스를 종료하지 않고 SGA 형태를 변경할 수 있는 기본조직을

    이행하므로, 인스턴스를 종료하지 않고 Database Buffer Cache와 Shared Pool의 크기를 변경할

    수 있습니다. Database Buffer Cache와 Shared Pool의 크기는 처음에는 작게 구성되었다가

    그들의 작업에 따라 SGA_MAX_SIZE의 최대 크기까지 성장 또는 축소될 수 있습니다

- SGA 크기

  . DB_CACHE_SIZE : 기본 블럭들의 Cache 크기 / UNIX의 기본은 48MB, NT의 기본은 52MB임

  . LOG_BUFFER : 리두 로그 버퍼에 할당될 바이트 수

  . SHARED_POOL_SIZE : 공유풀에 할당될 바이트 수 /기본은 16MB, 64bit에서는 64MB임

  . LARGE_POOL_SIZE : 대형풀의 크기 / PARALLEL_AUTOMATIC_TUNING=true로 설정되지

                                      않으면 기본은 0임

  . JAVE_POOL_SIZE : 자바풀의 크기, 기본은 24MB임

- SGA 크기 : SGA_MAX_SIZE - DB_CACHE_SIZE - LOG_BUFFER - SHARED_POOL_SIZE -

                      LARGE_POOL - JAVA_POOL

- 할당 단위 : Granule은 연속된 가상 메모리 할당 단위입니다. Granule의 크기는 SGA_MAX_SIZE

                      파라미터 값에 의해 계산된 SGA 전체 크기에 의존합니다

  . 계산된 SGA 크기가 128MB보다 적을 때 Granule 크기는 4MB

  . 계산된 SGA 크기가 128MB보다 클 때 Granule 크기는 16MB

  . Database Buffer Cache와 Shared Pool은 Granule 경계에 따라 확장되고 축소될 수 있습니다.  

    인스턴스가 시작할 때 오라클 서버는 각각의 구성요소에 한 개의 Granule을 할당합니다.

    데이터베이스가 계속 사용되면서 그들이 요구하는 것에 따라 더 많은 Granule을 할당합니다

  . SGA의 최소 구성은 다음과 같이 3개의 Granule입니다

    Redo Buffer를 포함한 Fixed SGA에 1개를 할당

    Database Buffer Cache에 1개를 할당

    Shared Pool에 1개를 할당

2) Shared Pool

- Shared Pool은 가장 최근에 실행된 SQL 문장과 가장 최근에 사용된 Dictionary를 저장하기 위해

   사용되며 아래 그림과 같이 Library Cache와 Data Dictionary Cache로 구성됩니다

 

-  Shared Pool 의 크기

  . Shared Pool은 다시 사용될 SQL Execution plan과 PL/SQL package, procedure, function과

    Cursor 정보 들을 공유하기 위해 사용됩니다

  . Shared Pool의 크기는 초기 파라미터 SHARED_POOL_SIZE에 의해 결정됩니다.

    또한 ALTER SYSTEM SET 명령을 사용하여 동적으로 조정할 수 있습니다. 그렇지만

    전체 SGA 크기는 SGA_MAX_SIZE를 초과 할 수 없습니다

- 초기 파라미터 SHARED_POOL_SIZE로 크기를 결정합니다

- ALTER SYSTEM SET SHARED_POOL_SIZE = 64M

- 전체 SGA 크기는 SGA_MAX_SIZE를 초과 할 수 없습니다

- Library Cache

  . Library Cache 크기는 Shared Pool의 크기에 의존하며 가장 최근에 사용된 SQL과 PL/SQL 문장

    에 관한 정보가 저장됩니다. 그러므로 Shared Pool의 크기가 너무 작으면, 이들 문장이 계속해서

    Library Cache에 올라오게 되어 성능에 영향을 미치게 됩니다

  . Library Cache는 LRU 알고리즘이 사용되므로 Cache가 꽉 차면 최근에 적게 사용된 Execution

    Plan과 Parse Tree를 제거하여 새로운 문장을 위한 공간을 만듭니다

  . Shared SQL : 다시 수행될 SQL문장을 위해 Execution Plan과 Parse Tree를 저장하며 동일한

                          SQL 문장이 다시 수행되면 Shared SQL에서 Parse 정보를 가져옴

                          동일한 문장이 되려면 글자와 스키마와 변수가 같아야 함

  . Shared PL/SQL : 가장 최근에 사용된 PL/SQL 문장을 저장

- Data Dictionary Cache

  . Data Dictionary Cache는 Row Cache 라고도 부릅니다. 오라클 서버에 의해 Dictionary 정보가

    필요하면 Dictionary Table로부터 정보를 읽어 Data Dictionary Cache에 저장합니다. Data

    Dictionary의 크기는 Shared Pool에 의존하므로, 만약 Data Dictionary의 크기가 너무

    작으면 서버에 의해 필요한 정보를 반복적으로 Dictionary Table로부터 읽게 됩니다. 그러므로

    Dictionary Cache로부터 읽는 것보다 속도가 느리게 됩니다

  . Data Dictionary Cache의 기능

    가장 최근에 사용된 Database 정보를 저장함

    파일, 테이블, 인덱스, 사용자, 권한, 기타 다른 객체 정보들이 저장됨

    Parse 단계에서 서버 프로세스가 Dictionary 정보를 찾음

 

3) Database Buffer Cache

 

- Query문을 수행하면 오라클 서버는 Database Buffer Cache에서 원하는 블럭들을

   찾습니다. 해당 블럭을 Buffer Cache에서 찾지 못하면 데이터 파일에서 블럭을 읽어

   Database Buffer Cache에 저장해 놓으므로 같은 블럭에 대한 요구가 있으면 메모리에서 그

   블럭을 찾을 수 있어 Physical Read를 하지 않아도 됩니다. 오라클 서버는 Database Buffer

   Cache에서 새로운 블럭에 대한 공간을 만들기 위해 최근에 사용이 안된 블럭들을 쫓아내는 LRU

   알고리즘을 사용합니다 

- Database Buffer Cache 크기

  . Database Buffer Cache안에 있는 각 버퍼의 크기는 DB_BLOCK_SIZE 파라미터에 의해 결정되는

    오라클 블럭 크기와 같습니다. Database Buffer Cache는 독립적인 sub-cache들로 구성되는데,

    DB_BLOCK_SIZE 파라미터는 기본 블럭 크기를 결정하며 SYSTEM 테이블스페이스에 사용됩니다

  . Database Buffer Cache 크기를 결정하는 파라메타

    DB_CACHE_SIZE : 기본 Buffer Cache 크기를 결정,반드시 지정하여야 하며 0으로 설정할 수

                                 없음

   DB_KEEP_CACHE_SIZE : 다시 사용되므로 메모리에 머무르게 하고 싶은 블럭을 위한 버퍼

                                           크기를 지정함

    DB_RECYCLE_CACHE_SIZE : 다시 사용되지 않으므로 메모리에서 제거하고 싶은 블럭을 위한

                                                 버퍼 크기를 지정함

[출처] 오라클 기초|작성자 myjoo80

- Buffer Cache Advisory

  . Buffer Cache Advisory는 다른 Cache 크기를 가졌을 때의 행동을 예견하기 위한 통계를 모으는

    작업을 활성화 혹은 비활성화 할 수 있다는 특징을 가지고 있습니다. 이 통계에 의해 제공되는

    정보는 주어진 작업에 따라 Database Buffer Cache 크기를 적당하게 조절할 수 있도록 합니다.

    Buffer Cache Advisory 정보는 V$DB_CACHE_ADVICE에 저장되며, DB_CACHE_ADVICE 초기

    파라미터로 활성화 할 수 있습니다

  . OFF : Advisory를 위한 메모리를 할당하지 않음

  . ON : CPU와 메모리의 과부하를 초래 / OFF 상태에서 ON으로 변경하면 ORA-4031 에러가 발생함

            / READY 상태에서 ON으로 변경하면 메모리가 할당되어 있어 에러가 발생하지 않음

  . READY : Advisory는 OFF되어 있지만 메모리는 할당되어 있음

 

4) Redo Log Buffer

 

- Redo Log Buffer는 데이터 파일 블럭들에 만들어진 변경을 포함하고 있는 순환 buffer입니다 

- 이 정보는 리두 엔트리 안에 저장됩니다 /

  . 리두엔트리 : INSERT, UPDATE, DELETE, CREATE, ALTER, DROP 명령에 의해 만들어진 변경전

                       의 데이타를 다시 만들기 위해 필요한 정보를 갖고 있음 

- Redo Log Buffer 크기 : 초기 파라미터 LOG_BUFFER에 의해 결정됩니다

 

5) Large Pool

- Shared Server, Oracle XA, Parallel Query Buffers에서 세션 메모리를 Large Pool에

   할당하므로 오라클은 공유하는 SQL 문장을 저장하기 위해 Shared Pool을 사용할 수 있습니다.

   따라서 Shared Pool 안의 영역에서 짐을 덜 수 있습니다. Shared Pool은 Shared Session 정보,

   I/O, Backup, Recover 프로세스들을 위하여 SQL Parse Tree를 메모리에서 포기할 필요가

  없습니다. 그러므로 Shared SQL을 확장하고 축소하며 발생하는 과부하를 줄여 성능이 좋아집니다

- Backup and Restore

  . BACKUP_DISK_IO=n, BACKUP_TAPE_IO_SLAVE=true 파라미터가 정의되었으면 Recovery

     Manager (RMAN)는 Large Pool을 사용합니다. 만약 Large Pool이 충분히 크지 않으면 Large

     Pool에 메모리 할당은 실패합니다. RMAN은 에러 메세지를 Alert! Log File에 기록하고 Backup이

    나 Restore를 위하여 I/O slaves를 사용하지 않습니다

- Parallel execution

  . PARALLEL_AUTOMATIC_TUNING=true 파라미터가 정의되었으면 Large Pool을 사용하고 그렇지

    않으면 Shared Pool을 사용합니다

- Large Pool 크기

  . LARGE_POOL_SIZE 파라미터에 의해 결정되며 이 파라미터는 동적이 아닙니다

- Large Pool 과 LRU list

  . Large Pool은 LRU list를 사용하지 않습니다. LRU list를 사용하는 Shared Pool안의 예약된

     공간과 다릅니다

 

6) Java Pool

- Java Pool은 선택적이지만 JAVA를 설치하거나 사용하려면 필요합니다. 크기는 JAVA_POOL_SIZE

   파라미터에 의해 결정되며, 기본 크기는 24MB입니다

 

7) Program Global Area

 

- Program Global Area 혹은 Process Global Area (PGA)는 단일 서버 프로세서나

  단일 백그라운드 프로세서를 위한 데이터와 제어정보를 갖고 있습니다. PGA는 프로세스가 시작할

  때 할당되고 프로세스가 종료되면 해제됩니다. 여러 개의 프로세스들에 의해 공유되는 SGA에 반해

  PGA는 단지 한 개의 프로세스에 의해 사용되는 영역입니다

- PGA 의 내용

  . PGA의 내용은 인스턴스가 Dedicated Server 혹은 Shared Server에서 운영되느냐에 따라 달라

     집니다. 일반적으로 PGA는 다음과 같은 정보를 포함

     Private SQL Area : bind 정보와 실행 메모리 구조 같은 데이터를 포함

     Session 메모리 : 세션 변수와 세션과 관련된 다른 정보를 포함

     SQL Work Area : Sort, Hash-join, Bitmap merge, Bitmap 생성시 사용

 

3. 프로세스 구조

오라클은 여러 가지 종류의 프로세스들을 갖고 있습니다. 사용자가 오라클 서버에
접속했을 때 시작하는 사용자 프로세스, 사용자가 세션을 만들었을 때 시작하여
오라클 인스턴스와 접속하는 서버 프로세스, 오라클 인스턴스가 시작했을 때
시작하는 백그라운드 프로세스가 그것입니다

 

1) 사용자 프로세스

 

- 데이터베이스의 정보를 요구하는 사용자는 먼저 오라클 서버와 접속을 해야 합니다. SQL*Plus

   같은 Tool을 사용하여 접속하면 사용자 프로세스가 시작됩니다. 사용자 프로세스는 오라클 서버와

   직접 작용하지 않는 대신 세션을 만들고 서버 프로세스를 시작시키는 User Program Interface

   (UPI)를 통해 접속합니다

 

2) 서버 프로세스

 

- 사용자가 접속하면 사용자의 요구를 처리하기 위해 서버 프로세스가 시작됩니다.

   서버 프로세스는 Dedicated Server process 혹은 Shared Server process가 될 수 있습니다.

   Dedicated Server 환경에서, 서버 프로세스는 한 개의 사용자 프로세스 요구를 처리하며 사용자

   프로세스가 종료하면 서버 프로세스도 종료합니다. 반면 Shared Server 환경에서, 서버

   프로세스는 여러 개의 사용자 프로세스 요구를 처리합니다. 서버 프로세스는 Oracle Program

   Interface(OPI)를 사용하여 오라클 서버와 통신합니다 

 

3) 백그라운드 프로세스

- 오라클은 뒤에서 설명할 다섯 개의 필수적인 백그라운드 프로세스와 옵션이 사용됐을 때

   시작하는 선택적인 백그라운드 프로세스가 있습니다

  . RECO : Recover

  . QMNn : Advanced Queuing

  . ARCn : Archiver

  . LCKn : Rac Lock Manager - Instance Locks

  . LMON : RAC DLM Monitor - Global Locks

  . LMDn : RAC DLM Monitor - Remote Locks

  . CJQ0 : Coordinator Job Queue background process

  . Dnnn : Dispatcher

  . Snnn : Shared Server

  . Pnnn : Parallel Query Slaves

- Database Writer (DBWn)

 

 

. 서버 프로세스는 변경을 Database Buffer Cache 안의 언두 블럭과 데이터 블럭에 기록합니다.

  DBWn은 Database Buffer Cache 안의 Dirty Buffer들을 데이터 파일에 기록합니다. 이렇게

  함으로써 Database Buffer Cache 안에 사용할 수 있는 많은 수의 Free Buffer를 보장할 수

  있습니다. 또한 서버 프로세스는 Database Buffer Cache 안에서만 변경을 하므로 데이터베이스의

  성능이 향상됩니다

. DBWn은 다음과 같은 경우가 될 때까지 데이터 파일에 기록을 지연합니다

  Checkpoint가 발생했을 때

  Dirty Buffer의 수가 한계에 도달했을 때

  서버 프로세스가 지정된 수의 블럭을 읽는 동안 Free Buffer를 찾지 못했을 때

  시간이 경과했을 때

  Real Application Clusters (RAC) 환경에서 ping을 요구했을 때

  테이블스페이스를 OFFLINE 시킬 때

  테이블스페이스를 READ ONLY로 변경시킬 때

  테이블을 DROP 하거나 TRUNCATE 시킬 때

  테이블스페이스를 BEGIN BACKUP 했을 때

- Log Writer (LGWR)

 

 

  . LGWR는 순차적으로 Redo Log Buffer를 리두 로그 파일에 기록합니다. 리두는 복구에 사용되므로

    LGWR는 리두가 디스크에 쓰여진 후에 COMMIT 명령을 확인합니다. LGWR는 데이터 파일에 기록

    하기 위해 DBWn을 부를 수도 있습니다 

  . LGWR는 다음과 같은 경우에 발생합니다

    COMMIT 명령이 수행됐을 때

    Redo Log Buffer가 1/3 이상 찼을 때

    Redo Log Buffer 안의 변경이 1MB를 초과했을 때

    DBWn이 Database Buffer Cache의 변경된 블럭을 데이터 파일에 기록하기 전 매 3초 마다

 

- System Monitor (SMON)

 

  . 오라클 인스턴스가 실패하면, 디스크에 기록되지 않은 SGA 안의 정보는 잃어버립니다.

    인스턴스를 잃은 후에 데이터베이스를 다시 시작하면 SMON이 자동적으로 인스턴스

    복구를 수행합니다 

  . 다음과 같은 순서로 인스턴스가 복구

    

 

- Process Monitor (PMON) 

 

 

. PMON은 실패한 프로세스를 다음과 같이 정리

  사용자의 현재 트랜잭션을 취소

  현재 걸려 있는 테이블 잠금과 로우 잠금을 해제

  사용자에 의해 유지되고 있는 다른 자원을 해제

  죽은 Dispatcher를 다시 시작함

 

- Checkpoint (CKPT)

 

 

. 매 3초마다 CKPT 프로세스는 리두로그 파일에서 복구가 시작될 위치를 확인하기 위해 컨트롤 파일

  안에 데이터를 저장합니다. 이것을 Checkpoint라고 부릅니다 

  Checkpoint의 목적은 한 시점 전에 Database Buffer Cache에서 수정된 모든 버퍼들이 데이터

  파일에 기록된 것을 보장하는 것입니다. 이 시점이 인스턴스 실패 시에 복구를 시작할 위치입니다.

  DBWn는 그 시점 이전에 Database Buffer Cache에서 변경된 모든 버퍼들을 기록합니다

  로그 스위치가 발생할 때 CKPT는 데이터 파일의 헤더에 Checkpoint 정보를 기록합니다

. Checkpoint는 다음과 같은 이유로 발생

  1. 메모리에서 수정된 데이터 블럭들이 주기적으로 디스크에 쓰여져 시스템 실패시에 데이터가

     손실되지 않도록 하기 위해

  2. 인스턴스 복구에 필요한 시간을 줄이기 위해, Checkpoint 이후의 리두 로그 엔트리만이 복구 필요

  3. 모든 COMMIT 된 데이터들이 데이터베이스 종료시에 데이터 파일에 기록된 것을 보장하기 위해

 

- Archiver (ARCn)

 

  . ARCn은 데이터베이스의 구성에 따라 선택이지만 디스크 손실 후에 데이터베이스를 복구하기 위해

    매우 중요합니다. 
    리두 로그 파일이 꽉 차면 오라클 서버는 다음 리두 로그 파일에 쓰기를 시작합니다. 한 개의 리두

    로그 파일에서 다음 리두 로그 파일로 옮겨 쓰는 것을 로그 스위치라고 부릅니다. 
    ARCn 프로세스는 로그 스위치가 발생하면 꽉 찬 리두 로그 파일의 백업을 시작합니다. 이렇게

    리두 로그 파일이 다시 사용되기 전에 자동적으로 백업되어 데이터베이스에서 만들어진 모든

    변경은 보관됩니다. DBA는 디스크가 깨진 경우 그 시점까지 데이터베이스를 복구할 수 있습니다 

. NOARCHIVELOG 혹은 ARCHIVELOG 모드로 운영

  NOARCHIVELOG : 리두 로그 파일은 로그 스위치가 발생할 때 겹쳐 쓰여 집니다

                              LGWR는 그 그룹에 대한 Checkpoint가 완료될 때까지 리두 로그 그룹을

                              겹쳐 쓸 수 없습니다. 이것은 COMMIT 된 데이터들이 인스턴스 실패 시에

                              복구될 수 있음을 보장합니다

  ARCHIVELOG  : 리두 로그 그룹은 다시 사용되기 전에 반드시 기록되어야 합니다

                           데이터베이스에서 만들어진 변경은 리두 로그 파일에 기록되어 있으므로 DBA는

                           데이터 파일의 물리적인 백업과 아카이브 파일을 사용하여 COMMIT 된 데이터의

                           손실 없이 데이터베이스를 복구할 수 있습니다

 

 

4. SQL 문장처리

사용자가 SQL*Plus를 사용하여 오라클 서버에 접속하면 사용자 프로세스가 시작하여
세션을 만들고 서버 프로세스를 시작시킵니다.
사용자 프로세스에서 수행시킨 SQL 문장을 서버 프로세스에서 처리할 때 사용되는 
구성요소는 SQL 문장의 종류에 따라 다릅니다. 어떤 구성요소는 SQL 문장 처리에
사용되지 않기도 합니다

- QUERY 문 처리

  . Parse (구문분석)

    1. 동일한 문장을 Library Cache에서 찾음

    2. 문법을 체크

    3. 객체명과 권한을 체크

    4. Parse 과정에서 사용되는 객체에 잠금을 함

    5. Execution plan을 생성하여 Library Cache에 저장함

  . Bind : 변수들에 값을 지정합니다

  . Execute : 문장을 처리합니다

  . Fetch : 사용자 프로세스에 데이터를 보냅니다

- DML 문 처리

  . Parse (구문분석)

  . Bind

  . Execute

    1. 데이터 블럭과 undo 블럭을 Buffer Cache에서 찾음

    2. 없으면 데이터 파일에서 읽어서 Buffer Cache에 저장함

    3. 변경될 데이터에 잠금을 함

    4. Redo Log Buffer에 변경 전 데이터와 변경 후 데이터를 기록

    5. 변경 전 데이터를 undo 블럭에 기록하고 데이터 블럭을 변경함

    6. Buffer Cache 안의 변경된 블럭은 Dirty Buffer로 기록됨

  . DELETE와 INSERT 문의 처리과정도 이와 유사합니다. DELETE 문의 변경 전 데이터는 삭제된

    로우의 전체 칼럼 값이며, INSERT 문의 변경 전 데이터는 로우의 위치 정보입니다

- DDL 문 처리

  . DDL 문의 실행은 DML 문이나 QUERY 문의 실행과 다릅니다.  왜냐하면 DDL 문의 성공은

    Dictionary에 쓰기를 요구합니다. 실제 Parsing은 Parsing과 Dictionary 검색과 Execution을

   포함합니다. Transaction Management, Session Management, System Management

   SQL 문이 Parse와 Execute 단계를 사용하여 처리됩니다

출처 - http://mes2good.egloos.com/763061#763061_1