Die schnellste Datenbank der Welt?

Transkript

1 Die schnellste Datenbank der Welt? IBM Informix Warehouse Accelerator Serbest Hammade Alkan Salan Dominik Schuhmacher Sascha Kroschewski Semesterprojekt Prof. Dr. Lothar Piepmeyer Hochschule Furtwangen Wintersemester 2011 /

2

3 i Zusammenfassung Relationale Datenbanksysteme verbringen oft einen erheblichen Teil Ihrer Laufzeit damit, auf die Ergebnisse von Ein- und Ausgabeoperationen von Festplatten zu warten. Einen anderen und wesentlich performanteren Ansatz verfolgen In-Memory-Datenbanken: Sie interagieren sehr selten mit der Festplatte und halten die Daten - wie der Name schon sagt - im Arbeitsspeicher vor. Zur Seite stehen diesen Systemen moderne Komprimierungstechniken und die Entwicklung kostengünstiger großer Speichermodule. So können teilweise gewaltige Datenmengen vorgehalten werden. Eines dieser Produkte - den Informix Warehouse Accelerator haben wir im Laufe des Semesterprojekts "Die schnellste Datenbank der Welt?" im Wintersemester 2011/2012 geleitet von Herrn Professor Doktor Lothar Piepmeyer an der Hochschule Furtwangen untersucht. Dieses Dokument gibt einen tiefen Einblick in das Datenbankmanagementsystem Informix R von IBM R, in den IBM R Informix Warehouse Accelerator R und in die von uns gesammelte Erfahrung bei der Leistungsprüfung von Datenbankmanagementsystemen mittels TPC-H TM Benchmarks.

4

5 Inhaltsverzeichnis Abstract i Inhaltsverzeichnis iii Abbildungsverzeichnis iii Tabellenverzeichnis iv 1. Einleitung 1 2. Das System Hardware Software Systemkonfiguration Verzeichnisse TPC-H Datengenerierung TPC-H und Informix Informix Konfiguration Optimierte Informix Instanz

6 5. Informix Warehouse Accelerator Installation Konfiguration Informix mit Accelerator verbinden Verbindung trennen Informationen über den Accelerator Marts verwalten Data Mart Definition Abfragen an den Accelerator Beispiel SQLite TPC-H und SQLite Scripte Datengenerierung Import der Daten in die Datenbanken Messscripte Probleme Informix Optimierte Informix Instanz Informix Warehouse Accelerator Vergleich der Messungen Messzeiten von Informix Messzeiten des Accelerators und Informix Messergebnisse von SQLite Fazit 37

7 Literaturverzeichnis 39 A. Anhang: Scripte 41 A.1. Tabellenerstellung A.2. Erstellung von Primärschlüssel A.3. Erstellung von Fremdschlüssel A.4. Import A.5. Konfiguration A.6. SQL-Abfragen

8

9 iii Abbildungsverzeichnis 3.1. Datenbankstruktur des TPC-H Benchmarks Messergebnisse Informix mit und ohne Primary-Keys Messergebnisse des Accelerators und optimierten Informix Messergebnisse von SQLite

10

11 iv Tabellenverzeichnis 2.1. Kernelparameterbeschreibung zu Shared Memory unter Linux Die wichtigsten Verzeichnisse Konfigurationsparameter von Informix Optimierte Konfigurationsparameter von Informix Konfigurationsparameter von conn.prop Java CLI - Marts verwalten USE_DWA-Flags

12 1. Einleitung 1 1. Einleitung Der IBM Informix Warehouse Accelerator erweitert Informix um den In-Memory- Ansatz. Sind die Daten von der Festplatte in den Zwischenspeicher geladen, sind komplexe Abfragen über hohe Datenmengen in nur wenigen Sekunden statt Minuten oder gar Stunden möglich. Es wird kein Tuning benötigt, Indexes und Statistiken fallen weg und Softwaresysteme, die die Datenbank nutzen, benötigen keine weiteren Änderungen. Das sind einige Vorteile, die IBM zum Informix Warehouse Accelerator nennt. Wir untersuchten mit den Benchmark-Tool TPC-H, wie schnell Informix die Abfragen in verschiedenen Konfigurationen verarbeitete. Dabei wurden bei gleicher Datenmenge drei unterschiedlich konfigurierte Informix-Instanzen genutzt. Die Erste Informix- Instanzen wurde nur grundlegend konfiguriert, die Zweite Informix-Instanzen wurde so weit optimiert, dass die Daten meist vom Zwischenspeicher gelesen wurden und die Dritte lief mit dem Informix Warehouse Accelerator. Zuletzt haben wir uns noch SQLite angeschaut und es mit den Informix-Instanzen verglichen.

13 1. Einleitung 2

14 2. Das System 2.1. Hardware Als Hardware stand uns ein Blade des Blade-Center der Fakultät Informatik in der Hochschule Furtwangen zu Verfügung: - CPU: Intel R Xeon R CPU 2.33GHz - RAM: 64 8x 8 GB DDR2 ECC - HDD: 500 GB 2.2. Software Als Betriebsystem haben wir Debian 5 (Lenny) mit dem Linux-Kernel gewählt. Wir wählten Debian 4 aufgrund seiner Stabilität und weil IBM Debian 5 in den Systemvoraussetzungen für den Informix Dynamic Server auflistet. [IBM11] Folgende Software wurde installiert: - IBM Informix Dynamic Server Version Datenbankmanagementsystem von IBM - IBM Informix Warehouse Accelerator Version 1.1 In-Memory-Modul, das die Performance von Informix massiv steigert. - TPC-H Version 2.14 Benchmark, der die Leistungsfähigkeit von Datenbankmanagementsystemen testet - sysstat Version Messung der Systemleistung für Linux - sar, iostat und mpstat - xterm Der Terminal-Emulator wird von dbaccess benötigt. dbaccess ist Teil von Informix

15 2. Das System Systemkonfiguration Informix nutzt in vielen Teilen seiner Speicherverwaltung Shared Memory (gemeinsam genutzter Speicher) um seine Daten im Zwischenspeicher zu speichern. Shared Memory ist eine Methode, damit mehrere Programme auf denselben Speicherbereich zugreifen können. Auch Linux beherrscht Shared Memory. Unter Linux sind es Kernelparameter, die den verfügbaren Shared Memory festlegen. Diese kann man nur mit root-rechten ändern. Kernelparameter SHMALL (kernel.shmall) SHMMIN (kernel.shmmin) SHMMAX (kernel.shmmax) SHMMNI (kernel.shmmni) PAGE_SIZE Beschreibung Gesamt verfügbarer Shared-Memory Pages im System Minimale Größe eines Shared-Memory-Segments Maximale Größe eines Shared-Memory-Segments Maximale Anzahl von Shared-Memory-Segmenten Größe einer Page, meist zwischen 1KB bis 4KB Tabelle 2.1.: Kernelparameterbeschreibung zu Shared Memory unter Linux SHMMAX steht für die maximale Größe eines gemeinsam genutzten Speichersegments in einem Linux-System, SHMALL steht dagegen für die maximale Zuordnung an Seiten gemeinsam genutzten Speichers in einem System. Es wird empfohlen, als Wert für SHMMAX die Gesamtmenge des physischen Hauptspeichers auf dem System anzugeben. Das erforderliche Minimum für 64-Bit-Systeme bei (1 GB).[SW 08] Die Kernelparameter können permanent über eine Änderung der Werte in /etc/sysctl.conf oder Temporär über die Dateien /proc/sys/kernel/shm* erreicht werden.

16 2. Das System Verzeichnisse Die folgende Tabelle gibt eine Übersicht der wichtigsten Verzeichnisse in unseren System. Verzeichnis /opt/ibm/informix /opt/ibm/iwa /home/informix oder ~/ /home/sqlite /home/informix/dbgen /home/informix/generieren /home/informix/instances /home/informix/messungen Beschreibung Installationsort für den Informix Dynamic Server Installationsort für den Informix Warehouse Accelerator Benutzerverzeichnis des Informix-Benutzers Benutzerverzeichnis des SQLite-Benutzers Verzeichnis für DBGen Scriptverzeichnis für das Generieren der Daten Speicherort für die Datenbankinstanzen von Informix Verzeichnis für alle Messungen an Informix Tabelle 2.2.: Die wichtigsten Verzeichnisse

17 2. Das System 6

