Empfohlene Oracle-Parameter

Prozesse

Dieser Parameter legt das Limit für die Anzahl der Datenbankverbindungen fest. Sie müssen eine ausreichend hohe Anzahl auswählen, damit die kombinierten Verbindungsanforderungen der Anwendungsserver, Agenten usw. das Verbindungslimit in Zeiträumen mit hoher Verarbeitungsauslastung nicht überschreiten. Wenn Sie es überschreiten, müssen Sie die Oracle-Instanz neu starten, um dieses Limit zu erhöhen.

Glücklicherweise ist dank der Verwendung von Verbindungspooling in Anwendungsservern die Anzahl der Datenbankverbindungen geringer als die Anzahl der bei der Systemsoftware „ Sterling™ Order Management “ angemeldeten Benutzer. Je nach erwarteten Spitzenauslastungen beim Datenverkehr kann dieser Parameter von einer kleinen Zahl wie 25 bis hin zu einer großen Zahl im Tausenderbereich reichen.

Sie müssen die Anzahl der gleichzeitig bestehenden Verbindungen bei der Produktion (und insbesondere während der Auslastungsspitzen) regelmäßig überwachen, um sicherzustellen, dass der maximale Wert nicht erreicht wird. Wenn die maximale Sitzung erreicht wird, verweigert Oracle die Einrichtung neuer Verbindungsanforderungen.

Siehe Diskussionen zum WebLogic unter WebLogic.

Siehe WebSphere® in WebSphere.

Richtlinien zum Schätzen der Anzahl von Verbindungen.

Die Anzahl der von der Systemsoftware „ Sterling Order Management “ benötigten gleichzeitigen Benutzer können Sie mit der folgenden Formel grob schätzen:

Dabei gilt:

• A = Maximale Anzahl von Agenten-Transaktions-Threads, die gleichzeitig laufen (siehe Agenten-Thread-Ebenen).
• B = Maximale Verbindungspoolgröße für den Anwendungsserver multipliziert mit der Anzahl der Anwendungsserverinstanzen. Siehe Maximale Kapazität.
• C = Alle zusätzlichen Verbindungen, die durch angepassten Code oder Benutzerexits geöffnet werden und nicht den Verbindungspool der Anwendungsserver durchlaufen. Diese Verbindungsanforderung ist für Ihre Implementierung bestimmt.
• D = Anzahl asynchroner Adapter (Servicedefinitionsframework) multipliziert mit der Anzahl der Verbindungen pro Adapter.

Die Agenten und Monitore der Systemsoftware „ Sterling Order Management “ sind lang laufende Java™-Anwendungen, die pro Thread eine „ Oracle “-Verbindung öffnen und verwenden.

Beispiel: Angenommen, Sie planen ein System mit folgenden Merkmalen:

• Sechs Anwendungsserverinstanzen, von denen auf jeder bis zu 25 Transaktionen gleichzeitig ablaufen können.
• Zwölf Agententhreads.
• Vier asynchrone Adapter, von denen jeder bis zu vier Threads aufweisen kann.
• Maximal zehn Verbindungen für aktive Tools wie Oracle OEM oder Quest SpotLight.

Weiterhin wird angenommen, dass jede Transaktion auf dem Anwendungsserver nur eine Datenbankverbindung erfordert. Insbesondere Benutzerexits öffnen nicht ihre eigene Datenbankverbindung. Daher ist für obiges Beispiel Folgendes erforderlich:

• Im ungünstigsten Fall 25 x 6 oder 150 Datenbankverbindungen von den Anwendungsservern während der Auslastungsspitzen, wenn die Möglichkeit besteht, dass alle Anwendungsserver-Threads aktiv werden. Dies ist natürlich kein wünschenswerter Zustand. Sofern diese Möglichkeit besteht, sollten Sie weitere Anwendungsserverinstanzen konfigurieren.
• 12 Datenbankverbindungen für die Agenten/Überwachungsprogramme
• 4 x 4 oder 16 Datenbankverbindungen von den asynchronen Adaptern
• 10 Datenbankverbindungen von den aktiven Überwachungsprogrammen

Daher sollten Sie mindestens 150 + 12 + 16 + 10 oder 188 Datenbankverbindungen einplanen.

Es wird wie immer dringend empfohlen, dass Sie für Ihr System ein Benchmarking ausführen, um diese Voraussetzungen und Schätzwerte vor der Implementierung in eine Produktionsumgebung zu überprüfen. Während des Tests müssen Sie die Nutzungsstufen für den Verbindungspool in jeder der WebLogic-Serverinstanzen, die Anzahl der auszuführenden Agenten, die Ihren Verarbeitungs- und Servicezielen entsprechen, sowie die Anzahl der tatsächlich eingerichteten Oracle-Verbindungen überwachen.

Kompatibel

Sie sollten den Parameter compatible auf die vierstufige Releasenummer festlegen, mit der die Oracle-Software ausgeführt wird, um die neuesten Funktionen des Optimierungsprogramms zu nutzen. Ein Beispiel für diese Releasenummer ist 10.2.0.3 oder 11.2.0.1.

Sga_max_size, sga_target, pga_aggregate_target

Durch das Festlegen von sga_target in Oracle kann der Hauptspeicher im Globalbereich des Systems (SGA) durch die Speicherverwaltung des automatischen Speichers verwaltet werden. Sie können sga_target dynamisch bis zu dem Wert ändern, der durch sga_max_size angegeben wird.

Deshalb können Sie für sga_target einen Wert festlegen, der kleiner als oder gleich dem Wert von sga_max_size ist.

Cursor_sharing

Bei aktiviertem "cursor_sharing" konvertiert Oracle dynamisches (nicht wiederverwendbares) SQL in wiederverwendbares SQL, indem die Literalwerte in Bindevariablen geändert werden. Wenn die gemeinsame Cursornutzung aktiviert ist, werden Konflikte durch einen gemeinsam genutzten Pool- und Speicherarchivcache erheblich verringert.

Wenn "cursor_sharing" auf FORCE festgelegt ist, wird auch die adaptive gemeinsame Cursornutzung in Oracle aktiviert, die es dem Optimierungsprogramm gestattet, Bindevariablen anzuzeigen und optimale Ausführungspläne für Abfragen auszuwählen, die bindungsempfindlich sind.

Wenn Sie optimale Leistungen erreichen möchten, müssen Sie cursor_sharing=FORCE festlegen.

Optimizer_mode

Ab Oracle10g wird der Optimierungsprogrammmodus nicht mehr verwendet. Sie sollten für optimizer_mode den Standardwert ALL_ROWS festlegen.

Open_cursors

Dieser Parameter beschränkt die Anzahl der Cursor, die in einer Oracle-Sitzung jederzeit geöffnet sein können. Im Allgemeinen ist die Standardeinstellung ausreichend, es sei denn, Sie legen eine hohe Cache-Größe für vorbereitete Anweisungen fest (siehe „Prepared Statement Cache Size“ (Cache-Größe für vorbereitete Anweisungen) unter „ WebLogic “ (Verbindungspool: Datenquelle definieren ) in „ Sterling Order Management “ (Systemsoftware).

Führen Sie die folgende Abfrage aus, um die Anzahl der von Sitzungen geöffneten Cursor zu ermitteln:

select a.value, s.username, s.sid, s.serial# from v$sesstat a, v$statname b, 
v$session s where a.statistic# = b.statistic# and s.sid=a.sid and b.name = 
'opened cursors current'; 

Weitere Details zur Überwachung geöffneter Datenbankcursor finden Sie unter der MetaLink-Hinweis-ID 753605.1.

Max_async_ports, disk_asynch_io

Asynchrone Ein-/Ausgabe ist für die Leistung sehr wichtig, insbesondere in Verarbeitungsumgebungen mit hohen Transaktionsvolumen. Zusammengefasst müssen Prozesse, die synchrone read()- oder write()-E/A-Aufrufe ausführen, vor dem Fortfahren darauf warten, bis die Ein-/Ausgabe abgeschlossen ist. Im Gegensatz dazu können Prozesse mehrere asynchrone (nicht blockierende) aio_read()- oder aio_write()-E/A-Aufrufe parallel und ohne Wartezeiten ausführen.

Memory_target

In Oracle 11g geben die Parameter "memory_target" und "memory_max_target" die Speichermenge an, die von der automatischen Speicherverwaltung dynamisch zu PGA und SGA zugeordnet werden kann. Die automatische Speicherverwaltung kann SGA und PGA bei Bedarf bis zum Wert von "memory_target" verringern oder erhöhen. Sie können den Wert von "memory_target" nur in den Wert ändern, der in "memory_max_target" angegeben ist. Daher können Sie "memory_target" auf einen Wert festlegen, der kleiner als oder gleich dem Wert von "memory_max_target" ist.

Wenn "sga_target" und "pga_aggregate_target" ebenfalls festgelegt sind, verwendet die automatische Speicherverwaltung diese Werte als Mindestgröße für die entsprechenden Bereiche. Diese Werte müssen auf null festgelegt werden, damit Oracle den uneingeschränkten Zugriff auf die Speicherverwaltung hat.