Skip to Main Content

Breadcrumb

Datenbank I/O Calibration

Oracle Database 11g

Oracle IO Calibration

Seit Oracle 11g gibt es im Database Resource Manager das I/O Calibration Utility. Damit hat man die Möglichkeit die Höchstwerte für IOPS und MB/sec zu ermitteln.

set serveroutput on

declare
   l_latency integer;
   l_iops    integer;
   l_mbps    integer;
begin
   dbms_resource_manager.calibrate_io (
      10, /* # of disks */
      10, /* max latency */
      l_iops, /* I/O Ops/sec */
      l_mbps, /* MBytes/sec */
      l_latency /* actual latency */
   );

   dbms_output.put_line ('I/O Ops/sec = ' || l_iops);
   dbms_output.put_line ('Actual Latency = ' || l_latency);
   dbms_output.put_line ('MB/sec = ' || l_mbps);
end;
/

Sinnvolle Werte für I/O Calibration

Anzahl der Disken: Gemeint sind jene HDDs auf denen die Datenbankfiles liegen. Es geht nicht darum ganz exakt zu weissen wie viele Disken man wirklich hat, sondern um die Größenordnung. Wenn Sie statt 22 HDDs nur 20 oder vielleicht 25 angeben, wird am Ergebnis nichts ändern - Sie sollten aber nicht 50 oder 100 HDDs übergeben.

Maximale Latency: Der Wert muss größer sein als der zu erwartende Wert - die Untergrenze ist 10 (weniger nimmt die Procedure nicht an). Mehr wie 25 macht aber auch keinen sinn.

Voraussetzungen und Rahmenbedinungen

  • Damit die Messwerte korrekt sind, muss man die Instanz mit dem Parameter FILESYSTEMIO_OPTIONS=SETALL betreiben, oder die Datenbank liegt im ASM. Bei Oracle dNFS ist der Parameter empfohlen aber nicht zwingend.
  • Die Datenbank muss zumindest um eine 10er Potenz größer sein wie das CACHE in der Storage bzw. Infrastruktur (zB: IBM SVC,...)

Welche Werte kann/darf man erwarten

  • SAS Disken: 150-250 IOPS, 100-200 MBPS, 4-6ms Latency
  • SATA Disken: 50-150 IOPS, 70-150 MBPS, 8-12ms Latency
  • SSD: 30.000 - 150.000 IOPS, 250-1200 MBPS, <1ms Latency

Fallen bei der Nutzung und wie man diese sinnvoll nutzen kann

Wenn die Datenbank sehr klein ist (zb: nur die default Datenbank), dann misst man nicht die Performance der HDDs sondern die Performancedaten des Storage Caches! Das kann man optimal nutzen um die absoluten Limits der Infrastruktur kennen zu lernen (Anbindung/Bandbreite oder Storage selbst).

Damit man wirklich die HDD Performance kennenlernt, sollte die Datenbank mindestens 10 mal größer sein wie das in der Storage verfügbare Cache.

Es müssen keine Daten in der Datenbank sein, man braucht nur einen entsprechend größen Tablespace anzulegen.

Wenn man die AKTUELLE Performancedaten für eine Datenbank erheben möchte, so braucht man nichts davon beachten - allerdings sollte man immer im Hinterkopf haben, dass jeder weitere Server, jede weitere Datenbank die Performance beeinflusst.