18 3. TPC-H Der TPC-H testet die Leistungsfähigkeit von Datenbankmanagementsystemen aus dem Bereich der Entscheidungsunterstützungssysteme. Die Abfragen zu diesen Bereich sind meist sehr komplex und haben hohe Ausführungszeiten. Die Abbildung 3.1 verdeutlicht die Komplexität des TPC-H Benchmarks. DBGen ist Teil des TPC-H Benchmarks. Es generiert die Daten für die Datenbanken und legt diese in sogenannten.tbl-dateien ab. Für das kompilieren und ausführen von DBGen sind folgende Schritte notwendig: 1. Aktuelle Version von runterladen 2. Das Archiv entpacken 3. makefile.suite editieren: - CC = gcc - DATABASE = INFORMIX für Informix - DATABASE = SQLSERVER für SQLite - MACHINE = LINUX - WORKLOAD = TPCH 4. make -f makefile.suite ausführen DBGen kann dann mit ~/dbgen/dbgen -s X ausgeführt werden, wobei X für 1GB*Faktor steht Datengenerierung Folgendes Script erstellt ein Ordner $1gb/ in ~/dbgen/ und generiert $1 GB Daten. 1 #! / b i n / bash 2 cd ~ / dbgen 3. / dbgen s $1 4 mkdir p $1gb / 5 mv. t b l $1gb / data/generieren.sh

19 3. TPC-H 8 Abbildung 3.1.: Datenbankstruktur des TPC-H Benchmarks 3.2. TPC-H und Informix Die generierten Daten vom TPC-H Benchmark haben als Trennzeichen und als Datumsformat Damit Informix mit diesen Daten umgehen kann müssen zuvor die Umgebungsvariable DELIMIDENT auf und DBDATE auf y4mdgesetzt werden. Für das Einfügen der Daten in die Datenbank wurde der SQL-Befehl CREATE EXTERNAL TABLE benutzt. Das folgende Script importiert die Daten in die Datenbanken. Es löscht, falls vorhanden, die Datenbank $1, erstellt die Datenbank $1 und fügt die Daten aus Ordner ~/dbgen/$2gb/ in die Datenbank ein. Als letztes werden die Statistiken für die Datenbank erstellt. Sollen Primary-Keys erstellt werden muss als dritter Parameter eine 1 übergeben werden. Für die Foreign-Keys muss als vierter Parameter eine weitere

20 3. TPC-H 9 1 übergeben werden. Beispiel:./einfuegen.sh messungen_15gb ~/dbgen/15gb/ 1 1 erstellt die Datenbank messungen_15gb und fügt 15 GB Daten ein. 1 #! / b i n / bash 2 echo " drop d a t a b a s e " $1 d b a c c e s s 3 echo " c r e a t e d a t a b a s e " $1 d b a c c e s s 4 c a t d s s. d d l d b a c c e s s $1 5 f i l e s =" r e g i o n n a t i o n s u p p l i e r c u s t o m e r o r d e r s p a r t p a r t s u p p l i n e i t e m " 6 f o r t i n $ f i l e s 7 do 8 echo " Fuege Daten aus D a t e i $ t e i n " 9 echo "CREATE EXTERNAL TABLE ${ t } e x t SAMEAS $ t USING ( DATAFILES ( DISK : $2 / ${ t }. t b l ) ) ; " d b a c c e s s $1 10 echo "INSERT INTO $ t SELECT FROM ${ t } e x t " d b a c c e s s $1 11 done 12 i f [ [ " $3 " =~ ^[0 9]+ $ ] ] ; then 13 i f [ " $3 " eq " 1 " ] ; then 14 echo " Fuege Primary Keys e i n " 15 c a t pk. r i d b a c c e s s $1 16 f i 17 i f [ [ " $4 " =~ ^[0 9]+ $ ] ] ; then 18 i f [ " $4 " eq " 1 " ] ; then 19 echo " Fuege Foreign Keys e i n " 20 c a t fk. r i d b a c c e s s $1 21 f i 22 f i 23 f i 24 echo " F e r t i g... Beginne mit u p d a t e s t a t i s t i c s high " 25 echo " u p d a t e s t a t i s t i c s high " d b a c c e s s $1 data/einfuegen.sh Weitere wichtige Dateien für das erstellen der Tabellenstruktur, der Primary- und Foreign- Keys sind im Anhang A.1, A.2 und A.3 zu finden.

21 3. TPC-H 10

22 4. Informix Informix wurde in der Version installiert. Dabei wurde die Installation nach Eric Herber [Her08] durchgeführt.. Das folgende Script erstellt alle benötigte Ordnerstruktur und Dateien, die die Installationsroutine von IBM nicht erstellt. Als Argument $1 benötigt es ein Namen für die Instanz. Der Name unserer Instanz lautete gepard. 1 # / b i n / bash 2 export SERVER=/ home / i n f o r m i x / i n s t a n c e s / $1 3 mkdir p $SERVER / l o g s 4 mkdir p $SERVER / d a t a 5 mkdir p $SERVER / backups / d b s p a c e s 6 mkdir p $SERVER / backups / l o g s 7 8 chmod 755 $SERVER / l o g s 9 chmod 700 $SERVER / d a t a 10 chmod 700 $SERVER / backups / t o u c h $SERVER / d a t a / r o o t d b s. chk1 13 chmod 660 $SERVER / d a t a / r o o t d b s. chk t o u c h $SERVER / d a t a / tempdbs. chk1 16 chmod 660 $SERVER / d a t a / tempdbs. chk1 17 o n s p a c e s c d tempdbs t p $SERVER / d a t a / tempdbs. chk1 o 0 s cd $SERVER / d a t a / 20 o n i n i t i v data/adddb.sh Für die Benutzerfreundlichkeit wurde die Shell zsh installiert und die ~/.zshrc um folgende Einträge erweitert: 1 export INFORMIXSERVER= g epard 2 export INFORMIXDIR=" / o p t / IBM / i n f o r m i x " 3 export ONCONFIG= o n c o n f i g. $INFORMIXSERVER 4 export INFORMIXSQLHOSTS=$INFORMIXDIR / e t c / s q l h o s t s. $INFORMIXSERVER 5 e x p o r t LD_LIBRARY_PATH=$LD_LIBRARY_PATH : $INFORMIXDIR / l i b 6 export LD_LIBRARY_PATH=$LD_LIBRARY_PATH : $INFORMIXDIR / l i b / e s q l 7 export PATH=${INFORMIXDIR } / b i n : ${PATH} 8 export GEPARD=/ home / i n f o r m i x / i n s t a n c e s / $INFORMIXSERVER

23 4. Informix 12 9 export TERMCAP=$INFORMIXDIR / e t c / termcap 10 export INFORMIXTERM= termcap data/zshrc.conf Zum starten und stoppen des Informix Dynamic Server sind zudem zwei weitere Scripte erstellt worden: 1 #! / b i n / bash 2 cd $GEPARD/ d a t a 3 o n i n i t v 1 #! / b i n / bash 2 onmode yuk 4.1. Konfiguration data/startinformix.sh data/stopinformix.sh Unsere Standardkonfiguration ist im Anhang A.3 zu finden. Die Tabelle zeigt eine Liste der veränderten Variablen und ihre Bedeutung Konfigurationsparameter Wert Beschreibung ROOTPATH./rootdbs.chk1 Ort des rootdbs-dbspaces ROOTSIZE Die Größe des rootdbs-dbspaces in KB DBSERVERNAME gepard Die Größe des rootdbs-dbspaces in KB NETTYPE soctcp,1,32,net Anzahl Threads für Verbindungen über TCP/IP NETTYPE ipcshm,1,32,cpu Anzahl Threads für Verbindungen über SHM MULTIPROCESSOR 1 Nutzung von mehreren CPU-Kernen VPCLASS cpu,num=4,noage Anzahl der genutzten CPU-Kerne Tabelle 4.1.: Konfigurationsparameter von Informix

