오라클 서버는 정보 관리(information management)를 위한 공개되고 이해하기 쉬우며 통합된 접근법을 제공하는 객체 관계형 관리 시스템입니다.

오라클 데이터베이스 사용자
 데이터베이스 사용자는 다음중의 한가지 방법으로 오라클 서버에 접속할 수 있습니다.

  -호스트(즉, 오라클 서버가 수행되고 있는 기계)에 직접 로그인(예, 오라클이     실행되고 있는 UNIX 기계에 접속하여,  Server Manager를 사용하여  
    데이터베이스에 접근할 수 있도록 호스트에 직접 로그인 합니다.)

  -two-tiered (client-server) 접속. 사용자가 로그인한 기계에서 오라클 서버가    수행중인 기계로 직접 접속. (예, Windows 95 환경의 개인용 컴퓨터에서
    Developer/2000 응용프로그램을 실행시켜  NT 서버에 있는 오라클
    데이터베이스에 접근하는 것이 two-tiered 접속을 사용하는 것입니다.)

  -three-tiered 접속. 사용자의 기계가 응용프로그램 또는 네트워크
    서버와 통신하며, 이 서버는 네트워크를 통해 오라클 서버가 실행중인
    기계와 접속됩니다. (UNIX 호스트에서 실행되고 있는 오라클
    데이터베이스로부터 데이터를 읽어 들이기 위해 NT 서버의 응용
    프로그램을 사용하는 네트워크 컴퓨터 상의 브라우저를 실행시키는
    경우입니다.)

 데이터베이스 사용자는 SQL*Plus같은 툴이나 SQL 문을 포함하는 응용 프로그램을 사용하여 SQL 문을  직접 실행할 수 있습니다. 오라클 서버 프로세스들은 이러한 명령들을 처리하여 사용자에게 그 결과를 리턴해 줍니다.

오라클 데이터베이스 관리자
 데이터베이스 관리자는 서버가 사용자의 요구를 처리할 수 있도록 오라클 서버를 유지 보수할 책임을 갖습니다. 효과적인 유지보수를 위해서는 오라클 구조를 이해해야 합니다.
이 과정는 사용자가 오라클 서버가 실행되고 있는 기계에 직접 로그인 하여 접속하거나 클라이언트-서버 모델을 이용하여 접속하는 오라클 서버를 생성하고 유지하는데 촛점을 두었습니다. 

 

데이터베이스에 접속
 오라클 서버를 사용하려면 사용자는 우선 데이터베이스와 접속을 해야 합니다. 다음 단계를 따라 데이터베이스에 접속합니다.

  - SQL*Plus 같은 툴을 시작하거나  Developer/2000 Form같은 툴을 사용하여      개발된 응용  프로그램을 실행시켜 사용자 프로세스(user process)를 생성      합니다.
     클라이언트-서버 모델에서는 툴이나 응용 프로그램이 클라이언트 기계에서
     실행됩니다.
 
  - 가장 간단한 구성(configuration)에서는 사용자가 사용자 이름, 비밀 번호,      그리고 데이터베이스를 지정하여 오라클 서버에 접속할 때 오라클 서버가      수행되는 기계에서 프로세스가 하나 생성됩니다. 이 프로세스는 서버
     프로세스(server process)라 불립니다. 서버 프로세스는 클라이언트에서      수행되는 사용자 프로세스를 대신하여 오라클 서버와 통신합니다.

접속
 접속은 사용자 프로세스와 오라클 서버 간의 통신 경로입니다. 오라클 서버가 있는 기계에서 툴이나 응용 프로그램을 실행한다면 통신 경로는 기계 상에서 사용 가능한 프로세스간 통신 처리 방법(interprocess communication mechanisms)을 이용하여 수립됩니다. 클라이언트 기계에서 툴을 실행한다면 오라클 서버와의 통신에 네트워크를 이용하기 위해 네트워크 소프트웨어가 사용됩니다.

세션
 세션은 사용자의 오라클 서버와의 특정 접속입니다. 세션은 오라클 서버가 사용자를 검증(validate)할 때 시작되고 사용자가 로그 아웃할 때나 비정상적으로 종료되었을 때 끝납니다. 동시에 여러 개의 툴이나 응용 프로그램, 또는 터미널에서 로그인 한다면 동시에 여러 개의 세션을 쓸 수 있습니다. 일부 특별한 데이터베이스 관리 도구를 제외하면 데이터베이스 세션을 시작하려면 오라클 서버가 사용 가능한 상태 이어야 합니다.

