Oracle Datenbankkopplung SNI BS2000 { KSR1

Transcription

Oracle Datenbankkopplung
SNI BS2000 { KSR1
Heinz Kredel, Robert Schumacher (eds.)
Rechenzentrum Universitat Mannheim
RUM 37/94
Juni 1994
Vorwort
Der folgende Bericht ist aus einer Ausarbeitung von Teilen eines internen Arbeitsberichts der Projektgruppe Datenbankkopplung entstanden. Das Projekt diente
der Evaluierung einer Oracle Datenbank-Kopplung fur Decision Support Anwendungen zwischen einem SNI BS2000 Rechner und einem KSR1 massiv parallelen
Rechner. Der Bericht gibt zunachst die Aufgabenstellung an und diskutiert dann
die Ergebnisse der einzelnen Teilaufgaben. In den Anhangen werden die durchgefuhrten Messungen und wichtige Parameter dokumentiert.
Zu den Zeitmesungen ist zu bemerken, da unsere Hard- und Software Konguration den Bedurfnissen einer Universiat entspricht. D.h. wir haben keine spezielle
Datenbank Hardware (leistungsfahiger I/O, dedizierter Rechner) und besitzen
auch nicht die Oracle Tuning Kenntnisse von groen Datenbank Anwendern.
Dieser Text bendet sich auch auf dem FTP Server der Universitat Mannheim
ftp.uni-mannheim.de in dem Verzeichniss pub/info/rumdoc in der komprimierten PostScript Datei rum3794.ps.Z.
Verbesserungsvorschlage 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 Durchfuhrung
6
2.1 Wahl der Datenbank
2.2 Wahl der Abfragen
: : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : :
3 Oracle 7.0 auf KSR1, Unix
3.1
3.2
3.3
3.4
3.5
3.6
Funktionsweise des Query{Decomposer von KSR
Installation und Betriebserfahrungen mit Oracle auf der KSR1
Generierung und Laden der Daten
Verwendete Begrie
Performance in Abhangigkeit der Verteilung der Daten
Performance fur unterschiedliche Queries
3.6.1 Query 1
3.6.2 Query 2
3.6.3 Query 8
3.6.4 Query 12
8
: : : : : : : : : :
: :
: : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : :
: : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : :
4 Oracle 7.0 auf SNI H60, BS2000
4.1 Installation
4.2 Laden der Datenbank
4.3 Queries
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
5 Oracle Kopplung BS2000 { KSR1
5.1 Installation
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
2
6
6
8
10
10
11
11
12
15
16
16
16
18
18
19
19
20
20
5.2 Datenbank Kommunikation
: : : : : : : : : : : : : : : : : : : : :
6 Zusammenfassung
6.1 Ausblick
21
22
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
22
A Projektstatistik
25
B Arbeitsplan, Zeitplan
27
C Messungen auf KSR1
29
C.1 Messungen auf einem Prozessor
C.2 Messungen fur verschiedene Verteilungen
C.3 Ergebnisse fur die einzelnen Queries
: : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : :
29
29
30
D Messungen auf SNI H60
33
E Messungen der Kopplung
34
F Listings
36
F.1 Denition der Datenbank
F.2 Queries
F.3 Umformulierte Queries
: : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : :
3
36
39
42
Kapitel 1
Aufgabenstellung
Ziel der Evaluierung der Datenbank-Kopplung ist die Sammlung von Erfahrungen
und die Gewinnung von Performancedaten fur den Einsatz eines KSR1 massiv
parallelen Rechners als Datenbankbackend fur eine SNI-BS2000 Anlage. Insbesondere soll festgestellt werden, ob eine solche Konguration fur den Einsatz im
praktischen Betrieb geeignet ist. Die Universitat Mannheim und die Fachhochschule Luneburg erwarten bei der Evaluierung Erfahrungen im Betrieb von Datenbanken auf massiv parallelen Rechnern sowie wissenschaftliche Erkenntnisse
bei der Parallelisierung von Decision Support Problemen.
Das Rechenzentrum der Universitat 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, Durchfuhrung und Unterstutzung bei der Installation der Software und der Netzkopplung.
Einrichten und Laden der Test-Datenbank, Durchfuhrung der Test-Queries.
Der FB Wirtschaft der Fachhochschule Luneburg, vertreten durch Herrn Prof.
Dr. Mayer-Wachsmuth, unterstutzt die Evaluierung bei
dem Aufbau einer geeigneten Oracle Testdatenbank,
der Formulierung und Durchfuhrung der Datenbankabfragen,
und der Durchfuhrung 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 Universitat Mannheim vorhanden,
die Bereitstellung eventuell zusatzlicher Hardware, um eine sinnvolle Evaluierung zu ermoglichen,
die Kosten fur Personal (bis zu einem maximalen Betrag),
eventuell anfallende Reisekosten und Spesen.
Die Evaluierung wird vom 1. Februar 1994 bis zum 31. Mai 1994 durchgefuhrt.
Der genauere Zeitplan ist im Anhang enthalten.
5
Kapitel 2
Zur Durchfuhrung
Aufgrund der heterogenen Systemumgebung eignet sich besonders das Oracle 7.0
Datenbanksystem. Oracle 7.0 ist sowohl fur BS2000 als auch fur KSR1 Rechner
verfugbar und stellt mit SQL*Net alle erforderliche Kommunikationssoftware zur
Verfugung. Zusatzlich bietet die Firma KSR einen Query Decomposer (QD) fur
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
Fur den uns interessierenden Fall von Decision Support Anwendungen gibt es
einen von SNI verwendeten Datenbank Benchmark. Der Benchmark umfat u.A.
die Denition einer geigneten Test-Datenbank, Programme um den Inhalt der Datenbank zu erzeugen und auf DSS zugeschnittene Datenbank Abfragen. Die TestDatenbank ist skalierbar in Schritten von ca. 100 MB. Der Benchmark enthalt
Datenbank Abfragen, die zu einem `full table scan' fuhren und solche, die zu
komplexen `multiple join' Operationen fuhren. Beide Arten von Abfragen sollten
sich gut fur die Parallelisierung auf einem massiv parallelen Rechner eignen.
2.2 Wahl der Abfragen
Aus den 19 im Benchmark vorbereiteten Queries ist es sinnvoll sich zunachst auf
wenige typische Queries zu beschranken. Es sollen dabei unterschiedliche Typen
von Queries erfat 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 Universitat
Mannheim. Bei dem Rechner handelt es sich um ein skalierbares MPP (massiv
paralleles) System mit 32 Prozessoren, 1 GB Hauptspeicher und 10 GB Plattenspeicher. Die Leistung eines Prozessors mit der Taktrate von 20 MHz betragt 40
Mips bzw. 40 Mops.
Das Betriebssystem des Rechners ist OSF1 kompatibles UNIX, das symmetrisch
auf allen Prozessoren lauft. Die KSR1 ist mit FDDI und Ethernet in das Netz
der Universitat eingebunden.
Im folgenden werden die Funktionsweise des von KSR entwickeltem Query Decomposer dargestellt, und die Betriebserfahrungen mit Oracle auf der KSR1 geschildert, 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 fur Decision
Support Anwendungen (DSS) eine erhebliche Reduzierung der Antwortzeiten {
von mehreren Stunden auf einige Minuten { ermoglichen 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 Parallelitat die Query in Subqueries
zerlegt, die dann an Oracle ubergeben werden.
Fur jede Subquery wird ein eigener Proze gestartet. Nach Abarbeitung der Subqueries werden die Ergebnisse von dem QD wieder zusammengefuhrt. Findet der
8
QD keine Moglichkeit der Parallelisierung, erfolgt die weitere Behandlung der
Query, als wenn es den QD nicht gabe.
Voraussetzung fur die Parallelisierung ist, da die Tabellen auf mehrere Dateien
{ auf die dann parallel zugegrien werden kann { verteilt vorliegen. Es konnen
also maximal soviele Subqueries gestartet werden, wie Dateien vorliegen. U ber
Direktiven kann diese Zahl verringert werden, bzw. der QD auch abgeschaltet
werden.
Als Ausgangspunkt fur die Parallelisierung wahlt der QD die von Oracle bestimmte '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 fur Query 1 exemplarisch vorgefuhrt.
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) zugegrien, 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 uberspielen auf ein internes Plattenlaufwerk einsatzbereit. Die Installation erfolgte
am 31. Marz 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 diesem Zeitpunkt schon bestehende Testdatenbank konnte in vollem Umfang weiter
benutzt werden. Mittlerweile besteht die Datenbank aus uber 100 Dateien mit
uber 5 GB Gesamtkapazitat verteilt auf 16 Plattenlaufwerken.
Alle Oracle und SQL Funktionen sind vorhanden und nutzbar. Einzige Einschrankung 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 nachsten
Release, dessen Erscheinen fur Juni angekundigt ist, andern.
Folgende Software{Komponenten umfat 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
Wahrend der jetzt achtwochigen Erfahrung mit Oracle auf der KSR1 gab es
wegen Oracle keinerlei Absturze oder Einschrankungen fur den Betrieb zu verzeichnen. Weiterhin wurde die KSR1 wahrend der gesamten Zeit im Multiuser{
Timesharing{Betrieb gefahren. Die MTBF{Zeit der KSR1 fur April lag mit 7.5
Tagen (=30 Tage/4 Crashes) 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 Einu auf Pointer und
andere Groen, was bei der Umstellung beachtet werden mute.
10
Die Generierung der Daten fur Skalierungsfaktor (SF) 1 (600 000 Zeilen) betrug
ca. 33 min, fur SF 10 (6 000 000 Zeilen) ca. 6 Std. Das Laden der Daten im 'direct{
mode' betrug fur SF 1 ca. 45 min und fur SF 10 ca. 7 Std.
3.4 Verwendete Begrie
Die im Report benutzten Begrie { Wall{Clock Zeit, Ezienz und Speedup {
sollen kurz erlautert 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
mit. Naturlich ubernimmt ein Programm die Funktion der Wanduhr, in diesem
Fall wurden alle Zeiten mit der Oracle Funktion set timing on gemessen. Die
Ezienz wird aus den Wall{Clock Zeiten wie folgt berechnet: die Wall{Clock
Zeit 1 fur den Ein{Prozessor Lauf entspricht einer Ezienz von 100%, fur den
16{Prozessor Lauf errechnet sich die Ezienz damit: e16 = 1 (16 16), oder
allgemein en = 1 ( n), wenn die Anzahl der Prozessoren ist. Hieraus lat
sich wiederum der Speedup n berechnen mit: n = en .
t
t =
t = n t
t
n
Sp
Sp
n
3.5 Performance in Abhangigkeit der Verteilung der Daten
Die Parallelisierung einer Query auf der KSR erfolgt auf der Basis der vorhandenen Dateien fur 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 wesentlichen um die Fragestellung, ob die Festplattenkapazitat der Konguration (10
Platten a 1 GB, davon stehen fur die Messungen eektiv 4 Platten zur Verfugung)
ausreicht, um Aussagen uber die Performance zu machen. Aussagen von KSR zufolge, macht es erst Sinn Oracle zu betreiben, wenn man 20 und mehr Platten
zur Verfugung 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 Kongurationen auf einer
100MB groen Tabelle vermessen. Die genauen Ergebnisse sind in Anhang C zu
nden. Fur eine geringe Anzahl Dateien spielt deren Verteilung keine Rolle; bei 4
Dateien auf 4 Laufwerken erhalt man 94% Ezienz und bei 4 Dateien auf einem
Laufwerk 93% Ezienz. Erhoht sich die Anzahl der Dateien, ist eine Abnahme
der Ezienz zu beobachten, so ergibt sich bei 12 Dateien verteilt auf 4 Laufwerke
eine Ezienz von 83%, und bei einer Verteilung auf 3 Laufwerke nur noch 76%.
Im Falle von 16 Dateien el die Ezienz gar auf 69%. Aufgrund dieses Ergebnisses
11
erfolgte die Beschaung weiterer 10 Laufwerke fur die KSR1, was auch zu einer
nochmaligen Leistungssteigerung fuhrte, s. Abb. 3.2. Die Zunahme des Speedups
von 13.4 auf 14.9 bei 16 Prozessoren bedeutet eine Vergroerung der Ezienz um
nahezu 10% von 84% auf 93%.
16
14
12
Speedup 10
8
6
4
.
2
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
?
?
?
.
?
.
.
?
.
?
.
4
.
.
2
.
.
16 Laufwerke
4 Laufwerke
linearer Speedup
6
8 10 12 14 16
Prozessoren
Abbildung 3.2: Speedup bei der parallelen Abarbeitung einer 1 GB groen Datenbanktabelle verteilt auf 4 Laufwerke und auf 16 Laufwerke
Scheinbar ohne Einu ist die Anzahl der Dateien und damit auch deren Verteilung bei Abarbeitung der Query ohne den QD. Die Einprozessorlaufzeiten variierten innerhalb der Toleranzgrenzen nicht, unabhangig davon, ob die Tabelle in
einer Datei oder in 16 Dateien verteilt abgespeichert ist.
3.6 Performance fur unterschiedliche Queries
Ursprunglich wurden 4 Queries aus dem Benchmark, die jeweils einen Typus reprasentieren, ausgewahlt. Queries 1 und 2 parallelisierten sofort, Queries 8 und 12
muten umformuliert werden. Zusatzlich wurden dann noch weitere 5 Queries bearbeitet, 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 fur jede einzelne Query bei Verwendung von 16 Prozessoren. Die durchschnittliche Ezienz betragt 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
14
Speedup
2
4
6
8
10
12
14
16
1
2
6
7
8
10
Query Nr.
Abbildung 3: Speedup fur unterschiedliche Queries
3
12
13
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Im folgenden sollen die vier ausgesuchten Queries 1, 2, 8 und 12 naher besprochen
werden. Der Querytext bendet sich in Anhang F.3.
3.6.1
Query 1
Bei dieser Query wird eine Tabelle (1 GB Daten) unter einer Bedingung durchsucht. Der QD hat diese Query auf Anhieb parallelisiert. Das Ergebnis ist Abb.
3.4 zu entnehmen.
32
30
28
26
24
22
20
18
Speedup 16
14
12
10
8
6
4
2
.
.
.
.
.
?
?.
.
.
.
.
?
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
?
?
.
?
.
linearer Speedup
2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 32
Prozessoren
Abbildung 3.4: Speedup fur Query 1
Wahrend die restlichen Queries nur auf 16 Prozessoren ausgemessen wurden,
wurde Query 1 auch auf 32 Prozessoren gemessen. Der relativ starke Abfall der
Ezienz von 93% bei 16 Prozessoren auf 81% bei 32 Prozessoren hat sicherlich
zwei Ursachen, zum einen sind 5 Prozessoren zusatzlich mit I/O{Operationen
beschaftigt, 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 enthalt, parallelisiert zwar auch auf Anhieb, wie
jedoch Abb. 3.5 zeigt, ist der Speedup sehr gering.
16
14
12
Speedup 10
8
6
4
2
.
.
.
.
?
.
.
.
.
.
.
?
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
?
?
linearer Speedup
2 4 6 8 10 12 14 16
Prozessoren
.
.
?
Die Grunde fur die schlechte Skalierung liegen nicht auf der Hand, zum einen kann
es am QD liegen, es kann aber auch am Oracle Optimizer liegen. Eine veranderte
Abspeicherung der 3 involvierten Tabellen, z. B. als Cluster, konnte ebenfalls eine
Verbesserung der Performance bringen.
3.6.3
Query 8
Der ursprungliche Querytext enthielt mehrere geschachtelte Views, wegen derer
der QD nicht parallelisieren konnte. Aus diesem Grund wurde die Query umformuliert. Die Views konnten elimiert werden, soda der QD aktiv werden konnte,
da Ergebnis aber nicht verandert wurde. Abb. 3.6 zeigt die Skalierung fur Query
8.
Bemerkenswert ist, da durch die Umformulierung die Einprozessor{Laufzeit um
30% verkurzt werden konnte.
3.6.4
Query 12
Der QD ist nicht in der Lage ein 'UNION ALL' Statement, welches in dieser Query
verwendet wird zu parallelisieren. Daher mute auch diese Query umformuliert
16
16
14
12
Speedup 10
8
6
4
2
.
.
.
.
?
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
?
?
?
linearer Speedup
2 4 6 8 10 12 14 16
Prozessoren
.
?
.
werden, damit der QD parallelisieren konnte. Die Ergebnisse fur Query 12 sind
in Abb. 3.7 dargestellt.
16
14
12
Speedup 10
8
6
4
2
.
.
.
?
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
?
?
?
linearer Speedup
2 4 6 8 10 12 14 16
Prozessoren
.
?
.
Wiederum ergab sich fur 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 Universiat Mannheim ist vom Typ
H60-F2 mit einem Prozessor und 32 MB Hauptspeicher. Die Leistung des Prozessors betragt ca. 5.5 Mips. Der freie Plattenplatz fur das Projekt betragt ca.
1.5 GB.
Entsprechend der Zielsetzung des Projekts sollte Oracle 7.0 mit SQL*Net auf
dem BS2000 Rechner installiert werden. Da die Konguration des Rechners nicht
primar fur Datenbankanwendungnen ausgelegt ist, sollte hauptsachlich die Funktionalitat 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 Versionen TCP-IP-AP V1.0 und BCAM/DCAM V11.0 erforderlich, die fur die H60
beschat werden muten.
Ende der Kalenderwoche 9 ist die ORACLE BS2000 Software zusammen mit
den notwendigen Zusatzen 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 durchgefuhrt 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 eingestellten Default-Werten erzeugt. Die Groe der Datenbank war ca. 100 MB entsprechend dem Skalierungsfaktor 1.
Die Ladedaten wurden als ASCII File von der KSR1 per ftp in ca 20 min U bertragen. Das Laden selbst wurde mit SQL*Load mit der Option direct=true durchgefuhrt. Die Zeit betrug etwa 80 min.
4.3 Queries
Die vorgesehenen Queries konnten ohne besondere Vorbereitungen direkt von der
KSR1 ubernommen werden.
Die Zeiten fur die Queries mit SF=1, nachts gemessen, waren:
Q1:
Q2:
Q8:
Q12:
CPU
CPU
CPU
CPU
Time 1509.07 sec
Time 182.17 sec
Time 641.16 sec
Time 1110.59 sec
Die Zeiten liegen in der Groenordnung der Zeiten auf einem Prozessor der KSR1
mit der alten Oracle Version.
19
Kapitel 5
Oracle Kopplung BS2000 {
KSR1
Oracle bietet die Moglichkeit auf Datenbanken (insbesondere auf einzelne Tabellen) 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 Moglichkeit sich direkt mit einer SQL*Plus
Sitzung auf dem anderen Rechner `einzuloggen', oder es gibt die Moglichkeit 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 zunachst die Funktionalitat im Vordergrund,
Performance-Daten waren nur fur die Groenordnung wichtig.
5.1 Installation
Die TCP/IP Software wurde auf der BS2000 Seite auf den neuesten Stand gebracht. `telnet', `ftp' usw. funktionieren unabhangig von Oracle.
Die Installation der SQL*Net Verbindung erforderte die Verwendung eines nichtpriviligierten 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 fur
`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
create database link
insert into
insert into
create snapshot
BS2000
BS2000
BS2000
KSR1
KSR1
--->
--->
--->
--->
--->
KSR1
KSR1
KSR1
BS2000
BS2000.
5.2 Datenbank Kommunikation

Die Ubertragungstests
wurden zunachst ohne besondere Optimierungen in der
gegebenen Konguration durchgefuhrt. Durch den Initialisierungsoverhead sind
bei kleineren Tabellen die U bertragungsraten schlechter als bei groeren Tabellen.
Das TCP/IP Netz ist in unserer Konguration nicht der Engpass.
Es ergaben sich folgende Datenraten
7.5 - 8.6 KB / sec fur das U bertragen mit DB Tools,
18.6 KB / sec fur das Laden auf BS2000,
163.6 KB / sec fur das U bertragen mit TCP/IP Tools.
Die Datenubertragungsrate mit DB Tools ist somit etwa 0.5 MB / min, d.h. 30
MB / h. Eine Datenbank von 1 GB wurde somit etwas mehr als einen Tag fur
die U bertragung benotigen.
Das U bertragen 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 fur das Schreiben von Tabellen etwa 2 mal so hoch wie fur das
Lesen von Tabellen.
Eine bessere Alternative zu ìnsert into' stellt ein `snapshot' der Datenbank dar.
Ein `snapshot' ist eine `read only' Kopie der DB, d.h. man kann alle Abfragen
durchfuhren, aber keine Modikationen. Der `snapshot' einer Tabelle ist etwa 10
bis 20 % schneller als das entsprechende ìnsert into'.
21
Kapitel 6
Zusammenfassung
Es konnte nachgewiesen werden, da die KSR1 als ORACLE-Datenbankbackend
fur einen BS2000 Mainframe gut geeignet ist.
Dies basiert auf folgenden Ergebnissen:
Die Interoperabilitat beider Anlagen ist bezuglich Hardware und Software
gut moglich.
Die Oracle Software auf der KSR1 ist stabil und uneingeschrankt benutzbar.
Die zugrundeliegende Decision Support Anwendung ist sehr gut parallelisierbar; die grobkornige Parallelitat liefert praktisch einen idealen, linearen
Speedup.
Obwohl ein einzelner Prozessor der KSR1 bei dieser Anwendung nur etwa die Leistung einer SNI H60 ausweist, gewahrleistet die Architektur der
KSR1 beliebige Skalierbarkeit bezuglich der Rechenleistung.
Auch bezuglich der Datenbankgroe (gemessen bis 1 GB) konnten wir mit
der KSR1 eine sehr gute Skalierbarkeit nachweisen.
Eine weitere Leistungsverbesserung liee sich erreichen, wenn zusatzlich zu den
parallelisierten Datenbankabfragen, auch das parallele Laden und Update der
Datenbank genutzt wurde. Diese Funktionalitat ist fur die Oracle Version 7.1
angekundigt und auch im Query Decomposer von KSR enthalten.
6.1 Ausblick
Um ein vollstandigeres Bild der Parallelisierbarkeit von Decision Support Anwendungen zu erhalten, ware es sinnvoll den gesammten Benchmark mit groe22
ren Datenbanken und mehr Prozessoren weiter zu fuhren. Insbesondere bleiben
folgende Probleme:
1.
2.
3.
4.
5.
6.
Test der Oracle Version 7.1.
Tests im Mehrbenutzerbetrieb.
Testen des parallelen Ladens der DB.
Testen der parallelen Queries von der BS2000 Seite aus.
Analyse des Einues der KSR1 Architektur.
Analyse der Systemresourcen.
23
Anhange
In den folgenden Anhangen werden die verschiedenen Zeitplane, Datenbank Denitionen und Queries, sowie die Messungen dokumentiert.
Die Mitarbeiter und Unterstutzer der Projektgruppe waren
RZ Universitat Mannheim:
Prof. Dr. H.-W. Meuer, Dr. H. Kredel, Dr. R. Schumacher, Dr. E. Strohmaier, Hr. R. Muller.
FB Wirtschaft Fachhochschule Luneburg:
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. Kostler, Mch-P
SU BS2, Hr. Prohl, MA.
24
Anhang A
Projektstatistik
Sondierungsgesprache im Herbst 1993.
Erstes Treen der Projektgruppe am 24. Januar 1994.
Letztes Treen der Projektgruppe am 19. Mai 1994.
Zeitdauer: 4 Monate, Februar bis Mai 1994.
Treen: 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.
Wochentliche 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.
zusatzlicher Sachaufwand:
1. Oracle 7.0 Demo Lizenz fur BS2000,
2. neue Versionen von TCP/IP und DCAM fur BS2000,
25
3. Oracle 7.0 Lizenz fur KSR1,
4. Benchmark Software,
5. 10 GB Platten fur KSR1.
26
Anhang B
Arbeitsplan, Zeitplan
Arbeitsplan vom Februar 1994.
Zeit
6. KW
Aktivitaten
Klarung der Hardwarevoraussetzungen,
Installation von DBGEN, Erstellung der Queries,
Laden und Messungen auf AIX in Luneburg,
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.
Durchfuhrung weiterer Queries,
Messung der Lade- und Updatezeiten,
bis 19. KW
Vervollstandigung der Messungen.
`KW' bedeutet Kalenderwoche im Jahr 1994.
27
Aktualisierter Arbeitsplan vom Marz 1994.
Zeit
Aktivitaten
bis 14. KW Klarung der HW/SW Situation,
Vorbereiten der Queries und Messungen in Luneburg,
Installation von Oracle auf KSR1 und BS2000,
Installation der Verbindung uber SQL*Net,
bis Datenbank groe 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,
Groere Datenbank, weitere Queries.
Aktualisierter Arbeitsplan vom April 1994.
Zeit
Aktivitaten
Ende KW 17 hochskalieren der DB bis 1 GB,
Load / Unload BS2000 - KSR1 uber SQL*Net,
Entscheidung uber Plattenbeschaung 10 GB.
18. KW
Durchfuhrung der Queries, Parallelisierung,
Vorlauger 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
Q 1:
Q 2:
Q 8:
Q12:
1281.0
206.0
1128.0
852.0
SF 10
sec
sec
sec
sec
11993
1381
4715
8895
sec
sec
sec
sec
SF 10
Neufassung
--3670 sec
4108 sec
C.2 Messungen fur verschiedene Verteilungen
Ergebnisse fur unterschiedliche Verteilung der Tabellen auf Dateien.
Ergebnisse fur SF 1
cpu
1
1
2
2
3
3
4
4
4
6
disk
1
1
1
2
1
3
1
2
4
2
files
1
16
2
2
3
3
4
4
4
6
7.0.12
1436
879
425
29
7.0.13
1281
1230
629
621
447
437
344
329
342
253
6
8
8
9
12
12
16
3
2
4
3
3
4
4
6
8
8
9
12
12
16
227
157
142
235
202
194
171
140
128
116
Ergebnisse fur SF 10
cpu
1
1
2
4
8
16
disk
4
4
4
4
4
4
files
16
4
4
4
16
16
7.0.13
12933*
12534*
6113*
3210**
1760*
962
Ergebnis aus 1 Messung.
Ergebnis aus 2 Messungen.
Bemerkungen:
*
**
Von Version 7.0.12 auf 7.0.13 ist eine Leistungsteigerung von 20% aufgetreten.
Die verbrauchte CPU{Zeit (die Messung geschah mit dem Betriebssystem)
schwankte zwischen 10%, unabhangig von Anzahl der CPUs, Files oder
Disks.
Die System-Zeit, sie betragt zwischen 5% und maximal 10% der CPU-Zeit,
steigt mit der Anzahl der Files.
C.3 Ergebnisse fur die einzelnen Queries
Query 1:
cpu
1
2
4
8
16
32
time
11993
5990
2966
1532
805
462
30
Query 2:
cpu
1
2
4
8
16
time
1381
932
572
406
362
Query 3:
cpu
1
2
4
8
16
time
12526
7239
4266
2495
2220
Query 6:
cpu
1
2
4
8
16
time
2221
1090
595
310
184
Query 7:
cpu
1
2
4
8
16
time
12946
8378
4585
2404
1573
Query 8:
cpu
1
2
4
8
16
time
3670
2052
1214
907
658
31
Query 10:
cpu
1
2
4
8
16
time
6251
3698
2156
1608
865
Query 12:
cpu
1
2
4
8
16
time
4108
2356
1142
675
393
Query 13:
cpu
1
2
4
8
16
time
403
232
132
80
60
32
Anhang D
Messungen auf SNI H60
Die Zeiten wurden mit `set timing on' von Oracle erhalten. Das Laden der Datenbank mit SF=1, ca. 100 MB Daten benotigte 80 min Elapsed time und 68 min
CPU time.
Die Zeiten fur die einzelnen Tabellen waren
Tabelle
SUPPLIERS
LINEITEM
PARTSUPP
PARTS
ORDERS
CUSTOMES
Elapsed Time
17.80
61:36.52
5:03.70
1:32.08
10:22.68
1:37.38
sec
min
min
min
min
min
CPU Time
6.37
52:30.97
3:49.93
1:11.00
8:23.33
1:14.63
sec
min
min
min
min
min
Die Zeiten fur die Queries mit SF=1 waren:
Q1:
Q2:
Q8:
Q12:
CPU
CPU
CPU
CPU
tagsueber
Time 1521.6 sec
Time 184.6 sec
Time 4622.4 sec
Time 1127.2 sec
33
nachts
1509.07
182.17
641.16
1110.59
sec
sec
sec
sec
Anhang E
Messungen der Kopplung
Die Èlapsed Times' wurden mit der `Wall Clock' gemessen. Die `CPU Times'
wurden den Oracle Meldungen auf der BS2000 entnommen, bzw. dem Zeitverbrauch von orasrv auf der KSR1.
Insert in Tabelle auf der KSR1 via SQL*Net database link, select von einer Tabelle 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 U bertragen der ASCII Datei per ftp dauert ca. 1 sec.
Damit ergeben sich folgende Datenraten
2.5 KB / sec fur das U bertragen mit DB Tools,
5.6 KB / sec fur das Laden,
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 U bertragen der ASCII Datei per ftp dauert ca. 11 sec.
Damit ergeben sich folgende Datenraten
34
7.5 - 8.6 KB / sec fur das U bertragen mit DB Tools,
18.6 KB / sec fur das Laden,
Die Datenubertragungsrate mit DB Tools ist somit etwa 0.5 MB / min, d.h. 30
MB / h. Eine Datenbank von 1 GB wurde somit etwas mehr als einen Tag fur
die U bertragung benotigen.
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 Denition der
Test-Datenbank und der Abfragen dokumentiert.
F.1 Denition 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
o_custkey
o_orderstatus
o_totalprice
o_orderdate
o_orderpriority
o_clerk
o_shippriority
number(12)
number(12),
char(1),
number(12,2),
date,
char(15),
char(15),
number(12),
NOT NULL,
37
o_comment
char(49)
)
TABLESPACE tso
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
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)
ps_suppkey
number(12)
ps_availqty
number(12),
ps_supplycost
number(12,2),
ps_comment
char(124)
NOT NULL,
NOT NULL,
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)
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;
NOT NULL,
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)
40
and
and
and
and
and
c_region = s_region
o_orderdate between to_date('01-JAN-95')
to_date('31-DEC-96')
c_region = 'AMERICA'
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
drop
drop
drop
view
view
view
view
country;
sum_country;
continent;
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'
and o_orderpriority in ('1-URGENT', '2-HIGH')
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))
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')
group by l_shipmode,
decode(o_orderpriority, '1-URGENT
', 'High Priority',
'2-HIGH
', 'High Priority',
'Low Priority')
order by 2 desc;
42