24 4. Informix Optimierte Informix Instanz In der optimierten Informix Instanz sollte Informix im normalen Betrieb während der endgültigen Abfragen nicht von der Festplatte lesen sondern vom Zwischenspeicher. Lesen sollte Informix nur beim Warmup der Datenbank. Beim Warmup wurden alle Daten jeder Tabellen mehrmals abgefragt, sodass Informix diese Daten in den Zwischenspeicher holte. Dies erreichen wir indem wir Informix ermöglichen Shared Memory zu nutzen. Konfigurationsparameter Wert Beschreibung SHMVIRTSIZE anfängliche Größe eines virtuellen SHM-Segments BUFFERPOOL s.u. Konfiguration des Bufferpools Tabelle 4.2.: Optimierte Konfigurationsparameter von Informix BUFFERPOOL default,buffers= ,lrus=8,lru_min_dirty= , lru_max_dirty= Das Argument buffers der Variable BUFFERPOOL gibt die Anzahl der PAGESIZE an, die von Informix zur Datenhaltung im Zwischenspeicher genutzt werden kann. In unseren Fall also *4096 = 76 GB. Das wir nur 64 GB RAM besitzt ist in unseren Fall uninteressant. Damit Informix die Daten im Zwischenspeicher hält müssen alle Daten zuerst abgefragt werden. Unsere Messungen ergaben, das über 90% der Daten gecacht werden. Dazu später in den Messergebnissen mehr. Um Informix weiter zu optimieren wurden fragmentierte Tabellen mit der Round-Robin-Methode eingesetzt.

25 4. Informix 14

26 5. Informix Warehouse Accelerator Das folgende Kapitel soll zeigen wie der Informix Warehouse Accelerator für Abfragen konfiguriert werden muss. Eine Beschreibung wie der Informix Warehouse Accelerator arbeitet erläutert das Dokument "IBM Informix Warehouse Accelerator - Performance is everything" [Mur11] und eine Vielzahl von Blogeinträgen auf planetids.com [inf11]. Unsere Accelerator-Instanz nannten wir HFU und den Data Mart hfumart 5.1. Installation Der Informix Warehouse Accelerator wurde in der Version 1.1 ins Verzeichnis /opt/ibm/iwa/ installiert. Es gibt zwei Varianten den Informix Warehouse Accelerator zu konfigurieren. Das IBM Smart Analytics Optimizer Studio ist ein auf der Entwicklungsumgebung Eclipse aufbauendes Tool zur grafischen Einrichtung des Informix Warehouse Accelerator. Die Java CLI (Command Line Interface) lässt die Einrichtung über die Konsole zu und kann direkt auf dem Server benutzt werden. Wir nutzten die Variante mit der Java CLI, da somit sämtliche Vorgänge auf unseren Server gesteuert werden konnte. Damit der Informix Warehouse Accelerator über die Java CLI eingerichtet werden kann, müssen die Variablen CLASSPATH und PATH vom Benutzer root erweitert werden. export CLASSPATH=.:/opt/IBM/iwa/dwa/example/cli/dwacli.jar export PATH=$INFORMIXDIR/extend/krakatoa/jre/bin:$PATH Damit die Java CLI weiß mit welcher Datenbank sie sich Verbinden soll, muss die Datei conn.prop erstellt werden. 1 d r i v e r =com. i n f o r m i x. j d b c. I f x D r i v e r 2 URL= j d b c : i n f o r m i x s q l i : / / [ HOST ] : [ PORT ] / [ DB ] : INFORMIXSERVER=[SQLSERVERNAME] 3 u s e r =[INFORMIXUSER] 4 passwd =[PASSWORD] data/conn.prop

27 5. Informix Warehouse Accelerator 16 Variable Unsere Einstellung [HOST] informix.informatik.hs-furtwangen.de [PORT] 9088 [DB] z.b. messung_15gb [SQLSERVERNAME] gepard [INFORMIXUSER] informix [PASSWORD]... Tabelle 5.1.: Konfigurationsparameter von conn.prop 5.2. Konfiguration Die Konfiguration vom Informix Warehouse Accelerator ist über die Datei dwainst.conf im Ordner /opt/ibm/iwa/dwa/etc vorzunehmen. 1 # DWA s t o r a g e d i r e c t o r y 2 # S t o r e s t h e c a t a l o g, marts, logs, t r a c e s e t c. 3 DWADIR=/ o p t / IBM / iwa / dwa / t e s t 4 5 # S t a r t i n g p o r t number 6 # Grows t o START_PORT 1+DEFAULT_NUMBER_ENTITLED_NODES 4. 7 START_PORT= # Number o f DWA_CM p r o c e s s e s 10 NUM_NODES= # Worker s h a r e d memory 13 # SHM ( i n Megabyte ) f o r a l l worker nodes. 14 # Minimum v a l u e i s 1 p e r c e n t o f p h y s i c a l memory. 15 WORKER_SHM= # C o o r d i n a t o r s h a r e d memory 18 # SHM ( i n Megabyte ) f o r a l l c o o r d i n a t o r nodes. 19 # Minimum v a l u e i s 1 p e r c e n t o f p h y s i c a l memory. 20 #COORDINATOR_SHM= COORDINATOR_SHM= # DRDA network i n t e r f a c e 24 # For r u n n i n g t h e a c c e l e r a t o r on a s e p a r a t e computer ask t h e s y s t e m 25 # a d m i n i s t r a t o r f o r t h e network i n t e r f a c e ( e. g. e t h 0 ) t h a t t h e I n f o r m i x 26 # d a t a b a s e s e r v e r s h o u l d c o n n e c t t o or run t h e i f c o n f i g command t o f i n d t h e 27 # network i n t e r f a c e. 28 DRDA_INTERFACE= l o data/dwainst.conf

28 5. Informix Warehouse Accelerator Informix mit Accelerator verbinden Um den IWA für eine Informix Instanz einzurichten gibt es folgenden Befehl: java setupdwa HFUDWA ondwa getpin Sobald die Informix Instanz sich mit den Accelerator verbunden hat, gibt ondwa status bei Cluster is in state: Fully Operational zurück. Zusätzlich ist in der $INFORMIXSQLHOST-Datei zwei Einträge der Form 1 gepard o n s o c t c p i n f o r m i x i d s _ g e p a r d 2 HFU group c =1, a =685 b a d416c397a3b62474d32 3 HFU_1 dwsoctcp g=hfu vorhanden Verbindung trennen data/sqlhosts.gepard Um die Verbindung zwischen Informix und IWA zu trennen gibt es den Befehl java removedwa HFU. Der Eintrag in der $INFORMIXSQLHOST-Datei und die Systemtabellen zum Accelerator sollten dann gelöscht sein. Überprüfen kann man dies wie oben schon gezeigt über ondwa status.

29 5. Informix Warehouse Accelerator Informationen über den Accelerator Der Befehl java displayaccel HFU gibt Statistiken über die Anzahl der ausgeführten Queries, Speicherverbrauch und Status zurück: 1 2 a c c e l e r a t o r s t a t i s t i c s : 3 ACCELERATOR MEMB STATUS REQUESTS QUED MAXQ FAIL 4 5 HFU IDS STARTED PORT= IPADDR = ??????? 8 DETAIL STATISTICS 9 LEVEL =????? 10 STATUS = FULLY OPERATIONAL 11 AVERAGE QUEUE WAIT = 0 12 MAXIMUM QUEUE WAIT = 0 13 PROCESSING CAPACITY = TOTAL NUMBER OF PROCESSORS = AVERAGE CPU UTILIZATION ON COORDINATOR NODES = 0.11% 16 NUMBER OF ACTIVE COORDINATOR NODES = 1 17 PHYSICAL MEMORY AVAILABLE ON COORDINATOR NODES = MB 18 PHYSICAL MEMORY AVERAGE USAGE ON COORDINATOR NODES = MB 19 AVERAGE CPU UTILIZATION ON WORKER NODES = 0.14% 20 NUMBER OF ACTIVE WORKER NODES = 3 21 PHYSICAL MEMORY AVAILABLE ON WORKER NODES = MB 22 PHYSICAL MEMORY AVERAGE USAGE ON WORKER NODES = MB 23 SHARED MEMORY DATA AVAILABLE ON WORKER NODES = 4770 MB 24 SHARED MEMORY DATA AVERAGE USAGE ON WORKER NODES = 5399 MB 25 MAXIMUM SHARED MEMORY DATA IN USE ON WORKER NODES = 5401 MB 26 ================================================================== data/displayaccelerator.log Zeile 3-4 zeigt an wie viel ausgeführte Queries ausgeführt wurden. Außerdem werden der Status und die Systemauslastung durch den Accelerator angezeigt.