문제 해결
 사용자나 응용 프로그램이 사용할 수 없는 오라클 서버에 접속하려 할 때 "ORA-01034: Oracle not available" 에러 메시지가 표시 됩니다. 이 문제를 해결하려면 데이터베이스 관리자가 오라클 서버를 시작해야 합니다.

 


클라이언트라고도 알려져 있는 사용자 프로세스는 다음과 같은 특성을 가집니다.
  
 -사용자가 SQL*Plus나 Server Manager, 또는 Developer/2000 응용 프로그램
   같은 툴이나 응용 프로그램을 실행할 때 생성됩니다.
 -클라이언트(즉, 사용자가 직접 로그인 한 기계)에서 실행됩니다.
 -툴이 시작될 때 프로세스는 시작되고 사용자가 종료하거나 강제로 중단되었을    때 종료됩니다.
 -사용자 프로세스는 사용자 프로그램 인터페이스(UPI)를 제공합니다.
   UPI는 사용자가 요구할 때마다 오라클 서버를 호출합니다.

 


서버 프로세스는 다음과 같은 특징을 갖습니다.

  -오라클 서버와 같은 기계에서 실행됩니다.
  -전용 서버(dedicated server)라고 알려진 가장 간단한 구성에서 각 서버 프로     세스는 사용자 프로세스를 하나씩 담당합니다. 서버 프로세스는 사용자가     접속을 요구할 때 생성되며 일반적으로 사용자가 접속을 끊을 종료 됩니다.
  -각 서버 프로세스는 PGA(Program Global Area)라고 불리우는 메모리 영역을     사용합니다. PGA는 본 장의 뒷부분에서 다루어질 것입니다.
  -서버 프로세스는 사용자의 요구에 따라 오라클 서버와 통신하는데 사용되는     OPI(Oracle Program Interface)를 제공합니다.
  -서버 프로세스는 사용자 프로세스에게 상태 정보와 결과를 리턴합니다.

주
 다중 스레드 서버(MTS) 구성을 사용하면 여러 개의 사용자 프로세스가 서버 프로세스를 공유하는 것이 가능합니다. MTS는 Oracle8: Network Administration 과정에서 더 자세히 다루어 집니다. 

데이터베이스 이름(DB_NAME)으로 식별할 수 있는 오라클 데이터베이스는 물리적 구조를 뜻하며 운영 체제 파일들로 구성되어 있습니다. 데이터베이스 이름을 인스턴스의 이름과 다르게 짓는 것이 가능하지만 관리의 편리를 위해 같은 이름을 사용할 것을 권장하는 바입니다.

데이터베이스 파일
 데이터베이스를 구성하는 파일은 사용자 데이터와 적절한 데이터베이스 작업에 필요한 부가 정보를 포함합니다.
오라클 데이터베이스는 다음과 같은 유형의 파일들로 구성되어 있습니다.
 
  -데이터 파일: 데이터 딕셔너리, 사용자 오브젝트, 그리고 현재의 트랜잭션에     의해 수정된 데이터의 이전 이미지를 저장합니다.  데이터베이스는 최소한     하나의 데이터 파일을 가지고 있습니다.
  -리두 로그 파일: 실패했을 경우 데이터의 재구성에 필요한 데이터베이스에
    가해진 변경 사항 기록을 담고 있습니다.(데이터베이스는 최소한 두 개의    
    리두 로그 파일이 필요합니다.)
  -콘트롤 파일: 데이터베이스 무결성을 유지하고 검증하는데 필요한 정보를
    담고 있습니다.(데이터베이스는 최소한 하나의 콘트롤 파일이 필요합니다.)

 

