RAC ONE NODE (Oracle Database HA Solution)

Advanced Oracle Document

RAC ONE NODE

(Oracle Database HA Solution)

Author: Hyun-Ho, Jung

Site: http://www.commit.co.kr

Email: [email protected]

[email protected]

Creation Date: 2011-09-18

Advanced Oracle Document …

Document 1 of 34

Document

Server Information

Items Description

Test Date 2011 / 09 / 18~24

Machine OracleVM Server 2.2.2

CPU vcpus = 4

Main Memory 3000MB

O/S version Solaris 10 (2Node)

Host Name jupiter1 , 2

GLOBAL DATABASE NAME JUPITER

ORACLE_SID JUPITER_1 , JUPITER_2

SERVICE NAME JUPITER.RON.COM

Oracle version 11.2.0.2


RAC ONE NODE 2 of 34

RAC ONE NODE

RAC ONE NODE 는 Oracle 11gR2 의 NF 중 하나이며,

Oracle RAC One Node 는 클러스터 노드 중 하나에서 작동되는 단일 인스턴스의 Oracle RAC 이며

오버헤드를 최소화하면서도 다수의 데이터베이스를 단일 클러스터에 통합할 수 있기 때문에

Failover, 롤링 방식의 온라인 패치 적용을 비롯해 Oracle Clusterware 를 위한 롤링 방식의 업그레이드를 통해

뛰어난 HA 이점을 제공하게 된다.

RAC ONE NODE 를 가장 쉽게 위해 할수 있는 것이 위의 그림이다.

가장 큰 기능인 failover 에 대한 그림이며, 물리적인 서버에 1 개이상의 인스턴스는 구동되어있을 것이고

해당 머신이나 인스턴스에 장애가 발생시 클러스터 그룹내 다른 서버로 Failover 가 되는 것이다.

OS Vender Cluster 나 3rd Party Cluster 를 이용한 HA 방식과 유사한다.

타 솔루션의 클러스터를 이용한 HA기능을 Oracle Grid infrastructure(이하 grid) 가 제공하게 된다.



애플리케이션에서 다운타임을 발생하지 않도록 Oracle RAC One Node 인스턴스를 클러스터의 또 다른

노드로 마이그레이션할 수 있도록 Omotion유틸리티(11.2.0.1 에서만) 가 제공되며, 일단 인스턴스가

마이그레이션되면 노드에 패치를 적용하거나 업그레이드등을 할수 있으며, 유지보수 작업이 완료되면

Oracle RAC One Node 를 다시 원래 Node 로 Relocate 가 가능하다.

RAC 가 대중화가 되었지만 HA 방식으로 사용할만한 구성이나 요건발생시 RAC 대신 HA를 사용하는 일은

자주 있는 일이다. 그렇다면 아직도 사용 되는 HA 에서 OS Vender Cluster 나 3rd Party Cluster 와

Oracle Grid 를 이용한 RAC ONE NODE 의 차이는 무엇일까?

아래 표로 확인이 가능하다.

해당 표에는 기술되어 있지 않지만 High Availability 부분에서 3rd Part Clustering 에서도 인스턴스의 프로세스를

감지하여 인스턴스가 문제시 Failover 를 할수 있다, 하지만 오라클 프로세스 모니터링이라는 것이 단순히

프로세스 의 유무를 가지고 돌아가는 Shell script 이기 때문에 Grid가 직접적으로 인스턴스를 관리하는 것과는

많은 차이를 보이게 된다.

위의 표에서 없는 부분중 아래 부분도 추가 해서 보는 것이 맞다라고 생각한다.



Grid를 사용한 HA의 경우 Instance 외 listener 와 같은 부가 적인 리소스들도 관리가 가능하기 때문에

이 부분도 3rd 제품보다 좋다고 할 수 있다.

Grid를 바탕으로 한 데이터베이스는 Oracle Restart 의 정책을 기반으로 동작하게 됨으로 instance 가

Crash 되거나 Listener 프로세스 Fault시 단순하게 Failover 를 시키는 Vender Cluster 와 달리 Grid가

instance 및 Listener 를 재구동하게 된다.

이러한 면을 봤을 때 Vendor Cluster 보다 oracle database 를 HA 환경에 사용함에 있어서 Grid가 더 탁월

하다고 할 수 있다.

RAC ONE NODE 의 가장 큰 제약 사항이라면 Enterprise Option 이라는 것이다.

라이선스 상 EE Option 으로 분류 되어 있다.

하지만 아래화면과 같이 Grid Installation Options 에서 RAC ONE NODE 를 선택 후 진행 해도 standard Edition

이 선택이 가능하며, 실제로도 DBCA 를 이용하여 인스턴스는 생성 가능하며 , RAC ONE NODE 기능 또한 사용

가능하다

http://download.oracle.com/docs/cd/E14072_01/server.112/e10595/restart001.htm



RAC: Frequently Asked Questions [ID 220970.1] 에서 확인 하면

Can I use Oracle RAC One Node for Standard Edition Oracle RAC?

No, Oracle RAC One Node is only part of Oracle Database 11g Release 2 Enterprise Edition. It is not licensed or supported for use with any other editions.