30 5. Informix Warehouse Accelerator Marts verwalten Listen Hinzufügen Löschen Laden Informationen Aktivieren/Deaktivieren java listmarts [IWANAME] java createmart [IWANAME] file.xml java dropmart [IWANAME] [MARTNAME] java loadmart [IWANAME] [MARTNAME] none java getmartinfo [IWANAME] [MARTNAME] java setmart [IWANAME] [MARTNAME] [ON OFF] 5.7. Data Mart Definition Tabelle 5.2.: Java CLI - Marts verwalten Die Struktur eines Marts kann über das Studio bestimmt werden. Das Studio bietet dafür eine Grafische Über die Export-Funktion kann das Studio die Struktur im XML- Format exportieren. Ist diese XML-Datei auf den Server geladen kann man über den Befehl Mart Hinzufügen die Struktur angelegt werden. Bei einer Abfrage wird dann vom Accelerator überprüft ob der Query die Struktur einhält. Unsere Data Mart Definition ist im Anhang A.5 zu finden Abfragen an den Accelerator Der von uns definierte Data Mart lässt nur die Abfragen 1, 3, 6, 10 und 12 der TPC-H- Queries zu. Die Abfragen sind im Anhang auf Seite 48 zu finden. Die Variable USE_DWA bestimmt wie der Accelerator benutzt werden soll. Dabei wird die Variable nicht als Integer gewertet sondern als Verknüpfungen von Binären Flags. Flag Name Beschreibung 0 ON Schaltet die Benutzung vom Accelerator an oder aus 1 DEBUG Schreibt Queryinformationen in online.log 2 NO_FALLBACK Abfrage schlägt fehl, wenn der Accelerator sie nicht bearbeitet 3 BINARY_SQLMINUS Schreibt generierte SQL-Queries in eine Datei Tabelle 5.3.: USE_DWA-Flags Da wir den Accelerator mit Debugfunktion und ohne Fallback benutzen wollen setzen wir USE_DWA auf 7. Die einfachste möglichkeiten ist USE_DWA im SQL-Script über SET ENVIRONMENT USE_DWA 7 ; zu setzen. Die einfachste Möglichkeit festzustellen ob die Abfrage vom Accelerator bearbeitet wird sind Explain-Dateien. Ohne Accelerator:

31 5. Informix Warehouse Accelerator 20 1 QUERY: ( OPTIMIZATION TIMESTAMP: : 5 6 : 4 0 ) Maximum Threads : 8 4 Temporary F i l e s R e q u i r e d For : Order By Group By 5 6 1) i n f o r m i x. o r d e r s : SEQUENTIAL SCAN 7 8 F i l t e r s : i n f o r m i x. o r d e r s. o _ o r d e r d a t e < Mit Accelerator: data/informixexplain.log 1 QUERY: DWA e x e c u t e d : ( OPTIMIZATION TIMESTAMP: : 4 9 : 3 8 ) Maximum Threads : ) messungen_15gb@hfu : dwa. aqt0fe888b1 0f16 450f af e508f : REMOTE PATH 6 7 Remote SQL Request : 8 {QUERY {FROM dwa. aqt0fe888b1 0f16 450f af e508f } {WHER 9 E ( ( ( ( { = COL60 " 819 AUTOMOBILE" } {ISNOTNULL COL54 } ) {ISNOTNULL 10 COL04 } ) {< COL08 {DATE " " } } ) {> COL48 {DATE " " } } ) } {SELECT {SYSCAST COL38 AS INTEGER NOTNULLA 12 BLE} {SUM { COL43 { COL44 } } } {SYSCAST COL08 AS DATE NO 13 TNULLABLE} {SYSCAST COL11 AS INTEGER NOTNULLABLE} } {GROUP COL38 14 COL08 COL11 } {ORDER {SUM { COL43 { COL44 } } } DESC N 15 ULLSFIRST COL08 ASC NULLSFIRST } {NUMROWS 10 } } QUERY: IDS FYI : ( OPTIMIZATION TIMESTAMP: : 4 9 : 3 8 ) s e l e c t f i r s t l _ o r d e r k e y, 21 sum ( l _ e x t e n d e d p r i c e (1 l _ d i s c o u n t ) ) as revenue, 22 o _ o r d e r d a t e, 23 o _ s h i p p r i o r i t y data/acceleratorexplain.log

32 5. Informix Warehouse Accelerator Beispiel Folgende Schritte sind notwendig damit der Accelerator seine Funktion aufnimmt. - Informix Dynamic Server starten, siehe benutzen um Daten zu generieren benutzen um Daten in eine Informix Datenbank zu importieren - Die Primary-Keys in die Datenbank einfügen, siehe A.2 - BUFFERPOOL auf Standardgröße setzen - als root-benutzer ondwa start ausführen um den Accelerator zu starten - als root-benutzer ondwa start ein Mart erstellen - als root-benutzer ondwa start ein Mart laden - eine Abfrage (siehe A.6) über die Messscripte 7.3 ausführen

33 5. Informix Warehouse Accelerator 22

34 6. SQLite SQLite ist eine Open Source Bibliothek, die ein relationales Datenbanksystem zur Verfügung stellt. Dabei ist kein zusätzlicher Server notwendig. Außerdem erlaubt SQLite auch den In-Memory Ansatz. Installiert wird SQLite durch den Befehl apt-get install sqlite TPC-H und SQLite Zuerst sind die in 3 beschrieben Punkte abzuarbeiten. Die Datenbank kann nun über den Befehl sqlite -init dss.ddl database.db erstellt werden. Damit die Daten importiert werden können, müssen diese zuerst formatiert werden. Dafür kann der Befehl sed -in-place= -e s/ // file benutzt werden. Folgendes Script formatiert die Daten und importiert diese in die Datenbank. 1 #! / b i n / bash 2 f o r f i l e i n. t b l ; 3 do 4 sed in p l a c e = e s / $ / / $ f i l e ; 5 s q l i t e 3 d a t a b a s e. db ". i m p o r t $f $ ( basename $f. t b l ) " ; 6 done data/importsqlite.sh Soll SQLite den In-Memory-Ansatz benutzt wird als Datenbank :memory: statt database.db verwendet.

35 6. SQLite 24

36 7. Scripte Folgende Scripte sind zur Datengenerierung, Import der Daten in die Datenbanken und für die Messungen, die durchgeführt wurden. $1, $2, $x sind das x-ste Argument eines Scripts Datengenerierung Folgendes Script erstellt ein Ordner /dbgen/$1gb/ und generiert $1 GB Daten. 1 #! / b i n / bash 2 cd ~ / dbgen 3. / dbgen s $1 4 mkdir p $1gb / 5 mv. t b l $1gb / data/generieren.sh 7.2. Import der Daten in die Datenbanken Folgendes Script löscht, falls vorhanden, die Datenbank $1, erstellt die Datenbank $1 und fügt die Daten aus Ordner /dbgen/$2gb/ in die Datenbank ein. Als letztes werden die Statistiken für die Datenbank erstellt. 1 #! / b i n / bash 2 echo " drop d a t a b a s e " $1 d b a c c e s s 3 echo " c r e a t e d a t a b a s e " $1 d b a c c e s s 4 c a t d s s. d d l d b a c c e s s $1 5 f i l e s =" r e g i o n n a t i o n s u p p l i e r c u s t o m e r o r d e r s p a r t p a r t s u p p l i n e i t e m " 6 f o r t i n $ f i l e s 7 do 8 echo " Fuege Daten aus D a t e i $ t e i n " 9 echo "CREATE EXTERNAL TABLE ${ t } e x t SAMEAS $ t USING ( DATAFILES ( DISK : $2 / ${ t }. t b l ) ) ; " d b a c c e s s $1 10 echo "INSERT INTO $ t SELECT FROM ${ t } e x t " d b a c c e s s $1 11 done 12 i f [ [ " $3 " =~ ^[0 9]+ $ ] ] ; then 13 i f [ " $3 " eq " 1 " ] ; then 14 echo " Fuege Primary Keys e i n " 15 c a t pk. r i d b a c c e s s $1

