Neue Logiken im DWH Umfeld möchten erst einmal getestet werden. Um nicht nach mehreren Stunden Laufzeit festzustellen was schief gelaufen ist, macht es Sinn den neuen Algorithmus erst einmal an einem Subset von Daten auszuprobieren.
Die Einschränkung nach fachlichen Keys ist zumeist nicht sehr interessant. Nicht fortlaufende oder zusammengesetzte Primary Keys erschweren die Selektion darauf. Überhaupt würden vielleicht fortlaufende Nummern gar keinen repräsentativen Teil der Daten wiederspiegeln; die Daten für einen Test also gar nicht taugen.
Random:
Man kann nun auf verschiedene Varianten nach zufälligen Daten selektieren.
Die bekannteste Variante ist nach Rownum einzuschränken:
select object_id, object_name from all_objects where rownum <= 500;
Theoretisch könnten bei zwei wiederholten Aufrufen die Zeilen sich unterscheiden. In der Praxis kommen hier oft die gleichen Werte – aber auch darauf kann man sich nicht verlassen.
Mit dem Paket DBMS_RANDOM und einer Logik ähnlich der folgenden kann man immerhin sicherstellen, dass wenigstens bei jedem Aufruf unterschiedliche Mengen zurückgeliefert werden:
WITH input as ( SELECT round(dbms_random.value(0,100)) randr, object_id, object_name FROM all_objects ), step_1 as ( SELECT * FROM input WHERE mod(randr,8)=0 ) SELECT * FROM step_1 WHERE rownum <= 500;
Für einen Test einer Massendatenverarbeitung birgt dies aber auch Nachteile. Jeder Aufruf liefert andere Daten mit anderer Ausprägung zurück, weshalb sich Laufzeit oder Ressourcenverhalten zweier Durchläufe nur schwer vergleichen lassen. Es gilt also einen „zufälligen“ aber doch deterministischen Ausschnitt aus den Daten zu bestimmen.
Function ORA_HASH:
Für diese spezifische Anforderung lässt sich die Funktion ORA_HASH verwenden:
SELECT object_id, object_name FROM all_objects WHERE ORA_HASH(object_id, 16) = 1
Mithilfe dieser Funktion regelt Oracle intern die Verteilung von Daten auf einzelne Partitionen einer hash-partitionierten Tabelle. ORA_HASH(object_id, 16) = 1 schränkt auf alle Zeilen ein, die in eine gedachte erste Partition kommen würden; man erhält 1/16 der Daten. Wichtig dabei ist, dass die gehashte Spalte (hier via object_id) eine hohe Anzahl verschiedener Werte (niedrige Density) hat (z.B. ein Primary Key), da ansonsten die Verteilung auf die einzelnen gedachten Partitionen nicht gleichmässig erfolgen würde.
Das Ergebnis via ORA_HASH des obigen Selects stellt also gleichermassen einen „zufälligen“ als auch einen reproduzierbaren (auch über andere Maschinen hinweg!) Ausschnitt zum Test dar.
