10g Workshop 1장

I. About Grid "g"
  1. Grid 개념 : PC나 서버, PDA 등 모든 컴퓨팅 기기를 하나의 네트워크로 연결해, 정보처리 능력을 슈퍼컴퓨터 혹은 그 이상의 수준으로 극대화하는 개념
  2. GRID 원리 : 가상의 슈퍼컴퓨팅파워를 구축해 주는 범네트워크 원리
     1) 세계 각지에 흩어져 있는 수억대의 PC와 첨단장비를 하나로 묶어서 제어
     2) 이 네트워크는 하나의 자원보다 수천, 수만배의 능력 발휘 가능
  3. Oracle’s grid infrastructure : Low cost, High quality of service, Easy to manage
    1) 소형 서버들을 연결해 하나의 커다란 컴퓨터처럼 사용
    2) 고성능을 유지하면서 대형 시스템보다 더욱 많은 자원을 활용할 수 있다는 점에서 비용절감을 위한 최적의 방안 
    3) 자유로운 접속을 통해 데이터 파일을 공유, 복사, 전송 가능 : 데이터 자원을 별도로 관리하면서 발생한 복잡성과 유지보수에 따른 비용 낭비 감소 가능
    4) 원격 접속을 통해 애플리케이션을 어떠한 데이터베이스에서도 수행 가능
    5) 스케줄링과 자원 관리,오라클 리소스매니저 그리고 표준 GRID 환경, 빠른 이식성 제공
    6) 관리 자동화 : 최상의 서비스를 제공하면서도, 비용 감소 가능
    7) Oracle’s grid computing technology includes

      ① ASM : 최소의 비용으로 높은  I/O 성능을 제공하기 위해서 모든 디스크에 데이터베이스 데이터 분산, storage grid 생성 및 관리. 온라인으로 disk 추가 삭제 가능(파일시스템의 logical volume manager의 관리 필요 없음)
      ② RAC : 물리적인 하나의 데이터베이스를 여러대의 서버가 공유하는 것으로 모든 노드들은 같은 데이터를 사용하게 되어 논리적으로는 하나의 데이터베이스 이용
      ③ Oracle Streams : 분산되어 있는 정보에 대한 공유(Information Sharing)를 위해 변경을 자동 탐지 및 전달하는 기능. 9I Release 2부터 지원
         가) 원격지 Database간의 정보 공유를 지원하며, 또한 Streams는 전달하는 과정에서 Source 변경사항 이외의 추가적인 변경이나, 추가적인 정보를 Mapping하여 Target에 반영 할 수 있는 Transformation 기능 지원
         나) Message Queuing : 사용자에게 임의의 Message type을 queue로 넣어 Destination database로 전달하고, 이 Message를 사용자에게 notify 해줌
         다) Data Replication : Source Database의 변경(DML, DDL)을 효율적으로 LCR(Logical Change Record) 형식으로 변경하여, 이를 Destination Database로 전달하며, Apply Process가 이 전달되어온 LCR를 적용하여 Data를 Replication 함
         라) 장점 : 위의 기능들을 활용하여 Data ware House Loading이나 Backup등의 기능으로 사용 가능
      ④ Enterprise Manager Grid Control : 오라클 Grid 와 모든 작동중인 어플리케이션의 모든 면을 관리하기 위한 통합된 솔루션
         가) 장애 예방 및 모니터링  : alert & notification, performance monitoring, lock & hang monitoring etc
         나) 자동 성능분석 : AWR + ASH + ADDM, SQL Tuning 기능 제공
         다) DB Admin : user, object 등 모든 DB 관리, Backup & Recovery, Patch관리, DB 이관 및 동기화 등
         라) 환경설정 및 변경 관리 : H/W & S/W 상세구성정보, DB Object Definition 정보 등


