43

orw - Universität Mannheim · on SNI v erw endeten Daten bank Benc hmark. Der Benc hmark umfa t u.A. die De nition einer geigneten T est-Daten bank, Programme um den Inhalt der Da-ten

Embed Size (px)

Citation preview

Page 1: orw - Universität Mannheim · on SNI v erw endeten Daten bank Benc hmark. Der Benc hmark umfa t u.A. die De nition einer geigneten T est-Daten bank, Programme um den Inhalt der Da-ten

Oracle Datenbankkopplung

SNI BS2000 { KSR1

Heinz Kredel, Robert Schumacher (eds.)

Rechenzentrum Universit�at Mannheim

RUM 37/94

Juni 1994

Page 2: orw - Universität Mannheim · on SNI v erw endeten Daten bank Benc hmark. Der Benc hmark umfa t u.A. die De nition einer geigneten T est-Daten bank, Programme um den Inhalt der Da-ten

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

Page 3: orw - Universität Mannheim · on SNI v erw endeten Daten bank Benc hmark. Der Benc hmark umfa t u.A. die De nition einer geigneten T est-Daten bank, Programme um den Inhalt der Da-ten

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

Page 4: orw - Universität Mannheim · on SNI v erw endeten Daten bank Benc hmark. Der Benc hmark umfa t u.A. die De nition einer geigneten T est-Daten bank, Programme um den Inhalt der Da-ten

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

Page 5: orw - Universität Mannheim · on SNI v erw endeten Daten bank Benc hmark. Der Benc hmark umfa t u.A. die De nition einer geigneten T est-Daten bank, Programme um den Inhalt der Da-ten

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

Page 6: orw - Universität Mannheim · on SNI v erw endeten Daten bank Benc hmark. Der Benc hmark umfa t u.A. die De nition einer geigneten T est-Daten bank, Programme um den Inhalt der Da-ten

� 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

Page 7: orw - Universität Mannheim · on SNI v erw endeten Daten bank Benc hmark. Der Benc hmark umfa t u.A. die De nition einer geigneten T est-Daten bank, Programme um den Inhalt der Da-ten

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

Page 8: orw - Universität Mannheim · on SNI v erw endeten Daten bank Benc hmark. Der Benc hmark umfa t u.A. die De nition einer geigneten T est-Daten bank, Programme um den Inhalt der Da-ten

Q2: Einfacher Join mit Subquery, block parallelization,

Q8: Vielfach-Join,

Q12: Union, block parallelization.

7

Page 9: orw - Universität Mannheim · on SNI v erw endeten Daten bank Benc hmark. Der Benc hmark umfa t u.A. die De nition einer geigneten T est-Daten bank, Programme um den Inhalt der Da-ten

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

Page 10: orw - Universität Mannheim · on SNI v erw endeten Daten bank Benc hmark. Der Benc hmark umfa t u.A. die De nition einer geigneten T est-Daten bank, Programme um den Inhalt der Da-ten

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

Page 11: orw - Universität Mannheim · on SNI v erw endeten Daten bank Benc hmark. Der Benc hmark umfa t u.A. die De nition einer geigneten T est-Daten bank, Programme um den Inhalt der Da-ten

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

Page 12: orw - Universität Mannheim · on SNI v erw endeten Daten bank Benc hmark. Der Benc hmark umfa t u.A. die De nition einer geigneten T est-Daten bank, Programme um den Inhalt der Da-ten

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

Page 13: orw - Universität Mannheim · on SNI v erw endeten Daten bank Benc hmark. Der Benc hmark umfa t u.A. die De nition einer geigneten T est-Daten bank, Programme um den Inhalt der Da-ten

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

Page 14: orw - Universität Mannheim · on SNI v erw endeten Daten bank Benc hmark. Der Benc hmark umfa t u.A. die De nition einer geigneten T est-Daten bank, Programme um den Inhalt der Da-ten

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

Page 15: orw - Universität Mannheim · on SNI v erw endeten Daten bank Benc hmark. Der Benc hmark umfa t u.A. die De nition einer geigneten T est-Daten bank, Programme um den Inhalt der Da-ten

246810

12

14

16

Speedup

1

2

3

6

7

8

10

12

13

QueryNr.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

Abbildung3:Speedupf �urunterschiedlicheQueries

14

Page 16: orw - Universität Mannheim · on SNI v erw endeten Daten bank Benc hmark. Der Benc hmark umfa t u.A. die De nition einer geigneten T est-Daten bank, Programme um den Inhalt der Da-ten

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

Page 17: orw - Universität Mannheim · on SNI v erw endeten Daten bank Benc hmark. Der Benc hmark umfa t u.A. die De nition einer geigneten T est-Daten bank, Programme um den Inhalt der Da-ten

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

Page 18: orw - Universität Mannheim · on SNI v erw endeten Daten bank Benc hmark. Der Benc hmark umfa t u.A. die De nition einer geigneten T est-Daten bank, Programme um den Inhalt der Da-ten

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

Page 19: orw - Universität Mannheim · on SNI v erw endeten Daten bank Benc hmark. Der Benc hmark umfa t u.A. die De nition einer geigneten T est-Daten bank, Programme um den Inhalt der Da-ten

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

Page 20: orw - Universität Mannheim · on SNI v erw endeten Daten bank Benc hmark. Der Benc hmark umfa t u.A. die De nition einer geigneten T est-Daten bank, Programme um den Inhalt der Da-ten

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

Page 21: orw - Universität Mannheim · on SNI v erw endeten Daten bank Benc hmark. Der Benc hmark umfa t u.A. die De nition einer geigneten T est-Daten bank, Programme um den Inhalt der Da-ten

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

Page 22: orw - Universität Mannheim · on SNI v erw endeten Daten bank Benc hmark. Der Benc hmark umfa t u.A. die De nition einer geigneten T est-Daten bank, Programme um den Inhalt der Da-ten

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

Page 23: orw - Universität Mannheim · on SNI v erw endeten Daten bank Benc hmark. Der Benc hmark umfa t u.A. die De nition einer geigneten T est-Daten bank, Programme um den Inhalt der Da-ten

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

Page 24: orw - Universität Mannheim · on SNI v erw endeten Daten bank Benc hmark. Der Benc hmark umfa t u.A. die De nition einer geigneten T est-Daten bank, Programme um den Inhalt der Da-ten

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

Page 25: orw - Universität Mannheim · on SNI v erw endeten Daten bank Benc hmark. Der Benc hmark umfa t u.A. die De nition einer geigneten T est-Daten bank, Programme um den Inhalt der Da-ten

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

Page 26: orw - Universität Mannheim · on SNI v erw endeten Daten bank Benc hmark. Der Benc hmark umfa t u.A. die De nition einer geigneten T est-Daten bank, Programme um den Inhalt der Da-ten

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

Page 27: orw - Universität Mannheim · on SNI v erw endeten Daten bank Benc hmark. Der Benc hmark umfa t u.A. die De nition einer geigneten T est-Daten bank, Programme um den Inhalt der Da-ten

3. Oracle 7.0 Lizenz f�ur KSR1,

4. Benchmark Software,

5. 10 GB Platten f�ur KSR1.

26

Page 28: orw - Universität Mannheim · on SNI v erw endeten Daten bank Benc hmark. Der Benc hmark umfa t u.A. die De nition einer geigneten T est-Daten bank, Programme um den Inhalt der Da-ten

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

Page 29: orw - Universität Mannheim · on SNI v erw endeten Daten bank Benc hmark. Der Benc hmark umfa t u.A. die De nition einer geigneten T est-Daten bank, Programme um den Inhalt der Da-ten

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

Page 30: orw - Universität Mannheim · on SNI v erw endeten Daten bank Benc hmark. Der Benc hmark umfa t u.A. die De nition einer geigneten T est-Daten bank, Programme um den Inhalt der Da-ten

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

Page 31: orw - Universität Mannheim · on SNI v erw endeten Daten bank Benc hmark. Der Benc hmark umfa t u.A. die De nition einer geigneten T est-Daten bank, Programme um den Inhalt der Da-ten

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

Page 32: orw - Universität Mannheim · on SNI v erw endeten Daten bank Benc hmark. Der Benc hmark umfa t u.A. die De nition einer geigneten T est-Daten bank, Programme um den Inhalt der Da-ten

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

Page 33: orw - Universität Mannheim · on SNI v erw endeten Daten bank Benc hmark. Der Benc hmark umfa t u.A. die De nition einer geigneten T est-Daten bank, Programme um den Inhalt der Da-ten

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

Page 34: orw - Universität Mannheim · on SNI v erw endeten Daten bank Benc hmark. Der Benc hmark umfa t u.A. die De nition einer geigneten T est-Daten bank, Programme um den Inhalt der Da-ten

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

Page 35: orw - Universität Mannheim · on SNI v erw endeten Daten bank Benc hmark. Der Benc hmark umfa t u.A. die De nition einer geigneten T est-Daten bank, Programme um den Inhalt der Da-ten

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

Page 36: orw - Universität Mannheim · on SNI v erw endeten Daten bank Benc hmark. Der Benc hmark umfa t u.A. die De nition einer geigneten T est-Daten bank, Programme um den Inhalt der Da-ten

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

Page 37: orw - Universität Mannheim · on SNI v erw endeten Daten bank Benc hmark. Der Benc hmark umfa t u.A. die De nition einer geigneten T est-Daten bank, Programme um den Inhalt der Da-ten

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

Page 38: orw - Universität Mannheim · on SNI v erw endeten Daten bank Benc hmark. Der Benc hmark umfa t u.A. die De nition einer geigneten T est-Daten bank, Programme um den Inhalt der Da-ten

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

Page 39: orw - Universität Mannheim · on SNI v erw endeten Daten bank Benc hmark. Der Benc hmark umfa t u.A. die De nition einer geigneten T est-Daten bank, Programme um den Inhalt der Da-ten

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

Page 40: orw - Universität Mannheim · on SNI v erw endeten Daten bank Benc hmark. Der Benc hmark umfa t u.A. die De nition einer geigneten T est-Daten bank, Programme um den Inhalt der Da-ten

)

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

Page 41: orw - Universität Mannheim · on SNI v erw endeten Daten bank Benc hmark. Der Benc hmark umfa t u.A. die De nition einer geigneten T est-Daten bank, Programme um den Inhalt der Da-ten

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

Page 42: orw - Universität Mannheim · on SNI v erw endeten Daten bank Benc hmark. Der Benc hmark umfa t u.A. die De nition einer geigneten T est-Daten bank, Programme um den Inhalt der Da-ten

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

Page 43: orw - Universität Mannheim · on SNI v erw endeten Daten bank Benc hmark. Der Benc hmark umfa t u.A. die De nition einer geigneten T est-Daten bank, Programme um den Inhalt der Da-ten

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