Policy Managed Database

02.
Mai
2016
Veröffentlicht von: Kurt Sauer

Der vorliegende Monatstipp hat das Ziel, die Vorteile einer "Policy Managed Database" und die Unterschiede zu der herkömmlichen Option in einer RAC Umgebung näher darzustellen.

Bereits mit Version Oracle 11gR2 war es möglich, eine Datenbank im Real Application Clusters-Umfeld (RAC) als sogenannte „Policy Managed Database“ anzulegen. Mit Einführung der Version Oracle 12c ist diese Option der Default bei der Einrichtung einer Oracle RAC-Datenbank.

Der vorliegende Monatstipp hat das Ziel, die Vorteile einer „Policy Managed Database“ und die Unterschiede zu der herkömmlichen Option näher darzustellen.

Die „Policy Managed Database“ setzt auf Funktionen der Oracle Clusterware auf, die zwischen Administrator- und Policy Based Managed Cluster-Ressourcen unterscheidet.

Bei der Administrator basierenden Methode bestimmt der Administrator oder DBA, auf welchem Cluster-Knoten eine Ressource gestartet werden soll.

Bei der Policy basierenden Methode werden innerhalb der Cluster-Umgebung sogenannte Server-Pools definiert, die der Aufnahme von Cluster-Ressourcen (z. B. Datenbank-Instanzen) dienen. Die Clusterware entscheidet anhand von zu definierenden Policies, wo welche Ressource gestartet werden kann.

Mit einem Serverpool kann folgendes erreicht werden:

  • Zuordnung von Datenbank-Instanzen oder applikationspezifischer Cluster-Ressourcen zu einer Gruppe von Servern
  • Dynamische Vergabe von Prioritäten entsprechend der aktuellen Workload
  • Trennung der Ressourcen durch Definition von Server-Pools

Vorteile:

  • Ermöglicht die Zuweisung von dynamischen Kapazitäten je nach Bedarf auf die verfügbaren Server-Kapazitäten
  • Aktiviert die Zuweisung von Ressourcen nach deren Priorität -  Anwendungen erhalten dadurch die erforderliche Mindestressourcen
  • Automatische Anlage Instanz-spezifischer Datenbank-Dateien bei Hinzunahme weiterer Server innerhalb des Server-Pools

Folgende Beispiele sollen das näher erläutern:

Ausgangspunkt ist ein Oracle 12c RAC mit zwei Knoten, server-a und server-b.

Anlage Serverpool

Beide sollen dem Serverpool rac1db_serverpool zugeordnet werden:

srvctl add srvpool -serverpool rac1db_serverpool -min 2 -max 2 -servers “server-a,server-b”

Wenn in den Serverpool gleichartige Server (z. B. mit einer bestimmten Anzahl an CPUs) aufgenommen werden sollen, lässt sich dies folgendermaßen erreichen:

crsctl add category server_fast  -attr "EXPRESSION='(CPU_COUNT > 8)'"
srvctl add serverpool -serverpool rac1db_serverpool  -min 2  -max 2 -category server_fast

Ein Blick in die Server-Konfiguration zeigt die Attribute des Knotens server-a:

crsctl status server server-a -p
NAME=server-a
MEMORY_SIZE=39540
CPU_COUNT=12
CPU_CLOCK_RATE=1995
CPU_HYPERTHREADING=1
CPU_EQUIVALENCY=1000
DEPLOYMENT=other
CONFIGURED_CSS_ROLE=hub
RESOURCE_USE_ENABLED=1
SERVER_LABEL=
PHYSICAL_HOSTNAME=

Anschließend wird die Relation zwischen der Datenbank rac1db und dem erstellten Serverpool hergestellt:

srvctl modify database -d rac1db -serverpool rac1db_serverpool

Die Datenbank startet mit jeweils einer Instanz auf server-a und server-b:

srvctl status database -db rac1db
Instance rac1db_2 is running on node server-a
Instance rac1db_1 is running on node server-b

Anmerkung:

Der Underscore-Suffix im Instanznamen verdeutlicht die ‚Policy Managed Database‘.Im Gegensatz zur Administrator Managed Database gibt es keine 1:1 Zuordnung von Instanz zum Server, d. h. Instanz 1 muss nicht zwangsläufig auf Knoten 1 laufen

Der bestehende Cluster soll um einen weiteren Knoten (server-c) erweitert werden, um zusätzliche Ressourcen für die Datenbank bereitzustellen. Der Knoten ist bereits mit der Clusterware und der Datenbank-Software durch das AddNode Perl-Skript angelegt.