II. Oracle Database Architecture
  0. Oracle Server = Oracle instance + Oracle database. 데이터베이스 관리 시스템

  1. Database Structures
     1) Instance = SGA + background process
     2) Oracle Startup Process
         ① nomount : 인스턴스 시작. 오라클 S/W는 SGA(System Global Area)라 불리우는 shared memory를 할당하고, background process가 시작 되고, trace 및 alert 파일 open.
            가) DB 생성, control file 재생성  가능
     3) mount : 인스턴스 시작 후, 오라클 S/W는  인스턴스와 연결됨
            가) control file 을 내용을 읽어 database file 적용(data file, redolog file)
            나) 적용할 database file check
            다) datafile 및 redo log file 관리, archive log mode 변경( alter database archivelog ), DB 복구 가능
     4) open : 권한있는 사용자 접근 가능

  2. Oracle Memory Structures = SGA + PGA(Program Global Area)

    1) System Global Area (SGA): Database buffer cache, redo log buffer, Shared pool, Large pool, Java pool, Streams pool
        ① 개요
            가) 모든 서버프로세스와 백그라운드 프로세스들이 공유해서 사용하는 영역
            나) 오라클서버를 동시에 사용하고 있는 사용자들은 SGA 공유
            다) SGA_TARGET : Instance에서 사용 가능한 SGA메모리의 전체 크기 결정. Oracle에서 할당된 전체크기로부터 자동으로 메모리 분배
                   ※  SGA_TARGET = 0 : Automatic Shared Memory Management(ASMM)은 비활성화
        ② Database buffer cache : 데이터를 읽고 수정하기 위해 DB내의 데이터를 읽고 복사하여 저장하고 있는 메모리공간
                                               DBWR가 데이터를 쓰기 전에 수정된 데이터 보유.
                                               사용된 Dirty Buffer는 DBRW에 의해 디스크에 쓰인 후 Free Buffer가 됨
                                              ※ Dirty Buffer : 내용은 변경 되었지만 DBRW에 의해 디스크에 아직 기록되지 않은것
        ③ Redo log buffer : DB내에 일어난 모든 변화를 저장하는 메모리 공간
                                    LGWR에 의해 DB복구에 사용되는 Online상태의 Redo Log file에 저장
                                    실제 변경보다 먼저 기록되기 때문에 어떤 상황에서도 복구 가능
        ④ Shared pool :  Library Cache + Dictionary Cache + Control Structures
             가) 하나의 데이터베이스에 행해지는 모든 SQL 문을 처리하기 위하여 사용됨
             나) Query를 실행하기 위해 그 문장과 관련된 실행 계획과 구문분석 정보 있음
             다) Library Cache : 명령문, 구문분석 코드, 실행계획 저장
             라) Data Dictionary Cache : 테이블과 컬럼 정의, 사용권한 등 저장
             마) Control Structures : lock / library cache handle 
        ⑤ Large pool : MTS 환경과 분산 환경에서 사용자들의 세션 정보(UGA)를 할당 하기 위해, 오라클 백업과 복원, 명령문의 병렬 실행을 위해 사용하는 영역
        ⑥ Java pool : Oracle JVM에 접속해 있는 모든 세션에서 사용하는 자바코드가 사용하는 메모리 영역 
        ⑦ Streams pool : Oracle Streams에서 사용하는 메모리 영역
    2) Program Global Area (PGA): 서버 프로세스와 백그라운드 프로세스가 개별적으로(독립적으로) 사용하는 비공유 메모리 영역
        ① 서버프로세스를 위한 데이터와 제어정보 저장
        ② 서버 프로세스가 시작할 때 Oracle에 의해 생성
        ③ PGA의 총 크기 : Oracle Instance에 속한 각 프로세스에 의해 할당. 프로세스가 생성될 때 할당되며 프로세스가 종료될 때 해제.

  3. Process Structures :  User process and Server process

    1) Oracle Instance를 구성
    2) User Process : 클라이언트 프로세스
       ① 사용자가 오라클 Application Program을 실행 시켰을 때 사용되는 프로세스
       ② 사용자가 오라클 서버에 접속할 때마다 사용자 프로세스가 생성
       ③ 사용자가 실행시킨 SQL문을 서버 프로세스에 전달하고, 그 결과를 서버 프로세스로부터 받는 역할을 수행
    3) Oracle Process
       ① Oracle은 서버프로세스를 생성하여 접속된 사용자 프로세스의 요구 사항을 처리 
       ② 서버 프로세스는 사용자 프로세스와의 통신과 사용자 프로세스의 요구 사항을 수행하는 Oracle과의 상호 작용을 담당
       ③ Oracle은 서버 프로세스당 사용자 프로세스 수를 조정하도록 구성
           가) 전용 서버 구성 :  서버 프로세스는 단일 사용자 프로세스에 대한 요구 사항을 처리
           나) 공유 서버 구성 :  여러 개의 사용자 프로세스가 적은 수의 서버 프로세스를 공유하여 서버 프로세스 수를 최소화하는 동시에 사용 가능한 시스템 자원 활용도를 최대화
       ④ 오라클 서버 프로세스는 사용자로부터 받은 요구사항(SQL문)을 처리
       ⑤ 사용자가 SGA Database Buffer에 없는 데이터를 질의하면 관련 서버 프로세스는 데이터 파일로부터 해당 데이터 블록을 시스템 글로벌 영역으로 읽어 들임
       ⑥ 전달받은 SQL문을 Parse하고 실행 시키는 역할을 함
       ⑦ Application이 정보를 처리할 수 있는 방법으로 결과를 돌려 줌
       ⑧ 전용(dedicate mode)모드 : PGA에 공유, user프로세스에 1:1 대응
       ⑨ 공유(shared mode)모드 : SGA에 공유
    4) Background Process : SMON, PMON, DBWn, CKPT, LGWR, ARCn, and so on

        ① DB 성능을 최대화하고 많은 사용자의 요구를 처리하기 위해 백그라운드 프로세스라는 여러 프로세스 사용
        ② DBWn(Database Writer) : 데이터파일에 기록. DB버퍼로부터 읽어들인 블럭의 내용을 데이터 파일에 쓰는 역활
        ③ LGWR (Log Writer) : 리두 로그 버퍼로부터 읽어 들인 블록의 내용을 리두로그 파일에 쓰는 역활
        ④ CKPT (Check Point) : 설정된 시간에 DBWn에 신호를 보내어 SGA내의 변경된 데이터들을 모두 데이터 파일에 기록하는 역활
        ⑤ SMON (System Monitor) : 시스템을 모니터링 함. Instance를 구성하는 메모리구조와 프로세스가 계속 실핼될 수 없어 Instance가 실패하는 경우 Instance를 복구하는 역활도 함.
        ⑥ PMON (Process Monitor) : 프로세스를 모니터링. 유저프로세스들이 올바로 동작하는가를 감시
    5) Server Process and Database Buffer Cache
        ① Free or unused : 아무 내용도 없는 buffer, 다른 것으로 들여서도 상관없는 buffer   (ex. select 문장 완료시….)
        ② Pined : access 하고 있는 순간의 buffer
        ③ Dirty : 변경이 일어난 buffer 
        ④ Clean : Pinned 상태에서 작업이 완료한 buffer
        ⑤ select 문장 실행 시 : Free buffer를 확보하여 data file의 해당 블록을 버퍼에 올린 후 내용을 보여주는 동안 Pined buffer로 변한 후 access 완료 후에는 다시 Free buffer로 변경
        ⑥ DML 문장 실행 시 : Free buffer를 확보하여 datafile의 해당 블록과 롤백 세그먼트 블록을 버퍼에 올린 후 DML 문장을 실행하는 동안 Pined buffer로 변한 후 data 변경이 완료되면 Dirty buffer로 변경
        ⑦  Dirty buffer가 Free buffer가 되기 위해선 DBWR이 해당 버퍼를 디스크에 I.O를 일으키며 data file에 write 해야 함

  4. Storage structures
    1) Logical: Database, schema, tablespace, segment, extent, and Oracle block
    2) Physical: Files for data, parameters, redo, and OS block

5. Physical Database Structure : block < extent < segment < tablespace

  0) 개요
     ① 크기가 일정한 것은 block와 tablespace
     ② 2KB ~ 32KB : 다양한 크기의 할당단위를 쓰는 이유는 속도와 효율성 때문
 

  1) Tablespaces
     ① 1개 이상의 데이터파일로 구성
     ② 생성할때 크기 정함

  2) Data Files : 확보된 디스크 공간에 여러개의 data file 생성. 오직 하나의 테이블스페이스에만 속함 

  3) SYSTEM and SYSAUX Tablespaces
     ① 필수 테이블스페이스로 반드시 online mode
     ② DB 생성 시점에 자동 생성
     ③ SYSTEM tablespace : data dictionary tables과 같은 core functionality 를 지원
     ④ SYSAUX tablespace : SYSTEM 테이블스페이스 보조. EM Repository와 같은 DB components 저장

  3-1) Temp Tablespace
     ① order by 나 Goup by 등의 정렬이 필요로 하는 부분이 발생되면 우선 pga영역에서 sort(정렬)작업을 하나, pga의 sort area의 용량을 넘어건 정렬작업은 디스크를 이용하여 하게 되는데 이때 사용되것이 임시 테이블스페이스 임
     ② sort중인 세션 조회

set line 150
col username format a10
col osuser format a10
col tablespace format a15
SELECT b.tablespace, b.segfile#, b.segblk#, b.blocks, a.sid, a.serial#, c.spid,
             a.username, a.osuser, a.status
FROM v$session a, v$sort_usage b, v$process c
WHERE a.saddr = b.session_addr and a.paddr=c.addr
ORDER BY b.tablespace, b.segfile#, b.segblk#, b.blocks;

     ③ sort하고 있는 블록 조회

col tablespace_name format a10
set linesize 120
select TABLESPACE_NAME, current_users, TOTAL_BLOCKS, USED_BLOCKS, FREE_BLOCKS
from v$sort_segment; 

  3-2) Undo Tablespace
     ① 정의
     ② Undo Tablespace가 꽉차는 이유
        ⓐ Undo를 많이 생성하는 Heavy DML이 왕성하게 수행
        ⓑ Undo Retention이 길거나 Undo Gurantee를 사용함으로써 많은 양의 Undo를 보관해야하는 경우
        ⓒ Undo를 재활용하지 못하거나 Undo Retention을 잘못 계산하는 Bug가 있는 경우 
     ③ Disk 여유 공간이 충분 : Undo Tablespace의 크기를 충분히 크게 설정하고 사용
     ④ 허용 가능한 Disk 공간보다 Undo Tablespace의 크기가 더 커질 경우
        ⓐ Oracle의 Bug 확인 : Autotuned Undo Retention을 사용하는 경우에 특정 버전에서 Retention을 잘못 계산해서 Undo를 재활용하지 못하는 버그 가능성 있음(예: 메타링크 노트 5387030)
        ⓑ 주기적으로 Undo를 교체해주는 전통적인 방식
※ Autotmatic Undo Retention은 아마 Autotuned Undo Retention을 의미하는 것 : Autotuned의 장점은 (항상 그렇듯이) 대부분의 경우에는 Oracle이 일을 잘 하지만, 간혹 Bug등으로 인해 예상치 못한 문제가 발생할 수 있음
※ 참고 사이트 : ask 엑셈

  4) Segments : Space Occupying Object (Table, Index). 계속 늘어남

     ① Data segments: 클러스터 되지 않은 테이블, 클러스터 테이블, 파티션 테이블로 구분되어져 저장 
         가) 테이블의 데이터가 저장되는 extents가 속한 세그먼트. 
         나) 파티션 테이블의 경우, 각각의 파티션이 데이터 세그먼트에 저장
         다) 클러스터 테이블은 하나의 데이터 세그먼트를 갖음 : 클러스터내의 테이블 데이터는 cluster’s data segment에 저장됨
     ② Index segments: 인덱스는 인덱스 세그먼트에 저장됨. 파티션 인덱스의 경우, 각각의 파티션이 인덱스 세그먼트에 저장됨
     ③ Undo segments: Transaction Rollback, 일기 일관성 유지(Read Consistency), Transaction Recovery를 위해 존재
         가) 관리 방식(9i 이후) : 자동 관리 모드와 수동 관리 모드 중 선택. 트랜잭션 처리를 위한 알고리즘 개선
         나) 생성, 할당 및 튜닝을 오라클 서버가 관리 : DBA는 더 이상 몇개의 Rollback 세그먼트를 생성 할 것인지, 크기는 어떻게 할 것인지, 트랜잭션에 따라 어떻게 할당할 것인지를 결정하지 않아도 됨
        다) Transaction Rollback : Oracle 서버에서 Undo Segment에 저장된 값을 이용해서 원래의 값으로 복원하는 기능.
                Transaction Rollback이 실행되는 경우는 사용자가 Rollback command를 실행하거나, Transaction이 비정상 종료되어 PMON이 자동 Rollback 처리하는 경우
        라) 읽기 일관성 : Transaction이 진행되는 동안 Database의 다른 사용자는 이 Consistent Read에 의해 Commit되지 않은 변경 사항을 볼 수 없는 기능
        마) Transaction Recovery : Transaction이 진행되는 동안 Instance가 실패한 경우 Database가 다시 열릴 때 Commit 되지 않은 사항은 Rollback 되어야 하는데, 이때 Undo Segment 정보가 사용 됨. Undo Segment의 변경사항은 리두로그 파일로 보호되므로 복구 가능
     ④ Temporary segments: SQL문의 완전한 실행을 위해 임시 작업 영역이 필요할 때 생성. 명령문 실행이 끝나면 임시 세그먼트의 확장 영역은 이후 사용을 위해 시스템으로 복귀
         가) Temporary Segments가 필요한 문장
            - CREATE INDEX - SELECT ... ORDER BY
            - SELECT DISTINCT ... - SELECT ... GROUP BY
            - SELECT . . . UNION - SELECT ... INTERSECT
            - SELECT ... MINUS

         나) CREATE TEMPORARY TABLESPACE로 임시 테이블스페이스를 생성해서 CREATE USER나, ALTER USER 명령시 지정 가능
         다) TEMPORARY TABLESPACE를 지정를 지정하지 않으면 USER는 SYSTEM 테이블스페이스를 사용
         라) Oracle9i는 부터는 DEFAULT TEMPORARY TABLESPACE를 생성해서 TEMPORARY TABLESPACE를 지정받지 않은 사용자가 SYSTEM 테이블스페이스를 사용하는 것을 방지

  5) Extents : Block이 모인 것들. Continous Block(연속된 Block 집합)
     ① create table 문장에서 storage option 중 initial extent를 10K로 지정하면 db_block_size가 2K일 경우 5 Block이 됨
         ==> 5개의 ORACLE Block이 하나의 extent로 구성됨을 의미
     ② "연속 된" 의 의미 : 테이블스페이스에 free space가 비록 많이 있더라도 fragment가 다수 발생하여 조각 조각 나 있다면 (연속된 덩어리로 extent 크기의 free space가 없는 경우) extent는 allocate되지 못함
     ③ 실제 사용자가 쓰는 단위
        ex) create table test_table ~~
              tablespace test_space storage (initial 2m next 2m pctincrease 0)
            ==> 데이터가 insert되면 초기에 2m짜리 extent를 할당 받고, 그 다음부터 2m를 할당 받음 (block = 2048 bytes인경우)

  6) Blocks : Storage, I/O 최소 단위.
     ① 실제 data , row가 저장되는 기본적인 단위
     ② 오라클 설치할 때 결정
     ③ ORACLE block이 2K 의미 : os에서 2048 bytes가 한 단위로 묶여서 block을 형성

  7) 관련 view
     ① dba_data_files : data file 정보
     ② dba_tablespaces : tablespace 정보
     ③ dba_rollback_segs : rollback segment 정보
     ④ dba_users : 오라클 사용자 정보
     ⑤ user_segment : 사용자 segment 정보

  8) Q&A
     Q1) Extent는 언제 할당(allocation)되나요?
        A1) Segment(Table, Index 등)가 처음 생성될 때 Initial Extent 크기 만한 Extent가 할당
             Segment가 점차 커짐에 따라 Next Extent 크기 만한 Extent가 할당됨
     Q2) Extent는 언제 de-allocaltion되나요?
        A2) Segment를 drop 또는 truncate시킬 때, Segment 크기가 optimal보다 커졌을 때(이 경우는 rollback segment에만 해당)
     Q3) Segment create 시 지정하는 max extent는 어떻게 계산되나요?
        A3)  Max extent #=((db_block_size - 24) / 2 - 44) / 8
        ex) db_block_size는 8K라면
              Max extent #=((8192 - 24) / 2 - 44) / 8 = 508