라고 나와있다.

http://www.oracle.com/us/corporate/pricing/price-lists/index.html 에 있는

http://www.oracle.com/us/corporate/pricing/technology-price-list-070617.pdf 를 참조 하면

Processor License 기준으로 아래와 같이 RAC 에 비해 반 이상 저렴하다.

RAC => 23000$

RAC ONE => 10000$

또한 RAC ONE NODE 는 특이한 라이선스 정책이 존재 한다.

RAC: Frequently Asked Questions [ID 220970.1] 의 내용 중 아래 와 같은 내용이 존재한다.

Oracle RAC One Node licensing also includes the 10-day rule, allowing a database to relocate to another node for up to 10 days per year, without incurring additional licensing fees. This is most often used in the case of failover, or for planned maintenance and upgrading. Only one node in the cluster can be used for the 10-day rule

년간 10 일 Rule 이라는 것이 존재 하는데, Omotion 이나 failover, 계획된 MA에 의한 인스턴스를 다른 노드로

옴 기는 것에 대해서 1 년중 10 일 동안은 무료 라는 부분이다.

외국 블로그 에서는 Standby Node 의 라이선스가격은 제외 된다는 내용도 있지만 해당 부분은 확인이

불가한 부분이다. 하지만 위의 FAQ 에서 나온 10 일 동안 무료 라는 부분으로 유추 하기론 Standby Node 에

대한 부분은 10 일간 Free 이고 그 이상 사용시 부가 된다 라고 생각 해볼 수 있다(검증 안됨)

참고사항

구성 시 RAC ONE NODE를 사용하려는 모든 Node는 Grid가 설치되어 있어야 한다.

그렇기 때문에 RAC와 동일하게 Shared Storage(Disk) 가 필요하며, RAC와 동일하게 VIP 와 Interconnect IP 등이

준비 되어있어야 한다.

본 문서는 2Node 환경에서 Grid가 설치 완료된 환경에서의 S/W설치시작 부분부터 기술되어있으며, Storage Type은

ASM 을 사용 한다.

설치 와 관리에 사용하는 명령어 등이 11.2.01 과 11.2.0.2 는 차이가 있다 11.2.0.2 기준으로 문서는 작성 되어있으며,

차이가 나는 부분은 별도로 기술되어 있다.

http://www.oracle.com/us/corporate/pricing/price-lists/index.html

http://www.oracle.com/us/corporate/pricing/technology-price-list-070617.pdf



RAC ONE NODE

1. S/W

11.2.0.1 의 S/W 설치 화면이다. 11.2.0.1 버전에서는 RAC 를 선택 하고 진행한다.

11.2.0.2 에서는 S/W 설치 단계에서 RAC ONE NODE 선택 메뉴가 있다



2. DBCA

11.2.0.1 에서는 아래와 같이 하나의 Node 만 선택하고 진행한다.

11.2.0.2 에서는 DBCA 메뉴에서 ONE NODE 항목이 추가 되었다.



아래와 같이 Global Database Name , SID, Service Name 을 기술한다.

Service Name 은 RAC 의 Service Name 과 유사함으로써 SID 와 동일 할 수 없다.

데이터베이스는 사용할(Active) Node 와 예비 Node 까지 선택 한다.

만약 3 개의 Node 에서 2 개만 RAC ONE NODE 에 사용하려면 2 개를

선택하는 것이다.

DBCA 를 실행 한 Local Node 는 반드시 활성화(선택됨) 되어 있으며 그 외

RAC ONE NODE 에 사용할 나머지 노드를 선택 하면 된다.

DBCA 진행 중 SCAN IP 가 없다면 SCAN LISTENER 가 존재 하지 않는 다는 경고가

발생 된다. 테스트 결과 DNS없이 /etc/hosts에 등록된 1 개의 SCAN IP 도 사용

가능하다. 가능하다면 Single Client Access Name(SCAN) 을 사용해도 나쁘지

않을 것 이다.



RAC 와 유사 하게 UNDOTBS 는 2 개가 default 이며,

REDO 또한 4 개의 Group 과 Thread 개념이 존재한다.



3. Current Status

현재 database 상태 조회

srvctl status database -d JUPITER

JUPITER1_1 의 Instance 가 jupiter1 노드에서 구동 중이며,

Relocation 상태는 INACTIVE 라는 걸 확인 할 수 있다.

$ srvctl config database -d JUPITER

database 의 config 현재 설정 및 정책 등을 살펴 볼 수 있다

Database unique name: JUPITER Database name: JUPITER Oracle home: /oracle/product/112/db Oracle user: oracle Spfile: +DATA/JUPITER/spfileJUPITER.ora Domain: Start options: open Stop options: immediate Database role: PRIMARY Management policy: AUTOMATIC Server pools: JUPITER Database instances: Disk Groups: DATA Mount point paths: Services: JUPITER.RON.COM Type: RACOneNode Online relocation timeout: 30 Instance name prefix: JUPITER Candidate servers: jupiter1,jupiter2 Database is administrator managed

Candidate Servers 나 Servcies 명 Type 등의 정보 등을 확인 하면 되며,

online relocation timeout : 30 의 경우 relocation 의 임계치 이며,