Erweiterung Serverpool

Nun soll der Serverpool rac1db_serverpool um diesen Knoten erweitert werden (selbstverständlich nur bei einem CPU Count von mehr als 8):

srvctl add srvpool -serverpool rac1db_serverpool -min 3 -max 3

Die Zuweisung eines Servers in einen Serverpool wird im Alert Log der Clusterware protokolliert:

2016-03-07 08:14:44.580 [CRSD(12339)]CRS-2772: Server 'server-c' wurde Pool 'Free' zugewiesen.
2016-03-07 11:52:59.693 [CRSD(12339)]CRS-2773: Server 'server-c' wurde aus Pool 'Free' entfernt.
2016-03-07 11:52:59.694 [CRSD(12339)]CRS-2772: Server 'server-c' wurde Pool 'ora.rac1db_serverpool' zugewiesen.

Mit srvctl lässt sich das Ergebnis überprüfen:

srvctl status database -db rac1db
Instance rac1db_2 is running on node server-a
Instance rac1db_1 is running on node server-b
Instance rac1db_3 is running on node server-c

Anmerkung:

Der Server muss als Clusterknoten konfiguriert sein, allerdings sind keine Instanz-spezifischen Konfigurationen (z. B. Anlage Redolog-Gruppen, Undo-Tablespace, etc.) erforderlich. In seltenen Fällen muss die Datenbank-Instanz mit "sqlplus" gestartet werden.

Hinzufügung weiterer Datenbanken

Nun soll eine weitere, bereits existierende Datenbank rac2db auf den Knoten laufen. Zunächst nur parallel zu rac1db auf den gleichen Knoten:

srvctl modify database -d rac2db -serverpool rac1db_serverpool  

Ergebnis:

srvctl status database -d rac2db
Instance rac2db_1 is running on node server-c
Instance rac2db_2 is running on node server-b
Instance rac2db_3 is running on node server-a

Aus Performance-Gründen sollen die Datenbanken aber nicht parallel auf dem gleichen Knoten laufen.

Ein weiterer Serverpool, in dem mindestens eine Instanz starten soll, wird angelegt:

srvctl add srvpool -serverpool rac2db_serverpool -min 1 -max 1

Die Datenbank rac2db wird dem Serverpool rac2db_serverpool zugeordnet:

Es erscheint folgende Meldung:

PRCD-1230 : Failed to modify database rac2db to use server pool rac2db_serverpool
PRCR-1071 : Failed to register or update resource ora.rac2db.db
CRS-2736: The operation requires stopping resource 'ora.rac2db.db' on server 'server-c'
CRS-2736: The operation requires stopping resource 'ora.rac2db.db' on server 'server-b'
CRS-2736: The operation requires stopping resource 'ora.rac2db.db' on server 'server-a'
CRS-2744: Unable to modify resource 'ora.rac2db.db' as this will affect running resources, but the force option was not specified

Wir versuchen es mit der Force-Option:

srvctl modify database -d rac2db -serverpool rac2db_serverpool -f

Ein Blick auf den Output von:

srvctl status database -db rac2db
Database is not running.

Wenn wir versuchen, die Datenbank zu starten:

srvctl start database -db rac2db
PRCR-1079 : Failed to start resource ora.rac2db.db
CRS-2643: The server pool(s) where resource 'ora.rac2db.db' could run have no servers

Instanzverteilung

Welche Möglichkeiten gibt es, eine Instanz der Datenbank rac2db  zu starten:

- Erhöhung der Prioriät eines Serverpools

srvctl modify serverpool -serverpool rac2db_serverpool  -importance 50
PRCS-1011 : Failed to modify server pool rac2db_serverpool
CRS-2736: The operation requires stopping resource 'ora.rac1db.db' on server 'server-a'
CRS-2738: Unable to modify server pool 'ora.rac2db_serverpool' as this will affect running resources, but the force option was not specified

Die Force-Option(-f)  ist erforderlich, da eine Instanz von rac1db gestoppt werden muss.

Jetzt haben wir folgende Aufteilung

rac1db

Instance rac1db_1 is running on node server-c
Instance rac1db_3 is running on node server-b

rac2db

Instance rac2db_3 is running on node server-a

- Änderung Serverpool-Attribute