데이터베이스 파일과는 별도로 오라클 서버는 다음과 같은 다른 파일도 사용합니다.

  -파라미터 파일: 오라클 인스턴스의 특징을 정의하는데 사용됩니다.
  -패스워드 파일: 권한이 있는 데이터베이스 사용자를 인증하는데 사용됩니다   -아카이브 리두 로그 파일: 매체 실패(media failures)시 복구에 필요할 수     있는 리두 로그 파일의 오프라인 사본입니다.

 본 장의 다음 부분에서는 서버 프로세스가 사용자 프로세스의 요구에 답하기 위하여 오라클 인스턴스의 구성 요소와 데이터베이스를 사용하는 방법을 설명할 것입니다.

오라클 서버는 오라클 인스턴스와 오라클 데이터베이스로 구성되어 있습니다. 오라클 인스턴스는 데이터베이스를 관리하기 위해 오라클 서버가 사용하는 SGA(System Global Area)라는 메모리 구조와 백그라운드 프로세스로 이루어져 있습니다. 운영 체제에서 ORACLE_SID를 설정함으로써 식별되는 오라클 인스턴스는 한번에 단 하나만의 데이터베이스를 오픈하여 사용할 수 있습니다.

SGA(System Global Area)
오라클 인스턴스의 메모리 구조는 오라클 서버를 위한 데이터와 제어 정보를 담고 있는 SGA라는 메모리 영역에 들어있습니다. SGA는 오라클 서버가 들어있는 컴퓨터의 가상 메모리에 할당됩니다. SGA는 다음과 같은 메모리 구조로 구성됩니다.
  
  -공유 풀: 가장 최근에 실행된 SQL과 데이터 딕셔너리에서 가장 최근에     사용된 데이터 등의 정보를 저장합니다.

  -데이터베이스 버퍼 캐쉬: 가장 최근에 사용된 데이터를 저장합니다.

  -리두 로그 버퍼: 인스턴스를 사용하여 데이터베이스에 가해진 변경 사항    을 기록합니다.

이러한 구조의 이용은 뒷장에 자세히 다루어질 것입니다.

백그라운드 프로세스
인스턴스의 백그라운드 프로세스는 전체 시스템의 무결성이나 성능에는 손상을 주지 않으면서 동시에 여러 사용자의 요구를 처리하는데 필요한 공통 기능을 수행합니다.  구성(configuration)에 따라 각 오라클 인스턴스는 여러 백그라운드 프로세스를 사용할 수 있지만 모든 인스턴스는 기본적으로 다음 다섯 가지의 백그라운드 프로세스를 가져야 합니다

각 프로세스의 기능은 본 과정 뒷 부분에서 자세히 다루어질 것입니다. 

질의문 실행
 다음은 질의문을 처리하는 주요 단계입니다.

1 구문 분석: 사용자 프로세스는 질의문을 분석 또는 컴파일하라는
   요구와 함께 서버 프로세스로 질의문을 보냅니다. 서버 프로세스는 명령의
   유효성을 검사한 후 공유 풀이라는 SGA의 영역을 사용하여 문장을
   컴파일합니다. 끝으로 서버 프로세스는 사용자 프로세스에게 상태(구문  
   분석의 성패 여부)를 리턴합니다.

2 실행: 서버 프로세스는 데이터를 읽어 올 준비를 합니다.

3 인출: 서버가 질의문에 의해 읽혀진 행들을 사용자에게로 리턴합니다.        전송에 이용하는 메모리 양에 따라 사용자에게 질의문 결과를 전송하기    위해 한번, 또는 여러번의 인출이 필요합니다.

 


 공유 풀은 구문 분석 단계에서 사용하는 SGA의 일부분입니다. 공유 풀의 크기는 파라미터 파일의 SHARED_POOL_SIZE라는초기화 파라미터에 지정합니다. 아래의 공유 풀의 구성 요소는 SQL 문을 분석하는데 사용됩니다.

라이브러리 캐쉬
 라이브러리 캐쉬는 가장 최근에 사용된 SQL 문에 대한 다음 정보를 저장하고 있습니다.
  -문장의 텍스트
  -문장의 컴파일된 버전인 구문 분석 트리(Parse tree)
  -옵티마이저에 의해 결정된, 문장을 실행하기 위해 따라야할 단계를 정의한     실행 계획

 라이브러리 캐쉬가 이와 같은 정보를 저장하고 있기에 실행 계획이 다른 문장에 의해 없어지기 전에 질의문이 재실행되면 서버 프로세스는 문장을 다시 구문 분석할 필요가 없습니다. 따라서 라이브러리 캐쉬는 응용 프로그램의 성능을 향상시키는데 도움이 됩니다.

 데이터 딕셔너리 캐쉬
 딕셔너리 캐쉬, 또는 row cache 라고도 불리우는 데이터 딕셔너리 캐쉬는 공유 풀의 일부분으로써 테이블, 컬럼 정의, 사용자 이름, 암호, 사용 권한같은 가장 최근에 사용된 데이터 딕셔너리 정보를 저장하고 있습니다.
