Verwaltung von CPU-Zeit auf Datenbankebene mit dem Oracle9i Resource Manager

Transkript

1 Verwaltung von CPU-Zeit auf Datenbankebene mit dem Oracle9i Resource Manager Autor: Wolfgang Thiem, ORACLE Deutschland GmbH DOAGNews Q1_2004 Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte, insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder der Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen, bleiben, bei auch nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen der gesetzlichen Bestimmungen des Urheberrechtes der Bundesrepublik Deutschland vom 9. September 1965 in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des Urheberrechtsgesetzes.

2 Einleitung Wenn man von Ressourcen Management im Rahmen der Datenbankadministration spricht, denkt man vor allem an die Verwaltung von Systemressourcen wie Plattenkapazität und Hauptspeicher. Werkzeuge zur Administration dieser Ressourcen sind in der Regel bei allen gängigen Datenbanksystemen im Standard enthalten. Die Ressource CPU-Zeit hingegen wird oftmals rein auf Betriebssystemebene verwaltet und demzufolge auf Basis von Automatismen, welche die unterschiedlichen Bedürfnisse an die Datenbank nicht differenzieren können. Da die Datenbanksysteme jedoch immer komplexer werden und die Anwender einer Datenbank unterschiedliche Anforderungen an das System haben (Online Transaktionen vs. Batchprozesse vs. Report Anwender), bietet Oracle bereits seit der Datenbank Version 8i, in der Enterprise Edition, den Oracle Resource Manager an, welcher es erlaubt auch CPU-Zeit auf Datenbankbenutzerebene zu steuern und somit Datenbanksysteme hinsichtlich CPU-Last optimal auszunutzen. Des weiteren bietet das Werkzeug zusätzliche Kontrollmechanismen und Konfigurationsmöglichkeiten an, um den Betrieb der Datenbank zu sichern und zu optimieren. Während der Oracle Resource Manager in den ersten Versionen über PL/SQL zu steuern war, bieten die Versionen ab Oracle9i ein breit gefächertes Spektrum von unterschiedlichen Konfigurationsmöglichkeiten, sowie eine Administrationsoberfläche innerhalb des Oracle Enterprise Managers 9i an. Anwendungsbereiche 1. Sicherung des Zugriffs - Es ist möglich, dass im Falle einer CPU-Überlastung (z.b. durch die Berechnung karthesischer Produkte, etc.) selbst Datenbankadministratoren nicht mehr auf das System zugreifen können, da bereits für den Connect an die Datenbank keine CPU-Zeit mehr zur Verfügung steht. Der Oracle Resource Manager erlaubt es, die Aufteilung der CPU-Zeit so durchzuführen, dass bestimmte Benutzergruppen z.b. der DBA auf jeden Fall CPU- Ressourcen zur Verfügung gestellt bekommen. Man hat somit die Möglichkeit, die den Engpass verursachenden Transaktionen festzustellen und die notwendigen Maßnahmen einzuleiten. 1. CPU-Lastverteilung - Speziell im Zuge der Konsolidierung von Daten entstehen unterschiedliche Anforderungsprofile an die Datenbank. Während beispielsweise Applikationen tagsüber häufig im OLTP (Online Transaction Processing)-Betrieb genutzt werden, sollen Reports über den Geschäftsverlauf grundsätzlich erst nachts durchgeführt werden. Dringend benötigte Reports, welche tagsüber erstellt werden müssen, sollen den OLTP- Betrieb so wenig wie möglich beeinflussen. Der Oracle Resource Manager erlaubt in diesem Kontext, Applikationen bzw. Anwendern, einen definierte Menge CPU- Zeit (Verbrauch) zuzuteilen, um die priorisierte Verarbeitung bestmöglich zu unterstützen. Consumer Group SYS GROUP Auftragserfassung Controlling Reporting OTHER GROUPS Level 1 100% Level 60% 20% 20% Abb. 1 Beispielhafter Multilevel Ressourcenplan. Level 100%