단위 는 분으로 써 최대 30 분안으로 relocate 하겠다 라는 의미이다.

Instance JUPITER_1 is running on node jupiter1 Online relocation: INACTIVE



$ srvctl config service -d JUPITER

config service 로 현재 JUPITER.RON.COM 이라는 서비스명 과 해당 설정 내역을

확인 가능 하다 Failover Type, method 등 relocate 시 정책이 설정 되어있다.

11.2.0.1 에서 존재 하였던 명령어는 아래와 같다.

raconestatus

raconeinit

raconefix

Omotion

11.2.0.2 에서는 srvctl 로 모두 통합 되었으며, 위의 명령어는 존재 하지 않는다.

4. RAC ONE NODE SID

RAC ONE NODE 에서의 SID 는 예전과는 조금은 다르다.

설치 시 Global Database Name 을 JUPITER 로 지정하였고

RAC 라면 노드별로 JUPITER1,JUPITER2….n 의 방식으로 SID 가 지정 된다.

Service name: JUPITER.RON.COM Service is enabled Server pool: JUPITER Cardinality: 1 Disconnect: false Service role: PRIMARY Management policy: AUTOMATIC DTP transaction: false AQ HA notifications: false Failover type: NONE Failover method: NONE TAF failover retries: 0 TAF failover delay: 0 Connection Load Balancing Goal: LONG Runtime Load Balancing Goal: NONE TAF policy specification: BASIC Edition: Preferred instances: JUPITER_1 Available instances:



RAC ONE NODE 는 JUPITER_1 , JUPITER_2 와 같이 _(언더바) 가 포함 되어

RAC 와는 다르게 표기 된다.

Omotion 이나 srvctl 을 통해 Relocate 하여 다른 노드로 이동 시키면 해당 SID는

변경 된다. 가령 1 번 노드에서 2 번노드로 Relocate 시키게 되면 JUPITER_2 로

2 번 노드에서 구동 된다.

하지만 1 번 노드에서는 항상 JUPITER_1 SID 로 , 2 번노드에서는 JUPITER_2 로

구동 되는 것은 아니다. 이 부분은 뒤에서 TAF 및 Relocate 설명 후 진행 하겠다.

5. Instance Relocate

11.2.0.1 까지 Omotion 이라는 커맨드로 Instance Migrate 하였는데,

Omotion 이란 커맨드의 의미를 먼저 설명하면

Oracle 에서는 RAC ONE NODE 를 가상화 와 비슷 하다라고 표현하면서,

Oracle VM 에서 Certified 솔루션이라는 소개도 한다.

VMware 의 Vmotion 와 Citrix 의 XEN Motion 유사한 기능 이며, 해당기능은

설치된 물리적 서버에서 작동중인 Virtual Machine 을 다른 ESX(물리서버) 서버로

shutdown 하지 않은 채 Live 상태로 이동시키는 기능을 의미한다



Omotion 이라는 커맨드도 위와 유사한 의미을 지니고 있다

하지만 가상화의motion 기능 보다는 부드럽지는 못한 것은 사실이다.

RAC 에서도 select 를 제외 하고 DML 은 트랜젝션이 롤백 된다는 사실은 알고

있을 것이다.

그럼 RAC ONE NODE 는 어디 부분 까지 가능 한지는 뒤에 있는 TEST 를 통해

확인 해보도록 하겠다.

Instance 의 Migrate 시 더 이상 Omotion 명령어를 사용 하지 않는다.

11.2.0.1 에서만 사용 가능하며, 11.2.0.2 에서는 srvctl를 사용 하게 된다.

srvctl relocate database -d 데이터베이스명 -n 옴기려는 노드명 -w 1 -v

-w 옵션을 기술 하지 않는다면 online relocation timeout : 30 이 적용된다

단위 는 분 이며 , 이 시간은 세션을 종료 하고 , 인스턴스를 migrate , 트랜잭션을

OPEN 하는 시간을 의미 한다.

시간 안에 트랜젝션이 종료 되지 않는다면, shutdown abort 과 같은 일환으로

트랜젝션은 취소 가 되며, 세션은 사라질 것이다.

이런 시간에 대한 제한에 대해서 default 30분이 아닌 다른 시간으로 제한을 두고자

할 때 -w 옵션을 사용한다.

보통의 경우 테스트 문서나 외국 문서들의 대부분이 -w 1 을 주며 시간의 범위는

1~720 분 까지 이다.

-v 옵션은 진행 중인 자세한 내역을 표시 하는 것이다.



실제로 아래와 같은 명령어로 relocate 하게 된다.

srvctl relocate database -d JUPITER -n jupiter2 -w 1 -v

위의 진행 상황을 보게 되면 JUPITER_2 가 먼저 기동이 된 후

1 분안에 JUPITER_1 (1 번 NODE 에서 구동 중인 Instance)의 종료를 기다리고 있다.

종료 된 후 Reconfiguration 이 된다.

dbca 진행 시 위에서 RAC 와 같은 Thread 개념이 존재하며, undotbs 가 노드별로

존재 하는 이유 이다. 짧지만 Relocate 되는 순간, Candidate Node 에서