구문 분석 단계에서 서버 프로세스는 SQL 문에 지정된 오브젝트 이름을 찾아내고 접근 권한을 검증하기 위해 딕셔너리 캐쉬의 정보를 찾아봅니다. 필요하다면 서버 프로세스는 데이터 파일로부터 이 정보들을 로드합니다.

 

질의문이 처리될 때 서버 프로세스는 필요한 블록을 데이터베이스 버퍼 캐쉬에서 찾습니다. 블록이 데이터베이스 버퍼에서 없으면 서버 프로세스는 데이터 파일로부터 블록을 읽어와 그 사본을 버퍼 캐쉬에 위치시킵니다. 이후에 같은 블록이 계속 필요하고 메모리에서 찾을  수 있으면 물리적으로 읽지 않아도 됩니다.

데이터베이스 버퍼 캐쉬의 기능
 데이터베이스 버퍼 캐쉬, 간단히 버퍼 캐쉬는 가장 최근에 사용된 데이터 블록을 저장하는데 사용되는 SGA의 영역입니다. 버퍼 캐쉬의 각 버퍼 크기는 데이터 블록의 크기와 같으며 DB_BLOCK_SIZE 파라미터로 지정할 수 있습니다. 버퍼의 갯수는 DB_BLOCK_BUFFERS 파라미터의 값과 같습니다. 오라클 서버는 LRU(least recently used) 알고리즘을 사용하여 버퍼 캐쉬에 새로운 블록을 불러올 때 최근에 접근한 적이 없는 버퍼를 없앱니다.  


서버 프로세스는 인스턴스에 의한 변경 사항을 SGA의 일부분인 리두 로그 버퍼에 기록합니다. 리두 로그 버퍼는 다음과 같은 특징을 갖습니다.
   
   -크기는 LOG_BUFFER 파라미터에 의해 바이트 단위로 정의됩니다.
   -변경 사항(즉, 변경된 블록, 변경 위치, 새 값)을 기록한 리두 기록을
     저장하고 있습니다. 리두 엔트리는 변경 사항을 등록합니다만 변경되는
     블록의 유형을 구분하지는 않습니다. 그렇기 때문에 데이터 블록으로의
     변경과 인덱스, 또는 롤백 블록의 변경을 구분하지는 못합니다.
   -리두 로그 버퍼는 순차적으로 사용되며 따라서 한 트랜잭션에 의한 변경  
     사항은 다른 트랜잭션에 의한 변경 사항과 교대로 기록될 수도 있습니다.
   -원형 버퍼로써 꽉 차면 재사용됩니다. 하지만 기존의 모든 리두 엔트리가
     리두 로그 파일에 저장된 이후에만 재사용 됩니다.

주
 리두 로그 파일은 "리두 로그 파일 관리" 장에서 더 자세히 다루어질 것입니다 

 


 PGA(Program Global Area)는 서버 프로세스나 각 백그라운드 프로세스를 위한 데이터와 제어 정보를 가지고 있는 메모리 영역입니다. Process global area라고도 불리우는 PGA는 여러 개의 프로세스가  공유하고 기록하기도(written) 하는 SGA와는 달리 한 프로세스에 의해서만 사용되는 영역입니다. 전용 서버 구성을 사용할 때, PGA는 다음으로 구성됩니다.

  -정렬 영역(Sort area): 행이 처리되거나 사용자에게 리턴되기 전에 필요할     수도 있는 정렬을 하는데 사용됩니다.
  -세션 정보: 세션에 대한 사용자 권한 따위 입니다.
  -커서 상태: 현재 세션이 사용하고 있는 각종 커서의 처리 단계를 표시해
    줍니다.
  -스택 공간: 세션 변수들을 포함합니다.

