Oracle-Initialisierungsparameter

Damit ArcSDE läuft, muss die Standardkonfiguration der Oracle-Instanz nicht geändert werden. Für größere Systeme jedoch können einige Änderungen an der Konfiguration der Oracle-Instanz sinnvoll sein.

Bei jedem Start einer Oracle-Instanz liest Oracle die Initialisierungsparameter entweder aus der Datei "init.ora" oder aus der Serverparameterdatei "spfile.ora". Beide Dateien definieren die Eigenschaften der Instanz, werden jedoch unterschiedlich verwaltet.

Die Datei "init.ora" befindet sich im Verzeichnis bzw. Ordner "ORACLE_BASE/admin/<ORACLE_SID>/pfile". "init.ora" ist der übliche Name für eine Initialisierungsdatei einer Oracle-Datenbankinstanz. Der Name für jede festgelegte Instanz lautet jedoch "init<oracle SID>.ora". Wenn beispielsweise die Oracle-System-ID (SID) GIS ist, lautet der Name der Datei "init.ora" für diese Instanz "initGIS.ora".

Das Ändern von Parametern mit dem Befehl "ALTER SYSTEM" wird automatisch in der Serverparameterdatei angezeigt, wenn die Instanz auf diese Weise gestartet wurde. Wenn die Instanz mit einer Datei "init.ora" gestartet wurde, müssen Sie die Datei manuell mit einem Text-Editor bearbeiten, falls Sie möchten, dass Änderungen an den Systemparametern nicht nur auf die aktuelle Instanz der Datenbank Auswirkungen haben.

Parameter, die den freigegebenen Speicher beeinflussen

In diesem Abschnitt werden einige der Parameter beschrieben, die die Zuordnung von freigegebenem Speicher steuern. Detaillierte Informationen zu den Oracle-Initialisierungsparametern finden Sie unter Oracle Server Tuning für Ihre Oracle-Version.

"OPEN_CURSORS"

Der Oracle-Initialisierungsparameter "OPEN_CURSORS" legt die Anzahl von Cursors fest, die gleichzeitig während einer Sitzung geöffnet sein können. Die Standardeinstellung liegt bei 300. Wenn die Sitzung versucht, einen neuen Cursor zu öffnen, jedoch die Höchstmenge von Cursors bereits geöffnet ist, wird die Oracle-Fehlermeldung "-1000" ausgegeben. In ArcSDE bleiben zur Verbesserung der Leistung häufig genutzte Cursor geöffnet. Wenn der Oracle-Parameter "OPEN_CURSORS" nicht hoch genug eingestellt ist, werden die oben genannte Fehlermeldung angezeigt. Aus der Oracle-Dokumentation lässt sich entnehmen, dass die Einstellung des Parameters auf einen hohen Wert keine negativen Auswirkungen hat. Aus diesem Grund können Sie den Wert extrem hoch setzen, z. B. auf 2000. Dadurch wird eine Begrenzung der Anzahl offener Cursor praktisch aufgehoben, jedoch besteht weiterhin ein Schutz vor aggressiven Prozessen, die versuchen, ein Übermaß an Cursor-Ressourcen zu verbrauchen. Wenn Sie stattdessen die potenzielle Anzahl offener Cursors für eine Sitzung berechnen möchten, kann die folgende Formel, die auf dem Datenmodell Ihres Unternehmens beruht, als Richtlinie verwendet werden:

• Verschiedene ArcSDE-Datenmanagement-Cursor (20) +
• Verschiedene anonyme PL/SQL-Blocks (20) +
• Räumliche Abfragen – potenziell sechs pro Layer +
• Abfragen der Protokolldatei (11) +
• Sonstige Abfragen, die bei der Bearbeitung von mehrfach versionierten Tabellen verwendet werden – 12 pro mehrfach versionierter Tabelle oder Layer.

Eine ArcMap-Anwendung mit 10 Layern, die in dem Dokument bearbeitet werden, kann also bis zu 231 Cursor geöffnet haben (20 + 20 + 60 + 11 + 120 = 231). Wenn Sie feststellen, dass die Anzahl der Cursor häufig nicht ausreicht, können Sie den Wert des Parameters OPEN_CURSORS in Stufen von 50 oder 100 erhöhen.

Hinweis:

Oracle 10g ist so vorkonfiguriert, dass eine Serverwarnung ausgegeben wird, wenn die Anzahl der geöffneten Cursor für die Instanz höher als 1.200 liegt. Da 1.200 geöffnete Cursor nicht ungewöhnlich für eine Geodatabase sind, können Sie den Grenzwert für diese Warnung erhöhen, um unnötige Warnungen zu vermeiden.