Instance 를 구동하게 된다.

그렇기 때문에 Datafile Umount => 신규 NODE 에서 MOUNT => Instance Startup

의 방식으로 Instance 가 완전히 종료 되는 OS Vendor Cluster 혹은 3rd Party Cluster

와는 다른 것이다.

그렇기 때문에 짧지만 2 개의 Instance 가 구동이 되기 때문에 노드 별로 Thead가

존재 하며, Redo, undotbs 를 다르게 사용 하는 것이다.

진행 중 다른 세션(창) 에서 srvctl status database -d JUPITER 로 확인 해보면

아래와 같이 진행 내역을 확인 할 수 있다.

Configuration updated to two instances

Instance JUPITER_2 started

Services relocated

Waiting for 1 minutes for instance JUPITER_1 to stop.....

Instance JUPITER_1 stopped

Configuration updated to one instance



아직 까지는 INACTIVE 상태 이다.

Active 상태로 변경 되었으며, Source Instance 에 대한 정보가 표기 된다.

각 Node 별로 Instance 가 개별 적으로 구동 되었다고 알 수 있으며,

Source Instance 와 Destination Instance 가 어느 NODE 에서 구동 되는지가

표기된다.

JUPITER_1 인스턴스(1번 NODE) 의 대한 정보가 사라 졌다.

현재 상태가 JUPITER_1 이 shutdown 이 완료 된 시점이다.

마지막 으로 Online relocation 이 INACTIVE 되면서 2 번노드에서

JUPITER_2 인스턴스가 정상 구동 됨을 알 수 있다.


Instance JUPITER_1 is running on node jupiter1 Online relocation: ACTIVE

Source instance: JUPITER_1 on jupiter1

Instance JUPITER_1 is running on node jupiter1 Instance JUPITER_2 is running on node jupiter2

Online relocation: ACTIVE Source instance: JUPITER_1 on jupiter1 Destination instance: JUPITER_2 on jupiter2

Instance JUPITER_2 is running on node jupiter2 Online relocation: ACTIVE Source instance: JUPITER_1 on jupiter1 Destination instance: JUPITER_2 on jupiter2




위와 같은 프로세스로 relocate 는 진행 되며 그래서 각 노드별로 _n 의 SID 가

존재 하는 것이다.

다시 1 번 노드로 migrate 하려면 아래와 같으며 일단 다시 relocate 를 한다.

srvctl relocate database -d JUPITER -n jupiter1 -w 1 -v

6. Change Settings

위에서 조회해 봤듯이 현재는 정상적인 relocate 에도 TAF,CTF등은 적용 되지

않는다. default 정책에서 수정해야 한다.

srvctl modify service -d 를 이용하여 각종 속성을 변경한다.

사용 가능한 속성은 아래와 같다.

-P {BASIC|PRECONNECT|NONE} : TAF Failover 정책

■ BASIC : On-demand 방식으로 Failover 가 필요할 때 살아 있는

인스턴스 쪽으로 Oracle Server Process 를 기동 한다.

■ PRECONNECT : Failover 가 이루어질 인스턴스에 미리 Oracle Server

Process 를 기동시켜 Failover 가 발생하는 오버헤드를

미리 줄여 놓는 방식, Failover 속도는 향상되지만

자원의 낭비는 초래 할 수 있다.

<RAC ONE NODE 에서는 사용불가 옵션>

-j {SHORT | LONG} : Connection Load Balancing Goal

-B {NONE | SERVICE_TIME | THROUGHPUT} : Runtime Load Balancing Goal

-m {NONE | BASIC} : Failover method

-e {NONE | SESSION | SELECT} : Failover type

■ NONE : TAF 기능 사용 하지 않는다.

■ SESSION : select 하다가 접속되어져 있는 노드가 다운이 되면 살아있는

노드로 재 접속은 되지만 fetch 가 진행 중이었다면

fetch 는 도중에 실패하게 된다.

■ SELECT : session 과 같고 fetch도 이어서 진행해 준다.

즉 . 대량의 레코드를 한번에 select 하는 app에 효율적이다.



-w failover_delay : Failover 시도에 지연 임계치

-z failover_retries : Failover 시도 횟수

위 의 속성 중 NONE 으로 설정 된 TAF Failover Policy, Failover type , Failover

method 를 변경 할 것이다.

TAF Failover Policy 는 PRECONNECT

Failover type 은 SELECT / Failover Method 는 Basic 으로 변경한다.

$ srvctl modify service -d JUPITER -s JUPITER.RON.COM -P PRECONNECT \

-e SELECT -m BASIC

Service name: JUPITER.RON.COM

Service is enabled

Server pool: JUPITER

Cardinality: 1

Disconnect: false

Service role: PRIMARY

Management policy: AUTOMATIC

DTP transaction: false

AQ HA notifications: false

Failover type: SELECT

Failover method: BASIC

TAF failover retries: 0

TAF failover delay: 0

Connection Load Balancing Goal: LONG

Runtime Load Balancing Goal: NONE

TAF policy specification: BASIC

Edition:

Preferred instances: JUPITER_1

Available instances:



7. TAF TEST

참고로 TAF 는 OCI 방식에서만 가능하며, JDBC THIN 드라이버의 경우

