Resource Management mit Pluggable Database

Mittlerweile gibt es einige Blogs rund um das Thema Pluggable Database und sehr oft wird als Schwachpunkt der konkurrierende Zugriff auf die Ressourcen genannt, da es nur eine SGA, einen Satz an Redolog Dateien und einen Undo-Tablespace gibt. Das ist richtig und sollte bei der Konsolidierung von Produktionsdatenbanken sicherlich berücksichtigt werden.

Aber es ist durchaus möglich, zumindest den CPU-Verbrauch und den Grad der Parallelisierung für einzelne PDBs zu setzen bzw. eine entsprechende Priorisierung vorzunehmen. Zusätzlich zu den bereits bestehenden Ressource Plänen, die natürlich auch in einzelnen PDBs angewendet werden können, gibt es spezielle CDB Ressource Pläne, die derzeit eine Limitierung des CPU Verbrauchs und der Anzahl paralleler Prozesse ermöglichen.

Es gibt zwei Arten, die Ressourcen zu begrenzen:

• Die Verwendung von Shares ähnlich wie bei VMware und anderen Virtualisierungslösungen
• Die harte Limitierung von Ressourcen

Lassen Sie uns beispielhaft annehmen, dass wir drei PDBs haben (JOHANN1, JOHANN2 und JOHANN1CLONE). Während JOHANN1 und JOHANN2 meine beiden wichtigsten Datenbanken sind, handelt es sich bei JOHANN1CLONE nur um eine Testkopie, die sich aus unerfindlichen Gründen ebenfalls auf dem Produktionsserver befindet. Man kann jetzt sehr einfach die beiden PDBs JOHANN1 und JOHANN2 stärker priorisieren und JOHANN1CLONE einfach nur einen kleinen Prozentsatz der Ressourcen zuteilen. Zudem ist es möglich, bei der Ressourcenvergabe den CPU Verbrauch von JOHANN1CLONE auf 50% zu deckeln und für diese PDB gar keine Parallelisierung zuzulassen.

Erstellen eines CDB Resource Plans:

Zunächst muss, wie üblich, eine so genannte Pending Area erstellt werden.

BEGIN
   dbms_resource_manager.create_pending_area();
END;

Jetzt kann der CDB Plan erstellt werden. Dieser Plan dient als Verwaltungseinheit der individuellen Direktiven und wird später über den Oracle Parameter „resource_manager_plan“ aktiviert bzw. deaktiviert.

BEGIN
   dbms_resource_manager.create_cdb_plan(        
      PLAN => 'johanns_plan',        
	  COMMENT => 'CDB Resource Plan for Database CJOHANN'); 
END;

Als nächstes werden die einzelnen Plandirektiven angelegt. Hierüber bekommen die einzelnen PDBs ihre Ressourcen zugewiesen:

BEGIN     
   dbms_resource_manager.create_cdb_plan_directive(         
      plan                  => 'johanns_plan',         
	  pluggable_database    => 'JOHANN1',        
	  shares                => 100,         
	  utilization_limit     => 100,         
	  parallel_server_limit => 100);     
   dbms_resource_manager.create_cdb_plan_directive(         
      plan                  => 'johanns_plan',                          
	  pluggable_database    => 'JOHANN2',         
	  shares                => 100,         
	  utilization_limit     => 100,         
	  parallel_server_limit => 100);     
   dbms_resource_manager.create_cdb_plan_directive(         
      plan                  => 'johanns_plan',         
	  pluggable_database    => 'JOHANN1CLONE',         
	  shares                => 10,         
	  utilization_limit     => 50,         
	  parallel_server_limit => 0); 
END;

Wie man sieht ist die Syntax recht simpel und es gibt nur drei mögliche Parameter:

• shares: Anzahl der Shares für diese PDB.
• utilization_limit: Deckelung der CPU Benutzung (in Prozent). 100 zeigt an, dass diese PDB, wenn möglich, die kompletten CPU Ressourcen benutzen darf.
• parallel_server_limit: Deckelung der Anzahl von parallelen Prozessen. Auch hier gibt die 100 an, dass bei Bedarf alle Ressourcen genutzt werden können.

Jetzt kann die Pending Area validiert und, falls es keine Fehlermeldungen gibt, der Resource Plan bestätigt werden.

BEGIN     
   dbms_resource_manager.validate_pending_area(); 
END;  

BEGIN     
   dbms_resource_manager.submit_pending_area(); 
END;

Unser CDB Resource Plan steht jetzt zur Verfügung und kann, durch die Änderung des Oracle Parameters RESOURCE_MANAGER_PLAN aktiviert werden:

SQL> ALTER SYSTEM SET RESOURCE_MANAGER_PLAN = 'johanns_plan';

Die Deaktivierung erfolgt dann einfach über den folgenden Befehl:

SQL> ALTER SYSTEM SET RESOURCE_MANAGER_PLAN = '';

Wenn der Plan gelöscht oder geändert werden soll, muss wiederum eine Pending Area aufgebaut werden. Im folgenden Beispiel wird der gesamte Plan wieder gelöscht:

BEGIN     
   dbms_resource_manager.create_pending_area();     
   dbms_resource_manager.delete_cdb_plan(PLAN => 'johanns_plan');     
   dbms_resource_manager.validate_pending_area();     
   dbms_resource_manager.submit_pending_area(); 
END;

Unglücklicherweise ist mir beim Testen ein Fehler unterlaufen, denn ich habe versucht, einen Plan zu aktivieren, den ich vorher gelöscht habe. So etwas kann schon mal passieren allerdings hatte ich nicht mit dieser Reaktion gerechnet:

SQL> ALTER SYSTEM SET RESOURCE_MANAGER_PLAN = 'johanns_plan'; 
ERROR: ORA-03113: end-of-file on communication channel Process ID: 21166 Session ID: 1 Serial number: 9

Der Fehler führte zum Absturz der Instanz!

Also seien Sie bitte vorsichtig bei der Änderung oder Aktivierung von Plänen – aber da sage ich Ihnen sicherlich nichts Neues.

Zusammenfassung

Dies ist sicherlich erst der erste Schritt zu einem Resource Management für Pluggable Database. Der Buffer Cache bzw. die I/O Last kann bisher bei „normalen“ Datenbanken noch nicht verwaltet werden. Oracle Exadata hat schon jetzt die Möglichkeit I/O Ressourcen zu verteilen bzw. entsprechend zuzuteilen und ich denke, in den nächsten Releases bzw. Patchsets werden wir einige Erweiterungen in diesem Bereich sehen.

Nichtsdestotrotz ist der derzeitige Ansatz sehr gut, er ist einfach zu nutzen und hilft sehr gut dabei, die Ressourcen der einzelnen PDBs entsprechend zuzuteilen.