Der Serverpool rac1db_serverpool wird dahingehend geändert, dass die Datenbank rac1db auch mit nur 2 Instanzen startet:

srvctl modify serverpool -serverpool rac1db_serverpool -min 2 -max 3
PRCS-1011 : Failed to modify server pool rac1db_serverpool
CRS-2736: The operation requires stopping resource 'ora.rac1db.db' on server 'server-a'
CRS-2738: Unable to modify server pool 'ora.rac1db_serverpool' as this will affect running resources, but the force option was not specified

Nach Angabe der Force-Option -f haben wir die gleiche Verteilung wie oben.

- Einrichtung Policy

Mit der Einrichtung einer Policy ist es möglich, tageszeitabhängige Ressourcen hinzu-/wegzunehmen. Die Datenbank mit den Reports-Auswertungen muss möglicherweise in der Nacht nur mit einer statt zwei Instanzen betrieben werden, während die DWH-DB für Verdichtungsläufe zusätzliche Ressourcen benötigt.

Beispiel für eine Policy:

crsctl add policy werktags
crsctl add policy abends
crsctl add policy wochenende

Zuordnung von Policy-Attributen:

crsctl modify serverpool ora.rac1db_serverpool -attr "MAX_SIZE=2" -policy werktags
crsctl modify serverpool ora.rac2db_serverpool -attr "MAX_SIZE=1" -policy werktags
crsctl modify serverpool ora.rac1db_serverpool -attr "MAX_SIZE=3" -policy abends
crsctl modify serverpool ora.rac2db_serverpool -attr "MAX_SIZE=0" -policy abends
crsctl modify serverpool ora.rac1db_serverpool -attr "MAX_SIZE=1" -policy wochenende
crsctl modify serverpool ora.rac2db_serverpool -attr "MAX_SIZE=2" -policy wochenende

Was passiert, wenn die Policy „abends“ gewählt wird? Mit dem Parameter „eval“ können die Auswirkungen ermittelt werden:

crsctl eval activate policy abends -f
Bereitstellungsgruppe 1:
--------------------------------------------------------------------------------
Bereitstellungsnummer   Erforderlich    Aktion
--------------------------------------------------------------------------------
     1              Y           Ressource "ora.rac2db.db" (3/1) wird Status
                                [OFFLINE] haben
                    Y           Server 'server-a' wird von Pools
                                [ora.rac2db_serverpool] zu Pools
                                [ora.rac1db_serverpool] verschoben 

     2              Y           Ressource "ora.rac1db.db" (2/1) wird Status
                                [ONLINE|INTERMEDIATE] haben auf Server
                                [server-a]

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

Die Aktivierung der Policy “abends” erfolgt mit:

crsctl modify policyset -attr "LAST_ACTIVATED_POLICY=abends“ -f
CRS-2673: Versuch, "ora.rac2db.db" auf "server-a" zu stoppen
CRS-2677: Stoppen von "ora.rac2db.db" auf "server-a" erfolgreich
CRS-2672: Versuch, "ora.rac1db.db" auf "server-a" zu starten
CRS-2676: Starten von "ora.rac1db.db" auf "server-a" erfolgreich

Anschließende Verteilung

rac1db

Instance rac1db_1 is running on node server-c
Instance rac1db_2 is running on node server-a
Instance rac1db_3 is running on node server-b

rac2db

Database is not running.

Die Verteilung der Ressourcen gemäß Auslastung kann mit dem Oracle Database Quality of Service Management auch automatisiert werden. Die Vorgehensweise würde den Rahmen dieses Monatstipps sprengen. Für nähere Informationen wird auf den Oracle Database Quality of Service User’s Guide verwiesen.

 

Fazit:

Die 'Policy Managed Database' ist eine durchaus praktikable Lösung, um auch bei kleineren Cluster-Umgebungen Datenbank-Ressoucen tageszeit- oder lastabhängig hinzuzuschalten.

Diese und weitere Komponenten rund um den Real Application Clusters lernen Sie in unserem RAC 12c Kurs kennen. Schauen Sie sich einfach einmal auf unseren Opens internal link in current windowSchulungsseiten um.

DBA RAC Oracle Datenbank 12c Policy Managed

Jede Menge Know-how für Sie!

In unserer Know-How Datenbank finden Sie mehr als 300 ausführliche Beiträge zu den Oracle-Themen wie DBA, SQL, PL/SQL, APEX und vielem mehr.
Hier erhalten Sie Antworten auf Ihre Fragen.