PGA는 프로세스가 생성될 때 할당되며 프로세스가 종료될 때 해제됩니다.

주
MTS 구성을 사용할 때는 이러한 구조 중 일부가 SGA에 저장됩니다.

 

DML 문 실행하기

DML(data manipulation language) 문은 두 단계의 처리 과정이 필요합니다.
   
   -질의문을 처리하는데 사용되는 것과 유사한 구문 분석
   -실행

실행 단계
다음 형태의 update를 실행하는 예를 보십시오.
        UPDATE emp
        SET sal=sal*1.1
        WHERE empno=7369;

다음은 update 문을 실행하는데 사용된 단계들입니다.

 1 버퍼 캐쉬에 데이터와 롤백 블록이 없으면 서버 프로세스는 데이터 파일에서  
   그것들을 읽어 옵니다.
 2 블록의 사본이 버퍼 캐쉬에 위치됩니다.
 3 서버 프로세스가 데이터에 잠금(lock)을 겁니다.
 4 서버 프로세스는 롤백(이전 이미지)과 데이터(변경된 값)에 행해진 변경 사항    을 리두 로그 버퍼에 기록합니다.
 5 서버 프로세스는 데이터베이스 버퍼 캐쉬에서 이전 이미지를 롤백 블록에    기록한 후 데이터 블록을 변경합니다. 버퍼 캐쉬 내의 변경된 두 블록은 더티    버퍼(dirty buffer) 즉, 디스크의 해당 블록과 같지 않은 버퍼로 표시됩니다.

주
 DELETE나 INSERT 명령 처리도 유사한 단계를 거칩니다. Delete의 경우 이전 이미지는 삭제된 행의 컬럼 값을 포함하는 반면 insert는 롤백에 저장된 행 위치 정보만을 포함합니다.

 

Oracle 인스턴스

Oracle 인스턴스는 SGA 메모리 구조와 데이터베이스 관리에 사용되는 백그라운드 프로세스로 구성됩니다.  인스턴스는 각 운영 체제에 지정된 방식에 따라 다릅니다.  인스턴스는 한 번에 하나씩 데이터베이스를 열어 사용할 수 있습니다.

 

시스템 글로벌 영역

SGA는 데이터베이스 프로세스가 공유하는 데이터베이스 정보를 저장하는 메모리 영역입니다.  여기에는 Oracle 서버의 데이터 및 제어 정보가 포함됩니다.  SGA는 Oracle 서버가 상주하는 시스템의 가상 메모리에 할당됩니다.  SGA는 다음과 같은 여러 메모리 구조로 궁성됩니다.

이 구조의 목적은 이 단원의 뒷 부분에서 자세하게 설명합니다.  SGA에는 또한 다음 두 개의 선택적인 메모리 구조가 있습니다.

 

백그라운드 프로세스

인스턴스에는 백그라운드 프로세스는 시스템의 무결성이나 성능의 저하없이 동시 사용자의 서비스 요구에 필요한 공통 기능을 수행합니다.  백그라운드 프로세스를 사용하여 사용자가 실행하는 여러 Oracle 프로그램으로 처리해야 할 기능을 통합할 수 있습니다.  백그라운드 프로세스는 I/O를 수행하고 다른 Oracle 프로세스를 모니터하여 병렬화를 높임으로써 성능 및 신뢰도를 향상시킵니다.

Oracle 인스턴스는 그 구성에 따라 여러 백그라운드 프로세스를 포함할 수 있으나, 모든 인스턴스는 다음 다섯 개의 백그라운드 프로세스를 포함합니다.

이 단원의 다음 부분에서는 서버 프로세스가 사용자 프로세스에서 제출한 SQL 문을 Oracle 인스턴스 및 데이터베이스의 일부 구성 요소를 사용하여 처리하는 방법에 대해 설명합니다.