3 - Damit die für eine Benutzergruppe eingeschränkt zur Verfügung gestellte CPU-Zeit nicht durch eine zu hohe Anzahl von aktiven Nutzern innerhalb dieser Gruppe nicht komplett verbraucht werden kann, können Active Session Pools konfiguriert werden. Diese Active Session Pools beschreiben die maximale Anzahl von gleichzeitig aktiven Sitzungen in einer User Group. Sofern die definierte Höchstgrenze von gleichzeitig aktiven Sitzungen überschritten wird, werden die neuen Sitzungen in eine Warteschlange gestellt und sobald wieder Ressourcen zur Verfügung stehen abgearbeitet. Hierbei kann eine zeitliche Begrenzung der Job Queue konfiguriert werden, nach deren Ablauf die Transaktion abgebrochen wird. - Im Rahmen des Einsatzes von Multiprozessor-Maschinen besteht die Möglichkeit, für verschiedenen Benutzergruppen einen maximalen Parallelisierungsgrad einzustellen und somit Teile des Rechners auf jeden Fall für andere Transaktionen frei zu halten. - Sofern Anwender einer definierten Gruppe Transaktionen ausführen, welche belastungsseitig dem Profil einer anderen Gruppe entsprechen, ist es möglich einen temporären Wechsel der Transaktion in ein anderes Nutzerprofil automatisiert durchzuführen. Beispiel: Ein OLTP-Anwender führt ein komplexes select -Statement aus. Im Oracle Resource Manager ist konfiguriert, dass alle Transaktionen welche länger als 5 Minuten laufen, automatisch überführt werden und über die Ressourcendefinition der Anwendergruppe Report ausgeführt werden sollen. Der OLTP-Betrieb wird somit nicht zusätzlich belastet, da das komplexe select -Statement mit einer geringeren CPU Zuweisung abgearbeitet wird. 3. Zusätzliche Konfigurationsmöglichkeiten - Der Oracle Resource Manager erlaubt die Anlage von sogenannten Undo-Pools und ermöglich somit eine Einschränkung des Platzverbrauchs im Undo -Tablespace für verschiedene Benutzergruppen. Report Anwender benutzen in der Regel kaum Undo - Ressourcen. Der Undo -Pool kann in diesem Fall für diese Benutzergruppe niedriger gesetzt werden. - Sofern verschiedene Ressourcenpläne konfiguriert wurden, können diese innerhalb einer Instanz dynamisch (ohne Shutdown/Startup) gewechselt werden. Der Oracle Resource Managers bietet ein Werkzeug zum automatisierten, zeitgesteuerten Wechsel von Ressourcenplänen an. Sofern z.b. ein Tag-/Nachtbetrieb definierbar ist, können die unterschiedlichen Ressourcenpläne zu fest definierten Zeitpunkten aktiviert werden. Bestandteile des Oracle Resource Managers Der Oracle Resource Manager besteht aus folgenden Teilkomponenten: 1. Resource Consumer Groups Eine Resource Consumer Group ist eine Gruppierung der verschiedenen Anwender nach ihrem zugeordneten Ressourcenverbrauch Standardmäßig sind die folgenden Gruppen bereits im System vorhanden: - DEFAULT_CONSUMER_GROUP Diese Gruppe hat für alle bislang nicht explizit zugeordneten Anwender Gültigkeit. Jeder neu angelegte User wird automatisch dieser Gruppe hinzugefügt. - OTHER_GROUPS

