PMD, 정책관리형 데이터베이스, 관리자관리형 데이터베이스, 서버풀에 대한 개념을 설명하기전에
사전에 미리 인지하고 있어야될 개념부터 1)~3) 항목에 설명해 놓겠습니다..~ 4) 항목부터
정책관리형 데이터베이스, 관리자관리형 데이터베이스, 서버풀에 대한 개념을 정리해 놓았습니다.
1) OCR(Oracle Cluster Registry)
CRS(Cluster Ready Service)의 핵심 구성요소이며 클러스터의 구성resource들의 정보를 저장관리하는 디스크 공간.
# 저장관리하는 구성resource 정보
- Cluster를 구성하는 서버노드 list
- Cluster Database Instance(SID)와 서버 노드간 node 매핑정보
- CRS Application resource profile(service, VIP)등
- Size : 100MB 이상
- p13390677_112040_Linux-x86-64_3of7.zip 파일 압축을 풀어 grid infra structure 설치시
ACFS로 ASM 디스크 공간을 구성하여 설치를 진행합니다.
2) Service resource
Oracle DB에 접속하려할때, 연결 String이나 TNS에 아래와 같이 "service" 항목을 본적이 있을것입니다.
--------------------------
service=instance_name
--------------------------
사실 이 "service"라는 것은 접속할 Database이름을 지정하는것이 아니라
세션들이 접속할 수 있는 논리적으로 묶인 집합을 지정하는것입니다.
이게 뭔말이냐...
"service" 라는 것은 세션들을 묶어 놓는 Database의 resource입니다.
Database가 Stand alone으로 생성되었을때, 기본적으로 "service"라는 resource가 instance 이름으로 생성됩니다.
사용자들을 DB에 세션을 맺을 때, instance 이름으로 생성된 "service" 집합에 귀속되며 Database에 접속 되는것입니다.
RAC 환경에서는 이러한 "service"를 여러개 만들수 있고,
사용자가 만들어진 여러개의 "service"중 특정 "service" 이름을 connect string이나, TNS에 적어주면
Database에서 특정 "service" 집합에 속한상태로 DB접속이 가능합니다.
이러한 "service"를 어플리케이션에서 connect string에 적절히 이용하면,
어플리케이션 기능별로 세션들을 묶어 DB에 접속시켜 활용할 수 있습니다.
또 RAC에서 "service" 단위로 접속되는 instance를 지정하거나, "service"라는 집합 단위로 접속되는
instance위치를 재배치 할 수도 있습니다.
예시로 "srvctl relocate A ..." 명령을 사용한다면 1번 인스턴스 노드에 연결되어있는 "A service" 세션집합을
2번 인스턴스로 옮겨서 접속시킬수가 있습니다.
3) Database resource & Non Database resource
RAC에서는 "crsctl add resource" 명령을 사용해 오라클이 아닌 특정 Thrd party Application을
오라클 클러스터에 resource으로 등록할 수 있고, resource 등록시 resource속성에, 쉘스크립트나 배치스크립트, 또는
Thrd party Application 명령을 등록해, 오라클 클러스터가 Thrd party Application을
가동/중지시키거나, 상태확인, 또는 여려 Thrd party Application의 특정기능을 수행할수 있습니다.
이러한 오라클 클러스터에 resource에 등록된 특정 Thrd party Application는 Non Database resource라 합니다.
그리고 Database resource는 아래항목들을 뜻합니다.
--------------------------------------------------
- database
- listener
- scan
- scan_listener
- vip
- ons
- gns
- ocj4
- network
- asm
--------------------------------------------------
4) 서버풀, 관리자 관리형 DB, 정책 관리형 DB
[1] Grid에 대한 개요
Grid Computing은 10g 이후로 존재 해 온 Oracle Database의 인프라 구성방식에 관련된 개념입니다.
Grid Computing의 기본 의미는 resource들(고가용성을 위해 연결된 resource들)을 여러 서버들에 나누어서 공유해
'어디서나 언제 어디서나' resource들을 사용할 수 있게하는 것입니다.
즉, 특정 서버자체에 고정되어 붙어있거나 특정 서버에서만 액세스 할 수있는 resource에 대한 제한이 없이
여러 서버에서 인프라 resource를 나누어 사용할수 있게 하는것입니다.
[2] 서버풀
11G에서는 서버 풀이라는 개념이 도입되면서 11.2 RAC에서는 Grid Computing 구현해 여러 인프라 resource들을
여러서버에서 나누어 공유해 사용할 수 있습니다.
서버 풀은 Database 클러스터에 구성원인 노드(서버)들을 논리적으로 나누고 그룹지어 지정한 논리적 집합으로써
이러한 논리적 구성집합에서는 다양한 Database 서비스(workload)에서 같은 resource(디스크resource)를 사용할 수 있습니다.
<1> 서버풀의 구성
- 서버풀은 DBMS가 아닌 클러스터에서 관리합니다.
클러스터를 운영하는데 필요한 Database resource(VIP, SCAN IP, SCAN LISTENER ,Database 등등)들은
여러 서버 풀에서, 서버풀 단위로 실행될수 있습니다.
- 각 서버(노드)에서는 때에 따라 여러 다른 DB들의 인스턴스를 기동할수 있고,
각 서버노드에 기본 인스턴스, 실행 가능 인스턴스로 기동 가능한 Database를 설정할 수 있습니다.
위 예시에서는 4개의 서버(노드)와 FRONT OFFICE, BACK OFFICE라는 서버 풀이 있습니다.
왼쪽 상자로 묶인 두 개의 인스턴스가있는 박스는 BACK OFFICE 서버 풀입니다.
그리고 오른쪽 상자로 묶인 또 다른 Database가 실행중인 FRONT OFFICE 서버풀이 있습니다.
각 서버 풀마다 두 개의 인스턴스가 실행 중입니다.
BACK OFFICE 서버 풀에 포함된 서버는, BACK OFFICE 서버 풀에 설정된 Database 인스턴스(SID)만 실행이 가능합니다.
( "srvctl add database" 명령으로 Database의 Instance(SID)와 특정 서버풀을 연결시킬수 있습니다. )
클러스터 resource는 클러스터에 정의된 서버 풀과 상관없이 클러스터의 모든 노드에서 실행될 수 있습니다.
이 클러스터 resource중 하나인 SHARED STORAGE에는 각 서버풀에서 기동중인 인스턴스 (TEST_DB1,TEST_DB2,PROD_DB1,PROD_DB2)가
사용할수 있는 Database(TEST_DB,PROD_DB)가 저장되어 있습니다.
<2> 서버풀의 속성
- 서버풀은 3개의 속성 (최소값, 최대값, 중요도)과 서버노드 목록으로 구성되어 있습니다.
- 서버풀의 속성
>> MIN - 서버풀에 포함될수 있는 최소 서버 수 (기본값 0)
>> MAX.. - 서버풀에 포함될수 있는 최대 서버 수 (기본값 0 또는 -1)
>> IMPORTANCE. - 서버풀의 중요도, 0 ~ 1000 까지 지정가능.
# 참고
MIN_SIZE 속성은 서버풀에서 사용하는 서버(노드)의 갯수를 지정하는 것과 같다 생각하면 됩니다.
서버풀의 값이 MIN_SIZE=2 일때 Database 인스턴스는 해당 서버 풀안에 두개의 서버에서 실행될 수 있는것입니다.
- 클러스터를 구성하는 서버노드를 서버 풀이라는것으로 논리적으로 묶어 분할하여 DBMS 클러스터 서비스의 인프라를 유동적으로 구성할 수 있습니다.
여기서 유동적이란 의미는 서버풀을 구성하는 서버노드가 서버풀에 고정되어 소속되어 있지 않고, 서비스의 장애 발생이나, 여러 상황에 따라 서버노드가
특정 서버풀에 포함되었다가, 해제 될수 있고, 또 다른 서버풀에 이동되어 포함될 수 있음을 의미 합니다.
<3> 서버풀의 서버 배치 규칙
일반적인 서버풀은 아래와 같이 3타입이 있습니다.
-1순위 Generic server pool
-2순위 User assigned server pool
-3순위 Free
오라클 클러스터를 기동하면 서버풀에 할당 될수 있는 서버들이 정해진 순위와 규칙에 따라 자동으로 서버풀에 배치가 됩니다.
이때 위의 타입순, Generic server pool부터 Free pool순으로 서버들이 채워져 할당됩니다.
각 서버노드들은 각 서버풀의 속성인 최소값(MIN)에 도달 할 때까지 서버풀에 채워지게 되는데.
여러개의 서버풀이 있을때 여러 서버풀의 속성인 중요도(IMP)가 높은 순위대로 모든 서버 풀을 채웁니다.
그 다음 각 서버노드들은 각 서버풀의 속성인 최대값(MAX)을 충족 할 때까지 채워지며,
마찬가지로 여러개의 서버풀이 있을 경우 서버풀의 속성인 중요도가 높은 서버풀 순위대로 모든 서버 풀을 채웁니다.
각 서버풀의 최대값 까지 다채우고 더이상 채워질 서버풀이 없다면 남음 서버노드들은 Free 풀로 이동합니다.
ex) 시나리오
- 위와 같이 3개의 User assigned server pool (BACK OFFICE, FRONT OFFICE, LOB)과, Free 서버풀이 1개 있습니다.
- 클러스터가 기동이 되면 서버노들들은 User assigned server pool 타입의 서버풀 (BACK OFFICE, FRONT OFFICE, LOB)에 먼저 할당이 됩니다.
- User assigned server pool (BACK OFFICE, FRONT OFFICE, LOB) 중 서버들이 배치되는 순서는 아래와 같습니다.
- 중요도가 가장 높은 4를 가진 FRONT OFFICE 서버풀의 Min값 2에 만족하기 위해 FRONT OFFICE 서버풀에 서버 2개를 할당합니다.
- 중요도가 그 다음 높은 3을 가진 BACK OFFICE 서버풀의 Min값 1에 만족하기 위해 BACK OFFICE 서버풀에 서버 1개를 할당합니다.
- 중요도가 제일 낮은 2를 가진 LOB 서버풀의 Min값 0에 만족하기 위해 LOB에는 서버를 할당하지 않습니다.
- 중요도가 가장 높은 4를 가진 FRONT OFFICE 서버풀의 Max값 3에 만족하기 위해 FRONT OFFICE 서버풀에 추가로 서버 1개를 할당합니다.
- 중요도가 그 다음 높은 3을 가진 BACK OFFICE 서버풀의 Max값 3에 만족하기 위해 BACK OFFICE 서버풀에 서버 3개를 할당합니다.
- 중요도가 제일 낮은 2를 가진 LOB 서버풀의 Max값 2에 만족하기 위해 LOB 서버풀에 서버 2개를 할당합니다.
- 그리고 마지막으로 나머지 서버는 FREE POOL에 있게 됩니다.
<4> 서버장애시 서버노드의 서버풀 이동
서버풀 안에 배치되어 있는 Database 인스턴스가 장애발생시, 클러스터 서비스는 클러스터내에 특정 서버를 선택해,
장애가 발생한 서버의 서버풀로 배치시키고 서비스의 가용성을 유지시킵니다.
이때 장애가 난 서버를 대신해 새롭게 배치될 서버를 차출할 서버풀을 선택하는 기준은 위에 나와있는 3가지 타입순으로
(Generic server pool부터 Free pool순) 서버풀을 선택해 해당 서버풀에서 서버를 차출, 장애가 난 서버풀로 이동/대체 시킵니다.
같은 타입의 서버풀이 여러개 있다면 같은 타입의 서버 풀의 important값을 비교해 낮은 important 값의 서버풀에서
서버를 차출해 장애가난 서버풀로 서버를 이동시킵니다. 예를 들어 Generic server pool 타입의 서버풀이 없고,
User assigned server pool 타입의 서버풀이 2개가 있을 때, 각 User assigned server pool 타입 서버풀의 속성인
important값이 낮은 곳부터 서버가 차출되 장애가난 서버풀로 배치됩니다.
예시1)
위 시나리오를 그대로 이어서 가정할 때 BACK OFFICE 서버풀에서 서버가 다운되었을 경우
FREE POOL 하나 남아있던 서버가 "FREE"풀에서 "BACK OFFICE"로 이동하고
이동한 해당 서버노드 에서 기존 장애가 났던 인스턴스가 시작됩니다.
예시2)
증요도가 가장 높은 서버 풀에서, 서버노드에 장애가 발생해 구성노드 갯수가 최소값 이하로 떨어지면
중요도가 낮은 서버 풀에서의 서버노드가 중요도가 높은 서버 풀로 이동됩니다.
- important 값이 낮은 서버 풀에서 이동 시킬 서버를 선택해 장애가 난 서버풀로 이동시킵니다.
- 동일한 값의 important 값이 있는 여러개의 서버풀에서 이동 시킬서버를 선택하려 할때는,
서버풀의 최소값보다 많은 서버가있는 서버 풀에서 서버를 선택해 장애가 난 서버풀로 이동시킵니다.
<5> command
- crsctl 서버풀 확인 명령
[grid@host01 ~]$ crsctl status serverpool -p
NAME=Free
IMPORTANCE=0
MIN_SIZE=0
MAX_SIZE=-1
SERVER_NAMES=
PARENT_POOLS=
EXCLUSIVE_POOLS=
ACL=owner:grid:rwx,pgrp:oinstall:rwx,other::r-x
NAME=Generic
IMPORTANCE=0
MIN_SIZE=0
MAX_SIZE=-1
SERVER_NAMES=host01 host02 host03
PARENT_POOLS=
EXCLUSIVE_POOLS=
ACL=owner:grid:r-x,pgrp:oinstall:r-x,other::r-x
NAME=ora.orcladm
IMPORTANCE=1
MIN_SIZE=0
MAX_SIZE=-1
SERVER_NAMES=host01 host02 host03
PARENT_POOLS=Generic
EXCLUSIVE_POOLS=
ACL=owner:oracle:rwx,pgrp:oinstall:rwx,other::r--
NAME=sp1
IMPORTANCE=2
MIN_SIZE=1
MAX_SIZE=2
SERVER_NAMES=
PARENT_POOLS=
EXCLUSIVE_POOLS=
ACL=owner:grid:rwx,pgrp:oinstall:rwx,other::r
- srvctl 서버풀 확인 명령
[grid@host01 bin]$ srvctl config serverpool -g Free
Server pool name: Free
Importance: 0, Min: 0, Max: -1
Candidate server names:
[grid@host01 bin]$ srvctl config serverpool -g Generic
PRKO-3160 : Server pool Generic is internally managed as part of administrator-
managed database configuration and therefore cannot be queried directly via srvpool
- 서버풀을 추가하는 명령
[grid@host01 Disk1]$ crsctl add serverpool sp_child1 -attr "PARENT_POOLS=sp1,MIN_SIZE=1, MAX_SIZE=1, IMPORTANCE=2"
- 서버 풀 sp1의 모든 노드에서 "all"이라는 서비스를 사용 할수 있게끔 생성하는 명령
srvctl add service –d orcladm –s all –g sp1 –c uniform ...
- 서버 풀 sp1의 하나의 노드에서 "one"이라는 서비스를 사용 할수 있게끔 생성하는 명령
srvctl add service –d orcladm –s all –g sp1 –c singleton ...
- "service"resource 관련된 uniform, singleton 옵션
Oracle Database에 사용되는 "service"(TNS를 사용해 DB에 붙는 세션들을 서비스라는 단위로 묶어 생성한 논리적 그룹)는
클러스터 resource(ex : SHARED STORAGE)가 여러 서버풀에서 사용될수 있는것과 달리 "service"를 만들 때 서버 풀에서
생성하고 생성된 서버풀에서만 실행할 수 있습니다. srvctl add service 명령에서 사용할수 있는 옵션 "uniform", "singleton"이 있고,
이 두 옵션은 "service" resource의 속성을 나타내며, 정책 기반 Database의 경우에만 해당 옵션들이 사용 가능합니다.
--------------------------------------------------------
- uniform : 서버풀 안의 모든 인스턴스에서 실행
- singleton : 서버풀 안의 한 인스턴스에서만 실행
--------------------------------------------------------
singleton 서비스에서 해당 인스턴스가 장애가 나면 해당 서비스를 서버 풀의 다른 인스턴스로 FAILOVER 합니다.
<6> "crsctl add serverpool" VS "srvctl add serverpool"
- "srvctl"명령은 접두사 "ora.*" 를 가진 Database resource를 관리하는 데 사용되고
"crsctl"은 접두사 "ora.*" 를 가진 resource을 조회 또는 시작/중지하는 데 사용되지만
수정하거나 편집하는 데 지원되지 않습니다.
- 접두사 "ora.*" (Database resource)가 있는 resource에서
"crs_*" 또는 "crsctl" 명령을 사용하는 것은 지원되지 않습니다.
- 따라서 "srvctl"을 사용하여 Database resource를 생성 한 경우
이 Database resource는 "srvctl"만으로 관리해야합니다.
- "crsctl"을 사용하여 Non Database resource를 작성했을 때는
해당 Non Database resource를 "crsctl" 명령을 사용하여 관리해야합니다.
- crsctl을 사용해 serverpool을 추가하면 해당 서버풀에는
응용 프로그램 등과 같은 Non Database resource만 포함될수 있습니다.
- srvctl을 사용해 serverpool을 추가하면 해당 서버풀에서는
Database resource만 포함될수 있습니다.
- crsctl을 사용해 serverpool을 추가했을 때는
Non Database resource가 활성화 될수 있는 서버풀을 추가하는 것입니다.
즉, Database resource ( database, listener, scan, vip ... ) 는
crsctl을 사용해 serverpool을 추가한 서버풀에 연결/할당 할수 없고,
srvctl을 사용해 serverpool을 추가한 서버풀에만 할당 할 수 있습니다.
- Non Database resource를 위한 서버풀 생성 명령
[grid@host01 ~]$ crsctl add serverpool sp1 -attr "MIN_SIZE=1, MAX_SIZE=1, IMPORTANCE=1"
[grid@host01 ~]$ crsctl add serverpool sp2 -attr "MIN_SIZE=1, MAX_SIZE=1, IMPORTANCE=2"
- Database resource를 위한 서버풀 생성 명령
[grid@host01 ~]$ srvctl add srvpool -g sp1 -l 1 -u 2 -i 999 -n host02
[grid@host01 ~]$ srvctl add srvpool -g sp2 -l 1 -u 2 -i 999 -n host03
[grid@host01 ~]$ crsctl status server -f
NAME=host01
STATE=ONLINE
ACTIVE_POOLS=Free
STATE_DETAILS=
NAME=host02
STATE=ONLINE
ACTIVE_POOLS=sp2
STATE_DETAILS=
NAME=host03
STATE=ONLINE
ACTIVE_POOLS=sp1
STATE_DETAILS=
Host01 is assigned to free pool and rest of the two hosts.
<7> Database 생성시 DBCA 명령에서 Server pool
11G release 2 RAC 설치에서 DBCA를 실행할때 세 번째 화면에는 아래 옵션 선택에 대한 화면이 있고.
서버풀을 활용할수 있는 정책관리형 Database형태로 Database를 생성할 수 있는 옵션이 있습니다.
* 구성 유형
- 관리자 관리형
- 정책 관리형
[3] 관리자형 관리 Database
전통적으로 Oracle은 DBA가 RAC 환경의 어떤 서버에서 어떤 인스턴스를 실행할지 정의했습니다.
이들은 node1이 SID:RAC1을 실행하고 node2가 SID:RAC2 등을 실행 함을 고정해 정의합니다.
지정된 인스턴스는 특정 노드에 연결/고정됩니다. 인스턴스가 DBA에 의해 관리되고 DBA가
인스턴스를 서버에 구체적으로 지정했기 때문에 이를 관리자 관리 Database라고합니다.
ex) RAC라는 Database는 RAC1, RAC2, RAC3, RAC4 인스턴스를 갖고 각 서버노드에 지정된 인스턴스를 띄워 Database를 운영할수 있다.
각 서버
Server1에서는 ORACLE_SID를 RAC1로 지정해 RAC1 인스턴스를 고정시켜 Startup 하고 띄우고
Server2에서는 ORACLE_SID를 RAC2로 지정해 RAC2 인스턴스를 고정시켜 Startup 하고 띄우고
Server3에서는 ORACLE_SID를 RAC3로 지정해 RAC3 인스턴스를 고정시켜 Startup 하고 띄우고
Server4에서는 ORACLE_SID를 RAC4로 지정해 RAC4 인스턴스를 고정시켜 Startup 하고 띄운다.
[4] 정책 관리 Database
정책 관리 Database는 DBA가 Database 특정 서버풀에서 실행하려는 인스턴스 수를 지정할수 있는 방식입니다.
Database는 특정 서버(노드)가 아닌 서버 풀에 연결/할당됩니다.
( "srvctl add database" 명령으로 Database의 Instance(SID)와 특정 서버풀을 연결시킬수 있습니다. )
<1> 서버풀의 구성과정과 배치 예시
- 클러스터 설치
>> 각서버에 Oracle Cluster service를 설치해 서버풀에 참여할수 있는 서버들을 구성합니다.
- 서버풀 생성
>> Oracle Cluster service에서 명령을 사용해 서버풀을 구성하고, 서버풀의 최대값, 최소값, 중요도 속성을 지정합니다.
서버풀을 생성할 때는 명시적으로, 서버풀에 포함할 Server node를 지정하여 서버풀을 구성하지 않습니다.
- 클러스터 기동 및, 노드서버 자동 배치
>> 클러스터를 기동하면, 서버풀에 참여할수 있는 서버들이 여러 서버풀 타입, 최대값, 최소값, 중요도 속성을 참고해
규정된 순위에 맞는 서버풀에 배치됩니다.
- Database 지정
>> 이와 별개로 "srvctl add database" 명령으로 Database의 Instance(SID)와 특정 서버풀을 연결시켜
Database 인스턴스가 가동될 서버풀을 지정해줍니다.
위 그림처럼 클러스터 resource(SHARED STORAGE)에는 "RAC" 라는 이름의 Database와 "TEST"라는 이름의 Database가 저장되어 있고,
각 Database는 "srvctl add database" 명령으로 각 서버풀에 지정되 해당 서버풀에서 DB인스턴스가 기동됩니다.
RAC Database. : BACK OFFICE SERVER POOL
TEST Database : FRONT OFFICE SERVER POOL
<2> 정책 관리 Database의 의미
정책 관리 Database의 궁극적목표는 특정 인스턴스나 서비스를 서버에 대해 하드코딩(명시적 지정)을 제거해
서비스가 물리적 resource들을 유동적으로 공유해 사용하게 하는 것입니다.
서버 풀에 할당 된 서버는 동적으로 자신이 속한 서버풀의 위치가 변경 될 수 있으므로
Oracle은 Cluster에서 사용 가능한 서버 수들을 동적으로 배치해 서비스의 가용성을 동적으로 제공 할 수 있습니다.
위 그림에서는 왼쪽부터 오른쪽으로 인스턴스 번호가 순서대로 배치된 모습이 보이지만,
Database의 모든 인스턴스(RAC1, RAC2, TEST1, TEST2)는 지정된 서버풀 내의 모든 노드에서 실행될 수 있습니다.
즉 인스턴스 번호와 서버노드 사이에는 고정 된 맵핑이 없습니다.
ex) 시나리오
위 그림에서 클러스터에 총 8개의 서버노드가 구성되어 있고, 3개의 RAC Database가 있는 경우
각 Database는 서버풀과 매칭되어 설정되고, 서버풀은 최소 및 최대 서버 수, 중요도로 정의됩니다.
즉 3개의 DB 서비스는 가용할수 있는 최소 및 최대 서버 수, 중요도가 지정되있다 봐도 무방합니다.
--------------------------------------------------
SERVER POOL1 : 중요도 10, 최소 4, 최대 6
SERVER POOL2 : 중요도 7, 최소 2, 최대 3
SERVER POOL3 : 중요도 5, 최소 2, 최대 3
--------------------------------------------------
DB1 <=> SERVER POOL1
DB2 <=> SERVER POOL2
DB3 <=> SERVER POOL3
--------------------------------------------------
DB1 <=> SERVER POOL1 : 중요도 10, 최소 4, 최대 6
DB2 <=> SERVER POOL2 : 중요도 7, 최소 2, 최대 3
DB3 <=> SERVER POOL3 : 중요도 5, 최소 2, 최대 3
--------------------------------------------------
DB1 : 중요도 10, 최소 4, 최대 6
DB2 : 중요도 7, 최소 2, 최대 3
DB3 : 중요도 5, 최소 2, 최대 3
--------------------------------------------------
클러스터 서비스 기동시 8개의 서버노드는 노드 번호 순서대로
서버풀 타입과, 최소, 최대, 중요도에 따라 아래와 같이 배치가 될것입니다.
DB1에 할당 된 노드 : 1, 2, 3, 4
DB2에 할당 된 노드 : 5, 6
DB3에 할당 된 노드 : 7, 8
어떤 이유로 장애가 발생해 DB1의 서버노드 3이 불능상태일 경우,
DB1은 중요도가 10으로써 가장 높고 최소 요구 사항이 4개이므로
클러스터 서비스가 DB3에서 노드7 또는 노드8을 DB1에 할당합니다.
DB2에서 이동시킬 서버노드를 선택하지 않은 이유는
DB2의 중요도가 DB3보다 더 높기 때문입니다.
서버노드3이 고쳐져 다시 사용 가능한 경우
DB3의 최소값을 맞쳐주기위해 노드3이 DB3에 즉시 할당됩니다.
9번째 노드가 새롭게 클러스터에 추가 된 경우,
중요도 및 DB1이 아직 최대 서버 수에 도달하지 않았기 때문에 DB1에 할당됩니다.
<3> 관리자 관리형 Database를 정책관리형으로 바꾸기
{1} DB type확인 : 맨 마지막 줄 "Database is administrator managed" => 관리자 관리형 DB임을 확인
[grid@host01 Disk1]$ srvctl config database -d orcladm
Database unique name: orcladm
Database name: orcladm
Oracle home: /u01/app/oracle/product/11.2.0/dbhome_1
Oracle user: oracle
Spfile: +FRA/orcladm/spfileorcladm.ora
Domain:
Start options: open
Stop options: immediate
Database role: PRIMARY
Management policy: AUTOMATIC
Server pools: orcladm
Database instances: orcladm1,orcladm2
Disk Groups: FRA
Services:
Database is administrator managed
{2} DB 인스턴스 중지 후 정책 관리형으로 DB유형 변경
[grid@host01 Disk1]$ srvctl stop database -d orcladm
[grid@host01 Disk1]$ srvctl modify database -d orcladm -g sp1
{3} DB type확인 : 맨 마지막 줄 "Database is policy managed" => 정책 관리형 DB임을 확인
[grid@host01 Disk1]$ srvctl config database -d orcladm
Database unique name: orcladm
Database name: orcladm
Oracle home: /u01/app/oracle/product/11.2.0/dbhome_1
Oracle user: oracle
Spfile: +FRA/orcladm/spfileorcladm.ora
Domain:
Start options: open
Stop options: immediate
Database role: PRIMARY
Management policy: AUTOMATIC
Server pools: sp1
Database instances:
Disk Groups: FRA
Services:
Database is policy managed
참고 링크1 :
http://db.geeksinsight.com/2013/01/13/11gr2-rac-server-pools-what-they-are
참고 링크2 :
http://www.ludovicocaldara.net/dba/oracle-rac-and-policy-managed-databases
참고 링크3 :
'Oracle > Theory' 카테고리의 다른 글
| "Begin Backup" 명령을 사용한 백업복원에서 Archive 파일이 필요한 이유. (1) | 2020.06.30 |
|---|
댓글