Database Instance Caging


Database Instance Caging ist die Möglichkeit ab der Version 11.2 eine oder mehrere Datenbanken auf einem Datenbank Server CPU technisch aufzuteilen. Anderes ausgedrückt, ich limitiere die Anzahl an CPUs welche eine Datenbank gleichzeitig benutzen darf. Dieses Feature basiert auf dem Oracle Ressource Manager weswegen diese Option auf Enterprise Edition eingeschränkt ist.

Beispiel over-provisioned:
Ein Datenbank Server 2 CPU* 2 Cores ergibt einen CPU Count von 4. Nehmen wir jetzt mal an, das auf diesen Datenbank Server 5 Instanzen laufen. Wenn jetzt alle Datenbanken zur gleichen Zeit eine hohe CPU Load abzuarbeiten haben sprechen wir in diesem Fall von einem „over-provisioned“ Server.

5 Instanzen * 4 CPU Count = 20 CPU`s

Mir ist auch klar, das man über diese Rechnung lange reden kann, ich will hier nur ein extremes „over-provisioned“ Beispiel zeigen.

Beispiel für den Einsatz:
Gehen wir nun von folgendem Szenario aus. Ein Server mit 32 CPU`s und wieder 4 Instanzen. Bei Instanz A und B handelt es sich um kleinere Erfassungsysteme, Instanz C ist ein Reporting System und Instanz D ist eine DWH Datenbank. Was man hier nun machen kann ist Instanz A und B auf 4 CPU`s zu limitieren Instance C bekommt 8 und die DWH Datenbank bekommt 16 CPU`s zugewiesen. Dadurch ergibt sich folgende Rechnung.

4 CPUs + 4 CPUs + 8 CPUs + 16 CPUs = 32 CPUs

Mit dem Beispiel kann der DBA Sorge tragen das sein Datenbank Server nicht in eine „over-provisioned“ Situation kommt. Natürlich darf man aber auch nicht vergessen das wenn Instanz C seine CPUs nicht benötigt diese auch nicht für Instanz A,B.D zur Verfügung stehen.

Für mich persönlich ist das auch nicht das Gelbe vom Ei, aber hier ein Beispiel das man in der Praxis schon öfter vorfinden kann (und ich selber schon gute Ergebnisse damit erzielt habe).

Beispiel Single Datenbank:

Gehen wir wieder zu unserem EE Server mit 2 CPUs und 2 Cores, jetzt haben wir aber nur eine Datenbank auf diesen Server im Einsatz. Stellen wir uns nun vor, das wir z.B. einen Tagesabschluss auf diesem System laufen haben, welcher ein paar Stunden am Laufen ist. Was jetzt passieren kann ist, das alle CPUs dieses Server für diesen Tagesabschluss am Laufen sind. Klingt fürs Erste gut, jedoch ist das Problem, das alle Background Prozesse wie z.B. ein LGWR oder DBWR ebenfalls knapp an CPU ( da die Task Queue des Operating System gefüllt ist ) sind, was zu eine Race Condition führen kann. Hier könnte man mit dem Instance Caging erreichen, das seitens des Operating System Ressourcen zur Verfügung stehen. Ich habe damit in der Praxis schon gute Erfahrungen gemacht (ebenfalls auf Exadata).

Wie wird es konfiguriert:
Die Konfiguration ist sehr simpel, da nur 2 Dinge benötigt werden. Das Setzen des „cpu_count“ Parameter und ein aktiver Ressource Plan welcher eine CPU Direktive enthält (auch der DEFAULT_PLAN).

SQL> alter system set cpu_count=2 scope=both;

System altered.

Wie man sieht kann man diesen Parameter in laufenden Betrieb setzen. Was man natürlich nicht machen kann, ist den Parameter höher zu setzten, als physikalische CPUs vorhanden sind.

SQL> select value from v$osstat where stat_name='NUM_CPUS';

     VALUE
----------
     4