CTF 와 10g JDBC 부터 나온 Fast Connection Failover(FCF) 만 사용 가능 하다.

tnsnames.ora 의 구성은 아래와 같이 2 가지 방식으로 가능하다.

1) 이전과 동일하게 2 개의 VIP 와 FAILOVER=ON 을 기술해서 사용 하는 방법

JUPITER_VIP=

(DESCRIPTION =

(ADDRESS_LIST=

(LOAD_BALANCE=ON)

(FAILOVER=ON)

(ADDRESS = (PROTOCOL = TCP)(HOST = 10.10.1.169)(PORT = 1521))

(ADDRESS = (PROTOCOL = TCP)(HOST = 10.10.1.168)(PORT = 1521)))

(CONNECT_DATA =

(SERVICE_NAME = JUPITER)

(FAILOVER_MODE=(TYPE=SELECT)(METHOD=BASIC))

)

)

2) 아래와 같이 SCAN IP 를 이용 하는 방법이 있다.

JUPITER_SRV =

(DESCRIPTION =

(ADDRESS = (PROTOCOL = TCP)(HOST = jupiter_scan)(PORT = 1521))

(CONNECT_DATA =

(SERVER = DEDICATED)

(SERVICE_NAME = JUPITER.RON.COM)

)

)

SCAN IP 를 이용할 경우 SERVICE_NAME 에는 DBCA 로 생성시 지정한

SERVICE_NAME 으로 해야 한다.



테스트에 사용 할 쿼리는 아래와 같다.

Filename : ron.sql

col sid format 99999

col serial# format 99999999

col failover_type format a13

col failover_method format a15

col failed_over format a11

select sid, serial#, failover_type, failover_method, failed_over from v$session where

username ='SYSTEM';

select instance_name from v$instance;

select count(*) from

(

select * from dba_source union


















select * from dba_source

);

col sid format 99999

col serial# format 99999999

col failover_type format a13

col failover_method format a15

col failed_over format a11



select sid, serial#, failover_type, failover_method, failed_over from v$session where

username ='SYSTEM';

select instance_name from v$instance;

select count(*) from

(



















select * from dba_source

);

■ TEST 1 : Active Session

Test 는 쿼리 수행 중 relocate 가 발생 되었을 때 세션 및 Select 작업에 대한

TAF 가 가능한지를 확인한다.

다른 oracle client 가 설치된 host에서 아래 커맨드로 ron.sql 을 실행한다.

sqlplus system/oracle@JUPITER_VIP<ron.sql

실행 중 relocate 를 실시 한다. 결과는 아래와 같다.



$ sqlplus system/oracle@JUPITER_VIP<ron.sql

SQL*Plus: Release 11.1.0.7.0 - Production on Tue Sep 20 03:11:44 2011

Copyright (c) 1982, 2008, Oracle. All rights reserved.

Connected to:

Oracle Database 11g Release 11.2.0.2.0 - 64bit Production

With the Real Application Clusters and Automatic Storage Management options

SID SERIAL# FAILOVER_TYPE FAILOVER_METHOD FAILED_OVER

------ --------- ------------- --------------- -----------

766 55 SELECT BASIC NO

=>> SID 는 766 이며 현재 Failover 가 된 상태는 아니다.

INSTANCE_NAME

----------------

JUPITER_1

=>> Instance 이름은 JUPITER_1 이다.

COUNT(*)

----------

158519

==>> 여러 개의 union 으로 된 쿼리가 수행이 되어 count 가 return 되었다.

SID SERIAL# FAILOVER_TYPE FAILOVER_METHOD FAILED_OVER

------ --------- ------------- --------------- ------------------------------------------

2278 23 SELECT BASIC YES

==>> 위와 동일 하게 SID등을 조회 한다. SID 및 SERIAL# 값이 변경 되었다.

FAILED_OVER 가 YES 로 되어있는 것으로 정상적으로 Failover 가 됨을 확인

가능하다



INSTANCE_NAME

----------------

JUPITER_2

==>> 인스턴스명도 JUPITER_2 로 변경 되었다.

COUNT(*)

----------

158519

인스턴스 2 에서 조회 한(쿼리가 수행된) count 값도 return 받았다.

srvctl status database -d JUPITER 로 조회 하면

2 번 노드에서 JUPITER_2 인스턴스가 구동중임을 확인 할 수 있다.

■ TEST 2 : Idle Session

SYSTEM@jupiter_vip> select sid, serial#, failover_type, failover_method, failed_over from

v$session where username ='SYSTEM';

SID SERIAL# FAILOVER_TYPE FAILOVER_M FAI

---------- ---------- ------------- ---------- -------------------------

11 81 SELECT BASIC NO

==>> 현재는 1 번노드의 인스턴스에서 Idle session 상태 이다.

Instance JUPITER_2 is running on node jupiter2

Online relocation: INACTIVE



SYSTEM@jupiter_vip> select instance_name from v$instance;

INSTANCE_NAME

----------------

JUPITER_1

==>> SID 는 JUPITER_1 이다. srvctl 로 relocate 를 실시 후 다시 확인 해보면