Sie müssen allerdings unter Umständen den Wert des Parameters herabsetzen, wenn die Speicherressourcen des Servers, auf dem die Oracle-Instanz läuft, nicht über ausreichend Speicher für jeden Oracle-Prozess verfügt. Um herauszufinden, welche Speichergröße für einen Prozess notwendig ist, muss ein Prototyp der Anwendung erstellt werden. Mehrere Oracle-Parameter und das Verhalten der Anwendung, z. B. eine SQL-Anweisung, können die Speicheranforderungen für einen Prozess beeinflussen.

"SESSION_CACHED_CURSORS"

Die SQL-Anweisungen, die für jede Sitzung übermittelt werden, werden von Oracle überwacht. Wenn dabei festgestellt wird, dass dieselbe Anweisung mehrmals übermittelt wurde, wird die Anweisung in den Cursor-Cache verschoben und der Cursor für die folgende Wiederbenutzung offen gehalten. Der Parameter SESSION_CACHED_CURSORS kontrolliert die zugelassene Anzahl der Cursor im Cursor-Cache. Der Standardwert für SESSION_CACHED_CURSORS ist je nach Oracle-Version unterschiedlich. Wenn Ihre Instanz nicht so konfiguriert ist, dass mindestens 50 Cursor in den Cache aufgenommen werden können, sollten Sie den Wert dieses Parameters auf 50 erhöhen.

"UNDO_MANAGEMENT und UNDO_TABLESPACE"

Oracle speichert mehrere Kopien der Daten, die aktuell von einem Benutzer geändert werden. Während des Ausführens einer Transaktion, bei der Daten geändert werden, wird eine Kopie der ursprünglichen Daten verwendet, um eine lesekonsistente Ansicht der Datenbank für andere Sitzungen bereitzustellen. Außerdem könnten Benutzer, die Änderungen vornehmen, diese mit einer ROLLBACK-Anweisung rückgängig machen, oder der Prozess stürzt während der Transaktion ab, wodurch Oracle die zuletzt durchgeführten Arbeiten rückgängig machen müsste, um die Datenbank in einem konsistenten State wiederherzustellen.

Um jedes dieser Szenarien zu unterstützen, speichert Oracle die Daten vor der Bearbeitung in einer speziellen Datenstruktur, einem Undo-Segment oder einem Rollback-Segment. Sie können die Parameter "UNDO_MANAGEMENT" und "UNDO_TABLESPACE" so einstellen, dass Oracle automatisch Undo-Segmente erstellt und verwaltet. Um die automatische Speicherplatzverwaltung zu aktivieren, müssen Sie zunächst "UNDO_MANAGEMENT" auf automatisch einstellen. Als nächstes müssen Sie "UNDO_TABLESPACE" auf den Namen des Tablespace einstellen, in dem die vom System verwalteten Undo-Segmente gespeichert werden.

Beachten Sie, dass Sie keinen beliebigen Tablespace für die Speicherung systemverwalteter Undo-Segmente verwenden können. Sie müssen den Tablespace als Undo-Tablespace zur Zeit der Erstellung kennzeichnen. Weitere Informationen zur Überwachung und Verwaltung von automatischem Undo-Verhalten finden Sie im Oracle Database Administrator's Guide.

"SESSIONS"

Standardmäßig erlaubt die Konfiguration von ArcSDE 48 oder 64 gleichzeitige Verbindungen, je nach Betriebssystem. Wenn Sie die Data Dictionary-Tabelle "SDE.SERVER_CONFIG" so konfigurieren, dass eine größere Anzahl an Verbindungen ermöglicht wird, müssen Sie eventuell auch den Oracle-Parameter "SESSIONS" ändern, um die neue Einstellung einzubeziehen.

Der Parameter "SESSIONS" limitiert direkt die Gesamtanzahl gleichzeitiger Sitzungen in Oracle. Wenn die Standardeinstellung nicht für die erwartete Anzahl an ArcSDE-Verbindungen ausreicht, erhöhen Sie den Parameter auf die Anzahl der voraussichtlichen aktuellen Verbindungen plus mindestens 10 %, um interne Oracle-Funktionen zu unterstützen.

Hinweis:

Wenn Sie die Oracle Shared Server-Konfiguration verwenden, verhält sich der Parameter SHARED_SERVER_SESSIONS wie der oben erwähnte Parameter SESSIONS, mit der Ausnahme, dass er nur bei gemeinsam genutzten Serververbindungen angewendet wird. Alle Sitzungen – gemeinsam genutzter Server und separater Server – werden durch den allgemeineren Parameter "SESSIONS" begrenzt.