SQL> alter system set cpu_count=8 scope=both;
alter system set cpu_count=8 scope=both
*
ERROR at line 1:
ORA-02097: parameter cannot be modified because specified value is invalid

Das Database Instance Caging im Einsatz ist, kann man natürlich ebenfalls am cpu_count Parameter erkennen.

SQL> select value from v$parameter where name = 'cpu_count' and (isdefault =
'FALSE' or ismodified != 'FALSE');   

VALUE
--------------------------------------------------------------------------------
2

Nicht zu vergessen das wir einen Ressource Manager Plan benöitgen welcher eine CPU Direktive hat.

SQL> alter system set resource_manager_plan='DEFAULT_PLAN' scope=both;

System altered.

SQL> select name from v$rsrc_plan where is_top_plan = 'TRUE' and cpu_managed =
'ON'; 

NAME
--------------------------------
DEFAULT_PLAN

Da das Ganze über den Resource Manager läuft, können wir auch über diesen in Erfahrung bekommen, in wie weit die CPU Nutzung auf einem Datenbank Server eingeschränkt wurde

SQL> select name, consumed_cpu_time, cpu_wait_time from v$rsrc_consumer_group;

NAME                 CONSUMED_CPU_TIME CPU_WAIT_TIME
-------------------------------- ----------------- -------------
SYS_GROUP                        74                0
OTHER_GROUPS                     4                 0
ORA$AUTOTASK_URGENT_GROUP        12                0
ORA$AUTOTASK_STATS_GROUP         0                 0
ORA$AUTOTASK_SPACE_GROUP         0                 0
ORA$AUTOTASK_SQL_GROUP           0                 0
ORA$AUTOTASK_HEALTH_GROUP        0                 0
ORA$AUTOTASK_MEDIUM_GROUP        0                 0
ORA$DIAGNOSTICS                  0                 0
_ORACLE_BACKGROUND_GROUP_        0                 0

10 rows selected.

SQL> select begin_time, consumer_group_name, cpu_consumed_time, cpu_wait_time
from v$rsrcmgrmetric_history order by begin_time;  2  

BEGIN_TIM CONSUMER_GROUP_NAME         CPU_CONSUMED_TIME CPU_WAIT_TIME
--------- ------------------------------ ----------------- -------------
23-OCT-12 SYS_GROUP                      21                0
23-OCT-12 OTHER_GROUPS                   0                 0
23-OCT-12 ORA$AUTOTASK_URGENT_GROUP      0                 0
23-OCT-12 ORA$AUTOTASK_STATS_GROUP       0                 0
23-OCT-12 _ORACLE_BACKGROUND_GROUP_      0                 0
23-OCT-12 ORA$AUTOTASK_SQL_GROUP         0                 0
23-OCT-12 ORA$AUTOTASK_HEALTH_GROUP      0                 0
23-OCT-12 ORA$AUTOTASK_MEDIUM_GROUP      0                 0
23-OCT-12 ORA$DIAGNOSTICS                0                 0
23-OCT-12 ORA$AUTOTASK_SPACE_GROUP       0                 0

10 rows selected.

Alternativen

Alternativen gibt es einige, hier kann man auf IBM LPAR oder Solaris Container setzen. Natürlich ist auch Virtualisierung eine Option, aber dies muss man sich vor einer Konsolidierung gut überlegen, da gerade Virtualisierung und Oracle Lizensierung ein heisses Thema ist, wo man sich schnell als DBA verbrennen kann bzw. die Kosten weitaus höher sind als einen Datenbank Parameter zu setzten.

Was gibt es noch:

Die Dokumentation

Folgende MOS Notes sollte man sich ebenfalls vorher ansehen:

Configuring and Monitoring Instance Caging [ID 1362445.1]
Recommended Patches for Instance Caging [ID 1208064.1]
Recommended Patches for Instance Caging [ID 1340172.1]

Wie immer freue ich mich auf Feedback zu meinem Block 🙂

Advertisements

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s