SYSTEM@jupiter_vip> select sid, serial#, failover_type, failover_method, failed_over from

v$session where username ='SYSTEM';

SID SERIAL# FAILOVER_TYPE FAILOVER_M FAI

---------- ---------- ------------- ---------- ------------------------

1527 5 SELECT BASIC YES

SYSTEM@jupiter_vip> select instance_name from v$instance;

INSTANCE_NAME

----------------

JUPITER_2

==>> Active Session 일 때 테스트한 결과와 동일하게 Session 에 대한

Fail-over 가 정상적으로 동작 하였다.

8. FAILOVER TEST

TEST1) pmon process kill

다시 노드를 1 번으로 relocate 후 위와 동일하게 쿼리를 수행 중 pmon 프로세스를

kill 로 종료를 하겠다.

crs_stat -p ora.jupiter.db 로 조회 하면 아래와 같아 CHECK_INTERVAL 은

default value 가 1 초이다. 따로 수정 없이 진행 하겠다.



NAME=ora.jupiter.db

TYPE=ora.database.type

ACTION_SCRIPT=

ACTIVE_PLACEMENT=1

AUTO_START=restore

CHECK_INTERVAL=1

DESCRIPTION=Oracle Database resource

FAILOVER_DELAY=0

FAILURE_INTERVAL=60

FAILURE_THRESHOLD=2

GEN_START_OPTIONS@SERVERNAME(jupiter1)=open

GEN_START_OPTIONS@SERVERNAME(jupiter2)=open

GEN_USR_ORA_INST_NAME@SERVERNAME(jupiter1)=JUPITER_1

GEN_USR_ORA_INST_NAME@SERVERNAME(jupiter2)=JUPITER_2

HOSTING_MEMBERS=

PLACEMENT=restricted

RESTART_ATTEMPTS=2

SCRIPT_TIMEOUT=60

START_TIMEOUT=600

STOP_TIMEOUT=600

UPTIME_THRESHOLD=1h

PMON 을 kill 로 종료 시키게 되면 JUPITER_1 의 Alert 에 아래와 같은 메시지와

함께 바로 인스턴스가 재 구동 된다.

도입부에 설명한 내용과 같이 Grid를 기반으로 하여 Oracle Restart 정책이

반영 되어있기 때문에 process 의 비정상 종료는 다른 노드로 Take-Over 하지 않고

현재 노드에서 1 초 내외로 인스턴스 구동을 하게 된다.

Tue Sep 20 03:37:05 2011

Shutting down instance (abort)

License high water mark = 5

USER (ospid: 20092): terminating the instance

Instance terminated by USER, pid = 20092

Tue Sep 20 03:37:07 2011

Instance shutdown complete

Tue Sep 20 03:38:35 2011

Starting ORACLE instance (normal)



이 부분 또한 프로세스 기반으로 모니터링 하여 Take Over 하거나 인스턴스를

구동하는 Vendor Cluster 보다 빠르게 동작한다.

TEST2) shutdown abort

Active session 혹은 Idle session 모두 shutdown 에 대한 부분은 fail-over 되지

않는다 abort 또한 shutdown 옵션 중 하나이기 때문에 instance 를 재기동 한다던가

다른 Node에서 재시작 하는 등의 Action은 존재 하지 않는다.

relocate 시 세션이 유지 되는 것은 위에서도 설명 되었던 것처럼 짧은 시간 다른

Candidate node 에서 Instance 가 구동되어 해당 서버프로세스 등의 정보를 받아

오기 때문에 가능 한 부분임으로 shutdown abort 과 같이 다른 유휴 노드에서

인스턴스 구동에 걸리는 시간보다 빠르게 종료 되는 상황이라면

Active session/ idle session 모두 Failover 는 불가능 하다.

TEST3) OS reboot

OS reboot 의 경우 OS의 Crash와 유사한 경우로써 session 이나 쿼리에 대한

Failover 는 불가능 하다. 하지만 시스템 사향에 따라 다르지만

20 초~수분 사이에 Grid 에 의해서 Candidate Node 에서 구동 됨을 확인 할 수 있다

reboot 명령을 내렸을 당시 마지막으로 Alert.log 에 찍힌 내용은 아래와 같다

시간상 14 시 41 분 5 초 에 마지막으로 로그가 기록 되었고

Wed Sep 21 14:41:05 2011

NOTE: ASMB terminating

Errors in file

/oracle/sbase/diag/rdbms/jupiter/JUPITER_1/trace/JUPITER_1_asmb_21142.trc:

ORA-15064: communication failure with ASM instance

ORA-03113: end-of-file on communication channel



다른 노드의 Alert.log 에서는 아래와 같이 14시 41 분 46 초에 2 번재 노드에서

instance 가 기동이 시작 됨을 알 수 있다.

이 부분의 경우에도 시스템 사양에 따라 달라지는 부분이며, Vendor Cluster 와

복구에 대한 시간은 얼추 비슷한 듯하다. 조금 이라도 빠르다라고 하면

RAC ONE NODE 에 해당 하는 모든 노드에서 ASM 스토리지나 ,Cluster file system

스토리지 영역이 Active 하게 mount 되어 있기 때문에 스토리지 절재 후 다시