서버 프로세스는 버퍼 캐쉬 내의 롤백과 데이터 블록에 변경 사항을 기록합니다. DBWR(database writer)는 데이터베이스 버퍼 캐쉬로부터 데이터 파일로 더티 버퍼(dirty buffer)를 옮겨 적습니다. 이렇게 함으로써 데이터베이스 버퍼 캐쉬 내에 충분한 수의 프리 버퍼(free buffer)(서버 프로세스가 데이터 파일로부터 블록들을 읽어올 필요가 있을 때 덮어 쓸 수 있는 버퍼)가 사용가능하게 됩니다. 서버 프로세스는  버퍼 캐쉬내의 내용만 변경하고 DBWR는 다음 이벤트중의 하나가 발생할 때까지 데이터 파일로 옮겨 적는 일을 지연시키기 때문에 데이터 베이스의 성능이 향상 됩니다.

   -더티 버퍼 수가 임계 값에  도달했을 때
   -프로세스가 지정된 갯수의 블록을 스캔하고도 프리버퍼를 하나도 발견      하지못했을 때
   -시간이 초과했을 때
   -DBWR 체크포인트가 데이터베이스를 닫는 등의 다양한 이벤트에 의해      발생될 수 있을 때(체크포인트는 데이터베이스 버퍼 캐쉬와 데이터 파일      을 동기화하는 방법입니다.)

주
체크포인트는 "리두 로그 파일 관리" 장에서 자세히 다루어질 것입니다 

 

 LGWR(Log Writer)는 리두 로그 버퍼로부터 리두 로그 파일로 엔트리를 옮겨 적는 백그라운드 프로세스입니다. LGWR은 다음 상황이 되면 리두 로그 파일로 순차적으로 옮겨 적습니다.
   
   -리두 로그 버퍼의 1/3이 찼을 때
   -시간이 초과됐을 때(매 3초마다)
   -DBWR이 데이터베이스 버퍼 캐쉬에서 수정된 블록을 데이터 파일로 옮겨
     적기 전에
   -트랜잭션이 커밋될 때 

 

아카이버 프로세스

다른 모든 백그라운드 프로세스는 데이터베이스의 구성에 따라 선택적이나 그 중 ARC0 프로세스는 디스크 손실 후 데이터베이스를 복구하는 데 필수적입니다.  온라인 리두 로그 파일이 채워지면 Oracle 서버는 다음 온라인 리두 로그 파일에 기록을 시작하는데 이와 같이 한 리두 로그에서 다른 리두 로그로 전환하는 프로세스를 로그 스위치라고 합니다.

리두 로그 파일 아카이브

데이터베이스를 ARCHIVELOG 모드와 NOARCHIVELOG 모드 중에서 어느 모드에서 작동하도록 구성할 지 여부는 DBA가 결정해야 하는 중요한 문제 중 하나입니다.

NOARCHIVELOG 모드

NOARCHIVELOG 모드에서는 로그 스위치가 발생할 때마다 온라인 리두 로그 파일을 겹쳐 씁니다. LGWR는 해당 그룹의 체크포인트가 완료될 때까지 리두 로그 그룹을 겹쳐 쓰지 않습니다. 따라서 인스턴스 실패 시 커밋된 데이터는 복구할 수 있고 SGA만 손실됩니다. 즉 디스크는 손실되지 않고 메모리만 손실되는데 예를 들어 운영 체제가 실패하면 인스턴스도 실패합니다.

ARCHIVELOG 모드

데이터베이스가 ARCHIVELOG 모드로 실행하도록 구성된 경우 채워진 온라인 리두 로그 파일의 비활성 그룹은 다시 사용하기 전에 아카이브해야 합니다. 데이터베이스의 변경 사항은 온라인 리두 로그 파일에 기록되기 때문에 DBA는 데이터 파일의 물리적 백업 및 아카이브된 온라인 리두 로그 파일을 사용하여 디스크 손실을 포함하여 어느 한 부분의 실패로 인해 커밋된 데이터를 손실하는 일 없이 데이터베이스를 복구할 수 있습니다. 대개 운용중인 데이터베이스는 ARCHIVELOG 모드에서 실행하도록 구성됩니다.

ARC0 프로세스

ARC0 프로세스는 로그 스위치가 발생할 때마다 채워진 로그 그룹을 백업하거나 아카이브하기 시작합니다. 이것은 로그를 다시 사용하기 전에 온라인 리두 로그를 자동 아카이브하므로 데이터베이스의 모든 변경 사항이 보존됩니다. 따라서 DBA는 디스크 드라이브가 손상되더라도 데이터베이스를 장애 발생 시점까지 복구할 수 있습니다.

 