37 7. Scripte f i 17 i f [ [ " $4 " =~ ^[0 9]+ $ ] ] ; then 18 i f [ " $4 " eq " 1 " ] ; then 19 echo " Fuege Foreign Keys e i n " 20 c a t fk. r i d b a c c e s s $1 21 f i 22 f i 23 f i 24 echo " F e r t i g... Beginne mit u p d a t e s t a t i s t i c s high " 25 echo " u p d a t e s t a t i s t i c s high " d b a c c e s s $ Messscripte data/einfuegen.sh Nach einer Messung sind die Messergebnisse als tar-archiv unter dem Namen $1.tar zu finden. Alle 22 Queries werden ausgeführt, die Zeit gemessen und die Auslastung des Systems gemessen. Argumente: $1 Verzeichnis $2 Datenbank 1 #! / b i n / bash 2 i f t e s t z " $1 " 3 then 4 echo " usage : $0 d i r e c t o r y d a t a b a s e query " 5 f i 6 echo " D i r e c t o r y : $1 / " 7 echo " D a t a b a s e : $2 " 8 mkdir $1 9 echo " S t a r t e Messung am $ ( d a t e ) " t e e $1 / messung. l o g 10 echo SET EXPLAIN FILE TO $1 / q u e r i e s. e x p l a i n d b a c c e s s $2 11 o n s t a t z 12 f o r i i n { } 13 do 14 d b a c c e s s $2 q u e r i e s / q. $ i. s q l > / dev / n u l l 2>&1 15 done 16 o n s t a t c > $1 / o n s t a t. c. l o g 17 o n s t a t > $1 / o n s t a t. l o g 18 o n s t a t D > $1 / o n s t a t.d. l o g 19 o n s t a t p > $1 / o n s t a t. p. l o g 20 o n s t a t z > $1 / o n s t a t. z. l o g 21 f o r i i n { } 22 do 23 mkdir $1 / messung$i 24 ( s a r r >> $1 / messung$i / s t a t. ram. $ i. l o g )& 25 SAR_RAM_PID=$! 26 ( s a r P ALL >> $1 / messung$i / s t a t. cpu. $ i. l o g )&

38 7. Scripte SAR_CPU_PID=$! 28 ( s a r b >> $1 / messung$i / s t a t. hdd. $ i. l o g )& 29 SAR_HDD_PID=$! echo " Beginne Messvorgang $ i um $ ( d a t e ) " t e e a $1 / messung. l o g START=$ ( d a t e +%s ) 34 d b a c c e s s $2 q u e r i e s / q $ i. s q l > $1 / messung$i / query. $ i. l o g 35 END=$ ( d a t e +%s ) 36 DIFF=$ ( ( $END $START ) ) 37 echo $ ( d a t e ) >> $1 / messung$i / time. $ i. l o g 38 echo $DIFF >> $1 / messung$i / time. $ i. l o g 39 s l e e p o n s t a t > $1 / o n s t a t. $ i. l o g 42 o n s t a t D > $1 / o n s t a t.d. $ i. l o g 43 o n s t a t p > $1 / o n s t a t. p. $ i. l o g echo " Beende Messvorgang um $ ( d a t e ) " t e e $1 / messung. l o g k i l l 9 $SAR_RAM_PID 48 k i l l 9 $SAR_CPU_PID 49 k i l l 9 $SAR_HDD_PID 50 done 51 echo " Beende Messung am $ ( d a t e ) " t e e a $1 / messung. l o g 52 t a r c f v $1. t a r $1 data/messung_1 22.sh Folgendes Script wurde dazu benutzt um nur ein Query auszuführen. Argumente: $1 Verzeichnis $2 Datenbank $3 Query 1 #! / b i n / bash 2 i f t e s t z " $1 " 3 then 4 echo " usage : $0 d i r e c t o r y d a t a b a s e query " 5 f i 6 echo " D i r e c t o r y : $1 / " 7 echo " D a t a b a s e : $2 " 8 echo " Query : $3 " 9 mkdir $1 10 echo " S t a r t e Messung am $ ( d a t e ) " 11 o n s t a t z 12 d b a c c e s s $2 q u e r i e s / q$3. s q l > / dev / n u l l 2>&1 13 o n s t a t c > $1 / o n s t a t. c. l o g

39 7. Scripte o n s t a t > $1 / o n s t a t. l o g 15 o n s t a t D > $1 / o n s t a t.d. l o g 16 o n s t a t p > $1 / o n s t a t. p. l o g 17 o n s t a t z > $1 / o n s t a t. z. l o g echo " Beginne Messvorgang $M um $ ( d a t e ) " START=$ ( d a t e +%s ) 22 d b a c c e s s $2 q u e r i e s / q$3. s q l 23 END=$ ( d a t e +%s ) 24 DIFF=$ ( ( $END $START ) ) 25 echo $ ( d a t e ) >> $1 / t ime. l o g 26 echo $DIFF >> $1 / time. l o g 27 s l e e p o n s t a t > $1 / o n s t a t. l o g 30 o n s t a t D > $1 / o n s t a t.d. l o g 31 echo " Beende Messvorgang um $ ( d a t e ) " k i l l 9 $SAR_RAM_PID 34 k i l l 9 $SAR_CPU_PID 35 k i l l 9 $SAR_HDD_PID 36 echo " Beende Messung am $ ( d a t e ) " 37 t a r c f v $1. t a r $1 data/messung_x.sh Bei einer Messung am Accelerator werden keine Messungen der Systemauslastung benötigt. Über das Array queries kann festgelegt werden, welche Queries ausgeführt werden. Argumente: $1 Verzeichnis $2 Datenbank 1 #! / b i n / bash 2 q u e r i e s =( ) 3 i f t e s t z " $1 " 4 then 5 echo " usage : $0 d i r e c t o r y d a t a b a s e " 6 f i 7 echo " D i r e c t o r y : $1 / " 8 echo " D a t a b a s e : $2 " 9 mkdir $1 10 echo " S t a r t e Messung am $ ( d a t e ) " t e e $1 / messung. l o g 11 o n s t a t z 12 o n s t a t c > $1 / o n s t a t. c. l o g 13 o n s t a t > $1 / o n s t a t. l o g 14 o n s t a t D > $1 / o n s t a t.d. l o g

40 7. Scripte o n s t a t p > $1 / o n s t a t. p. l o g 16 o n s t a t z > $1 / o n s t a t. z. l o g 17 f o r i i n " ${ q u e r i e s [@] } " 18 do 19 mkdir $1 / messung$i 20 echo " Beginne Messvorgang $ i um $ ( d a t e ) " t e e a $1 / messung. l o g START=$ ( d a t e +%s ) 23 d b a c c e s s $2 q u e r i e s / q $ i. s q l > $1 / messung$i / query. $ i. l o g 24 END=$ ( d a t e +%s ) 25 DIFF=$ ( ( $END $START ) ) 26 echo $ ( d a t e ) >> $1 / messung$i / time. $ i. l o g 27 echo $DIFF >> $1 / messung$i / time. $ i. l o g 28 s l e e p o n s t a t > $1 / o n s t a t. $ i. l o g 31 o n s t a t D > $1 / o n s t a t.d. $ i. l o g 32 o n s t a t p > $1 / o n s t a t. p. $ i. l o g echo " Beende Messvorgang um $ ( d a t e ) " t e e $1 / messung. l o g 35 done 36 echo " Beende Messung am $ ( d a t e ) " t e e a $1 / messung. l o g 37 t a r c f v $1. t a r $1 data/messung_iwa.sh

41 7. Scripte 30

42 8. Probleme Während des Projektes sind uns zeitraubende Fehler unterlaufen, die im folgenden Erläutert werden Informix Die ersten Abfragen liefen nur mit einem Thread. Denn seit der Version ist die Option NUMCPUVPS nicht mehr nutzbar. Die Option VPCLASS ersetzt diese Optimierte Informix Instanz Obwohl die gesamte Konfiguration darauf ausgerichtet war die Daten der Datenbank zu cachen und weitere Festplattenzugriffe unnötig zu machen gab es bei manchen Abfragen trotzdem Lese- und Schreibzugriffe. Das Debugging über Explain-Dateien ergab, das der Optimizer von Informix temporäre Indizes erstellt und dabei auf Festplatte schreibt und liest, was die Abfragen aus bremste. Zudem hatten wir bei Abfragen mit 40 GB Probleme die Daten im Zwischenspeicher zu halten, da der RAM zu 99% ausgelastet war, obwohl nur Informix große Mengen nutzte. Lösung war hierbei Primary- und Foreign-Keys zu löschen. Diese benötigten zusammen mehr als 20 GB Platz im Zwischenspeicher Informix Warehouse Accelerator Die conn.prop darf keine Leerzeichen enthalten, ansonsten kann keine Verbindung aufgebaut werden. Es ist wichtig, dass in der conn.prop die richtige Datenbank angegeben ist. Falsche Angaben erzeugen Verbindungsfehler, wenn die Datenbank nicht mit den Accelerator verbunden ist oder es wird die falsche Datenbank konfiguriert. USE_DWA über Prozeduren in SYSDBOPEN von Informix zu steuern ist nur bedingt möglich, da die Option NO_FALLBACK auch bedeutet, dass keine Abfragen auf die Systemtabellen von Informix zugreifen kann. Da die Tabellen des Accelerators in halb der Systemtabellen zu finden ist kann auch die Java CLI etwas am Accelerator einstellen.

