Oracle Datenbankkopplung
SNI BS2000 { KSR1
Heinz Kredel, Robert Schumacher (eds.)
Rechenzentrum Universit�at Mannheim
RUM 37/94
Juni 1994
Vorwort
Der folgende Bericht ist aus einer Ausarbeitung von Teilen eines internen Arbeits-
berichts der Projektgruppe Datenbankkopplung entstanden. Das Projekt diente
der Evaluierung einer Oracle Datenbank-Kopplung f�ur Decision Support Anwen-
dungen zwischen einem SNI BS2000 Rechner und einem KSR1 massiv parallelen
Rechner. Der Bericht gibt zun�achst die Aufgabenstellung an und diskutiert dann
die Ergebnisse der einzelnen Teilaufgaben. In den Anh�angen werden die durch-
gef�uhrten Messungen und wichtige Parameter dokumentiert.
Zu den Zeitmesungen ist zu bemerken, da� unsere Hard- und Software Kon�gura-
tion den Bed�urfnissen einer Universi�at entspricht. D.h. wir haben keine spezielle
Datenbank Hardware (leistungsf�ahiger I/O, dedizierter Rechner) und besitzen
auch nicht die Oracle Tuning Kenntnisse von gro�en Datenbank Anwendern.
Dieser Text be�ndet sich auch auf dem FTP Server der Universit�at Mannheim
ftp.uni-mannheim.de in dem Verzeichniss pub/info/rumdoc in der komprimier-
ten PostScript Datei rum3794.ps.Z.
Verbesserungsvorschl�age und Fehlerhinweise nehmen wir dankbar entgegen. Wir
sind unter der e-Mail Adresse [email protected] zuerreichen.
Mannheim, 15. Juni 1994 Heinz Kredel, Robert Schumacher
1
Inhaltsverzeichnis
1 Aufgabenstellung 4
2 Zur Durchf�uhrung 6
2.1 Wahl der Datenbank : : : : : : : : : : : : : : : : : : : : : : : : : 6
2.2 Wahl der Abfragen : : : : : : : : : : : : : : : : : : : : : : : : : : 6
3 Oracle 7.0 auf KSR1, Unix 8
3.1 Funktionsweise des Query{Decomposer von KSR : : : : : : : : : : 8
3.2 Installation und Betriebserfahrungen mit Oracle auf der KSR1 : : 10
3.3 Generierung und Laden der Daten : : : : : : : : : : : : : : : : : : 10
3.4 Verwendete Begri�e : : : : : : : : : : : : : : : : : : : : : : : : : 11
3.5 Performance in Abh�angigkeit der Verteilung der Daten : : : : : : 11
3.6 Performance f�ur unterschiedliche Queries : : : : : : : : : : : : : : 12
3.6.1 Query 1 : : : : : : : : : : : : : : : : : : : : : : : : : : : : 15
3.6.2 Query 2 : : : : : : : : : : : : : : : : : : : : : : : : : : : : 16
3.6.3 Query 8 : : : : : : : : : : : : : : : : : : : : : : : : : : : : 16
3.6.4 Query 12 : : : : : : : : : : : : : : : : : : : : : : : : : : : : 16
4 Oracle 7.0 auf SNI H60, BS2000 18
4.1 Installation : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 18
4.2 Laden der Datenbank : : : : : : : : : : : : : : : : : : : : : : : : : 19
4.3 Queries : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 19
5 Oracle Kopplung BS2000 { KSR1 20
5.1 Installation : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 20
2
5.2 Datenbank Kommunikation : : : : : : : : : : : : : : : : : : : : : 21
6 Zusammenfassung 22
6.1 Ausblick : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 22
A Projektstatistik 25
B Arbeitsplan, Zeitplan 27
C Messungen auf KSR1 29
C.1 Messungen auf einem Prozessor : : : : : : : : : : : : : : : : : : : 29
C.2 Messungen f�ur verschiedene Verteilungen : : : : : : : : : : : : : : 29
C.3 Ergebnisse f�ur die einzelnen Queries : : : : : : : : : : : : : : : : : 30
D Messungen auf SNI H60 33
E Messungen der Kopplung 34
F Listings 36
F.1 De�nition der Datenbank : : : : : : : : : : : : : : : : : : : : : : : 36
F.2 Queries : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 39
F.3 Umformulierte Queries : : : : : : : : : : : : : : : : : : : : : : : : 42
3
Kapitel 1
Aufgabenstellung
Ziel der Evaluierung der Datenbank-Kopplung ist die Sammlung von Erfahrungen
und die Gewinnung von Performancedaten f�ur den Einsatz eines KSR1 massiv
parallelen Rechners als Datenbankbackend f�ur eine SNI-BS2000 Anlage. Insbe-
sondere soll festgestellt werden, ob eine solche Kon�guration f�ur den Einsatz im
praktischen Betrieb geeignet ist. Die Universit�at Mannheim und die Fachhoch-
schule L�uneburg erwarten bei der Evaluierung Erfahrungen im Betrieb von Da-
tenbanken auf massiv parallelen Rechnern sowie wissenschaftliche Erkenntnisse
bei der Parallelisierung von Decision Support Problemen.
Das Rechenzentrum der Universit�at Mannheim, vertreten durch Herrn Prof. Dr.
H.-W. Meuer, beteiligt sich mit folgenden Ressourcen an dem Projekt:
� Bereitstellung der SNI-H60, BS2000 Rechenanlage,
� Bereitstellung des KSR1 Parallelrechners,
� Knowhow, Durchf�uhrung und Unterst�utzung bei der Installation der Soft-
ware und der Netzkopplung.
� Einrichten und Laden der Test-Datenbank, Durchf�uhrung der Test-Queries.
Der FB Wirtschaft der Fachhochschule L�uneburg, vertreten durch Herrn Prof.
Dr. Mayer-Wachsmuth, unterst�utzt die Evaluierung bei
� dem Aufbau einer geeigneten Oracle Testdatenbank,
� der Formulierung und Durchf�uhrung der Datenbankabfragen,
� und der Durchf�uhrung von Referenzmessungen.
Die Firma Siemens Nixdorf Informationssysteme AG �ubernimmt im Rahmen der
Evaluierung
4
� die Beratung beim Vorgehen und bei der Analyse der Messungen,
� die Bereitstellung der erforderlichen Software, soweit nicht bei der Univer-
sit�at Mannheim vorhanden,
� die Bereitstellung eventuell zus�atzlicher Hardware, um eine sinnvolle Eva-
luierung zu erm�oglichen,
� die Kosten f�ur Personal (bis zu einem maximalen Betrag),
� eventuell anfallende Reisekosten und Spesen.
Die Evaluierung wird vom 1. Februar 1994 bis zum 31. Mai 1994 durchgef�uhrt.
Der genauere Zeitplan ist im Anhang enthalten.
5
Kapitel 2
Zur Durchf�uhrung
Aufgrund der heterogenen Systemumgebung eignet sich besonders das Oracle 7.0
Datenbanksystem. Oracle 7.0 ist sowohl f�ur BS2000 als auch f�ur KSR1 Rechner
verf�ugbar und stellt mit SQL*Net alle erforderliche Kommunikationssoftware zur
Verf�ugung. Zus�atzlich bietet die Firma KSR einen Query Decomposer (QD) f�ur
Oracle auf KSR1 Rechner an, dessen Aufgabe die Parallelisierung, d.h. in diesem
Fall die Verteilung der Queries auf die Prozessoren der KSR1 ist.
2.1 Wahl der Datenbank
F�ur den uns interessierenden Fall von Decision Support Anwendungen gibt es
einen von SNI verwendeten Datenbank Benchmark. Der Benchmark umfa�t u.A.
die De�nition einer geigneten Test-Datenbank, Programme um den Inhalt der Da-
tenbank zu erzeugen und auf DSS zugeschnittene Datenbank Abfragen. Die Test-
Datenbank ist skalierbar in Schritten von ca. 100 MB. Der Benchmark enth�alt
Datenbank Abfragen, die zu einem `full table scan' f�uhren und solche, die zu
komplexen `multiple join' Operationen f�uhren. Beide Arten von Abfragen sollten
sich gut f�ur die Parallelisierung auf einem massiv parallelen Rechner eignen.
2.2 Wahl der Abfragen
Aus den 19 im Benchmark vorbereiteten Queries ist es sinnvoll sich zun�achst auf
wenige typische Queries zu beschr�anken. Es sollen dabei unterschiedliche Typen
von Queries erfa�t werden und es soll vermieden werden, �ahnliche Abfragen zu
wiederholen. Die Wahl �el auf folgende 4 Queries:
Q1: Partitionierung der Daten, parallel full table scan,
6
Q2: Einfacher Join mit Subquery, block parallelization,
Q8: Vielfach-Join,
Q12: Union, block parallelization.
7
Kapitel 3
Oracle 7.0 auf KSR1, Unix
Die KSR1 ist der zentrale Compute{Server des Rechenzentrums der Universit�at
Mannheim. Bei dem Rechner handelt es sich um ein skalierbares MPP (massiv
paralleles) System mit 32 Prozessoren, 1GB Hauptspeicher und 10GB Platten-
speicher. Die Leistung eines Prozessors mit der Taktrate von 20MHz betr�agt 40
Mips bzw. 40 M ops.
Das Betriebssystem des Rechners ist OSF1 kompatibles UNIX, das symmetrisch
auf allen Prozessoren l�auft. Die KSR1 ist mit FDDI und Ethernet in das Netz
der Universit�at eingebunden.
Im folgenden werden die Funktionsweise des von KSR entwickeltem Query De-
composer dargestellt, und die Betriebserfahrungen mit Oracle auf der KSR1 ge-
schildert, sowie die erzielten Leistungssteigerungen diskutiert.
3.1 Funktionsweise des Query{Decomposer von
KSR
Der Query Decomposer (QD) ist ein von KSR entwickeltes Softwareprodukt,
welches zusammen mit dem Datenbanksystem Oracle insbesondere f�ur Decision
Support Anwendungen (DSS) eine erhebliche Reduzierung der Antwortzeiten {
von mehreren Stunden auf einige Minuten { erm�oglichen soll.
Die QD{Software ist als ein Teil von SQL*Plus anzusehen. Bevor eine Query
von SQL*Plus an Oracle zur Bearbeitung gegeben wird, wird von dem QD eine
Analyse vorgenommen, und bei vorhandener Parallelit�at die Query in Subqueries
zerlegt, die dann an Oracle �ubergeben werden.
F�ur jede Subquery wird ein eigener Proze� gestartet. Nach Abarbeitung der Sub-
queries werden die Ergebnisse von dem QD wieder zusammengef�uhrt. Findet der
8
QD keine M�oglichkeit der Parallelisierung, erfolgt die weitere Behandlung der
Query, als wenn es den QD nicht g�abe.
Voraussetzung f�ur die Parallelisierung ist, da� die Tabellen auf mehrere Dateien
{ auf die dann parallel zugegri�en werden kann { verteilt vorliegen. Es k�onnen
also maximal soviele Subqueries gestartet werden, wie Dateien vorliegen. �Uber
Direktiven kann diese Zahl verringert werden, bzw. der QD auch abgeschaltet
werden.
Als Ausgangspunkt f�ur die Parallelisierung w�ahlt der QD die von Oracle be-
stimmte 'driving table' (i. d. R. ist dies die Tabelle mit den meisten Zeilen), ist
diese Tabelle auf mehrere Dateien verteilt, wird die Query parallelisiert.
Die Funktionsweise des QD wird durch eine, ebenfalls von KSR vorgenommene
Erweiterung der SQL*Plus explain Funktion veranschaulicht.
In Abb. 3.1 ist die Wirkungsweise des QD f�ur Query 1 exemplarisch vorgef�uhrt.
SQL> explain plan for
2 select
3 l_returnflag, l_linestatus, sum(l_quantity),
4 sum(l_extendedprice),
5 sum(l_extendedprice * (1 - l_discount/100)),
6 sum(l_extendedprice * (1 - l_discount/100) * l_tax/100),
7 avg(l_quantity),
8 avg(l_extendedprice), avg(l_discount), count(*)
9 from lineitem
10 where l_shipdate <= to_date('01-DEC-98') - 90
11 group by l_returnflag, l_linestatus
12 order by l_returnflag, l_linestatus;
Explained.
QUERY_PLAN
--------------------------------------------------------------
1 0 KSR PARALLEL EXECUTION AGGREGATION LINEITEM
2 1 0 SORT GROUP BY
3 2 1 TABLE ACCESS FULL LINEITEM
Abbildung 3.1: Wirkungsweise des Query Decomposers
Bei der Query wird auf eine Tabelle (lineitem) zugegri�en, damit ist diese Tabelle
gleichzeitig die 'driving table'. Da diese Tabelle auf mehrere Dateien verteilt ist,
wird der QD aktiviert. Das Ergebnis ist dem Query Plan zu entnehmen.
9
3.2 Installation und Betriebserfahrungen mit
Oracle auf der KSR1
Die Oracle Software wird auf einem Exabyte{Tape geliefert und ist nach �uber-
spielen auf ein internes Plattenlaufwerk einsatzbereit. Die Installation erfolgte
am 31. M�arz dieses Jahres, die Version war 7.0.12.2.2.
Am 26. April wurde die Version 7.0.13.1.1 ebenso leicht eingespielt. Die zu die-
sem Zeitpunkt schon bestehende Testdatenbank konnte in vollem Umfang weiter
benutzt werden. Mittlerweile besteht die Datenbank aus �uber 100 Dateien mit
�uber 5GB Gesamtkapazit�at verteilt auf 16 Plattenlaufwerken.
Alle Oracle und SQL Funktionen sind vorhanden und nutzbar. Einzige Ein-
schr�ankung ist, da� der Query{Decomposer nicht von Pro*C und SQL*Net aus
aufrufbar ist, dieses wird sich jedoch nach Aussage von KSR in einem n�achsten
Release, dessen Erscheinen f�ur Juni angek�undigt ist, �andern.
Folgende Software{Komponenten umfa�t die momentane Oracle{Installation auf
der KSR1:
ORACLE Server 7.0.13.1.1
SQL*DBA 7.0.13.1.1
SQL*Loader 7.0.13.1.1
SQL*Plus 3.1.2.2.1
PL/SQL 2.0.15.1.0
KSR Query Decomposer 1.0.0
Pro*C 1.5.7.0.1
SQL*Net V1
SQL*Net V2
W�ahrend der jetzt achtw�ochigen Erfahrung mit Oracle auf der KSR1 gab es
wegen Oracle keinerlei Abst�urze oder Einschr�ankungen f�ur den Betrieb zu ver-
zeichnen. Weiterhin wurde die KSR1 w�ahrend der gesamten Zeit im Multiuser{
Timesharing{Betrieb gefahren. Die MTBF{Zeit der KSR1 f�ur April lag mit 7.5
Tagen (=30Tage/4Crashes) �uber dem Durchschnitt, der bei 5{6 Tagen MTBF{
Zeit liegt.
3.3 Generierung und Laden der Daten
Zur Generierung der Daten wurde das Programm `dbgen' auf die KSR1 portiert,
dh. die 64bit{Architektur der KSR hat unmittelbaren Ein u� auf Pointer und
andere Gr�o�en, was bei der Umstellung beachtet werden mu�te.
10
Die Generierung der Daten f�ur Skalierungsfaktor (SF) 1 (600 000 Zeilen) betrug
ca. 33min, f�ur SF 10 (6 000 000 Zeilen) ca. 6 Std. Das Laden der Daten im 'direct{
mode' betrug f�ur SF 1 ca. 45min und f�ur SF 10 ca. 7 Std.
3.4 Verwendete Begri�e
Die im Report benutzten Begri�e { Wall{Clock Zeit, E�zienz und Speedup {
sollen kurz erl�autert werden.
Alle gemessenen Zeiten sind Antwortzeiten oder Wall{Clock Zeiten, man stelle
sich einen Benutzer vor, der mit seiner Armbanduhr oder einer Wanduhr die Zeit
mi�t. Nat�urlich �ubernimmt ein Programm die Funktion der Wanduhr, in diesem
Fall wurden alle Zeiten mit der Oracle Funktion set timing on gemessen. Die
E�zienz wird aus den Wall{Clock Zeiten wie folgt berechnet: die Wall{Clock
Zeit t1 f�ur den Ein{Prozessor Lauf entspricht einer E�zienz von 100%, f�ur den
16{Prozessor Lauf errechnet sich die E�zienz damit: e�16 = t1=(16 � t16), oder
allgemein e�n = t1=(n � tn), wenn n die Anzahl der Prozessoren ist. Hieraus l�a�t
sich wiederum der Speedup Spn berechnen mit: Spn = n�e�n.
3.5 Performance in Abh�angigkeit der Vertei-
lung der Daten
Die Parallelisierung einer Query auf der KSR erfolgt auf der Basis der vorhan-
denen Dateien f�ur eine Tabelle, z. B.: besteht eine Tabelle aus 16 Dateien, kann
eine Query zu dieser Tabelle mit maximal 16 Prozessoren abgearbeitet werden.
Im ersten Abschnitt des Projekts, �uber den hier berichtet wird, ging es im wesent-
lichen um die Fragestellung, ob die Festplattenkapazit�at der Kon�guration (10
Platten �a 1GB, davon stehen f�ur die Messungen e�ektiv 4 Platten zur Verf�ugung)
ausreicht, um Aussagen �uber die Performance zu machen. Aussagen von KSR zu-
folge, macht es erst Sinn Oracle zu betreiben, wenn man 20 und mehr Platten
zur Verf�ugung hat, oder genauer pro Datei oder Prozessor ein Plattenlaufwerk.
Um das zu untersuchen, wurde die in Anlehnung an den Benchmark ausgesuchte
Query 1 { ein full table scan { in 16 unterschiedlichen Kon�gurationen auf einer
100MB gro�en Tabelle vermessen. Die genauen Ergebnisse sind in Anhang C zu
�nden. F�ur eine geringe Anzahl Dateien spielt deren Verteilung keine Rolle; bei 4
Dateien auf 4 Laufwerken erh�alt man 94% E�zienz und bei 4 Dateien auf einem
Laufwerk 93% E�zienz. Erh�oht sich die Anzahl der Dateien, ist eine Abnahme
der E�zienz zu beobachten, so ergibt sich bei 12 Dateien verteilt auf 4 Laufwerke
eine E�zienz von 83%, und bei einer Verteilung auf 3 Laufwerke nur noch 76%.
Im Falle von 16 Dateien �el die E�zienz gar auf 69%. Aufgrund dieses Ergebnisses
11
erfolgte die Bescha�ung weiterer 10 Laufwerke f�ur die KSR1, was auch zu einer
nochmaligen Leistungssteigerung f�uhrte, s. Abb. 3.2. Die Zunahme des Speedups
von 13.4 auf 14.9 bei 16 Prozessoren bedeutet eine Vergr�o�erung der E�zienz um
nahezu 10% von 84% auf 93%.
2
4
6
8
10
12
14
16
Speedup
2 4 6 8 10 12 14 16
Prozessoren
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
�
�
�
�
�
?
?
?
?
?
? 16 Laufwerke
� 4 Laufwerke
� � � linearer Speedup
Abbildung 3.2: Speedup bei der parallelen Abarbeitung einer 1GB gro�en Da-
tenbanktabelle verteilt auf 4 Laufwerke und auf 16 Laufwerke
Scheinbar ohne Ein u� ist die Anzahl der Dateien und damit auch deren Vertei-
lung bei Abarbeitung der Query ohne den QD. Die Einprozessorlaufzeiten vari-
ierten innerhalb der Toleranzgrenzen nicht, unabh�angig davon, ob die Tabelle in
einer Datei oder in 16 Dateien verteilt abgespeichert ist.
3.6 Performance f�ur unterschiedliche Queries
Urspr�unglich wurden 4 Queries aus dem Benchmark, die jeweils einen Typus re-
pr�asentieren, ausgew�ahlt. Queries 1 und 2 parallelisierten sofort, Queries 8 und 12
mu�ten umformuliert werden. Zus�atzlich wurden dann noch weitere 5 Queries be-
arbeitet, deren Ergebnisse hier nur wiedergegeben, aber nicht diskutiert werden.
12
Zur Auswertung wurden die jeweils besten erzielten Leistungen herangezogen.
Alle Messungen wurden an der SF 10 Datenbank vorgenommen.
Abb. 3.3 zeigt den Speedup f�ur jede einzelne Query bei Verwendung von 16 Pro-
zessoren. Die durchschnittliche E�zienz betr�agt dabei 50%, mit einer Streuung
von 24% bis 93%. Bedenkt man, da� bis hierhin noch keinerlei Tuning der Queries
stattgefunden hat, ist dieses Ergebnis nicht hoch genug zu bewerten.
13
246810
12
14
16
Speedup
1
2
3
6
7
8
10
12
13
QueryNr.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Abbildung3:Speedupf �urunterschiedlicheQueries
14
Im folgenden sollen die vier ausgesuchten Queries 1, 2, 8 und 12 n�aher besprochen
werden. Der Querytext be�ndet sich in Anhang F.3.
3.6.1 Query 1
Bei dieser Query wird eine Tabelle (1GB Daten) unter einer Bedingung durch-
sucht. Der QD hat diese Query auf Anhieb parallelisiert. Das Ergebnis ist Abb.
3.4 zu entnehmen.
2
4
6
8
10
12
14
16
18
20
22
24
26
28
30
32
Speedup
2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 32
Prozessoren
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
?
?
?
?
?
?
� � � linearer Speedup
Abbildung 3.4: Speedup f�ur Query 1
W�ahrend die restlichen Queries nur auf 16 Prozessoren ausgemessen wurden,
wurde Query 1 auch auf 32 Prozessoren gemessen. Der relativ starke Abfall der
E�zienz von 93% bei 16 Prozessoren auf 81% bei 32 Prozessoren hat sicherlich
zwei Ursachen, zum einen sind 5 Prozessoren zus�atzlich mit I/O{Operationen
besch�aftigt, bei den Messungen mit 16 Prozessoren waren alle 16 Prozessoren frei
von I/O{Operationen; zum anderen wurden pro Laufwerk 2 Dateien angelegt, da
keine 32 Laufwerke vorhanden sind.
Mit dieser Query wurden die besten Ergebnisse erzielt.
15
3.6.2 Query 2
Diese Query, die eine Subquery enth�alt, parallelisiert zwar auch auf Anhieb, wie
jedoch Abb. 3.5 zeigt, ist der Speedup sehr gering.
2
4
6
8
10
12
14
16
Speedup
2 4 6 8 10 12 14 16
Prozessoren
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
??
?
??
� � � linearer Speedup
Abbildung 3.5: Speedup f�ur Query 2
Die Gr�unde f�ur die schlechte Skalierung liegen nicht auf der Hand, zum einen kann
es am QD liegen, es kann aber auch am Oracle Optimizer liegen. Eine ver�anderte
Abspeicherung der 3 involvierten Tabellen, z. B. als Cluster, k�onnte ebenfalls eine
Verbesserung der Performance bringen.
3.6.3 Query 8
Der urspr�ungliche Querytext enthielt mehrere geschachtelte Views, wegen derer
der QD nicht parallelisieren konnte. Aus diesem Grund wurde die Query umfor-
muliert. Die Views konnten elimiert werden, soda� der QD aktiv werden konnte,
da� Ergebnis aber nicht ver�andert wurde. Abb. 3.6 zeigt die Skalierung f�ur Query
8.
Bemerkenswert ist, da� durch die Umformulierung die Einprozessor{Laufzeit um
30% verk�urzt werden konnte.
3.6.4 Query 12
Der QD ist nicht in der Lage ein 'UNIONALL' Statement, welches in dieser Query
verwendet wird zu parallelisieren. Daher mu�te auch diese Query umformuliert
16
2
4
6
8
10
12
14
16
Speedup
2 4 6 8 10 12 14 16
Prozessoren
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
?
?
?
?
?
� � � linearer Speedup
Abbildung 3.6: Speedup f�ur Query 8
werden, damit der QD parallelisieren konnte. Die Ergebnisse f�ur Query 12 sind
in Abb. 3.7 dargestellt.
2
4
6
8
10
12
14
16
Speedup
2 4 6 8 10 12 14 16
Prozessoren
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
?
?
?
?
?
� � � linearer Speedup
Abbildung 3.7: Speedup f�ur Query 12
Wiederum ergab sich f�ur die umformulierte Query eine diesmal um einen Faktor
2 reduzierte Einprozessor{Laufzeit.
17
Kapitel 4
Oracle 7.0 auf SNI H60, BS2000
Der SNI Rechner am Rechenzentrum der Universi�at Mannheim ist vom Typ
H60-F2 mit einem Prozessor und 32 MB Hauptspeicher. Die Leistung des Pro-
zessors betr�agt ca. 5.5 Mips. Der freie Plattenplatz f�ur das Projekt betr�agt ca.
1.5 GB.
Entsprechend der Zielsetzung des Projekts sollte Oracle 7.0 mit SQL*Net auf
dem BS2000 Rechner installiert werden. Da die Kon�guration des Rechners nicht
prim�ar f�ur Datenbankanwendungnen ausgelegt ist, sollte haupts�achlich die Funk-
tionalit�at von Oracle mit der Netzverbindung zur KSR1 getestet werden.
4.1 Installation
Zum Betrieb von Oracle Version 7.0 auf BS2000 mit SQL*Net sind die Versio-
nen TCP-IP-AP V1.0 und BCAM/DCAM V11.0 erforderlich, die f�ur die H60
bescha�t werden mu�ten.
Ende der Kalenderwoche 9 ist die ORACLE BS2000 Software zusammen mit
den notwendigen Zus�atzen im Rechenzentrum in Mannheim angekommen. Im
einzelnen handelt es sich um folgende Software:
ORACLE Server 7.0.13.0.40
SQL*DBA 7.0.13.0.40
SQL*Loader 7.0.13.0.40
PL/SQL 2.0.15.0.40
SQL*Plus 3.1.1.9.40
SQL*Net 7.0.13.0.40
TCP/IP NET SERVER 1.2.7.1.40
ONC 1.0.0.2.40
18
Die Installation von Oracle wurde in der Kalenderwoche 10 durchgef�uhrt aber die
notwendigen Systemarbeiten am BS2000 haben sich noch bis zur Kalenderwoche
12 hingezogen.
4.2 Laden der Datenbank
Die Test-Datenbank wurde ohne besondere Optimierungen, nur mit den einge-
stellten Default-Werten erzeugt. Die Gr�o�e der Datenbank war ca. 100 MB ent-
sprechend dem Skalierungsfaktor 1.
Die Ladedaten wurden als ASCII File von der KSR1 per ftp in ca 20 min �Ubertra-
gen. Das Laden selbst wurde mit SQL*Load mit der Option direct=true durch-
gef�uhrt. Die Zeit betrug etwa 80 min.
4.3 Queries
Die vorgesehenen Queries konnten ohne besondere Vorbereitungen direkt von der
KSR1 �ubernommen werden.
Die Zeiten f�ur die Queries mit SF=1, nachts gemessen, waren:
Q1: CPU Time 1509.07 sec
Q2: CPU Time 182.17 sec
Q8: CPU Time 641.16 sec
Q12: CPU Time 1110.59 sec
Die Zeiten liegen in der Gr�o�enordnung der Zeiten auf einem Prozessor der KSR1
mit der alten Oracle Version.
19
Kapitel 5
Oracle Kopplung BS2000 {
KSR1
Oracle bietet die M�oglichkeit auf Datenbanken (insbesondere auf einzelne Tabel-
len) auf verschiedenen Rechnern und gar auf verschiedenen Rechnerarchitekturen
zuzugreifen. Die Verbindung wird �uber die SQL*Net Software, die in unserem
Falle TCP/IP verwendet, hergestellt.
Als Verbindungsvarianten gibt es die M�oglichkeit sich direkt mit einer SQL*Plus
Sitzung auf dem anderen Rechner `einzuloggen', oder es gibt die M�oglichkeit aus
einer SQL*Plus Sitzung auf einem Rechner einen Link auf eine Tabelle auf einem
anderen Rechner herzustellen. Mit dem Link kann dann wie mit einer lokalen
Tabelle gearbeitet werden.
Bei der Datenbank Kopplung stand zun�achst die Funktionalit�at im Vordergrund,
Performance-Daten waren nur f�ur die Gr�o�enordnung wichtig.
5.1 Installation
Die TCP/IP Software wurde auf der BS2000 Seite auf den neuesten Stand ge-
bracht. `telnet', `ftp' usw. funktionieren unabh�angig von Oracle.
Die Installation der SQL*Net Verbindung erforderte die Verwendung eines nicht-
priviligierten TCP/IP Ports (=3000) auf der BS2000. Mit der Oracle Version
7.0.12 auf der KSR1 kam keine Verbindung �uber SQL*Net zustande. Der Fehler
war immer ORA-6136. Mit der Oracle Version 7.0.13 auf der KSR1 kommen nun
Verbindungen �uber SQL*Net zustande. Die SQL*Net Verbindung funktioniert
im Moment nur von BS2000 nach KSR1, die umgekehrte Richtung KSR1 nach
BS2000 bringt noch Fehlermeldungen. Daher gibt es auch noch keine Zeiten f�ur
`snapshot' der DB von der BS2000 nach KSR1. Das `insert into' von Tabellen
20
von BS2000 von und nach KSR1 funktioniert.
Es funktioniert auf der BS2000 Seite
sqlplus BS2000 ---> KSR1
create database link BS2000 ---> KSR1
insert into BS2000 ---> KSR1
insert into KSR1 ---> BS2000
create snapshot KSR1 ---> BS2000.
5.2 Datenbank Kommunikation
Die �Ubertragungstests wurden zun�achst ohne besondere Optimierungen in der
gegebenen Kon�guration durchgef�uhrt. Durch den Initialisierungsoverhead sind
bei kleineren Tabellen die �Ubertragungsraten schlechter als bei gr�o�eren Tabellen.
Das TCP/IP Netz ist in unserer Kon�guration nicht der Engpass.
Es ergaben sich folgende Datenraten
7.5 - 8.6 KB / sec f�ur das �Ubertragen mit DB Tools,
18.6 KB / sec f�ur das Laden auf BS2000,
163.6 KB / sec f�ur das �Ubertragen mit TCP/IP Tools.
Die Daten�ubertragungsrate mit DB Tools ist somit etwa 0.5 MB / min, d.h. 30
MB / h. Eine Datenbank von 1 GB w�urde somit etwas mehr als einen Tag f�ur
die �Ubertragung ben�otigen.
Das �Ubertragen von Tabellen mittels Oracle SQL*Net von der BS2000 zur KSR1
dauert etwa 2 bis 2.5 mal die Zeit des Ladens dieser Tabelle auf der BS2000 Seite.
Die CPU Zeit ist f�ur das Schreiben von Tabellen etwa 2 mal so hoch wie f�ur das
Lesen von Tabellen.
Eine bessere Alternative zu `insert into' stellt ein `snapshot' der Datenbank dar.
Ein `snapshot' ist eine `read only' Kopie der DB, d.h. man kann alle Abfragen
durchf�uhren, aber keine Modi�kationen. Der `snapshot' einer Tabelle ist etwa 10
bis 20 % schneller als das entsprechende `insert into'.
21
Kapitel 6
Zusammenfassung
Es konnte nachgewiesen werden, da� die KSR1 als ORACLE-Datenbankbackend
f�ur einen BS2000 Mainframe gut geeignet ist.
Dies basiert auf folgenden Ergebnissen:
� Die Interoperabilit�at beider Anlagen ist bez�uglich Hardware und Software
gut m�oglich.
� Die Oracle Software auf der KSR1 ist stabil und uneingeschr�ankt benutzbar.
� Die zugrundeliegende Decision Support Anwendung ist sehr gut paralleli-
sierbar; die grobk�ornige Parallelit�at liefert praktisch einen idealen, linearen
Speedup.
� Obwohl ein einzelner Prozessor der KSR1 bei dieser Anwendung nur et-
wa die Leistung einer SNI H60 ausweist, gew�ahrleistet die Architektur der
KSR1 beliebige Skalierbarkeit bez�uglich der Rechenleistung.
� Auch bez�uglich der Datenbankgr�o�e (gemessen bis 1 GB) konnten wir mit
der KSR1 eine sehr gute Skalierbarkeit nachweisen.
Eine weitere Leistungsverbesserung lie�e sich erreichen, wenn zus�atzlich zu den
parallelisierten Datenbankabfragen, auch das parallele Laden und Update der
Datenbank genutzt w�urde. Diese Funktionalit�at ist f�ur die Oracle Version 7.1
angek�undigt und auch im Query Decomposer von KSR enthalten.
6.1 Ausblick
Um ein vollst�andigeres Bild der Parallelisierbarkeit von Decision Support An-
wendungen zu erhalten, w�are es sinnvoll den gesammten Benchmark mit gr�o�e-
22
ren Datenbanken und mehr Prozessoren weiter zu f�uhren. Insbesondere bleiben
folgende Probleme:
1. Test der Oracle Version 7.1.
2. Tests im Mehrbenutzerbetrieb.
3. Testen des parallelen Ladens der DB.
4. Testen der parallelen Queries von der BS2000 Seite aus.
5. Analyse des Ein u�es der KSR1 Architektur.
6. Analyse der Systemresourcen.
23
Anh�ange
In den folgenden Anh�angen werden die verschiedenen Zeitpl�ane, Datenbank De-
�nitionen und Queries, sowie die Messungen dokumentiert.
Die Mitarbeiter und Unterst�utzer der Projektgruppe waren
RZ Universit�at Mannheim:
Prof. Dr. H.-W. Meuer, Dr. H. Kredel, Dr. R. Schumacher, Dr. E. Stroh-
maier, Hr. R. M�uller.
FB Wirtschaft Fachhochschule L�uneburg:
Prof. Dr. H. Meyer-Wachsmuth, Hr. T. Slotos.
Kendall Square Research (KSR):
Hr. Henry Strau�, Mch, Ph.D. Stephen Pass, UK, Hr. David Wheat, USA.
Siemens Nixdorf Informationssysteme (SNI):
Hr. Ewinger, Mch-P SU BS2, Dr. Biller,Mch-P SU BS2, Dr. K�ostler, Mch-P
SU BS2, Hr. Prohl, MA.
24
Anhang A
Projektstatistik
Sondierungsgespr�ache im Herbst 1993.
Erstes Tre�en der Projektgruppe am 24. Januar 1994.
Letztes Tre�en der Projektgruppe am 19. Mai 1994.
Zeitdauer: 4 Monate, Februar bis Mai 1994.
Tre�en: 5 Sitzungen, 24.1., 7.2., 24.3., 14.4. und 19.5. 1994.
2 Tage Besuch eines Oracle Experten von KSR UK vom 14.4. bis 15.4.
5 Tage Besuch eines Oracle Experten von KSR USA vom 16.5. bis 20.5.
Kommunikation: im Wesentlichen mittels E-Mail, zum Teil per FAX und
Telefon.
W�ochentliche Projektberichte �uber eine Projekt-Mailing-Liste.
Personalaufwand: 6 Mannmonate.
vorhandene Resourcen:
1. SNI H60, BS2000, 32 MB, 5.5 Mips, 1.5 GB Platten,
2. KSR1, OSF1 Unix, 32 Prozessoren, 1 GB, 32*40=1280 Mips, 10 GB
Platten,
3. TCP/IP �uber Ethernet Verbindungen.
zus�atzlicher Sachaufwand:
1. Oracle 7.0 Demo Lizenz f�ur BS2000,
2. neue Versionen von TCP/IP und DCAM f�ur BS2000,
25
Anhang B
Arbeitsplan, Zeitplan
Arbeitsplan vom Februar 1994.
Zeit Aktivit�aten
6. KW Kl�arung der Hardwarevoraussetzungen,
Installation von DBGEN, Erstellung der Queries,
Laden und Messungen auf AIX in L�uneburg,
Installation von Oracle auf KSR1 und SNI BS2000,
bis 9. KW Installation und Test des SQL*net.
10. KW Erstellung der ca. 1 GB grossen Testdatenbank,
Messung der 4 wichtigten Queries
auf SNI BS2000 und KSR1 ohne und Parallelisierung.
11. KW Auswertung und Analyse mit KSR Experten,
Entscheidungen �uber weiteres Vorgehen und
weiteren Zeitplan.
12. und 13. KW Tuning und Optimierungen der Datenbank.
Durchf�uhrung weiterer Queries,
Messung der Lade- und Updatezeiten,
bis 19. KW Vervollst�andigung der Messungen.
`KW' bedeutet Kalenderwoche im Jahr 1994.
27
Aktualisierter Arbeitsplan vom M�arz 1994.
Zeit Aktivit�aten
bis 14. KW Kl�arung der HW/SW Situation,
Vorbereiten der Queries und Messungen in L�uneburg,
Installation von Oracle auf KSR1 und BS2000,
Installation der Verbindung �uber SQL*Net,
bis Datenbank gr�o�e 1 GB, 4 Queries.
15. KW Messung der 4 wichtigten Queries
auf KSR1 ohne und mit Parallelisierung,
(BS2000 nicht zwingend im ersten Schritt),
Verbindung BS2000 - KSR1 �uber SQL*Net.
14.4. Auswertung und Analyse mit KSR-Experten.
16. KW Entscheidungen �uber Weiteres Vorgehen,
bis 19. KW Tuning und Optimierungen der Datenbank.
20. KW Messungen mit Oracle SQL*Net, BS2000 - KSR1,
21. KW Parallelisierung, Laden und update der DB auf KSR1,
Hinzunahme weiterer Queries aus dem Benchmark,
Gr�o�ere Datenbank, weitere Queries.
Aktualisierter Arbeitsplan vom April 1994.
Zeit Aktivit�aten
Ende KW 17 hochskalieren der DB bis 1 GB,
Load / Unload BS2000 - KSR1 �uber SQL*Net,
Entscheidung �uber Plattenbescha�ung 10 GB.
18. KW Durchf�uhrung der Queries, Parallelisierung,
Vorl�au�ger Bericht �uber das Projekt,
20. KW Hinzuziehen eines KSR Oracle Experten aus USA,
Abschlu� Bericht und Sitzung �uber das Projekt.
28
Anhang C
Messungen auf KSR1
C.1 Messungen auf einem Prozessor
Ergebnisse der Queries mit Oracle Version 7.0.13 auf einem Prozessor.
SF 1 SF 10 SF 10
Neufassung
Q 1: 1281.0 sec 11993 sec --
Q 2: 206.0 sec 1381 sec --
Q 8: 1128.0 sec 4715 sec 3670 sec
Q12: 852.0 sec 8895 sec 4108 sec
C.2 Messungen f�ur verschiedene Verteilungen
Ergebnisse f�ur unterschiedliche Verteilung der Tabellen auf Dateien.
Ergebnisse f�ur SF 1
cpu disk files 7.0.12 7.0.13
1 1 1 1436 1281
1 1 16 - 1230
2 1 2 629
2 2 2 879 621
3 1 3 447
3 3 3 437
4 1 4 344
4 2 4 329
4 4 4 425 342
6 2 6 253
29
6 3 6 235
8 2 8 202
8 4 8 227 194
9 3 9 171
12 3 12 140
12 4 12 157 128
16 4 16 142 116
Ergebnisse f�ur SF 10
cpu disk files 7.0.13
1 4 16 12933*
1 4 4 12534*
2 4 4 6113*
4 4 4 3210**
8 4 16 1760*
16 4 16 962
* Ergebnis aus 1 Messung.
** Ergebnis aus 2 Messungen.
Bemerkungen:
� Von Version 7.0.12 auf 7.0.13 ist eine Leistungsteigerung von 20% aufgetre-
ten.
� Die verbrauchte CPU{Zeit (die Messung geschah mit dem Betriebssystem)
schwankte zwischen 10%, unabh�angig von Anzahl der CPUs, Files oder
Disks.
� Die System-Zeit, sie betr�agt zwischen 5% und maximal 10% der CPU-Zeit,
steigt mit der Anzahl der Files.
C.3 Ergebnisse f�ur die einzelnen Queries
Query 1:
cpu time
1 11993
2 5990
4 2966
8 1532
16 805
32 462
30
Query 2:
cpu time
1 1381
2 932
4 572
8 406
16 362
Query 3:
cpu time
1 12526
2 7239
4 4266
8 2495
16 2220
Query 6:
cpu time
1 2221
2 1090
4 595
8 310
16 184
Query 7:
cpu time
1 12946
2 8378
4 4585
8 2404
16 1573
Query 8:
cpu time
1 3670
2 2052
4 1214
8 907
16 658
31
Query 10:
cpu time
1 6251
2 3698
4 2156
8 1608
16 865
Query 12:
cpu time
1 4108
2 2356
4 1142
8 675
16 393
Query 13:
cpu time
1 403
2 232
4 132
8 80
16 60
32
Anhang D
Messungen auf SNI H60
Die Zeiten wurden mit `set timing on' von Oracle erhalten. Das Laden der Da-
tenbank mit SF=1, ca. 100 MB Daten ben�otigte 80 min Elapsed time und 68 min
CPU time.
Die Zeiten f�ur die einzelnen Tabellen waren
Tabelle Elapsed Time CPU Time
SUPPLIERS 17.80 sec 6.37 sec
LINEITEM 61:36.52 min 52:30.97 min
PARTSUPP 5:03.70 min 3:49.93 min
PARTS 1:32.08 min 1:11.00 min
ORDERS 10:22.68 min 8:23.33 min
CUSTOMES 1:37.38 min 1:14.63 min
Die Zeiten f�ur die Queries mit SF=1 waren:
tagsueber nachts
Q1: CPU Time 1521.6 sec 1509.07 sec
Q2: CPU Time 184.6 sec 182.17 sec
Q8: CPU Time 4622.4 sec 641.16 sec
Q12: CPU Time 1127.2 sec 1110.59 sec
33
Anhang E
Messungen der Kopplung
Die `Elapsed Times' wurden mit der `Wall Clock' gemessen. Die `CPU Times'
wurden den Oracle Meldungen auf der BS2000 entnommen, bzw. dem Zeitver-
brauch von orasrv auf der KSR1.
Insert in Tabelle auf der KSR1 via SQL*Net database link, select von einer Ta-
belle auf BS2000:
Tabelle: suppliers mit 1000 rows, 0.1 MB
Elapsed time 40 sec,
CPU time H-60 4.4 sec
CPU time KSR1 5.7 sec.
Zum Vergleich: das Laden dieser Tabelle dauert ca. 18 sec auf der BS2000 und
das �Ubertragen der ASCII Datei per ftp dauert ca. 1 sec.
Damit ergeben sich folgende Datenraten
2.5 KB / sec f�ur das �Ubertragen mit DB Tools,
5.6 KB / sec f�ur das Laden,
100.0 KB / sec f�ur das �Ubertragen mit TCP/IP Tools.
Tabelle: customers mit 15000 rows, 1.8 MB
Elapsed time 210-240 sec,
CPU time H-60 73 sec (read)
CPU time KSR1 77 sec (write).
Zum Vergleich: das Laden dieser Tabelle dauert ca. 97 sec auf der BS2000 und
das �Ubertragen der ASCII Datei per ftp dauert ca. 11 sec.
Damit ergeben sich folgende Datenraten
34
7.5 - 8.6 KB / sec f�ur das �Ubertragen mit DB Tools,
18.6 KB / sec f�ur das Laden,
163.6 KB / sec f�ur das �Ubertragen mit TCP/IP Tools.
Die Daten�ubertragungsrate mit DB Tools ist somit etwa 0.5 MB / min, d.h. 30
MB / h. Eine Datenbank von 1 GB w�urde somit etwas mehr als einen Tag f�ur
die �Ubertragung ben�otigen.
Insert in Tabelle auf der BS2000 via SQL*Net database link, select von einer
Tabelle auf KSR1:
Tabelle: customers mit 15000 rows, 1.8 MB
Elapsed time 310 sec,
CPU time H-60 169 sec (write)
CPU time KSR1 30 sec (read).
Snapshot auf der BS2000 via SQL*Net, select von einer Tabelle auf KSR1:
Tabelle: customers mit 15000 rows,
Elapsed time 290 sec,
CPU time H-60 180 sec (write)
CPU time KSR1 38 sec (read).
35
Anhang F
Listings
In diesem Abschnitt werden die wesentlichen SQL Statements zur De�nition der
Test-Datenbank und der Abfragen dokumentiert.
F.1 De�nition der Datenbank
set echo on
DROP TABLE customers;
CREATE TABLESPACE tsc
DATAFILE 'tsc.dbf' SIZE 4M REUSE;
CREATE TABLE customers
(
c_custkey number(12) NOT NULL,
c_name char(25),
c_address char(25),
c_nation char(25),
c_region char(25),
c_phone char(15),
c_acctbal number(12,2),
c_mktsegment char(10),
c_comment char(27)
)
TABLESPACE tsc
STORAGE (INITIAL 100K NEXT 100K PCTINCREASE 0);
CREATE UNIQUE INDEX i_customers ON customers
(
c_custkey
)
TABLESPACE tsc;
36
DROP TABLE lineitem;
CREATE TABLESPACE tsl
DATAFILE 'tsl.dbf' SIZE 150M REUSE;
CREATE TABLE lineitem
(
l_orderkey number(12) NOT NULL,
l_partkey number(12),
l_suppkey number(12),
l_linenumber number(12) NOT NULL,
l_quantity number(12),
l_extendedprice number(12,2),
l_discount number(12),
l_tax number(12),
l_returnflag char(1),
l_linestatus char(1),
l_shipdate date,
l_commitdate date,
l_receiptdate date,
l_shipinstruct char(25),
l_shipmode char(10),
l_comment char(59)
)
STORAGE ( INITIAL 1000K NEXT 1000K PCTINCREASE 0 )
TABLESPACE tsl;
CREATE UNIQUE INDEX i_lineitem ON lineitem
(
l_orderkey,
l_linenumber
)
TABLESPACE tsl;
DROP TABLE orders;
CREATE TABLESPACE tso
DATAFILE 'tso.dbf' SIZE 30M REUSE;
CREATE TABLE orders
(
o_orderkey number(12) NOT NULL,
o_custkey number(12),
o_orderstatus char(1),
o_totalprice number(12,2),
o_orderdate date,
o_orderpriority char(15),
o_clerk char(15),
o_shippriority number(12),
37
o_comment char(49)
)
TABLESPACE tso
STORAGE (INITIAL 6000K NEXT 3000K PCTINCREASE 0);
CREATE UNIQUE INDEX i_orders ON orders
(
o_orderkey
)
TABLESPACE tso;
DROP TABLE parts;
CREATE TABLESPACE tsp
DATAFILE 'tsp.dbf' SIZE 4700K REUSE;
CREATE TABLE parts
(
p_partkey number(12) NOT NULL,
p_name varchar2(50),
p_mfgr char(25),
p_brand char(10),
p_type char(25),
p_size number(12),
p_container char(10),
p_retailprice number(12,2),
p_comment char(14)
)
TABLESPACE tsp
STORAGE (INITIAL 1000K NEXT 1000K PCTINCREASE 0);
CREATE UNIQUE INDEX i_parts ON parts
(
p_partkey
)
TABLESPACE tsp;
DROP TABLE partsupp;
CREATE TABLESPACE tsps
DATAFILE 'tsps.dbf' SIZE 20M REUSE;
CREATE TABLE partsupp
(
ps_partkey number(12) NOT NULL,
ps_suppkey number(12) NOT NULL,
ps_availqty number(12),
ps_supplycost number(12,2),
ps_comment char(124)
38
)
TABLESPACE tsps
STORAGE (INITIAL 500K NEXT 500K PCTINCREASE 0);
CREATE UNIQUE INDEX i_partsupp ON partsupp
(
ps_partkey,
ps_suppkey
)
TABLESPACE tsps;
DROP TABLE suppliers;
CREATE TABLESPACE tss
DATAFILE 'tss.dbf' SIZE 500K REUSE;
CREATE TABLE suppliers
(
s_suppkey number(12) NOT NULL,
s_name char(25),
s_address char(25),
s_nation char(25),
s_region char(25),
s_phone char(15),
s_acctbal number(12,2),
s_comment char(17)
)
TABLESPACE tss;
CREATE UNIQUE INDEX i_suppliers ON suppliers
(
s_suppkey
)
TABLESPACE tss;
F.2 Queries
Query 1:
set echo on;
set timing on;
select
l_returnflag, l_linestatus, sum(l_quantity), sum(l_extendedprice),
sum(l_extendedprice * (1 - l_discount/100)),
sum(l_extendedprice * (1 - l_discount/100) * l_tax/100),
avg(l_quantity),
avg(l_extendedprice), avg(l_discount), count(*)
from lineitem
39
where l_shipdate <= to_date('01-DEC-98') - 90
group by l_returnflag, l_linestatus
order by l_returnflag, l_linestatus;
Query 2:
set echo on;
set timing on;
select
s_name, s_acctbal, s_address, s_phone, s_comment
from parts, suppliers, partsupp
where p_partkey = ps_partkey
and s_suppkey = ps_suppkey
and p_size = 15
and p_type = 'BRASS'
and s_nation = 'FRANCE'
and ps_supplycost = (select min(ps_supplycost)
from partsupp ps1, suppliers s1
where p_partkey = ps1.ps_partkey
and s1.s_suppkey = ps1.ps_suppkey
and s1.s_nation = s_nation);
Query 8:
set echo on;
set timing on;
create view country (year, volume) as select
to_char(o_orderdate, 'YY'), l_extendedprice*(1-l_discount/100)
from parts, suppliers, lineitem, orders, customers
where p_partkey = l_partkey
and s_suppkey = l_suppkey
and l_orderkey = o_orderkey
and o_custkey = c_custkey
and c_nation = s_nation
and o_orderdate between to_date('01-JAN-95')
and to_date('31-DEC-96')
and c_nation = 'BRAZIL'
and p_type = 'STEEL';
create view sum_country (year, volume) as select
year, sum(volume)
from country
group by year;
create view continent (year, volume) as select
to_char(o_orderdate,'YY'), l_extendedprice*(1-l_discount/100)
from parts, suppliers, lineitem, orders, customers
where p_partkey = l_partkey
and s_suppkey = l_suppkey
and l_orderkey = o_orderkey
and o_custkey = c_custkey
40
and c_region = s_region
and o_orderdate between to_date('01-JAN-95')
and to_date('31-DEC-96')
and c_region = 'AMERICA'
and p_type = 'STEEL';
create view sum_continent (year, volume) as select
year, sum(volume)
from continent
group by year;
select
a.year, a.volume/b.volume
from sum_country a, sum_continent b
where a.year = b.year;
drop view country;
drop view sum_country;
drop view continent;
drop view sum_continent;
Query 12:
set echo on;
set timing on;
select
l_shipmode, count(*), 'High Priority'
from orders, lineitem
where o_orderkey = l_orderkey
and o_orderpriority in ('1-URGENT', '2-HIGH')
and (l_shipmode = 'MAIL' or l_shipmode = 'SHIP')
and l_commitdate < l_receiptdate
and l_shipdate < l_commitdate
and l_receiptdate >= to_date('01-JAN-94')
and l_receiptdate < to_date('01-JAN-94') + 360
group by l_shipmode
union all
select
l_shipmode, count(*), 'Low Priority'
from orders, lineitem
where o_orderkey = l_orderkey
and o_orderpriority in ('1-URGENT', '2-HIGH')
and (l_shipmode = 'MAIL' or l_shipmode = 'SHIP')
and l_commitdate < l_receiptdate
and l_shipdate < l_commitdate
and l_receiptdate >= to_date('01-JAN-94')
and l_receiptdate < to_date('01-JAN-94') + 360
group by l_shipmode
order by 2 desc;
41
F.3 Umformulierte Queries
Neufassung von Query 8:
select
to_char(o_orderdate, 'YY'),
sum(decode(c_nation, 'BRAZIL ',
decode(s_nation, 'BRAZIL ',
l_extendedprice*(1-l_discount/100), 0), 0))
/ sum(l_extendedprice*(1-l_discount/100))
from parts, suppliers, lineitem, orders, customers
where p_partkey = l_partkey
and s_suppkey = l_suppkey
and l_orderkey = o_orderkey
and o_custkey = c_custkey
and c_region = s_region
and o_orderdate between '01-JAN-95' and '31-DEC-96'
and c_region = 'AMERICA'
and p_type = 'STEEL'
group by to_char(o_orderdate, 'YY');
Neufassung von Query 12:
select l_shipmode, count(*),
decode(o_orderpriority, '1-URGENT ', 'High Priority',
'2-HIGH ', 'High Priority',
'Low Priority')
from orders, lineitem
where o_orderkey = l_orderkey
and (l_shipmode = 'MAIL' or l_shipmode = 'SHIP')
and l_commitdate < l_receiptdate
and l_shipdate < l_commitdate
and l_receiptdate >= to_date('01-JAN-94')
and l_receiptdate < to_date('01-JAN-94') + 360
group by l_shipmode,
decode(o_orderpriority, '1-URGENT ', 'High Priority',
'2-HIGH ', 'High Priority',
'Low Priority')
order by 2 desc;
42