4 Sofern Anwender in Gruppen eingeordnet sind, welche dem aktuell aktiven Ressourcen Plan nicht angehören, werden diese Anwender dieser Gruppe zugeordnet. - SYS_GROUP Dieser Gruppe sind grundsätzlich die User SYS und SYSTEM zugeordnet. Bei Bedarf sollten auch weitere DBA-User dieser Gruppe hinzugefügt werden. 2. Resource Plan Der Resource Plan beinhaltet den Namen, die Beschreibung, sowie die eingestellten Werte eines Planes. Diesen Ressourcen Plänen werden die Resource_Consumer_Groups zugeordnet. 3. Resource Plan Schedule Der Resource Plan Schedule, welcher auf der Datenbankfunktionalität DBMS_JOB aufsetzt, erlaubt es, verschiedene Ressourcen Pläne automatisiert zu bestimmten Zeiten zu aktivieren. Dies ist besonders bei zeitlich klar definierbaren Datenbankanforderungen sinnvoll. 4. Resource Plan Directives Innerhalb der Ressourcen Pläne werden die sogenannten Resource Plan Directives eingestellt, Diese stellen die eigentliche Konfiguration des Planes dar, und enthält die Definitionen zur CPU-Verteilung, Session Pool, etc.. Voraussetzungen Um Ressourcen Pläne innerhalb des Oracle Resource Manager verwalten zu können, ist das Systemprivileg ADMINISTER_RESOURCE_MANAGER bzw. die Rolle DBA notwendig. Die Parameter anhand des Beispiel SYSTEM_PLAN Im folgenden wird der standardmäßig vordefinierte Plan SYSTEM_PLAN erläutert, welcher bei jeder Oracle 9i Datenbankinstallation integriert ist. Der Plan ist auf die Funktionalität zur Sicherung des Zugriffs bei CPU- Ressourcen Problemen optimiert. Der Plan kann ohne weitere Einstellungen jederzeit aktiviert werden. Sofern andere Einstellung gewünscht sind, kann der Plan individuell angepasst werden. Die Wertigkeit 100 % bezieht sich im folgenden nicht auf 100 % der CPU- Zeit im Gesamtsystem, sondern auf die maximale CPU-Zeit welche der Datenbank vom Betriebssystem für aktive Datenbankverbindungen zur Verfügung gestellt wird. Abb. 2. System Plan generelle Einstellungen

5 Der Plan ist als Multi Level Plan aufgesetzt, wobei der SYS_GROUP, welche standardmäßig die Anwender SYS und SYSTEM beinhaltet, die höchste Priorität zugewiesen ist Level %. Die Gruppe OTHER_GROUPS (Level 2 100%) ist die Gruppe, deren Wertigkeiten für alle Gruppen (und somit deren Anwender) zutrifft, welche nicht explizit als Gruppe im Plan aufgeführt sind. Sofern Anwender im System arbeiten, deren Priorität als niedrig eingestuft ist, werden diese der Gruppe LOW_GROUP zugeordnet Level 3, ebenfalls mit 100%. Was bedeuten diese Einstellungen in der Praxis? Die Anwender der LOW_GROUP können das System zu 100% nutzen, sofern keine Anwender der Gruppe OTHER_GROUPS innerhalb der Datenbank CPU Ressourcen benötigen. Arbeiten User der Gruppe OTHER_GROUPS im System, werden die Ressourcen der LOW_GROUP sukzessiv heruntergefahren. Sobald die Anwender der Gruppe OTHER_GROUPS 100 % der CPU-Zeit verwenden, steht für diesen Zeitraum keine CPU-Zeit für die LOW_GROUP zur Verfügung. Unter dem Menüpunkt Parallelism ist eine unbegrenzte Parallelisierung für alle Gruppe aktiviert. Sofern Multiprozessor-Maschinen zur Verfügung stehen, ließe sich eine Einschränkung des maximalen Parallelisierungsgrades einstellen. Damit werden individuelle Einstellungen (z.b. innerhalb eines Skriptes) aufgehoben. Der Menüpunkt Session Pool beinhaltet die Einstellungen für die maximale Anzahl von gleichzeitig aktiven Verbindungen, die zur Datenbank bestehen können, welche pro Gruppe durchgeführt werden können. Im Beispiel sind die Wertigkeiten für alle Gruppen auf Unbegrenzt gestellt. Sofern hier andere Werte konfiguriert wurden, werden die Transaktionen von Anwendern, die sich oberhalb des Grenzwertes befinden, in eine Warteschlange gestellt. Sobald eine aktive Session inaktiv wird, beginnt die Abarbeitung der Warteschlange. Über den Parameter Timeout (in Sekunden) wird definiert, wie lange Transaktionen maximal in der Warteschlange gehalten werden, bevor sie mit einer Fehlermeldung abbrechen. create table objects3 as select * from objectsn * ERROR at line 1: ORA-07454: queue timeout, 2 second(s), exceeded Abb. 3. Fehlermeldung bei Zeitüberschreitung Im Beispielplan ist unter Undo-Pool ebenfalls unbegrenzter Zugriff für alle Gruppen vorgegeben. Im Falle der Überschreitung des eingestellten Wertes werden laufende Transaktionen, welche in den Undo-Pool schreiben, abgebrochen. Neue Transaktionen können erst gestartet werden, wenn wieder Platz im Undo-Pool zur Verfügung steht.