COMMIT 처리

 오라클은 빠른 커밋 기법(fast commit mechanism)을 사용하여 실패했을 경우에도 커밋된 변경 사항을 복구할 수 있도록 보장합니다.

System Change Number
 트랜잭션이 커밋될 때마다 오라클 서버는 트랜잭션에 커밋 SCN(System Change Number)을 지정합니다. SCN은 데이터베이스 내에서 유일한 값이며 증가합니다. SCN은 데이터가 데이터 파일로부터 읽혀질 때 데이터를 동기화하고 읽기 일관성(read consistency)을 제공할 수 있도록 오라클 서버가 내부 "time stamp"로 사용합니다. SCN을 사용함으로써 오라클 서버는 운영 체제의 날짜나 시간에 의존하지 않고 일관성 검사를 수행할 수 있습니다.

COMMIT 처리 단계
 COMMIT이 실행되면 다음 단계대로 수행됩니다.

  1 서버 프로세스는 SCN과 함께 커밋 기록을 리두 로그 버퍼에 위치시킵니다.
  2 LGWR은 모든 리두 로그 버퍼 엔트리와 커밋 기록을 리두 로그 파일에 연속적      으로 옮겨 적습니다.  이후 오라클 서버는 실패하는 경우에도 변경 사항을      잃지 않게 됩니다.
  3 사용자에게 COMMIT이 완료되었다는 것을 알립니다.
  4 서버 프로세스는 트랜잭션이 완료되었으며 자원 잠금(lock)이 해제되었다는      것을 나타내는 정보를 기록합니다.

커밋 전후 아무 때나 DBWR에 의해 더티 버퍼(dirty buffer)를 데이터 파일로 옮기는 일이 독립적으로 수행됩니다.

주
 트랜잭션을 롤백하는 것이 디스크로 옮겨 적는 LGWR를 발생시키지는 않습니다. 오라클 서버는 실패로부터 복구할 때는 항상 커밋되지 않은 변경 사항을 롤백합니다. 롤백 이후 실패가 발생하면 롤백 엔트리가 디스크에 기록되기 전일지라도 커밋 기록이 없으므로 롤백된 트랜잭션에 의한 변경 사항을 충분히 확인할 수 있습니다.

Fast - COMMIT의 장점
 COMMIT를 처리하기 위해 이러한 단계를 거치는 것은 다음과 같은 장점이 있습니다.
  -로그 파일로 순차적으로 옮겨 적는 것이 데이터 파일로 서로 다른 블록을
    옮겨 적는 것보다 빠릅니다.
  -변경 사항을 기록하기 위해 로그 파일로 옮겨 적는 것은 최소한의 정보만이
    필요합니다. 반면 데이터 파일로 옮겨 적는 것은 데이터 전체 블록들이
    필요합니다.
  -데이터베이스 COMMIT은 커밋을 요구하는 여러 개의 트랜잭션으로부터
    리두 로그 기록들을 piggyback할 수 있습니다.
  -리두 로그 버퍼가 꽉 차지 않는다면 트랜잭션 당 하나의 동기화 쓰기만이
    요구됩니다.(트랜잭션 당 하나보다 적은 동기화 쓰기가 될수도 있습니다.)
  -트랜잭션의 크기는 실제 COMMIT 작업을 위해 필요한 시간에 영향을 주지
    않습니다 


 요약참조

관련내용

참조

프로세스

사용자 프로세스
서버 프로세스
백그라운드 프로세스 :
  -DBWR
  -LGWR

메모리 구조

SGA :
  -공유 풀
  -데이터베이스 버퍼 캐쉬
  -리두 로그 버퍼
  -PGA

물리적 구조 (파일)

데이터베이스 파일 :
  -데이터 파일
  -콘트롤 파일
  -리두 로그 파일
그밖의 파일 :
  -파라미터 파일
  -패스워드 파일
  -아카이브 리두 로그 파일

파라미터

SHARED_POOL_SIZE
DB_BLOCK_SIZE
DB_BLOCK_BUFFERS
LOG_BUFFER

X 정답:D


X 정답:C


X 정답:B


X 정답:AD


X 정답:B


X 정답:C


X 정답:D


X 정답:D


X 정답:B


X 정답:A


X 정답:B


X 정답:B


X 정답:A