Speicheroptimierung in Oracle

Nachstehend finden Sie einige allgemeine Regeln zur Konfiguration des System Global Area (SGA) von Oracle und zu den Speicherstrukturen, die die Größe des Private Global Area (PGA) eines Oracle-Benutzers beeinflussen. Beim SGA handelt es sich um einen Block gemeinsamen Speichers, den Oracle zuweist und für alle Sitzungen freigibt. Weitere Informationen zum SGA finden Sie im Oracle Concepts Guide für Ihre Oracle-Version.

• SGA darf nicht auslagern.

  Sie sollten keinen SGA mit einer Größe von über zwei Dritteln der Größe des verfügbaren Arbeitsspeichers (RAM) Ihres Servers erstellen. Ihr virtueller Speicher muss sowohl den SGA als auch die Anforderungen aller aktiven Prozesse auf dem Server aufnehmen können.

• Vermeiden Sie übermäßige Auslagerung.

  Verwenden Sie zur Überprüfung einer übermäßigen Auslagerung die Werkzeuge des Betriebssystems ("vmstat" unter UNIX und den Task-Manager unter Windows). Ein hohes Maß an Auslagerung kann durch einen zu großen SGA hervorgerufen werden.

• Konfigurieren Sie ausreichend virtuellen Speicher.

  Oracle empfiehlt, dass die Größe des Auslagerungsspeichers bei mindestens der drei- bis vierfachen Größe des verfügbaren Arbeitsspeichers liegen solle. Die erforderliche Größe der Swap-Datei (UNIX) bzw. der Auslagerungsdatei (Windows) hängt von der Anzahl der aktiven ArcSDE-Sitzungen ab. Für jede ArcSDE-Dienstsitzung (Anwendungsserver) werden ein gsrvr-Prozess und ein entsprechender Oracle-Prozess gestartet. Um die Speicherverwendung dieser Prozesse festzustellen, verwenden Sie den Befehl "ps –elf" auf UNIX-Systemen oder die Registerkarte "Prozesse" im Task-Manager von Windows. Sie müssen die Größe des SGA von Oracle vom Oracle-Benutzerprozess abziehen. Die Gesamtgröße der ArcSDE-gsrvr-, ArcSDE-giomgr-, Oracle-Benutzer-, Oracle-Hintergrund-, Betriebssystemprozesse und aller anderen laufenden Prozesse auf dem Server muss durch den virtuellen Speicher abgedeckt sein.

  Für ArcSDE-Client-Anwendungen mit direkter Verbindung zu einer Oracle-Instanz gibt es keinen gsrvr-Prozess. Wenn der ArcSDE-Dienst nicht verwendet wird, da alle Client-Anwendungen direkte Verbindungen zur Oracle-Instanz herstellen, wird auch der giomgr-Prozess nicht gestartet. Aus diesem Grund verbrauchen direkte Verbindungen weniger Speicherplatz auf dem Server, da es keine gsrvr-Prozesse gibt. Folgende Parameter wirken sich auf den Speicher aus: LOG_BUFFERSHARED_POOL_SIZE, DB_CACHE_SIZE, PGA_AGGREGATE_TARGET, SGA_TARGET und WORKAREA_SIZE_POLICY.

  Erläuterungen und Einstellungsvorschläge zu diesen Parametern finden Sie unter Oracle-Initialisierungsparameter.

• Verwenden Sie explizite Quota für Tablespaces, um zu verhindern, dass der gesamte verfügbare Speicherplatz aufgebraucht wird.

  Benutzer mit der Berechtigung, Oracle-Objekte zu erstellen, z. B. der Benutzer „SDE“, der Besitzer einer in einem Benutzerschema gespeicherten Geodatabase und Datenbesitzer können auf einem der zwei folgenden Wege auf den Speicherplatz zugreifen: durch den Besitz der Systemberechtigung UNLIMITED TABLESPACE oder durch den Erhalt eines expliziten Quotas für einen Tablespace.

  Mit der Berechtigung UNLIMITED TABLESPACE darf ein Benutzer eine unbegrenzte Speichermenge in allen Tablespaces in der Datenbank reservieren, einschließlich der von Oracle verwalteten Tablespaces SYSTEM und SYSAUX. Somit kann der Endbenutzer beabsichtigt oder unbeabsichtigt den verfügbaren Gesamtspeicherplatz belegen und sogar die Oracle-Instanz zum Absturz bringen. Aus diesem Grund sollte nur der Datenbankadministrator (DBA) über diese sehr umfangreiche Systemberechtigung verfügen.

  Sie sollten Benutzern, die keine Datenbankadministratoren sind, ein Quota auf einem oder mehreren Tablespaces zuweisen, damit diese Benutzer Oracle-Objekte kontrolliert erstellen können. Sie gewähren beispielsweise dem Besitzer der GIS_ADMIN-Daten ein Quota in den Tablespaces GIS_DATA und GIS_INDEX, aber nicht in den Tablespaces SYSTEM und SYSAUX. Auf diese Weise können Sie steuern, wo der Besitzer der Daten seine Tabelle und Indizes erstellen kann. Sie können auch festlegen, wie viel Speicherplatz diese Objekte belegen dürfen.

  Normalerweise weist der DBA ein unbegrenztes Quota oder kein Quota in jedem Tablespace für Projektinstanzadministratoren und Datenbesitzer zu. Auf diesem Weg steuert der DBA, wo die Daten gespeichert werden, z. B. auf einem gespiegelten Festplatten-Array für erhöhten Datenschutz, und er kann Daten in logische Container getrennt von Systemdaten und Daten für andere Projekte und Anwendungen aufteilen. Durch das unbegrenzte Quota kann der Datenbesitzer so viel Platz zuweisen, wie in den Tablespaces benötigt wird, auf die er Zugriff hat. Dies ist normalerweise die geeignete Vorgehensweise, da Benutzer mit Zugriff auf das Konto des Datenbesitzers normalerweise zusätzliche Schulungen erhalten haben oder über zusätzliche Kenntnisse verfügen und häufig mehr über die Speicheranforderungen ihrer eigenen GIS-Daten wissen als der Datenbankadministrator.

  In Umgebungen, in denen Benutzer mit der Berechtigung "Daten bearbeiten" oder "Daten lesen" ihre eigenen Geodatabase-Objekte erstellen dürfen, z. B. Ausgabe von Geoverarbeitungsvorgängen, können Sie ein begrenztes Quota in den Tablespaces zuweisen, auf die diese Benutzer Schreibzugriff haben. Im Tablespace GIS_DATA können Benutzer mit der Berechtigung "Daten lesen" beispielsweise ein Quota von 100 MB, Benutzer mit der Berechtigung "Daten bearbeiten" ein Quota von 500 MB und Datenbesitzer ein unbegrenztes Quota haben. Sie sollten Quota-Zuweisungen anpassen, um die besonderen Bedürfnisse der Daten- und Geschäftsprozesse zu erfüllen.