Candidate Node 에서 mount 하는 Storage Failover 에 대한 시간은 절약 할 수는

있다.

9. Dynamic SID

위에서 1 번 노드에서는 JUPITER_1 , 2 번노드에서는 JUPITER_2 로

나타남을 확인 할 수 있었다. 하지만 이것이 항상 동일 하진 않다 라고 말하였다.

1 번 노드에서 JUPITER_1 의 SID 로 기동 되어 있는 상태에서 OS의 장애(reboot)

가 발생 되면 SID 에 대한 부분이 조금 달라진다.

아래와 같이 1 번 노드에서 JUPITER_1 SID 로 기동 중이다.

os 에서 reboot 명령으로 crash 형태를 만든다.

Wed Sep 21 14:41:46 2011

Starting ORACLE instance (normal)

LICENSE_MAX_SESSION = 0

LICENSE_SESSIONS_WARNING = 0

[root@jupiter1:/root]$ hostname

jupiter1

[root@jupiter1:/root]$ ps -ef | grep ora_smon | grep -v grep

oracle 13940 1 0 16:11:08 ? 0:03 ora_smon_JUPITER_1



2 번 서버에서 instance 가 기동 된 후 확인 해보면 아래와 같은 SID 로

기동 된다.

2 번 노드에서 JUPITER_2 가 아닌 JUPITER_1 로 기동 됨을 확인 할 수 있다.

위와 같이 Crash 나 reboot 상황에서 srvctl relocate 로 migrate 시 아래와 같이

1 번 노드에서 JUPITER_2 로 구동 됨을 확인 할 수 있다.

장애에 의해서 Candidate 노드로 구동 될 때에는 이전 Node 에서 사용중인

SID 를 그대로 사용하며, 정상적인 srvctl relocate 명령을 이용하여 migrate 를

하게 되면 SID 는 순차적으로 변경이 된다.

위와 같이 1 번 노드에서 JUPITER_2 를 2번 노드에서는 JUPITER_1 라는

SID 에서 노드별로 SID 를 맞추려면 Crash(reboot) 이 되거나, srvctl stop database

로 정상 종료 후 start 하게 되면 해당 노드에 맞는 SID로 기동 된다.

10. Converting a Database from Oracle RAC One Node to Oracle RAC

srvctl convert 커맨드를 이용하여 기존의 RAC ONE NODE 를 Online 상태에서

RAC 로 Convert 하는 기능도 제공 되며 반대로 RAC => RAC ONE NODE 로도

가능하다.


jupiter2

[root@jupiter2:/root]$ ps -ef | grep ora_ | grep -v grep

oracle 28283 1 0 10:05:47 ? 0:00 ora_lms0_JUPITER_1

oracle 28363 1 0 10:05:51 ? 0:00 ora_o000_JUPITER_1


jupiter1

[root@jupiter1:/root]$ ps -ef | grep ora_pmon | grep -v grep

oracle 1960 1 0 10:21:38 ? 0:00 ora_pmon_JUPITER_2



현재 인스턴스는 JUPITER_1 1 개만 존재 하는 상태 이며, node 1 에 구동 중 이다.

먼저 사용중인 JUPITER.RON.COM 서비스를 삭제를 해야 한다.

JUPITER.RON.COM 은 ora.JUPITER 라는 기본 Server pool 에 종속 되어 있다.

ora.JUPITER 라는 Server pool 은 RAC 변환 후에도 사용 하기 때문에 -f 옵션을 사용

하여 JUPITER.RON.COM 서비스를 삭제 한다.

$ srvctl remove service -d JUPITER -s JUPITER.RON.COM -f

srvctl convert 를 이용하여 기존 RAC ONE NODE 를 RAC 로 변환한다.

$ srvctl convert database -d JUPITER -c RAC

srvctl config 로 조회 해보면 아래와 같이 RAC 로 변경 된 것을 확인 할 수 있다.

이제 2 번째 노드를 추가 하여 Active-Active 상태로 변경 한다. 현재 까지는

RAC 이지만 인스턴스는 1 개 이다.

아래와 같이 srvctl add instance 를 이용한다.

$ srvctl add instance -d JUPITER -i JUPITER_2 -n jupiter2

[oracle@jupiter1:/oracle]$ srvctl config database -d JUPITER Database unique name: JUPITER Database name: JUPITER Oracle home: /oracle/product/112/db Oracle user: oracle Spfile: +DATA/JUPITER/spfileJUPITER.ora Domain: Start options: open Stop options: immediate Database role: PRIMARY Management policy: AUTOMATIC Server pools: JUPITER Database instances: JUPITER_1 Disk Groups: DATA Mount point paths: Services:

Type: RAC Database is administrator managed



추가 후 srvctl config database 로 조회 하면 아래와 같이 Instance 가 추가 된 것을

확인 할 수 있다.

ONE NODE RAC 에서 RAC 로 변경 시 Online 으로 모든 작업이 진행 된다.

그러므로 _n 형식의 SID는 변경 되지 않는다.

JUPITER_2 인스턴스를 구동한다.

$ srvctl start instance -d JUPITER -n jupiter2