43 8. Probleme 32

44 9. Vergleich der Messungen Alle Messungen wurden mit 15 GB Datenvolumen gemessen Messzeiten von Informix Es wurden zwei Informix Datenbanken mit Primary-Keys und ohne Primary-Keys verglichen. Zur Sicherheit wurden beiden Messungen zwei Mal durchgeführt. Die Messungen von den Queries #20 und #22 wurden wegen zu langer Laufzeit abgebrochen. Die Abweichungen bei diesen Messungen sind daher irrelevant. Query #2 ohne Primary Keys wurde nochmal überprüft. Abbildung 9.1.: Messergebnisse Informix mit und ohne Primary-Keys Bei Messungen in denen die Abweichungen größer 10 Sekunden ist, wurde zumindest von der Platte gelesen. Bei Messungen mit Abweichungen größer 300 Sekunden wurde sogar auf Festplatte geschrieben. Diese Lese und Schreibvorgänge sind, wie in den Problemen beschrieben, Vorgänge des Optimizers.

45 9. Vergleich der Messungen Messzeiten des Accelerators und Informix Abbildung 9.2.: Messergebnisse des Accelerators und optimierten Informix Da der Accelerator in unserer Mart Definition nur fünf Queries ausführen konnte wurden auch nur diese verglichen. Der Faktor bezieht sich immer im Vergleich zur Messung mit Accelerator. Es zeigt sich, das eine optimierte Informix Instanz sehr wohl mit den Accelerator mithalten kann.

46 9. Vergleich der Messungen Messergebnisse von SQLite Abbildung 9.3.: Messergebnisse von SQLite Da nicht alle Abfragen von SQLite funktionierten und die Abfragen leider unterschiedlich zu den Queries vom Informix Warehouse Accelerator sind können die Ergebnisse nicht verglichen werden. Verglichen mit Messzeiten von Informix mit und ohne Primary-Keys zeigt SQLite in einfachen Abfragen eine sehr schnelle Ausführungszeit, während komplexe Abfragen schnell Ausführungszeiten um ein Faktor größer 10 haben.

47 9. Vergleich der Messungen 36

48 10. Fazit Fazit Das Semesterprojekt hat uns vieles gelehrt. Wir haben Erfahrung in Benchmarking von Datenbanken gesammelt, wie Informix installiert, konfiguriert und benutzt werden kann, wie der Informix Warehouse Accelerator einzurichten ist, wie dieser funktioniert und welche Zusammenhänge mit dem Informix-Server bestehen und gelernt wie SQ- Lite zu benutzten ist. Außerdem haben wir Probleme im System analysiert und gelöst. Im Bereich des Benchmarkings haben wir festgestellt, dass nicht alle Systemressourcen, wie CPU-Auslastung, der Verbrauch des Zwischenspeichers und die Festplattenaktivitäten, relevant für eine Messung sind. So ist es bei den Messungen des Accelerators nicht von Bedeutung, wie viel Zwischenspeicher vom Accelerator benutzt wird, da dieser Verbrauch konstant ist. Auch sind die Festplattenaktivitäten beim Accelerator überflüssig, da die Datenbank keine Zugriffe auf die Festplatten tätigen. Allerdings ist die Messung des benutzten Zwischenspeichers und der Festplattenaktivitäten bei der Initialisierung des Accelerators von Bedeutung, da gemessen werden kann wie viel Zwischenspeicher der Accelerator durch Komprimierung spart und die Festplatte beansprucht wird. Die Messung der CPU-Auslastung war nur zur Validierung der Informix Konfiguration nötig. Die Messergebisse zeigen, dass der Informix Warehouse Accelerator im Gegensatz zu der optimierten Informix Instanz konstante Laufzeiten hat und bei den meisten Abfragen schneller ist. Diese beiden Eigenschaften sind für die Datenbankmanagementsysteme aus dem Bereich der Entscheidungsunterstützungssysteme extrem wichtig, da die Geschäftsführung meist aktuelle Daten benötigen. Wenn Informix in kleinen oder mittelständischen Unternehmen zur Anwendung kommt dürfte es Kostengünstiger sein Informix optimal auf das System zugeschnitten zu konfigurieren. Für kleine Softwarelösungen lässt sich dagegen SQLite perfekt einsetzen, da es keinen eigenen Server mit eigener Konfiguration benötigt, allerdings muss die Software die Bibliothek einsetzen, um die Daten zu verarbeiten.

49 10. Fazit 38

50 LITERATURVERZEICHNIS 39 Literaturverzeichnis [Her08] HERBER, Eric: Informix 11.5: IBM Informix Dynamic Server. entwickler.press, 2008 [IBM11] IBM (Hrsg.): Informix Server System Requirements. IBM, September 7, uid=swg [inf11] INFORMIX german: Introducing Informix Warehouse Accelerator. In: planetids.com 1 (2011), 1. introducing-informix-warehouse-accelerator [Mur11] MURTHY, Keshava: IBM Informix Warehouse Accelerator Performance is everything / IBM Informix Development. Version: ftp://public.dhe.ibm.com/ software/data/sw-library/informix/whitepapers/ InformixWarehouseAcceleratorPaper.pdf Forschungsbericht [SW 08] SW TSC GERMANY (Hrsg.): DB2 Version 9.7 für Linux, UNIX und Windows. Kst. 2877: SW TSC Germany, 2008

51 LITERATURVERZEICHNIS 40

52 A. Anhang: Scripte A.1. Tabellenerstellung 1 CREATE TABLE NATION ( N_NATIONKEY INTEGER NOT NULL, 2 N_NAME CHAR( 2 5 ) NOT NULL, 3 N_REGIONKEY INTEGER NOT NULL, 4 N_COMMENT VARCHAR( ) ) ; 5 6 CREATE TABLE REGION ( R_REGIONKEY INTEGER NOT NULL, 7 R_NAME CHAR( 2 5 ) NOT NULL, 8 R_COMMENT VARCHAR( ) ) ; 9 10 CREATE TABLE PART ( P_PARTKEY INTEGER NOT NULL, 11 P_NAME VARCHAR( 5 5 ) NOT NULL, 12 P_MFGR CHAR( 2 5 ) NOT NULL, 13 P_BRAND CHAR( 1 0 ) NOT NULL, 14 P_TYPE VARCHAR( 2 5 ) NOT NULL, 15 P_SIZE INTEGER NOT NULL, 16 P_CONTAINER CHAR( 1 0 ) NOT NULL, 17 P_RETAILPRICE DECIMAL( 1 5, 2 ) NOT NULL, 18 P_COMMENT VARCHAR( 2 3 ) NOT NULL ) 19 FRAGMENT BY ROUND ROBIN 20 p a r t i t i o n p1 in r o o t d b s, 21 p a r t i t i o n p2 in r o o t d b s, 22 p a r t i t i o n p3 in r o o t d b s, 23 p a r t i t i o n p4 in r o o t d b s ; CREATE TABLE SUPPLIER ( S_SUPPKEY INTEGER NOT NULL, 28 S_NAME CHAR( 2 5 ) NOT NULL, 29 S_ADDRESS VARCHAR( 4 0 ) NOT NULL, 30 S_NATIONKEY INTEGER NOT NULL, 31 S_PHONE CHAR( 1 5 ) NOT NULL, 32 S_ACCTBAL DECIMAL( 1 5, 2 ) NOT NULL, 33 S_COMMENT VARCHAR( ) NOT NULL) ; CREATE TABLE PARTSUPP ( PS_PARTKEY INTEGER NOT NULL, 36 PS_SUPPKEY INTEGER NOT NULL, 37 PS_AVAILQTY INTEGER NOT NULL, 38 PS_SUPPLYCOST DECIMAL( 1 5, 2 ) NOT NULL, 39 PS_COMMENT VARCHAR( ) NOT NULL ) ;

