I/O-Durchsatzmessung mittels calibration unter Oracle 11g

von Frank Schneede, ORACLE Deutschland GmbH

Die Implementierung eines I/O Subsystems mit einem hohen Durchsatz ist ein integraler Bestandteil der Infrastruktur für eine zeitgemäße Applikation, sowohl im Datawarehouse- als auch im OLTP-Umfeld. Defizite im Design des Gesamtsystems wie zum Beispiel eine zu geringe Anzahl eingesetzter Festplatten oder eine nicht ausreichende Netzwerk-Bandbreite machen sich dann im laufenden Betrieb in Form schlechter Antwortzeiten unangenehm bemerkbar. Um den Kunden zur Vermeidung von Performanceengpässen eine Hilfe zu geben, hat Oracle vor einiger Zeit die Oracle Optimized Warehouse Initiative gestartet, die eine auf allen Ebenen der Systemlandschaft ausgewogene Architektur beschreibt. Diese Initiative hat im September letzten Jahres ihren bisherigen Höhepunkt in der Vorstellung der HP Oracle Database Machine gefunden, die auf den Prinzipien der well-balanced Architektur beruht. Diesen Idealzustand findet der DBA jedoch in historisch gewachsenen Umgebungen häufig nicht vor - vielmehr hat er für Anwenderklagen über mangelhafte Antwortzeiten Ursachen und Lösungen zu finden.

Der Prozeß der Problemlösung beginnt üblicherweise mit der Waitevent-Analyse eines AWR-Reports. Hierbei deutet sich durch erhöhte Werte für I/O-bezogene Wait-Events (Wait Class "User I/O" oder "System I/O") ein Engpass im I/O-Durchsatz an. Um diesen Ansatz weiterzuverfolgen, ist es notwendig, die maximale Rate der I/O Operationen der Datenbank zu messen, die diese zuverlässig bereitstellen kann. Diesen Vorgang nennt man calibration. Das Ziel einer calibration hängt natürlich auch von dem Lastprofil ab, mit der die Datenbank betrieben wird:

OLTP-Last: Fokus auf IOPS und Latenz
DWH-Last: Fokus auf I/O-Durchsatz

Dieser Community-Tipp zeigt die Möglichkeiten der calibration in der aktuellen Version von Oracle 11g auf. Damit können I/O-Engpässe in bestehenden Umgebungen aufgezeigt oder auch die I/O Spezifikation einer neuen Systemlandschaft verifiziert werden.

Dabei bieten sich folgende Ansätze zur Analyse des I/O Durchsatzes an, die am Ende dieses Tipps miteinander verglichen werden:

calibration mit Hilfe eines unabhängigen Utilities
calibration mit Hilfe der Oracle Datenbank

Bis zur Datenbankversion Oracle 10g war der DBA ausschließlich auf die Nutzung eines unabhängigen Utilities angewiesen, das für die eingesetzte Plattform und die Datenbankversion vorliegen und installiert werden muss. Über das Oracle Technology Network steht zu diesem Zweck das Tool ORION zum Download bereit. ORION erzeugt unabhängig von der Datenbank eine synthetische Last auf dem Speichersystem. Diese Last entspricht von der Charakteristik, also der Verteilung und Art der I/O Operationen sowie den genutzten Betriebssystemaufrufen einer Last, die durch eine laufende Oracle Datenbank erzeugt wird. Nach Durchführung der Messung hat der DBA einen Richtwert für den Durchsatz der Hardware. Die Messergebnisse können benutzt werden, um Fehlerquellen abseits der Datenbank auszuschließen oder eine neue Hardware auf deren Eignung hin zu überprüfen. ORION kann für zahlreiche Einsatzmöglichkeiten parametrisiert werden, an dieser Stelle soll nur ein kurzes Beispiel gezeigt werden.

Die zur Verfügung stehenden LUNs müssen in einem File angegeben werden, das den Namen des durchzuführenden Tests tragen muss. Anschließend wird der Test aufgerufen, wobei die Anzahl der benutzten Festplatten als Parameter angegeben wird:

C:\Program Files\Oracle\Orion>more mytest.lun
D:\ORADATA\SNA1111\SYSTEM01.DBF
D:\ORADATA\SNA1111\SYSAUX01.DBF
D:\ORADATA\SNA1111\UNDOTBS01.DBF
D:\ORADATA\SNA1111\USERS01.DBF

C:\Program Files\Oracle\Orion>orion -run simple -testname mytest -num_disks 1
ORION: ORacle IO Numbers -- Version 10.2.0.1.0
Test will take approximately 9 minutes
Larger caches may take longer


C:\Program Files\Oracle\Orion>

In diesem Test, der auf MS Windows Plattform stattfand, standen keine unterschiedlichen Volumes zur Verfügung, sinnvollerweise sollte hier auf physikalisch separate Festplatten zugegriffen werden.
Das Ergebnis ist dann in einer Datei zusammengefasst:

C:\Program Files\Oracle\Orion>more mytest_summary.txt
ORION VERSION 10.2.0.1.0