jupiter2(node2) 에서 pmon 이 구동이 되는 것이 확인 가능하며

crsctl stat res -t 로 확인 해보면 2 개의 instance 가 OPEN 상태 임을 확인 가능하다.

[oracle@jupiter1:/oracle]$ srvctl config database -d JUPITER Database unique name: JUPITER Database name: JUPITER Oracle home: /oracle/product/112/db Oracle user: oracle Spfile: +DATA/JUPITER/spfileJUPITER.ora Domain: Start options: open Stop options: immediate Database role: PRIMARY Management policy: AUTOMATIC Server pools: JUPITER

Database instances: JUPITER_1,JUPITER_2 Disk Groups: DATA Mount point paths: Services: Type: RAC Database is administrator managed


jupiter2

[root@jupiter2:/root]$ ps -ef | grep ora_pmon | grep -v grep

oracle 8915 1 0 03:59:37 ? 0:00 ora_pmon_JUPITER_2

[root@jupiter2:/root]$ crsctl stat res -t ora.jupiter.db 1 ONLINE ONLINE jupiter1 Open

2 ONLINE ONLINE jupiter2 Open



srvctl status database 로 조회 하면 이전 과 다르게 Online relocation: INACTIVE

라는 문구는 존재 하지 않는다.

11. Converting a Database from Oracle RAC to Oracle RAC One Node

위에서 변경 한 RAC 를 다시 RAC ONE NODE 로 변경 하겠다.

먼저 할 작업은 instance 를 단일 instance 로 변경 하는 것이다.

3NODE 라면 2NODE 를 삭제 하고 1 개의 NODE 를 남겨 놔야 하는 것이다.

instance 의 구동을 정지 하고 삭제를 진행한다.

instance 정지

$ srvctl stop instance -d JUPITER -i JUPITER_2

instance 삭제

$ srvctl remove instance -d JUPITER -i JUPITER_2

Remove instance from the database JUPITER? (y/[n]) y

RAC ONE NODE 생성시 dbca 작업 중 service 를 JUPITER.RON.COM 로 등록해서

생성 한 내역이 존재 한다. 동일하게 RAC ONE NODE 를 위한 service 부터 생성

해줘야 한다.

srvctl add service -d JUPITER -s JUPITER.RON.COM -r "JUPITER_1"

서비스 네임 : JUPITER.RON.COm

종속 instance : JUPITER_1

서비스를 추가 하게 되면 자동으로 server pool 이 생성된다.

crsctl status serverpool 로 확인 하면 아래와 같이 새로운 Server pool 이 생성

되었으며, 해당 SERVER(node) 가 등록 되었음을 확인 가능하다.

[oracle@jupiter1:/oracle]$ srvctl status database -d JUPITER





다시 srvctl convert 를 이용해서 RAC ONE NODE 로 변경 한다.

-i 옵션은 Instance name prefix 으로 써 JUPITER 로 기술 하면 RAC ONE NODE

로 전환 되면서 SID 는 자동으로 _1 , _2 …._n 형 태로 등록 됨으로 따로 _(언더바)

는 붙이지 않는다.

$ srvctl convert database -d JUPITER -c RACONENODE -w 1 -i JUPITER

srvctl config database 로 조회하면 다시 RAC ONE NODE 로 변경 되었다.

[oracle@jupiter1:/oracle]$ crsctl status serverpool

NAME=Free

ACTIVE_SERVERS=jupiter2

NAME=Generic


NAME=ora.JUPITER


NAME=ora.JUPITER_JUPITER.RON.COM




$ srvctl config database -d JUPITER

다시 srvctl status database 로 조회 하면 Online relocation: INACTIVE 상태를 확인

할 수 있다

[oracle@jupiter1:/oracle]$ srvctl config database -d JUPITER

Database unique name: JUPITER

Database name: JUPITER

Oracle home: /oracle/product/112/db

Oracle user: oracle

Spfile: +DATA/JUPITER/spfileJUPITER.ora

Domain:

Start options: open

Stop options: immediate

Database role: PRIMARY

Management policy: AUTOMATIC

Server pools: JUPITER

Database instances:

Disk Groups: DATA

Mount point paths:

Services: JUPITER.RON.COM

Type: RACOneNode

Online relocation timeout: 1

Instance name prefix: JUPITER

Candidate servers: jupiter1

Database is administrator managed

[oracle@jupiter1:/oracle]$ srvctl status database -d JUPITER


Online relocation: INACTIVE



12. 결론

RAC ONE NODE 는 분명히 Vendor Cluster 와는 조금은 다른 형태의 HA 동작

방식을 제공 하며, Grid 에 의해 Oracle 을 HA 방식으로 이용하려 할 때 좀더

빠르게 Failover 를 지원 하게 됨을 확인 할 수 있었다.

relocate 시 RAC 와 동일하게 select 작업 까지 TAF가 지원 됨으로 계획된

Server 작업 및 Oracle S/W Patch 시 Rolling Patch 시 Online 성이

Vendor Cluster 보다는 좀더 좋다 라고 평가 할 수 있겠다.

RAC ONE NODE (Oracle Database HA Solution)

Documents

Transcript of RAC ONE NODE (Oracle Database HA Solution)