1. Oracle Server
  1) Oracle instance : 메모리에서 일어나는 일(Ram)
  2) Oracle Database : 데이터 파일에 관한 일

2. Instance
  1) System Global Area(SGA) : 쿼리 등의 오라클을 실행하는 거
  2) Background processes(BS) : 뒷단에서 눈에 보이지 않는 작업을 하는 거

3. SGA
  1) Shared Pool
  2) Streams Pool
  3) Large Pool
  4) Java Pool
  5) Database Buffer Cache
  6) Redo Log Buffer

4. Background Processes : 메모리에서 일어나는 일들을 뒤에서 실행하는 거
  1) System Monitor(SMON)
  2) Process Moniter(PMON)
  3) DataBase Writer(DBWn)
  4) LogWriter(LGWR)
  5) Check Point(CKPT)

OWI : SQL 실행을 빠르게 하기 위한 개선책을 찾는 방법 (일종의 SQL튜닝?)

* 실행 과정
SQL(select * from emp)
-> user processer
-> server processer(문법 검사[Parsing] -> 권한 검사)
======================> SGA[Shared Pool]
-> 실행
======================> SGA[DB Buffer Cache] : HDD에 있는 걸 메모리에 올려주기 (속도 up) - 만약 파일 관리가 제대로 안된다면 속도 down
->

* full scan이 발생하면 DB Buffer Cache에 모든 block이 다 올라오기 때문에 기존에 있던 block들은 모두 해제된다.
그 후 full scan 후 다시 메모리에 올려야하기 때문에 속도 up, 시간 down
저작자표시 비영리 변경금지

'Database > Oracle' 카테고리의 다른 글

인덱스(Index)  (1) 2009.12.30
뷰 View  (1) 2009.12.30
Query 실행 과정 10g  (1) 2009.12.30
10g RAC의 Load Balancing과 Failover  (1) 2009.12.30
Backup and Recover  (0) 2009.12.30
1. SELECT 실행 과정 {SELECT * FROM emp;}
-> user process (sqlplus)
-> server process : Parsing
  => ASCII 변환 (query를 변환)
  => Hash 함수
  => Cache가 있는지 확인
    ==> instance [Shared Pool:Library Cache] - soft parsing
  => 문법검사
    ==> instance [Shared Pool:Dictionary cache] - hard parsing
  => 권한검사
-> optimaser
  => 실행계획
    ==> 실행 계획까지의 모든 데이터를 저장
    ==> instance [Shared Pool:Library Cache]
    ==> Dictionary를 확인하고 계획을 세우기 때문에 Dictionary를 Update 해야함 [CBO:9i]
-> server process
  => Execute : 실행계획을 받아서 실행
    ==> Database buffer Cache에 있는지 확인
    ==> Data File에서 Block의 정보를 읽고 Database buffer Cache에 전체를 복사해서 결과 가지고 옴
  => Fetch
    ==> 필요한 정보만을 Block에서 간추린다. [PGA]
    ==> user process 전달

2. UPDATE 실행계획{UPDATE emp SET name='홍길동' WHERE empno=100}
-> SELECT의 parsing까지 동일
-> server process
  => Execute : 실행계획을 받아서 실행
    ==> Database buffer Cache에 있는지 확인
    ==> Data File에서 Block의 정보를 읽고 Database buffer Cache에 전체를 복사해서 결과 가지고 옴
    ==> Redo log Buffer 작업 내용 저장[작업일지]
      ===> instance 이기 때문에 수시로 Redo log file에 저장
        ====> 속도 fast - 수정 및 저장 내용이 적고 간결, Block의 위치에 상관없기 때문에
        ====> LGWR
      ===> 만약 불가피하게 디비가 죽는다면 다시 디비를 올리면서 Database File의 데이터와
           Redo log file의 내용을 비교해서 변경사항이 있다면 Database File의 내용을 변경한다.
        ====> 아카이브 로그에 다시 백업 복사
    ==> undo segment에 원래 내용 저장[취소하기 위해서]
    ==> Database buffer Cache에 원하는 정보로 변경 [commit 전에 변경 완료]

저작자표시 비영리 변경금지

'Database > Oracle' 카테고리의 다른 글

뷰 View  (1) 2009.12.30
Admin Workshop 1 - 구조 10g  (0) 2009.12.30
10g RAC의 Load Balancing과 Failover  (1) 2009.12.30
Backup and Recover  (0) 2009.12.30
Admin Workshop 1 - 구조  (0) 2009.12.15