53 A. Anhang: Scripte CREATE TABLE CUSTOMER ( C_CUSTKEY INTEGER NOT NULL, 42 C_NAME VARCHAR( 2 5 ) NOT NULL, 43 C_ADDRESS VARCHAR( 4 0 ) NOT NULL, 44 C_NATIONKEY INTEGER NOT NULL, 45 C_PHONE CHAR( 1 5 ) NOT NULL, 46 C_ACCTBAL DECIMAL( 1 5, 2 ) NOT NULL, 47 C_MKTSEGMENT CHAR( 1 0 ) NOT NULL, 48 C_COMMENT VARCHAR( ) NOT NULL) ; CREATE TABLE ORDERS ( O_ORDERKEY INTEGER NOT NULL, 51 O_CUSTKEY INTEGER NOT NULL, 52 O_ORDERSTATUS CHAR( 1 ) NOT NULL, 53 O_TOTALPRICE DECIMAL( 1 5, 2 ) NOT NULL, 54 O_ORDERDATE DATE NOT NULL, 55 O_ORDERPRIORITY CHAR( 1 5 ) NOT NULL, 56 O_CLERK CHAR( 1 5 ) NOT NULL, 57 O_SHIPPRIORITY INTEGER NOT NULL, 58 O_COMMENT VARCHAR( 7 9 ) NOT NULL) ; CREATE TABLE LINEITEM ( L_ORDERKEY INTEGER NOT NULL, 61 L_PARTKEY INTEGER NOT NULL, 62 L_SUPPKEY INTEGER NOT NULL, 63 L_LINENUMBER INTEGER NOT NULL, 64 L_QUANTITY DECIMAL( 1 5, 2 ) NOT NULL, 65 L_EXTENDEDPRICE DECIMAL( 1 5, 2 ) NOT NULL, 66 L_DISCOUNT DECIMAL( 1 5, 2 ) NOT NULL, 67 L_TAX DECIMAL( 1 5, 2 ) NOT NULL, 68 L_RETURNFLAG CHAR( 1 ) NOT NULL, 69 L_LINESTATUS CHAR( 1 ) NOT NULL, 70 L_SHIPDATE DATE NOT NULL, 71 L_COMMITDATE DATE NOT NULL, 72 L_RECEIPTDATE DATE NOT NULL, 73 L_SHIPINSTRUCT CHAR( 2 5 ) NOT NULL, 74 L_SHIPMODE CHAR( 1 0 ) NOT NULL, 75 L_COMMENT VARCHAR( 4 4 ) NOT NULL) 76 FRAGMENT BY ROUND ROBIN 77 p a r t i t i o n p1 in r o o t d b s, 78 p a r t i t i o n p2 in r o o t d b s, 79 p a r t i t i o n p3 in r o o t d b s, 80 p a r t i t i o n p4 in r o o t d b s ; data/dss.ddl A.2. Erstellung von Primärschlüssel 1 Primary Keys 2 For t a b l e REGION 3 ALTER TABLE REGION

54 A. Anhang: Scripte 43 4 ADD CONSTRAINT PRIMARY KEY ( R_REGIONKEY) ; 5 6 For t a b l e NATION 7 ALTER TABLE NATION 8 ADD CONSTRAINT PRIMARY KEY ( N_NATIONKEY) ; 9 10 For t a b l e PART 11 ALTER TABLE PART 12 ADD CONSTRAINT PRIMARY KEY ( P_PARTKEY) ; For t a b l e SUPPLIER 15 ALTER TABLE SUPPLIER 16 ADD CONSTRAINT PRIMARY KEY ( S_SUPPKEY) ; For t a b l e PARTSUPP 19 ALTER TABLE PARTSUPP 20 ADD CONSTRAINT PRIMARY KEY ( PS_PARTKEY, PS_SUPPKEY ) ; For t a b l e CUSTOMER 23 ALTER TABLE CUSTOMER 24 ADD CONSTRAINT PRIMARY KEY ( C_CUSTKEY) ; For t a b l e LINEITEM 27 ALTER TABLE LINEITEM 28 ADD CONSTRAINT PRIMARY KEY ( L_ORDERKEY, L_LINENUMBER) ; For t a b l e ORDERS 31 ALTER TABLE ORDERS 32 ADD CONSTRAINT PRIMARY KEY (O_ORDERKEY) ; data/dss.pk.ri A.3. Erstellung von Fremdschlüssel 1 For t a b l e NATION 2 ALTER TABLE NATION 3 ADD CONSTRAINT FOREIGN KEY(N_REGIONKEY) r e f e r e n c e s REGION ; 4 5 For t a b l e SUPPLIER 6 ALTER TABLE SUPPLIER 7 ADD CONSTRAINT FOREIGN KEY(S_NATIONKEY) r e f e r e n c e s NATION ; 8 9 For t a b l e CUSTOMER 10 ALTER TABLE CUSTOMER 11 ADD CONSTRAINT FOREIGN KEY(C_NATIONKEY) r e f e r e n c e s NATION ; For t a b l e PARTSUPP 14 ALTER TABLE PARTSUPP 15 ADD CONSTRAINT FOREIGN KEY ( PS_SUPPKEY ) r e f e r e n c e s SUPPLIER ; 16

55 A. Anhang: Scripte ALTER TABLE PARTSUPP 18 ADD CONSTRAINT FOREIGN KEY (PS_PARTKEY) r e f e r e n c e s PART ; For t a b l e ORDERS 21 ALTER TABLE ORDERS 22 ADD CONSTRAINT FOREIGN KEY (O_CUSTKEY) r e f e r e n c e s CUSTOMER; For t a b l e LINEITEM 25 ALTER TABLE LINEITEM 26 ADD CONSTRAINT FOREIGN KEY (L_ORDERKEY) r e f e r e n c e s ORDERS; ALTER TABLE LINEITEM 29 ADD CONSTRAINT FOREIGN KEY (L_PARTKEY, L_SUPPKEY) r e f e r e n c e s PARTSUPP ; data/dss.fk.ri A.4. Import 1 #! / b i n / bash 2 echo " drop d a t a b a s e " $1 d b a c c e s s 3 echo " c r e a t e d a t a b a s e " $1 d b a c c e s s 4 c a t d s s. d d l d b a c c e s s $1 5 f i l e s =" r e g i o n n a t i o n s u p p l i e r c u s t o m e r o r d e r s p a r t p a r t s u p p l i n e i t e m " 6 f o r t i n $ f i l e s 7 do 8 echo " Fuege Daten aus D a t e i $ t e i n " 9 echo "CREATE EXTERNAL TABLE ${ t } e x t SAMEAS $ t USING ( DATAFILES ( DISK : $2 / ${ t }. t b l ) ) ; " d b a c c e s s $1 10 echo "INSERT INTO $ t SELECT FROM ${ t } e x t " d b a c c e s s $1 11 done 12 i f [ [ " $3 " =~ ^[0 9]+ $ ] ] ; then 13 i f [ " $3 " eq " 1 " ] ; then 14 echo " Fuege Primary Keys e i n " 15 c a t pk. r i d b a c c e s s $1 16 f i 17 i f [ [ " $4 " =~ ^[0 9]+ $ ] ] ; then 18 i f [ " $4 " eq " 1 " ] ; then 19 echo " Fuege Foreign Keys e i n " 20 c a t fk. r i d b a c c e s s $1 21 f i 22 f i 23 f i 24 echo " F e r t i g... Beginne mit u p d a t e s t a t i s t i c s high " 25 echo " u p d a t e s t a t i s t i c s high " d b a c c e s s $1 data/einfuegen.sh