"PROCESSES"

Mit dem Parameter "PROCESSES" können Sie die Höchstzahl an Prozessen limitieren, die Oracle erstellen kann. Wenn sie einen separaten Server verwenden, entspricht dieser Prozess in etwa der Anzahl an gleichzeitigen Sitzungen, die von der Datenbank unterstützt werden. Wenn Sie die Anzahl der von ArcSDE zugelassenen Verbindungen erhöhen, stellen Sie sicher, dass der Parameter "PROCESSES" mindestens so hoch ist wie die Anzahl der ArcSDE-Verbindungen plus 25 für einen typischen Satz von Oracle-Hintergrundprozessen.

Parameter, die Oracle-Statistiken beeinflussen

"OPTIMIZER_MODE"

Ändern Sie den Standardwert für den Oracle-Parameter "OPTIMIZER_MODE" nicht. Für Oracle 10g und 11g lautet der Standardwert "all_rows". Dies ist für die meisten Geodatabases die beste Einstellung, und sie verbessert die Gesamtskalierbarkeit der Geodatabase.

Parameter, die den Speicher beeinflussen

Bei der Einstellung der Initialisierungsparameter, die den Speicher beeinflussen, muss vorsichtig vorgegangen werden. Wenn diese Parameter größer eingestellt werden als der verfügbare Speicherplatz des Host-Computers, wird die Leistung erheblich beeinträchtigt.

LOG_BUFFER

Der Protokollpuffer ist eine Komponente des System Global Area (SGA) von Oracle, die unbestätigte Änderungen an der Datenbank speichert, bis Oracle-Hintergrundprozesse die Möglichkeit haben, die Änderungen permanent auf der Festplatte zu speichern. Da diese Speicherungen häufig vorgenommen werden – mindestens alle drei Sekunden – benötigt der Protokollpuffer nicht viel Speicherplatz und kann auf weniger als ein Megabyte konfiguriert werden. Die Größe des Protokollpuffers zum Rückgängigmachen wird durch den ParameterLOG_BUFFER gesteuert. Die Standardgröße des Protokollpuffers ist ausreichend für die meisten Geodatabases. Jedoch kann bei Datenbanken mit einem hohen Grad an Schreibaktivität die Leistung beeinträchtigt werden, wenn verschiedene Benutzer gleichzeitig versuchen, auf den Protokollpuffer zuzugreifen. Um diesen Zustand zu erkennen und zu beheben, werden fortgeschrittene Fähigkeiten benötigt, wie das Überwachen von elektronischen Schaltern und Warteereignissen. Weitere Informationen erhalten Sie im Oracle Database Performance Tuning Guide und in der MetaLink Knowledge Base.

Hinweis:

Wenn Sie den Parameter LOG_BUFFER auf einen hohen Wert einstellen, um umfangreiche Ladetransaktionen durchzuführen, kann dies zu einer Verminderung der Performance führen. Es kann zwischen Transaktionen zum Konkurrenzbetrieb zwischen den elektronischen Schaltern kommen, wenn der Protokollpuffer zu hoch eingestellt ist.

SHARED_POOL_SIZE

Der gemeinsam genutzte Pool ist eine weitere Komponente des SGA von Oracle, die sowohl den Data Dictionary-Cache als auch den Bibliotheks-Cache enthält. Der Data Dictionary-Cache beinhaltet Informationen über Datenobjekte, freien Speicherplatz und Berechtigungen. Der Bibliotheks-Cache beinhaltet aktuell verarbeitete SQL-Anweisungen. Wenn der gemeinsam genutzte Pool groß genug für die Ressourcenanforderungen des Bibliotheks-Cache ist, ist er in der Regel auch groß genug für den Data Dictionary-Cache. ArcSDE-Geodatabases profitieren von einem größeren gemeinsamen Pool als andere Oracle-Anwendungen. ArcSDE behält einen Cache von SQL-Anweisungen, die durch Client-Anwendungen übermittelt wurden, im Speicher. Durch einen großen gemeinsamen Pool können mehr Cursor geöffnet bleiben, wodurch Verwaltungsabläufe für Cursor reduziert werden und die Performance verbessert wird. Die Größe des gemeinsamen Pools wird durch den Parameter SHARED_POOL_SIZE gesteuert. Esri empfiehlt, den Parameter "SHARED_POOL_SIZE" auf ein Mehrfaches von 16 MB einzustellen, um jedes von Esri unterstützte System einzubeziehen. Der Parameter sollte mindestens auf 128 MB eingestellt werden.