6 Die Execution Time bezieht sich auf die vom System erwartete Ausführungszeit für eine Transaktion. Sobald die erwartete Zeit länger ist als der eingestellte Wert, wird die Transaktion nicht gestartet beziehungsweise mit einer Fehlermeldung terminiert. Im Beispiel sind keine Beschränkungen konfiguriert. Unter Group Switch kann definiert werden, das Transaktionen welche nicht dem Normalfall der Gruppe entsprechen, in eine andere Gruppe übergeleitet werden. Beispiel: Die normale Transaktionszeit der Anwender in der Gruppe OTHER_GROUPS liegt durchschnitt-lich bei 30 Sekunden. Der Ressource Manager ist so konfiguriert, dass er diese Gruppe mit einer hohen Priorität, sprich viel CPU-Zeit versorgt. Ein Anwender der Gruppe startet eine Transaktion deren Laufzeit größer 5 Minuten, sowie CPU intensiv ist. Für solche Fälle kann die Funktionalität Group Switching genutzt werden. Abb. 4. System Plan / Group Switching Anhand der Parameter wird bestimmt: - Nach welcher Zeit eine Transaktion in eine andere Gruppe (vorzugsweise geringer priorisiert) transferiert werden soll. Wobei der Transfer unterbrechungsfrei stattfindet, - beziehungsweise ob bereits vor dem Start der Transaktion ein Wechsel in eine niedriger priorisierte Gruppe stattfinden soll. In diesem Fall ist die Option Estimate auszuwählen, welche eine Abschätzung der Laufzeit vorab durchführt. Erstellen eigener Ressourcen Pläne Wie bereits beschrieben, unterstützt der Oracle Enterprise Manager 9i alle Funktionen des Oracle Resource Managers. Um mit diesem Werkzeug die Konfiguration für einen eigenen Ressourcen Plan zu erstellen, empfiehlt sich die Verwendung des Wizards. Mit Hilfe des Wizards lassen sich schnell einfache Pläne, aber auch Multi Level Pläne entwickeln. Am Ende jeder Konfiguration, welche über den Wizard surchgeführt wird, wird ein Script generiert, welches man innerhalb des Oracle Enterprise Managers 9i ausführen lassen kann. Eine Speicherung des Skriptes, um es beispielsweise für andere Datenbankinstanzen anzuwenden, ist ebenfalls möglich.

7 Zusammenfassung Der Oracle Resource Manager ermöglicht die Verwaltung von System-Ressourcen auf Datenbankebene. Durch die individuelle Verteilung von CPU-Ressourcen kann eine detaillierte Abbildung von unterschiedlichen Bedürfnissen an den Datenbankbetrieb erreicht werden. Der Einsatz des Werkzeuges kann die Performanz eines Systems erhöhen. Die Möglichkeit, bestimmten Anwendern (z.b. DBA) auf jeden Fall Ressourcen zur Verfügung zu stellen und somit einen Zugriff auf das System garantiert zu erhalten, auch im Falle von CPU Engpässen, erhöht die Verfügbarkeit der Datenbank. Weiter Informationen Oracle9i Database Administrator s Guide Release 2 (9.2) Kapitel 27 Oracle9i Enterprise Manager Administrators Guide Kontaktadresse: ORACLE Deutschland GmbH Wolfgang Thiem STCC München Riesstrasse 15 D München Telefon: +49(0) Fax: +49(0) wolfgang.thiem@oracle.com Internet: