Datenbank-Optimierung: Aspekte der 64-Bit-Architektur

Hauptabsatzmarkt für 64-Bit-Prozessoren sind IT-Abteilungen, welche die verbesserte RAM-Adressierung einer 64-Bit-Umgebung benötigen. Gewöhnlich nutzen große Oracle-OLTP-Abteilungen 2-GByte-SGA-Bereiche, die große Volumen kritischer Daten zwischenspeichern, um so den raschen Zugriff auf die Daten zu gewährleisten. Diese superschnellen RAM-Speicherbereiche werden jedoch nicht immer gebraucht.

Während Datenbank-Puffergrößen (db_cache_size) von 30 GByte für OLTP-Anwender oder IT-Abteilungen mit einem umfangreichen Working Set durchaus angebracht sind, bringt ein groß dimensioniertes SGA für Data Warehouses und Decision Support Systems (DSS) wenig, bei denen der Großteil des Datenzugriffs über einen Full-Table-Scan erfolgt. Hierbei ist zu beachten, dass beim Full-Table-Scan unter Oracle die Datenbankblöcke unter Umgehung des RAM-Datenpuffers direkt in die PGA (Program Global Area) gelesen werden.

Wie bereits erwähnt verfügen alle 64-Bit-Server über eine größere Wortlänge (2⁶⁴), die bis zu 18 Billionen Gigabyte (das sind 18 Exabyte) ermöglicht. So gesehen erscheint ein riesig dimensionierter RAM-Datenpuffer durchaus erstrebenswert. Die Nachteile von extra großen Datenbank-Puffern dürfen jedoch nicht unberücksichtigt bleiben. Während der direkte Zugriff auf die Daten per Hashing erfolgt, muss die Datenbank in bestimmten Fällen alle Blöcke im RAM-Cache durchsuchen:

• Systeme mit vielen ungültigen Bereichen: Wenn ein Programm eine abgeschnittene Tabelle erzeugt, temporäre Tabellen benutzt oder große Datenmengen bereinigt, muss Oracle alle Blöcke im Datenbank-Puffer (db_cache_size) löschen, um beschädigte Blöcke zu entfernen. Bei Systemen mit einer Datenbank-Puffergröße von über 10 GByte kann dies mit einem erheblichen Ressourcenbedarf verbunden sein.
• Systeme mit häufigen Updates: Bei der asynchronen Überschreibung bereinigt der Database Writer (DBWR) alle Datenblöcke aus dem Datenbank-Puffer. Durch eine sehr umfangreiche Datenbank-Puffergröße kann der DBWR übermäßig belastet werden.
• RAC-Systeme: Oracle9i RAC kommt mit extrem groß dimensionierten RAM-Datenpuffern nicht gut zurecht. Bei der Verwendung hoher Datenbank-Puffergrößen in mehreren RAC-Instanzen können vermehrt Cross-Instance-Calls auftreten. Dieses „Pinging“ zwischen den Instanzen kann zu einem erheblichen Overhead führen, weshalb RAC-Datenbank-Administratoren die RAC-Instanzen so zu isolieren versuchen, dass auf genau festgelegte Datenbankbereiche zugegriffen wird.

Weist ein System eine oder mehrere dieser Eigenschaften auf und soll dennoch eine große SGA verwendet werden, müssen bestimmte Operationen durchgeführt werden um die Belastung des RAM-Speichers während bestimmter Verarbeitungszeiten gering zu halten. In Systemen mit hohen Datenbereinigungsraten und abgeschnittenen Datenbereichen, in denen der Datenpufferspeicher vor Ausführung dieser Operationen heruntergesetzt werden kann, bereinigt man den Puffer (unter Oracle 10g) und legt anschließend die Größe der Datenpufferbereiche mithilfe des Codes in Listing A neu fest.

Bei großen Oracle-Anwendungen wie Oracle Application Server 10g (ehemals Oracle Application Server 10i) werden oftmals 32-Bit- und 64-Bit-Server gleichzeitig betrieben. So laufen beispielsweise die Back-End- und Infrastruktur-Datenbanken in einer 64-Bit-Umgebung, während HTTP-Server und Web-Cache-Server mit 32-Bit-Architektur arbeiten.