shared_pool_size = 128,000,000

Für hochaktive Geodatabases, die flüchtige Dienstprogramme oder Flurstückbearbeitungssysteme unterstützen, muss der Parameter "SHARED_POOL_SIZE" u. U. auf mehr als 250 MB gesetzt werden.

Der gemeinsame Pool ist der wichtigste der drei SGA-Puffer. Wenn der SGA bereits die maximale Größe in Anbetracht des verfügbaren Speicherplatzes erreicht hat, reduzieren Sie die Größe des Puffer-Cache, um einen größeren gemeinsamen Pool einzubeziehen.

DB_CACHE_SIZE

Der Puffer-Cache ist eine weitere Komponente des SGA von Oracle, in der die aktuell verwendeten Datenblöcke gespeichert werden. Datenblöcke sind die atomaren Einheiten des Datentransfers bei Oracle. Wenn der Benutzer die Datenbank bearbeitet oder eine Abfrage startet, werden von Oracle Datenblöcke gelesen bzw. geschrieben. Die Größe des Puffer-Caches wird durch den Parameter "DB_CACHE_SIZE" gesteuert.

Anders als beim gemeinsamen Pool und beim Protokollpuffer gibt es beim Puffer-Cache keine Empfehlungen für die Mindestgröße. Das Ziel bei der Größenbestimmung des Puffer-Caches sollte sein, so viel wie möglich von der Datenbank im Speicher zu behalten. Ordnen Sie daher den gesamten verbleibenden Speicher dem Puffer-Cache zu, nachdem Sie den Bedarf des restlichen Systems bestimmt haben. Befolgen Sie diese Schritte, um dies zu bestimmen:

1. Stellen Sie fest, wie groß der verfügbare Arbeitsspeicher (RAM) Ihres Servers ist.
2. Multiplizieren Sie diese Zahl mit 0,66, um die Zielgröße des SGA zu bestimmen.
3. Ziehen Sie "SHARED_POOL_SIZE" und "LOG_BUFFER" davon ab, und Sie erhalten den für den Puffer-Cache verfügbaren Speicher.
4. Reduzieren Sie diese Zahl um 10 %, um den internen Speicherbedarf von Oracle einzubeziehen.
5. Teilen Sie den Betrag durch die Blockgröße der Datenbank, um die Einstellung für "DB_BLOCK_BUFFERS" zu bestimmen.

Beispiel:

memory available to SGA = physical RAM * 2/3

memory available to buffer cache
= (memory available to SGA - (shared_pool_size + log_buffer)) * 0.9

db_block_buffers 

= memory available to buffer cache / db_block_size

PGA_AGGREGATE_TARGET

Weisen Sie dem Private Global Area (PGA) der Oracle-Serverprozesse Speicherplatz zu. Dieser Speicherplatz wird in der Regel als temporärer Puffer für das Sortieren und Zusammenführen von Daten während einer Tabellenverbindung verwendet. Stellen Sie WORKAREA_SIZE_POLICY auf AUTO ein, und setzen Sie dann PGA_AGGREGATE_TARGET zunächst auf den gesamten verfügbaren Arbeitsspeicher, multipliziert mit 0,16. Wenn die Anwendung eine Weile verwendet worden ist, gleichen Sie PGA_AGGREGATE_TARGET wie in der Dokumentation Oracle Performance Tuning Guide and Reference beschrieben an.

workarea_size_policy = auto
pga_aggregate_target = <total physical RAM * 0.16)

Hinweis:

Oracle verwendet PGA_AGGREGATE_TARGET nur dann zum Reservieren von Speicher für das Sortieren, wenn WORKSPACE_POLICY auf AUTO eingestellt ist. Wenn dies nicht der Fall ist, verwendet Oracle eine ältere, manuelle Methode, um den Sortierbereich zu verwalten. Hierzu müssen die Parameter SORT_AREA_SIZE und HASH_AREA_SIZE eingestellt werden.

Verwenden der automatischen Verwaltung des Arbeitsbereiches