<표 1> 라이선스의 형태 이해(출처: 컴퓨터프로그램보호위원회)


<표 2> 오픈소스 DBMS 라이선스 비교


<표 3> 오픈소스 소프트웨어의 제공 서비스

출처 : 한국 마이크로 소프트웨어 [2009년 5월호]
제공 : DB포탈사이트 DBguide.net
저작자표시 비영리 변경금지

'Database' 카테고리의 다른 글

DBMS별 날짜 포멧  (0) 2010.01.27
DBMS별 날짜 포멧  (0) 2009.12.30
지금 우리에게 필요한 건 정렬의 제거이다  (0) 2009.12.04

여기서는 DBMS의 고가용성(HA)을 보장해주는 여러 제품군들 가운데 Oracle RAC를 살펴보기로 한다. Oracle RAC의 특징 중 하나는 Load Balancing과 FailOver 기능으로, 이중에서도 RAC를 이용하는 가장 큰 이유는 바로 Application FailOver 기능 때문일 것이다. Application FailOver는 하나의 노드에 장애가 발생했을 때 다른 살아 있는 노드에서 이 Application의 서비스를 대신해주는 것으로, 실제 사용자는 서비스 중이던 노드에 장애가 일어났는지를 감지하지 못하고 정상적으로 서비스를 이용할 수 있는 기능을 의미한다.

 Oracle RAC에서 Fail-Over를 가능하게 해주는 것이 Oracle 9i부터 소개된 방법인 CTF(Connection Time Failover)와 TAF(Transparent Application Failover)이다. CTF는 클라이언트가 해당 데이터베이스로 접속을 시도했으나, 해당 서버에 장애가 발생하여 접속하지 못할 경우 살아 있는 다른 서버로 접속할 수 있게 해주는 기능이고 TAF는 클라이언트가 RAC에서 어느 한 노드에 접속하여 작업하던 도중 장애가 발생했을 경우 살아 있는 다른 노드에서 수행 중이던 작업을 계속할 수 있게 해주는 기능이다. 먼저 Oracle RAC의 Load Balancing 기능을 먼저 살펴보자.

 Client-Side Connect-Time Load Balancing

 Client-Side Connect-Time Load Balancing의 특징은 이용 가능한 Listener 리스트 중에서 랜덤(random)하게 접속 요청을 하는 것이다. 이는 클라이언트의 tnsnames.ora에 “LOAD_ BALANCE=ON”을 설정함으로써 가능하다.