56 A. Anhang: Scripte 45 A.5. Konfiguration d e f a u l t, b u f f e r s = , l r u s =8, l r u _ m i n _ d i r t y = , l r u _ m a x _ d i r t y = ROOTPATH / home / i n f o r m i x / i n s t a n c e s / g epard / d a t a / r o o t d b s. chk1 # Path f o r d e v i c e c o n t a i n i n g r o o t dbspace 2 ROOTSIZE # S i z e o f r o o t dbspace ( Kbytes ) 3 DBSERVERNAME g e p a r d # Name o f d e f a u l t d a t a b a s e s e r v e r 4 NETTYPE s o c t c p, 1, 3 2,NET # C o n f i g u r e p o l l t h r e a d ( s ) f o r n e t t y p e 5 NETTYPE ipcshm, 1, 3 2,CPU # C o n f i g u r e p o l l t h r e a d ( s ) f o r n e t t y p e 6 MULTIPROCESSOR 1 # 7 #NUMCPUVPS 4 # Number o f u s e r ( cpu ) vps, V e r a l t e t! 8 VPCLASS cpu, num=4, noage 9 SHMBASE 0 x l # Shared memory base a d d r e s s 10 SHMVIRTSIZE # i n i t i a l v i r t u a l shared memory segment s i z e 11 BUFFERPOOL d e f a u l t, b u f f e r s =500, l r u s =4, l r u _ m i n _ d i r t y = , l r u _ m a x _ d i r t y = BUFFERPOOL data/onconfig.std.conf 1 <? xml v e r s i o n =" 1. 0 " e n c o d i n g ="UTF 8"?>< a q t m a r t : m a r t M o d e l x m l n s : a q t m a r t =" h t t p : / /www. ibm. com / xmlns / prod / dwa " v e r s i o n =" 1. 0 "> 2 < mart x m l n s : x s i =" h t t p : / /www. w3. org / / XMLSchema i n s t a n c e " name=" h f u m a r t "> 3 < t a b l e name=" r e g i o n " schema=" i n f o r m i x "> 4 <column name=" r _ r e g i o n k e y " / > 5 <column name=" r_name " / > 6 <column name=" r_ comment " / > 7 < / t a b l e > 8 < t a b l e name=" o r d e r s " schema=" i n f o r m i x "> 9 <column name=" o _ o r d e r k e y " / > 10 <column name=" o _ c u s t k e y " / > 11 <column name=" o _ o r d e r s t a t u s " / > 12 <column name=" o _ t o t a l p r i c e " / > 13 <column name=" o _ o r d e r d a t e " / > 14 <column name=" o _ o r d e r p r i o r i t y " / > 15 <column name=" o _ c l e r k " / > 16 <column name=" o _ s h i p p r i o r i t y " / > 17 <column name=" o_comment " / > 18 < / t a b l e > 19 < t a b l e name=" p a r t s u p p " schema=" i n f o r m i x "> 20 <column name=" p s _ p a r t k e y " / > 21 <column name=" ps_suppkey " / > 22 <column name=" p s _ a v a i l q t y " / > 23 <column name=" p s _ s u p p l y c o s t " / > 24 <column name=" ps_comment " / > 25 < / t a b l e > 26 < t a b l e name=" p a r t " schema=" i n f o r m i x ">

57 A. Anhang: Scripte <column name=" p _ p a r t k e y " / > 28 <column name=" p_name " / > 29 <column name=" p_mfgr " / > 30 <column name=" p_brand " / > 31 <column name=" p _ t y p e " / > 32 <column name=" p _ s i z e " / > 33 <column name=" p _ c o n t a i n e r " / > 34 <column name=" p _ r e t a i l p r i c e " / > 35 <column name=" p_comment " / > 36 < / t a b l e > 37 < t a b l e name=" n a t i o n " schema=" i n f o r m i x "> 38 <column name=" n _ n a t i o n k e y " / > 39 <column name=" n_name " / > 40 <column name=" n _ r e g i o n k e y " / > 41 <column name=" n_comment " / > 42 < / t a b l e > 43 < t a b l e name=" s u p p l i e r " schema=" i n f o r m i x "> 44 <column name=" s_suppkey " / > 45 <column name=" s_name " / > 46 <column name=" s _ a d d r e s s " / > 47 <column name=" s _ n a t i o n k e y " / > 48 <column name=" s_phone " / > 49 <column name=" s _ a c c t b a l " / > 50 <column name=" s_comment " / > 51 < / t a b l e > 52 < t a b l e name=" l i n e i t e m " schema=" i n f o r m i x "> 53 <column name=" l _ o r d e r k e y " / > 54 <column name=" l _ p a r t k e y " / > 55 <column name=" l _ s u p p k e y " / > 56 <column name=" l _ l i n e n u m b e r " / > 57 <column name=" l _ q u a n t i t y " / > 58 <column name=" l _ e x t e n d e d p r i c e " / > 59 <column name=" l _ d i s c o u n t " / > 60 <column name=" l _ t a x " / > 61 <column name=" l _ r e t u r n f l a g " / > 62 <column name=" l _ l i n e s t a t u s " / > 63 <column name=" l _ s h i p d a t e " / > 64 <column name=" l _ c o m m i t d a t e " / > 65 <column name=" l _ r e c e i p t d a t e " / > 66 <column name=" l _ s h i p i n s t r u c t " / > 67 <column name=" l_shipmode " / > 68 <column name=" l_ comment " / > 69 < / t a b l e > 70 < t a b l e name=" c u s t o m e r " schema=" i n f o r m i x "> 71 <column name=" c _ c u s t k e y " / > 72 <column name=" c_name " / > 73 <column name=" c _ a d d r e s s " / > 74 <column name=" c _ n a t i o n k e y " / > 75 <column name=" c_phone " / > 76 <column name=" c _ a c c t b a l " / > 77 <column name=" c_mktsegment " / >

58 A. Anhang: Scripte <column name=" c_comment " / > 79 < / t a b l e > 80 < r e f e r e n c e d e p e n d e n t C a r d i n a l i t y =" n " dependenttablename=" p a r t s u p p " dependenttableschema =" i n f o r m i x " i s R u n t i m e J o i n =" t r u e " p a r e n t C a r d i n a l i t y =" 1 " parenttablename =" s u p p l i e r " p a r e n t T a b l e S c h e m a =" i n f o r m i x " r e f e r e n c e T y p e ="LEFTOUTER"> 81 < parentcolumn name=" s_suppkey " / > 82 <dependentcolumn name=" ps_suppkey " / > 83 < / r e f e r e n c e > 84 < r e f e r e n c e d e p e n d e n t C a r d i n a l i t y =" n " dependenttablename=" p a r t s u p p " dependenttableschema =" i n f o r m i x " i s R u n t i m e J o i n =" t r u e " p a r e n t C a r d i n a l i t y =" 1 " parenttablename =" p a r t " p a r e n t T a b l e S c h e m a =" i n f o r m i x " r e f e r e n c e T y p e ="LEFTOUTER"> 85 < parentcolumn name=" p _ p a r t k e y " / > 86 <dependentcolumn name=" p s _ p a r t k e y " / > 87 < / r e f e r e n c e > 88 < r e f e r e n c e d e p e n d e n t C a r d i n a l i t y =" n " dependenttablename=" c u s t o m e r " dependenttableschema =" i n f o r m i x " i s R u n t i m e J o i n =" t r u e " p a r e n t C a r d i n a l i t y =" 1 " parenttablename =" n a t i o n " p a r e n t T a b l e S c h e m a =" i n f o r m i x " r e f e r e n c e T y p e ="LEFTOUTER"> 89 < parentcolumn name=" n _ n a t i o n k e y " / > 90 <dependentcolumn name=" c _ n a t i o n k e y " / > 91 < / r e f e r e n c e > 92 < r e f e r e n c e d e p e n d e n t C a r d i n a l i t y =" n " dependenttablename=" n a t i o n " dependenttableschema =" i n f o r m i x " i s R u n t i m e J o i n =" t r u e " p a r e n t C a r d i n a l i t y =" 1 " parenttablename =" r e g i o n " p a r e n t T a b l e S c h e m a =" i n f o r m i x " r e f e r e n c e T y p e ="LEFTOUTER"> 93 < parentcolumn name=" r _ r e g i o n k e y " / > 94 <dependentcolumn name=" n _ r e g i o n k e y " / > 95 < / r e f e r e n c e > 96 < r e f e r e n c e d e p e n d e n t C a r d i n a l i t y =" n " dependenttablename=" s u p p l i e r " dependenttableschema =" i n f o r m i x " i s R u n t i m e J o i n =" t r u e " p a r e n t C a r d i n a l i t y =" 1 " parenttablename =" n a t i o n " p a r e n t T a b l e S c h e m a =" i n f o r m i x " r e f e r e n c e T y p e ="LEFTOUTER"> 97 < parentcolumn name=" n _ n a t i o n k e y " / > 98 <dependentcolumn name=" s _ n a t i o n k e y " / > 99 < / r e f e r e n c e > 100 < r e f e r e n c e d e p e n d e n t C a r d i n a l i t y =" n " dependenttablename=" o r d e r s " dependenttableschema =" i n f o r m i x " i s R u n t i m e J o i n =" t r u e " p a r e n t C a r d i n a l i t y =" 1 " parenttablename =" c u s t o m e r " p a r e n t T a b l e S c h e m a =" i n f o r m i x " r e f e r e n c e T y p e ="LEFTOUTER"> 101 < parentcolumn name=" c _ c u s t k e y " / > 102 <dependentcolumn name=" o _ c u s t k e y " / > 103 < / r e f e r e n c e > 104 < r e f e r e n c e d e p e n d e n t C a r d i n a l i t y =" n " dependenttablename=" l i n e i t e m " dependenttableschema =" i n f o r m i x " i s R u n t i m e J o i n =" t r u e "