Commandline:
-run simple -testname mytest -num_disks 1

This maps to this test:
Test: mytest
Small IO size: 8 KB
Large IO size: 1024 KB
IO Types: Small Random IOs, Large Random IOs
Simulated Array Type: CONCAT
Write: 0%
Cache Size: Not Entered
Duration for each Data Point: 60 seconds
Small Columns:,      0
Large Columns:,      0,      1,      2
Total Data Points: 8

Name: D:\ORADATA\SNA1111\SYSTEM01.DBF   Size: 838868992
Name: D:\ORADATA\SNA1111\SYSAUX01.DBF   Size: 956506112
Name: D:\ORADATA\SNA1111\UNDOTBS01.DBF  Size: 907026432
Name: D:\ORADATA\SNA1111\USERS01.DBF    Size: 287973376
4 FILEs found.

Maximum Large MBPS=17.33 @ Small=0 and Large=2
Maximum Small IOPS=69 @ Small=2 and Large=0
Minimum Small Latency=14.52 @ Small=1 and Large=0

C:\Program Files\Oracle\Orion>

Zusätzlich werden noch weitere Ergebnisdateien (in diesem Beispiel: mytest_mbps.csv, mytest_iops.csv, mytest_lat.csv) erzeugt, die im csv-Format vorliegen und, nach erfolgter Bearbeitung in MS Excel, die Messungen visualisieren. Im hier dargestellten Beispiel wurde auf die Visualisierung verzichtet, da die Ergebnisse der Laborumgebung (Laptop, single disk) hierfür nicht geeignet sind.

Das Tool ORION steht auch für die aktuelle Datenbankversion Oracle 11g auf unterschiedlichen Betriebssystemen, zur Zeit jedoch nicht auf MS Windows Plattform, zur Verfügung. Für diesen Test wurde daher die Orion Version 10g verwendet.

Zu beachten:
ORION ist eine beta Software, die durch Oracle nicht unterstützt wird. Der Anwender ist also für Konsequenzen, die sich aus der Benutzung von ORION ergeben, selbst verantwortlich!

Eine bessere Alternative gibt es ab Oracle 11g auch innerhalb der Datenbank. Das Werkzeug zur calibration des I/O-Systems steht nun als Erweiterung des bewährten Database Resource Managers bereit. Die API DBMS_RESOURCE_MANAGER.CALIBRATE_IO() erzeugt eine gemischte read-only Last bestehend aus:

zufälligen I/Os in der Größe der parametrisierten db_block_size
sequentiellen I/Os mit 1MByte Blockgröße

Da die Prozedur CALIBRATE_IO() den Oracle Call-Stack nutzt und die I/O Operationen gegen Blöcke laufen, die in der Datenbank gespeichert sind, kann man die erzielten Messergebnisse als sehr realistisch für die tatsächlich erreichbare Performance ansehen. Da die calibration möglicherweise eine starke Belastung der Datenbank darstellt, ist es sinnvoll, diesen Vorgang zu Zeiten durchzuführen, an denen die Datenbank sehr gering ausgelastet ist. Zu beachten ist ebenfalls, dass Datenbanken, die auf den gleichen Speicher zugreifen und zum Zeitpunkt der calibration aktiv sind, das Messergebnis verfälschen können.

Um den die calibration mit dem Database Resource Manager nutzen zu können, müssen verschiedene Vorausetzungen eingehalten werden:

eingesetzte Datenbankversion >=11.1
aufrufender Benutzer hat SYSDBA-Privileg
asynchrones I/O ist aktiviert (DISC_ASYNCH_IO=TRUE und FILESYSTEMIO_OPTIONS=SETALL)
zum Zeitpunkt der calibration geringe Last auf der Datenbank

Der Initialisierungsparameter DISC_ASYNCH_IO ist bereits standardmäßig auf den Wert TRUE gesetzt, während der Standardwert für den Parameter FILESYSTEMIO_OPTIONS abhängig vom eingesetzten Betriebssystem automatisch auf den optimalen Wert für diese Plattform gesetzt wird. Im Zweifelsfall sollte an dieser Stelle die plattformspezifische Dokumentation zu Rate gezogen werden.

FILESYSTEMIO_OPTIONS kann folgende Werte annehmen:

asynch: Asynchronous I/O wird verwendet, wenn das OS das unterstützt.
directIO: Direct I/O wird verwendet, wenn das OS das unterstützt. Direct I/O umgeht den Unix buffer cache.
setall: Asynchronous und direct I/O wird aktiviert.
none: Deaktiviert asynchronous und direct I/O. Oracle benutzt normale synchronous writes ohne direct I/O Options.

Die Voraussetzungen lassen sich durch Abfrage des Data Dictionary verifizieren:

SQL> COLUMN name   FORMAT a35
SQL> COLUMN value  FORMAT a15
SQL> COLUMN asynch FORMAT a10
SQL>
SQL> SELECT name
     ,      value
     FROM   v$parameter
     WHERE name IN ('timed_statistics'
                   ,'filesystemio_options'
                   ,'disk_asynch_io');

