Zur Ausführung von ArcGIS 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 init.ora-Datei befindet sich im ORACLE_BASE/admin/<ORACLE_SID>/pfile-Verzeichnis bzw. -Ordner. "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 init.ora-Datei 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.
Es folgen einige Vorschläge für das Festlegen von Parametern beim Implementieren einer großen, vielbenutzten Geodatabase in Oracle.
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 in der Oracle Dokumentation für Ihre Oracle-Version.
OPEN_CURSORS
Der Oracle-Initialisierungsparameter "OPEN_CURSORS" legt die Anzahl von Cursorn 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 Cursorn bereits geöffnet ist, wird die Oracle-Fehlermeldung "-1000" ausgegeben. In ArcGIS bleiben zur Verbesserung der Performance häufig genutzte Cursor geöffnet. Wenn der Oracle-Parameter "OPEN_CURSORS" nicht hoch genug eingestellt ist, wird 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 Cursor für eine Sitzung berechnen möchten, kann die folgende Formel, basierend auf dem Datenmodell Ihres Unternehmens, als Richtlinie verwendet werden. Beachten Sie, dass ArcGIS 80 % der angegebenen Anzahl von geöffneten Cursorn öffnet, wodurch Oracle-Prozesse die anderen 20 % verwenden können.
- Verschiedene ArcGIS-Datenmanagement-Cursor (20) +
- Verschiedene anonyme PL/SQL-Blocks (20) +
- Räumliche Abfragen – potenziell sechs pro Feature-Class +
- Abfragen der Protokolldatei (11) +
- Sonstige Abfragen, die bei der Bearbeitung von versionierten Tabellen verwendet werden – 12 pro versionierter Tabelle oder Layer.
Wenn Sie also 10 Layer in ArcMap bearbeiten, sind möglicherweise 231 Cursor geöffnet (20 + 20 + 60 + 11 + 120 = 231). In diesem Fall ist die Einstellung "300 OPEN_CURSORS" ausreichend, da ArcGIS mit dieser Einstellung 240 Cursor geöffnet hält. Wenn Sie jedoch 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.
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.
SESSIONS
In der Geodatabase ist die Zulässigkeit einer unbegrenzten Anzahl von Verbindungen mit der Geodatabase konfiguriert. Wenn Sie eine große Anzahl gleichzeitiger Verbindungen mit der Geodatabase erwarten, empfiehlt es sich, den Oracle-Parameter SESSIONS entsprechend zu ändern.
Der Parameter "SESSIONS" limitiert direkt die Gesamtanzahl gleichzeitiger Sitzungen in Oracle. Wenn die Standardeinstellung nicht für die erwartete Anzahl an Geodatabase-Verbindungen ausreicht, erhöhen Sie den Parameter auf die Anzahl der voraussichtlichen aktuellen Verbindungen plus mindestens 10 %, um interne Oracle-Funktionen zu unterstützen.
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. Stellen Sie sicher, dass der Parameter PROCESSES mindestens so hoch ist wie die Anzahl der erwarteten gleichzeitigen Geodatabase-Verbindungen plus 25 für einen typischen Satz von Oracle-Hintergrundprozessen.
Parameter, die Oracle-Statistiken beeinflussen
OPTIMIZER_MODE
Ändern Sie den Standardwert (all_rows) für den Oracle-Parameter OPTIMIZER_MODE nicht. 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 Performance erheblich beeinträchtigt. Sie sollten den Datenbanken auf dem Server im Allgemeinen nicht mehr als 70 Prozent des physischen Speicherplatzes des Servers zuweisen.
SHARED_POOL_SIZE
Der gemeinsam genutzte Pool ist eine weitere Komponente des Oracle System Global Area (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.
Geodatabases profitieren von einem größeren gemeinsamen Pool als andere Oracle-Anwendungen. ArcGIS 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ücksbearbeitungssysteme 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.
Verwenden der automatischen Verwaltung des Arbeitsbereichs und des gemeinsamen Speichers
Sie sollten die von Oracle bereitgestellten Verfahren zur automatischen Verwaltung des Arbeitsbereichs und der Speicherzuweisung nutzen. Weitere Informationen zum Konfigurieren des Arbeitsbereichs und der Speicherverwaltung finden Sie im Oracle Database Administrator's Guide für die Version, die Sie verwenden.
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 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.