Oracle kann, ähnlich wie bei der Verwaltung gemeinsamen Speichers mit ASMM (Automatic Shared Memory Management), nicht öffentlichen Speicher für die Serverprozesse verwalten, die automatisch für Benutzersitzungen verwendet werden. SQL-Arbeitsbereiche für Sortieren, Streuspeicherverfahren und Bitmap-Indexverarbeitung können von Oracle aus einem großen Speicherpool für alle PGAs dynamisch reserviert werden und müssen nicht mit einer bestimmten Größe durch den Datenbankadministrator (DBA) konfiguriert werden. Um die automatische Arbeitsbereichsverwaltung zu aktivieren, stellen Sie den Parameter WORKAREA_SIZE_POLICY auf AUTO ein. Konfigurieren Sie anschließend den gesamten verfügbaren Speicher zu allen PGAs, indem Sie die Größe als den Wert für den Parameter "PGA_AGGREGATE_TARGET" angeben. Standardmäßig konfiguriert Oracle die Gesamtgröße des PGA als 20 % der Größe des SGA. Dies ist ein guter Ausgangspunkt, allerdings sollte die Größe des PGA je nach Art der vom Serverprozess durchgeführten Arbeit festgelegt werden, nicht strikt relativ zur Größe des SGA. Sobald die Datenbank unter normaler Last arbeitet, können Sie die Größe des PGA-Zieles auf Grundlage der tatsächlichen Arbeitslast überwachen und abstimmen. Weitere Informationen über diesen Prozess finden Sie im Oracle Database Performance Tuning Guide.

Verwenden von ASMM (Automatic Shared Memory Management)

Wenn Sie Oracle 10g verwenden, können Sie eine Gesamtgröße für den SGA konfigurieren und Oracle erlauben, die Verteilung von Speicher an die einzelnen Pools automatisch zu verwalten. Dabei handelt es sich um ASMM, das über den Parameter SGA_TARGET aufgerufen wird. Durch die individuelle Konfiguration der Pools wird nicht nur die Arbeit des DBA erleichtert; die Verwendung von ASMM ermöglicht Oracle außerdem, den Bedarf jedes Pools ständig zu überwachen und die Größe dynamisch anzupassen, während die Instanz läuft. Ein DBA könnte diesen Grad der Kontrolle nicht durchgängig gewährleisten. Sie können ASMM unterstützen, indem Sie den Parameter "SGA_TARGET" auf die Gesamtgröße des SGA und mindestens einen Parameter für einzelne Pools konfigurieren. Wenn sowohl "SGA_TARGET" als auch eine Poolgröße angegeben werden, interpretiert Oracle die Poolgröße als Mindestgröße, die ASMM für diesen Cache beibehält.

Aufgrund der Bedeutung des gemeinsamen Pools für die Performance der Geodatabase sollten Sie bei der Verwendung von ASMM zusätzlich zur Einstellung von "SGA_TARGET" die Mindestgröße für den gemeinsamen Pool (den Initialisierungsparameter "SHARED_POOL_SIZE") wie empfohlen auf mindestens 128 MB einstellen.

Hinweis:

Für die automatische Verwaltung des Arbeitsbereichs und des gemeinsamen Speichers muss der Parameter STATISTICS_LEVEL auf TYPICAL (empfohlener Standardwert) oder ALL eingestellt werden.

Andere Änderungen

Obwohl UNDO_POOL, die Plan-Direktive des Database Resource Managers, kein Initialisierungsparameter ist, kann sie so eingerichtet werden, dass einer Verbrauchergruppe des Benutzers "sde" eine große Menge an Undo-Speicherplatz für Komprimierungsvorgänge zur Verfügung steht.

Dafür müssen Sie eine Verbrauchergruppe für den Benutzer "sde" einrichten und die Plan-Direktive UNDO_POOL so ändern, dass ein unbegrenzter Undo-Pool für diese Verbrauchergruppe zulässig ist.

Mit "UNDO_POOL" wird die Gesamtmenge von Undo-Speicherplatz bestimmt, die die Mitglieder einer Ressourcen-Gruppe gemeinsam gleichzeitig reservieren können.

Wenn Sie für die Bearbeitung eine mehrfach versionierte Geodatabase verwenden, müssen Sie regelmäßig eine Komprimierung durchführen, um alte Informationen zu entfernen und die Inhalte der Geodatabase zu vereinfachen. Wenn seit der letzten Komprimierung viele Änderungen vorgenommen wurden, können durch die erneute Komprimierung große Transaktionen erzeugt werden, die viel Undo-Speicherplatz benötigen. Wenn UNDO_POOL zu niedrig eingestellt ist, kann die Komprimierung fehlschlagen und die Performance verschlechtert werden. Stellen Sie möglichst einen unbegrenzten Undo-Pool für die Verbrauchergruppe des Benutzers "sde" ein. Andernfalls müssen Sie die Größe der Komprimierungstransaktionen überwachen und eine ausreichende Größe des Undo-Pools wählen.