NAME                                VALUE
----------------------------------- ---------------
timed_statistics                    TRUE
filesystemio_options                SETALL
disk_asynch_io                      TRUE

SQL>
SQL> SELECT f.name       NAME
     ,      i.asynch_io  ASYNCH
     FROM  v$datafile    f
     ,     v$iostat_file i
     WHERE f.file#         = i.file_no
     AND   i.filetype_name = 'Data File';

NAME                                ASYNCH
----------------------------------- ----------
D:\ORADATA\SNA1111\SYSTEM01.DBF     ASYNC_ON
D:\ORADATA\SNA1111\SYSAUX01.DBF     ASYNC_ON
D:\ORADATA\SNA1111\UNDOTBS01.DBF    ASYNC_ON
D:\ORADATA\SNA1111\USERS01.DBF      ASYNC_ON

SQL>

Anschließend wird die calibration durch Aufruf der API in einem kleinen PL/SQL-Block gestartet. Die API benötigt hierbei zwei Parameter als Eingabe:

NUM_DISKS: Dieses ist die Anzahl der Platten, die der Datenbank zur Verfügung stehen. Hier ist zu beachten, dass bei ASM-Nutzung lediglich die physikalischen Platten angegeben werden, die für Daten genutzt werden, Platten, die für eine Flash Recovery Area genutzt werden, müssen also ausgespart werden.
MAX_LATENCY: Hier ist die maximale Latenz in Millisekunden für einen Plattenzugriff einzutragen.

Mit diesen Informationen aufgerufen, erhält man nach kurzer Zeit das Ergebnis angezeigt:

SQL> SET SERVEROUTPUT ON
SQL> DECLARE
      lat  INTEGER;
      iops INTEGER;
      mbps INTEGER;
     BEGIN
      --DBMS_RESOURCE_MANAGER.CALIBRATE_IO(, , iops, mbps, lat);
      DBMS_RESOURCE_MANAGER.CALIBRATE_IO (1, 10, iops, mbps, lat);
      DBMS_OUTPUT.PUT_LINE ('max_iops = ' || iops);
      DBMS_OUTPUT.PUT_LINE ('latency  = ' || lat);
      DBMS_OUTPUT.PUT_LINE ('max_mbps = ' || mbps);
      END;
      /
max_iops = 69
latency  = 13
max_mbps = 16

PL/SQL-Prozedur erfolgreich abgeschlossen.

SQL>

Der Status der Messung wird in der View V$IO_CALIBRATION_STATUS festgehalten, dieses verschafft dem DBA auch während einer laufenden Messung einen Überblick. Nach Ende der calibration wird das Ergebnis in der Data Dictionary View DBA_RSRC_IO_CALIBRATE festgehalten und kann jederzeit abgefragt werden:

SQL> SELECT * FROM v$io_calibration_status;

STATUS        CALIBRATION_TIME
------------- ------------------------------------
IN PROGRESS   04.05.09 10:13:22,584

...

SQL> SELECT * FROM v$io_calibration_status;

STATUS        CALIBRATION_TIME
------------- ------------------------------------
READY         05.05.09 15:55:11,828


SQL> SELECT start_time
     ,      end_time
     ,      max_iops
     ,      max_mbps
     ,      latency
     ,      num_physical_disks
     FROM dba_rsrc_io_calibrate;

START_TIME                END_TIME                    MAX_IOPS   MAX_MBPS    LATENCY NUM_PHYSICAL_DISKS
------------------------- ------------------------- ---------- ---------- ---------- ------------------
05.05.09 15:51:08,031000  05.05.09 15:55:11,828000          69         16         13                  1


SQL>

Mit den beiden vorgestellten Methoden hat der DBA somit ein Portfolio, aus dem er das geeignete Utility auswählen kann. Zur Abgrenzung beider calibration Tools und als "Auswahlhilfe" soll zum Abschluß noch diese Aufstellung dienen:

	DBMS_RESOURCE_MANAGER.CALIBRATE_IO()	ORION
Pro	RAC-weite calibration möglich Verfügbar auf allen Plattformen volle Oracle-Unterstützung	Standalone Betrieb ohne Datenbank-Installation möglich
Contra	Nicht verfügbar in Releases vor 11g Benötigt eine laufende Datenbank	calibration eines RAC muß manuell durchgeführt werden Nicht verfügbar auf allen Plattformen nicht unterstützt von Oracle

Zusammengefasst lässt sich sagen, dass die Erweiterung des Database Resource Managers ein sehr wertvolles Tool darstellt, das hilft, die Einschränkungen der vorliegenden I/O Architektur zu verstehen. Nach Beendigung einer calibration verfügt der DBA über die Informationen, die notwendig sind, um die Größe und das Design des I/O Systems anforderungsgerecht zu gestalten.

Mehr zu diesem Thema bzw. zu weiteren Themen rund um die Datenbank lesen Sie in den nächsten Ausgaben ...

Zurück zur Community-Seite