-- TNSNAMES.ORA ghlee = (DESCRIPTION = (LOAD_BALANCE=ON) (ADDRESS = (PROTOCOL = TCP)(HOST = 192.128.25.18)(PORT = 1521)) #ghlee1 (ADDRESS = (PROTOCOL = TCP)(HOST = 192.128.25.19)(PORT = 1521)) #ghlee2 (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = GHLEE))) -- 첫 번째 접속 시도 [/oracle/product/10.2.0/network/admin> sqlplus scott/tiger@ghlee SCOTT@ghlee1 >@in.sql INSTANCE_NUMBER INSTANCE_NAME HOST_NAME -------------- -------------- -------------- 1 ghlee1 ghlee1 -- 두 번째 접속 시도 [/oracle/product/10.2.0/network/admin> sqlplus scott/tiger@ghlee INSTANCE_NUMBER INSTANCE_NAME HOST_NAME --------------- --------------- -------------- 1 ghlee1 ghlee1 -- 세 번째 접속 시도 [/oracle/product/10.2.0/network/admin> sqlplus scott/tiger@ghlee INSTANCE_NUMBER INSTANCE_NAME HOST_NAME --------------- --------------- -------------- 1 ghlee1 ghlee1 -- 네 번째 접속 시도 [/oracle/product/10.2.0/network/admin> sqlplus scott/tiger@ghlee INSTANCE_NUMBER INSTANCE_NAME HOST_NAME --------------- --------------- -------------- 2 ghlee2 ghlee2 -- 다섯 번째 접속 시도 [/oracle/product/10.2.0/network/admin> sqlplus scott/tiger@ghlee INSTANCE_NUMBER INSTANCE_NAME HOST_NAME --------------- --------------- -------------- 1 ghlee2 ghlee2

 위의 결과에서 볼 수 있는 것처럼 랜덤하게 접속을 시도한다. 만약 “LOAD_BALANCE=OFF”로 설정되어 있다면 List에 명시된 처음 Address (HOST = 192.128.25.18)로 먼저 접속을 시도하고 응답이 없을 경우 TCP TIMEOUT까지 대기한 후 다음 Address list (HOST = 192.128.25.19 )로 접근을 시도한다.

 Server-Side Connect-Time Load Balancing

 Server-Side Connect-Time Load Balancing이라는 것은 서버 측에 설정하는 것으로서 동작 방식은 다음과 같다.

<그림 1> Server-Side Connect-Time Load Balancing

 ① PMON Process가 Listener에 Performance 정보와 함께 Service를 동적으로 등록한다. <표 1>과 같은 정보들이 주기적으로 기록된다.

<표 1> 주기적으로 기록된 정보

 ② 클라이언트가 Connection을 요청하면, 클라이언트의 tnsnames.ora 파일에 기술된 Protocol address 중에 랜덤으로 하나의 접속에 성공한다. 그 Listener가 ghlee1의 Listener이다. ghlee1의 Listener는 ghlee1과 ghlee2 instance의 load의 양을 비교한다. 여기서는 ghlee2의 load의 양이 더 적으므로 ghlee2를 선택한다.

 ③ Ghlee1의 Listener는 클라이언트에게 ghlee2의 Listener로 connection하도록 redirect 한다.

 ④ 클라이언트는 ghlee2의 Listener로 접속한다. Listener는 server process를 생성하고 Listener로부터 connection 요청을 상속받아 이제부터는 Listener를 거치지 않고 바로 클라이언트와 통신한다.

이와 같은 방식으로 실행하기 위해서는 ghlee1의 Listener에 ghlee2의 Node의 상태 정보나, Service의 정보들이 PMON에 의해 Listener에 주기적으로 갱신해줘야 하는데 이를 위해서는 Instance가 Listener에 자동으로 등록되는 방식을 사용해야 한다. 이를 Dynamic Register 방식이라 하고, 이를 위해서는 몇 가지 설정이 필요하다.

 Dynamic Register

 8i 이전까지는 Database Instance의 정보를 listener.ora 파일에 수동으로 기술했지만, 8i 이후부터는 스스로 Listener에 등록할 수 있다. PMON process가 현재의 상태와 Instance의 load 정보를 Listener에게 보내는 방식이다. 8i 이전까지는 아래와 같이 listener.ora 파일에 Instance에 대한 사항을 기술해주었다.

-- LISTENER.ORA LISTENER_GHLEE1 = (DESCRIPTION_LIST = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = 192.128.25.18)(PORT = 1521) )#ghlee1_vip (ADDRESS = (PROTOCOL = TCP)(HOST = 192.128.25.30)(PORT = 1521) ) #ghlee1_real ip )) SID_LIST_LISTENER_GHLEE1 = (SID_LIST = (SID_DESC = (SID_NAME = GHLEE1) (ORACLE_HOME = /oracle/product/10.2.0))) -- Parameter들의 값 GHLEE1@SQL> show parameter listener NAME TYPE VALUE ----------------------------------- ----------- local_listener string remote_listener string SQL> show parameter service NAME TYPE VALUE ----------------------------------- ----------- service_names SQL> show parameter db_name NAME TYPE VALUE ----------------------------------- ----------- ------ db_name string GHLEE SQL> show parameter domaine_name &#52091; 설정되어 있지 않음 -- Listener의 Service 상태 정보 [/oracle/product/10.2.0/network/admin> lsnrctl services Service "GHLEE" has 1 instance(s). Instance "GHLEE1", status READY, has 1 handler(s) for this service... Handler(s): "DEDICATED" established:6 refused:0 state:ready LOCAL SERVER Service "GHLEE1" has 1 instance(s). Instance "GHLEE1", status UNKNOWN, has 1 handler(s) for this service... Handler(s): "DEDICATED" established:0 refused:0 LOCAL SERVER

 위의 정보에서 보면 지금 Listener에는 “GHLEE”와 “GHLEE1”이라는 두 개의 서비스가 등록되어 있고, 각 서비스는 “GHLEE1” Instance에 등록되어 있음을 확인할 수 있다. 그리고 “GHLEE” 서비스는 상태 정보가 “READY”인 반면, “GHLEE1” 서비스의 상태 정보는 “UNKNOWN”임을 확인할 수 있다. “GHLEE”라는 서비스는 동적으로 등록된 서비스이므로 PMON에 의해 상태를 지속적으로 Listener에게 업데이트해줌으로써 상태 정보를 확인할 수 있어 “READY”라고 보이며, GHLEE1이라는 서버는 위의 listener.ora 파일에서 기술한 정보이므로 동적으로 등록되지 않아 상태 정보를 확인할 수 없어 “UNKNOWN”이라고 보이는 것이다. Dynamic Register의 구성 방법은 다음과 같다.

 ● Service Registration 구성
이것은 초기화 파라미터 중 “SERVICE_NAMES” 파라미터에 값을 설정함으로써 가능하다. 이 이름이 바로 Listener에 등록하는 서비스 이름으로 Default 이름은 DB Install 시에 설정한 dbname.domain이다. 여기서는 SERIVCE_NAMES 파라미터를 설정하지 않았어도, dbname.domain에 의해 서비스 이름이 “GHLEE”가 되었다.

 ● Default Local Listener Registration 방법
Default로 PMON process는 TCP/IP Port 1521을 사용하는 local Listener에 자동으로 서비스 정보를 등록한다. 위의 예제에서는 Default Port를 사용하고 dbname.domain에 의해서 “GHLEE”라는 서비스가 자동으로 등록되었다.

 ● NON-Default Listener Registration 방법
PMON에 의해 Local Listener에 등록을 원하고 TCP/IP가 Port 1521을 사용하지 않을 경우는 다음과 같이 LOCAL_ LISTENER PARAMETER를 설정하면 된다.

 LOCAL_LISTENER = <listener_alias> → Parameter file 기술
Listener_alias =
(DESCRIPTION= (ADDRESS=(PROTOCOL=TCP_(HOST= node1_vip)(PORT=1524))
→ 서버의 tnsnames.ora 파일에 기술
or
LOCAL_LISTENER =“(ADDRESS=(PROTOCOL=TCP)(HOST =node1_vip)(PORT=1524))” → Parameter 변경

 ● Remote Listener Registration 방법
PMON process에 의해 remote Listener를 등록하고 싶다면, 다음과 같이 REMOTE_LISTENER 파라미터를 설정해야 한다.

 REMOTE_LISTENER=< listener_alias> → Parameter file 기술
Listener_alias =
(DESCRIPTION= (ADDRESS=(PROTOCOL=TCP_(HOST =node2_vip)(PORT=1521))
or
REMOTE_LISTENER=“(ADDRESS=(PROTOCOL=TCP_(HOST =node2_vip)PORT=1521))”

 위와 같이 등록했을 때 LISTENER SERVICES를 확인하면 다음과 같다.

-- PMON에 의해 자동으로 등록하는 방법을 이용하기 위해 listener.ora 파일에 SID 정보를 기술하지 않는다. GHLEE2에도 다음의 상황처럼 기술한다. LISTENER_GHLEE1 = (DESCRIPTION_LIST = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = 192.128.25.18)(PORT = 1521))#ghlee1_vip (ADDRESS = (PROTOCOL = TCP)(HOST = 192.128.25.30)(PORT = 1521))#ghlee1_real ip )) -- service_names에 ghlee, ghlee1 서비스를 설정한다. SQL> alter system set service_names='GHLEE', 'GHLEE1' scope=BOTH sid='GHLEE1'; -- remote_listener에 ghlee2의 vip와 port 등을 설정한다. SQL> alter system set remote_listener='(address= (protocol=tcp)(host=192.128.25.19)(PORT=1521)' scope=BOTH sid='GHLEE1'; -- Listener Service의 정보 확인. 위의 Parameter 값들의 설정으로 인해 PMON에 의해서 자동으로 등록된 것을 확인할 수 있다. [ghlee1@/oracle/product/10.2.0/network/admin> lsnrctl services Service "GHLEE" has 2 instance(s). Instance "GHLEE1", status READY, has 1 handler(s) for this service... Handler(s): "DEDICATED" established:0 refused:0 state:ready LOCAL SERVER Instance "GHLEE2", status READY, has 1 handler(s) for this service... Handler(s): "DEDICATED" established:0 refused:0 state:ready REMOTE SERVER (ADDRESS=(PROTOCOL=TCP)(HOST=GHLEE2-vip)(PORT=1521)) Service "GHLEE1" has 1 instance(s). Instance "GHLEE1", status READY, has 1 handler(s) for this service... Handler(s): "DEDICATED" established:0 refused:0 state:ready LOCAL SERVER Service "GHLEE2" has 1 instance(s). Instance "GHLEE2", status READY, has 1 handler(s) for this service... Handler(s): "DEDICATED" established:0 refused:0 state:ready REMOTE SERVER (ADDRESS=(PROTOCOL=TCP)(HOST=GHLEE2-vip)(PORT=1521))

위와 같이 Server에 Dynamic Register 방식으로 구성하게 되면 각 Listener는 Server의 상태 정보를 가지고 있어 좀 더 Idle한 서버에서 클라이언트의 요청을 받을 수 있는 Load Balancing을 구현할 수 있다. 이제부터 Oracle RAC의 강력한 기능인 Fail-Over에 대해 살펴보도록 하겠다.

 Fail-Over

 CTF는 앞에서 언급했던 것처럼, connection할 당시 해당 서버에 장애가 발생했을 경우 이용 가능한 서버로 connection을 요청하는 방법으로 클라이언트의 tnsnames.ora 파일에 아래와 같이 설정하면 된다.

-- 클라이언트의 TNSNAMES.ORA ghlee = (DESCRIPTION = (LOAD_BALANCE=OFF)(LOAD_BALANCE=ON) (ADDRESS = (PROTOCOL = TCP)(HOST = 192.128.25.18)(PORT = 1521)) (ADDRESS = (PROTOCOL = TCP)(HOST = 192.128.25.19)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = GHLEE))) -- 10g RAC부터는 VIP를 사용하는데, 만약 NODE1이 DOWN되면 VIP NODE2가 가지고 감으로써 NODE2의 Listener에서 node1_vip, node2_vip를 둘 다 Listening한다. 그러므로 TCP TIMEOUT까지 대기할 필요가 없다

 TAF는 서버에 접속하여 작업 중일 때 작업 중이던 데이터베이스에 문제가 발생했을 경우에 이용 가능한 다른 Node에서 진행 중이던 작업을 계속 해주는 것으로서, 엔드유저는 이 데이터베이스에 장애를 감지하지 못하는 Fail-Over 방식이다. TAF의 Mode에는 현재 접속 중이던 Session을 Fail-Over시키는 Session 방식과 실행 중이던 Select 문을 다른 Node에서 장애가 발생한 시점 이후부터 다시 Select를 실행해주는 Select 방식이 있다.

 Fail-Over Method에는 Session이 맺어 있던 Node를 이용할 수 없을 경우 Oracle이 자동으로 살아있는 Instance 쪽으로 다시 접속하는 BASIC 방식과 Instance에 미리 Session을 접속해 Fail-Over 시에 세션을 새로 맺는 오버헤드를 줄이는 방식인 Preconnect 방식이 존재한다. 설정 방법은 다음과 같다.

 1. TYPE=SELECT, METHOD=BASIC

-- 클라이언트의 TNSNAMES.ORA test_basic1 = (DESCRIPTION = (FAILOVER=ON) (LOAD_BALANCE=ON) (ADDRESS = (PROTOCOL = TCP)(HOST =192.128.25.18)(PORT = 1521)) (ADDRESS = (PROTOCOL = TCP)(HOST =192.128.25.19)(PORT = 1521)) (CONNECT_DATA = (SERVICE_NAME = GHLEE) (FAILOVER_MODE = (TYPE=SELECT) (METHOD=BASIC)))) -- Session접속 [/oracle/product/10.2.0/network/admin>sqlplus scott/tiger@test_basic1 SQL>@se INST_ID USERNAME SID SERIAL# FAILOVER_M FAILOVER_TYPE FAI SERVICE_NAME ---------- --------------- ------- ---------- ---------- 1 SCOTT 2162 13814 BASIC SELECT NO GHLEE -- 접속한 Session에서 Long Query 실행 SQL> select * from t1; -- instance kill(접속된 Instance인 ghlee1을 Kill한다) [ghlee1@/oracle/product/10.2.0/network/admin>srvctl stop instance -d ghlee -i ghlee1 -o abort Sun Apr 12 10:30:55 KST 2009 -- 위의 접속되어 있는 Session의 상태는 INSTANCE가 죽을 당시 잠시 멈춰 있다가 다시 실행되는 현상을 확인할 수 있다. FAILED_OVER Column의 상태를 보면 “YES”로 되어서 Fail-Over되었음을 알 수 있다. SQL> @se INST_ID USERNAME SID SERIAL# FAILOVER_M FAILOVER_TYPE FAI SERVICE_NAME ---------- --------------- ------- ---------- ---------- 2 SCOTT 2177 10 BASIC SELECT YES GHLEE

 

<표 2> 결과 정보

 2. TYPE=SELECT, METHOD=PRECONNECT

-- 클라이언트의 TNSNAMES.ORA. Preconnect 방식을 이용할 때는 반드시 BACKUP을 명시해야 한다. test_preconn1 = (DESCRIPTION = (FAILOVER=ON) (LOAD_BALANCE=ON) (ADDRESS = (PROTOCOL = TCP)(HOST = 192.128.25.18)(PORT = 1521)) (ADDRESS = (PROTOCOL = TCP)(HOST = 192.128.25.19)(PORT = 1521)) (CONNECT_DATA = (SERVICE_NAME = CAFE4DB) (FAILOVER_MODE = (TYPE=SELECT) (METHOD=PRECONNECT) (BACKUP=PRECONNECT2) ))) PRECONNECT2 = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = 192.128.25.19)(PORT = 1521)) (CONNECT_DATA = (service_name = GHLEE) (instance_name = GHLEE2) ) ) -- Session 접속 (미리 2개의 Session이 연결되어 있는 것을 확인할 수 있다) [/oracle/product/10.2.0/network/admin>sqlplus scott/tiger@test_preconn1 SQL>@se INST_ID USERNAME SID SERIAL# FAILOVER_M FAILOVER_TYPE FAI SERVICE_NAME ---------- --------------- ------- ---------- ---------- 1 SCOTT 2162 13814 PRECONNECT SELECT NO GHLEE 2 SCOTT 1065 10351 NONE NONE NO GHLEE --접속한 Session에서 Long Query 실행 SQL> select * from t1; -- instance kill(접속된 Instance인 ghlee1을 Kill한다) [ghlee1@/oracle/product/10.2.0/network/admin>srvctl stop instance -d ghlee -i ghlee1 -o abort Sun Apr 12 10:35:25 KST 2009 -- 위의 접속되어 있는 Session의 상태는 INSTANCE가 죽을 당시 잠시 멈춰 있다가 다시 실행되는 현상을 확인할 수 있다. FAILED_OVER Column의 상태를 보면 "YES"로 되어서 Fail-Over되었다는 것을 알 수 있다. SQL> @se INST_ID USERNAME SID SERIAL# FAILOVER_M FAILOVER_TYPE FAI SERVICE_NAME ---------- --------------- ------- ---------- ---------- 2 SCOTT 1065 10351 PRECONNECT YES NO GHLEE

 

<표 3> 결과 정보

 3. TYPE=SESSION, METHOD=BASIC

-- 클라이언트의 TNSNAMES.ORA test_basic2 = (DESCRIPTION = (FAILOVER=ON) (LOAD_BALANCE=ON) (ADDRESS = (PROTOCOL = TCP)(HOST = 192.128.25.18)(PORT = 1521)) (ADDRESS = (PROTOCOL = TCP)(HOST = 192.128.25.19)(PORT = 1521)) (CONNECT_DATA = (SERVICE_NAME = CAFE4DB) (FAILOVER_MODE = (TYPE=SESSION) (METHOD=BASIC)))) -- Session 접속 [/oracle/product/10.2.0/network/admin>sqlplus scott/tiger@test_basic2 SQL>@se INST_ID USERNAME SID SERIAL# FAILOVER_M FAILOVER_TYPE FAI SERVICE_NAME ---------- --------------- ------- ---------- ---------- 1 SCOTT 1050 1822 BASIC NO GHLEE -- 접속한 Session에서 Long Query 실행 SQL> select * from t1; -- instance kill(접속된 Instance인 ghlee1을 Kill한다) [ghlee1@/oracle/product/10.2.0/network/admin>srvctl stop instance -d ghlee -i ghlee1 -o abort Sun Apr 12 10:40:01 KST 2009 -- 이 방식은 Session만 보장하는 방식으로 실행되고 있던 Select는 "ora-25401 : can not continue fetches"라는 Error를 뿌리면서 종료된다. SQL> @se INST_ID USERNAME SID SERIAL# FAILOVER_M FAILOVER_TYPE FAI SERVICE_NAME ---------- --------------- ------- ---------- ---------- 2 SCOTT 1023 10231 BASIC YES GHLEE

 

<표 4> 결과 정보

 4. TYPE=SESSION, METHOD=PRECONNECT

-- 클라이언트의 TNSNAMES.ORA test_preconn2 = (DESCRIPTION = (FAILOVER=ON) (LOAD_BALANCE=ON) (ADDRESS = (PROTOCOL = TCP)(HOST = 192.128.25.18)(PORT = 1521)) (ADDRESS = (PROTOCOL = TCP)(HOST = 192.128.25.19)(PORT = 1521)) (CONNECT_DATA = (SERVICE_NAME = CAFE4DB) (FAILOVER_MODE = (TYPE=SESSION) (METHOD=PRECONNECT) (BACKUP=PRECONNECT2) ))) PRECONNECT2 = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = 192.128.25.19)(PORT = 1521)) (CONNECT_DATA = (service_name = GHLEE) (instance_name = GHLEE2))) -- Session 접속 (미리 2개의 Session이 연결되어 있는 것을 확인할 수 있다) [/oracle/product/10.2.0/network/admin>sqlplus scott/tiger@test_preconn2 SQL>@se INST_ID USERNAME SID SERIAL# FAILOVER_M FAILOVER_TYPE FAI SERVICE_NAME ---------- --------------- ------- ---------- ---------- 1 SCOTT 1098 143 PRECONNECT SESSION NO GHLEE 2 SCOTT 1023 159 NONE NONE NO GHLEE -- 접속한 Session에서 Long Query 실행 SQL> select * from t1; -- instance kill(접속된 Instance인 ghlee1을 Kill한다) [ghlee1@/oracle/product/10.2.0/network/admin>srvctl stop instance -d ghlee -i ghlee1 -o abort Sun Apr 12 10:45:23 KST 2009 -- Instance에 장애가 발생함과 동시에 "ora-25401 : can not continue fetches"라는 Error를 뿌리면서 종료된다. SQL> @se INST_ID USERNAME SID SERIAL# FAILOVER_M FAILOVER_TYPE FAI SERVICE_NAME ---------- --------------- ------- ---------- ---------- 2 SCOTT 1023 159 PRECONNECT SESSION YES GHLEE

 

<표 5> 결과 정보

 아쉬운 점은 Instance가 종료된 이후 Node가 다시 정상적으로 이용 가능하다고 하더라도 RAC 내에서 자동으로 Fail-Over된 Session을 다시 원래의 Node로 돌려주는 기능은 아직 구현되어 있지 않다는 것이다. DBA가 원래 Node의 Instance로 돌려주어야 한다.

exec dbms_service.disconnect_session(service_name); or ALTER SYSTEM DISCONNECT SESSION 'sid, serial' POST_TRANSACTION;

 

본문에 사용한 스크립트

in.sql
col host_name format a15
col INSTANCE_NAME format a15
select INSTANCE_NUMBER,INSTANCE_NAME,HOST_NAME from v$instance;

se.sql
col service_name format a15
select instance_id, username, sid, serial#, failover_method, failover_type, failed_over, service_name
from gv$session
where program='sqlplus.exe'

OLTP 환경에서는 수행 시간이 긴 Select 문은 거의 존재하지 않으므로 보통은 Session 방식으로 설정하여 사용하며, DW 환경과 같이 수행시간이 긴 Select 문에서는 Select 방식을 많이 선호한다. 아쉽게도 DML은 아직 지원되고 있지 않다. Preconnect 방식은 오버헤드는 줄여줄 수 있지만 하나의 Session을 맺을 때 미리 하나의 Session을 더 맺어두는 방식으로 한번 연결에 총 두 개의 Session을 맺으므로 시스템에 Idle한 Server Process가 하나 더 생성되는 방식이므로 리소스의 낭비를 초래할 수 있다. 각자의 환경에 맞게 Fail-Over 환경을 구성함으로써 효율적인 HA를 구성해 사용하길 바란다.

참고자료
1. Oracle Net Services Administrator's Guide
2. http://metalink.oracle.com

저작자표시 비영리 변경금지

'Database > Oracle' 카테고리의 다른 글

Admin Workshop 1 - 구조 10g  (0) 2009.12.30
Query 실행 과정 10g  (1) 2009.12.30
Backup and Recover  (0) 2009.12.30
Admin Workshop 1 - 구조  (0) 2009.12.15
Query 실행 과정  (1) 2009.12.15

+ Recent posts

티스토리툴바