Microsoft SQL Server 2000 3-8273-1723-1
Das Buch erläutert Datenbankprogrammierern, Systemadministratoren und Endbenutzern die diversen Komponenten des SQL Serv
272 80 4MB
English Pages 630 Year 2001
Microsoft SQL Server 2000......Page 3
Verwaltung von Datenbanken und Datenbankobjekten......Page 5
CREATE TABLE-Anweisung – die Grundform......Page 6
Standard-Aggregatfunktionen......Page 7
Zusammenfassung......Page 8
Geschachteltes Loop-Join-Verfahren......Page 9
Zusammenfassung......Page 10
Speicherung von Transaktionen......Page 11
Hard- und Softwarevoraussetzungen......Page 12
Zusammenfassung......Page 13
Zusammenfassung......Page 14
Arbeitsspeicher......Page 15
Dimensionales Modell......Page 16
Erstellung eines IIS virtuellen Verzeichnisses mit Hilfe der graphischen Schnittstelle......Page 17
B Lösungen......Page 18
Stichwortverzeichnis......Page 19
Teil I - SQL Server: Grundkonzepte......Page 25
Eigenschaften von MS SQL Server......Page 27
Physikalische Datenunabhängigkeit......Page 29
Datenintegrität......Page 30
Datenschutz......Page 31
Relationale Datenbanken......Page 32
Datenbankdesign......Page 35
Erste Normalform......Page 36
Dritte Normalform......Page 37
Das E/R-Modell......Page 38
Die Datenbanksprache SQL......Page 41
Notation......Page 42
Zusammenfassung......Page 43
SQL Server Onlinedokumentation......Page 47
SQL Server Enterprise Manager – eine Einführung......Page 49
Die Benutzung des Enterprise Managers......Page 50
Verwaltung von Datenbanken und Datenbankobjekten......Page 53
Verwaltung von Tabellen mit Hilfe des Enterprise Managers......Page 57
Query Analyzer......Page 61
Der Query Analyzer-Editor......Page 62
Zusammenfassung......Page 68
Teil II - Transact-SQL-Sprache......Page 71
Literale......Page 73
Reservierte Wörter......Page 75
Numerische Datentypen......Page 76
Alphanumerische Datentypen......Page 77
Datums- und Zeitangaben......Page 79
Neue Datentypen in SQL Server 7 und 2000......Page 80
Prädikate......Page 81
Numerische Funktionen......Page 82
Datumsfunktionen......Page 84
Zeichenkettenfunktionen......Page 85
Systemfunktionen......Page 87
Skalare Operatoren......Page 89
Globale Variablen und Ausdrücke......Page 90
NULL- Werte......Page 91
Zusammenfassung......Page 93
Erstellen der Objekte......Page 95
Erstellen einer Datenbank......Page 96
CREATE TABLE-Anweisung – die Grundform......Page 99
Die erweiterte Form der CREATE TABLE-Anweisung......Page 101
Die CREATE TABLE-Anweisung und die deklarativen Integritätsregeln......Page 102
Die PRIMARY KEY-Klausel......Page 104
Die FOREIGN KEY-Klausel......Page 105
Die referentielle Integrität......Page 106
Die ON DELETE- und ON UPDATE-Angabe......Page 108
Die CHECK-Bedingung......Page 110
Weitere Anweisungen zur Erstellung der Datenbankobjekte......Page 111
Integritätsregeln und Wertebereiche......Page 113
Benutzerdefinierte Datentypen......Page 114
Definition der Standardwerte......Page 115
Regeldefinition für Wertebereiche......Page 116
Änderung einer Datenbank......Page 117
Änderung der Tabellenstruktur......Page 119
Die erweiterte Form der ALTER TABLE-Anweisung......Page 120
Löschen der Objekte......Page 123
Zusammenfassung......Page 124
Grundform der SELECT-Anweisung......Page 127
Die WHERE-Klausel......Page 128
Boolesche Funktionen......Page 131
Die Operatoren IN und BETWEEN......Page 134
Der NULL-Operator......Page 137
Der Operator LIKE......Page 139
Unterabfrage und Vergleichsoperatoren......Page 142
Unterabfragen und IN-Operator......Page 143
Die Operatoren ANY und ALL......Page 145
Die Unterabfragen in der FROM-Klausel......Page 147
Die GROUP BY-Klausel......Page 148
Aggregatfunktionen......Page 149
Standard-Aggregatfunktionen......Page 150
Die Funktionen MIN und MAX......Page 151
Die Funktion AVG......Page 152
Die Funktionen COUNT und COUNT_BIG......Page 153
Statistische Aggregatfunktionen......Page 155
Die HAVING-Klausel......Page 156
Die ORDER BY-Klausel......Page 157
Die SELECT-Anweisung und die IDENTITY- Eigenschaft......Page 159
Mengenoperatoren......Page 160
Die Verwendung von CASE in Ausdrücken......Page 164
Die COMPUTE-Klausel......Page 166
Temporäre Tabellen......Page 168
Berechnete Spalten......Page 169
Zusammenfassung......Page 170
Verknüpfen zweier oder mehrerer Tabellen......Page 173
Zwei Syntaxformen für die Join-Implementierung......Page 174
Der Equijoin......Page 175
Das Kartesische Produkt......Page 177
Der Natürliche Join......Page 178
Der Thetajoin......Page 180
Verknüpfung von mehr als zwei Tabellen......Page 182
Eine Tabelle mit sich selbst verknüpfen......Page 183
Der Outer Join......Page 185
Korrelierte Unterabfragen......Page 188
Die EXISTS-Funktion in Unterabfragen......Page 191
Zusammenfassung......Page 194
Einfügen einer Reihe......Page 197
Einfügen mehrerer Reihen......Page 200
Die UPDATE-Anweisung......Page 202
Die DELETE-Anweisung......Page 204
Zusammenfassung......Page 206
Der BEGIN-Block......Page 209
Die WHILE-Anweisung......Page 210
Lokale Variablen......Page 211
Weitere prozedurale Anweisungen......Page 212
Datenbankprozeduren......Page 213
Die Erstellung und Ausführung der Datenbankprozeduren......Page 215
Systemprozeduren......Page 219
Erstellung und Ausführung benutzerdefinierter Funktionen......Page 220
Text/image-Datentypen......Page 224
Abfragen auf text/image-Daten......Page 225
Modifikation der text/image-Daten......Page 226
Zusammenfassung......Page 227
Indizes......Page 229
Clustered und Nonclustered Indizes......Page 231
Transact-SQL-Anweisungen in bezug auf Indizes......Page 232
Indizes und Schlüssel......Page 237
AND-Operator......Page 239
Join......Page 240
Join statt korrelierter Unterabfrage......Page 241
Der LIKE-Operator......Page 242
Transact-SQL-Anweisungen und Optimieren von Suchanweisungen......Page 243
Der Optimierer......Page 246
Statistiken......Page 247
Geschachteltes Loop-Join- Verfahren......Page 249
Das Hash-Join- Verfahren......Page 250
Hinweise für den Optimierer......Page 251
DBCC-Kommando und Indizes......Page 258
Zusammenfassung......Page 259
Erstellen von Views......Page 261
Views modifizieren und löschen......Page 266
Abfragen in Views......Page 267
INSERT-Anweisung und View......Page 268
UPDATE-Anweisung und View......Page 271
DELETE-Anweisung und View......Page 273
Partitionierte Views......Page 274
Indizierte Views......Page 275
Anforderung bezüglich indizierter Views......Page 276
Optimiererhinweise und indizierte Views......Page 279
Zusammenfassung......Page 280
sysobjects......Page 283
sysindexes......Page 284
sysdatabases......Page 285
sysreferences......Page 286
Abfragen auf Systemtabellen......Page 287
Andere Abfragemöglichkeiten......Page 288
Systemprozeduren und der Systemkatalog......Page 289
Eigenschaftsfunktionen......Page 292
Informationsschema......Page 293
Zusammenfassung......Page 295
Einloggen in das SQL Server-System......Page 297
sp_password......Page 299
Setzen der Datenbankrechte......Page 300
Rollen......Page 302
Server-Rollen......Page 303
Datenbankrollen......Page 304
Applikationsrollen......Page 306
Benutzerdefinierte Rollen......Page 307
Anweisungsberechtigungen und die GRANT-Anweisung......Page 309
Objektberechtigungen und die GRANT-Anweisung......Page 311
Die DENY-Anweisung......Page 313
Die REVOKE-Anweisung......Page 314
Einschränkung des Datenzugriffs mit Views......Page 315
Zusammenfassung......Page 317
Einführung......Page 321
Trigger......Page 322
Anwendungsgebiete für AFTER- Trigger......Page 323
Anwendungsgebiete für INSTEAD OF-Option......Page 327
Ausführungsreihenfolge von multiplen Triggern......Page 328
Zusammenfassung......Page 329
Einführung......Page 331
Transact-SQL-Anweisungen in bezug auf Transaktionen......Page 332
Speicherung von Transaktionen......Page 335
Objekte sperren......Page 336
Typen von Sperren......Page 337
Isolierungsstufen......Page 340
Gegenseitige Blockierung (Deadlock)......Page 342
Zusammenfassung......Page 343
Speicherung von Daten......Page 345
Systemdatenbanken......Page 346
osql......Page 347
odbcping......Page 349
Instanzen des SQL Server-Systems......Page 350
Die Auswahl des Zeichensatzes......Page 352
Die Architektur des SQL Servers......Page 354
Die Architektur der Multiprozessorrechner......Page 355
Multithreading-Architektur des SQL Servers......Page 356
Zusammenfassung......Page 358
Teil III - Sql Server: Systemadministration......Page 359
Der SQL Server und die Systemadministration......Page 361
Die Administrationswerkzeuge des SQL Servers......Page 363
Der Systemadministrator......Page 364
Zusammenfassung......Page 365
Anwendungszweck eines SQL Server-Systems......Page 367
Hard- und Softwarevoraussetzungen......Page 368
Die notwendigen Angaben bei der Installation......Page 370
Installationsanfang......Page 372
Die Installation von Client-Komponenten......Page 378
Versionsumstellung......Page 379
Die Erstellung der Server-Gruppen und die Registrierung des Servers......Page 381
Die Zuweisung eines Kennwortes der......Page 382
Server-Optionen setzen......Page 383
Das Starten und Stoppen des SQL Server- Systems......Page 384
Zusammenfassung......Page 385
Verwaltung von Dateigruppen......Page 387
Dateien sichten......Page 388
Datenbanken verwalten......Page 389
Datenbankoptionen sichten bzw. ändern......Page 390
Änderung der Datenbankstruktur......Page 394
Transaktionsprotokolle verwalten......Page 396
Zusammenfassung......Page 397
Einführung......Page 399
Das Verwalten von Login-ID......Page 401
Verwaltung des Zugriffs auf einzelne Datenbanken......Page 403
Rollen......Page 404
Zugriffsberechtigungen verwalten......Page 407
Objektberechtigungen verwalten......Page 408
Anweisungsberechtigungen verwalten......Page 410
Zusammenfassung......Page 411
Mögliche Fehler eines Datenbanksystems......Page 413
Transaktionsprotokoll......Page 414
Die Archivierung......Page 415
Archivierung des Transaktionsprotokolls......Page 416
Die dynamische Archivierung......Page 418
Archivierung mit Hilfe des Enterprise Managers......Page 419
Planung der Archivierung mit Hilfe des Enterprise Managers......Page 422
Archivierung mit Hilfe der Transact-SQL-Anweisungen......Page 424
Welche Datenbanken sollen archiviert werden und wann ?......Page 429
Vorbeugende Maßnahmen gegen den Datenverlust......Page 431
Wiederherstellung von Datenbanken......Page 434
Die vom Benutzer initiierte Wiederherstellung – eine Einführung......Page 435
Die Wiederherstellung einer Benutzerdatenbank......Page 436
Die Wiederherstellung anderer Systemdatenbanken......Page 443
Wiederherstellungsmodelle......Page 444
Wiederherstellung zu einer Marke......Page 446
Zusammenfassung......Page 447
Einführung......Page 449
DTS-Pakete......Page 451
Andere DTS-Komponenten......Page 454
Das bcp-Kommando......Page 455
Die Verwendung der austauschbaren Medien......Page 457
Zusammenfassung......Page 459
Einführung......Page 461
SQL Server Agent......Page 462
Starten und Konfigurieren des SQL Server Agent......Page 463
Auftragsschritte definieren......Page 464
Auftrag erstellen......Page 465
Planung der Auftragsausführung......Page 467
Operatoren und Benachrichtigungen erstellen......Page 468
Auftragschronik......Page 470
Warnungen......Page 472
Die Erstellung von Standardwarnungen......Page 473
Benutzerdefinierte Warnungen......Page 477
Auftragsautomatisierung in Multi-Server- Umgebung......Page 478
Zusammenfassung......Page 479
Fehlermeldungen......Page 481
Das SQL Server-Protokoll......Page 483
Windows NT/2000-Ereignisprotokoll......Page 484
Fehlerbehebung......Page 485
Zusammenfassung......Page 487
Einführung......Page 489
Benutzeranforderungen......Page 490
Physikalisches Datenbankdesign......Page 491
Sperren......Page 493
Die Effizienz des Prozessors......Page 494
Arbeitsspeicher......Page 495
Benutzerverbindungen......Page 496
Performance- Werkzeuge für Datenbankanwendungen......Page 497
SQL Server spezifische Performance- Werkzeuge......Page 501
Werkzeuge zur Überwachung der Systemressourcen......Page 503
Der SQL Server Profiler......Page 504
Der Indexoptimierungsassistent......Page 505
Zusammenfassung......Page 512
Einführung......Page 515
SQL Server Datenreplikation – ein Überblick......Page 516
Publikations-, Abonnement- und Verteilungsserver......Page 517
Transaktionale Publikation......Page 518
Merge-Publikation......Page 520
Replikationsmodelle......Page 522
Zentraler Verleger mit dem Verteiler......Page 523
Datereplikationen verwalten......Page 524
Setzen des Verteilungs- und Publikationsservers......Page 525
Setzen des Abonnementservers......Page 527
Zusammenfassung......Page 528
Teil IV - MS Analysis Services......Page 531
OLTP-Systeme......Page 533
Data Warehouse-Systeme......Page 534
Data Warehouse und Data Mart......Page 535
Dimensionales Modell......Page 538
Multidimensionale Würfel und Speicherungsmodi......Page 542
MOLAP, ROLAP und HOLAP......Page 543
Zusammenfassung......Page 544
Einführung......Page 545
Data Warehouse- Tier......Page 546
Server-Tier......Page 547
Client- Tier......Page 548
Katalog......Page 549
Der Analysis Manager......Page 550
Data Transformation Services (DTS)......Page 554
Zusammenfassung......Page 555
Der CUBE-Operator......Page 557
Der Operator ROLLUP......Page 560
Die TOP n-Klausel......Page 561
Microsoft Client- Werkzeuge......Page 562
Analysis Manager......Page 563
Client-Software der Drittanbieter......Page 565
Zusammenfassung......Page 566
Teil V - Erstellung der Softwarelösungen mit SQL Server......Page 567
World Wide Web......Page 569
XML und verwandte Sprachen......Page 570
Grundkonzepte von XML......Page 571
Erstellung des IIS virtuellen Verzeichnisses mit Hilfe der graphischen Schnittstelle......Page 574
Erstellung eines IIS virtuellen Verzeichnisses mit Hilfe von regxmlss......Page 577
Abfrageausführung mit Hilfe von URL......Page 578
SQL Server Modi......Page 580
Zusammenfassung......Page 583
Einleitung......Page 585
Der Volltextindex......Page 586
Aktivierung der Volltextsuche mit Hilfe des Enterprise Managers......Page 587
Auffüllen des Volltextindex......Page 589
Aktivieren einer Datenbank für die Volltextindizierung......Page 590
Erstellung eines Volltextkatallogs......Page 591
Vorbereitungsschritte......Page 592
Das FREETEXT-Prädikat......Page 593
Das CONTAINS-Prädikat......Page 594
FREETEXTTABLE......Page 596
CONTAINSTABLE......Page 597
Zusammenfassung......Page 598
Beispieldatenbank......Page 599
L.1.6......Page 601
L.2.2......Page 602
L.3.1......Page 603
L.4.1......Page 604
L.4.10......Page 605
L.5.3......Page 606
L.5.10......Page 607
L.6.1......Page 608
L.6.4......Page 609
L.6.8......Page 610
L.7.3......Page 611
L.8.1......Page 612
L.9.3......Page 613
L.10.2......Page 614
L.11.2......Page 615
L.12.1......Page 616
L.12.8......Page 617
L.13.1......Page 618
L.13.2......Page 619
L.14.9......Page 620
L.15.5......Page 621
L.19.2......Page 622
L.20.4......Page 623
L.22.3......Page 624
L.25.4......Page 625
L.26.6......Page 626
D......Page 627
N......Page 628
T......Page 629
W......Page 630
Recommend Papers
![Microsoft SQL Server 2000 Unleashed [2 ed.]
9780672324673, 0672324679](https://ebin.pub/img/200x200/microsoft-sql-server-2000-unleashed-2nbsped-9780672324673-0672324679.jpg)
File loading please wait...
Citation preview
Microsoft SQL Server 2000
Duan Petkoviæ
Microsoft SQL Server 2000
Bitte beachten Sie: Der originalen Printversion liegt eine CD-ROM bei. In der vorliegenden elektronischen Version ist die Lieferung einer CD-ROM nicht enthalten. Alle Hinweise und alle Verweise auf die CD-ROM sind ungültig.
An imprint of Pearson Education M ünchen • Boston • San Francisco • Harlow , England Don M ills, Ontario • Sydney • M exico City M adrid • Amsterdam
Die Deutsche Bibliothek – CIP-Einheitsaufnahme
Ein Titelsatz für diese Publikation ist bei Der Deutschen Bibliothek erhältlich
© 2001 Addison-Wesley Verlag, ein Imprint der Pearson Education Deutschland GmbH M artin-Kollar-Straße 10 –12, D-81829 M ü nchen/Germany Alle Rechte vorbehalten Einbandgestaltung: vierviertel gestaltung, Kö ln
Fü r Verbesserungsvorschläge und Hinw eise auf Fehler sind Verlag und Herausgeber dankbar.
Lektorat: M artin Asbach, [email protected] Herstellung: Anja Zygalakis, [email protected] Korrektorat: Sibille M ozer-Petkovic´ Satz: reemers publishing service gmbh, www.reemers.de. Gesetzt aus der Palatino 9,5/12 pt. Druck: Bercker Graphischer Betrieb, Kevelaer
Alle Rechte vorbehalten, auch die der fotomechanischen W iedergabe und der Speicherung in elektronischen M edien. Die gew erbliche Nutzung der in diesem Produkt gezeigten M odelle und Arbeiten ist nicht zulässig. Fast alle Hardw are- und Softw arebezeichnungen, die in diesem Buch erw ähnt w erden, sind gleichzeitig auch eingetragene Warenzeichen oder sollten als solche betrachtet w erden.
Printed in Germany Die Informationen in diesem Produkt w erden ohne Rü cksicht auf einen eventuellen Patentschutz verö ffentlicht. Warennamen w erden ohne Gew ährleistung der freien Verw endbarkeit benutzt. Bei der Zusammenstellung von Texten und Abbildungen w urde mit gr ößter Sorgfalt vorgegangen. Trotzdem k ö nnen Fehler nicht vollst ändig ausgeschlossen w erden. Verlag, Herausgeber und Autoren k ö nnen f ü r fehlerhafte Angaben und deren Folgen w eder eine juristische Verantw ortung noch irgendeine Haftung ü bernehmen.
Umw elthinw eis: Dieses Produkt w urde auf chlorfrei gebleichtem Papier gedruckt. Die Einschrumpffolie – zum Schutz vor Verschmutzung – ist aus umw eltvertr äglichem und recyclingf ähigem PE-M aterial.
10 9 8 7 6 5 4 3 2 1 04 03 02 01
ISBN 3-8273-1723-1
Inhaltsverzeichnis Vorwort Teil I
21 SQL Server: Grundkonzepte
1 Einleitung
25 27
1.1
Eigenschaften von MS SQL Server
27
1.2
Datenbanken – allgemein
29
1.2.1
Logische Datenunabhängigkeit
29
1.2.2
Physikalische Datenunabhängigkeit
29
1.2.3
Prozedurale und nichtprozedurale Schnittstellen
30
1.2.4
Effiziente Abarbeitung der Datenbankoperationen
30
1.2.5
Datenintegrität
30
1.2.6
Konkurrierender Datenzugriff
31
1.2.7
Datensicherheit
31
1.2.8
Datenschutz
31
1.3
Relationale Datenbanken
32
1.4
Datenbankdesign
35
1.4.1
Allgemeine Hinweise zur Normalisierung
36
1.4.2
Erste Normalform
36
1.4.3
Zweite Normalform
37
1.4.4
Dritte Normalform
37
1.4.5
Vierte Normalform
38
1.4.6
Das E/R-Modell
38
1.5
Die Datenbanksprache SQL
41
1.6
Notation
42
1.7
Zusammenfassung
43
2 SQL Server Enterprise Manager und Query Analyzer 2.1
Die SQL Server-Programmgruppe und Online-Dokumentation 47 2.1.1
2.2
47
SQL Server Onlinedokumentation
47
SQL Server Enterprise Manager – eine Einführung
49
2.2.1
Die Benutzung des Enterprise Managers
50
2.2.2
Verwaltung von Datenbanken und Datenbankobjekten 53
5
Inhaltsverzeichnis
2.2.3 2.3
2.4
Verwaltung von Tabellen mit Hilfe des Enterprise Managers
Query Analyzer
61
2.3.1
Verbindung zum Query Analyzer
62
2.3.2
Der Query Analyzer-Editor
62
Zusammenfassung
68
Transact-SQL-Sprache
71
3 Grundkomponenten des SQL Servers
73
Teil II
3.1
3.2
3.3
Grundelemente der SQL-Sprache
73
3.1.1
Literale
73
3.1.2
Begrenzer
75
3.1.3
Namen
75
3.1.4
Reservierte Wörter
75
Datentypen
76
3.2.1
Numerische Datentypen
76
3.2.2
Alphanumerische Datentypen
77
3.2.3
Datums- und Zeitangaben
79
3.2.4
Abgeleitete Datentypen
80
3.2.5
Neue Datentypen in SQL Server 7 und 2000
80
Prädikate
81
3.4
Aggregatfunktionen
82
3.5
Skalare Funktionen
82
3.5.1
Numerische Funktionen
82
3.5.2
Datumsfunktionen
84
3.5.3
Zeichenkettenfunktionen
85
3.5.4
Text/image-Funktionen
87
3.5.5
Systemfunktionen
87
3.6
Skalare Operatoren
3.7
NULL-Werte
91
3.8
Zusammenfassung
93
3.6.1
Globale Variablen und Ausdrücke
4 Datendefinition 4.1
6
57
89 90
95
Erstellen der Objekte
95
4.1.1
Erstellen einer Datenbank
96
4.1.2
CREATE TABLE-Anweisung – die Grundform
99
Inhaltsverzeichnis
4.2
4.3
4.1.3
Die erweiterte Form der CREATE TABLE-Anweisung 101
4.1.4
Die CREATE TABLE-Anweisung und die deklarativen Integritätsregeln
102
4.1.5
Die UNIQUE-Klausel
104
4.1.6
Die PRIMARY KEY-Klausel
104
4.1.7
Die FOREIGN KEY-Klausel
105
4.1.8
Die referentielle Integrität
106
4.1.9
Die ON DELETE- und ON UPDATE-Angabe
108
4.1.10
Die CHECK-Bedingung
110
4.1.11
Weitere Anweisungen zur Erstellung der Datenbankobjekte
111
Integritätsregeln und Wertebereiche
113
4.2.1
Benutzerdefinierte Datentypen
114
4.2.2
Definition der Standardwerte
115
4.2.3
Regeldefinition für Wertebereiche
116
Änderung der Objekte
117
4.3.1
Änderung einer Datenbank
117
4.3.2
Änderung der Tabellenstruktur
119
4.3.3
Die erweiterte Form der ALTER TABLE-Anweisung
120
4.4
Löschen der Objekte
123
4.5
Zusammenfassung
124
5 Einfache Abfragen 5.1 5.2
5.3
127
Grundform der SELECT-Anweisung
127
Die WHERE-Klausel
128
5.2.1
Boolesche Funktionen
131
5.2.2
Die Operatoren IN und BETWEEN
134
5.2.3
Der NULL-Operator
137
5.2.4
Der Operator LIKE
139
Einfache Unterabfragen
142
5.3.1
Unterabfrage und Vergleichsoperatoren
142
5.3.2
Unterabfragen und IN-Operator
143
5.3.3
Die Operatoren ANY und ALL
145
5.3.4
Die Funktion EXISTS
147
5.3.5
Die Unterabfragen in der FROM-Klausel
147
5.4
Die GROUP BY-Klausel
148
5.5
Aggregatfunktionen
149
5.5.1
150
Standard-Aggregatfunktionen
7
Inhaltsverzeichnis
5.5.2
Die Funktionen MIN und MAX
151
5.5.3
Die Funktion SUM
152
5.5.4
Die Funktion AVG
152
5.5.5
Die Funktionen COUNT und COUNT_BIG
153
5.5.6
Statistische Aggregatfunktionen
155
5.5.7
Super-Aggregatfunktionen
156
5.6
Die HAVING-Klausel
156
5.7
Die ORDER BY-Klausel
157
5.8
Die SELECT-Anweisung und die IDENTITY-Eigenschaft
159
5.9
Mengenoperatoren
160
5.10 Die Verwendung von CASE in Ausdrücken
164
5.11
166
Die COMPUTE-Klausel
5.12 Temporäre Tabellen
168
5.13 Berechnete Spalten
169
5.14 Zusammenfassung
170
6 Komplexe Abfragen 6.1
Verknüpfen zweier oder mehrerer Tabellen
173
6.2
Zwei Syntaxformen für die Join-Implementierung
174
6.2.1
Der Equijoin
175
6.2.2
Das Kartesische Produkt
177
6.2.3
Der Natürliche Join
178
6.2.4
Der Thetajoin
180
6.2.5
Verknüpfung von mehr als zwei Tabellen
182
6.2.6
Eine Tabelle mit sich selbst verknüpfen
183
6.2.7
Der Outer Join
185
6.3
Korrelierte Unterabfragen
188
6.4
Die EXISTS-Funktion in Unterabfragen
191
6.5
Zusammenfassung
194
7 Änderung der Tabelleninhalte 7.1
8
173
Die INSERT-Anweisung
197 197
7.1.1
Einfügen einer Reihe
197
7.1.2
Einfügen mehrerer Reihen
200
7.2
Die UPDATE-Anweisung
202
7.3
Die DELETE-Anweisung
204
7.4
Zusammenfassung
206
Inhaltsverzeichnis
8 SQL-Erweiterungen und Datenbankprozeduren 8.1
8.2
Transact-SQL-Erweiterungen
209
8.1.1
Der BEGIN-Block
209
8.1.2
Die IF-Anweisung
210
8.1.3
Die WHILE-Anweisung
210
8.1.4
Lokale Variablen
211
8.1.5
Weitere prozedurale Anweisungen
212
Datenbankprozeduren 8.2.1 8.2.2
8.3
8.5
215
Systemprozeduren
219
Erstellung und Ausführung benutzerdefinierter Funktionen
9.2
9.3
9.4
220 220
Text/image-Datentypen
224
8.4.1
Abfragen auf text/image-Daten
225
8.4.2
Modifikation der text/image-Daten
226
Zusammenfassung
9 Indizes und die Optimierung der Abfragen 9.1
213
Die Erstellung und Ausführung der Datenbankprozeduren
Benutzerdefinierte Funktionen 8.3.1
8.4
209
Indizes
227 229 229
9.1.1
Clustered und Nonclustered Indizes
231
9.1.2
Transact-SQL-Anweisungen in bezug auf Indizes
232
9.1.3
Indizes und Schlüssel
237
Kriterien zur Erstellung eines Index
239
9.2.1
WHERE-Klausel
239
9.2.2
AND-Operator
239
9.2.3
Join
240
Allgemeine Kriterien zur Verbesserung der Effizienz
241
9.3.1
Join statt korrelierter Unterabfrage
241
9.3.2
Unvollständige Anweisungen
242
9.3.3
Der LIKE-Operator
242
9.3.4
Transact-SQL-Anweisungen und Optimieren von Suchanweisungen
243
Der Optimierer
246
9.4.1
Statistiken
247
9.4.2
Implementierung der Join-Operation
249
9.4.3
Geschachteltes Loop-Join-Verfahren
249
9
Inhaltsverzeichnis
9.4.4
Das Merge-Join-Verfahren
250
9.4.5
Das Hash-Join-Verfahren
250
9.4.6
Hinweise für den Optimierer
251
9.5
DBCC-Kommando und Indizes
258
9.6
Zusammenfassung
259
10 Views
261
10.1 Datendefinitionsanweisungen und Views Erstellen von Views
261
10.1.2
Views modifizieren und löschen
266
10.2 Abfragen in Views
267
10.3 INSERT-Anweisung und View
268
10.4 UPDATE-Anweisung und View
271
10.5 DELETE-Anweisung und View
273
10.6 Partitionierte Views
274
10.7 Indizierte Views
275
10.7.1
Anforderung bezüglich indizierter Views
10.7.2
Änderung der Struktur eines indizierten Views
279
Optimiererhinweise und indizierte Views
279
11 Der Systemkatalog des SQL Servers 11.1
11.2 11.3
11.4
276
10.7.3
10.8 Zusammenfassung
10
261
10.1.1
280 283
Beschreibung der Systemtabellen
283
11.1.1
sysobjects
283
11.1.2
syscolumns
284
11.1.3
sysindexes
284
11.1.4
sysusers
285
11.1.5
sysdepends
285
11.1.6
sysdatabases
285
11.1.7
sysconstraints
286
11.1.8
sysreferences
286
Abfragen auf Systemtabellen
287
Andere Abfragemöglichkeiten
288
11.3.1
Systemprozeduren und der Systemkatalog
289
11.3.2
Systemfunktionen
292
11.3.3
Eigenschaftsfunktionen
292
11.3.4
Informationsschema
293
Zusammenfassung
295
Inhaltsverzeichnis
12 Das Sicherheitskonzept des SQL Servers
297
12.1 Einloggen in das SQL Server-System
297
12.1.1
sp_addlogin
299
12.1.2
sp_droplogin
299
12.1.3
sp_password
12.2 Datenbanksicherheit 12.2.1
Standardbenutzernamen
12.2.2
Setzen der Datenbankrechte
12.3 Rollen
299 300 300 300 302
12.3.1
Server-Rollen
303
12.3.2
Server-Rollen und ihre Rechte
304
12.3.3
Datenbankrollen
304
12.3.4
Applikationsrollen
306
12.3.5
Benutzerdefinierte Rollen
307
12.4 Transact-SQL-Anweisungen bezüglich der Sicherheit 12.4.1
309
Anweisungsberechtigungen und die GRANT-Anweisung
309
12.4.2
Objektberechtigungen und die GRANT-Anweisung
311
12.4.3
Die DENY-Anweisung
313
12.4.4
Die REVOKE-Anweisung
314
12.5 Einschränkung des Datenzugriffs mit Views
315
12.6 Einschränkung des Datenzugriffs mit Datenbankprozeduren
317
12.7 Zusammenfassung
317
13 Die prozedurale Datenintegrität
321
13.1 Einführung
321
13.2 Trigger
322
13.2.1
Anwendungsgebiete für AFTER-Trigger
13.2.2
Anwendungsgebiete für INSTEAD OF-Option
327
13.2.3
Ausführungsreihenfolge von multiplen Triggern
328
13.2.4
Änderung der Trigger-Struktur
329
13.3 Zusammenfassung 14 Transaktionen
323
329 331
14.1 Einführung
331
14.2 Transact-SQL-Anweisungen in bezug auf Transaktionen
332
14.2.1
Speicherung von Transaktionen
335
11
Inhaltsverzeichnis
14.3 Sperren 14.3.1
336 Objekte sperren
14.3.2
Typen von Sperren
337
14.3.3
Die SELECT-Anweisung und Sperren
340
14.3.4
Isolierungsstufen
340
14.4 Gegenseitige Blockierung (Deadlock)
342
14.5 Zusammenfassung
343
15 Systemumgebung
345
15.1 Speicherung von Daten
345
15.2 Systemdatenbanken
346
15.3 Dienstprogramme
347
15.3.1
osql
347
15.3.2
odbcping
349
15.3.3
isql
350
15.3.4
bcp
350
15.3.5
console
350
15.4 Instanzen des SQL Server-Systems
350
15.5 Unterstützung nationaler Sprachen
352
15.5.1
Die Auswahl des Zeichensatzes
15.6 Die Architektur des SQL Servers
Teil III
352 354
15.6.1
Die Architektur der Multiprozessorrechner
355
15.6.2
Multithreading-Architektur des SQL Servers
356
15.7 Zusammenfassung SQL Server: Systemadministration
16 Die Systemadministration
358
359 361
16.1 Der SQL Server und die Systemadministration
361
16.2 Die Administrationswerkzeuge des SQL Servers
363
16.3 Der Systemadministrator
364
16.4 Zusammenfassung
365
17 Die Planung und die Ausführung der Systeminstallation 17.1 Die Planung der Installation eines SQL Server-Systems
12
336
367 367
17.1.1
Anwendungszweck eines SQL Server-Systems
367
17.1.2
Hard- und Softwarevoraussetzungen
368
Inhaltsverzeichnis
17.1.3
Die notwendigen Angaben bei der Installation
17.2 Die Installation eines SQL Server-Systems
370 372
17.2.1
Installationsanfang
372
17.2.2
Die Installation von Client-Komponenten
378
17.2.3
Versionsumstellung
379
17.3 Administrationsaufgaben nach der Installation 17.3.1
381
Die Erstellung der Server-Gruppen und die Registrierung des Servers
381
17.3.2
Die Zuweisung eines Kennwortes der sa-Kennung
382
17.3.3
Server-Optionen setzen
383
17.4 Das Starten und Stoppen des SQL Server-Systems
384
17.5 Zusammenfassung
385
18 Das Verwalten der Systemressourcen
387
18.1 Verwaltung von Dateigruppen
387
18.1.1
Dateigruppen sichten
388
18.1.2
Dateien sichten
388
18.2 Datenbanken verwalten
389
18.2.1
Datenbank erstellen
390
18.2.2
Datenbankoptionen sichten bzw. ändern
390
18.2.3
Änderung der Datenbankstruktur
394
18.2.4
Datenbank löschen
396
18.3 Transaktionsprotokolle verwalten
396
18.4 Zusammenfassung
397
19 Benutzerverwaltung
399
19.1 Einführung
399
19.2 Verwaltung des Zugriffs auf das Datenbanksystem
401
19.2.1
Das Verwalten von Login-ID
19.3 Verwaltung des Zugriffs auf einzelne Datenbanken 19.3.1
Rollen
19.4 Zugriffsberechtigungen verwalten
401 403 404 407
19.4.1
Objektberechtigungen verwalten
408
19.4.2
Anweisungsberechtigungen verwalten
410
19.5 Zusammenfassung
411
13
Inhaltsverzeichnis
20 Die Archivierung und Wiederherstellung von Datenbanken 20.1 Einführung
413
20.1.1
Mögliche Fehler eines Datenbanksystems
413
20.1.2
Transaktionsprotokoll
414
20.2 Die Archivierung
415
20.2.1
Volle Archivierung
416
20.2.2
Differentielle Archivierung
416
20.2.3
Archivierung des Transaktionsprotokolls
416
20.2.4
Archivierung von Dateien
418
20.2.5
Die dynamische Archivierung
418
20.3 Archivierung verwalten
419
20.3.1
Archivierung mit Hilfe des Enterprise Managers
20.3.2
Planung der Archivierung mit Hilfe des Enterprise Managers
422
20.3.3
Der Sicherungsassistent
424
20.3.4
Archivierung mit Hilfe der Transact-SQL-Anweisungen
424
20.3.5
Welche Datenbanken sollen archiviert werden und wann ?
429
Vorbeugende Maßnahmen gegen den Datenverlust
431
20.3.6
20.4 Wiederherstellung von Datenbanken
419
434
20.4.1
Die automatische Wiederherstellung
20.4.2
Die vom Benutzer initiierte Wiederherstellung – eine Einführung
435
20.4.3
Die Wiederherstellung einer Benutzerdatenbank
436
435
20.4.4
Die Wiederherstellung der master-Datenbank
443
20.4.5
Die Wiederherstellung anderer Systemdatenbanken
443
20.4.6
Wiederherstellungsmodelle
444
20.4.7
Wiederherstellung zu einer Marke
446
20.5 Zusammenfassung
447
21 Der Transfer von Daten
449
21.1 Einführung
449
21.2 Data Transformation Services (DTS)
451
21.2.1
DTS-Pakete
451
21.2.2
Andere DTS-Komponenten
454
21.3 Das bcp-Kommando 21.3.1
Die Verwendung der austauschbaren Medien
21.4 Zusammenfassung
14
413
455 457 459
Inhaltsverzeichnis
22 Automatische Ausführung der Administrationsaufgaben
461
22.1 Einführung
461
22.2 SQL Server Agent
462
22.2.1
Starten und Konfigurieren des SQL Server Agent
22.3 Erstellung von Aufträgen und Operatoren
463 464
22.3.1
Auftragsschritte definieren
464
22.3.2
Auftrag erstellen
465
22.3.3
Planung der Auftragsausführung
467
22.3.4
Operatoren und Benachrichtigungen erstellen
468
22.3.5
Auftragschronik
470
22.4 Warnungen
472
22.4.1
Die Erstellung von Standardwarnungen
473
22.4.2
Benutzerdefinierte Warnungen
477
22.5 Auftragsautomatisierung in Multi-Server-Umgebung
478
22.6 Zusammenfassung
479
23 Die Untersuchung und Behebung entstandener Systemfehler 23.1 Fehlermeldungen 23.1.1
Das SQL Server-Protokoll
23.1.2
Windows NT/2000-Ereignisprotokoll
481 481 483 484
23.2 Fehlerbehebung
485
23.3 Zusammenfassung
487
24 Die Durchführung der Maßnahmen zur Verbesserung der Performance
489
24.1 Einführung
489
24.2 Anwendungen und die Performance
490
24.2.1
Benutzeranforderungen
490
24.2.2
Die Effizienz des Benutzercodes
491
24.2.3
Logisches Datenbankdesign
491
24.2.4
Physikalisches Datenbankdesign
24.3 Das Datenbankmanagementsystem
491 493
24.3.1
Der Optimierer
493
24.3.2
Sperren
493
24.4 Systemressourcen
494
24.4.1
Die Effizienz des Prozessors
494
24.4.2
Arbeitsspeicher
495
15
Inhaltsverzeichnis
24.4.3
Platten-Ein- und -Ausgabe
496
24.4.4
Netzwerkeffizienz
496
24.4.5
Benutzerverbindungen
24.5 Komponenten zur Überwachung der Performance
496 497
24.5.1
Performance-Werkzeuge für Datenbankanwendungen
497
24.5.2
SQL Server spezifische Performance-Werkzeuge
501
24.5.3
Werkzeuge zur Überwachung der Systemressourcen
503
24.5.4
Der SQL Server Profiler
504
24.5.5
Der Indexoptimierungsassistent
505
24.6 Zusammenfassung
512
25 Datenreplikation
515
25.1 Einführung
515
25.1.1
SQL Server Datenreplikation – ein Überblick
516
25.1.2
Publikations-, Abonnement- und Verteilungsserver
25.2 Publikationstypen
517 518
25.2.1
Transaktionale Publikation
518
25.2.2
Snapshot-Publikation
520
25.2.3
Merge-Publikation
520
25.3 Replikationsmodelle
522
25.3.1
Zentraler Verleger mit dem Verteiler
523
25.3.2
Zentraler Abonnent mit multiplen Verlegern
524
25.3.3
Multiple Verleger mit multiplen Abonnenten
524
25.4 Datereplikationen verwalten 25.4.1
Setzen des Verteilungs- und Publikationsservers
25.4.2
Setzen des Abonnementservers
25.5 Zusammenfassung
524 525 527 528
Teil IV MS Analysis Services 26 Data Warehousing-Systeme – eine Einführung 26.1 OLTP- und Data Warehousing-Systeme 26.1.1
OLTP-Systeme
26.1.2
Data Warehouse-Systeme
533 533 533 534
26.2 Data Warehouse und Data Mart
535
26.3 Der Entwurf eines Data Warehouse
538
26.3.1
16
531
Dimensionales Modell
538
Inhaltsverzeichnis
26.4 Multidimensionale Würfel und Speicherungsmodi 26.4.1
MOLAP, ROLAP und HOLAP
26.5 Zusammenfassung 27 Server-Komponenten des MS Analysis Services
542 543 544 545
27.1 Einführung
545
27.2 Architektur von Analysis Services
546
27.2.1
Data Warehouse-Tier
546
27.2.2
Server-Tier
547
27.2.3
Client-Tier
27.3 Analysis Services-Komponenten
548 549
27.3.1
Katalog
549
27.3.2
Der Analysis Manager
550
27.3.3
Data Transformation Services (DTS)
554
27.4 Zusammenfassung 28 Client-Komponenten des Analysis Services 28.1 Transact-SQL-Erweiterungen in bezug auf Analysis Services 28.1.1
Der CUBE-Operator
555 557 557 557
28.1.2
Der Operator ROLLUP
560
28.1.3
Die TOP n-Klausel
561
28.2 Microsoft Client-Werkzeuge
562
28.2.1
Excel 2000
563
28.2.2
Analysis Manager
563
28.3 Client-Software der Drittanbieter
565
28.4 Zusammenfassung
566
Teil V
Erstellung der Softwarelösungen mit MS SQL Server
29 SQL Server und XML 29.1 Einleitung
567 569 569
29.1.1
World Wide Web
569
29.1.2
XML und verwandte Sprachen
570
29.1.3
Grundkonzepte von XML
571
29.2 SQL Server und XML-Unterstützung 29.2.1
Erstellung des IIS virtuellen Verzeichnisses mit Hilfe der graphischen Schnittstelle
574 574
17
Inhaltsverzeichnis
29.2.2
Erstellung eines IIS virtuellen Verzeichnisses mit Hilfe von regxmlss
577
29.2.3
Abfrageausführung mit Hilfe von URL
578
29.2.4
SQL Server Modi
580
29.3 Zusammenfassung 30 Die Volltextsuche
585
30.1 Einleitung
585
30.2 Der Volltextindex
586
30.2.1
Aktivierung der Volltextsuche mit Hilfe des Enterprise Managers
587
30.2.2
Auffüllen des Volltextindex
589
30.2.3
Aktivieren einer Datenbank für die Volltextindizierung
590
30.2.4
Aktivieren einer Tabelle für die Volltextindizierung
591
30.2.5
Aktivieren einer Spalte für die Volltextindizierung
591
30.2.6
Erstellung eines Volltextkatallogs
591
30.3 Abfragen mit Hilfe eines Volltextindex 30.3.1
Vorbereitungsschritte
592 592
30.3.2
Das FREETEXT-Prädikat
593
30.3.3
Das CONTAINS-Prädikat
594
30.3.4
FREETEXTTABLE
596
30.3.5
CONTAINSTABLE
597
30.4 Zusammenfassung
598
A Die Beispieldatenbank
599
B Lösungen
601
B.1
KAPITEL 1
601
B.2
KAPITEL 2
602
B.3
KAPITEL 3
603
B.4
KAPITEL 4
604
B.5
KAPITEL 5
606
B.6
KAPITEL 6
608
B.7
KAPITEL 7
611
B.8
KAPITEL 8
612
B.9
KAPITEL 9
613
B.10 KAPITEL 10
18
583
614
Inhaltsverzeichnis
B.11 KAPITEL 11
615
B.12 KAPITEL 12
616
B.13 KAPITEL 13
618
B.14 KAPITEL 14
620
B.15 KAPITEL 15
621
B.16 KAPITEL 18
622
B.17 KAPITEL 19
622
B.18 KAPITEL 20
623
B.19 KAPITEL 21
624
B.20 KAPITEL 22
624
B.21 KAPITEL 23
625
B.22 KAPITEL 25
625
B.23 KAPITEL 26
626
Stichwortverzeichnis
627
19
Vorwort Relationale Datenbanksysteme sind in den letzten Jahren mit Abstand die wichtigsten Datenbanksysteme geworden, die in der Praxis angewendet werden. Die Gründe dafür sind mannigfaltig: die hohe Portierbarkeit der Anwendungen, die Verwendung der Standarddatenbanksprache SQL usw. Eines der herausragendsten relationalen Datenbanksysteme heutzutage stellt der SQL Server der Firma Microsoft dar. Der SQL Server gilt als am weitesten entwickeltes relationales Datenbanksystem in bezug auf mindestens folgende drei Themen: die benutzerfreundliche graphische Schnittstelle, die optimale Unterstützung der Rechner mit eng gekoppelten Prozessoren und die Untersützung der sehr großen Datenbanken bzw. Data Warehouses. Dieses Buch führt den Leser in das komplette SQL Server-System ein. Im Unterschied zu der SQL Server-Onlinedokumentation, die sehr umfangreich und dadurch für den Benutzer manchmal unübersichtlich ist, versucht dieses Buch dem Leser sowohl beim Erlernen der verschiedenen SQL ServerKomponenten behilflich zu sein, als auch die Zusammenhänge zwischen diesen Komponenten verständlich zu machen. Das Buch berücksichtigt auch, daß es zwei unterschiedliche Gruppen von Benutzern gibt, die das SQL Server-System verwenden. Auf der einen Seite sind Endbenutzer und Datenbankprogrammierer und auf der anderen die Systemadministratoren. Dementsprechend kann das Buch in fünf Teile unterteilt werden: Der erste Teil des Buches – Kapitel 1 und 2 – erläutert die Grundbegriffe des Systems und ist für alle Benutzer als Einführung gedacht. Der zweite Teil – Kapitel 3 bis 15 – ist den Endbenutzern und den Datenbankprogrammierern gewidmet. In diesem Teil wird die Transact-SQL-Sprache erörtert. Der dritte Teil – Kapitel 16 bis 25 – erläutert alle Aufgaben, die ein Systemadministrator durchzuführen hat. Der beiden letzten Teile des Buches sind den unterschiedlichen Möglichkeiten gewidmet, wie Softwarelösungen mit dem SQL Server gebaut werden können. Dementsprechend beschreibt der vierte Teil (Kapitel 26 bis 28) die Analysis Services-Komponente, während Kapitel 29 und 30 die XML-Unterstützung und Volltextindizierung in dieser Reihenfolge erläutern. Das Buch ist als praktisches Lehrbuch gedacht. Diesem Ziel dienen zahlreiche Beispiele, die alle auf einer sehr kleinen Beispieldatenbank basieren. Dem Leser wird empfohlen, die Beispieldatenbank mit dem zur Verfügung stehenden SQL Server-System zu erstellen und alle angegebenen Beispiele nachzuvollziehen. (Die zip-Datei, die alle Dateien für die Erstellung der Beispieldatenbank enthält, befindet sich auf meiner Internet-Seite (siehe
21
Vorwort
unten).) Dasselbe gilt für die Übungsaufgaben, die sich am Ende fast jedes Kapitels befinden. Sowohl die Beispiele als auch die Übungsaufgaben sind am Rechner erstellt und getestet worden. Das Thema des Buches ist der SQL Server Version 2000. Die funktionalen Unterschiede dieser Version zu den vorherigen Versionen sind an den entsprechenden Stellen im Buch beschrieben. Das Buch hat insgesamt 30 Kapitel, die, wie schon erwähnt, in fünf Teile unterteilt werden können. Der erste Teil des Buches führt den Benutzer in allgemeine Themen wie Datenbanken und SQL. Zusätzlich dazu enthält dieser Teil auch eine Einführung in die beiden wichtigsten Komponenten des SQL Servers: den Enterprise Manager und Query Analyzer. Der zweite Teil des Buches enthält selbst insgesamt vier Unterteile. Kapitel 3 beschreibt die Grundelemente der Transact-SQL-Sprache. Die Kapitel 4 bis 8 beschreiben alle Datendefinitions- und Datenmanipulationsanweisungen der Transact SQL-Sprache sowie die prozeduralen Erweiterungen von Transact-SQL. Kapitel 9 bis 14 enthalten allgemeine Datenbankkonzepte: Kapitel 9 die Indizes, Kapitel 10 Views, Kapitel 11 den Systemkatalog, Kapitel 12 die Datensicherheit, Kapitel 13 Trigger und Kapitel 14 Transaktionen. Schließlich beinhaltet Kapitel 15 die Beschreibung der Systemumgebung des SQL Servers. Der dritte Teil befaßt sich mit allen Funktionen, die ein Systemadministrator für seine Aufgabe braucht: Kapitel 16 stellt eine Einführung in diesen Teil des Buches dar, während die nachfolgenden Kapitel folgende Themen erläutern: 왘 die Systeminstallation (Kapitel 17) 왘 das Verwalten der Systemressourcen (Kapitel 18) 왘 die Benutzerverwaltung (Kapitel 19) 왘 die Archivierung und Wiederherstellung von Datenbanken (Kapitel 20) 왘 den Transfer von Daten (Kapitel 21) 왘 die automatische Ausführung der Administrationsaufgaben (Kapitel 22) 왘 die Untersuchung und Behebung entstandener Systemfehler (Kapitel 23) 왘 die System-Performance (Kapitel 24) 왘 die Datenreplikation (Kapitel 25).
Der vorletzte Teil des Buches erläutert die MS Analysis Services-Komponente. Nach der allgemeinen Einführung zu Data Warehousing-Systemen, die in Kapitel 26 gegeben ist, werden die Server- (Kapitel 27) und ClientKomponenten (Kapitel 28) der Analysis Services beschrieben. Der letzte Teil des Buches beschreibt die Untersützung von XML (Kapitel 29) und Volltextindizierung mit Hilfe des MS Search-Dienstes (Kapitel 30).
22
Vorwort
Das Buch wendet sich an Endbenutzer, Datenbankprogrammierer und Systemadministratoren des SQL Server-Systems sowie an alle, die dieses System erlernen wollen. Vom Leser werden keine tieferen EDV-Kenntnisse erwartet. Kenntnisse einer Programmiersprache sind nicht Voraussetzung, können aber hilfreich sein. Kommentare und Kritiken von Lesern dieses Buches sind willkommen. Bitte benutzen Sie die Seite: www.fh-rosenheim.de/~petkovic.
23
I
Teil
SQL Server: Grundkonzepte
25
1
Einleitung
Der SQL Server von Microsoft ist ein relationales Datenbankmanagementsystem, das seinen Ursprung in einem Projekt an der Universität von Kalifornien in Berkeley (1973-1975) hat. Nachdem der erste Prototyp des im Projekt entstandenen Datenbankmanagementsystems (DBMS) erstellt worden war, haben mehrere Mitarbeiter das Projekt verlassen, um eine eigene Firma, die sich der Herstellung eines kommerziellen Datenbankmanagementsystems widmete, zu gründen. Diese Firma hieß Britton Lee und wurde u.a. von Dr. Robert Epstein und Mark Hoffman gegründet. Das erste kommerzielle System dieser Firma wurde im Jahre 1981 freigegeben. 1986 verließen Dr. Epstein und Mark Hoffman die Firma Britton Lee und gründeten die neue Firma – Sybase Inc. Ziel der neuen Firma war, eine offene Client-Server-Datenbankarchitektur zu entwickeln. Bereits 1987 machte Sybase den SQL Server verfügbar und damit das erste relationale Datenbankmanagementsystem, das explizit für die Verteilung von Funktionalitäten über heterogene Client/Server-Umgebungen hinweg entwickelt worden war. Als Partner der Firma Sybase hat Microsoft die Lizenz für den SQL Server im Jahre 1988 erworben und in demselben Jahr die erste Version des SQL Servers für das Betriebssystem OS/2 freigegeben. Anfang der neunziger Jahre wurde die Entwicklung des SQL Servers für Windows NT begonnen, mit dem Ziel, das Datenbankmanagementsystem eng mit dem Betriebssystem zu integrieren. Im Jahre 1992 hat Microsoft den Quellcode für den SQL Server von Sybase erworben. Ende 1993 wurde der SQL Server V4.2 für Windows NT V3.1 freigegeben. Im April 1994 hat Microsoft den Kooperationsvertrag mit Sybase gekündigt und entwickelt seitdem allein den SQL Server weiter.
1.1
Eigenschaften von MS SQL Server
Der SQL Server ist der wichtigste Teil von Microsoft Back Office, das eine Palette unterschiedlicher Softwareprodukte für die Client-Server Programmierung darstellt. (Neben dem SQL Server enthält MS Back Office noch folgende Komponenten: Windows NT/2000 Server, SNA Server, Systems Management Server, Exchange 2000 Server, MS Transaction Server, Internet Information Server und MSMQ Server.) Der SQL Server 2000 läuft unter Windows NT/2000 und Windows 9x. Die Entscheidung der Firma Microsoft, SQL Server ausschließlich unter diesen beiden eigenen Betriebssystemen laufen zu lassen, hat viele Vorteile, aber auch einen Nachteil. Die wichtigsten Vorteile sind:
27
Einleitung 왘 Das
SQL Server-System kann als natürliche Erweiterung von Windows NT/2000 betrachtet werden, weil es mit diesem Betriebssystem eng verbunden ist. Der Vorteil für den Benutzer ist, daß er eine schon bekannte Benutzerschnittstelle verwenden kann.
왘 Der SQL Server 2000 ist sehr benutzerfreundlich. Die Installation der
Software ist sehr leicht, und viele komplexe Administrationsaufgaben, die in vorherigen Versionen noch der Datenbankadministrator machen mußte, werden automatisch vom System durchgeführt. 왘 Der SQL Server 2000 verwendet Windows NT/2000, um erweiterte Da-
tenbankdienste anzubieten. Dazu gehören zum Beispiel die Verwaltung der Benutzerkennungen und die Erstellung bzw. der Empfang von Warnungen. Andererseits hindert die Konzentration auf die beiden Betriebssysteme von Microsoft den SQL Server daran, spezielle Eigenschaften des UNIX-Betriebssystems (wie z.B. parallele Server-Architekturen und unternehmensweite Programmierung) zu verwenden. Microsoft hat den SQL Server 2000 mit der neuen Software – MS Analysis Services gebündelt, um ein kombiniertes System anzubieten, das neben den operativen auch die analytischen Dienste durchführen kann. MS Analysis Services ermöglicht den Aufbau von Data Warehouses and Data Marts. (Der vierte Teil dieses Buches beschreibt ausführlich diese neue Technologie von Microsoft.) Der SQL Server enthält, wie alle anderen relationalen Datenbankmanagementsysteme 왘 Client-Komponenten (front ends) und 왘 den Datenbank-Server (back end) .
Client-Komponenten kennzeichnen herstellerspezifische Werkzeuge, die unterschiedliche Schnittstellen für verschiedene Anwenderaktivitäten (Erstellung von Datenbankanwendungen, Monitoring usw.) darstellen. Zu den MS SQL Server Client-Komponenten gehören u.a.: 왘 Enterprise Manager 왘 Query Analyzer 왘 Performance Monitor 왘 Service Manager 왘 Profiler
Alle diesen Client-Komponenten werden in unterschiedlichen Kapiteln dieses Buches beschrieben. Zum Datenbank-Server gehört jene Datenbank-Software, die die Verwaltung von gespeicherten Daten ermöglicht und solche Aufgaben wie Datendefinition, Datenmanipulation usw. übernimmt. Das SQL Server-System von Microsoft hat den gleichnamigen Datenbank-Server.
28
Datenbanken – allgemein
1.2
Datenbanken – allgemein
Bevor wir uns mit relationalen Datenbanken befassen, soll der Begriff der Datenbank allgemein erläutert werden. Eine Datenbank kann aus verschiedenen Blickwinkeln betrachtet werden, abhängig davon, in welchem Zusammenhang sie gesehen wird. Aus der Sicht eines Managers ist die Datenbank eine Sammlung logisch zusammenhängender Daten, die ein Modell der Aktivitäten seines Unternehmens darstellen. Aus der Sicht eines Datenbankmanagementsystems ist die Datenbank eine Sammlung von physikalischen Daten. Obwohl beide Betrachtungsweisen diametral verschieden sind, haben sie etwas gemeinsam: Sie erfordern Funktionen, mit denen eine Datenbank abgefragt und modifiziert werden kann sowie Schnittstellen, die maschinenunabhängig sind. Alle diese Funktionen und Schnittstellen soll ein Datenbankmanagementsystem bieten. Zusammenfassend soll ein Datenbankmanagementsystem folgendes gewährleisten: 왘 logische Datenunabhängigkeit 왘 physikalische Datenunabhängigkeit 왘 prozedurale und nichtprozedurale Schnittstellen 왘 effiziente Abarbeitung von Datenbankoperationen 왘 Datenintegrität 왘 konkurrierender Datenzugriff 왘 Datensicherheit 왘 Datenschutz
Jede dieser Grundeigenschaften eines Datenbankmanagementsystem soll nachfolgend erläutert werden.
1.2.1
Logische Datenunabhängigkeit
Die logische Datenunabhängigkeit bezieht sich auf unterschiedliche logische Sichten einer Datenbank. Einerseits existiert die logische Struktur einer Datenbank mit allen dazugehörigen Objekten und Zusammenhängen, die zwischen diesen Objekten bestehen. Andererseits sieht jeder Benutzer, der eine Datenbankanwendung programmiert oder benutzt, nur den für ihn relevanten Ausschnitt der gesamten logischen Struktur. Die logische Unabhängigkeit bedeutet, daß jeder Benutzer seine Sicht der Datenbank erzeugen und modifizieren kann, ohne daß die logische Gesamtstruktur geändert werden müßte.
1.2.2
Physikalische Datenunabhängigkeit
Unter der physikalischen Datenunabhängigkeit versteht man die Unabhängigkeit zwischen logischer und physikalischer Struktur einer Datenbank.
29
Einleitung
Die physikalische Datenunabhängigkeit garantiert, daß die physikalische Struktur einer Datenbank beliebig geändert werden kann, ohne daß dadurch die logische Struktur berührt wird.
1.2.3
Prozedurale und nichtprozedurale Schnittstellen
Bei Datenbankmanagementsystemen existieren u.a. zwei Arten von Benutzern, nämlich der Programmierer und der Endbenutzer. Die Aufgabe eines Programmierers ist es, Programme zu schreiben, mit denen eine Datenbank abgefragt oder modifiziert werden kann. Endbenutzer sind in der Regel keine DV-Fachleute. Sie greifen auf die Datenbank über eine leicht erlernbare Kommandosprache zu. Falls auf der Ebene dieser Kommandosprache Kontrollstrukturen angeboten werden, wie z.B. IF bedingung THEN wahr_zweig ELSE falsch_zweig
spricht man von einer prozeduralen, ansonsten von einer nichtprozeduralen Schnittstelle. Ein Programmierer hat in den meisten Fällen weitaus komplexere Aufgabenstellungen zu erledigen als ein Endbenutzer und benötigt daher nahezu immer Programmiersprachen mit einem umfangreichen Spektrum an Kontrollstrukturen. Dementsprechend sind alle bekannteren Datenbankschnittstellen für Programmierer prozedurale Schnittstellen.
1.2.4
Effiziente Abarbeitung der Datenbankoperationen
Mit der Verwendung mächtiger Datenbankprogrammiersprachen wird die Entwicklungszeit von Datenbankanwendungen in der Regel reduziert, oft allerdings auf Kosten von zusätzlichen E/A-Operationen und längerer Verarbeitungszeit. Das Datenbankmanagementsystem sollte daher für die Abarbeitung der jeweiligen Datenbankoperation eine optimale Strategie entwickeln können.
1.2.5
Datenintegrität
Ein Datenbankmanagementsystem sollte offensichtlich unsinnige Daten erkennen und abweisen können. (Das Datum 30.Februar oder die Uhrzeit 17:77:00 sind typische Beispiele.) Des weiteren ist es wünschenswert, gegenüber dem Datenbankmanagementsystem Begrenzungen oder Formatangaben zu Eingabedaten deklarieren zu können, z.B.: Jahrgang > 1959
30
Datenbanken – allgemein
Ausgereifte Datenbankmanagementsysteme stellen außerordentlich komplexe Mechanismen zur Plausibilitätsprüfung von Eingabedaten zur Verfügung. Dazu gehört insbesondere die Fähigkeit, bereits in der Datenbank vorhandene Daten in die Plausibilitätsprüfung mit einzubeziehen.
1.2.6
Konkurrierender Datenzugriff
Der Umstand, daß im Regelfall viele Benutzer gleichzeitig auf eine Datenbank zugreifen, wirft eine Reihe von Problemen auf. Ein besonders gravierendes Problem wird durch das folgende Beispiel erläutert: 1. Auf dem Konto 4711 der Bank X befinden sich 2.000,- DM. 2. Die Kunden A und B gehen in zwei verschiedene Filialen der Bank X und heben gleichzeitig 1.000,- DM vom Konto 4711 ab. 3. Die Kassierer in beiden Bankfilialen bekommen vom Datenbanksystem den Kontostand 2.000,- DM gezeigt. 4. Beide Kassierer zahlen jeweils 1.000,- DM aus und ändern das Konto 4711 mit dem Wert 2.000,- DM minus 1.000,- DM gleich 1.000,- DM. 5. Es ist nun unerheblich, in welcher Reihenfolge diese beiden Änderungen ausgeführt werden; das Konto 4711 steht auf 1000,- DM statt auf 0,- DM. Der ganze Problemkreis des konkurrierenden Datenzugriffs, der hier aufgezeigt wurde, muß von einem Datenbankmanagementsystem natürlich mit völliger Korrektheit abgehandelt werden. Bezogen auf das vorangehende Beispiel bedeutet dies, daß ein Datenbankmanagementsystem den Kontostand von 0 DM garantieren muß, nachdem die beiden Kunden je 1.000,- DM ausgezahlt wurden.
1.2.7
Datensicherheit
Der Begriff der Datensicherheit bezieht sich auf den Ausfall von Hardware und/oder Software. Ein Datenbankmanagementsystem sollte in der Lage sein, nach denkbaren Ausfällen die betroffenen Datenbanken automatisch in den letzten konsistenten Stand zu überführen.
1.2.8
Datenschutz
Eine Datenbank sollte gegen unerlaubten Zugriff geschützt werden können. Wenn z.B. eine Datenbank die Gehälter der Mitarbeiter einer Firma enthält, ist es dringend notwendig, den Zugriff auf diese Daten nur ausgewählten Benutzern zu ermöglichen. Dasselbe gilt für die sicherheitsrelevanten Daten eines Unternehmens. Entsprechende Möglichkeiten, wie Vergabe und Entzug der Zugriffsrechte, sollte jedes Datenbankmanagementsystem unterstützen.
31
Einleitung
1.3
Relationale Datenbanken
Der Begriff der relationalen Datenbanken wurde 1970 von E.F.Codd eingeführt. In dem Artikel »A Relational Model of Data for Large Shared Data Banks« wurde die theoretische Grundlage für relationale Datenbanken festgelegt: das sogenannte relationale Datenmodell. Im Unterschied zu anderen Datenbankmanagementsystemen (netzwerkartigen bzw. hierarchischen Systemen), basiert das relationale Modell völlig auf den mathematischen Grundlagen der relationalen Algebra. Eine Erklärung der relationalen Algebra liegt außerhalb der Ziele dieses Buches. Wir werden die wichtigsten Eigenschaften des relationalen Modells mit Hilfe einer Beispieldatenbank erklären. Weiter dient die Beispieldatenbank als Grundlage für alle praktischen Beispiele innerhalb dieses Buches. Das Grundelement einer relationalen Datenbank ist die Tabelle. Aus der Benutzersicht besteht jede relationale Datenbank nur aus Tabellen. Eine Tabelle setzt sich aus Reihen und Spalten zusammen, d.h. sie beinhaltet keine, eine oder mehrere Reihen und eine oder mehrere Spalten. Das Objekt, das genau zu einer Reihe und einer Spalte gehört, heißt Datenwert oder Datum. Die Beispieldatenbank enthält die Datenwerte einer Firma, die in mehrere Abteilungen unterteilt ist. Jeder Mitarbeiter der Firma gehört einer der existierenden Abteilungen an. Die Eigenschaft unserer Firma ist, daß die Mitarbeiter ihre Tätigkeiten in verschiedenen Projekten ausüben. Jeder Mitarbeiter kann in verschiedenen Projekten arbeiten und dabei unterschiedliche Aufgaben wahrnehmen. Die Datenbank besteht bei uns aus vier Tabellen: 왘 abteilung, 왘 mitarbeiter, 왘 projekt und 왘 arbeiten.
Die Tabelle abteilung stellt alle Abteilungen der Firma dar. Jede Abteilung ist auf folgende Weise beschrieben: abteilung (abt_nr,abt_name,stadt)
abt_nr ist die für jede Abteilung der Firma eindeutige Abteilungsnummer. abt_name steht für den Namen der Abteilung; stadt für die Stadt, in der sich diese Abteilung befindet. Die Tabelle mitarbeiter beinhaltet alle Mitarbeiter der Firma. Jeder Mitarbeiter ist auf folgende Weise beschrieben: mitarbeiter (m_nr,m_name,m_vorname,abt_nr)
m_nr kennzeichnet die für jeden Mitarbeiter eindeutige Personalnummer. m_name und m_vorname kennzeichnen Namen und Vornamen des Mitarbeiters, während abt_nr die Nummer der Abteilung benennt, welcher der Mitarbeiter angehört.
32
Relationale Datenbanken
Die Tabelle projekt stellt alle Projekte der Firma dar. Jedes Projekt ist dabei auf folgende Weise beschrieben: projekt (pr_nr,pr_name,mittel)
pr_nr bezeichnet die innerhalb der Firma eindeutige Nummer des Projektes. pr_name und mittel kennzeichnen den Namen des Projektes bzw. die Geldmittel, die für das Projekt zur Verfügung stehen. Die Geldmittel sind in DM angegeben. Die Tabelle arbeiten beschreibt die Beziehung zwischen den Mitarbeitern und den Projekten. Diese Tabelle ist auf folgende Weise beschrieben: arbeiten (m_nr,pr_nr,aufgabe,einst_dat)
m_nr zeigt die Personalnummer des Mitarbeiters und pr_nr die Nummer des Projektes, in dem der Mitarbeiter arbeitet, an. Die Kombination aus m_nr und pr_nr ist innerhalb der Firma eindeutig. aufgabe beschreibt die Funktion des Mitarbeiters (mit der Personalnummer m_nr) innerhalb des Projektes (mit der Nummer pr_nr). einst_dat kennzeichnet das Eintrittsdatum des Mitarbeiters in das Projekt. Die relationale Datenbank für das soeben beschriebene Schema ist in Tabellen 1.1 bis 1.4 dargestellt. Tabelle 1.1: Tabelle abteilung
abt_nr
abt_name
stadt
a1 a2 a3
Beratung Diagnose Freigabe
München München Stuttgart
m_nr
m_name
m_vorname
abt_nr
25348 10102 18316 29346 9031 2581 28559
Keller Huber Müller Probst Meier Kaufmann Mozer
Hans Petra Gabriele Andreas Rainer Brigitte Sibille
a3 a3 a1 a2 a2 a2 a1
pr_nr
pr_name
mittel
p1 p2 p3
Apollo Gemini Merkur
120000.0 95000.0 186500.0
Tabelle 1.2: Tabelle mitarbeiter
Tabelle 1.3: Tabelle projekt
33
Einleitung Tabelle 1.4: Tabelle arbeiten
m_nr
pr_nr
aufgabe
einst_dat
10102 10102 25348 18316 29346 2581 9031 28559 28559 9031 29346
p1 p3 p2 p2 p2 p3 p1 p1 p2 p3 p1
Projektleiter Gruppenleiter Sachbearbeiter
1.Okt.1988 0:00 1.Jan.1989 0:00 15.Feb.1988 0:00 1.Jun.1989 0:00 15.Dez.1987 0:00 15.Okt.1989 0:00 15.Apr.1989 0:00 1.Aug.1988 0:00 1.Feb.1989 0:00 15.Nov.1988 0:00 1.Apr.1989 0:00
Projektleiter Gruppenleiter Sachbearbeiter Sachbearbeiter Sachbearbeiter
Mit Hilfe unseres Beispiels können wir jetzt einige wichtige Eigenschaften des relationalen Modells erklären: 왘 die Reihen innerhalb einer Tabelle können eine beliebige Reihenfolge ha-
ben; 왘 die Spalten innerhalb einer Tabelle können eine beliebige Reihenfolge ha-
ben; 왘 alle Datenwerte einer Spalte haben genau denselben Datentyp; 왘 jede Spalte hat einen eindeutigen Namen innerhalb einer Tabelle. Spal-
ten, die verschiedenen Tabellen angehören, können durchaus denselben Namen haben. (Beispiel: Die Spalte m_nr in der Tabelle arbeiten und die Spalte m_nr in der Tabelle mitarbeiter.); 왘 jeder einzelne Datenwert innerhalb einer Tabelle ist durch einen einzigen
Wert dargestellt. Das heißt: In einer Reihe und innerhalb einer Spalte können sich nie mehrere Werte gleichzeitig befinden; 왘 in jeder Tabelle einer relationalen Datenbank existiert ein Bezeichner, der
jede Reihe der Tabelle eindeutig definiert. Dieser Bezeichner kann entweder aus einer Spalte oder aus einer Kombination mehrerer Spalten bestehen. Im relationalen Modell heißt dieser Bezeichner Primärschlüssel. Die Spalte abt_nr ist der Primärschlüssel in der Tabelle abteilung; m_nr ist der Primärschlüssel in der Tabelle mitarbeiter; pr_nr ist der Primärschlüssel in der Tabelle projekt und die Kombination der Spalten (m_nr, pr_nr) ist der Primärschlüssel in der Tabelle arbeiten. (Die Primärschlüssel der Beispieldatenbank sind grau dargestellt.) 왘 in einer Tabelle existieren nie zwei identische Reihen. (Diese Eigenschaft
wird vom SQL Server und allen anderen relationalen Datenbankmanagementsystemen nicht unterstützt.)
34
Datenbankdesign
In der Terminologie relationaler Datenbanken existieren mehrere analoge Begriffe. So entsprechen die mathematischen Begriffe Relation, Tupel und Attribut in der Praxis jeweils den Begriffen Tabelle, Reihe und Spalte in dieser Reihenfolge. Zusätzlich existieren in der Praxis weitere Begriffe wie Satz oder Record (für Reihe), Feld (für Spalte) usw. In diesem Buch werden nur die Begriffe benutzt, die im SQL-Standard verwendet werden, also Tabelle, Reihe und Spalte.
1.4
Datenbankdesign
Das Datenbankdesign ist eine sehr wichtige Phase, die der Erstellung einer Datenbank vorangeht. Falls das Datenbankdesign intuitiv und ohne sorgfältige Analysephase entworfen wird, ist die daraus resultierende Datenbank in den meisten Fällen nicht optimal an die Aufgabe, zu deren Lösung sie aufgebaut wurde, angepaßt. Die daraus resultierende Folge kann überflüssige Datenredundanz, mit damit verbundenen Nachteilen für Speicherverbrauch und Datenkonsistenz sein. Die Normalisierung der Daten stellt ein Verfahren dar, in dem die Datenredundanz auf der Basis der funktionalen Abhängigkeiten stufenweise reduziert werden kann. Die funktionale Abhängigkeit gilt dann innerhalb einer Tabelle zwischen zwei Spalten (bzw. Spaltengruppen), wenn in jeder Tabellenreihe der Wert einer Spalte (Spaltengruppe) eindeutig durch den entsprechenden Wert der anderen Spalte (Spaltengruppe) festgelegt wird. Die funktionale Abhängigkeit wird durch einen Pfeil (A→B: »B ist funktional abhängig von A«) gekennzeichnet. Beispiel 1.1
In der Tabelle mitarbeiter der Beispieldatenbank gilt: m_nr → m_name
,
weil jeder Mitarbeitername eindeutig durch die entsprechende Mitarbeiternummer identifiziert werden kann. Eine zweite Art der Abhängigkeit, die auch eine Rolle bei den Normalformen spielt, ist die mehrwertige Abhängigkeit. Die mehrwertige Abhängigkeit besagt, daß auf Grund eines Spaltenwertes immer die entsprechende Menge von Werten anderer Spalten eindeutig festgelegt werden kann. Diese Art von Abhängigkeit zwischen Tabellenspalten wird durch einen Doppelpfeil »→→» gekennzeichnet. Beispiel 1.2
ISBN →→ Autoren
35
Einleitung
Das Attribut Autoren ist mehrwertig von dem ISBN-Code jedes Buches abhängig, weil wir auf Grund des Codes alle Autoren jedes Buches eindeutig festlegen können. Insgesamt existieren fünf Normalformen, von welchen wir die ersten vier erläutern werden. Die fünfte Normalform hat keine bzw. sehr geringe praktische Bedeutung. Jede Normalform ist in der nachfolgenden enthalten.
1.4.1
Allgemeine Hinweise zur Normalisierung
Der Prozeß der Normalisierung einer Datenbank sollte immer mit der ersten Normalform beginnen. Nachdem die Datenbank die erste Normalform erfüllt, sollten die Tabellen der Datenbank so zerlegt werden, daß sie die zweite Normalform erfüllen usw. Für die meisten Datenbanken genügt die Normalisierung bis einschließlich der dritten Normalform. Die vierte und insbesondere die fünfte Normalform finden in der Praxis selten Anwendung. Die im Zusammenhang mit der Normalisierung entscheidende Frage ist, wieviel Datenredundanz sinnvoll ist. Diese Frage kann nur für jede Datenbank separat beantwortet werden. Das wichtigste Kriterium für diese Entscheidung ist, ob die Datenbank wenigen oder vielen Änderungen unterworfen ist. Die Datenbanken, die wenigen oder keinen Änderungen unterworfen sind, können problemlos mehr Datenredundanz enthalten. Demgegenüber sollten die Datenbanken, die häufig geändert werden, möglichst wenig redundante Daten haben, weil das Ziel, die redundanten Daten konsistent zu halten, im allgemeinen nur mit hohem Aufwand zu erreichen ist.
1.4.2
Erste Normalform
Eine Tabelle befindet sich in der ersten Normalform, falls in jeder Reihe und für jede Spalte nur atomare Werte existieren. Wie aus dem vorherigen Abschnitt ersichtlich, beinhaltet das relationale Datenmodell an sich schon diese Eigenschaft. Die erste Normalform werden wir anhand eines Ausschnitts aus der Tabelle arbeiten der Beispieldatenbank darstellen: 10102 10102 ..........
p1 p3 ..........
....... ....... .......
Falls diese zwei Reihen folgendermaßen geschrieben würden: 10102 ..........
(p1,p3) ..........
........ ........
würde die Tabelle arbeiten nicht in der ersten Normalform sein. (Dies ist im relationalen Datenmodell nicht möglich.)
36
Datenbankdesign
1.4.3
Zweite Normalform
Eine Tabelle befindet sich in der zweiten Normalform, wenn sie keine funktionale Abhängigkeiten von Teilen des Schlüssels enthält. Mit anderen Worten, jede Spalte dieser Tabelle, die den Primärschlüssel nicht bildet, darf nur vom ganzen Primärschlüssel (und nicht nur von einem Teil dieses Schlüssels) funktional abhängig sein. Nehmen wir an, die Tabelle arbeiten der Beispieldatenbank enthielte folgende Spalten: m_nr
pr_nr
aufgabe
einst_dat
abt_nr
10102 10102 25348 18316 ..... .....
p1 p3 p2 p2 ... ...
Projektleiter Gruppenleiter Sachbearbeiter
1.Oct.1988 0:00 1.Jan.1989 0:00 15.Feb.1988 0:00 1.Jun.1989 0:00 .......... ..........
a3 a3 a3 a1 ... ...
.......... ..........
Den Primärschlüssel dieser Tabelle bildet die Kombination der Spalten m_nr und pr_nr. Die Spalte abt_nr ist nicht voll funktional vom kompletten Primärschlüssel, sondern schon von einem Teil (m_nr) abhängig. Deswegen befindet sich die oben abgebildete Tabelle nicht in der zweiten Normalform. (Die Tabelle arbeiten der Beispieldatenbank befindet sich in der zweiten Normalform.)
1.4.4
Dritte Normalform
Die dritte Normalform besagt, daß zwischen den Spalten einer Tabelle, die nicht den Primärschlüssel bilden, keine Abhängigkeiten existieren dürfen. Ausgegangen wird dabei immer von einer Tabelle, die sich bereits in der zweiten Normalform befindet. Nehmen wir an, die Tabelle mitarbeiter enthielte eine zusätzliche Spalte mit dem Namen der Abteilung: m_nr
m_name
m_vorname
abt_nr
abt_name
25348 10102 18316 29346 ..... .....
Keller Huber Müller Probst ........ ........
Hans Petra Gabriele Andreas ........ ........
a3 a3 a1 a2 ... ...
Freigabe Freigabe Beratung Diagnose ........ ........
Der Primärschlüssel dieser Tabelle ist die Spalte m_nr. Weil die Spalten abt_nr und abt_name voneinander abhängig sind, und keine von beiden Teil des Primärschlüssels ist, befindet sich die oben abgebildete Tabelle nicht in der dritten Normalform. (Die Tabelle mitarbeiter, genauso wie alle ande-
37
Einleitung
ren Tabellen der Beispieldatenbank, befindet sich in der dritten Normalform.) Datenbanken, die die dritte Normalform erfüllen, enthalten weitgehend nicht redundante Daten.
1.4.5
Vierte Normalform
Die vierte Normalform beseitigt die mehrwertigen Abhängigkeiten in den Tabellen einer Datenbank. Als praktisches Beispiel betrachten wir die Tabelle verkauf, mit welcher der Verkauf diverser Artikel in verschiedenen Läden abgewickelt wird. art_nr
laden_nr
farbe
art_1 art_1 art_2 art_2 art_2 art_2 art_3 .........
laden_1 laden_1 laden_1 laden_1 laden_2 laden_2 laden_2 ..........
schwarz weiß rot schwarz rot schwarz weiß ........
Die Tabelle verkauf erfüllt die dritte Normalform, weil der einzige Primärschlüssel die Kombination aller drei Spalten art_nr, laden_nr und farbe ist. Trotzdem sind die Datenwerte dieser Tabelle redundant. Der Grund für die Redundanz liegt darin, daß jeder Artikel sowohl in mehreren Läden verkauft wird als auch mehrere mögliche Farben hat. Der Artikel art_2 z.B. wird in zwei Läden verkauft: laden_1 und laden_2 und in zwei verschiedenen Farben schwarz und rot. Deswegen existieren in der Tabelle verkauf mehrwertige Abhängigkeiten, die mit der Trennung in zwei Tabellen beseitigt werden können.
1.4.6
Das E/R-Modell
Alle Daten einer relationalen Datenbank können theoretisch mit Hilfe einer einzigen Tabelle dargestellt werden. (Eine solche Tabelle wird universelle Tabelle genannt.) Der wichtigste Nachteil eines solchen Datenbankentwurfs ist die große Redundanz von Daten. Falls eine Datenbank z.B. alle Daten in bezug auf Mitarbeiter und Projekte einer Firma beinhaltet (wo z.B. jeder Mitarbeiter in verschiedenen Projekten arbeitet und jedes Projekt mehrere Mitarbeiter beschäftigt), wird die Speicherung dieser Daten in einer Tabelle dazu führen, daß die Tabelle sehr viele Reihen und Spalten hat. Diese Daten werden redundant sein, was im Falle einer Änderung erhebliche Probleme aufwerfen kann.
38
Datenbankdesign
Der Entwurf der relationalen Datenbanken mit Hilfe des E/R-Modells funktioniert so, daß die existierenden Datenredundanzen in den Tabellen entfernt werden, indem jede Tabelle mit redundanten Daten unterteilt wird, bis keine Datenredundanzen mehr existieren. Das Grundkonzept des E/R-Modells ist die Entität, d.h. ein Objekt der realen Welt. Jede Entität hat mehrere Attribute, die spezifische Eigenschaften dieser Entität darstellen. Abhängig von seinem Typ kann ein Attribut: 왘 einwertig (atomar) 왘 mehrwertig 왘 zusammengesetzt
sein. Ein Attribut ist einwertig, falls je ein Wert für die Darstellung jeder Instanz einer Entität benutzt wird. Der Familienname einer Person ist ein Beispiel eines einwertigen Attributs. (Die meisten Attribute sind einwertig.) Ein mehrwertiges Attribut kann einen oder mehrere Werte für die Darstellung der Instanzen einer Entität haben. Der Standort einer Firma ist z.B. ein mehrwertiges Attribut, weil jede Firma ein oder mehrere Standorte haben kann. Zusammengestellte Attribute sind Attribute, die aus mehreren (voneinander unabhängigen) Subattributen zusammengestellt sind. Das typische Beispiel eines zusammengesetzten Attributs ist die Adresse (einer Person oder einer Firma). Dieses Attribut ist aus mehreren einwertigen Attributen, wie PLZ, Stadt und Straße zusammengesetzt. Das folgende Beispiel zeigt die Entität PERSON, die mehrere Attribute hat, von welchen das Attribut Adresse zusammengesetzt und das Attribut Vornamen mehrwertig ist. (Alle anderen Attribute sind einwertig.) Beispiel 1.3
PERSON (Personal_nr, Familien_name, {Vornamen}, Alter, Adresse (PLZ, Strasse))
Jede Entität hat ein Attribut (oder eine Kombination mehrerer Attribute), desssen Werte eindeutig für alle Instanzen sind. Ein solches Attribut wird Schlüsselattribut genannt. (In Beispiel 1.3 ist das Attribut Personal_nr das Schlüsselattribut der Entität PERSON.) Das dritte Grundkonzept des E/R-Modells (neben Entität und Attribut) ist die Beziehung (relationship). Eine Beziehung existiert, falls eine Entität den Bezug auf eine oder mehrere Entitäten hat. (Im spezifischen Fall kann eine Entität auch eine Beziehung mit sich selbst haben.) Die Anzahl der an einer Beziehung teilnehmenden Entitäten spezifiziert den Rang der Beziehung. (Die Beziehung arbeitet zwischen den Entitäten MITARBEITER und PROJEKT (siehe Abbildung 1.1) hat z.B. den Rang 2, weil sie zwei Entitäten verbindet.)
39
Einleitung
Jede existierende Beziehung zwischen zwei Entitäten kann nur einen der drei folgenden (Beziehungs-)Typen haben: 1:1, 1:N und M:N. Die Entitäten ABTEILUNG und MITARBEITER haben z.B. den Beziehungstyp 1:N, falls in jeder Abteilung ein oder mehrere Mitarbeiter arbeiten und jeder Mitarbeiter nur einer einzigen Abteilung angehört. Eine Beziehung kann, genauso wie jede Entität auch Attribute haben (siehe die Beziehung arbeiten in Abbildung 1.1) Abbildung 1.1 zeigt ein Beispiel eines E/R-Diagramms. (Ein E/R-Diagramm ist die graphische Notation, die für die Beschreibung eines spezifischen Modells verwendet wird.) In der E/R-Notation wird jede Entität als Rechteck dargestellt, wobei der Entitätsname innerhalb des Rechtecks (gewöhnlich in Großbuchstaben) geschrieben wird. Attribute sind durch Ellipsen spezifiziert, und jedes Attribut ist durch eine gerade Linie mit der entsprechenden Entität (oder Beziehung) verbunden. Schließlich werden die Rauten für die Darstellung der Beziehungen verwendet und alle Entitäten, die zu einer Beziehung gehören, werden mit ihr durch gerade Linien verbunden. Der Beziehungstyp jeder Entität wird auf der Verbindungslinie notiert. Die E/R-Notation ist nicht standardisiert. Deswegen ist die in Abbildung 1.1 verwendete Notation nur eine von vielen existierenden E/R-Notationen. Abbildung 1.1: Beispiel eines E/RDiagramms
40
Die Datenbanksprache SQL
1.5
Die Datenbanksprache SQL
Der SQL Server unterstützt wie alle anderen relationalen DB-Systeme die Sprache SQL. SQL ist eine Datenbanksprache, die auf dem relationalen Datenmodell basiert. Der Name steht als Abkürzung für Structured Query Language, d.h. strukturierte Abfragesprache. Die Entstehungsgeschichte von SQL ist eng mit dem Projekt System R bei IBM verbunden. System R sollte beweisen, daß ein relationales Datenbankmanagementsystem allen praktischen Anforderungen gerecht werden kann. Ein derartiges System soll also sehr leistungsfähig sein und alle Funktionen beinhalten, die für die alltägliche praktische Anwendung notwendig sind. Die Entwicklung von System R erfolgte in drei Phasen. Das Ziel der ersten Phase – Phase Null – war die schnelle Implementierung eines Prototyps, der nur einen Teil der vorgesehenen Funktionen beinhalten sollte. Als Datenbanksprache wurde in dieser Phase SEQUEL gewählt. Für diese Sprache wurde ein Interpreter in PL/I geschrieben, der ihre Anweisungen ausführen konnte. Im weiteren Verlauf dieser Phase wurde der Name der Sprache in »SQL« geändert. Trotz dieser Änderung wird SQL heute noch häufig als Sequel (sprich: siekwel ) ausgesprochen. Die implementierte Untermenge der SQL-Sprache bot die Möglichkeit, sowohl die Datenbank abzufragen und zu modifizieren als auch dynamische Änderungen des Datenbankdesigns durchzuführen. Zusätzlich wurden Unterabfragen implementiert. Damit war es möglich, die Suche in mehreren Tabellen durchzuführen; das endgültige Ergebnis konnte nur aus einer Tabelle entnommen werden. In dieser Phase wurde System R als Einplatzsystem implementiert, d.h. die Abfragen mittels SQL konnten nur von einem Bildschirm aus gestartet werden. Die schwierigste Aufgabe in dieser Phase war die Arbeit an optimierenden Algorithmen. Das Ziel war, die Anzahl der Zugriffe auf Datenbanken bei Abfragen zu minimieren. Diese Phase dauerte zwei Jahre, von 1974 bis 1975, und hat in bezug auf SQL bewiesen, daß die Sprache in der Praxis einsetzbar war. Die zweite Phase von System R – Phase Eins – dauerte von 1976 bis Mitte 1977. Der Prototyp aus der ersten Phase wurde jedoch nicht weiterentwikkelt, sondern eine ganz neue Version von System R konstruiert. Diese Version beinhaltete alle schon erwähnten Funktionen und war ein Mehrplatzsystem. Die wichtigsten Komponenten der zweiten Phase in bezug auf SQL waren die Implementierung von Abfragen, die mehrere Tabellen verknüpfen, und das Subsystem für Datenschutz. Dieses Subsystem sicherte jedem Benutzer genau den Zugriff zu, der ihm vom Eigentümer des entsprechenden Objektes eingeräumt wurde.
41
Einleitung
Zusätzlich dazu wurde SQL in zwei höhere Programmiersprachen, – COBOL und PL/I, – eingebettet. Das Ziel war, jedem Programmierer dieselben Möglichkeiten zu geben, ungeachtet dessen, ob er interaktive Abfragen oder die COBOL- bzw. PL/I-Schnittstelle benutzt. Das erklärte Ziel der zweiten Phase war, System R für die IBM-Betriebssysteme VM/CMS und MVS/TSO lauffähig zu machen. In der dritten Phase, von Juni 1977 bis Ende 1979, wurde System R intern bei IBM und bei drei ausgewählten Kunden getestet. Die SQL-Benutzerschnittstelle von System R wurde generell als einfach und mächtig bewertet. Die Sprache war so strukturiert, daß die Anwender sie in relativ kurzer Zeit erlernen konnten. Im Jahre 1982 gründete das American National Standards Institute (ANSI) ein Gremium, das einen Standard für relationale Datenbanksprachen entwerfen sollte. Im Laufe der Zeit wurde zum größten Teil der SQL-Dialekt von IBM als Standard übernommen und im Oktober 1986 verabschiedet. Nach der Verabschiedung eines weiteren SQL-Standards im Jahre 1989 hat sich dasselbe Gremium dem Entwurf eines neuen Standards mit dem Namen SQL92 gewidmet. SQL92 wurde im Dezember 1992 offiziell verabschiedet. Der nächste Standard namens SQL99 wurde im Dezember 1999 verabschiedet. Dieser Standard enthält als wichtigste Erweiterungen objektorientierte Konzepte und Trigger .
1.6
Notation
Für die Darstellung der Syntax aller in diesem Buch definierten SQL-Anweisungen wird eine einfache formale Sprache benutzt, die nachfolgend definiert wird:
42
Schreibweise
Beschreibung
RESERVIERTES_WORT
Jedes reservierte Wort der SQL-Sprache wird in Großbuchstaben angegeben. (Beispiel: CREATE TABLE). Zusätzliche Erklärungen zu reservierten Wörtern können Sie in Kapitel 2 finden.
variable
Die Schreibweise mit Kleinbuchstaben bezeichnet eine Variable. Beispiel: CREATE TABLE tabelle (für »tabelle« muß ein aktueller Wert eingegeben werden).
{var_1|var_2}
Alternative Darstellung: Genau einer der Ausdrücke, der durch einen senkrechten Strich von den anderen getrennt ist, ist auszuwählen, z.B. {ALL|DISTINCT}.
var1|var2|var3
Auswahl: Einer oder mehrere Ausdrücke, die durch einen senkrechten Strich von den anderen getrennt sind, sind auszuwählen.
Zusammenfassung
Schreibweise
Beschreibung
[]
Eckige Klammern bezeichnen optionale Werte. Werte innerhalb der eckigen Klammern dürfen also weggelassen werden.
Voreinstellung
Unterstrichene Werte kennzeichnen die Voreinstellung. Dieser Wert wird also implizit angenommen, wenn explizit keine Alternative angegeben ist.
...
Wiederholungszeichen: Der unmittelbar vorhergehende Ausdruck darf mehrmals wiederholt werden (getrennt durch ein oder mehrere Leerzeichen).
{ } ...
Der Ausdruck, der innerhalb der geschweiften Klammern erscheint, darf mehrmals wiederholt werden (getrennt durch ein oder mehrere Leerzeichen).
Zusätzlich zur Notation werden alle Objekte der Beispieldatenbank im Text fettgedruckt dargestellt. Hinweise erscheinen neben
und grau unterlegt.
Die reservierten Wörter der SQL-Sprache werden in diesem Buch unterschiedlich bei der Syntaxbeschreibung und in den Beispielen dargestellt. In der Syntaxbeschreibung einer Anweisung werden alle reservierten Wörter, wie in der Notation angegeben, groß geschrieben. In den Beispielen werden alle Angaben (reservierte Wörter, Variablen usw.) klein geschrieben. Der Grund für diese Unterscheidung liegt darin, daß die SQL Server-Versionen Benutzertabellen -> Orders in dieser Reihenfolge ausgewählt und die Funktion Spalten in das Abfragefenster verschoben werden. Abbildung 2.15 zeigt den Anfangsteil einer SELECT-Anweisung, wo alle Spaltennamen mit Hilfe des obigen Verfahrens spezifiziert wurden.
66
Query Analyzer Abbildung 2.15: Die SELECTAnweisung mit allen Spalten der Tabelle Orders
Der Objektkatalog kann auch für die Ausgabe aller Reihen einer Tabelle verwendet werden. Um alle Reihen der Tabelle mitarbeiter der Beispieldatenbank auszugeben, müssen die Ordner beispiel und Benutzertabellen (in dieser Reihenfolge) geöffnet, die Tabelle mitarbeiter angeklickt und die Funktion Öffnen ausgewählt werden. Der Objektkatalog ermöglicht auch das Modifizieren bzw. das Löschen einzelner Datenbankobjekte. Für das Modifizieren klickt man (mit der rechten Maustaste) das Objekt an und wählt Bearbeiten. Der Objektkatalog gibt die ALTER-Anweisung für das gewählte Objekt im Abfragefenster aus. (Für die Beschreibung der ALTER-Anweisung, siehe Kapitel 4.) Falls ein Objekt gelöscht werden soll, muß die Funktion Löschen (anstatt Bearbeiten) ausgewählt werden. Die Funktionalität des Objektkatalogs unterscheidet sich während des Modifizierens und des Löschens eines Objektes. Die Auswahl der Funktion Löschen verursacht nicht die Erstellung der entsprechenden SQLAnweisung im Abfragefenster. In diesem Fall muß der Benutzer die Ausführung der Löschung bestätigen. 2.3.2.3
Objektsuche
Die Funktionalität der Objektsuche-Komponente ist ähnlich der Windows NT/2000-Komponente namens Explorer. Im Unterschied zum Explorer, der das Durchsuchen von Dateien und Dateiverzeichnissen ermöglicht, sucht die Objektsuche-Komponente nach den Objekten eines Datenbank-Servers.
67
SQL Server Enterprise Manager und Query Analyzer
Das Öffnen der Objektsuche-Komponente erfolgt durch das Anklicken der gleichnamigen Schaltfläche in der Systemleiste des Query Analyzers. (Alternativ kann die Taste F4 gedrückt oder die Funktion Objektsuche im ToolsMenü ausgewählt werden.) Das Suchen nach einem Datenbankobjekt erfolgt durch das Eintippen des Objektnamens im Feld Objektname, die Auswahl des Servers und der Datenbank (in der gleichnamigen Listen) und durch das Markieren eines oder mehrerer Objekttypen (siehe Abbildung 2.16). Die Liste der Ergebnisse kann durch die maximale Anzahl der ausgewählten Objekte eingeschränkt werden. Abbildung 2.16: Das Suchen nach allen Tabellen namens mitarbeiter
2.4
Zusammenfassung
Dieses Kapitel beschreibt zwei wichtige SQL Server-Komponenten, die sowohl für Endbenutzer als auch für den Systemadministrator wichtig sind. Die erste – SQL Server Enterprise Manager – unterstützt Benutzer bei diversen Aufgaben. Die wichtigsten Endbenutzeraufgaben mittels Enterprise Manager – die Erstellung von Datenbanken und Tabellen – sind in diesem Kapitel ausführlich beschrieben. (Die administrativen Aufgaben, die mit Enterprise Manager ausgeführt werden können, sind in diesem Kapitel nur erwähnt. Ihre Funktionalität wird im dritten Abschnitt dieses Buches erläutert.)
68
Zusammenfassung
Die zweite Komponente – SQL Server Query Analyzer – unterstützt die Endbenutzer bei der interaktiven Erstellung und Ausführung von TransactSQL-Anweisungen. Zusätzlich ermöglicht diese Komponente die Analyse des ausgewählten Ausführungsplans und die Erstellung der Vorschläge in bezug auf die Indizes für eine Abfrage. Aufgaben
A.2.1
Mit Hilfe des Enterprise Managers erstellen Sie eine Datenbank namens test. Diese Datenbank soll in der Datei testdate_a des Verzeichnisses C:\tmp gespeichert werden mit 10 MB zur Verfügung stehendem Speicherplatz. Falls Speicherplatz nicht vorhanden ist, soll die Datei jedesmal um 2 MB vergrößert werden bis zu einer Gesamtgröße von 20 MB.
A.2.2
Mit Hilfe des Enterprise Managers ändern Sie das Transaktionsprotokoll der test-Datenbank. Die Anfangsgröße soll 3 MB betragen mit einem Zuwachs von 20%. Die Datei soll unbeschränkt vergrößerbar sein.
A.2.3
Mit Hilfe des Enterprise Managers erlauben Sie die Benutzung der test-Datenbank nur dem Datenbankeigentümer (dbo) und dem Systemadministrator (sa). Können mehrere Benutzer die Datenbank gleichzeitig benutzen?
A.2.4
Mit Hilfe des Enterprise Managers erstellen Sie alle vier Tabellen der Beispieldatenbank. (Die aktuelle Datenbank ist die test-Datenbank.)
A.2.5
Mit Hilfe des Enterprise Managers sichten Sie alle Tabellen der Northwind-Datenbank. Danach wählen Sie die Tabelle orders aus und sichten Sie ihre Eigenschaften.
A.2.6
Mit Hilfe des Query Analyzers tippen Sie die folgende SQL-Anweisung ein: CREATE DATABASE test
und erläutern Sie die Fehlermeldung, die Sie bekommen. A.2.7
Speichern Sie die SQL-Anweisung (A.2.6) in der Datei C:\tmp\createdb.sql
A.2.8
Die test-Datenbank soll mit Hilfe des Query Analyzers die aktuelle Datenbank des Systems werden.
A.2.9
Ändern Sie mit Hilfe des Query Analyzers die Form der Ausgabe der Abfrage. Die Ergebnismenge soll in Textform ausgegeben werden.
69
II
Teil
Transact-SQL-Sprache
71
3
Grundkomponenten des SQL Servers
In diesem Kapitel werden Grundkomponenten des SQL Servers beschrieben. Zuerst werden die Grundelemente der Sprache, wie Literale, Namen und Begrenzer erörtert, im Anschluß daran die Datentypen definiert. Danach werden alle existierenden Operatoren und Funktionen beim SQL Server beschrieben. Am Ende des Kapitels werden die NULL-Werte erörtert.
3.1
Grundelemente der SQL-Sprache
Die SQL-Sprache des SQL-Servers heißt Transact-SQL und hat wie jede andere Programmiersprache folgende Grundelemente: 왘 Literale 왘 Begrenzer 왘 Namen (Identifikatoren) 왘 reservierte Wörter
3.1.1
Literale
Ein Literal ist eine alphanumerische, hexadezimale oder numerische Konstante. Eine alphanumerische Konstante (auch Zeichenkette genannt) beinhaltet ein oder mehrere Zeichen des SQL Server-Zeichensatzes, die zwischen zwei Apostrophen oder zwei Anführungszeichen stehen. Die hexadezimalen Konstanten dienen der Darstellung der nicht abdruckbaren Zeichen. Jede hexadezimale Konstante fängt mit dem Zeichenpaar »0x« an, gefolgt von einer geraden Anzahl von Buchstaben oder Ziffern. Beispiel 3.1
Es folgen Beispiele für alphanumerische und hexadezimale Konstanten: 왘 'Stuttgart' 왘 ''1000 Berlin 30'' 왘 '9876' 왘 'Apostroph wird mit '' dargestellt' 왘 0x53514C0D
73
Grundkomponenten des SQL Servers Beispiel 3.2
Bei folgenden Beispielen handelt es sich nicht um alphanumerische Konstanten: 왘 'AB'C'
ungerade Anzahl von Apostrophen
왘 'München''
das Apostroph und das Anführungszeichen können nicht gemischt werden.
Seit Version 6 haben Anführungszeichen beim SQL Server eine doppelte Bedeutung. Außer als Zeichenkettenbegrenzer können Anführungszeichen auch als Begrenzer für sogenannte begrenzte Bezeichner (delimited identifier) verwendet werden. Begrenzte Bezeichner sind eine spezielle Art von Bezeichnern, die gewöhnlich benutzt werden, um Schlüsselwörter zusätzlich als Bezeichner zu verwenden. Die Unterscheidung zwischen Apostrophen und Anführungszeichen als Begrenzer wurde im SQL92-Standard durchgeführt. Bei den Bezeichnern unterscheidet dieser Standard zwischen regulären (regular identifier) und begrenzten Bezeichnern. Der wichtigste Unterschied ist, daß begrenzte Bezeichner innerhalb Anführungszeichen geschrieben werden und zwischen Groß- und Kleinschreibung unterscheiden. Apostrophe werden als ausschließliche Zeichenkettenbegrenzer verwendet. Die Bedeutung der Anführungszeichen beim SQL Server wird mit Hilfe der QUOTED_IDENTIFIER-Option der SET-Anweisung festgelegt. Falls diese Option auf ON gesetzt ist, wird ein Bezeichner innerhalb der Anführungszeichen als begrenzter Bezeichner identifiziert. In diesem Fall dürfen Anführungszeichen nicht als Zeichenkettenbegrenzer benutzt werden. Standardmäßig ist diese Option nicht auf ON gesetzt, d.h. Anführungszeichen werden standardmäßig als eine Alternative zu den Apostrophen als Zeichenkettenbegrenzer betrachtet. Die praktische Verwendung der begrenzten Bezeichner wird in Kapitel 4 gegeben (siehe Beispiel 4.28). Zu numerischen Konstanten gehören alle Ganz-, Festpunkt- und Gleitpunktzahlen mit oder ohne Vorzeichen. Beispiel 3.3
Es folgen Beispiele für numerische Konstanten: 왘 130 왘 -130.00 왘 -0.357E5 왘 22.3E-3
Ein Literal besitzt immer einen Datentyp und eine Länge, die beide vom Format des Literals abhängig sind. Zusätzlich besitzt jede numerische Konstante eine Genauigkeits- und Skalierungsangabe. (Die Datentypen unterschiedlicher Literalarten werden später in diesem Kapitel beschrieben.)
74
Grundelemente der SQL-Sprache
3.1.2
Begrenzer
Mit Hilfe der Begrenzer werden die lexikalischen Einheiten (token) einer Programmiersprache voneinander getrennt. Kommentare und alphanumerische Konstanten stellen auch Begrenzer dar. Transact-SQL kennt folgende Begrenzer: ,
(
)
.
:
=
+
–
*
/
=
Ein Kommentar kann auf verschiedene Weise in einer Transact-SQL-Anweisung dargestellt werden. Die Zeichenpaare »/*« und »*/« definieren den dazwischen befindlichen Text, der sich auch auf mehrere Zeilen erstrecken kann, als Kommentar. Genauso wird das Zeichenpaar »--« als Kommentar erkannt. Dabei wird dieses Zeichenpaar, zusammen mit dem Rest der Zeile, als Kommentar betrachtet. (Das Zeichenpaar »--« entspricht dem ANSISQL-Standard, während »/*« und »*/« die spezifische Erweiterung der Transact-SQL-Sprache ist.)
3.1.3
Namen
Namen (Identifikatoren) in der Transact-SQL-Sprache werden für die Identifizierung einzelner Objekte, wie Datenbanken, Tabellen, Indizes usw. verwendet. Sie sind durch Zeichenketten dargestellt, die bis zu 128 alphanumerische Zeichen enthalten können. Jeder Name muß mit einem Buchstaben oder mit einem der folgenden Zeichen: »_«, »#«, und »@« beginnen. Das Zeichen »#« am Anfang eines Tabellennamens kennzeichnet eine temporäre Tabelle, während »@« am Anfang eines Namens eine lokale Variable kennzeichnet.
3.1.4
Reservierte Wörter
Jede Programmiersprache hat eine Menge von Wörtern, die eine gewisse vorgegebene Bedeutung haben, und die in der jeweils vorgegebenen Form geschrieben werden müssen. Solche Wörter heißen reservierte Wörter. In der Transact-SQL-Sprache gibt es eine Vielzahl solcher Wörter, die wie in den meisten anderen Programmiersprachen als Objektnamen nicht benutzt werden dürfen. Die Liste aller reservierten Wörter kann in den entsprechenden Handbücherndes SQL Server-Systems gefunden werden. Die Namen aller Datentypen und Systemfunktionen wie char, int usw. stellen bei der Transact-SQL-Sprache keine reservierten Wörter dar. Deswegen kann man sie auch als Namen von Objekten benutzen.
75
Grundkomponenten des SQL Servers
3.2
Datentypen
Alle Datenwerte einer Spalte müssen denselben Datentyp haben. Die Transact-SQL-Sprache kennt mehrere Datentypen, die in folgende Klassen unterteilt werden können: 왘 numerische Datentypen, 왘 alphanumerische Datentypen, 왘 Datentypen für Datums- und/oder Zeitangaben und 왘 abgeleitete Datentypen.
Alle diese Datentypen werden in den folgenden Abschnitten beschrieben.
3.2.1
Numerische Datentypen
Numerische Datentypen ermöglichen die Darstellung von Zahlen. TransactSQL enthält folgende numerische Datentypen:
76
Datentyp
Beschreibung
int
Beschreibt ganzzahlige numerische Werte, die in vier Byte gespeichert werden können. int ist die verkürzte Schreibweise für integer.
smallint
Beschreibt ganzzahlige numerische Werte, die in zwei Byte gespeichert werden können und deswegen zwischen -32768 und 32767 liegen.
tinyint
Beschreibt ganzzahlige, positive numerische Werte, die in einem Byte gespeichert werden können. (tinyint-Werte liegen zwischen 0 und 255).
bigint
Beschreibt ganzzahlige numerische Werte, die in acht Byte gespeichert werden können und deswegen zwischen -263 und 263 -1 liegen.
decimal(p,[q])
Beschreibt Festpunktzahlen. Die Angabe p kennzeichnet die Anzahl aller Ziffern und q die Anzahl der Ziffern hinter dem Dezimalkomma. (decimal-Werte werden, abhängig von der Angabe p, in 2 bis einschließlich 17 Byte gespeichert. Die Angabe dec ist das Kürzel für decimal.)
numeric(p,[q])
Synonym für decimal.
real
Beschreibt Gleitkommazahlen. Der Wertebereich der positiven real-Zahlen liegt etwa zwischen 2.23E-308 und 1.79E+308, während sich der Wertebereich der negativen Zahlen zwischen -2.23E-308 und -1.79E+308 befindet.
float[(p)]
Beschreibt Gleitkommazahlen wie den Datentyp float. Die Angabe p spezifiziert die Genauigkeit, wobei für p=25 die doppelte Genauigkeit (8 Byte) verwendet wird.
Datentypen
Datentyp
Beschreibung
money
Wird für die Darstellung von Geldbeträgen verwendet. Die money-Werte entsprechen den decimal-Werten, die in acht Byte gespeichert und auf vier Stellen hinter dem Komma aufgerundet sind.
smallmoney
Entspricht dem money-Datentyp, wird aber in 4 Byte gespeichert.
3.2.2
Alphanumerische Datentypen
Der alphanumerische Datentyp ermöglicht die Darstellung von Zeichenketten, wobei alle alphanumerischen Zeichen innerhalb der Zeichenkette auftreten können. Die alphanumerischen Datentypen sind: Datentyp
Beschreibung
char[(n)]
Beschreibt eine Zeichenkette, wobei n die Anzahl der Zeichen innerhalb der Zeichenkette angibt. Der Wert von n kann maximal 8000 betragen. character(n) ist eine zusätzliche, äquivalente Schreibweise für char(n). Falls n ausgelassen wird, beträgt die Länge der Zeichenkette 1.
varchar[(n)]
Beschreibt eine Zeichenkette variabler Länge (0 @alte_summe * 1.5 begin print 'Die Änderung der Projektmittel nicht ausgeführt' rollback transaction end else print 'Die Änderung der Projektmittel ausgeführt' end
In Beispiel 13.2 wurde eine Regel erstellt, die Änderungen der Projektmittel in bezug auf die Gesamtsumme aller Mittel überprüft. Der Trigger tr_gesamt_mittel überprüft bei jeder Änderung der Projektmittel, ob die Gesamtsumme der Mittel um mehr als 50% erhöht wurde. Nur solche Änderungen an Projektmitteln, bei denen die Gesamtsumme um weniger als 50% erhöht wird, werden zugelassen. Im anderen Fall wird die UPDATE-Anweisung mit Hilfe der ROLLBACK TRANSACTION-Anweisung zurückgesetzt. (Die ROLLBACK-Anweisung wird im nächsten Abschnitt beschrieben.) Ein weiteres Anwendungsgebiet für Trigger stellt die referentielle Integrität dar. Diese wichtige Integritätsregel, die in Kapitel 4 beschrieben wurde, kann entweder deklarativ oder mit Hilfe von Triggern spezifiziert werden . Folgendes Beispiel zeigt die Implementierung der referentiellen Integrität.
325
Die prozedurale Datenintegrität Beispiel 13.3
create trigger tr_refint_arb on arbeiten for insert, update as if update(m_nr) begin if (select mitarbeiter.m_nr from mitarbeiter, inserted where mitarbeiter.m_nr = inserted.m_nr) is null begin print 'Die Reihe könnte nicht eingefügt/geändert werden' rollback transaction end else print 'Die Reihe wurde eingefügt/geändert' end
In Beispiel 13.3 werden die Änderungen der Werte des Fremdschlüssels m_nr der Tabelle arbeiten in Bezug auf die existierenden Werte des gleichnamigen Primärschlüssels der Tabelle mitarbeiter überprüft und jede Verletzung der Datenintegrität bei der UPDATE-Anweisung zurückgewiesen. Jede Änderung eines Datenwertes der Spalte m_nr der Tabelle arbeiten, die mit Hilfe der INSERT- bzw. UPDATE-Anweisung ausgeführt wird, wird in bezug auf die existierenden Werte in der gleichnamigen Spalte der Tabelle mitarbeiter überprüft. Wird ein Wert in der Spalte m_nr der Tabelle arbeiten eingefügt bzw. geändert, zu dem kein entsprechender Wert in der gleichnamigen Spalte der Tabelle mitarbeiter existiert, wird die ausgeführte INSERTbzw. UPDATE-Anweisung mit Hilfe der ROLLBACK TRANSACTION-Anweisung zurückgesetzt. Anderenfalls wird eine Bestätigungsmeldung am Bildschirm ausgegeben. Die in Beispiel 13.3 definierte Integritätsregel überprüft die beiden ersten Fälle für den Primärschlüssel der Tabelle mitarbeiter und den entsprechenden Fremdschlüssel der Tabelle arbeiten (siehe Abschnitt »Referentielle Integrität« in Kapitel 4). Die Verletzungen der referentiellen Integrität, die durch die Fälle (3) und (4) für die Tabellen mitarbeiter und arbeiten ausgelöst werden können, können mit dem in Beispiel 13.4 definierten Trigger überprüft und zurückgesetzt werden. Beispiel 13.4
create trigger tr_refint_arb2 on mitarbeiter for delete, update as if update(m_nr) begin if (select count(*) from arbeiten, deleted where arbeiten.m_nr = deleted.m_nr) > 0
326
Trigger
begin rollback transaction print 'Die Reihe könnte nicht gelöscht/geändert werden' end else print 'Die Reihe wurde gelöscht/geändert' end
Die Überprüfung der referentiellen Integrität bezüglich der übrigen existierenden Beziehungen zwischen Primär- und den entsprechenden Fremdschlüsseln in der Beispieldatenbank kann analog den Beispielen 13.3 und 13.4 programmiert werden.
13.2.2
Anwendungsgebiete für INSTEAD OF-Option
Ein Trigger mit der INSTEAD OF-Option spezifiziert eine Anweisungsfolge, die als Ersatz für den existierenden Ausführungsteil des Triggers aktiviert wird. Der Ausführungszeitpunkt dieser Anweisungsfolge erfolgt unmittelbar nachdem die beiden Tabellen (INSERTED und DELETED) erstellt werden. Ein Trigger mit der INSTEAD OF-Option kann sowohl für Tabellen als auch für Views definiert werden. Falls eine Transact-SQL-Anweisung ein View mit einer INSTEAD OF-Option referenziert, wird vom System der Trigger aktiviert, ohne daß irgendeine andere Aktion ausgeführt wird. Für eine Spalte, deren Werte mit einer INSTEAD OF-Option zugewiesen werden, gelten folgende Bedingungen: 왘 die Spalte darf nicht vom Typ TIMESTAMP sein 왘 die Spalte darf nicht berechnet sein 왘 die Spalte darf nicht die IDENTITY-Eigenschaft besitzen (es sei denn, die
Option IDENTITY_INSERT ist aktiviert). Das folgende Beispiel zeigt das unterschiedliche Verhalten beim Einfügen der Werte für eine berechnete Spalte mit Hilfe einer Tabelle bzw. des entsprechenden Views. Beispiel 13.5
create table bestellung (bestell_nr int not null, preis money not null, menge int not null, bestell_datum datetime not null, gesamt_preis as preis * menge, liefer_datum as dateadd (day, 7, orderdate)) go create view alle_bestellungen as select bestell_nr, preis, menge, bestell_datum, gesamt_preis,
327
Die prozedurale Datenintegrität
liefer_datum from bestellungen go create trigger tr_bestellung on alle_bestellungen instead of insert as begin insert into bestellung select bestell_nr, preis, menge, bestell_datum from inserted end
Eine INSERT-Anweisung muß explizit den Wert für eine View-Spalte enthalten, falls diese Spalte einer berechneten Spalte der Basistabelle entspricht. Das kann umgangen werden, falls ein Trigger mit der INSTEAD OF-Option verwendet wird (siehe das obige Beispiel).
13.2.3
Ausführungsreihenfolge von multiplen Triggern
Der SQL Server erlaubt die Erstellung von multiplen Triggern für jede Tabelle bzw. jedes View und jede Aktion (INSERT, UPDATE und DELETE). (Views können nur mit Triggern mit der INSTEAD OF-Option verwendet werden.) Zusätzlich dazu kann die Ausführungsreihenfolge der multiplen Trigger festgelegt werden. Mit Hilfe der sp_settriggerorder-Systemprozedur ist es möglich einen der multiplen Trigger als ersten (first) oder letzten (last) in der Ausführungsreihenfolge zu definieren. Diese Systemprozedur hat einen Parameter namens @option, der drei Werte enthalten kann: 왘 first 왘 last 왘 none
Der Wert first spezifiziert, daß der Trigger als erster ausgeführt wird. Der Wert last legt fest, daß der Trigger als letzter in der Ausführungsreihenfolge aktiviert wird, während none besagt, daß keine festgelegte Reihenfolge für die Ausführung von multiplen Triggern existiert. Beispiel 13.6 zeigt die Verwendung der sp_settriggerorder-Systemprozedur. Beispiel 13.6
sp_settriggerorder @triggername = 'tr_mittel_protokoll', @order = 'first', @stmttype = 'update'
Die Reihenfolge der multiplen Trigger kann mit Hilfe der: 왘 sp_helptrigger-Systemprozedur 왘 objectproperty-Funktion
spezifiziert werden.
328
Zusammenfassung
Die Systemprozedur sp_helptrigger enthält den Parameter order, der die Ausführungsreihenfolge multipler Trigger ausgibt. Mit Hilfe der objectproperty-Funktion kann eine der beiden Eigenschaften ExecIsFirstTrigger und ExecIsLastTrigger als zweiter Parameter spezifiziert werden. (Der erste Parameter dieser Funktion ist immer der Name des Datenbankobjektes, in diesem Fall der Name des Triggers.) Die Ausführungsreihenfolge kann nicht für einen Trigger mit der INSTEAD OF-Option spezifiziert werden, weil der Trigger mit einer solchen Option immer vor der Änderung der Basistabellendaten aktiviert wird.
13.2.4
Änderung der Trigger-Struktur
Der SQL Server 2000 unterstützt eine weitere Transact-SQL-Anweisung bezüglich Trigger – ALTER TRIGGER. Die ALTER TRIGGER-Anweisung wird gewöhnlich verwendet, um den Ausführungsteil eines Triggers zu ändern. Alle Klauseln und Optionen der ALTER TRIGGER-Anweisung entsprechen den gleichnamigen Klauseln und Optionen der CREATE TRIGGER-Anweisung. Mit der Anweisung DROP TRIGGER trigger_name wird ein existierender Trigger gelöscht.
13.3 Zusammenfassung Die Eigenschaft des SQL Servers ist, viele unterschiedliche Möglichkeiten für die Erstellung der Integritätsregeln zu unterstützen. Für die Definition der Integritätsregeln stehen drei Möglichkeiten zur Verfügung: 왘 die deklarative Form, 왘 Trigger und 왘 die Definition der Wertebereiche.
Die deklarative Form der Integritätsregeln wird mit Hilfe der Datendefinitionsanweisungen CREATE TABLE und ALTER TABLE definiert und entspricht dem SQL-Standard. Trigger sind Mechanismen des Datenbank-Servers, bei denen eine Anweisungsfolge ausgeführt wird, falls die dazu definierte Bedingung erfüllt ist. Wertebereiche sind benutzerdefinierte Datentypen, die Spalten einer Tabelle genauer definieren, als dies mit den Standarddatentypen möglich ist. Aufgaben
A.13.1
Definieren Sie mit Hilfe von Triggern die referentielle Integrität für den Primärschlüssel der Tabelle abteilung (abt_nr) und des gleichnamigen Fremdschlüssels der Tabelle mitarbeiter.
329
Die prozedurale Datenintegrität
A.13.2
330
Definieren Sie mit Hilfe von Triggern die referentielle Integrität für den Primärschlüssel der Tabelle projekt (pr_nr) und des gleichnamigen Fremdschlüssels der Tabelle arbeiten.
14
Transaktionen
In diesem Kapitel werden zwei verwandte Begriffe – konkurrierender Datenzugriff und Transaktionen – behandelt. Zuerst werden die Definition der Transaktion gegeben und die Transact-SQL-Anweisungen, die in bezug zu Transaktionen stehen, erläutert. Danach werden das Sperren der Datenbankobjekte und die Isolierungsstufen behandelt, womit der konkurrierende Zugriff mehrerer Benutzer auf die Daten einer Datenbank gewährleistet bzw. beeinflußt wird.
14.1 Einführung Eine Datenbank wird in der Regel von mehreren Anwendern gleichzeitig benutzt. Dieser Umstand wirft eine Reihe von Problemen auf, die alle mit völliger Korrektheit abgehandelt werden müssen. Der konkurrierende Datenzugriff mehrerer Benutzer muß bei jedem Datenbankmanagementsystem gewährleistet sein. Ein weiteres Problem, mit dem ein Datenbankmanagementsystem konfrontiert ist, sind Fehler, die sowohl in der Software als auch in der Hardware auftreten können. Ein Datenbankmanagementsystem sollte in der Lage sein, nach denkbaren Ausfällen die betroffenen Datenbanken in den letzten konsistenten Zustand zu überführen. Sowohl der konkurrierende Datenzugriff mehrerer Benutzer als auch die Erhaltung der Konsistenz der Datenbanken nach einem Hardware- oder Softwareausfall wird mit Hilfe der Transaktionen gewährleistet. Eine Transaktion kennzeichnet mehrere nacheinander folgende, logisch zusammenhängende Anweisungen. An folgendem Beispiel wird dieser Begriff praktisch erläutert. In der Beispieldatenbank soll der Mitarbeiter namens Huber eine neue Personalnummer bekommen. (Der Grund dafür könnte die Änderung des Arbeitsstandortes o.ä. sein.) Die neue Personalnummer soll 39831 sein. Die Änderung der Personalnummer muß gleichzeitig in zwei Tabellen durchgeführt werden: Eine Reihe der Tabelle mitarbeiter muß geändert werden sowie alle Reihen der Tabelle arbeiten, die Daten des Mitarbeiters Huber enthalten. Falls nur eine der beiden Tabellen geändert würde (z.B. die Tabelle mitarbeiter), wäre die Beispieldatenbank inkonsistent, weil der Primär- und Fremdschlüssel von Herrn Huber nicht mehr zueinander passen würden.
331
Transaktionen Beispiel 14.1
begin transaction /* Anfang der Transaktion */ update mitarbeiter set m_nr = 39831 where m_nr = 10102 if (@@error 0) rollback transaction /* Zurücksetzen der Transaktion */ update arbeiten set m_nr = 39831 where m_nr = 10102 if (@@error 0) rollback transaction commit transaction /* Erfolgreiches Ende der Transaktion*/
Die Konsistenz der Beispieldatenbank kann nur erhalten bleiben, wenn die UPDATE-Anweisungen in Beispiel 14.1 entweder vollständig durchgeführt oder – im Falle eines Fehlers während der Transaktion – rückgängig gemacht werden. In Beispiel 14.1 wird die Systemvariable @@error nach jeder UPDATE-Anweisung überprüft, um festzustellen, ob die Anweisung erfolgreich ausgeführt wurde. Falls ein Fehler bzw. eine Warnung angezeigt wird (@@error 0) wird die Ausführung der Anweisung(en) zurückgesetzt. (Für die Beschreibung der ROLLBACK TRANSACTION-Anweisung siehe den nächsten Abschnitt.) Der in Beispiel 14.1 dargestellte Fall stellt gleichzeitig auch eine Verletzung der referentiellen Integrität dar. Deswegen wird dieser Fall in der Praxis gewöhnlich mit Hilfe der deklarativen Integritätsregeln behandelt, die dann die Ausführung der beiden UPDATE-Anweisungen (oder keiner) garantieren.
14.2 Transact-SQL-Anweisungen in bezug auf Transaktionen Der SQL Server kennt mehrere Transact-SQL-Anweisungen: 왘 BEGIN TRANSACTION 왘 BEGIN DISTRIBUTED TRANSACTION 왘 COMMIT TRANSACTION 왘 ROLLBACK TRANSACTION 왘 SAVE TRANSACTION 왘 SAVE IMPLICIT_TRANSACTION
die im Zusammenhang mit den Transaktionen stehen.
332
Transact-SQL-Anweisungen in bezug auf Transaktionen
Mit der Anweisung BEGIN TRANSACTION [transaktions_name] [WITH MARK ['marke']]
wird eine Transaktion gestartet. transaktions_name ist der Name der Transaktion, der nur innerhalb des äußersten BEGIN....COMMIT-Paares (bzw. BEGIN...ROLLBACK-Paares) verwendet werden kann. Die WITH MARK-Option spezifiziert, daß die Transaktion innerhalb des Transaktionsprotokolls markiert werden soll. marke ist eine Zeichenkette, die die Markierung beschreibt. Die WITH MARK-Option wird für die Herstellung einer Datenbank verwendet (siehe auch Kapitel 20). Die BEGIN DISTRIBUTED TRANSACTION-Anweisung spezifiziert den Anfang einer verteilten Transaktion, die vom MS Distributed Transaction Coordinator (MS DTC) verwaltet wird. Eine verteilte Transaktion umfaßt die gleichzeitige Datenänderung an mehreren Servern. (Für die Beschreibung der verteilten Transaktionen siehe Kapitel 25.) Mit der Anweisung COMMIT TRANSACTION [transaktions_name]
wird eine Transaktion beendet, und alle ursprünglichen Datenwerte, die innerhalb der Transaktion geändert wurden, werden in das Transaktionsprotokoll geschrieben. Mit der Anweisung ROLLBACK TRANSACTION [transaktions_name]
werden alle schon ausgeführten Anweisungen innerhalb einer Transaktion rückgängig gemacht. Diese Anweisung wird entweder vom System implizit durchgeführt oder muß explizit vom Programmierer im Programm (wie in Beispiel 14.1) angegeben werden. Der Programmierer verwendet die Anweisung ROLLBACK TRANSACTION, wenn er nicht sicher ist, ob alle Änderungen an der Datenbank korrekt ausgeführt wurden. Die Anweisung SAVE TRANSACTION transaktions_name
erstellt eine Marke für eine TRANSACT-SQL-Anweisung innerhalb einer Transaktion. Eine anschließende ROLLBACK TRANSACTION-Anweisung mit demselben Transaktionsnamen setzt alle Anweisungen zwischen der SAVE- und ROLLBACK TRANSACTION-Anweisung zurück. Die SAVE TRANSACTION-Anweisung veranlaßt nicht, daß die Datenänderungen in das Tansaktionsprotokoll geschrieben werden. Diese Anweisung zeigt lediglich eine Marke auf, die mit einer anschließenden ROLLBACK-Anweisung mit der gleichnamigen Marke als Bereich definiert wird, wo alle Anweisungen zurückgesetzt werden (siehe das folgende Beispiel).
333
Transaktionen Beispiel 14.2
begin transaction insert into abteilung (abt_nr, abt_name) values ('a4', 'Vertrieb') save transaction a insert into abteilung (abt_nr, abt_name) values ('a5', 'Verwaltung') save transaction b insert into abteilung (abt_nr, abt_name) values ('a6', 'Marketing') rollback transaction b insert into abteilung (abt_nr, abt_name) values ('a7', 'Support') rollback transaction a commit transaction
Die einzige Anweisung, die in der Transaktion des Beispiels 14.2 ausgeführt wird, ist die erste INSERT-Anweisung. Die INSERT-Anweisung mit der Abteilungsnummer a6 wird durch die ROLLBACK TRANSACTION b und die zwei übrigen INSERT-Anweisungen durch die ROLLBACK TRANSACTION a zurückgesetzt. Die SAVE TRANSACTION-Anweisung stellt ein nützliches Konstrukt dar, um die Ausführung verschiedener Teile einer Transaktion, mit Hilfe der if- bzw. while-Anweisung zu ermöglichen. Andererseits widerspricht ihre Verwendung dem Prinzip, daß eine Transaktion so kurz wie möglich sein soll. Jede Transact-SQL-Anweisung befindet sich immer innerhalb einer Transaktion, entweder implizit oder explizit. Die explizite Transaktion kennzeichnet alle Anweisungen zwischen der BEGIN TRANSACTION und der COMMIT (bzw. ROLLBACK) TRANSACTION. Andererseits wird jede Anweisung implizit als eine einzelne Transaktion behandelt, falls keine expliziten Transaktionen angegeben sind. Implizite Transaktionen entsprechen der Definition von Transaktionen im SQL-Standard. Im impliziten Modus wird jede Anweisung für sich als eine Transaktion betrachtet. Das bedeutet., daß die BEGIN TRANSACTION-Anweisung vor jeder Anweisung implizit ausgeführt wird. (Diese Aussage gilt nur für die wichtigsten Transact-SQL-Anweisungen: Die Liste dieser Anweisungen ist unten gegeben.) Falls mehrere Anweisungen als Teil einer impliziten Transaktion betrachtet werden sollen, muß die COMMIT-Anweisung (bzw. die ROLLBACK-Anweisung) verwendet werden. Jede COMMIT- (ROLLBACK-)Anweisung beendet die vorherige und startet die neue Transaktion. Das Aktivieren des impliziten Transaktionsmodus für die aktuelle Sitzung wird durch das Setzen der SET IMPLICIT_TRANSACTIONS-Anweisung
334
Transact-SQL-Anweisungen in bezug auf Transaktionen
auf ON erreicht. Das Ausführen folgender Transact-SQL-Anweisungen startet eine Transaktion im impliziten Modus: ALTER TABLE
FETCH
REVOKE
CREATE
GRANT
SELECT
DELETE
INSERT
TRUNCATE TABLE
DROP
OPEN
UPDATE
Der SQL Server erlaubt die Verwendung von geschachtelten Transaktionen. Jedes Anweisungspaar BEGIN/COMMIT bzw. BEGIN/ROLLBACK kann innerhalb eines oder mehrerer solcher Paare geschrieben werden. Die praktische Anwendung der geschachtelten Transaktionen liegt darin, daß die Datenbankprozeduren, die Anweisungen bezüglich einer Transaktion enthalten, selbst innerhalb einer Transaktion aufgerufen werden können. Die Systemvariable @@trancount enthält die augenblickliche Schachtelungstiefe innerhalb der geschachtelten Transaktionen. Die Anweisungen BEGIN TRANSACTION, COMMIT TRANSACTION und ROLLBACK TRANSACTION können mit einem optionalen Namen angegeben werden. (Eine ROLLBACK TRANSACTION-Anweisung mit Namen kann entweder einer genannten Transaktion oder einer gleichnamigen SAVE TRANSACTION-Anweisung entsprechen.) Ein Name soll im Falle einer verschachtelten Transaktion nur für die äußerste Transaktion verwendet werden.
14.2.1
Speicherung von Transaktionen
Um innerhalb einer Transaktion entscheiden zu können, ob die Transaktion ausgeführt oder zurückgesetzt werden soll, ist es notwendig, alle geänderten Reihen in deren ursprünglichen Form zu protokollieren. Für die Speicherung dieser Werte wird beim SQL Server (genau wie bei allen anderen Datenbankmanagementsystemen) das Transaktionsprotokoll verwendet. Jede Datenbank eines SQL Server-Systems hat ein eigenes Transaktionsprotokoll. Damit enthält ein Transaktionsprotokoll sämtliche Informationen über abgeschlossene und nicht abgeschlossene Transaktionen einer Datenbank. Die Datenbank selbst und ihr Transaktionsprotokoll sollten auf zwei unterschiedliche Platten gespeichert werden. Es gibt zwei Gründe, warum diese Empfehlung grundsätzlich für (fast) alle Datenbanken gilt: 왘 wegen der Wiederherstellung der Datenbank 왘 wegen der Performance.
Für die Datenbankwiederherstellung ist das Transaktionsprotokoll unbedingt notwendig, weil dort alle Änderungen bezüglich der Datenbank protokolliert sind. Bei einem Plattenfehler gehen sowohl Daten selbst, als auch die notwendige Information, wie die Daten restauriert werden sollen, verloren.
335
Transaktionen
Die Performance-Einbußen entstehen dadurch, daß sowohl das Schreiben im Transaktionsprotokoll als auch die Änderung der Datenbank u.U. nicht parallel ausgeführt werden können, wenn sich beide auf einer Platte befinden. Seit Version 7 werden Transaktionsprotokolle, genauso wie Datenbanken, in den Dateien gespeichert. (Bei den früheren SQL Server-Versionen enthielt die Systemtabelle syslogs das entsprechende Transaktionsprotokoll.) Weitere Einzelheiten über die Verwendung der Transaktionsprotokolle in bezug auf die Wiederherstellung finden Sie in Kapitel 20.
14.3 Sperren Ein Datenbankmanagementsystem muß beim Mehrbenutzerbetrieb Mechanismen enthalten, die allen Benutzern zur selben Zeit den Zugriff auf Daten einer Datenbank ermöglichen. Beim SQL Server, wie bei den meisten anderen Datenbankmanagementsystemen wird dies mit Hilfe von Sperren erreicht. Das Sperrverfahren dient dem Zweck, einem Benutzer die Möglichkeit zu geben, eine oder mehrere Reihen exklusiv zu bearbeiten, ohne daß die anderen Benutzer diese Reihe in der Zwischenzeit in unvorgesehener Weise benutzen bzw. ändern können.
14.3.1
Objekte sperren
Objekte einer Datenbank können beim SQL Server sowohl implizit als auch explizit gesperrt werden. Der SQL Server kann vier verschiedene Objekte sperren: 왘 eine Reihe 왘 eine physikalische Seite 왘 eine Tabelle 왘 einen Index 왘 ein extent 왘 eine Datenbank.
Eine Reihe ist das kleinste Datenbankobjekt, das gesperrt werden kann. Mit Hilfe von Reihensperren können sowohl die Daten- als auch Indexreihen gesperrt werden. Die physikalische Seite ist das Objekt, das beim SQL Server in den meisten Fällen gesperrt wird. Die Seitensperre sperrt die physikalische Seite, in der sich die Reihe befindet, die gesperrt werden soll. Eine Seitensperre kann
336
Sperren
vom System implizit in eine Tabellensperre befördert werden. Dies geschieht, falls die Anzahl der gespeicherten Seiten einen maximalen Wert überschreitet. (Dieser Vorgang wird lock escalation genannt.) Ein extent (siehe Kapitel 15) kann auch gesperrt werden. Die Sperren für extents werden automatisch gesetzt, falls eine Tabelle (oder ein Index) wächst und deswegen mehr Speicherplatz braucht. Die Entscheidung, welches Objekt beim SQL Server gesperrt werden soll, hängt von mehreren Faktoren ab. Bei einer Seitensperre wird einerseits die Verfügbarkeit anderer Reihen der Tabelle, die sich auf derselben Seite befinden, eingeschränkt, andererseits wird die Anzahl der Sperren gering gehalten. Bei einer Reihensperre wird die Verfügbarkeit der Reihen für die anderen Benutzer erhöht, gleichzeitig aber auch die Anzahl der notwendigen Sperren. Grundsätzlich gilt, daß eine Seitensperre Vorteile gegenüber einer Reihensperre aufweist, wenn die Abarbeitungsreihenfolge der physikalischen Folge der Reihen entspricht. Dadurch werden gleichzeitig mehrere bearbeitete Reihen mit einer einzigen Sperre gesperrt.
14.3.2
Typen von Sperren
Das SQL Server-System benutzt unterschiedliche Typen von Sperren, abhängig davon, ob es sich um Reihen-, Seiten- oder Tabellensperren handelt. Bei den Reihen- und Seitensperren existieren insgesamt drei unterschiedliche Sperrarten: 왘 Share (S-Sperre), 왘 eXclusive (X-Sperre) und 왘 Update (U-Sperre).
Wenn ein Benutzer ein Objekt mit einer S-Sperre belegt, dürfen alle anderen Benutzer nur lesend auf dieses Objekt zugreifen. Alle Abfragen, die dieses Objekt betreffen, sind dann erlaubt. Demgegenüber wird jeder Versuch, das Objekt zu ändern, in den Wartezustand versetzt. Ein Objekt kann mehrere SSperren haben. Die X-Sperre stellt eine wesentlich restriktivere Art des Sperrens dar. Wenn ein Benutzer ein Objekt mit der X-Sperre belegt, werden alle Versuche anderer Benutzer, auf dieses Objekt schreibend oder lesend zuzugreifen, in den Wartezustand versetzt. Die U-Sperre entspricht der S-Sperrre, solange das Sperrobjekt nicht modifiziert wird. Nach der Änderung des Objektes und dem Aufheben der entsprechenden Sperre wird die U-Sperre in die X-Sperre befördert. Ein Objekt kann nur eine U-Sperre haben. Die U-Sperre kann für ein Objekt erworben werden, falls es schon eine oder mehrere S-Sperren hat. Diese Sperre kann aber nicht in eine X-Sperre beför-
337
Transaktionen
dert werden, solange ein anderer Prozeß die Sperre für das Objekt hält. Die U-Sperre wird für jede Reihe verwendet, die in einer FOR UPDATE-Klausel im Zusammenhang mit dem Cursor angewendet wird. Seitensperren erlauben auch die Verwendung von intent-Sperren, die später in diesem Abschnitt beschrieben sind. Die Kompatibilitätsmatrix dieser drei Sperren wird in Tabelle 14.1 dargestellt. Tabelle 14.1: Die Kompatibilitätsmatrix der Reihenund Seitensperren
S
U
X
S
j
j
n
U
j
n
n
X
n
n
n
Die Kompatibilitätsmatrix in Tabelle 14.1 kann folgendermaßen interpretiert werden: Nehmen wir an, daß die Transaktion T1 eine Sperre hält, wie in einer der Reihen der Matrix spezifiziert wurde. Genauso hält eine andere Transaktion T2 eine Sperre, wie in einer der Spalten der Matrix festgelegt ist. Ein »j« besagt, daß die Sperre der Transaktion T2 möglich ist, während »n« einen Sperrkonflikt darstellt. Bei den Tabellensperren gibt es insgesamt fünf unterschiedliche Sperren: 왘 Share (S-Sperre) 왘 eXclusive (X-Sperre) 왘 Intent Share (IS-Sperre) 왘 Intent eXclusive (IX-Sperre) 왘 Share with Intent eXclusive (SIX-Sperre)
Die ersten beiden Sperren entsprechen den schon beschriebenen gleichnamigen Seitensperren. Bei der IS-Sperre stellt ein Prozeß lediglich fest, ob eine SSperre möglich wäre, ohne die Sperre tatsächlich zu setzen. Genauso stellt ein Prozeß bei der IX-Sperre fest, ob eine X-Sperre möglich wäre. Die Kompatibilitätsmatrix der Tabellensperren ist in Tabelle 14.2 dargestellt. Tabelle 14.2: Die Kompatibilitätsmatrix der Tabellensperren
338
IS
IX
SIX
S
X
IS
j
n
n
j
n
IX
j
j
n
n
n
SIX
j
n
n
n
n
S
j
n
n
j
n
X
n
n
n
n
n
Sperren
Der SQL Server unterstützt die Konfigurationsoption namens locks, die die Anzahl der Sperren des jeweiligen Systems spezifiziert. Der Standardwert 0 bedeutet, daß der SQL Server zwei Prozent des Gesamtspeichers für die Speicherung von Sperren benutzt. (Mit Hilfe der Systemprozedur sp_configure kann diese Option geändert werden.) Die wichtigste Systemprozedur bezüglich Sperren ist sp_lock. Diese Prozedur kann die Information über die Prozesse, die Sperren halten, am Bildschirm ausgegeben. Die Syntax von sp_lock sieht folgendermaßen aus: sp_lock [spid]
spid ist die ID-Nummer des SQL Server-Prozesses. Falls die ID-Nummer nicht angegeben wird, werden Infomationen zu allen aktiven Prozessen angezeigt. Beispiel 14.3
Nehmen wir an, daß folgende Transact-SQL-Anweisung für die Beispieldatenbank ausgeführt wird: set showplan_text on go begin transaction update mitarbeiter set m_name = 'Lang' where m_nr = 28559
Tabelle 14.3 stellt die Ausgabe der Systemprozedur sp_lock dar, falls für die Tabelle mitarbeiter ein CLUSTERED-Index für die Spalte m_nr existiert. Spid
Dbid
ObjId
Type
6
8
0
6
8
0
6
8
117575457
PAG
6
8
117575457
TAB
Resource
Mode
Status
DB
S
GRANT
DB
S
GRANT
IX
GRANT
IX
GRANT
1:291
Tabelle 14.3: Das Ergebnis der Anweisung aus dem Beispiel 14.3
spid und dbid spezifizieren die ID-Nummern der Tabelle und der Datenbank. Die Spalte type definiert das Sperrobjekt (PAG = Seitensperre, DB 0 = Datenbanksperre, TAB = Tabellensperre). Die wichtigste Spalte der Systemprozedur sp_lock ist mode. Diese Spalte spezifiziert den Sperrtyp. (In Beispiel 14.3 existiert eine S-Sperre für die ganze Datenbank, und jeweils eine IX-Sperre für die Seite mit der Nummer 1:291 und die Tabelle mitarbeiter.)
339
Transaktionen
14.3.3
Die SELECT-Anweisung und Sperren
In der FROM-Klausel der SELECT-Anweisung ist es möglich, die Verwendung der Seiten- und Tabellensperren explizit zu beeinflussen. Folgende Angaben sind möglich: 왘 UPDLOCK 왘 TABLOCK 왘 TABLOCKX 왘 PAGLOCK 왘 ROWLOCK
Es existieren weitere Angaben, die aber die Isolierungsstufen betreffen. Diese Angaben werden im nächsten Abschnitt beschrieben. Die Angabe UPDLOCK bedeutet, daß während der ganzen Transaktion für jede gelesene Tabellenreihe eine S-Sperre in eine U-Sperre geändert wird. TABLOCK setzt eine S-Sperre für die ganze Tabelle (anstelle der einzelnen S-Seitensperren) während der Anweisungsausführung. (Die Kombination aus TABLOCK und HOLDLOCK verlängert die Wirkung der Tabellensperre bis zum Transaktionsende.) TABLOCKX entspricht der Angabe TABLOCK, bis auf die Verwendung einer X-Sperre statt S-Sperre. Die PAGLOCK-Angabe ersetzt die S-Tabellensperre durch S-Sperren für jede physikalische Seite dieser Tabelle. Dementsprechend ersetzt die ROWLOCK-Angabe die S-Tabellensperre durch S-Sperren für jede angesprochene Tabellenreihe. Die Verwendung der o.g. Angaben ist in beliebigen Kombinationen möglich, es sei denn, die Kombination ergibt keinen Sinn (wie z.B. die Kombination aus TABLOCK und PAGLOCK).
14.3.4
Isolierungsstufen
Isolierungsstufen stellen auf verschiedenen Ebenen dar, wie sicher ein Benutzer sein kann, daß die von ihm gelesenen Reihen aktuellen Inhalt haben. (Sie stehen damit immer im Zusammenhang mit den Leseoperationen bzw. S-Sperren.) Der SQL Server unterstützt alle vier Isolierungsstufen, die im SQL-Standard beschrieben sind: 왘 READ UNCOMMITTED 왘 READ COMMITTED 왘 REPEATABLE READ 왘 SERIALIZABLE
340
Sperren
READ UNCOMMITTED kennzeichnet die niedrigste Isolierungsstufe; dabei wird keine Sperre vom Prozeß gesetzt. Vor dem Lesen der Reihe wird auch nicht geprüft, ob irgendeine Sperre auf dieser Reihe schon existiert. Die Daten, die bei der READ UNCOMMITTED-Stufe gelesen werden, können verfälscht sein. Dies tritt in dem Fall auf, wenn eine Reihe gelesen wird, die zuvor von einem anderen Prozeß geändert und anschließend mit der Anweisung ROLLBACK zurückgesetzt wurde. Diese Isolierungsstufe kann nützlich sein, wenn die Genauigkeit aller gelesenen Daten nicht die höchste Priorität hat bzw. wenn sich die Daten einer Tabelle nie ändern. Bei READ COMMITTED wird vom System festgestellt, ob eine S-Sperre möglich ist. Bei dieser Isolierungsstufe setzt das System keine Sperre; vielmehr wird überprüft, ob eine solche Sperre gesetzt werden kann. COMMITTED READ gerantiert einem Benutzer, daß die von ihm gelesene Reihe im Augenblick des Lesens nicht verfälscht ist. Nachdem die Reihe gelesen wurde, ist es durchaus möglich, daß ein anderer Prozeß diese Reihe ändert. Diese Isolierungsstufe kann z.B. bei der Erstellung der wöchentlichen oder monatlichen Berichte verwendet werden. Im Unterschied zu READ COMMITTED wird bei REPEATABLE READ für die gerade gelesene Reihe eine S-Sperre gesetzt. Während des Lesens der Reihe, wird diese Sperre gehalten. Bei der Isolierungsstufe SERIALIZABLE werden S-Sperren auf alle Reihen gesetzt, die zum Ergebnis einer Abfrage gehören. Diese Sperren werden so lange gehalten, bis die Transaktion, zu der die Abfrage gehört, beendet wird. Bei dieser höchsten Isolierungsstufe kann der Benutzer sicher sein, daß alle von ihm abgefragten Reihen nicht geändert werden, bis die Transaktion beendet ist. Die Isolierungsstufe SERIALIZABLE ist beim SQL Server mit Hilfe der Sperre für den Bereichsschlüssel (key-range lock) implementiert. Diese Methode sperrt einzelne Reihen und zusätzlich den ganzen Bereich zwischen ihnen. Die Eigenschaft der Sperren für den Bereichsschlüssel ist, daß sie Index- anstatt Datenseiten sperren. Die Konsequenz ist, daß Änderungsoperationen anderer Transaktionen nicht ausgeführt werden können, weil alle Änderungen der Indexseiten unmöglich sind. Jede strengere Isolierungsstufe schränkt im Vergleich zur vorherigen die Verfügbarkeit der Tabellenreihen für die anderen Benutzer ein. Andererseits kann es bei der vorherigen Stufen eher vorkommen, daß die gelesenen Reihen unmittelbar nach dem Lesen von einem anderen Benutzer geändert werden und damit eine anschließende Leseoperation unterschiedliche Datenwerte liefert. Der SQL Server hat standardmäßig die Isolierungsstufe READ COMMITTED.
341
Transaktionen
Isolierungsstufen eines SQL Server-Systems können explizit mit Hilfe: 왘 der TRANSACTION ISOLATION LEVEL-Angabe der SET-Anweisung 왘 verschiedener Angaben in der FROM-Klausel der SELECT-Anweisung
für die Dauer einer SQL Server-Sitzung geändert werden. Die TRANSACTION ISOLATION LEVEL-Angabe der SET-Anweisung kennt insgesamt vier Optionen, die mit den vier Isolierungsstufen gleichnamig sind. Jede Option setzt die entsprechende Isolierungsstufe für die Dauer der Sitzung fest. Die FROM-Klausel der SELECT-Anweisung kennt insgesamt sechs unterschiedliche Angaben, die im Zusammenhang mit den Isolierungsstufen stehen: 왘 READUNCOMMITTED 왘 READCOMMITTED 왘 REPEATABLEREAD 왘 SERIALIZABLE 왘 NOLOCK 왘 HOLDLOCK
Die ersten vier Angaben entsprechen den vier oben beschriebenen gleichnamigen Isolierungsstufen. NOLOCK und HOLDLOCK sind Synonyme für READUNCOMMITTED und REPEATABLEREAD (in dieser Reihenfolge). Das Setzen der Angaben in der FROM-Klausel der SELECT-Anweisung hat Vorrang vor der Verwendung der Optionen in der SET-Anweisung. Die Option USEROPTIONS der DBCC-Anweisung zeigt die aktuelle Isolierungsstufe eines Prozesses. (Das DBCC-Kommando wird in Kapitel 23 ausführlich beschrieben.)
14.4 Gegenseitige Blockierung (Deadlock) Deadlock stellt eine spezielle Situation dar, in der eine Abhängigkeit zwischen zwei (oder mehreren) Prozessen im Zusammenhang mit Sperren existiert. Der erste Prozeß hält eine Sperre für das Objekt, auf das der zweite Prozeß zugreifen will. Gleichzeitig versucht der erste Prozeß ein Objekt zu benutzen, das vom zweiten gesperrt wurde. Beispiel 14.4 zeigt eine Situation wo die gegeseitige Blockierung zweier Prozesse auftritt.
342
Zusammenfassung Beispiel 14.4
/* Beide Prozesse müssen gleichzeitig gestartet werden */ begin transaction update arbeiten set aufgabe = 'Chef' where m_nr = 18316 and pr_nr = 'p2' waitfor delay "00:00:05" update mitarbeiter set m_name = 'Meier-Kunz' where m_nr = 9031 commit transaction
begin transaction update mitarbeiter set abt_nr = 'a2' where m_nr = 9031 waitfor delay "00:00:05" delete from arbeiten where m_nr = 18316 and pr_nr = 'p2' commit transaction
Falls die beiden in Beispiel 14.4 dargestellten Transaktionen parallel ausgeführt werden, tritt eine Deadlock-Situation auf. Weil die Parallelität der Prozesse und damit die Reproduzierung einer gegenseitigen Blockierung mit einer kleinen Datenbank wie beispiel sehr schwierig zu erreichen ist, haben wir aus Lehrzwecken in beiden Transaktionen des Beispiels 14.4 die WAITFOR-Anweisung verwendet, die eine Pause von 5 Sekunden zwischen der Ausführung der beiden Anweisungen in der jeweiligen Transaktion vorsieht. Das SQL Server-System erkennt eine Deadlock-Situation und bricht den Prozeß, der die geringste Prozessorzeit verbraucht hat, mit der Fehlermeldungsnummer 1205 ab. (Das Abbrechen eines Prozesses bedeutet, daß seine aktuelle Transaktion zurückgesetzt wird.) Da dies ein kontrollierbarer Abbruch ist, kann der Programmierer solche gegenseitige Blockierungen in seinem Programm sehr gut berücksichtigen und entsprechend behandeln, z.B. durch einen erneuten Versuch der abgewiesenen Transaktion.
14.5 Zusammenfassung Transaktionen ermöglichen nicht nur den konkurrierenden Datenzugriff mehrerer Benutzer, sondern sie bilden auch die Basis für die Wiederherstellung von Datenbanken, die durch Fehler verschiedenen Ursprungs inkonsistent geworden sind. Die Wiederherstellung von Datenbanken wird in Kapitel 21 erläutert. Aufgaben
A.14.1
Wozu werden die Transaktionen verwendet?
A.14.2
Was ist der Unterschied zwischen lokalen und verteilten Transaktionen?
343
Transaktionen
344
A.14.3
Was ist der Unterschied zwischen impliziten und expliziten Transaktionen?
A.14.4
Welche Sperrarten sind mit einer exklusiven Sperre kompatibel?
A.14.5
Wie kann die erfolgreiche bzw. fehlerhafte Ausführung einer SQLAnweisung getestet werden?
A.14.6
Wann wird die SAVE TRANSACTION-Anweisung in der Praxis verwendet?
A.14.7
Welche Vorteile hat eine Reihensperre im Vergleich zu einer entsprechenden Seitensperre und umgekehrt?
A.14.8
Kann ein Benutzer das Sperrverhalten des Systems explizit beeinflussen?
A.14.9
Was ist der Unterschied zwischen der S- und X-Sperre einerseits und der U-Sperre andererseits?
A.14.10
Was bedeutet lock escalation?
A.14.11
Was ist der Unterschied zwischen den Isolierungsstufen READ UNCOMMITTED und SERIALIZABLE?
A.14.12
Was bedeutet die gegenseitige Blockierung? Welcher Prozeß wird bei der gegenseitigen Blockierung vom System beendet?
15
Systemumgebung
In diesem Kapitel werden mehrere Themen behandelt, die alle im Zusammenhang mit der Umgebung des SQL Server-Systems stehen. Zuerst wird eine ausführliche Beschreibung der Elemente für Datenspeicherung beim SQL Server gegeben. Danach werden Systemdatenbanken und Dienstprogramme, die der Benutzer bei der Bewältigung wichtiger Aufgaben benötigt, erörtert. Die Verwendung von Unicode und die damit verbundene Unterstützung von nationalen Sprachen (z.B. Deutsch) werden anschließend gezeigt. Am Ende des Kapitels werden die unterschiedlichen Arten der Systemarchitektur, die der SQL Server unterstützt, beschrieben.
15.1 Speicherung von Daten Die Datenspeicherung beim SQL Server basiert auf zwei physikalischen Einheiten: 왘 physikalische Seite 왘 extent
Die wichtigste Einheit für die Datenspeicherung beim SQL Server ist die physikalische Seite. Eine physikalische Seite weist eine feste Größe von 8 KB auf. (Die Größe der physikalischen Seiten bei den SQL Server-Versionen < 7 beträgt 2 KB.) Jede Seite hat einen Anfangsbereich von 96 Bytes, der für die Speicherung der Systeminformation benutzt wird. Daten werden unmittelbar nach dem Anfangsbereich gespeichert. Eine wichtige Eigenschaft vom SQL Server ist, daß Daten einer Reihe nicht auf zwei oder mehrere physikalischen Seiten verteilt werden können. Deswegen beträgt die maximale Größe einer einzigen Reihen (außer Reihen mit text/image-Daten) 8060 Bytes. Der SQL Server hat sechs unterschiedliche Typen von physikalischen Seiten: 왘 Datenseite 왘 Indexseite 왘 text/image-Seite 왘 leere (reservierte) Seiten 왘 globale Seiten bezüglich extent-Allokierung (global allocation map pages) 왘 Seiten bezüglich Tabellen- und Index-extents (index allocation map pages).
Bei der Erstellung einer Tabelle oder eines Index wird vom SQL Server zuerst ein fester Speicherbereich zur Verfügung gestellt. Falls der zur Verfügung stehende Speicherbereich für die Daten nicht ausreicht, wird vom Sy-
345
Systemumgebung
stem zusätzlicher Speicher zugewiesen. Die physikalische Einheit, die vom System in so einem Fall zugewiesen wird, heißt extent. Ein extent umfaßt acht nebeneinander liegende physikalische Seiten. Der SQL Server unterscheidet zwischen zwei Arten von extents: 왘 einheitliche extents 왘 mixed-extents
Ein einheitliches extent wird ausschließlich für die Speicherung der Werte einer Tabelle (bzw. eines Index) benutzt, während ein mixed-extent Daten von maximal acht Tabellen (oder Indizes) aufnehmen kann. Der SQL Server weist zuerst für eine neue Tabelle physikalische Seiten eines mixed-extents zu. Falls Daten der Tabelle (des Index) mehr als 64 KB umfassen, werden der Tabelle (dem Index) einheitliche extents zugewiesen.
15.2 Systemdatenbanken Bei der Installation eines SQL Server-Systems werden automatisch vier Systemdatenbanken installiert: 왘 die master-Datenbank, 왘 die Modelldatenbank, 왘 die temporäre Datenbank und 왘 die msdb-Datenbank.
Die master-Datenbank ist die wichtigste Datenbank eines SQL Server-Systems. Diese Datenbank enthält diejenigen Sytemtabellen, die die ganze Information über den SQL Server selbst und alle seinen Datenbanken umfaßt. Die master-Datenbank enthält z.B. die Information über alle vom System verwalteten Datenbanken, Systemverbindungen zu den existierenden Clients und Benutzerberechtigungen. Die Modelldatenbank enthält diejenigen Systemtabellen, die jede Benutzerdatenbank benötigt. Damit stellt diese Datenbank eine Standardschablone dar, die bei der Erstellung jeder Benutzerdatenbank verwendet wird. Der Systemadministrator hat die Möglichkeit, die Modelldatenbank zu ändern und sie damit seinen Vorstellungen anzupassen. Die temporäre Datenbank (tempdb) bietet den Speicherplatz für alle temporären Tabellen bzw. Ausdrücke. Falls eine SELECT-Anweisung z.B. die ORDER BY-Klausel enthält, wird dadurch die Sortierung der Reihenmenge des Ergebnisses verursacht und in der temporären Datenbank durchgeführt. Die Standardgröße der temporären Datenbank beträgt 2 MB. Sie kann vom Systemadministrator geändert werden.
346
Dienstprogramme
Die msdb-Datenbank steht in enger Beziehung zu der SQL Server AgentKomponente. Sie enthält die ganze Information über diejenigen Aufgaben des Systemadministrators, die automatisch ausgeführt werden können. (Für die ausführliche Beschreibung der msdb-Datenbank und der SQL Server Agent-Komponente siehe Kapitel 22.) Der SQL Server unterstützt eine weitere Systemdatenbank – distributionDatenbank. Diese Datenbank wird auf dem Verteilungsserver installiert, falls die Daten repliziert werden. (Für die Beschreibung der Datenreplikation im allgemeinen und des Verteilungsservers im speziellen siehe Kapitel 25.)
15.3 Dienstprogramme Dienstprogramme sind fester Bestandteil des SQL Server-Systems. Sie unterstützen die Benutzer bei den immer wiederkehrenden Aufgaben wie die Archivierung und Wiederherstellung von Daten usw. Für alle SQL ServerDienstprogramme gilt gemeinsam, daß sie: 왘 als Kommando des entsprechenden Betriebssysstems aufgerufen werden 왘 im allgemeinen eine große Anzahl von möglichen Parametern haben.
In diesem Abschnitt werden die wichtigsten Dienstprogramme des SQL Servers beschrieben. Dies sind: 왘 osql 왘 odbcping 왘 isql 왘 bcp 왘 console.
15.3.1
osql
Aus der Benutzersicht ist osql eines der wichtigsten Dienstprogramme des SQL Server-Systems, weil mit ihm die Erstellung und die Ausführung der interaktiven SQL-Anweisungen möglich ist. Dieses Dienstprogramm ist eine Client-Komponente des SQL Servers, das ODBC als Schnittstelle für die Kommunikation mit dem Datenbank-Server benutzt. Die allgemeine Syntaxform von osql ist: osql [{-schalter [parameter]} ...] ,
wobei schalter ein Zeichen mit spezifischer Bedeutung und parameter den Variablennamen des entsprechenden Schalters darstellt. (Zwischen schalter und parameter können kein, ein oder mehrere Leerzeichen geschrieben werden.)
347
Systemumgebung
osql hat eine große Anzahl von Schaltern, von denen die wichtigsten in der Tabelle 15.1 dargestellt sind: Tabelle 15.1: osql-Schalter
348
Schalter
Beschreibung
-S server_name
spezifiziert den Namen des SQL Servers, zu dem die Verbindung aufgebaut wird. Falls dieser Schalter ausgelassen wird, wird der mit der Umgebungsvariablen OSQLSERVER gesetzte Servername übernommen.
-U ben_name
spezifiziert den Benutzernamen. Der Name muß davor mit der Systemprozedur sp_addlogin erstellt werden. Falls dieser Schalter ausgelassen wird, wird der Wert der Umgebungsvariablen OSQLUSER genommen.
-P kennwort
spezifiziert das Kennwort des mit dem Schalter »-U« genannten Benutzers. Falls dieser Schalter ausgelassen wird, fordert osql nachträglich die Eingabe des Kennwortes vom Benutzer. Hat der Benutzer (noch) kein Kennwort (z.B. der Benutzer sa unmittelbar nach der Installation des Systems, bleibt die Angabe kennwort leer (NULL)).
-c endezeichen
erlaubt dem Benutzer das Endekommando zu ändern. Die Voreinstellung ist »go«. (Dieser Schalter kann für jene Benutzer besonders nützlich sein, die sich an das Endezeichen »;« gewöhnt haben, das bei den anderen Datenbanksystemen üblich ist.)
-i eingabe_dat
spezifiziert den Namen der Datei, in der sich die TransactSQL-Anweisungsfolge befindet. Die Datei muß das Endekommando (Standardwert: »go«) (ggf. mehrfach) enthalten. Diese Angabe ist mit der Angabe < eingabe_dat identisch.
-o ausgabe_dat
spezifiziert den Namen der Datei, in der die Ausgabe der Transact-SQL-Anweisungsfolge gespeichert wird. Diese Angabe ist mit der Angabe > ausgabe_dat identisch.
-E
Verwendet die vertraute Verbindung (siehe Kapitel 12), anstatt das Kennwort anzufordern.
-e
Jede Eingabe wird wiedergegeben.
-D option|quelle
Erstellt die Verbindung zu einer ODBC-Datenquelle. Die Verbindung kann mit Hilfe eines ODBC-Treibers (option) oder mit Hilfe der Datenquelle (quelle) spezifiziert werden.
-L
Zeigt die Liste aller SQL Server-Instanzen, die im Netzwerk existieren. (SQL Server-Instanzen sind später in diesem Kapitel beschrieben.)
Dienstprogramme
Nach dem Aufruf des osql-Dienstprogrammes erscheint der interne SQL Server-Editor. Dieser Editor ist zeichenorientiert und nicht so benutzerfreundlich wie die meisten Bildschirmeditoren. Auf der Editorebene ist es möglich, weitere Parameter anzugeben (siehe Tabelle 15.2). Parameter
Beschreibung
go
Spezifiziert das Endekommando einer Anweisungsfolge. Danach wird die Aweisungsfolge, die sich im Puffer befindet, ausgeführt.
ed
ruft den Editor im Windows NT/2000-Betriebssystem auf.
reset
Löscht den Pufferinhalt.
!! kommando
führt das Betriebssystemkommando namens kommando aus.
quit bzw. exit()
Beendet das osql-Dienstprogramm.
STRG+C
Bricht eine Abfrage ab, ohne osql zu beenden.
Tabelle 15.2: osql-Parameter auf der Editorebene
Beispiel 15.1
osql -Sinf_ente -Upetra -ib0401.sql -ob0401.out -c";"
In Beispiel 15.1 wird der SQL Server namens inf_ente vom Benutzer petra aufgerufen. Die Transact-SQL-Anweisungsfolge, die ausgeführt wird, befindet sich in der Datei b0401.sql und die Ausgabe wird in der Datei b0401.out gespeichert. In der Datei b0401.sql muß das Endekommando »;« in einer separaten Zeile geschrieben werden. (Weil der Schalter »-P« nicht angegeben ist, wird die Angabe des Kennwortes für den Benutzer petra nachträglich vom System verlangt.)
15.3.2
odbcping
Das Dienstprogramm odbcping testet die Verbindung vom Client zum SQL Server-System. Zusätzlich dazu wird auch die Integrität der ODBC-Datenquelle getestet. Die Syntax des entsprechenden Kommandos ist: odbcping [?] | [{ -S server | -D datenquelle} [-U login] [-P password]]
Die Optionen -S, -U und -P haben dieselbe Bedeutung wie die gleichnamigen Optionen des osql-Dienstprogramms. -D spezifiziert den Namen der Datenquelle. Seit SQL Server 2000 wird dieses Dienstprogramm nicht zusammen mit dem Datenbanksystem installiert. Falls odbcping gebraucht wird, muß es von CD-ROM auf die Platte kopiert werden.
349
Systemumgebung
15.3.3
isql
Das isql-Dienstprogramm ist eine weitere interaktive Client-Komponente vom SQL Server, die der osql-Komponente sehr ähnlich ist. Der einzige Unterschied zwischen diesen beiden Komponenten ist, daß isql für die Kommunikation mit dem Datenbank-Server DB-Library (anstatt ODBC) verwendet.
15.3.4
bcp
bcp ist ein sehr nützliches Dienstprogramm, mit dem ein Benutzer die gewünschte Tabelle in einer Datei entladen bzw. aus einer Datei laden kann. Zusätzlich dazu kann das Format des Ladens, bzw. Entladens nach den benutzerspezifischen Normen gewählt werden. Weil das Laden bzw. das Entladen von Daten in den meisten Fällen die Aufgabe des Systemadministrators ist, wird dieses Dienstprogramm in Kapitel 22 beschrieben.
15.3.5
console
console wird vom Systemadministrator verwendet, um die Archivierung bzw. Wiederherstellung von Datenbanken durchzuführen. Die Syntax dieses Kommandos ist: console [-Sserver_name] [-Ppipe_name]
Der Schalter -S definiert den SQL Server, mit dem die Verbindung aufgebaut werden soll. -P kennzeichnet den Namen der Pipe, mit der der SQL Server gestartet wird. (Dieses Dienstprogramm verwendet standardmäßig die Named Pipes.) console führt den Systemadministrator beim Aktivieren und Deaktivieren einzelner Magnetbänder bzw. Disketten, die entweder die Information für die Wiederherstellung der Datenbanken enthalten oder auf denen die zu archivierende Datenbank gespeichert werden soll. Dieses Dientsprogramm muß bei der Diskettensicherung vor einer DUMP- bzw. LOAD-Anweisung ausgeführt werden.
15.4 Instanzen des SQL Server-Systems Der SQL Server 2000 unterstützt zum ersten Mal die mehrfachen Instanzen eines SQL Server-Systems. Eine Instanz ist ein Datenbank-Server, der eigene System- und Benutzerdatenbanken verwaltet sowie unabhängige Dienste (SQLServer und SQLServerAgent) hat. Der SQL Server 2000 unterstützt zwei Instanzarten: 왘 Standardinstanz 왘 benannte Instanz
350
Instanzen des SQL Server-Systems
Eine Standardinstanz (default instance) entspricht dem Datenbank-Server, so wie die früheren SQL Server-Versionen ihn kennen. Der Name des Rechners, auf dem diese Instanz läuft, spezifiziert gleichzeitig den Namen der Standardinstanz. Jede Installation von SQL Server 7.0 bzw. 6.5, die zusammen mit SQL Server 2000 auf einem Rechner läuft, wird als Standardinstanz betrachtet. Jede weitere installierte Instanz vom SQL Server 2000 wird als benannte Instanz betrachtet. Um eine solche Instanz eindeutig zu identifizieren, müssen ihr Name und der Name des Rechners, auf dem sie läuft, spezifiziert werden: zum Beispiel NTB11901\INSTANZ1. Obwohl die meisten Systemressourcen (wie die SQLServer- und SQLServerAgent-Dienste, sowie System- und Benutzerdatenbanken) zwischen unterschiedlichen Instanzen nicht geteilt werden, existieren einige Systemkomponenten, die von allen zusammen verwendet werden. Dies sind: 왘 die SQL Server-Programmgruppe 왘 der Analysis Server 왘 Systembibliotheken für Programmentwicklung.
Die Existenz einer einzigen SQL Server-Programmgruppe bedeutet, daß nur eine Kopie jeder Systemkomponente wie der Enterprise Manager und Query Analyzer existiert. Deswegen arbeiten solche Komponenten mit allen Instanzen, die auf einem Rechner installiert sind. Die Verwendung von multiplen Instanzen setzt voraus, daß der Rechner, auf dem sie installiert sind, entsprechende Ressourcen hat. Aus diesem Grund sollte ihre Verwendung im voraus geplant und genau überlegt werden. Folgende Gründe sprechen für die Installation multipler Instanzen: 왘 auf einem Rechner sollten unterschiedliche Typen von Datenbanken ver-
wendet werden 왘 der verwendete Rechner ist kein Einprozessor-System.
Das Hauptgebiet für die Verwendung von multiplen Instanzen ist die Notwendigkeit, existierende Datenbanken in verschiedene Gruppen zu unterteilen. Falls ein Datenbanksystem z.B. unterschiedliche Arten von Datenbanken (Produktions-, Test- und Demonstrationsdatenbanken) verwaltet, kann es sinnvoll sein, diese unter mehreren Instanzen laufen zu lassen. Auf diese Art können eine oder mehrere Produktionsdatenbanken vom Zugriff nichterfahrener Benutzer geschützt werden. Ein Einprozessor-Rechner wird in der Regel nicht genügend Ressourcen haben, um multiple Instanzen des SQL Server-Systems zu beherbergen. Aus diesem Grund soll ein Multiprozessor- oder ein Cluster-Rechner als Hardwareplattform für multiple Instanzen verwendet werden.
351
Systemumgebung
15.5 Unterstützung nationaler Sprachen Die Unterstützung nationaler Sprachen ist ein wichtiges Anliegen, das zur Internationalisierung von Software gehört. Folgende Anforderungen müssen in diesem Zusammenhang von einem System erfüllt werden: 왘 Elemente der Schrift jeder nationalen Sprache, die unterstützt wird, müs-
sen sich im Zeichensatz des Rechners befinden; 왘 die Verarbeitung der alphabetischen Information soll auf den entspre-
chenden Ordnungskriterien (Sortierung, Unterteilung in Klassen usw.) der jeweiligen Sprache basieren; 왘 die Ein- und Ausgabe solcher Information, wie Geldbeträge, Datumsan-
gaben usw. sollen im landesüblichen Format erfolgen. Die Unterstützung nationaler Sprachen beim SQL Server beeinflußt folgendes: 왘 die Auswahl des entsprechenden Zeichensatzes 왘 die Festlegung des Sortierkriteriums 왘 die Installation der Fehlermeldungen in der nationalen Sprache 왘 die Spezifizierung des Formats der Datumsausgabe.
15.5.1
Die Auswahl des Zeichensatzes
Ein Zeichensatz besteht aus einer festen Menge von Zeichen (Buchstaben, Ziffern und Symbole), die vom System erkannt werden. Generell existieren mehrere Standards, die beschreiben wie einzelne Zeichen dargestellt werden. Manche Standards verwenden 7 Bit für die Speicherung von Zeichen, während andere 8 Bit benutzen. Die SQL Server-Versionen < 7 verwenden das sogenannte Codeseite-Modell, während Version 7 und 2000 Unicode benutzen. (Codeseite ist ein Synonym für den Zeichensatz.) Die beiden Modelle werden in den folgenden Unterabschnitten erläutert. 15.5.1.1
Das Codeseite-Modell
Beide Microsoft-Betriebssysteme Windows und Windows NT haben früher hauptsächlich Englisch und einige wenige westeuropäische Sprachen unterstützt. Zu dem Zeitpunkt hatten alle Zeichensätze 256 Zeichen. Jedes Byte hat ein Zeichen dargestellt. Dazu gehörten 26 Zeichen des englischen Alphabets, Interpunktionszeichen, alle Zeichen des griechischen Alphabets und die sogenannten Ligaturen. (Ligaturen stellen die Verbindung zweier Zeichen dar, die ein einziges typographisches Zeichen repräsentieren.) Jede Codeseite hat zwei Teile: Den ASCII-Zeichensatz, der den Bereich von 0 bis 127 abdeckt und den erweiterten Teil (ab 128). Der erweiterte Teil umfaßt spezielle Symbole der westeuropäischen Sprachen und Ideographen. (Ideo-
352
Unterstützung nationaler Sprachen
graphen sind Zeichen, die zu der Begriffsschrift der fernöstlichen Sprachen gehören.) Jedem Land ist eine entsprechende Codeseite zugewiesen, die Zeichen des Alphabets dieser Sprache sowie spezielle Zeichen im erweiterten Teil des Zeichensatzes enthält. Für die früheren Versionen vom SQL Server waren drei Zeichensätze (siehe Tabelle 15.3) am wichtigsten. Bezeichnung
Erklärung
1252
Dieser Zeichensatz wird auch ANSI-Zeichensatz genannt. Er ist gleichzeitig der Standardzeichensatz, den der SQL Server benutzt.
Codeseite 859
Dieser Zeichensatz enthält, zusätzlich zu den üblichen alphabetischen und numerischen Zeichen, alle Buchstaben, die in den wichtigsten europäischen Sprachen existieren.
Codeseite 473
Dieser Zeichensatz wird meistens in den USA verwendet.
Tabelle 15.3: Die wichtigsten Codeseiten der früheren SQL ServerVersionen
Der SQL Server 2000 unterstützt alle Codeseiten aus Kompatibilitätsgründen. 15.5.1.2
Unicode
Unicode ist ein 16-Bit Zeichensatz, der vom Unicode-Konsortium entwickelt und vertrieben wird. Unicode umfaßt fast alle Zeichen, die heutzutage weltweit für Rechner verwendet werden. (Der Grund liegt darin, daß ein 16-BitZeichensatz mehr als 64.000 Zeichen aufnehmen kann.) Z. Zt. sind etwa 34.000 Punkte von Unicode durch Zeichen und mathematische und technische Symbole belegt. Unicode unterstützt auch einen privaten Bereich, der 6.500 Punkte umfaßt und benutzerdefinierten Anwendungen zur Verfügung steht. Im Gegensatz zu den ersten Zeichensätzen, die nur eine begrenzte Anzahl von Zeichen aufnehmen konnten, stellt Unicode eine einheitliche Methode für die Aufnahme unterschiedlichsten Zeichen dar. Das bedeutet, daß mit Unicode die Darstellung von Zeichen vieler Alphabete gleichzeitig in einem Dokument möglich ist. (Deswegen entfällt bei Unicode die Notwendigkeit, multiple Codeseiten gleichzeitig zu verwenden.) 15.5.1.3
Unicode Datentypen und Funktionen
Der SQL Server unterstützt drei Unicode-Datentypen: 왘 NCHAR 왘 NVARCHAR 왘 NTEXT.
Der Datentyp NCHAR speichert Unicode-Zeichen fester Länge. Die Verwendung dieses Datentyps empfiehlt sich, falls alle Werte einer alphanume-
353
Systemumgebung
rischen Spalte etwa gleiche Länge haben. Der Datentyp NVARCHAR speichert Unicode-Zeichen variabler Länge. Dieser Datentyp eignet sich für alle Tabellenspalten, deren Werte extrem unterschiedliche Längen haben. Der Datentyp NTEXT wird für alphanumerische Werte benutzt, die größer als 4000 Byte sind. Unicode unterstützt auch zwei Funktionen: 왘 UNICODE (›ausdruck‹) 왘 NCHAR (num_wert)
Die Funktion UNICODE ermittelt den numerischen Wert des ersten Zeichens des alphanumerischen Ausdrucks ausdruck. Die Funktion NCHAR dagegen gibt das Unicode-Zeichen zurück, das dem numerischen Wert num_wert entspricht. Beispiel 15.2
declare @var1 NVARCHAR(40) set @var1 = N'Welches Zeichen?' SELECT unicode(@var1) 'Numerischer Wert', nchar(unicode(@var1)) 'UNICODE zeichen'
Das Ergebnis ist: Numerischer Wert UNICODE zeichen ------------------- --------------87 W
15.6 Die Architektur des SQL Servers Der SQL Server 2000 ist das Musterbeispiel eines skalierbaren Datenbanksystems. Das bedeutet, daß derselbe Datenbank-Server sowohl auf den kleinsten Laptops (mit dem Betriebssystem Windows 9x) als auch auf leistungsstarken Rechnern (mit dem Betriebssystem Windows NT/2000 Server Enterprise Edition) verwendet werden kann. Der notwendige Arbeitsspeicher zum Laden des SQL Servers (memory footprint) ist sehr klein und garantiert damit, daß das System ohne Probleme auf den Laptops benutzt werden kann. Auf der anderen Seite hat der SQL Server eine Multithreading Architektur, die ihm ermöglicht auf den SMP- und Cluster-Rechnern benutzt zu werden. (Alle Begriffe aus dem letzten Satz werden im weiteren Verlauf dieses Abschnitts erläutert.) Bevor wir die Architektur des SQL Servers erklären, werden wir die existierenden Hardware-Architekturen beschreiben.
354
Die Architektur des SQL Servers
15.6.1
Die Architektur der Multiprozessorrechner
Weil die traditionelle Hardwarearchitektur mit einem Prozessor zunehmend ihre Leistungsgrenze erreicht hat, wurde im Bestreben, die Performance eines Rechners weiter zu steigern, die parallele Architektur eingeführt. Für diese Architektur wurden im Laufe der Zeit verschiedene Formen entwikkelt, die alle eines gemeinsam haben: Die Anzahl der Prozessoren ist immer größer als eins. Bei den Rechnern mit mehreren Prozessoren wird generell zwischen eng gekoppelten (tightly coupled) und lose gekoppelten (loosely coupled) Prozessoren unterschieden. Bei den eng gekoppelten Prozessoren nutzen alle Prozessoren einen gemeinsamen Arbeitsspeicher und ein einziges Bussystem, auf das alle Prozessoren des Systems gleichzeitig zugreifen. Die Kommunikation der Prozessoren untereinander erfolgt über den Hauptspeicher. Die Rechner mit eng gekoppelten Prozessoren werden auch symmetrische Multiprozessorrechner (Symmetric Multi Processor – SMP) genannt. Die Vorteile der SMP-Rechner liegen in ihrer Skalierbarkeit, d.h. die Anzahl der Prozessoren kann, falls (wegen der Performance) notwendig, relativ einfach erhöht werden. Ab einer gewissen Prozessorenanzahl aber bringt das weitere Aufrüsten eines Rechners mit zusätzlichen Prozessoren keine weitere Leistungssteigerung. Dies beruht auf der Tatsache, daß die Synchronisation aller Prozessoren über den Hauptspeicher erfolgt, dieser aber der Steigerung der Prozessorentaktrate kaum mehr folgen kann. Einen Ausweg aus dieser Sackgasse bieten die lose gekoppelten Systeme. Jeder Prozessor eines lose gekoppelten Systems benutzt einen eigenen Arbeitsspeicher. Die Rechner, die miteinander lose gekoppelt sind, werden auch Cluster-Rechner genannt. Falls mehrere SMP-Rechner miteinander lose gekoppelt werden, kann die Performance weiter erhöht werden. SMPRechner können, besonders in der Cluster-Form, die Performance von Mainframes erreichen. Der Cluster hat zusätzlich den Vorteil, daß der Ausfall eines Rechners nicht den Ausfall des Gesamtsystems nach sich zieht. Trotz dieser offensichtlichen Vorteile der SMP-Architektur wurde eine weitere parallele Architektur entwickelt, die noch mehr Leistungssteigerung verspricht: die sogenannten massiv-parallelen Prozessoren (MPP). Ein massiv-paralleles System vereinigt, genauso wie ein Cluster, mehrere Prozessoren. Der Unterschied zu einem Cluster liegt zuerst in der Anzahl der Rechner, die vereinigt werden. Ein massiv-paralleles System enthält wesentlich mehr Rechner als ein Cluster. Der zweite Unterschied liegt darin, daß die Rechner dieser Hardwarearchitektur durch eine Punkt-zu-Punkt-Verbindung vernetzt sind. (Die Rechner eines Clusters dagegen sind gewöhnlich durch einen einzigen Kommunikationsweg verbunden.) Schließlich benutzt ein massiv-paralleles System keine LANs wie Cluster-Rechner, sondern Hochgeschwindigkeitsnetzwerke für die Verbindung einzelner Knoten.
355
Systemumgebung
Genauso wie bei den Cluster-Rechnern erfolgt die Kommunikation bei den massiv-parallelen Rechnern zwischen den einzelnen Prozessoren über Nachrichtenaustausch. Zu dem Zeitpunkt, wo dieses Buch geschrieben wird, unterstützt der SQL Server sowohl unterschiedliche SMP-Rechner als auch einen Cluster-Typ (NT2-machine cluster). Die Anzahl der Prozessoren eines SMP-Rechners, für den der SQL Server benutzt werden kann, erhöht sich ständig, so daß der SQL Server auch für die größten Datenbanken und Data WarehouseSysteme (siehe Kapitel 28) verwendet werden kann.
15.6.2
Multithreading-Architektur des SQL Servers
Die Architektur eines SQL Server-Systems kann an die Hardware, auf der es läuft, angepaßt werden. Bei den Monoprozessor-Rechnern wird damit immer ein Prozeß gestartet, der dann mit allen Datenbankanwendungen, die in bezug zum SQL Server stehen, kommuniziert (d.h. der SQL Server besitzt eine Multithreading-Architektur). Die Multithreading-Architektur kennzeichnet die Eigenschaft eines Datenbankmanagementsystems, mehrere threads parallel ausführen zu können. (Ein thread ist Teil eines Prozesses, der aus der Sicht des Datenbankmanagementsystems als eine logische Einheit verarbeitet werden kann. Aus diesem Grund werden threads auch Leichtgewichtprozesse genannt.) Durch die Unterteilung der Prozesse in threads ist es möglich, eine hohe Anzahl von Datenbankanwendungen mit Hilfe einer kleinen Anzahl von Prozessoren effizient auszuführen. Das Umschalten von einem thread zu einem anderen in der Multithreading-Architektur geschieht wesentlich schneller als das entsprechende Umschalten von einem Prozeß zu einem anderen in der herkömmlichen Architektur. Zusätzlich dazu teilen threads, die einem Prozeß zugewiesen sind, immer die Ressourcen des Betriebssystems. Falls der Rechner, auf dem der SQL Server läuft, mehrere Prozessoren hat, kann der SQL Server so konfiguriert werden, daß die Leistung aller Prozessoren gleichmäßig und effektiv ausgenutzt wird. (Damit hat der SQL Server eine wichtige Eigenschaft, nämlich, daß die Anzahl der zur Verfügung stehenden Prozessoren vom Datenbankadministrator selbst bestimmt werden kann.) Abbildung 15.1 zeigt die Architektur des SQL Servers auf einem Mehrprozessorrechner. (Eine solche Architektur wird auch »Ein Prozeß Multithreading«-Architektur genannt.)
356
Die Architektur des SQL Servers Abbildung 15.1: Die Architektur des SQL Servers bei Mehrprozessorrechnern
Der SQL Server ermöglicht die optimale Auslastung der zur Verfügung stehenden Prozessoren und die Steigerung der Anwenderkapazität. Diese Architektur von SQL Server hat damit folgende Eigenschaften: 왘 die Anzahl der von dem Datenbankmanagementsystem genutzten Pro-
zessoren kann vom Systemadministrator bestimmt werden 왘 die Verwaltung der Benutzer und des Speichers ist für das Datenbank-
managementsystem optimiert 왘 die Speicherkapazität wird als Ganzes behandelt.
Der Vorteil der Verwendung eines Mehrprozessorrechners für den SQL Server liegt in der Parallelisierung einiger Aufgaben. Dazu gehören: 왘 die Archivierung von Daten und 왘 die parallele Datenbearbeitung.
Der SQL Server kann die Archivierung einer Datenbank bzw. eines Transaktionsprotokolls parallel durchführen, falls mehrere Dateien für diesen Vorgang zur Verfügung stehen. (Für weitere Erklärungen bezüglich der parallelen Archivierung siehe Kapitel 21.) Die parallele Datenbearbeitung (parallel scan) bezieht sich auf das sequentielle Lesen der physikalischen Seiten, wo Daten einer Tabelle bzw. eines Index gespeichert sind. In diesem Fall kann der SQL Server einzelne Seiten asynchron und im voraus lesen (read ahead). Diese Art der Abarbeitung der physikalischen Seiten kann signifikante Performanceverbesserungen bringen bei: 왘 den Abfragen, die sequentiell abgearbeitet werden 왘 der Erstellung eines Index 왘 der Aktualisierung eines Index mittels der UPDATE STATISTICS-Anwei-
sung 왘 bei der Überprüfung der logischen und physikalischen Konsistenz mit-
tels der DBCC-Anweisung.
357
Systemumgebung
15.7 Zusammenfassung Der SQL Server gilt als technisch weit entwickeltes relationales Datenbankmanagementsystem in bezug auf zwei in diesem Kapitel erörterte Themen: 왘 die Unterstützung nationaler Sprachen und 왘 die Architektur des Datenbank-Servers.
Die Unterstützung nationaler Sprachen ist besonders in den Ländern, wo Englisch nicht die nationale Sprache ist, wichtig. Bei der deutschen Sprache geht es nicht nur um die bloße Unterstützung der Umlaute, sondern vielmehr um die richtige Sortierung (z.B. in der SELECT-Anweisung mit der ORDER BY-Klausel) der Tabellenreihen. All dies wird durch entsprechende Komponenten beim SQL Server unterstützt. Der SQL Server hat auch eine moderne Technologie in bezug auf die Ausnutzung der Hardware mit eng gekoppelten Prozessoren. Die »Ein Prozeß Multithreading«-Architektur beim SQL Server ermöglicht die optimale Ausnutzung der zur Verfügung stehenden Prozessoren. Zusätzlich dazu wird sich die Performance des Servers durch die Erhöhung der Benutzeranzahl unwesentlich ändern, was bei den anderen DBMS, die diese Architektur nicht optimal unterstützen, nicht der Fall ist. Aufgaben
358
A.15.1
Welcher Unterschied existiert zwischen dem isql- und osqlDienstprogramm?
A.15.2
Wo speichert das SQL Server-System temporäre Daten?
A.15.3
Nennen Sie Vor- und Nachteile von multiplen Instanzen.
A.15.4
Was bedeutet multithreading?
A.15.5
Welche Administrierungsaufgaben können mit Hilfe des SQL Server-Systems parallelisiert werden?
III
Teil
SQL Server: Systemadministration
359
16
Die Systemadministration
In diesem Kapitel wird sowohl ein allgemeiner Überblick über die Systemadministrationswerkzeuge, die der SQL Server bietet, als auch eine Einführung in die allgemeinen Aufgaben eines Systemadministrators gegeben. Es stellt gleichzeitig eine Einführung für den dritten Teil des Buches dar, der die Administrierungsaufgaben erörtert.
16.1 Der SQL Server und die Systemadministration Der Microsoft SQL Server ist ein skalierbares Datenbankmanagementsystem, das sich besonders für hohe Anforderungen bezüglich der Performance eignet. Zusätzlich dazu gehört der SQL Server zu den technisch am weitesten entwickelten Systemen in bezug auf die offene Client/Server-Architektur und die optimale Unterstützung der Rechner mit eng gekoppelten Prozessoren. Diese Eigenschaften werden beim SQL Server durch folgende Funktionen erreicht: 왘 die enge Integration des SQL Server-Systems in Windows NT/2000 bzw.
Windows 9x 왘 die Möglichkeit, mehrere SQL Server zentralisiert zu verwalten 왘 die Auftragsplanung und die Verwaltung von Warnungen
Die enge Integration des SQL Servers in Windows NT/2000 zeigt sich durch die direkte Verwendung mehrerer Betriebssystemdienste und Werkzeuge seitens des SQL Servers. Dazu gehören die Dienste zur threads-Verwaltung und die parallele Benutzung (zusammen mit dem Windows NT/2000) von Performance Monitor und dem Ereignisprotokoll. Eine weitere Verbindung zeigt sich durch die Möglichkeit, Benutzerverwaltung des Betriebs- und des Datenbanksystems zu vereinen. Der SQL Server bietet eine einfache und benutzerfreundliche Oberfläche für die zentralisierte Verwaltung aller Datenbank-Server, die einem Unternehmen gehören. Diese Funktionalität ermöglicht die Überwachung und die Verwaltung aller Datenbank-Server an einer Stelle zu vereinigen. Der SQL Server enthält auch eine grafische Schnittstelle für die Planung unterschiedlicher Aufträge und die Verwaltung möglicher Systemwarnungen. Diese Funktionalität beinhaltet nicht nur die Protokollierung diverser Fehlermeldungen im entsprechenden Protokoll wie bei den anderen Datenbanksystemen, sondern auch die Möglichkeit, im voraus ausgewählte Mitarbeiter über Medien wie die elektronische Post bzw. pager zu informieren.
361
Die Systemadministration
Der SQL Server verwendet den SQL DMO (Distributed Management Objects), um unternehmensweite Systemadministration zu ermöglichen. Mit dem SQL DMO ist es möglich, Funktionen wie die zentrale Serververwaltung und die Auftragsplanung zu realisieren. SQL DMO faßt mehrere Dienste zusammen, die in mehrere Gruppen unterteilt werden können (siehe Abbildung 16.1). Abbildung 16.1: Die Komponenten des SQL Distributed Management Objects
Auf der niedrigsten Ebene befinden sich der Datenbank-Server und der SQL Server Agent. Der SQL Server Agent gehört zu den SQL Server-Diensten und ermöglicht die Verwaltung von Ereignissen, die bei der Benutzung eines SQL Server-Systems auftreten. Die zweite Ebene enthält eine 32-Bit-Schnittstelle – SQL-DMO (Distributed Management Objects) –, die die Information über sämtliche Verwaltungsfunktionen des SQL Servers beinhaltet. SQL-DMO faßt über 50 Objekte und 1000 unterschiedliche Eigenschaften und Methoden dieser Objekte zusammen, die dann von logisch übergeordneten Werkzeugen benutzt werden können. Auf der höchsten Ebene befindet sich der SQL Enterprise Manager. Dieses Werkzeug verwendet die Information, die im SQL-DMO über den SQL Server und seine Objekte gespeichert ist, und damit dem Systemadministrator die Möglichkeit gibt, alle seine Aufgaben auf eine einfache und benutzerfreundliche Weise zu lösen.
362
Die Administrationswerkzeuge des SQL Servers
16.2 Die Administrationswerkzeuge des SQL Servers Der SQL Server beinhaltet viele grafische Werkzeuge, die für unterschiedliche Administrationsaufgaben benutzt werden können. Diese Werkzeuge befinden sich in der Programmgruppe »Microsoft SQL Server« (siehe Abbildung 16.2). Welche Werkzeuge tatsächlich angeboten werden, hängt davon ab, um welche Umgebung (Client oder Server) es sich handelt. Abbildung 16.2: Die Programmgruppe »Microsoft SQL Server«
Die in Abbildung 16.2 dargestellten Werkzeuge werden in der Tabelle 16.1 aufgelistet und einzeln beschrieben. Werkzeug
Beschreibung
Analysis Services
Analysis Services ist die Data Warehousing-Komponente des SQL Server-Systems. (Für die Beschreibung dieser Komponente siehe den vorletzten Teil dieses Buches ab Kapitel 26.)
SQL Server ClientKonfiguration
Ermöglicht die Einstellung der Bibliotheks- und ServerInformationen auf der Client-Seite.
SQL XML-Unterstützung in IIS konfigurieren
Mit dieser Komponente läßt sich der SQL Server als XML-Server konfigurieren, falls IIS installiert ist (siehe Kapitel 29).
Daten importieren und exportieren
Wird für die logische Übertragung von Objekten und Daten zwischen zwei SQL Server-Systemen verwendet.
Dienst-Manager
Dient zum Starten und Stoppen des SQL Servers und des SQL Server Agents.
SQL Enterprise Manager
Das wichtigste SQL Server-Werkzeug aus der Sicht eines Systemadministrators. Dient praktisch für fast alle Aufgaben, die der Administrator eines SQL Server-Systems hat.
Tabelle 16.1: Werkzeuge der Programmgruppe MS SQL Server
363
Die Systemadministration
Werkzeug
Beschreibung
Onlinedokumentation
Onlinedokumentation enthält die ganze Dokumentation in bezug auf SQL Server. (Für die Beschreibung der Onlinedokumentation siehe Kapitel 2.)
Profiler
Wird vom Systemadministrator für die Verwaltung der Server-Aktivitäten verwendet.
Query Analyzer
Wird meistens für die Eingabe und Ausführung von Transact-SQL-Anweisungen und Datenbankprozeduren verwendet.
SQL Server Netzwerk-Konfiguration
Bietet die Möglichkeit, alle in einem Netz befindlichen SQL Server-Systeme zu konfigurieren.
Zusätzlich zu den grafischen Werkzeugen, die in Abbildung 16.2 dargestellt sind, bietet der SQL Server dem Systemadministrator zusätzliche Mittel an, die in folgende drei Gruppen unterteilt werden können: 왘 Dienstprogramme, 왘 Systemprozeduren und 왘 Kommandos bzw. Transact-SQL-Anweisungen.
16.3 Der Systemadministrator Die Aufgabe des Systemadministrators umfaßt alle Dienste, die zum Arbeiten mit einem SQL Server-System im allgemeinen relevant sind. Zu diesen Aufgaben gehören: 왘 die Planung und die Ausführung der Systeminstallation 왘 das Starten und Stoppen des Systems 왘 das Verwalten der Systemressourcen 왘 die Erstellung von Login-ID und die Vergabe bzw. der Entzug der Zu-
griffsrechte 왘 der Transfer der Massendaten 왘 die Untersuchung und Behebung entstandener Systemfehler 왘 die Archivierung und Wiederherstellung von Datenbanken und Transak-
tionsprotokollen 왘 die Durchführung der Maßnahmen zur Verbesserung der Performance 왘 das Verwalten der Datenreplikation.
Die oben genannten Aufgaben des Systemadministrators werden in unterschiedlichen Kapiteln erörtert. Das nachfolgende Kapitel beschreibt sowohl die Installation als auch das Starten bzw. Stoppen des Systems. Das Verwalten der Datenbanken und Transaktionsprotokolle ist das Thema des Kapitels 18, während die Verwaltung von Login-ID und Benutzerkennungen in
364
Zusammenfassung
Kapitel 19 beschrieben werden. In Kapitel 20 wird die Archivierung bzw. Wiederherstellung von Datenbanken erörtert, während der Transfer der Massendaten und die neue DTS-Komponente (Data Transformation Services) in Kapitel 21 beschrieben werden. Die automatische Ausführung der Administrationsaufgaben ist in Kapitel 22 beschrieben. Die Untersuchung und Behebung entstandener Systemfehler ist das Thema des Kapitels 23, während die allgemeinen Performance-Fragen in Kapitel 24 beschrieben sind. Die Datenreplikation wird in Kapitel 25 erörtert. Die Aufgabe des Systemadministrators ist oft sehr schwierig von den Aufgaben eines Datenbankadministrators zu unterscheiden. Wenn z.B. eine Benutzerdatenbank nicht genügend Speicherplatz zur Verfügung hat, kann es sich sowohl um ein SQL Server System- als auch um ein Datenbankproblem handeln. Dazu kommt noch, daß bei Systemen mit vielen Datenbanken grundsätzlich zu empfehlen ist, sowohl System- als auch allgemeine Datenbankaufgaben einer Person – dem Systemadministrator – zu übertragen. Aus diesen Gründen werden wir im weiteren Text keinen Unterschied zwischen den System- und allgemeinen Datenbankaufgaben machen.
16.4 Zusammenfassung Die Systemadministration kann aus zwei Blickwinkeln betrachtet werden: aus der Sicht des Systemadministrators und aus der Sicht des Datenbanksystems. Die Aufgaben des Systemadministrators umfassen alle Dienste, die den anderen Benutzern eine störungsfreie und performante Benutzung des SQL Server-Systems ermöglichen. Der SQL Server stellt dem Systemadministrator zahlreiche grafische Werkzeuge zur Verfügung, mit denen die Administrierung des Systems leicht durchführbar ist.
365
17
Die Planung und die Ausführung der Systeminstallation
In diesem Kapitel werden alle Aufgaben rund um die Installation des SQL Servers beschrieben. Zuerst werden Themengruppen genannt, die vor der Installation geplant werden sollen. Danach werden sowohl die Installation des Datenbank-Servers als auch der Clients erörtert. Ein weiteres Thema dieses Kapitels sind die Maßnahmen, die der Systemadministrator in der Postinstallationsphase durchführen soll. Schließlich werden unterschiedliche Alternativen zum Starten und Stoppen eines SQL Server-Systems erörtert.
17.1 Die Planung der Installation eines SQL Server-Systems Die Installation eines SQL Server-Systems sollte nicht ohne Vorplanung durchgeführt werden. Eine sorgfältige Planung ist unbedingt notwendig, weil sehr viele Faktoren existieren, die die Entscheidungen bei der Installation beeinflußen. Bei der Installationsplanung sollte sich der Systemadministrator mit den folgenden Themengruppen beschäftigen: 왘 welchem Zweck dienen das SQL Server-System und die dazugehörigen
Datenbanken? 왘 welche Hard- und Software werden für das SQL Server-System benötigt? 왘 wie viele Benutzer werden das Datenbanksystem gleichzeitig verwen-
den?
17.1.1
Anwendungszweck eines SQL Server-Systems
Ein SQL Server-System kann sehr vielen unterschiedlichen Zwecken dienen. Falls ein System z.B. ausschließlich für Lehrzwecke verwendet wird, sind die meisten der nachfolgenden Themen bezüglich der Installation irrelevant. In den meisten Fällen wird der SQL Server für produktive Zwecke verwendet, wobei sehr große Unterschiede bezüglich der Benutzeranzahl oder des Datenvolumens existieren können. Eine weitere Frage, die bei den modernen Datenbanksystemen wichtig ist, ist der allgemeine Verwendungszweck des Systems: Wird das System überwiegend für OLTP (OnLine Transaction Processing)-Anwendungen oder als DSS (Decision Support System) angewendet?
367
Die Planung und die Ausführung der Systeminstallation
Der SQL Server 2000 unterstützt multiple Instanzen des Datenbank-Servers, so daß einzelne Instanzen für unterschiedliche Zwecke verwendet werden können. Die Frage, ob es sich bei Ihrem System überwiegend um ein OLTP-System (d.h. ein System mit vielen Benutzern, kurzen Transaktionen und schnellen Antwortzeiten) oder um ein Decision Support System (d.h. ein System mit wenig Benutzern und mit komplexen Abfragen auf ein sehr großes Datenvolumen) handelt, ist wichtig, weil sich verschiedene Teile des SQL Servers unterschiedlich für diese beide Aufgaben eignen. Microsoft liefert zusammen mit dem SQL Server 2000 auch den MS Analysis Services. Dabei soll der SQL Server für OLTP-Anwendungen benutzt werden, während Analysis Services die DSS-Komponente darstellt. Falls die Anzahl der Benutzer sehr groß ist, kann es schwierig sein, die Performance des Systems optimal zu halten. Eine naheliegende Möglichkeit bei der Verwendung des SQL Servers wäre, einen Mehrprozessorrechner anzuschaffen, damit die Skalierbarkeit des Systems möglich ist. (Unabhängig davon benötigt jeder Benutzer des SQL Server-Systems etwa 40KB des Arbeitsspeichers, womit auch die notwendige Gesamtgröße des Arbeitsspeichers beeinflußt wird.) Die geschätzte Größe der Datenbanken bezieht sich auf die Anschaffung der ausreichenden Plattenkapazität. Im allgemeinen kann man sagen, daß die Anschaffung mehrerer kleinerer Platten für das System vorteilhafter in bezug auf die Datensicherheit ist, als der Kauf einer einzigen Platte mit sehr großer Kapazität.
17.1.2
Hard- und Softwarevoraussetzungen
Die Tatsache, daß der SQL Server nur auf Microsoft eigenen Betriebssystemplattformen Windows NT/2000 und Windows 9x läuft, vereinfacht die Entscheidung bezüglich der Anschaffung der notwendigen Hard- und Software. Vor der Installation muß die Entscheidung bezüglich folgender Hardund Softwarekomponenten getroffen werden: 왘 welcher Rechner benutzt wird 왘 welches Netzwerkprotokoll für die Kommunikation zwischen dem Ser-
ver und den Clients verwendet werden soll. 17.1.2.1
Rechnerplattformen eines SQL Server-Systems
Die Betriebssysteme Windows NT/2000 und Windows 9x – und damit auch der SQL Server – laufen ausschließlich auf dem Intel-Prozessoren und kompatiblen Systemen.
368
Die Planung der Installation eines SQL Server-Systems
Hardwareplattformen mit dem DEC Alpha AXP-Prozessor und kompatiblen Systemen unterstützen MS-Betriebssysteme nicht mehr. 17.1.2.2
Netzwerkprotokolle
Weil der SQL Server ein Client-Server-Datenbanksystem ist, werden von ihm unterschiedliche Netzwerkprotokolle, die die Kommunikation zwischen den Clients und dem Server ermöglichen, unterstützt. Bei der Installation eines SQL Server-Systems kann der Systemadministrator entscheiden, welche Protokolle (als Bibliotheken) vorhanden sein sollten. Folgende Netzwerkprotokolle werden vom SQL Server unterstützt: 왘 Named Pipes 왘 TCP/IP 왘 Multi-Protokoll 왘 NWLink IPX/SPX 왘 Banyan Vines 왘 AppleTalk ADSP.
Named Pipes ist das Standard-Netzwerkprotokoll des SQL Servers. Mit diesem Protokoll ist die Interprozeßkommunikation (IPC) entweder lokal oder über Netze möglich. (Nach der Installation ist es möglich, die Unterstützung für Named Pipes zu löschen und ein anderes Netzwerkprotokoll für die Kommunikation zwischen Clients und dem Server zu wählen. TCP/IP (Transmission Control Protocol/Internet Protocol) ist das meistbenutzte Protokoll bei den UNIX-Rechnern. (Windows 9x verwendet dieses Protokoll als Standardprotokoll.) Der Systemadministrator muß für dieses Protokoll die Port-Nummer für den SQL Server während der Systeminstallation angeben. Multi-Protokoll benutzt den RPC (Remote Procedure Call)-Mechanismus für die Kommunikation zwischen einem Client und seinem Server. Dieses Protokoll enthält z.Zt. drei andere Protokolle – Named Pipes, IPX/SPX und TCP/ IP. (Das ist das einzige Netzwerkprotokoll, das keine Konfigurationsparameter braucht.) NWLink IPX/SPX (Internet Packet eXchange/Sequenced Packet eXchange) ist das Standardprotokoll für Novell SPX und Windows NT/2000. Falls der Systemadministrator sich bei der Installation für dieses Protokoll entscheidet, muß er den Dienstnamen für Novell Bindary angeben. (Der Standardname für Novell Bindary ist der Rechnername, wo sich der Server befindet.) Banyan Vines ist ein weiteres Protokoll, das häufig bei der Kommunikation in der PC-Welt verwendet wird. (Banyan Vines-Unterstützung für Windows NT/2000-basierte Clients steht z. Zt. nur auf der Intel-Plattform zur Verfügung.) Bei der Installation dieses Protokolls muß der Systemadmi-
369
Die Planung und die Ausführung der Systeminstallation
nistrator den Dienstnamen des PCs in der Sprache Street Talk angeben. (Dieser Name muß vorher mit Hilfe des Banyan Vines-Dienstprogramms mservice erstellt werden.) Apple Talk ADSP ist ein Netzwerkprotokoll der Firma Apple, das die Kommunikation zwischen dem SQL Server und den Apple Macintosh-Clients ermöglicht. Decnet ist ein Netzwerkprotokoll der Firma Digital, das sehr oft für die Kommunikation mit dem Betriebssystem VMS verwendet wird. Ähnlich wie bei den anderen Protokollen muß der Systemadministrator auch beim Decnet den Namen (in der Form einer Objekt-ID) bei der Installation angeben. Die Auswahl des Netzwerkprotokolls beeinflußt die Benutzung der angebotenen Sicherheitsmodi beim SQL Server. Der SQL Server unterstützt zwei Authentifizierungen: SQL Server- und Windows-Authentifizierung. Die SQL Server-Authentifizierung kann mit allen oben genannten Netzwerkprotokollen verwendet werden, während die Windows-Authentifizierung nur mit Named Pipes und dem Multi-Protokoll möglich ist. Das schnellste aller Protokolle ist das SQL Server Standard-Protokoll Named Pipes. Die Benutzung eines der beiden Protokolle TCP/IP bzw. IPX/ SPX macht die Netzwerk-Kommunikation schneller als die Benutzung des Multi-Protokolls, das eine Vereinigung von TCP/IP, Named Pipes undIPX/SPX darstellt.
17.1.3
Die notwendigen Angaben bei der Installation
Bei einer Installation des SQL Servers muß der Systemadministrator sehr viele Angaben machen. Einige diese Angaben sind einfach, während andere vorbereitet werden sollten. Folgende Fragen sollten vor der Installation geklärt werden: 왘 Wo soll sich das Hauptverzeichnis befinden? 왘 Welchen Zeichensatz und welches Sortierkriterium soll das System ver-
wenden? 왘 Welchen Sicherheitsmodus soll das System verwenden? 왘 Welche Benutzerkennungen sollen den SQL Server- und SQL Server
Agent-Diensten zugewiesen werden? 왘 Wo soll die Online-Dokumentation installiert werden?
Das Hauptverzeichnis des SQL Servers enthält die meisten SQL Server-Systemdateien. Wir empfehlen, den Standard-Pfadnamen (C:\Mssql) zu behalten, weil dieser Name die Server-Version eindeutig identifiziert. (Beim SQL Server ist es durchaus möglich, unterschiedliche SQL Server-Versionen nebeneinander zu installieren und zu verwenden.)
370
Die Planung der Installation eines SQL Server-Systems
Die Angaben zum Zeichensatz und Sortierkriterium spielen eine wichtige Rolle bei der Verwendung des SQL Servers außerhalb des englischsprachigen Raums. Die Entscheidung über den entsprechenden Zeichensatz und das Sortierkriterium muß gut überlegt werden, weil die nachträgliche Änderung sehr viel Arbeit verursachen kann. (In diesem Fall müssen die Daten aller Tabellen neu geladen werden.) Während der Installationsphase müssen auch die Angaben über Unicode-Daten gemacht werden. Hier empfiehlt sich die Standardangabe zu wählen, besonders für den Fall, daß die früheren SQL Server-Versionen auch verwendet werden. Nach der Installationsphase muß man zwischen den beiden Sicherheitsmodi wählen: 왘 Windows-Modus 왘 Mixed-Modus.
Bei dem Windows-Sicherheitsmodus wird das Einloggen in das Datenbanksystem mit dem Einloggen in das Betriebssystem vereinigt. Der Benutzer muß also nur auf der Betriebssystemebene seine Kennung zu der eigenen Identifizierung verwenden, um auch dem SQL Server-System bekannt zu sein und dieses benutzen zu können. Der Mixed-Modus erlaubt den Benutzern entweder nur die Windows-Authentifizierung oder die beiden Authentifizierungen zu benutzen. Das heißt, daß manche Kennungen ausschließlich die Windows-Authentifizierung benutzen, während andere sowohl die Windows- als auch die SQL Server-Authentifizierung verwenden. Wir empfehlen die Benutzung des Mixed-Modus, weil er dem Benutzer die Möglichkeit gibt, zwischen den beiden Alternativen (Windows- und SQL Server-Authentifizierung) zu wählen. Für die SQLServer- und SQLServerAgent-Dienste sollten die Benutzerkennungen vor der Installation erstellt werden. (Beide Dienste können dieselbe Kennung verwenden.) Die Online-Dokumentation kann entweder auf der Platte gespeichert oder von der CD-ROM verwendet werden. Falls die Anlage 15 MB Plattenspeicher zur Verfügung hat, empfehlen wir diese Handbücher bei der Installation auf der Platte zu speichern, weil dadurch der Zugriff auf die notwendige Information direkt und damit schneller ist. (Für die Verwendung der Online-Dokumentation von der CD-ROM sind 2 MB Plattenspeicher erforderlich.)
371
Die Planung und die Ausführung der Systeminstallation
17.2 Die Installation eines SQL ServerSystems Für die Installation des SQL Servers muß das Installationsprogramm, das sich auf dem SQL Server CD-ROM befindet, gestartet werden. Das Installationsprogramm beinhaltet mehrere Alternativen, die alle in den nachfolgenden Abschnitten beschrieben werden.
17.2.1
Installationsanfang
Um die Installation des SQL Servers 2000 zu starten, muß die SQL Server 2000 CD-ROM in das entsprechende Laufwerk gelegt werden. Danach wird vom System automatisch das SQL Server Automenü (Abbildung 17.1) am Bildschirm angezeigt. (Falls das Automenü nicht automatisch angezeigt wird, muß die Setup-Komponente, die sich auf der CD-ROM befindet, explizit gestartet werden.) Abbildung 17.1: Das SQL Server 2000 Automenü
Wie aus Abbildung 17.1 ersichtlich, existieren verschiedene Optionen, die gestartet werden können. Die erste Option, die angeklickt werden soll, sind die SQL Server 2000 Voraussetzungen. Der Sinn dieser Entscheidung ist, sich zu vergewissern, ob alle erforderlichen Komponenten für die Installation des SQL Servers auf Ihrem System schon existieren.
372
Die Installation eines SQL Server-Systems
Die Softwarevoraussetzungen für den SQL Server 2000 sind abhängig vom Betriebssystem, auf dem die Installation läuft. Für beide Betriebssysteme – Windows NT/2000 und Windows 9x – ist die Version 5 des MS Internet Explorers die Voraussetzung. Diese Komponente ist sowohl für die Client- als auch für die Server-Installation notwendig. Die minimale Installation des Browsers ist ausreichend, und es muß nicht der Standard-Browser Ihres Systems sein. Für Windows NT-Rechner ist die Version 4 mit mindestens dem Service Pack 6 die Voraussetzung. (Die Voraussetzungen für das Netzwerk und die Clients werden in den entsprechenden Abschnitten erläutert.) 17.2.1.1
Installation der SQL Server 2000-Komponenten
Nach der Installation der erforderlichen Komponenten kann mit der Installation der SQL Server-Komponenten begonnen werden, indem die gleichnamige Option im SQL Server Automenü ausgewählt wird. Danach erscheint das Menü mit allen Komponenten (Abbildung 17.2). Abbildung 17.2: Das SQL Server 2000 Automenü: SQL Server-Komponenten
Bevor die Komponenten des SQL Servers erörtert werden, werden wir die existierenden Editionen des SQL Server erklären. Microsoft unterstützt sechs SQL Server-Editionen: 왘 Standard-Edition 왘 Enterprise-Edition 왘 Personal-Edition
373
Die Planung und die Ausführung der Systeminstallation 왘 Desktop Edition 왘 Windows CE-Edition 왘 Entwickler- (Developer) Edition.
Die Standard-Edition ist die Standardversion des SQL Servers 2000. Diese Edition umfaßt die volle Funktionalität des Datenbank-Servers und läuft deswegen nur auf Windows NT/2000-Rechnern. Die Enterprise-Edition ist eine spezielle Version des SQL Servers, die für die zeitkritischen Datenbankanwendungen mit vielen Benutzern besonders geeignet ist. Im Unterschied zu der Standard-Edition enthält die EnterpriseEdition zusätzliche Funktionalität, die die Arbeit mit den SMP-Rechnern und Clustern vereinfacht. Die wichtigsten Funktionen sind: 왘 log shipping (siehe Kapitel 20) 왘 die Erstellung von Partitionen als Speicherungsorte für Daten und Ag-
gregationen eines Würfels (siehe Kapitel 28). Die Personal-Edition wird gewöhnlich für Datenbankanwendungen, die auf mobilen Rechnern laufen, benutzt. Diese Edition wird mit Windows NT/ 2000 oder MS BackOffice Small Business-Server verwendet. Die Desktop-Edition wird als entfernter Datenbank-Server verwendet, der die Verbindung zu einem zentralen Server hat und die Erstellung von Datenbankanwendungen ermöglicht. Diese Edition läuft auf Windows NT/2000und Windows 9x-Rechnern. Die Windows CE-Edition läuft auf Windows CE-Geräten. Die Entwicklerversion des SQL Servers wird von Programmierern für die Erstellung von Datenbankapplikationen für den SQL Server verwendet. Im Unterschied zu den anderen Editionen ist diese nur für die Entwicklungssysteme (und nicht für die Produktionssysteme) lizenziert. Nach der Beschreibung der existierenden Editionen werden wir zu der Installation der SQL Server-Komponenten zurückkehren. Wie aus Abbildung 17.2 ersichtlich, bietet die SQL Server-CD-ROM die Installation dreier Komponenten: des Datanbankservers, Analysis Services und English Query. In diesem Abschnitt werden wir die Installation der Standardversion des Datenbankservers beschreiben. (Die Installation des Analysis Services wird in Kapitel 27 erörtert, während die English Query-Komponente kein Thema dieses Buches ist.) Um die Installation des Datenbankservers zu starten, muß die entsprechende Schaltfläche angeklickt werden. In dem folgenden Menü (Abbildung 17.3) wird der Name des Rechners, auf dem der SQL Server installiert werden soll, eingetragen. Die Installation kann entweder auf dem lokalen oder irgendeinem im Netzwerk befindlichen Rechner durchgeführt werden. (Falls die Installation auf einem entfernten Rechner durchgeführt werden soll, werden zusätzliche Informationen darüber vom Installationsprozeß verlangt.)
374
Die Installation eines SQL Server-Systems Abbildung 17.3: Das Computername-Menü
Sowohl die lokale als auch die entfernte Installation haben folgende Voraussetzungen: 왘 sowohl der lokale als auch der entfernte Rechner müssen als Betriebssys-
tem Windows NT/2000 haben 왘 die aktuelle Benutzerkennung auf dem lokalen Rechner muß auf dem
entfernten Rechner Administrationsrechte besitzen. Im weiteren Verlauf dieses Kapitels werden wir die lokale Installation beschreiben. Nach der Auswahl des lokalen Rechners sucht der Installationsprozeß nach den existierenden SQL Server-Dateien, um festzustellen, ob der SQL Server schon vorher installiert wurde. Falls SQL Server-Dateien nicht existieren, erscheint das nächste Menü (Abbildung 17.4), wo entweder die Installation einer neuen Instanz oder die Aktualisierung einer existierenden vorgenommen werden kann. Nach der Auswahl der Installation einer neuen Instanz erscheint das Menü mit dem Lizenzierungsverfahren, das akzeptiert werden muß, um mit der Installation fortfahren zu können. Das nächste Menü (Abbildung 17.5) ermöglicht die Auswahl der Softwareteile, die auf Ihrem Rechner installiert werden sollen. Für die volle Installation von Client- und Server-Komponenten muß die Option »Server- und Clienttools« ausgewählt werden. (Der Installationsprozeß der Client-Komponenten wird später in diesem Kapitel beschrieben.) Im nächsten Installationsschritt wird entweder die Installation des Standard-Servers oder einer benannten Instanz veranlaßt (siehe Abbildung 17.6). Wie schon erwähnt wurde, unterstützt der SQL Server 2000 mehrfache Instanzen des Datenbank-Servers, wo jede Instanz ihre eigenen System- und Benutzerdatenbanken besitzt.
375
Die Planung und die Ausführung der Systeminstallation Abbildung 17.4: Das Installationsauswahl-Menü
Abbildung 17.5: Installationsdefinition
376
Die Installation eines SQL Server-Systems Abbildung 17.6: Das InstanznameMenü
Abbildung 17.7: Setup-Typ
Nach der Auswahl der Instanzart wird im nächsten Installationsschritt (Abbildung 17.7) eine der drei folgenden Installationsoptionen ausgewählt: 왘 Standardinstallation 왘 minimale Installation 왘 benutzerdefinierte Installation.
377
Die Planung und die Ausführung der Systeminstallation
Diese drei Optionen unterscheiden sich voneinander in der Anzahl der SQL Server-Komponenten, die dem Benutzer nach der Installationsphase zur Verfügung stehen. Die Standardinstallation verwendet die Standardangaben und ist für die meisten Benutzer und Systeme die beste Option. Sie installiert den SQL Server, alle Client-Komponenten und die Onlinedokumentation. Die minimale Installation, wie der Name schon sagt, installiert die minimale Anzahl von Komponenten, die für die Verwendung des SQL Server-Systems notwendig ist. (Diese Installationsoption empfiehlt sich, falls der Rechner, auf dem die Installation durchgeführt wird, wenig Speicherplatz aufweist.) Mit Hilfe der benutzerdefinierten Installation kann man die zu installierenden Komponenten selbst auswählen. Die benutzerdefinierte Installation empfiehlt sich für Software-Experten, die genau wissen, welche SQL Server-Komponenten sie installieren wollen und welche nicht. Jeder der oben beschriebenen Installationstypen verlangt im Anfangsstadium einige allgemeine Angaben, wie den Maschinen- und Firmennamen sowie die Produktnummer. Alle diese Angaben müssen in den folgenden Installationsschritten angegeben werden. Abgesehen von diesen allgemeinen Schritten laufen manche Installationstypen eher automatisch ab (wie z.B.die Standardinstallation), während für die anderen (wie benutzerdefinierte Installation) mehrere Eingaben notwendig sind. Der letzte Schritt der Standardinstallation ist die Auswahl der Kennung für den SQL Server und den SQL Server Agent (siehe Abbildung 17.8). Sowohl der SQL Server als auch der SQL Server Agent können bei Windows NT/ 2000 entweder eine lokale oder eine Domänenkennung benutzen. Standardmäßig wird eine Domänenkennung verwendet, die dem System erlaubt mit den verschiedenen im Netz befindlichen Datenbank-Servern zu kommunizieren und solche Operationen durchzuführen, die mehrere Rechner umfassen (wie z.B. Datenreplikation). In demselben Schritt wird auch die Auswahl des Startmodus für den SQL Server und den SQL Server Agent durchgeführt. In der benutzerdefinierten Installation ist es möglich die Autostart-Option zu wählen und dadurch den Startmodus für den SQL Server und den SQL Server Agent zu ändern. (Standardmäßig werden beide Dienste manuell gestartet.)
17.2.2
Die Installation von Client-Komponenten
Die Installation der Client-Software empfiehlt sich auf den Rechnern, die ausschließlich als Clients verwendet werden. Diese Software kann sowohl auf Rechnern mit Windows NT/2000 bzw. Windows 9x installiert werden. Die Installation kann entweder direkt von der SQL Server CD-ROM oder von der Platte (nach dem die Software dorthin kopiert wurde) durchgeführt werden. (Die Voraussetzung für die Installation der Client-Software auf den Rechnern mit dem Betriebssystem Windows 9x ist die Existenz der autoexec.bat-Datei.)
378
Die Installation eines SQL Server-Systems Abbildung 17.8: Das DienstkontenMenü
Für die Installation der Client-Komponenten müssen in der Installationsphase die Option Nur Clienttools (siehe Abbildung 17.5) im Dialogfenster ausgewählt und danach die einzelnen Komponenten markiert werden.
17.2.3
Versionsumstellung
Im allgemeinen kann man sagen, daß die Versionsumstellung wesentlich komplexer als eine Neuinstallation ist. Bevor die Versionsumstellung gestartet wird, empfiehlt sich dringend alle SQL Server 7 bzw. 6.x-Datenbanken zu archivieren. (Das dient der Vorbeugung der möglichen Probleme, die nach der Versionsumstellung auftreten können.) Die Umstellung von SQL Server 4.2-Datenbanken ist mit dem SQL Server 2000 nicht möglich. Der SQL Server 4.2 muß zuerst auf SQL Server 6.x umgestellt werden. Die Versionsumstellung wird generell mit dem Aktualisierungs-Assistenten durchgeführt. 17.2.3.1
Umstellung von Version 6.x mit Hilfe des SQL Server Aktualisierungs-Assistenten
Der SQL Server Aktualisierungs-Assistent dient u.a. zur Übertragung der Server-Komponenten und der Datenbanken von einem SQL Server 6.x- zu dem auf dem Host-Rechner installierten SQL Server 2000-System. Um den Assistenten zu starten muß die gleichnamige Schaltfläche in der SQL Server-Versionsumstellung-Menüfunktion angeklickt werden.
379
Die Planung und die Ausführung der Systeminstallation
Die Versionsumstellung entfernt nicht das SQL Server Version 6.x-System von Ihrem Rechner. Das heißt, daß diese Version nach der Installation des SQL Server 2000 parallel zu dem neuen Datenbank-Server existiert. Diese Tatsache ist wichtig zu wissen, wegen des zusätzlichen Speicherplatzes, der notwendig ist. Im ersten Schritt werden die Datenübertragungsmethode und die Prüfung der Übertragung (optional) gewählt. (Der Standardwert für die Datenübertragungsmethode ist Named Pipe.) Im zweiten Schritt wird der Name des Export-Server (d.h. des SQL Server 6.x-Systems) und des Import-Servers (d.h. des SQL Server 2000-Systems) festgelegt. (Der Export-Server kann auch auf einem anderen im Netz befindlichen Rechner liegen.) Bei diesem Schritt wird auch das Kennwort des Systemadministrators auf den beiden Rechnern festgelegt. Im nächsten Schritt werden alle 6.x-Datenbanken, die umgestellt werden sollen, ausgewählt und diejenigen, die nicht umgestellt werden explizit in einer separaten Liste aufgeführt. Danach werden die zu transferierenden Objekte ausgewählt. Zu den Objekten gehören: 왘 Server-Konfiguration, die die Server-Konfigurationsoptionen und Login-
Id umfaßt (siehe Kapitel 12) 왘 Datenreplikationsangaben (Für die Beschreibung der Datenreplikation
siehe Kapitel 25.) 왘 SQL Executive-Angaben (Diese Angaben ermöglichen den Transfer aller
Server-Aufträge bezüglich der SQL Executive-Komponente zu der entsprechenden Komponente des SQL Servers namens SQL Server Agent.) Schließlich wird das Verhalten der NULL-Werte und die Verwendung von Anführungszeichen als Zeichenkettenbegrenzer festgelegt. (Die beiden Begriffe sind in Kapitel 2 ausführlich beschrieben.) 17.2.3.2
Umstellung von Version 7 mit Hilfe des SQL Server Aktualisierungs-Assistenten
Die Umstellung von Version 7 wird mit Hilfe der SQL Server CD-ROM durchgeführt. Sie verläuft zuerst wie die Installation einer neuen SQL Server 2000-Version. Für die Umstellung muß im Schritt Installationsauswahl (siehe Abbildung 17.4) die Option Eine vorhandene Instanz von SQL Server aktualisieren ausgewählt werden. Der Umstellungsprozeß wird durch die Zustimmung zur Umstellung der Programme weitergeführt. (Alle anderen Schritte entsprechen den schon beschriebenen Schritten in diesem Kapitel.)
380
Administrationsaufgaben nach der Installation
17.3 Administrationsaufgaben nach der Installation Nach der Installation des SQL Servers muß der Systemadministrator einige Arbeiten durchführen, bevor Anwender das System benutzen können. Zu diesen gehören: 왘 die Erstellung der Server-Gruppen und die Registrierung des installier-
ten Servers 왘 die Zuweisung eines Kennwortes der sa-Kennung 왘 das Setzen verschiedener Server-Optionen.
17.3.1
Die Erstellung der Server-Gruppen und die Registrierung des Servers
Der SQL Server kann eine oder mehrere Server-Gruppen enthalten. Eine Server-Gruppe ist eine Sammlung von SQL Server-Systemen, die zusammengefaßt werden, um die Organisationsstruktur eines Unternehmens oder einer Abteilung darzustellen. Gleich nach der Installation existiert eine Standard-Server-Gruppe namens SQL Server Group. Weitere Gruppen können mit Hilfe des Enterprise Managers erstellt werden, indem die Funktion Neue SQL Server-Gruppe im Menü Vorgang ausgewählt wird. Danach erscheint das Dialogfeld ServerGruppen (Abbildung 17.9), in das die neue Gruppe eingegeben werden kann. (Gruppennamen müssen eindeutig sein.) Abbildung 17.9: Das Dialogfeld Server-Gruppen
381
Die Planung und die Ausführung der Systeminstallation
Die Registrierung eines SQL Servers ist unbedingt notwendig, damit dieser durch den SQL Enterprise Manager verwaltet werden kann. Durch die Registrierung wird dem SQL Enterprise Manager der Servername bekanntgemacht. Zusätzlich dazu wird festgelegt, zu welcher Server-Gruppe der installierte Server gehört. Wenn der Enterprise Manager zum ersten Mal aufgerufen wird, wird der lokale Server automatisch registriert. Weitere Server können entweder mit Hilfe des SQL Server-Registrierungs-Assistenten oder mit Hilfe des Dialogfeldes Registrierter SQL Server registriert werden. (Um dieses Dialogfeld aufzurufen, muß die Funktion Neue SQL Server-Registrierung im Menü Vorgang aufgerufen werden.) Bei der Registrierung eines Servers muß folgendes angegeben werden: 왘 der Name des Servers 왘 der Typ der Authentifizierung (Falls die SQL Server-Authentifizierung
ausgewählt wird, müssen zusätzlich die Benutzerkennung und das entsprechende Kennwort spezifiziert werden.)
17.3.2
Die Zuweisung eines Kennwortes der saKennung
Die Zuweisung des Kennwortes der sa-Login-ID ist nur dann erforderlich, falls für den SQL Server nicht die Windows-Authentifizierung ausgewählt wurde. (Für die Definition aller Authentifizierungstypen siehe Kapitel 12.) Direkt nach der Installation des SQL Servers existiert kein Kennwort für die sa-Login-ID. Weil der Benutzer, der diese Login-ID verwenden kann, praktisch uneingeschränkten Zugriff auf das SQL Server-System hat, ist es dringend zu empfehlen, gleich nach der Installation ein Kennwort zuzuweisen. Die Zuweisung eines Kennwortes der sa-Login-ID wird am einfachsten mit Hilfe des SQL Enterprise Managers durchgeführt. Nach dem Aufruf dieser Komponente muß der Name des Servers, für den das sa-Kennwort zugewiesen werden soll, ausgewählt werden. Im Ordner Sicherheit des ausgewählten Servers muß der zweite Ordner Benutzernamen und danach (mit der rechten Maustaste) die sa-Login-ID angeklickt und die Funktion Eigenschaften ausgewählt werden. Im Dialogfeld SQL Server Anmeldungseigenschaften wird das neue Kennwort angegeben. (Die Systemprozedur sp_password kann auch für die Zuweisung des Kennwortes für eine beliebige Login-ID verwendet werden.) Durch die Angabe des Kennwortes, das im nachfolgenden Dialogfeld bestätigt werden muß, wird ein gültiges sa-Kennwort zugewiesen. Vergessen Sie das sa-Kennwort Ihres Systems nicht! Der Zugang zum System ist nur mit diesem Kennwort möglich. Sonst müssen Sie das System neu installieren.
382
Administrationsaufgaben nach der Installation
17.3.3
Server-Optionen setzen
Eine der wichtigsten Eigenschaften des SQL Servers 2000 ist, daß das System selbst viele Administrationsaufgaben automatisch ausführt. Dies bezieht sich auch auf das Setzen der Server-Optionen. Falls die Standardwerte für Ihr System nicht optimal sind, kann die Änderung der Werte durch das Anklicken des Servers (mit der rechten Maustaste) und die Auswahl der Funktion Eigenschaften durchgeführt werden. Die Registerkarte Allgemein des Dialogfeldes SQL Server Eigenschaften (Abbildung 17.10) bietet die Möglichkeit, die Einstellung für das Starten des SQL Servers, SQL Server Agent und MSDTC zu wählen (automatisch oder manuell). Abbildung 17.10: Das Dialogfeld SQL Server Eigenschaften
383
Die Planung und die Ausführung der Systeminstallation
17.4 Das Starten und Stoppen des SQL Server-Systems Das Starten des SQL Servers kann entweder automatisch oder mit Hilfe einer der SQL Server-Komponenten bzw. -Kommandos durchgeführt werden. Falls der Systemadministrator bei der Installation des SQL Servers die Option für das automatische Starten des SQL Servers beim Hochfahren des Betriebssystems ausgewählt hat, wird der SQL Server zusammen mit Windows NT/2000 bzw. Windows 9x automatisch gestartet. Das Starten, Anhalten bzw. Stoppen des SQL Servers kann auch mit Hilfe: 왘 des SQL Server Dienst-Managers, 왘 des Enterprise Managers, 왘 der Windows-Dienste, 왘 des sqlservr-Kommandos und 왘 des net start-Kommandos
durchgeführt werden. Falls der Dienst-Manager für das Starten bzw. Stoppen des SQL Server-Systems verwendet wird, erscheint nach dem Anklicken der entsprechenden Komponente das in Abbildung 17.11 gezeigte Bild. (Um den Dienst-Manager zu öffnen, muß in der SQL Server-Programmgruppe die gleichnamige Funktion angeklickt werden.) Im Feld Dienste muß die Angabe SQLServer ausgewählt werden. (Dementsprechend können die zwei anderen Dienste – SQLServerAgent und MSDTC – durch Ihre Auswahl gestartet bzw. gestoppt werden.) Die Ampel zeigt den augenblicklichen Stand des SQL Servers. Falls ein laufender Server gestoppt werden soll, muß das rote Ampellicht angeklickt werden. Dementsprechend muß ein gestoppter SQL Server durch das Anklicken des grünen Lichts wieder gestartet werden. Das Anklicken des gelben Lichts läßt die existierenden Prozesse weiterlaufen, hindert aber neue Benutzer am Einloggen in das SQL Server-System. Abbildung 17.11: Der DienstManager
384
Zusammenfassung
Das Starten bzw. Stoppen des SQL Servers mit Hilfe der Windows NT/2000Dienste funktioniert anders. In diesem Fall muß der Systemadministrator die Funktion Dienste in der Programmgruppe Systemsteuerung anklicken und anschließend den SQL Server (MSSQLServer) auswählen. Die Angaben neben MSSQLServer zeigen, ob der Server läuft und in welchem Modus das Starten erfolgt (automatisch bzw. manuell). Durch die Auswahl der entsprechenden Schaltfläche (»Starten«, »Beenden«, »Anhalten«) kann das System gestartet, gestoppt oder angehalten werden. Mit dem Kommando sqlservr options_liste
kann ausschließlich der SQL Server gestartet werden. options_liste enthält mögliche Optionen, die in der Tabelle 17.2 beschrieben sind: Option
Beschreibung
-c
Startet den SQL Server unabhängig von Windows NT/2000-Diensten;
-d
Gibt den absoluten Pfadnamen für das master-Datenbankmedium an;
-e
Gibt den absoluten Pfadnamen für die Fehlerprotokolldatei an;
-r
Gibt den absoluten Pfadnamen des gespiegelten Mediums an.
Tabelle 17.1: Mögliche Optionen für das sqlservrKommando
Mit dem net start-Kommando wird auch der SQL Server von der Betriebssystemebene gestartet. Beispiel 17.1
net start mssqlserver
Mit dem net start-Kommando in Beispiel 17.1 wird der SQL Server gestartet.
17.5 Zusammenfassung Die Installation eines SQL Servers hat zusätzlich noch zwei Phasen: die Präund die Postinstallationsphase. In der Präinstallationsphase müssen einige Voraussetzungen (existierendes Netzwerkprotokoll usw.) ermittelt werden. Die Installationsphase erfolgt direkt danach. Die Postinstallationsphase enthält folgende Schritte: 왘 die Erstellung der Server-Gruppen und die Registrierung des installier-
ten Servers 왘 die Zuweisung eines Kennwortes der sa-Kennung 왘 das (optionale) Setzen verschiedener Server-Optionen.
385
18
Das Verwalten der Systemressourcen
In diesem Kapitel wird gezeigt, wie der SQL Server Daten speichert und wie sie vom Systemadministrator verwaltet werden. Folgende Systemadministrationsaufgaben sind Teil des Datenmanagements: 왘 Verwaltung von Dateigruppen 왘 Verwaltung von Datenbanken 왘 Verwaltung des Transaktionsprotokolls.
18.1 Verwaltung von Dateigruppen Wie wir in Kapitel 15 schon beschrieben haben, verwendet der SQL Server 8 K große Blöcke, um Daten zu speichern. Diese Blöcke heißen physikalische Seiten. Bei der Erstellung einer Tabelle bzw. eines Index verwendet der SQL Server acht nebeneinander liegende physikalische Seiten, die extent heißen. extents werden für die Speicherung von Tabellen bzw. Indizes benutzt. (Ein extent kann von mehreren Tabellen bzw. Indizes verwendet werden.) Alle Datenbanken haben eine primäre Datei, die implizit mit dem Suffix ».mdf«spezifiziert wird. Zusätzlich kann eine Datenbank eine oder mehrere sekundäre Dateien haben, die mit dem Suffix ».ndf«spezifiziert werden. Genauso existieren eine oder mehrere Transaktionsprotokolle einer Datenbank, die das Suffix ».ldf« haben. (Alle drei Suffixe sind Standardwerte, können aber geändert werden.) Alle für die Speicherung der Datenbanken und Transaktionsprotokolle verwendeten Dateien haben zwei Namen: einen physikalischen und einen logischen. Der physikalische Name stellt den Datennamen dar, der vom Betriebssystem verwendet wird, während der logische Name vom SQL ServerSystem benutzt wird. Eine Sammlung von Dateien, die auf einer Platte liegen, können zu einer Dateigruppe zusammengefaßt werden. Verschiedene Tabellen oder Indizes können innerhalb einer solchen Gruppe gespeichert werden. Der SQL Server unterstützt drei unterschiedliche Typen von Dateigruppen: 왘 primäre 왘 benutzerdefinierte 왘 standardmäßige
Die primäre Dateigruppe wird implizit vom System bei der Erstellung der Datenbank, zu der die Gruppe gehört, erstellt. Alle Systemtabellen der Datenbank werden in ihrer primären Dateigruppe gespeichert, während eine
387
Das Verwalten der Systemressourcen
Benutzertabelle entweder in der primären oder in einer benutzerdefinierten Dateigruppe gespeichert werden kann. Mit anderen Worten, jede Benutzertabelle bzw. jeder Index wird in der primären Dateigruppe gespeichert, falls sie explizit einer anderen Dateigruppe nicht zugeordnet wird. (Die primäre Dateigruppe ist auch Standarddateigruppe jeder Datenbank. Der Systemadministrator oder der Datenbankeigentümer können die Standarddateigruppe mit Hilfe der ALTER DATABASE-Anweisung ändern.) Eine benutzerdefinierte Dateigruppe muß explizit vom Systemadministrator definiert und anschließend mit Hilfe der CREATE DATABASE- bzw. ALTER DATABASE-Anweisung der entsprechenden Datenbank zugewiesen werden. (Eine Datei kann höchstens einer Dateigruppe angehören.) Für die primäre Dateigruppe ist es sehr wichtig, genügend Speicherplatz zuzuweisen. Falls diese Gruppe keinen Speicherplatz mehr zur Verfügung hat, kann keine Systeminformation dem Datenbankkatalog hinzugefügt werden. (Falls eine benutzerdefinierte Dateigruppe keinen Speicherplatz mehr zur Verfügung hat, sind nur die Daten dadurch betroffen, die in einzelnen Dateien der Dateigruppe gespeichert sind.
18.1.1
Dateigruppen sichten
Alle Dateigruppen einer Datenbank können mit Hilfe: 왘 des Enterprise Managers 왘 der Systemprozedur sp_helpfilegroup
gesichtet werden. Um die Dateigruppen einer Datenbank mit Hilfe des Enterprise Managers zu sichten, muß die Datenbank (mit der rechten Maustaste) angeklickt und die Funktion Eigenschaften ausgewählt werden. In dem Dialogfeld Datenbankeigenschaften (siehe Abbildung 18.1) werden alle Dateigruppen der Datenbank mit allen Dateien dargestellt. Die Systemprozedur sp_helpfilegroup gibt die angegebene Dateigruppe mit allen dazugehörigen Dateien (mit Namen und Größe) aus. Falls kein Name angegeben ist, werden die Eigenschaften aller Dateigruppen der aktuellen Datenbank ausgegeben, wenn man die Registerkarte Dateigruppen anklickt.
18.1.2
Dateien sichten
Alle Dateien einer Datenbank können mit Hilfe: 왘 des Enterprise Managers 왘 der Systemprozedur sp_helpfile
gesichtet werden.
388
Datenbanken verwalten Abbildung 18.1: Die Eigenschaften der Dateigruppen der Beispieldatenbank
Das Sichten der Dateien einer Datenbank mit Hilfe des Enterprise Managers wird wie das Sichten der Dateigruppen durchgeführt (siehe den vorherigen Unterabschnitt und Abbildung 18.1). Die Systemprozedur sp_helpfile liefert den physikalischen und den logischen Namen, sowie weitere Attribute aller Dateien, die zu der aktuellen Datenbank gehören.
18.2 Datenbanken verwalten Eine Datenbank ist eine logisch zusammenhängende Sammlung von Daten, die einem gewissen Zweck dienen. Jede Datenbank enthält weitere Objekte wie Tabellen, Indizes, Trigger, Datenbankprozeduren usw. Die Verwaltung einer Datenbank beinhaltet folgende Aufgaben: 왘 Datenbank erstellen 왘 Datenbankoptionen sichten bzw. ändern 왘 Datenbankstruktur ändern 왘 Datenbank löschen.
389
Das Verwalten der Systemressourcen
18.2.1
Datenbank erstellen
Kapitel 4 behandelt die Erstellung von Datenbanken mit Hilfe der CREATE DATABASE-Anweisung und des Datenbankerstellungs-Assistenten. Eine weitere Möglichkeit Datenbanken zu erstellen bietet der Enterprise Manager. In diesem Fall muß der Ordner Datenbanken (mit der rechten Maustaste) angeklickt und die Funktion Neue Datenbank ausgewählt werden. Das Dialogfeld Datenbankeigenschaften erscheint. Die einzige Angabe, die unbedingt angegeben werden muß, ist der Datenbankname. Das Kontrollkästchen Datei automatisch vergrößern muß markiert werden, falls die Größe des Speichers, der der Datenbank zur Verfügung stehen wird, dynamisch vom SQL Server verwaltet werden soll. (Andererseits können die Daten der Datenbank nur im festgelegten Speicher, der Datei zur Verfügung steht, gespeichert werden.) Falls das Kontrollkästchen Datei automatisch vergrößern markiert ist, kann entweder In Megabyte oder In Prozent ausgewählt werden. Die erste Alternative spezifiziert wieviel MB Speicherplatz jedesmal vom Datenbanksystem bei der dynamischen Vergrößerung der Datei in Anspruch genommen wird, während die zweite eine prozentuale Vergrößerung zuläßt. Die anderen beiden Auswahlknöpfe Unbeschränkt vergrößerbar und Beschränkt auf (MB) spezifizieren, ob die Dateigröße unbeschränkt oder nicht wachsen kann. (Die Angabe Unbeschränkt vergrößerbar entspricht dem Wert UNLIMITED der Option FILEGROWTH der CREATE DATABASE-Anweisung.) Die master-Datenbank sollte jedesmal nach der Erstellung einer Datenbank archiviert werden.
18.2.2
Datenbankoptionen sichten bzw. ändern
Nach der Erstellung der Datenbank werden alle Datenbankoptionen vom System gesetzt. Die Datenbankoptionen können mit Hilfe: 왘 des SQL Enterprise Managers 왘 der Systemprozedur sp_dboption 왘 der ALTER DATABASE-Anweisung
gesichtet bzw. geändert werden. Zusätzlich dazu kann die DATABASEPROPERTYEX-Funktion verwendet werden, um alle Datenbankoptionen zu sichten. Der Enterprise Manager ermöglicht das Setzen von ausgewählten Optionen, während die Systempozedur sp_dboption die Änderung aller Optionen erlaubt.
390
Datenbanken verwalten
Um die Datenbankoptionen mit Hilfe des Enterprise Managers zu sichten bzw. zu modifizieren muß der Name der Datenbank (mit der rechten Maustaste) angeklickt und die Funktion Eigenschaften ausgewählt werden. Anschließend wird im Dialogfeld Datenbankeigenschaften die Registerkarte Optionen (Abbildung 18.2) ausgewählt. Tabelle 18.1 listet alle Datenbankoptionen mit ihrer Beschreibung auf. Abbildung 18.2: Datenbankoptionen
Datenbankoption
Beschreibung
Zugriff einschränken (Mitglieder von db_owner, dbcreator oder sysadmin)
Falls diese Option aktiviert wird, dürfen nur die Mitglieder der aufgelisteten Rollen (db_owner, dbcreator und sysadmin) auf die Datenbank zugreifen. Die Benutzer, die sich vor der Änderung der Option eingeloggt haben und diese Datenbank verwenden, können mit ihr weiterarbeiten. Standardmäßig wird diese Option bei der Erstellung einer Datenbank nicht aktiviert.
Tabelle 18.1: Datenbankoptionen
391
Das Verwalten der Systemressourcen
392
Datenbankoption
Beschreibung
Zugriff einschränken (Einzelbenutzermodus)
Das Aktivieren dieser Option (englisch: Single User) beschränkt die Benutzung der Datenbank auf einen einzelnen Benutzer. (Die zum Zeitpunkt der Aktivierung dieser Option angemeldeten Benutzer können weiter die Datenbank verwenden.) Ein neuer Benutzer wird erst dann eine Verbindung zur Datenbank herstellen können, wenn alle angemeldeten Benutzer ihre Verbindung zur Datenbank beenden.
Schreibgeschützt
Mit der Option »Schreibgeschützt« (englisch: read only) können Daten einer Datenbank von den Benutzern nur gelesen werden. Standardmäßig ist diese Option nicht aktiviert.
Wiederherstellung
Diese Option beschreibt den Typ der Wiederherstellung. Alle drei Wiederherstellungstypen werden in Kapitel 20 beschrieben.
ANSI NULL ist Standard
Diese Option (englisch: ANSI NULL default) beeinflußt die Definition einzelner Tabellenspalten, die ohne explizite Angabe (NULL bzw. NOT NULL) definiert sind. Falls diese Option aktiviert wird, wird allen solchen Spalten die NULL-Angabe zugewiesen, was dem SQL-Standard entspricht. Der SQL Server weist solchen Spalten standardmäßig NOT NULL zu. Der Benutzer hat durch die Aktivierung dieser Option die Möglichkeit, Spalten ohne explizite NULL-Angabe entsprechend dem SQL-Standard zu behandeln (siehe Beispiel 18.1).
Rekursive Trigger
Falls diese Option aktiviert ist, können Trigger, die andere Trigger aufrufen, implementiert werden (siehe auch Kapitel 14).
Statistiken automatisch aktualisieren
Falls diese Option aktiviert ist, werden Statistiken (unabhängig von der expliziten Ausführung der UPDATE STATISTICS-Anweisung) in regelmäßigen Abständen aktualisiert.
Erkennung von zerissenen Seiten
Falls diese Option aktiviert ist, werden unvollständig beschriebene physikalische Seiten vom System erkannt.
Automatisch schließen
Falls diese Option aktiviert ist, wird die Datenbank heruntergefahren, wenn der letzte Benutzer seine Anwendung beendet hat.
Automatisch verkleinern
Falls eine Datenbank freien Speicherplatz aufweist, wird dieser freigegeben (siehe auch die Beschreibung der DBCC SHRINKDATABASE-Anweisung später in diesem Kapitel.)
Bezeichner in Anführungszeichen verwenden
Für Bezeichner können sowohl Apostrophe als auch Anführungszeichen verwendet werden (siehe Kapitel 3).
Datenbanken verwalten Beispiel 18.1
create table test (nummer integer)
Beispiel 18.1 zeigt zwei verschiedene Verhalten, abhängig davon, ob die Option »ANSI NULL ist Standard« aktiviert ist oder nicht. Falls diese Option nicht aktiviert ist, wird die Spalte nummer NULL-Werte nicht zulassen. Im anderen Fall (ANSI entsprechend) wird diese Spalte NULL-Werte erlauben. Bei der Erstellung einer neuen Datenbank ist es empfehlenswert, die Option »ANSI NULL ist Standard« zu aktivieren, weil dadurch die neue Datenbank dem SQL-Standard in diesem Punkt entsprechen wird. Das Sichten und die Änderung der Datenbankoptionen kann alternativ mit der Systemprozedur sp_dboption [db_name, option, {TRUE|FALSE}]
durchgeführt werden. Diese Prozedur hat dieselben Optionen wie die SQL Enterprise Manager-Komponente, diese Optionen müssen aber in englischer Sprache geschrieben werden. Falls die Systemprozedur sp_dboption ohne irgendwelche Angaben ausgeführt wird, wird die Liste aller verfügbaren Datenbankoptionen ausgegeben. Beispiel 18.2
sp_dboption beispiel 'read only', TRUE
In Beispiel 18.2 wird die Datenbank beispiel nur für die Leseoperationen zugelassen. Bei der Angabe des Optionsnamens kann man jeden Teil des Optionsnamens, der die Option eindeutig identifiziert, eingeben (z.B. ›read‹ anstatt ›read only‹). Die Systemprozedur sp_dboption wird als depracate feature im SQL Server 2000 gekennzeichnet. Das heißt, daß sie in einer der nachfolgenden Versionen nicht mehr unterstützt wird. 18.2.2.1
Die DATABASEPROPERTYEX-Funktion
Die DATABASEPROPERTYEX-Funktion gibt den aktuellen Wert der spezifizierten Option bzw. Datenbankeigenschaft aus. Die Syntax dieser Funktion ist: DATABASEPROPERTYEX (db_name, eigenschaft) eigenschaft legt den Namen der Eigenschaft fest, deren Werte zurückgegeben werden sollen. In den meisten Fällen ist der Rückgabewert entweder 1 (richtig), 0 (falsch) oder NULL (falsche Eingabe). Tabelle 18.2 zeigt die Liste der ausgewählten Eigenschaften mit ihrer Beschreibung.
393
Das Verwalten der Systemressourcen Tabelle 18.2: Eigenschaften der DATABASEPROPERTYEXFunktion
Eigenschaft
Beschreibung
IsAnsiNullDefault
Gibt den Wert 1 zurück, falls die Datenbank in bezug auf NULL-Werte ANSI-kompatibel ist. (Siehe auch die Diskussion über die NULL-Werte am Ende des dritten Kapitels.)
IsAnsiNullEnabled
Gibt den Wert 1 zurück, falls alle Vergleiche mit NULL ANSIkompatibel sind.
IsAutoShrink
Gibt den Wert 1 zurück, falls alle zur Datenbank gehörenden Dateien vom System periodisch dahingehend überprüft werden, ob sie verkleinert werden können.
IsAutoCreateStatistics
Gibt den Wert 1 zurück, falls die existierenden Statistiken implizit vom System aktualisiert werden.
IsAutoUpdatedStatistics
Gibt den Wert 1 zurück, falls die automatische Aktualisierung von Statistiken aktiviert ist.
IsNullConcat
Diese Datenbankoption beeinflußt die Konkatenation mit dem NULL-Wert. Sie gibt den Wert 1 zurück, falls eine solche Konkatenation den NULL-Wert liefert.
IsQuotedIdentifiersEnabled
Gibt den Wert 1 zurück, falls Anführungszeichen für die Identifikatoren verwendet werden. (Siehe die Diskussion über die benannten Identifikatoren in Kapitel 3.)
IsInStandby
Gibt den Wert 1 zurück, falls die Datenbank im Nur-LeseModus ist.
Status
Gibt den Status der Datenbank aus. Die möglichen Werte sind: ONLINE, OFFLINE, RESTORING, RECOVERING und SUSPECT.
Updateability
Gibt den Status der Datenbank in bezug auf Datenänderung aus. Die möglichen Werte sind: READ_ONLY (Änderungen nicht erlaubt) and READ_WRITE (Änderungen erlaubt).
18.2.3
Änderung der Datenbankstruktur
Alle administrativen Aufgaben in bezug auf die Änderung der Datenbankstruktur sind seit Version 7 wesentlich leichter durchzuführen als in den vorherigen SQL Server-Versionen. Die einzige Aufgabe, die der Systemadministrator ausführen kann, ist die Vergrößerung bzw. die Verkleinerung der Dateien, die zu einer Datenbank gehören. Die Vergrößerung der Dateien, die einer Datenbank gehören, kann mit Hilfe des Enterprise Managers automatisch durchgeführt werden, indem das Kontrollkästchen Datei automatisch vergrößern im Dialogfeld Datenbankeigenschaften markiert wird. Mit dieser Methode können die administrativen Aufgaben bezüglich der Verwaltung einer Datenbank wesentlich reduziert werden, weil das System selbst die Vergrößerung der Datei(en) übernimmt. (Die Alternative ist, die Angabe FILEGROWTH mit der ALTER DATABASE-Anweisung zu setzen.)
394
Datenbanken verwalten
Die Größe einer Datenbank kann auch geändert werden, wenn ihre Dateien nicht dynamisch wachsen. In diesem Fall können entweder die absolute Größe der existierenden Dateien geändert oder neue Dateien hinzugefügt werden. Die einfachste Methode, die absolute Größe einer Datei zu ändern ist das Kontrollkästchen In Megabyte im Dateivergrößerung-Rahmens zu markieren. Eine neue Datei kann entweder mit Hilfe der ALTER DATABASE-Anweisung oder durch ihre Spezifikation im Dialogfeld Datenbankeigenschaften geändert werden. In beiden Fällen müssen der physikalische und der logische Name, sowie die Größe der Datei angegeben werden. Die Verkleinerung der Datenbank kann entweder durch die Verringerung der Datenbankgröße oder durch die Verkleinerung der Dateien, die der Datenbank gehören, durchgeführt werden. Die ganze Datenbank kann entweder mit Hilfe des Enterprise Managers oder mit der Systemprozedur sp_dboption verkleinert werden. Im ersten Fall müssen die Datenbank (mit der rechten Maustaste) angeklickt und nacheinander die Funktionen Alle Aufgaben und Datenbank verkleinern ausgewählt werden. Im Dialogfeld Datenbank verkleinern muß das Kontrollkästchen Periodisch überprüfen, ob der Datenbank-Festplattenspeicher verkleinert werden kann markiert werden. (Die Alternative ist die Option autoshrink der Systemprozedur sp_dboption auf richtig (true) zu setzen.) Die automatische Verkleinerung einer Datenbank wird jedesmal automatisch durchgeführt, wenn die Datenbank eine gewisse Speichergröße frei hat. Die manuelle Verkleinerung der Datenbank mit Hilfe des Enterprise Managers erfolgt identisch wie die automatische bis auf den letzten Schritt: anstatt das Kontrollkästchen Periodisch überprüfen, ob der Datenbank-Festplattenspeicher verkleinert werden kann müssen das Kontrollkästchen Datenbank verkleinern um (%) markiert und der Prozentsatz angegeben werden. Das DBCC-Kommando kann als Alternative zum Enterprise Manager verwendet werden. Mit Hilfe der DBCC SHRINKDATABASE-Kommandos kann die Verkleinerung einer Datenbank sofort ausgeführt werden. (Die Datenbankgröße wird nach der Ausführung der DBCC-Kommandos nur einmal für den angegeben Prozentsatz verringert, falls überhaupt möglich.) In diesem Fall werden alle Dateien, die zur Datenbank gehören, verringert. (Das DBCC-Kommando mit der Angabe SHRINKFILE wird benutzt, um die Größe einer gewissen Datei zu verringern.) Beispiel 18.2
dbcc shrinkdatabase (beispiel, 20)
In Beispiel 18.2 wird der angegebene Wert (20%) als Zielwert für den freien Speicherplatz verwendet. Die Datenbankgröße wird also nur verringert, wenn zur Verfügung stehender Speicherplatz größer als 20% ist.
395
Das Verwalten der Systemressourcen
Die master-Datenbank sollte jedesmal nach der Änderung der Datenbankstruktur archiviert werden.
18.2.4
Datenbank löschen
Eine Datenbank kann mit Hilfe: 왘 der DROP DATABASE-Anweisung (siehe Kapitel 4) 왘 des SQL Enterprise Managers 왘 der Systemprozedur sp_dbremove
gelöscht werden. Um eine Datenbank mit Hilfe des SQL Enterprise Managers zu löschen, müssen der Ordner Datenbank geöffnet und die zu löschende Datenbank mit der rechten Maustaste angeklickt werden. Nach der Auswahl der Menüfunktion Datenbank löschen und der Bestätigung dieser Operation wird die Datenbank gelöscht. Im Unterschied zu der DROP DATABASE-Anweisung kann mit dem Enterprise Manager nur eine Datenbank zu einem gewissen Zeitpunkt gelöscht werden. Genauso kann eine Datenbank mit der Systemprozedur sp_dbremove db_name
gelöscht werden. Diese Systemprozedur wird nur aus Kompatibilitätsgründen zu den früheren SQL Server-Versionen unterstützt. Generell gilt: Das Löschen der Datenbank bedeutet, daß sie mit allen dazugehörigen Objekten (Tabellen, Trigger, Indizes, Datenbankprozeduren usw.) entfernt wird. Alle Einträge, die über diese Datenbank in der master-Datenbank existieren, werden ebenso entfernt. Das Löschen einer Datenbank kann entweder vom Systemadministrator oder vom Eigentümer dieser Datenbank vorgenommen werden. Die master-Datenbank sollte jedesmal nach dem Löschen einer Datenbank archiviert werden.
18.3 Transaktionsprotokolle verwalten Der SQL Server speichert alle Änderungen, die während einer Transaktion durch Datenmanipulationsanweisungen ausgeführt werden in einer oder mehreren Dateien, die Transaktionsprotokolle heißen. Jede Datenbank eines Systems hat ein eigenes Transaktionsprotokoll. (Für weitere Erläuterungen bezüglich der Transaktionsprotokolle siehe Kapitel 14.)
396
Zusammenfassung
Dateien eines Transaktionsprotokolls werden zu demselben Zeitpunkt wie die Datenbankdateien erstellt. Sie können mit Hilfe des Enterprise Managers oder mit der CREATE DATABASE-Anweisung (siehe Kapitel 4) erstellt werden. Mit dem Enterprise Manager werden die Transaktionsprotokolldateien genauso wie die Datenbankdateien erstellt, bis auf die Auswahl der Registerkarte Transaktionsprotokoll (siehe Abbildung 18.3). Alle Angaben entsprechen den gleichnamigen Angaben, die wir bei der Erstellung der Datenbankdateien erläutert haben. Die Änderung der Transaktionsprotokolldateien kann entweder mit der ALTER DATABASE-Anweisung (siehe Kapitel 4) oder mit dem Enterprise Manager durchgeführt werden. Um Transaktionsprotokolldateien mit Hilfe des Enterprise Managers zu modifizieren (oder zu sichten), muß die Datenbank mit der rechten Maustaste angeklickt und die Funktion Eigenschaften ausgewählt werden. Danach wird im Dialogfeld Datenbankeigenschaften die Registerkarte Transaktionsprotokoll angeklickt. Die Änderung der Transaktionsprotokolldateien wird genauso wie die Änderung der Datenbankdateien behandelt. Die Anfangsgröße des Transaktionsprotokolls muß genau geplant und ihr Zuwachs muß überwacht werden, weil einige Operationen (wie z.B. Laden von Massendaten in einer Tabelle mit vielen Indizes) es sehr schnell auffüllen können. Aus diesem Grund sollte eine Warnung erstellt werden, die den Operator über das Auffüllen des Protokolls (über eine festgelegte Grenze) informiert (siehe Kapitel 22).
18.4 Zusammenfassung Eine der wichtigsten Eigenschaften des SQL Server-Systems ist seine leichte Bedienbarkeit. Im Vergleich mit den vorherigen Versionen ist SQL Server 2000 in bezug auf die Verwaltung von Datenbanken sehr »administrierungsfreundlich«, weil nur ein geringer Teil der früheren Aufgaben vom Systemadministrator durchgeführt werden muß. Fast alle Aufgaben in bezug auf Datenbanken können entweder mit dem Enterprise Manager oder mit den Transact-SQL-Anweisungen CREATE DATABASE und ALTER DATABASE durchgeführt werden. (Für das Sichten von Datenbanken und ihnen zugehörigen Dateien existieren zusätzlich einige wenige Systemprozeduren.) Aufgaben
A.18.1
Wann ist die primäre Dateigruppe gleichzeitig auch die standardmäßige?
A.18.2
Welche Ähnlichkeiten und Unterschiede existieren in der Anwendung der Systemprozedur sp_dboption und der databasepropertyex-Funktion?
397
Das Verwalten der Systemressourcen Abbildung 18.3: Das Dialogfeld Datenbankeigenschaften: Transaktionsprotokoll
398
A.18.3
Welches SQL Server-Werkzeug würden Sie für die Änderung der Datenbankoptionen bevorzugen?
A.18.4
Wie kann man den Zustand einer Datenbank in bezug auf die automatische Verkleinerung zu ihr gehörender Dateien erfahren?
A.18.5
Können Daten einer Datenbank und das zu ihr gehörende Transaktionsprotokol zusammen in eine Datei gespeichert werden?
19
Benutzerverwaltung
In diesem Kapitel werden alle Aspekte der Benutzerverwaltung beim SQL Server erläutert. Nach der allgemeinen Einführung und Erklärung der Differenz zwischen den Begriffen »Login-ID« und »Benutzername« werden unterschiedliche Sicherheitsmodi, die der SQL Server unterstützt, beschrieben. Danach wird der Zugriff auf ein Datenbanksystem erläutert. Am Ende werden Zugriffe auf einzelne Datenbanken bzw. ihre Objekte dargestellt.
19.1 Einführung Die Benutzerverwaltung beim SQL Server bezieht sich auf die Frage, wer das SQL Server-System benutzen darf und welche verschiedenen Möglichkeiten ein im System eingeloggter Benutzer in bezug auf einzelne Datenbanken und ihre Objekte hat. Damit kann die Benutzerverwaltung in drei Teile unterteilt werden: 왘 Verwaltung des Zugriffs auf das Datenbanksystem 왘 Verwaltung des Zugriffs auf einzelne Datenbanken 왘 Verwaltung der Zugriffsberechtigungen.
Jede Aufgabe wird in nachfolgenden Abschnitten separat behandelt. Die erste Aufgabe wird mit Hilfe von Login-ID und die zweite mit Hilfe der Datenbankbenutzernamen realisiert. Die beiden Begriffe: 왘 Login-ID und 왘 Datenbankbenutzername
können mißverstanden werden. Deswegen werden wir ihre Unterschiede hier hervorheben. Ein Anwender, der eine Login-ID für ein SQL Server-System verwendet, kann sich nur in das System einloggen: Dies erlaubt ihm nicht, einzelne Datenbanken des Systems ohne weiteres zu benutzen. Genauso hat ein Anwender mit einem Datenbankbenutzernamen im allgemeinen keinen Zugriff auf das SQL Server-System: Er kann nur diese eine Datenbank und ihre Objekte verwenden. Die Login-ID eines Benutzers kann beim SQL Server mit der Betriebssystemkennung von Windows NT/2000 vereinigt bzw. unabhängig von ihr gehalten werden. Dies hängt vom Sicherheitsmodus des SQL Servers ab.
399
Benutzerverwaltung
Basierend auf Windows- und SQL Server-Authentifizierung (siehe Kapitel 12) existieren beim SQL Server zwei unterschiedliche Modi: 왘 Windows-Modus 왘 Mixed-Modus.
Wenn ein Benutzer die Verbindung zum SQL Server-System im WindowsModus durchführt, wird das Einloggen in das Datenbanksystem mit dem Einloggen in das Betriebssystem vereinigt. Mit anderen Worten, der SQL Server sucht nach der Windows-Kennung in der Liste aller existierenden SQL Server Login-ID: Falls die Login-ID existiert, werden die beiden als identisch betrachtet und der SQL Server führt keine weiteren Überprüfungen durch. (Deswegen heißt diese Art der Verbindung die vertraute Verbindung, weil der SQL Server dem Betriebssystem vertraut, daß es die Validierung der Kennung und des entsprechenden Kennwortes durchführt.) Der Mixed-Modus erlaubt den Benutzern entweder die Windows- oder die beiden Authentifizierungen (Windows und SQL Server) zu verwenden. Das heißt, daß manche Kennungen die Verbindung zum SQL Server-System nur durch das Einloggen auf der Betriebssystemebene herstellen, während andere zusätzlich eine Login-ID für denselben Vorgang brauchen. (Im zweiten Fall überprüft das Datenbanksystem, ob die angegebene Login-ID zu der Liste existierender Login-ID gehört.) Die beiden Modi haben ihre Vor- und Nachteile: Der Windows-Modus weist einen geringeren Administrationsaufwand auf, weil nur Windows-Kennungen und – Gruppen verwaltet werden müssen. Andererseits bietet der Mixed-Modus (falls die beiden Authentifizierungen verwendet werden) erhöhte Sicherheit, weil zwei Sicherheitsebenen (die vom Betriebssystem und die vom Datenbanksystem) existieren. Für Produktionsdatenbanken wird der Mixed-Modus mit den beiden Authentifizierungen dringend empfohlen, weil das Hinzufügen einer zusätzlichen Sicherheitsebene die Datenbanken besser gegen den Mißbrauch schützt. Die Auswahl der beiden Sicherheitsmodi kann mit Hilfe des Enterprise Managers durchgeführt werden. Das Setzen des Windows-Modus erfolgt durch das Anklicken des Servers (mit der rechten Maustaste) und die Auswahl der Funktion Eigenschaften. Im Dialogfeld SQL Server Eigenschaften (Abbildung 19.1) müssen die Registerkarte Sicherheit ausgewählt und das Feld Nur Windows markiert werden. Das Setzen des Mixed-Modus wird ähnlich durchgeführt. Der einzige Unterschied ist, daß das Feld SQL Server und Windows in demselben Dialogfeld markiert werden muß. Der Windows-Modus existiert nicht, falls der SQL Server auf einem Rechner mit Windows 9x läuft.
400
Verwaltung des Zugriffs auf das Datenbanksystem Abbildung 19.1: Das Dialogfeld SQL Server Eigenschaften: Registerkarte Sicherheit
19.2 Verwaltung des Zugriffs auf das Datenbanksystem Nach der Auswahl des Modus wird der Zugriff auf Datenbanken und einzelne Datenbankobjekte einheitlich verwaltet (unabhängig davon, ob der eine oder der andere Modus ausgewählt wurde.)
19.2.1
Das Verwalten von Login-ID
Für Windows-Kennungen und -Gruppen existiert eine Systemprozedur – sp_grantlogin –, mit der eine Benutzerkennung bzw. Benutzergruppe die Verbindung zum SQL Server im Windows-Modus herstellen kann. Falls eine neue Login-ID erstellt werden soll, kann die Systemprozedur sp_addlogin verwendet werden. (Für die Beschreibung dieser beiden sowie ihnen verwandte Systemprozeduren siehe Kapitel 12.) Die Erstellung einer neuen Login-ID mit Hilfe des Enterprise Managers erfolgt durch das Anklicken (mit der linken Maustaste) des Ordners Sicherheit und anschließendem Anklicken (mit der rechten Maustaste) des
401
Benutzerverwaltung
Unterordners Benutzernamen. Nach der Auswahl der Funktion Neuer Benutzername erscheint das in Abbildung 19.2 dargestellte Dialogfeld SQL Server Anmeldungseigenschaften. Im Dialogfeld müssen der neue LoginID-Name und die Art der Authentifizierung eingetragen werden. Zusätzlich können noch die Standarddatenbank und die Standardsprache für die Login-ID spezifiziert werden. (Die Standarddatenbank ist diejenige Datenbank, zu der der Benutzer automatisch die Verbindung nach dem Einloggen hat.) Abbildung 19.2: Das Dialogfeld SQL Server Anmeldungseigenschaften
Eine existierende Login-ID kann mit Hilfe: 왘 des Enterprise Managers 왘 der Systemprozedur sp_droplogin
gelöscht werden. Das Löschen einer Login-ID mit Hilfe des Enterprise Managers erfolgt durch das Anklicken des Ordners Sicherheit und des Unterordners Benutzernamen. Im Detailfenster wird anschließend der zu löschende Name mit der rechten Maustaste angeklickt und die Funktion Löschen ausgewählt. Das Löschen einer Login-ID kann auch mit der Systemprozedur sp_droplogin durchgeführt werden, die in Kapitel 12 beschrieben ist.
402
Verwaltung des Zugriffs auf einzelne Datenbanken
19.3 Verwaltung des Zugriffs auf einzelne Datenbanken Nachdem der Systemadministrator Login-ID für verschiedene Benutzer erzeugt hat, müssen auch Zugriffe auf einzelne Datenbanken geregelt werden. Eine Login-ID ermöglicht nur das Einloggen in das SQL Server-System. Jeder Benutzer, der eine Datenbank des Systems verwenden will, braucht einen Namen, welcher der Datenbank bekannt ist. Dementsprechend muß ein Benutzer einen gültigen Benutzernamen für jede Datenbank, die er verwenden will, haben. (Der Datenbankbenutzername kann mit der Login-ID identisch sein, muß aber nicht.) Die Vergabe des Zugriffs auf eine Datenbank mit Hilfe des Enterprise Managers erfolgt durch das Anklicken des Ordners Datenbanken und die Auswahl (mit der rechten Maustaste) der entsprechenden Datenbank. Danach muß die Funktionsfolge Neu und Datenbankbenutzer ausgewählt werden. Im Dialogfeld Datenbankbenutzer – Eigenschaften (Abbildung 19.3) wird die Login-ID angeklickt und der Benutzername eingetragen. Optional können (zusätzlich zu der public-Rolle, zu der jeder Benutzer automatisch gehört) weitere Datenbankrollen ausgewählt werden. (Die alternative Methode ist, die Systemprozedur sp_grantdbaccess, die in Kapitel 12 beschrieben ist, zu benutzen.) Abbildung 19.3: Das Dialogfeld Datenbankbenutzer –Eigenschaften
403
Benutzerverwaltung
19.3.1
Rollen
Neben Login-ID sind Rollen weitere Mechanismen, die einem Benutzer den Zugriff auf einzelne Datenbanken ermöglichen. Eine Rolle ist eine Sammlung einzelner Mitglieder. (Ein Mitglied einer Rolle kann eine Windows-Benutzerkennung oder eine Login-ID sein.) Jedes Mitglied, das einer Rolle angehört, enthält im allgemeinen die Zugriffsberechtigungen, die für diese Rolle gelten. Damit kann der Systemadministrator die Verwaltung der Benutzerkennungen wesentlich vereinfachen, indem er die Zugriffsberechtigungen global der Rolle vergibt bzw. entzieht. Rollen ersetzen die Benutzergruppen, die von den SQL Server-Versionen < 7 unterstützt wurden. Der SQL Server 2000 unterstützt vier Arten von Rollen: 왘 Server-Rollen 왘 Datenbankrollen 왘 benutzerdefinierte Rollen 왘 Applikations-Rollen
19.3.1.1
Hinzufügen einer Login-ID in eine Server- bzw. Datenbankrolle
Der Enterprise Manager kann benutzt werden, um eine Login-ID bzw. eine Windows-Benutzerkennung einer Server- oder einer Datenbankrolle hinzuzufügen. Die Zuweisung einer Login-ID in eine Server-Rolle erfolgt durch die Auswahl des Ordners Sicherheit und Unterordners Serverrollen. Im Detailfenster wird die entsprechende Rolle mit der rechten Maustaste angeklickt und die Funktion Eigenschaften ausgewählt. Im Dialogfeld Serverrolle – Eigenschaften (Abbildung 19.4) werden durch das Anklicken der Schaltfläche Hinzufügen eine oder mehrere Login-ID ausgewählt und damit der Server-Rolle hinzugefügt. (Mit der Systemprozedur sp_addsrvrolemember, die in Kapitel 12 beschrieben ist, können auch eine oder mehrere Login-ID einer Server-Rolle hinzugefügt werden.) Das Hinzufügen einer Login-ID bzw. einer Windows-Kennung in eine Datenbankrolle erfolgt durch die Auswahl des Ordners Datenbanken und das Anklicken der gewünschten Datenbank. Danach werden der Ordner Rollen ausgewählt und die entsprechende Datenbankrolle im Detailfenster mit der rechten Maustaste angeklickt. Nach der Auswahl der Funktion Eigenschaften erscheint das Dialogfeld Datenbankrolle – Eigenschaften (Abbildung 19.5). Mit der Schaltfläche Hinzufügen können weitere Login-ID hinzugefügt werden. (Die alternative Methode stellt die Verwendung der Systemprozedur sp_addrolemember dar, die in Kapitel 12 beschrieben ist.)
404
Verwaltung des Zugriffs auf einzelne Datenbanken Abbildung 19.4: Das Dialogfeld Serverrolle – Eigenschaften
Abbildung 19.5: Das Dialogfeld Datenbankrolle – Eigenschaften
Die Listen der Server- und Datenbankrollen sind fix, d.h. weder können existierende Server- bzw. Datenbankrollen entfernt noch neue hinzugefügt werden.
405
Benutzerverwaltung
19.3.1.2
Benutzerdefinierte Rollen verwalten
Die Erstellung einer benutzerdefinierten Rolle mit Hilfe des Enterprise Managers erfolgt durch die Auswahl des Ordners Datenbanken und das Anklicken der gewünschten Datenbank. Danach werden der Ordner Rollen mit der rechten Maustaste angeklickt und die Funktion Neue Datenbankrolle ausgewählt. Das Dialogfeld Datenbankrolle – Eigenschaften erscheint (Abbildung 19.6). Durch den Eintrag des Namens der benutzerdefinierten Rolle und das Anklicken der Funktion Hinzufügen kann die neue Rolle mit allen ihren Mitgliedern erstellt werden. (Als Alternative kann die Systemprozedur sp_addrole verwendet werden, die in Kapitel 12 beschrieben ist.) Abbildung 19.6: Das Dialogfeld Datenbankrolle – Eigenschaften
Das Hinzufügen neuer Mitglieder einer existierenden benutzerdefinierten Rolle mit Hilfe des Enterprise Managers erfolgt genauso wie das Hinzufügen neuer Mitglieder einer Datenbankrolle. 19.3.1.3
Die Erstellung von Applikationsrollen
Die Erstellung einer Applikationsrolle mit Hilfe des Enterprise Managers erfolgt durch die Auswahl des Ordners Datenbanken und das Anklicken der gewünschten Datenbank. Danach werden der Ordner Rollen mit der rechten Maustaste angeklickt und die Funktion Neue Datenbankrolle ausgewählt. Das Dialogfeld Datenbankrolle – Eigenschaften erscheint. Durch den Eintrag des Namens der Applikationsrolle und des entsprechenden Kennwortes wird die neue Rolle erstellt. (Damit das System die neue Rolle
406
Zugriffsberechtigungen verwalten
als Applikationsrolle registriert, muß Anwendungsrolle im unteren Teil des Dialogfeldes markiert werden. Als Alternative kann die Systemprozedur sp_addapprole verwendet werden, die in Kapitel 12 beschrieben ist.)
19.4 Zugriffsberechtigungen verwalten Nach der Erstellung der Benutzernamen für jede einzelne Datenbank muß der Datenbankeigentümer spezifische Berechtigungen in bezug auf die Datenbank erstellen. Abhängig von ihrem Typ können Zugriffsberechtigungen beim SQL Server in zwei Gruppen unterteilt werden: 왘 Objektberechtigungen 왘 Anweisungsberechtigungen
Objektberechtigungen besagen, wer von den Benutzern welche Rechte in bezug auf folgende Datenbankobjekte: 왘 Tabellen, 왘 Spalten, 왘 Views und 왘 Datenbankprozeduren
hat. Die Anweisungsberechtigungen beziehen sich auf unterschiedliche Rechte, die der Systemadministrator bzw. der Datenbankeigentümer den einzelnen Benutzern, die Objekte einer Datenbank erstellen sollen, zuweisen. Jede Berechtigung kann sich in einem der drei unterschiedlichen Zuständen befinden: 왘 vergeben (oder positive Berechtigung) 왘 verweigert (oder negative Berechtigung) 왘 keine
Ein Datenbankbenutzer kann alle Operationen in einer Datenbank ausführen, die für ihn vergeben wurden. In diesem Fall existieren entsprechende Einträge in der Systemtabelle sysprotects der jeweiligen Datenbank. Ein negativer Eintrag in derselben Systemtabelle verwehrt die Verwendung der Berechtigung für den jeweiligen Benutzer. Dieser Eintrag überschreibt die Zugriffsberechtigung, die der Benutzer explizit oder implizit (durch die Zugehörigkeit zu einer Rolle, der dieses Recht vergeben wurde) hat, und hindert ihn daran, die Berechtigung zu verwenden. Beim letzten Zustand (keine Berechtigung) hat der Benutzer keine explizite Berechtigung, kann diese aber trotzdem implizit erwerben (durch die Zugehörigkeit zu einer Rolle, die dieses Recht hat).
407
Benutzerverwaltung
19.4.1
Objektberechtigungen verwalten
Die Vergabe und der Entzug der Objektberechtigungen kann mit Hilfe: 왘 des SQL Enterprise Managers 왘 der Transact-SQL-Anweisungen GRANT, DENY und REVOKE
durchgeführt werden. In diesem Abschnitt wird nur die Benutzung des SQL Enterprise Managers gezeigt. (Die Verwendung der GRANT-, DENY- und REVOKE-Anweisungen für diese beiden Aufgaben ist in Kapitel 12 beschrieben.) Abbildung 19.7: Das Dialogfeld Objekteigenschaften
Die Objektberechtigungen können mit Hilfe des Enterprise Managers aus zwei Sichten angezeigt werden: aus der Sicht einzelner Benutzer und aus der Sicht einzelner Objekte. Wir werden zuerst die Vergabe bzw. den Entzug der Objektberechtigungen aus der Sicht einzelner Objekte erläutern. Die Verwaltung der Objektberechtigungen mit Hilfe des Enterprise Managers erfolgt durch das Anklicken des Ordners Datenbanken und die Auswahl der Datenbank. Danach muß das Datenbankobjekt (Tabelle, Sicht, Datenbankprozedur) ausgewählt werden, für das die Berechtigung erstellt bzw. modifiziert werden soll. Im Detailfenster werden das ausgewählte Datenbankobjekt mit der rechten Maustaste angeklickt und die Funktionen Alle Aufgaben und Berechtigungen verwalten (in dieser Reihenfolge) ausgewählt. Das Dialogfeld Objekteigenschaften (Abbildung 19.7) erscheint.
408
Zugriffsberechtigungen verwalten
Durch das Markieren einzelner Felder für die jeweiligen Benutzer werden die Vergabe, der Entzug und die Verweigerung der Berechtigungen eingeleitet. (Das Zeichen »√» spezifiziert die Vergabe, das Zeichen »X« die Verweigerung und ein leeres Zeichen kein Recht.) Objektberechtigung
Beschreibung
SELECT (Auswählen)
Diese Berechtigung erlaubt den lesenden Zugriff auf Reihen einer Tabelle (eines Views).
UPDATE (Aktualisieren)
Diese Berechtigung erlaubt das Ändern der Reihen einer Tabelle (eines Views).
INSERT (Einfügen)
Erlaubt das Einfügen von Reihen in eine Tabelle.
DELETE (Löschen)
Erlaubt das Löschen von Reihen einer Tabelle.
DRI
Erlaubt einem Benutzer referentielle Integrität für eine referenzierte Tabelle zu erstellen, für die er keine Auswahlberechtigung hat.
Tabelle 19.1: Objektberechtigungen
EXEC (Ausfüh- Erlaubt dem Benutzer Datenbank-Prozeduren auszuführen. ren) Abbildung 19.8: Das Dialogfeld Datenbankbenutzer – Eigenschaften
409
Benutzerverwaltung
Die Vergabe der Objektberechtigungen aus der Sicht eines Benutzers erfolgt ähnlich. Zuerst muß die gewünschte Datenbank, zu der der Benutzer gehört, ausgewählt werden. Danach wird entweder der Unterordner Benutzer oder Rollen ausgewählt, abhängig davon, wem die Objektberechtigung vergeben bzw. entzogen werden soll. Bei den Benutzerkennungen werden die entsprechende Kennung im Detailfenster mit der rechten Maustaste angeklickt und die Funktionen Alle Aufgaben und Berechtigungen verwalten nacheinander ausgewählt. Das Dialogfeld Datenbankbenutzer – Eigenschaften (Abbildung 19.8) erscheint. Durch das Markieren einzelner Felder für das jeweilige Objekt werden die Vergabe, der Entzug und die Verweigerung der Berechtigungen eingeleitet. (Das Zeichen »√» spezifiziert die Vergabe, das Zeichen »X« die Verweigerung und ein leeres Zeichen kein Recht.) Tabelle 19.1 enthält alle in Abbildungen 19.7 und 19.8 existierenden Berechtigungen mit ihrer Beschreibung.
19.4.2
Anweisungsberechtigungen verwalten
Die Vergabe und der Entzug der Anweisungsberechtigungen kann mit Hilfe: 왘 des SQL Enterprise Managers und 왘 der Transact-SQL-Anweisungen GRANT, DENY und REVOKE
durchgeführt werden. In diesem Abschnitt wird nur die Benutzung des SQL Enterprise Mangers gezeigt. (Die Verwendung der GRANT-, DENY und REVOKE-Anweisungen für diese Aufgabe ist in Kapitel 12 beschrieben.) Die Verwaltung der Anweisungsberechtigungen mit Hilfe des Enterprise Managers erfolgt durch die Auswahl des Ordners Datenbanken und das Anklicken (mit der rechten Maustaste) der gewünschten Datenbank. Nach der Auswahl der Funktion Eigenschaften muß die Registerkarte Berechtigungen im Dialogfeld Datenbank – Eigenschaften (Abbildung 19.9) angeklickt werden. Durch das Markieren einzelner Felder für die jeweilige Anweisung werden die Vergabe, der Entzug und die Verweigerung der Berechtigungen eingeleitet. Tabelle 19.2 enthält alle in Abbildung 19.9 existierenden Berechtigungen mit ihrer Beschreibung. Tabelle 19.2: Anweisungsberechtigungen
410
Transact-SQL-Anweisung
Beschreibung
Tabelle erstellen (CREATE TABLE)
Erstellt eine neue Tabelle.
Sicht erstellen (CREATE VIEW)
Erstellt ein neues View.
SP erstellen (CREATE PROCEDURE)
Erstellt eine neue Datenbankprozedur.
Regel erstellen (CREATE RULE)
Erstellt eine neue Regel.
Standard erstellen (CREATE DEFAULT)
Erstellt einen neuen Standardwert.
Funktion erstellen (CREATE FUNCTION)
Erstellt eine neue benutzerdefinierte Funktion.
Zusammenfassung
Transact-SQL-Anweisung
Beschreibung
Sicherungs-DB (BACKUP DATABASE)
Archiviert eine Datenbank.
Sicherungsprotokoll (BACKUP TRANSACTION)
Archiviert ein Transaktionsprotokoll.
Abbildung 19.9: Das Dialogfeld Datenbank -Eigenschaften: Berechtigungen
19.5 Zusammenfassung In bezug auf die Benutzerverwaltung existieren beim SQL Server zwei Ebenen: die System- und die Datenbankebene. Eine Login-ID gehört der Systemebene an und erlaubt dem Benutzer den Zugriff auf das SQL ServerSystem. Der Datenbankbenutzername ermöglicht den Zugriff auf eine Datenbank des Systems. Alle Aufgaben in bezug auf die Datenbankverwaltung können entweder mit Hilfe des Enterprise Managers oder der Systemprozeduren durchgeführt werden. Zusätzlich existieren drei Transact-SQL-Anweisungen GRANT, DENY und REVOKE, die die Verwaltung der Objekt- und Anweisungsbe-
411
Benutzerverwaltung
rechtigungen ermöglichen. Generell gilt, daß die Verwendung von Systemprozeduren und Transact-SQL-Anweisungen GRANT, DENY und REVOKE mehr Funktionalität bietet als die Verwendung des Enterprise Managers. Aufgaben
412
A.19.1
Mit Hilfe des Enterprise Managers erstellen Sie drei neue LoginID: adam, berta und chris. Die Kennwörter dieser Login-ID sind abc, def und fgh, in dieser Reihenfolge. Die Beispieldatenbank ist die Standarddatenbank aller Login-ID. Überprüfen Sie nach der Erstellung der Login-ID ihre Existenz mit Hilfe der entsprechenden Systemtabellen.
A.19.2
Erstellen Sie mit Hilfe des Enterprise Managers drei Benutzernamen für die in A.19.1 erstellten Login-ID. Die Benutzernamen lauten: beisp_adam, beisp_berta und beisp_chris.
A:19.3
Erstellen Sie mit Hilfe des Enterprise Managers eine neue benutzerdefinierte Rolle namens manager, und fügen Sie die drei oben definierten Benutzernamen als Mitglieder dieser Rolle ein.
A.19.4
Erlauben Sie mit Hilfe des Enterprise Managers dem Benutzer beisp_adam die Erstellung von Tabellen und dem Benutzer beisp_chris die Erstellung von Datenbankprozeduren in der Beispieldatenbank.
A.19.5
Erlauben Sie mit Hilfe des Enterprise Managers der Rolle manager die Reihen in die Tabelle projekt einzufügen.
20
Die Archivierung und Wiederherstellung von Datenbanken
In diesem Kapitel wird die wichtigste Aufgabe des Systemadministrators – die Archivierung und Wiederherstellung – beschrieben. Nach der allgemeinen Einführung über die möglichen Fehlerquellen und der Definition des Transaktionsprotokolls werden alle Archivierungsarten (mit Hilfe des SQL Enterprise Managers und der BACKUP-Anweisungen) erläutert. Danach wird die Wiederherstellung sowohl der Benutzer- als auch der Systemdatenbanken (master und msdb) beschrieben.
20.1 Einführung Der Prozeß der Datenbankarchivierung wird benutzt, um dem Datenverlust bzw. der Dateninkonsistenz innerhalb einer Datenbank vorzubeugen. Der Datenverlust steht direkt im Zusammenhang mit Fehlern eines Datenbanksystems, die verschiedenen Ursprungs sein können. Deswegen werden wir zuerst die unterschiedlichen Fehlerarten, die in einem Datenbanksystem auftreten können, beschreiben.
20.1.1
Mögliche Fehler eines Datenbanksystems
Die Inkonsistenz einer Datenbank kann durch Fehler aus vier unterschiedlichen Gruppen verursacht werden. Dies sind: 왘 Programmfehler 왘 Systemfehler 왘 Plattenfehler 왘 Kombination unterschiedlicher Fehler
Ein Programmfehler betrifft die Anwendung eines einzelnen Datenbankbenutzers und hat gewöhnlich keinen Einfluß auf das ganze System. Programmfehler können im Regelfall nicht vom System abgefangen werden; es ist vielmehr Aufgabe des Programmierers, solche Fehler mit Hilfe von Transaktionen und der COMMIT- bzw. ROLLBACK-Anweisung selbst abzufangen. (Die beiden Transact-SQL-Anweisungen COMMIT und ROLBACK sind in Kapitel 14 beschrieben.) Für einen Systemfehler ist typisch, daß die im Arbeitsspeicher gespeicherten Daten verlorengehen. Dies tritt z.B. bei einem Stromausfall auf. Damit betrifft ein Systemfehler alle im Arbeitsspeicher befindlichen Anwendungen.
413
Die Archivierung und Wiederherstellung von Datenbanken
Ein Plattenfehler äußert sich dadurch, daß die Information auf einer Platte bzw. einem Plattenbereich verlorengeht. Die Ursache eines Plattenfehlers kann mechanischer (z.B. Schreib/Lesekopf-Fehler) oder verwaltungstechnischer Natur sein. Bei einer Kombination unterschiedlicher Fehler kann es vorkommen, daß sich eine oder mehrere Datenbanken des Systems in einem nicht konsistenten Zustand befinden. Abgesehen von der ersten Fehlerart, die vom Programmierer selbst abgefangen werden muß, werden die übrigen drei mit Hilfe des SQL Server-Systems behoben. Die Systemfehler werden durch die sogenannte automatische Wiederherstellung des Systems beseitigt. (Die automatische Wiederherstellung wird später in diesem Kapitel beschrieben.) Die beiden letzten Fehlerarten werden entweder durch vorbeugende Maßnahmen abgefangen, die dem System das weitere Arbeiten ohne Unterbrechung ermöglicht oder durch die Archivierung bzw. Wiederherstellung von Daten einer Datenbank behoben. Das nächste Thema, das wir behandeln werden, sind Transaktionsprotokolle. Nur die Archivierung der Datenbank und ihres Transaktionsprotokolls ermöglicht die Wiederherstellung von Daten, ohne anschließend vor dem Fehler ausgeführte aber nicht gesicherte Transaktionen manuell ausführen zu müssen.
20.1.2
Transaktionsprotokoll
Ein Transaktionsprotokoll beinhaltet alle Datenbankänderungen, die in einem gewissen Zeitraum durchgeführt werden. Immer wenn eine Datenbank mit dem SQL Server-System erstellt wird, wird automatisch das dazugehörige Transaktionprotokoll erstellt. (Im Unterschied zu manchen anderen Datenbanksystemen, ist es beim SQL Server nicht möglich, eine Datenbank ohne Transaktionsprotokoll zu erstellen.) Das Transaktionsprotokoll steht in direktem Zusammenhang mit den Transaktionen. Um entscheiden zu können, ob alle Anweisungen innerhalb einer Transaktion ausgeführt oder zurückgesetzt werden sollen, ist es notwendig, alle geänderten Reihen in ihrer ursprünglichen und geänderten Form zu protokollieren. Für die Speicherung dieser Werte wird das Transaktionsprotokoll verwendet. Damit enthält ein Transaktionsprotokoll sämtliche Informationen über abgeschlossene und nicht abgeschlossene Transaktionen einer Datenbank. Transaktionsprotokolle verwenden folgende zwei Konzepte: 왘 before images 왘 after images
um das Ausführen bzw. das Zurücksetzen aller Anweisungen innerhalb einer Transaktion zu ermöglichen.
414
Die Archivierung
before image kennzeichnet den Zustand einer Reihe vor ihrer Änderung. Der Prozeß der Erstellung eines before image bedeutet also, daß der Zustand der Reihe vor ihrer Änderung im Transaktionsprotokoll gespeichert wird. (Bei der Speicherung von before images wird immer die ganze physikalische Seite, zu der die Reihe gehört, gespeichert.) before images werden benutzt, um alle ausgeführten Anweisungen innnerhalb einer nicht abgeschlossenen Transaktion wieder zurückzusetzen. after image kennzeichnet den Zustand einer Reihe nach ihrer Änderung. Der Prozeß der Erstellung eines after image bedeutet also, daß der Zustand der Reihe nach ihrer Änderung im Transaktionsprotokoll gespeichert wird. (Bei der Speicherung von after images wird immer die ganze physikalische Seite, zu der die Reihe gehört, gespeichert.) after images werden benutzt, um alle Anweisungen einer abgeschlossenen, aber in der Datenbank noch nicht gesicherten Transaktion vom Anfang zu wiederholen. Im Zusammenhang mit before und after images steht das sogenannte write ahead-Prinzip. Dieses Prinzip besagt, daß jede Änderung zuerst im Transaktionsprotokoll gespeichert werden muß, bevor sie in die Datenbank (d.h. auf der Platte) gespeichert wird. Dank dieser Vorgehensweise besitzt das System ausreichende Informationen, um das Wiederholen von Änderungen durchführen zu können, falls ein Fehler im System auftritt.
20.2 Die Archivierung Die Archivierung kennzeichnet die Erstellung einer Kopie der zu einem bestimmten Zeitpunkt existierenden Daten einer Datenbank. Im Unterschied zu manchen anderen Datenbanksystemen archiviert der SQL Server einzelne Datenbanken getrennt, was ihre Wiederherstellung sicherer macht. Der SQL Server kann eine Archivierung sowohl statisch als auch dynamisch durchführen. Eine statische Archivierung bedeutet, daß zum Zeitpunkt der Archivierung dieser Prozeß der einzige Prozeß ist, der läuft. Demgegenüber läuft die dynamische Archivierung parallel zu vielen anderen Benutzerprozessen. (Die dynamische Archivierung wird ausführlich später in diesem Abschnitt beschrieben.) Der SQL Server unterstützt vier unterschiedliche Archivierungsarten: 왘 volle Archivierung 왘 differenzielle Archivierung 왘 Archivierung des Transaktionsprotokolls 왘 Archivierung von Dateien und Dateigruppen.
Wir werden im weiteren Text des Buches den Begriff »Sicherung« als Synonym für den Begriff »Archivierung« benutzen.
415
Die Archivierung und Wiederherstellung von Datenbanken
20.2.1
Volle Archivierung
Die volle Archivierung kennzeichnet die Archivierung einer ganzen Datenbank. Bei dieser Archivierungsart kopiert das System alle physikalischen Seiten, wo sich Daten, benutzerdefinierte Datenbankobjekte und Systemtabellen befinden auf ein Sicherungsmedium (Platte, Magnetband oder Named Pipes). Falls die volle Archivierung dynamisch ausgeführt wird, werden auch alle Operationen, die während der Archivierung laufen, vom System gesichert. Dementsprechend werden alle nicht abgeschlossenen Transaktionen auf dem Sicherungsmedium gesichert.
20.2.2
Differentielle Archivierung
Seit Version 7 unterstützt der SQL Server neben der vollen auch die differentielle Archivierung. Mit Hilfe der differentiellen Archivierung werden nur diejenigen Teile der Datenbank, die seit der letzten vollen Archivierung geändert wurden, gesichert. (Genauso wie bei der vollen dynamischen Archivierung werden alle Aktivitäten, die parallel zu der dynamischen differentiellen Archivierung laufen, auch gesichert.) Der Vorteil der differentiellen Archivierung (im Vergleich zu der vollen) liegt in der Geschwindigkeit und Einfachheit, weil eine differentielle Archivierung wesentlich kürzer dauert und die Wiederherstellung der Datenbank einfacher ist. (Im Unterschied zu der vollen Archivierung, die alle physikalischen Seiten einer Datenbank enthält, umfaßt die differentielle Archivierung nur die geänderten Seiten.)
20.2.3
Archivierung des Transaktionsprotokolls
Diese Art der Archivierung bezieht sich ausschließlich auf die Änderungen, die im Transaktionsprotokoll einer Datenbank gespeichert sind. Im Unterschied zu der vollen und differentiellen Archivierung, die physikalische Seiten sichern, wird bei der Archivierung des Transaktionsprotokolls logische Information (d.h. alle durch die Datenmanipulationsanweisungen durchgeführten Änderungen) gesichert. Deswegen nennt man oft die ersten beiden Archivierungsarten physikalische und die letzte logische Archivierung. Die Archivierung des Transaktionsprotokolls wird wesentlich schneller als die volle Archivierung durchgeführt, weil die Datenmenge, die zu sichern ist, kleiner ist. Diese Archivierungsart hat einen doppelten Zweck: erstens wird dadurch die Sicherung der zuletzt geänderten Daten erstellt und zweitens wächst die Größe des Transaktionsprotokolls nicht ununterbrochen weiter, weil nach jeder partiellen Sicherung jede abgeschlossene Transaktion im Transaktionsprotokoll gelöscht wird. Die Archivierung des Transaktionsprotokolls ist nur sinnvoll, falls die volle Archivierung mindestens einmal davor durchgeführt wurde.
416
Die Archivierung
Mit Hilfe der vollen Archivierung und der Gruppe aller nacheinander erstellten Archivierungen des Transaktionsprotokolls ist es möglich, eine Datenbank auf einen anderen Rechner vollkommen zu übertragen. (Derselbe Satz von Sicherungskopien kann selbstverständlich auch verwendet werden, um die Daten der existierenden Datenbank nach einem schwerwiegenden Fehler zu überschreiben.) Der SQL Server erlaubt es nicht, das Transaktionsprotokoll gemeinsam mit der Datenbank in derselben Datei zu speichern. Der eine Grund für diese Einschränkung ist, daß die Verwendung dieses Teils des Transaktionsprotokolls für die Wiederherstellung der Datenbank nicht möglich wäre, falls die Datei beschädigt ist. (Damit wäre eine komplette Wiederherstellung dieser Datenbank unmöglich.) Das Transaktionsprotokoll wird bei fast allen relationalen Datenbanksystemen für die Speicherung der Änderungen, die auf den Daten einer Datenbank durchgeführt werden, benutzt. Trotzdem existieren manchmal Ausnahmesituationen, wo der Systemadministrator entscheiden kann, die Verwendung des Transaktionsprotokolls temporär auszusetzen. Das Laden von Massendaten in einer Tabelle ist ein solcher Fall, weil es stundenlang dauern kann (besonders dann, wenn die Tabelle viele existierende Indizes enthält). In so einem Fall wird die Operation wesentlich schneller ausgeführt, falls das Protokollieren von geänderten Daten vorübergehend abgeschaltet wird. Bei der Archivierung des Transaktionsprotokolls werden im allgemeinen folgende Operationen durchgeführt: 왘 das Kopieren aller abgeschlossenen Transaktionen, die sich im Transak-
tionsprotokoll befinden, auf ein Sicherungsmedium 왘 das Entfernen der abgeschlossenen Transaktionen aus dem Transaktions-
protokoll Abhängig von den verwendeten Optionen werden entweder die beiden o.g. Operationen oder eine von ihnen ausgeführt. Einer der häufigsten Fehler, der in einem System auftreten kann, ist das Auffüllen der Datei, die das Transaktionsprotokoll enthält. Dieses Problem kann nur umgangen werden, indem das Transaktionsprotokoll regelmäßig archiviert wird. (Die Archivierung einer Datenbank entfernt nicht die abgeschlossenen Transaktionen aus dem Transaktionsprotokoll.) Sowohl die Transaktions- als auch die differentielle Archivierung sichern Daten einer Datenbank nur partiell. Trotzdem gibt es einen wichtigen Unterschied zwischen diesen beiden Archivierungsarten: Die Sicherung des Transaktionsprotokolls enthält alle Änderungen einer Reihe, die seit der letzten Archivierung mehrmals geändert wurde, während die differentielle Archivierung nur die letzte Änderung dieser Reihe beinhaltet.
417
Die Archivierung und Wiederherstellung von Datenbanken
Die Verwendung der differentiellen Archivierung hat Vor- und Nachteile im Vergleich zu der Verwendung der Archivierung des Transaktionsprotokolls. Der wichtigste Vorteil ist, daß für die komplette Wiederherstellung einer Datenbank die volle Archivierung derselben und die zuletzt erstellte differentielle Archivierung vollkommen genügen. (Demgegenüber braucht man für das Verfahren mit den archivierten Transaktionsprotokollen die Sicherung der Datenbank, die mit der vollen Archivierung erstellt wurde sowie alle seit diesem Zeitpunkt erstellten Sicherungen des Transaktionsprotokolls. Andererseits kann die differentielle Archivierung nicht für die Wiederherstellung von Daten zu einem spezifischen Zeitpunkt verwendet werden, weil sie keine Zwischenänderungen der Reihen enthält. (Für die Beschreibung der Wiederherstellung zu einem spezifischen Zeitpunkt siehe die Beschreibung der Option STOPAT der RESTORE LOG-Anweisung später in diesem Kapitel.)
20.2.4
Archivierung von Dateien
Diese Archivierungsart ermöglicht das Sichern einer oder mehrerer Dateien (oder Dateigruppen), die für die Speicherung einer Datenbank benutzt werden. Einzelne Dateien bzw. Dateigruppen sollten in der Praxis gesichert werden, falls nur eine kleine Untermenge aller durch den Fehler betroffenen Dateien wiederhergestellt werden soll. (Die Sicherung der Datenbank und des Transaktionsprotokolls kann parallel zu der Sicherung von Dateien verwendet werden.) Die Archivierung von Dateien und ihre Verwendung empfiehlt sich in der Praxis nur für den Fall, daß die zu wiederherstellende Datenbank zu groß ist und deswegen die zur Verfügung stehende Zeit nicht für die volle Wiederherstellung ausreicht.
20.2.5
Die dynamische Archivierung
Die dynamische Archivierung kennzeichnet die Möglichkeit, die Archivierung der Datenbanken bzw. Transaktionsprotokolle durchzuführen, während der SQL Server aktiv ist. Alle Benutzer können also ungehindert weiter mit dem SQL Server während der Archivierung arbeiten. (Der einzige Indikator für die Benutzer, daß parallel zu ihrer Arbeit auch die Archivierung durchgeführt wird, ist die Verschlechterung der Performance.) Die dynamische Archivierung ist ein wichtiges Merkmal des SQL Servers, weil dadurch die Produktionssysteme weiterlaufen können, während die Archivierung durchgeführt wird. Die dynamische Archivierung wird folgendermaßen durchgeführt: Das Transaktionsprotokoll der zu archivierenden Datenbank wird auf abgeschlossene Transaktionen hin untersucht und alle physikalischen Seiten, die zu diesen Transaktionen gehören, werden auf der Platte gesichert. (Dieser
418
Archivierung verwalten
Vorgang wird in der Datenbankterminologie checkpoint genannt.) Danach werden alle physikalischen Seiten, die der Datenbank angehören, sequentiell archiviert. Die sequentielle Archivierung wird unterbrochen, falls eine Seite von einem Benutzer geändert werden soll. In diesem Fall wird diese Seite gesichert, bevor der Benutzer sie ändern kann. Danach wird die Seite geändert und die Archivierung von dem ursprünglichen Punkt an weitergeführt. (Alle geänderten und davor gesicherten Seiten werden bei der sequentiellen Bearbeitung übersprungen.) Schließlich werden alle abgeschlossenen Transaktionen aus dem Transaktionsprotokoll entfernt.
20.3 Archivierung verwalten Alle Archivierungsarten können mit Hilfe: 왘 des Enterprise Managers 왘 des Sicherungsassistenten 왘 der Transact-SQL-Anweisungen
durchgeführt werden. Jede dieser Methode wird in den nachfolgenden Abschnitten beschrieben.
20.3.1
Archivierung mit Hilfe des Enterprise Managers
Bevor der Archivierungsprozeß gestartet wird, müssen die zu verwendenden Sicherungsmedien spezifiziert bzw. erstellt werden. Die Erstellung der Platten- und Bandmedien mit Hilfe des Enterprise Managers erfolgt ähnlich. In beiden Fällen müssen der Server und der Ordner Verwaltung angeklickt und anschließend der Unterordner Sicherung mit der rechten Maustaste ausgewählt werden. Nach der Auswahl der Funktion Neues Sicherungsmedium erscheint das in Abbildung 20.1 dargestellte Dialogfeld Eigenschaften von Sicherungsmedium. Falls Dateiname angeklickt wird, wird ein Plattensicherungsmedium erstellt, während die Auswahl von Name des Bandlaufwerkes ein Bandsicherungsmedium erzeugt. Im ersten Fall kann der Schalter ... auf der rechten Seite des Feldes angeklickt werden, um existierende Medien darzustellen. Falls am lokalen Rechner keine Magnetbandgeräte angeschlossen sind, ist es nicht möglich das Feld Name des Bandlaufwerkes zu markieren. Nach der Spezifikation bzw. Neuerstellung von Medien ist es möglich, die Datenbank zu archivieren. Dies wird durch die Auswahl des Ordners Datenbanken und das Anklicken (mit der rechten Maustaste) der Datenbank angeleitet. Danach müssen die Funktionen Alle Aufgaben und Datenbank sichern nacheinander ausgewählt werden. Das Dialogfeld SQL Server Sicherung (Abbildung 20.2) erscheint. Die Auswahl der Registerkarte Allgemein ermöglicht die Archivierungseigenschaften zu spezifizieren.
419
Die Archivierung und Wiederherstellung von Datenbanken Abbildung 20.1: Das Dialogfeld Eigenschaften von Sicherungsmedium
Zuerst müssen die zu sichernde Datenbank, der Name der Sicherung und die Beschreibung (optional) in die entsprechenden Feldern eingetragen werden. Danach muß die Sicherungsart (im Rahmen Sicherung) angegeben werden. (Weil es sich um die volle Archivierung der Beispieldatenbank handelt, muß Datenbank –vollständig markiert werden.) Der Name des Sicherungsmediums wird im Rahmen Ziel durch das Anklikken der Schaltfläche Hinzufügen angegeben. Dementsprechend können ein oder mehrere existierende Sicherungsmedien nach dem Anklicken der Schaltfläche Entfernen entfernt werden. Im Rahmen Überschreiben wird spezifiziert, ob der existierende Inhalt auf dem Sicherungsmedium überschrieben werden soll oder nicht. An Medien anfügen heißt, daß die neue Sicherung an den existierenden Inhalt des Mediums angehängt werden soll, während mit dem Markieren von Vorhandene Medien überschreiben der Inhalt der neuen Sicherung vom Anfang des Mediums geschrieben wird. Im Zeitplan-Rahmen können Angaben über die wiederholte Ausführung des Archivierungsprozesses gemacht werden. (Für die Beschreibung der Automatisierung einzelner Systemadministrationsaufgaben siehe Kapitel 22.) Um eine Datenbanksicherung zusätzlich zu verifizieren, muß die Registerkarte Optionen des Dialogfelds SQL Server Sicherung ausgewählt und Sicherung bei Abschluss überprüfen markiert werden (siehe Abbildung 20.3). Diese Maßnahme empfiehlt sich, um vorher festzustellen, ob die erstellte Archivierung überhaupt für die spätere Wiederherstellung benutzt werden kann oder nicht. Dieses Dialogfeld kann auch für die Initialisierung und Bezeichnung des Mediums (im Rahmen Mediensatzbezeichnung) verwendet werden. Nachdem alle Optionen gesetzt sind, muß die Schaltfläche OK angeklickt werden, um die Datenbank zu archivieren. Um die Liste aller Sicherungsdateien anzuzeigen müssen nacheinander der Server, der Ordner Verwaltung und der Unterordner Sicherung ausgewählt werden.
420
Archivierung verwalten Abbildung 20.2: Das Dialogfeld SQL Server Sicherung: Allgemein
Abbildung 20.3: Das Dialogfeld SQL Server Sicherung: Optionen
421
Die Archivierung und Wiederherstellung von Datenbanken
Die Archivierung des Transaktionsprotokolls und die differentielle Archivierung werden genauso wie die volle Archivierung ausgeführt, bis auf die Auswahl der Felder Transaktionsprotokoll bzw. Datenbank – differenziell im Sicherungs-Rahmen (siehe Abbildung 20.2).
20.3.2
Planung der Archivierung mit Hilfe des Enterprise Managers
Ein wohlüberlegter Plan ist sehr wichtig bei der Archivierung einer Datenbank, weil er Engpässe bei der produktiven Benutzung der Datenbank beseitigt. Dieser Plan muß sowohl den Faktor Zeit als auch den Archivierungstyp berücksichtigen. (Eine dynamische Archivierung z.B. ist nicht empfehlenswert, solange der Systemadministrator genug Zeit für die Sicherung der Datenbank zwischen zwei Aktivierungen des Systems hat.) Der Enterprise Manager ermöglicht die Verwaltung der Archivierung sowohl in bezug auf die Zeit als auch in bezug auf den Typ. Die Archivierung einer Datenbank kann einmalig oder in (regelmäßigen bzw. unregelmäßigen) zeitlichen Abständen durchgeführt werden. Im Zeitplan-Rahmen des Dialogfeldes SQL Server Sicherung (Abbildung 20.2) muß Zeitplan angeklickt werden. Der SQL Server bietet den Standardwert für die periodische Ausführung der Sicherung (einmal wöchentlich, am Sonntag um Mitternacht), diese Angabe kann durch das Anklicken von ... auf der rechten Seite des Zeitplan-Feldes geändert werden. In diesem Fall erscheint das in Abbildung 20.4 dargestellte Dialogfeld Zeitplan bearbeiten. Abbildung 20.4: Das Dialogfeld Zeitplan bearbeiten
422
Archivierung verwalten
In dem angebotenen Dialogfeld muß ein Name eingetragen werden. (Es empfiehlt sich, einen aussagekräftigen Namen anzugeben, damit die Identifikation jeder Sicherung in der Zukunft erleichtert wird. Dies ist besonders wichtig, damit man die Aufgabe später im Windows NT/2000-Ereignisprotokoll bzw. im SQL Server-Fehlerprotokoll erkennen kann.) Um einen Ablaufplan für eine Datenbanksicherung erstellen zu können, muß der SQLServerAgent-Dienst laufen. (Der SQL Server Agent ist in Kapitel 22 beschrieben.) Im Rahmen Zeitplantyp existieren insgesamt vier unterschiedliche Optionen: 왘 Automatisch starten, wenn der SQL Server-Agent startet 왘 Starten, sobald die CPU im Leerlauf ist 왘 Einmal 왘 Wiederholt
In den ersten beiden Fällen startet der SQL Server den Archivierungsprozeß zu unregelmäßigen Zeiten. Die erste Option besagt, daß die Sicherung gleichzeitig mit dem Starten des SQL Server Agent-Dienstes ausgeführt wird. Die zweite Option – Starten, sobald die CPU im Leerlauf ist – bedeutet, daß der Archivierungsprozeß gestartet wird, wenn wenig (oder keine) Operationen auf dem Datenbank-Server laufen und dadurch der Prozessor wenig zu tun hat. Dies ist wichtig, weil der Archivierungsprozeß sehr viel Prozessorzeit in Anspruch nehmen kann. Abbildung 20.5: Das Dialogfeld Zeitplan für wiederkehrende Aufträge
423
Die Archivierung und Wiederherstellung von Datenbanken
Falls man das Feld Einmal markiert, wird der Archivierungsprozeß einmalig, zum angegebenen Zeitpunkt ausgeführt. Im Unterschied dazu veranlassen die Markierung der Option Wiederholt und das Anklicken der Schaltfläche Ändern das Erscheinen des Dialogfeldes Zeitplan für wiederkehrende Aufträge bearbeiten(Abbildung 20.5) mit dem die Planung und die Ausführung des Archivierungsprozesses regelmäßig in den angegebenen Zeitintervallen veranlaßt werden kann. (Diese Option ist ausführlich in Kapitel 22 beschrieben.)
20.3.3
Der Sicherungsassistent
Der Sicherungsassistent bietet dem Datenbank- bzw. dem Systemadministrator eine einfache Methode, um Datenbanken und/oder ihre Transaktionsprotokolle zu sichern. Um diesen Assistenen zu wählen, müssen die Assistenten-Ikone im Hauptmenü des Enterprise Managers angeklickt und die Funktion Verwaltung ausgewählt werden. Nach dem Doppelklick des Sicherungsassistenten können folgende Aufgaben ausgeführt werden 왘 Die durchzuführende Sicherung angeben 왘 Die zur Datensicherung gehörenden Medien auswählen 왘 Neue Daten an das Sicherungsmedium anhängen bzw. alte überschrei-
ben 왘 Die Sicherung verifizieren.
20.3.4
Archivierung mit Hilfe der Transact-SQLAnweisungen
Alle Archivierungsoperationen können mit Hilfe der folgenden TransactSQL-Anweisungen ausgeführt werden: 왘 BACKUP DATABASE 왘 BACKUP LOG
Bevor wir die beiden Anweisungen erläutern, werden wir die Typen der Sicherungsmedien beschreiben. 20.3.4.1
Typen von Sicherungsmedien
Der SQL Server ermöglicht die Archivierung einer Datenbank bzw. eines Transaktionsprotokolls auf diversen Medien. Zu diesen gehören: 왘 die Platte 왘 das Magnetband 왘 Named Pipe
Die Verwendung der Platte als Sicherungsmedium wird gewöhnlich benutzt, wenn größere Datenbanken archiviert werden sollen. Dabei ist es wichtig, daß sich die Archivierung auf einer anderen Platte als die Daten-
424
Archivierung verwalten
bank selbst (bzw. das Transaktionsprotokoll) befindet. Beim SQL Server ist es auch möglich, einem Sicherungsmedium, das sich auf der Platte befindet, und andere Archivierungen schon enthält, eine neue Archivierung anzuhängen. Diese Funktionalität stellt für die meisten Systemadministratoren eine wichtige Erweiterung dar. Der SQL Server unterstützt sowohl die Archivierung auf den lokalen als auch auf den im Netz befindlichen Platten. Die Verwendung des Magnetbandes ist generell die am häufigsten bevorzugte Methode der Archivierung bei allen Datenbanksystemen. Der Vorteil der Magnetbänder liegt in der einfachen Handhabung und Aufbewahrung. Im Unterschied zu den Platten kann Magnetbandarchivierung nur auf lokalen Geräten ausgeführt werden. Named Pipe als Sicherungsmedium wird, im Unterschied zu den anderen Sicherungsmedien, als Parameter in der BACKUP-Anweisung angegeben und damit erstellt. Dieser Typ des Sicherungsmediums bietet anderen Herstellern die Möglichkeit, ihre Software mit dem SQL Server-System zu verbinden und anschließend Archivierungs- bzw. Wiederherstellungsoperationen durchzuführen. 20.3.4.2
Die BACKUP DATABASE-Anweisung
Für die volle Archivierung einer Datenbank wird die BACKUP DATABASEAnweisung verwendet. Diese Anweisung hat folgende Syntax: BACKUP DATABASE {db_name | @var1} TO medien_liste [WITH options_liste]
Der SQL Server unterstützt aus Kompatibilitätsgründen zusätzlich zu der BACKUP DATABASE-Anweisung auch die DUMP DATABASEAnweisung. Die beiden Anweisungen haben dieselben Optionen. Wir empfehlen, ausschließlich die BACKUP DATABASE-Anweisung für die Datenbankarchivierung zu verwenden, weil die DUMP DATABASEAnweisung in einer der nachfolgenden SQL Server-Versionen nicht mehr unterstützt wird. db_name ist der Name der Datenbank, die archiviert (gesichert) werden soll. (Der Datenbankname kann auch mit Hilfe der Variablen @var1 ermittelt werden.) medien_liste spezifiziert ein oder mehrere Sicherungsmedien, wo die Datenbanksicherung gespeichert werden soll. (medien_liste kann Namen von Plattendateien, Magnetbändern oder Named Pipes enthalten.)
425
Die Archivierung und Wiederherstellung von Datenbanken
options_liste umfaßt mehrere Optionen, die für unterschiedliche Archivierungstypen spezifiziert werden können. Die wichtigsten Optionen sind: 왘 INIT / NOINIT 왘 SKIP / NOSKIP 왘 FORMAT 왘 DIFFERENTIAL 왘 UNLOAD / NOUNLOAD
Die INIT-Option überschreibt alle Daten, die sich auf dem Sicherungsmedium befinden. Die NOINIT-Option, die den Standardwert darstellt, hängt die neue Sicherung an die existierende an. Die Option SKIP veranlaßt, daß die Überprüfung der Namen der Archivierungsmedien und des Verfallsdatums des Inhaltes nicht stattfindet. Diese Überprüfungen werden standardmäßig bzw. durch die explizite Angabe der Option NOSKIP durchgeführt, um das Überschreiben der Namen und Inhalte zu verhindern. In bezug auf die INIT-Option ist es möglich, daß das Verfallsdatum der auf dem Medium befindlichen Sicherung nicht erreicht wird. In diesem Fall wird der Sicherungsprozeß mit einer Fehlermeldung abgebrochen. Das Überschreiben einer solchen Sicherung kann durch die Verwendung der Optionen SKIP und INIT erreicht werden. Mit der FORMAT-Option wird der Verwaltungsteil (header) auf alle Dateien bzw. Magnetbänder, die für den Archivierungsprozeß verwendet werden, geschrieben. Damit wird diese Option für die Initialisierung des Mediums benutzt. Falls die FORMAT-Option für die Initialisierung eines Magnetbandes verwendet wird, werden zwei andere Optionen – INIT und SKIP – implizit ausgeführt. Dementsprechend wird die INIT-Option implizit ausgeführt, falls die FORMAT-Option für die Initialisierung einer Plattendatei verwendet wird. Die DIFFERENTIAL-Option spezifiziert eine differentielle Archivierung. Falls diese Option nicht angegeben ist, wird, die volle Archivierung der Datenbank durchgeführt. Die UNLOAD-Option, die den Standardwert darstellt, spezifiziert, daß das Magnetband nach dem Archivierungsprozeß automatisch zurückgespult und entladen wird. Dementsprechend wird die NOUNLOAD-Option das Magnetband in dem Zustand hinterlassen, wie es unmittelbar nach dem Archivierungsprozeß war. 20.3.4.3
Die BACKUP LOG-Anweisung
Die BACKUP LOG-Anweisung archiviert den nicht aktiven Teil eines Transaktionsprotokolls auf einem oder mehreren Sicherungsmedien. Die Syntax dieser Anweisung sieht folgendermaßen aus:
426
Archivierung verwalten
BACKUP LOG {db_name | @var1} [WITH {NO_LOG | TRUNCATE_ONLY}] TO medien_liste [WITH options_liste]
Der SQL Server unterstützt aus Kompatibilitätsgründen zusätzlich zu der BACKUP LOG-Anweisung auch die DUMP TRANSACTION-Anweisung. Die beiden Anweisungen haben dieselben Optionen. Wir empfehlen ausschließlich die BACKUP LOG-Anweisung für die Archivierung der Transaktionsprotokolle zu verwenden, weil die DUMP TRANSACTION-Anweisung in einer der nachfolgenden SQL Server-Versionen nicht mehr unterstützt wird. db_name, @var1 und medien_liste haben dieselbe Bedeutung wie die gleichnamigen Angaben in der BACKUP DATABASE-Anweisung. options_liste hat dieselben Optionen wie die BACKUP DATABASE-Anweisung, unterstützt aber eine zusätzliche Option – NO_TRUNCATE. Deswegen besteht der einzige Unterschied zwischen diesen beiden Transact-SQLAnweisungen in der Existenz dreier zusätzlicher Optionen bei der Sicherung des Transaktionsprotokolls: 왘 NO_TRUNCATE 왘 TRUNCATE_ONLY 왘 NO_LOG
Diese Angaben stellen unterschiedliche Verfahren dar, was mit den zu sichernden Daten eines Transaktionsprotokolls gemacht werden kann. Die Option NO_TRUNCATE wird benutzt, falls die Datenbank beschädigt ist, das entsprechende Transaktionsprotokoll aber nicht. In diesem Fall wird der nicht aktive Teil des Transaktionsprotokolls auf dem Sicherungsmedium gespeichert. Mit dieser Maßnahme schafft man die Voraussetzung für die Wiederherstellung der beschädigten Datenbank auch mit den zuletzt durchgeführten Änderungen. Die Option NO_TRUNCATE sollte verwendet werden, falls die Datenbank beschädigt oder verlorengegangen ist. In diesem Fall muß zuerst die Datenbank wiederhergestellt und danach die Sicherung des Transaktionsprotokolls (als letzter Teil des Wiederherstellungsprozesses) verwendet werden. Die TRUNCATE_ONLY-Option entfernt den nicht aktiven Teil des Transaktionsprotokolls, ohne ihn auf dem Sicherungsmedium zu sichern. (Der aktive Teil eines Transaktionsprotokolls kennzeichnet alle nicht abgeschlossenen Transaktionen, die auf dem Medium archiviert wurden.)
427
Die Archivierung und Wiederherstellung von Datenbanken
Die NO_LOG-Option entfernt auch den nicht aktiven Teil des Transaktionsprotokolls. Im Unterschied zur TRUNCATE_ONLY-Option protokolliert NO_LOG die durchgeführten Tätigkeiten nicht im Transaktionsprotokoll, so daß kein zusätzlicher Speicherplatz im Transaktionsprotokoll notwendig ist. Deswegen empfiehlt sich die Benutzung dieser Angabe falls die Datenbank (und das entsprechende Transaktionsprotokoll) keinen zusätzlichen Speicherplatz zur Verfügung haben. Durch das Ausleeren des Transaktionsprotokolls wird Platz für die weitere Arbeit mit der Datenbank geschaffen. Die Verwendung der NO_LOG-Angabe empfiehlt sich nur als letzte Maßnahme, weil dadurch die Archivierung der letzten Änderungen von Daten im Transaktionsprotokoll verlorengehen könnte. Um dies zu verhindern, soll der Systemadministrator unmittelbar nach der BACKUP LOGAnweisung die volle Archivierung der Datenbank starten und anschließend, mit der ALTER DATABASE-Anweisung den zusätzlichen Speicherplatz der Datenbank zur Verfügung stellen. Alle drei Optionen haben verschiedenen Einfluß auf den Wiederherstellungsprozeß. Deswegen ist es für den Systemadministrator wichtig zu wissen, welche dieser Optionen zu welchem Zeitpunkt verwendet werden soll. Nach der vollen Archivierung einer Datenbank werden im Laufe der Zeit zusätzlich mehrere Sicherungen des Transaktionsprotokolls gemacht. Diese Sicherungen bilden eine logische Kette, wo alle Glieder unbedingt notwendig sind, um die Datenbank bis zur letzten abgeschlossenen und gesicherten Transaktion zu restaurieren. Der Wiederherstellungsprozeß ist nur möglich, falls keine Unterbrechungen bei der Sicherung des Transaktionsprotokolls existieren. Die Unterbrechung der logischen Kette entsteht bei der Verwendung der Optionen TRUNCATE_ONLY und NO_LOG. Dementsprechend entsteht die gültige Kette der Sicherungen von Transaktionsprotokollen nur bei der Verwendung der NO_TRUNCATE-Option. Andererseits ist es nicht immer möglich, die Kette der nacheinander folgenden Transaktionsprotokolle zu gewährleisten. Bei einem Systemfehler ist es oft so, daß die Datenbank in einen nicht konsistenten Zustand gerät. Ein Systemfehler tritt z.B. auf, wenn das Transaktionsprotokoll voll ist. In diesem Fall sollte entweder die TRUNCATE_ONLY- oder die NO_LOG-Option verwendet werden. Zusätzlich zu den drei oben beschriebenen Optionen bietet der SQL Server auch eine andere Möglichkeit, den nicht aktiven Teil eines Transaktionsprotokolls zu entfernen. Falls die Option truncate log on checkpoint der Systemprozedur sp_dboption gesetzt ist, wird der nicht aktive Teil bei jedem Prüfpunkt (checkpoint) entfernt. In diesem Fall werden die Änderungen, die an den Daten der Datenbank durchgeführt werden, nicht im Transaktionsprotokoll gespeichert. Dementsprechend kann nach dem Setzen dieser Option das Transaktionsprotokoll nicht als Teil im Wiederherstellungsprozeß verwendet werden.
428
Archivierung verwalten
Falls keine der drei Angaben gemacht wird, wird das Transaktionsprotokoll auf dem Sicherungsmedium archiviert. Dies ist auch der übliche Vorgang. Beispiel 20.1
dump transaction beispiel to band_1
In Beispiel 20.1 wird das Transaktionsprotokoll der Datenbank beispiel auf dem Sicherungsmedium namens band_1 gesichert.
20.3.5
Welche Datenbanken sollen archiviert werden und wann ?
Folgende Datenbanken sollten regelmäßig archiviert werden: 왘 die master-Datenbank 왘 alle Produktionsdatenbanken 왘 die msdb-Datenbank
20.3.5.1
Die Archivierung der master-Datenbank
Die wichtigste Datenbank eines SQL Server-Systems – die master- Datenbank – muß in regelmäßigen Abständen archiviert werden. Zusätzlich dazu sollte sie nach der Ausführung derjenigen Transact-SQL-Anweisungen und Systemprozeduren, die sie verändern, auch archiviert werden. Falls die master-Datenbank beschädigt ist und ihre Sicherung nicht existiert, muß der Datenbank- bzw. Systemadministrator alle Systemdatenbanken neu erstellen, weil in so einem Fall alle Informationen bezüglich dieser Datenbanken verlorengehen. Für diesen Zweck existiert das Dienstprogramm rebuildm, das alle Systemdatenbanken als eine Einheit wieder erstellt. Folgende Aktivitäten sollten die anschließende Archivierung der master-Datenbank veranlassen: 왘 das Erstellen, Ändern oder Löschen einer Datenbank 왘 das Ändern eines Transaktionsprotokolls 왘 das Hinzufügen bzw. Entfernen eines Datenbankservers
Grundsätzlich ist es möglich, nur die volle Archivierung der master-Datenbank durchzuführen.
429
Die Archivierung und Wiederherstellung von Datenbanken
Der Systemadministrator muß dafür sorgen, daß keine Benutzerobjekte (Tabellen usw.) in der master-Datenbank gespeichert werden, um die Änderungen an ihr zu minimieren. 20.3.5.2
Die Archivierung aller Produktionsdatenbanken
Alle Produktionsdatenbanken sollten in regelmäßigen Abständen und zusätzlich nach gewissen Aktivitäten archiviert werden. Die Durchführung folgender Aktivitäten sollte den Datenbankadministrator veranlassen, anschließend die betroffene Datenbank zu archivieren: 왘 die Erstellung derselben 왘 die Erstellung eines oder mehrerer Indizes 왘 die Ausführung nicht protokollierter Operationen 왘 die Entfernung des nicht aktiven Teils des Transaktionsprotokolls.
Der Grund für die Archivierung einer Datenbank unmittelbar nach ihrer Erstellung liegt darin, daß zwischen der Erstellung und der ersten geplanten Archivierung ein Fehler auftreten kann, der die Arbeit von mehreren Tagen zunichte machen kann. (In diesem Fall werden die erstellten Transaktionsprotokolle nur anwendbar, wenn eine Sicherung der Datenbank vorhanden ist.) Die Archivierung der Datenbank soll auch nach der Erstellung eines oder mehrerer Indizes ausgeführt werden. Der Grund für diese Maßnahme ist, daß die erstellten Indexstrukturen bei der Datenbanksicherung auch gesichert werden und damit, im Fehlerfall, die Zeit für die Neuerstellung der Indizes gespart wird. (Die Sicherung eines Transaktionsprotokolls beinhaltet die Information über jeden neu erstellten Index, archiviert aber nicht die existierenden Indexstrukturen.) Der SQL Server hat mehrere Optionen, die die Protokollierung der Änderungen im Transaktionsprotokoll deaktivieren. Dies sind: 왘 die WRITETEXT- bzw. UPDATETEXT-Anweisung 왘 die SELECT-Anweisung mit INTO-Klausel 왘 das Ausführen des »schnellen« Ladens von Daten mit Hilfe des bcp-
Kommandos (siehe Kapitel 21) 왘 das Ausführen der BACKUP LOG-Anweisung mit der NO_LOG-Option
Die Notwendigkeit der anschließenden Archivierung resultiert daraus, daß alle ausgeführten Änderungen nicht im Transaktionsprotokoll gesichert sind und dadurch ein Datenverlust entsteht, falls der Fehler vor der nächsten Datenbankarchivierung auftritt. (Die Archivierung der Datenbank nach der Ausführung der BACKUP LOG-Anweisung mit der NO LOG-OPTION ist notwendig, weil dadurch die Archivierung der letzten Änderungen von Daten im Transaktionsprotokoll verlorengehen könnte.)
430
Archivierung verwalten
20.3.5.3
Die Archivierung der msdb-Datenbank
Die msdb-Datenbank enthält alle Daten, die die SQL Server Agent-Komponente für die Durchführung der Auftragsplanung braucht. Falls diese Datenbank nicht zur Verfügung steht, können alle geplanten Aktivitäten (u.a. auch die regelmäßigen Archivierungen) nicht ausgeführt werden. Deswegen ist es unbedingt notwendig, eine gesicherte Version dieser Datenbank zur Verfügung zu haben. (Der SQL Server unterstützt das Dienstprogramm rebuildm, das alle Systemdatenbanken als eine Einheit wiedererstellt.) Falls nur die msdb-Datenbank beschädigt ist, kann sie mit Hilfe des Skriptes instmsdb.sql, das sich im Dateiverzeichnis \INSTALL befindet, neu erstellt werden. (Die erstellte Datenbank ist aber leer.)
20.3.6
Vorbeugende Maßnahmen gegen den Datenverlust
Alle Plattenfehler und einige der schweren Fehler können durch vorbeugende Maßnahmen und ohne Wiederherstellung der Datenbank umgangen werden. Zu den vorbeugenden Maßnahmen gehören: 왘 die Verwendung eines standby-Rechners 왘 die Verwendung der RAID-Technologie
Die vorherigen Versionen vom SQL Server haben die Spiegelung der Medien als vorbeugende Maßnahme gegen den Datenverlust unterstützt. Der SQL Server unterstützt die Spiegelung nicht mehr selbst, weil diese Funktionalität vom Betriebssystem (Windows NT/2000) angeboten wird. (Diese Funktionalität entspricht der RAID 1-Technologie, die später in diesem Abschnitt beschrieben wird.) 20.3.6.1
Die Verwendung eines standby-Rechners
Bei einem Produktionssystem, das keine längeren Zeitintervalle für das Stoppen des Systems (wegen der Wiederherstelllung) erlaubt, empfiehlt sich die Anschaffung eines standby-Rechners. Dieses Verfahren bedeutet, daß ein zweiter Rechner existiert, der eine identische Konfiguration und Daten wie der erste Rechner hat. Jedesmal wenn die Archivierung einer Datenbank auf dem ersten Rechner durchgeführt wird, soll diese, gemeinsam mit der Archivierung der entsprechenden Transaktionsprotokolle, auf dem zweiten Rechner wiederhergestellt werden. Falls der erste Rechner aus irgendwelchen Gründen nicht zur Verfügung steht, kann die ganze Produktion auf dem zweiten Rechner fortgesetzt werden.
431
Die Archivierung und Wiederherstellung von Datenbanken
Die Konfiguration (Datenbanken, Login-ID, Zugriffsrechte) des zweiten Rechners sollte, bis auf zwei Ausnahmen, identisch mit dem ersten Rechner sein. Die einzigen Ausnahmen bilden die beiden Datenbankoptionen no ckpt on recovery und read only, die für jede Benutzerdatenbank aktiviert (auf true gesetzt) werden sollen. Die beiden aktivierten Optionen verhindern die Ausführung irgendwelcher Aktivitäten zwischen zwei Wiederherstellungen einer Datenbank. Damit werden die Änderungen einer Datenbank auf dem standby-Rechner ausschließlich mit Hilfe der archivierten Kopie dieser Datenbank und ihres Transaktionsprotokolls durchgeführt. (Für die Beschreibung dieser Datenbankoptionen siehe Kapitel 18.) Die Vorgehensweise, um die genaue Kopie einer Produktionsdatenbank auf dem standby-Rechner zu erstellen, enthält folgende Schritte: 왘 die Wiederherstellung der Datenbank auf dem standby-Rechner mit Hilfe
der RESTORE DATABASE-Anweisung mit der STANDBY-Option 왘 die Wiederherstellung aller (außer des letzten) gesicherten Transaktions-
protokolle mit Hilfe der RESTORE LOG-Anweisung mit der STANDBYOption 왘 die Wiederherstellung des zuletzt gesicherten Transaktionsprotokolls
mit Hilfe der RESTORE LOG-Anweisung mit der RECOVERY-Option. Diese abschließende Anweisung bringt die Datenbank in den Lese/ Schreib-Modus, womit auch die Schreiboperationen auf der Datenbank ausgeführt werden können. (Für die Beschreibung der RECOVERY-Option siehe den nächsten Abschnitt dieses Kapitels.) 20.3.6.2
Log Shipping
Das log shipping gehört zu den neuen Funktionen des SQL Servers 2000. Es ermöglicht das Senden des Transaktionsprotokolls einer Datenbank zu den Datenbanken auf entfernten Rechnern. Damit hat der Server, auf dem sich die Quelldatenbank befindet, die Rolle des standby-Rechners und ermöglicht das Laden der Daten von der Quelldatenbank zu den Datenbanken auf entfernten Rechnern. Die log shipping-Funktionalität wird nur von der Enterprise Edition des SQL Servers 2000 unterstützt. Das log shipping wird mit Hilfe des Datenbank-Wartungsplanungs-Assistenten aktiviert. Beim ersten Schritt werden die Datenbanken auf entfernten Rechnern ausgewählt. Falls eine dieser Datenbanken nicht existiert, kann sie mit Hilfe des Assistenten neu erstellt werden. Im zweiten Schritt werden diese Datenbanken initialisiert, indem die Art der Wiederherstellung (die Verwendung der vollen bzw. der letzten Protokollarchivierung) spezifiziert wird. Schließlich wird die Zeitangabe gemacht, die die Zeitverzögerung der Übertragung der archivierten Version spezifiziert. Das angegebene Zeitintervall soll ermöglichen die Übertragung eines fehlerhaften Transaktionsprotokols zu verhindern.
432
Archivierung verwalten
20.3.6.3
RAID
Eine weitere Möglichkeit, die Datensicherheit bei den Plattenfehlern zu erhöhen, ist die RAID-Technologie. RAID (Redundant Array of Inexpensive Disks) kennzeichnet eine besondere Konfiguration von Platten, indem mehrere unterschiedliche Platten, logisch gesehen, eine sogenannte Striped-Platte bilden. Eine Striped-Platte ermöglicht die Verteilung von Daten auf unterschiedlichen Platten. Neben der sehr guten Performance ermöglicht diese Technologie eine erhöhte Datensicherheit. Insgesamt existieren sechs RAIDEbenen: RAID 0 bis RAID 5. Der SQL Server verwendet RAID 0, 1 und 5. RAID 0 spezifiziert die Striped-Platte und hat deswegen minimale Datensicherheit. (Das heißt, wenn eine der Platten beschädigt ist, sind alle auf der Platte gespeicherten Daten nicht mehr verfügbar.) Andererseits ist RAID 0 die schnellste von allen RAID-Technologien. RAID 1 kennzeichnet die Spiegelung der Platten bzw. Teilen von Platten. Die Spiegelung der Platten schützt vor Datenverlust, falls ein Plattenfehler auftritt. Bei diesem Prozeß werden alle Daten, die in einer (primären) Datei gespeichert sind, zusätzlich in eine weitere (sekundäre) Datei gespeichert. Die Voraussetzung für das ungestörte Weiterarbeiten mit einem SQL Server-System im Falle eines Plattenfehlers ist, daß die primäre und die sekundäre Datei sich nicht auf derselben Platte befinden. Falls die primäre Datei wegen eines Plattenfehlers nicht zur Verfügung steht, enthält die sekundäre Datei die identische Information, und das System arbeitet normal mit der sekundären Datei weiter. Welche Platten bzw. Plattenteile gespiegelt werden sollen, muß genau überlegt werden. Einerseits bringt die Spiegelung eine höhere Datensicherheit, andererseits wird, durch die Verdoppelung der Schreiboperationen die Verarbeitung der Daten mit dem SQL Server langsamer. Auf jeden Fall ist es dringend zu empfehlen, die Datei, auf der sich die master-Datenbank befindet, zu spiegeln. Die Spiegelung der master-Datenbank minimiert die notwendige Zeit, um das SQL Server-System nach einem Plattenfehler in einen konsistenten Zustand zu bringen. Wie aus der ganzen Diskussion ersichtlich ist, ist die RAID 1-Technologie wesentlich sicherer als RAID 0. Andererseits ist sie langsamer (wegen der Verdoppelung aller Schreiboperationen). Die RAID 5-Technologie unterstützt (wie RAID 0) das Platten-Striping, enthält aber zusätzliche Information, die ihr ermöglicht, die beschädigten Daten zu restaurieren. Damit kann ein System mit der RAID 5-Technologie durch einen Plattenfehler einen Teil der Daten verlieren und trotzdem alle verlorenen Daten selbst wiederherstellen. Die RAID 5-Technologie kostet weniger als RAID 1 (weil weniger Platten angeschafft werden müssen). Andererseits ist diese Technologie nicht so performant wie RAID 0 bzw. RAID 1.
433
Die Archivierung und Wiederherstellung von Datenbanken
Eine allgemeine Empfehlung ist, alle Datenbankdateien mit Hilfe der RAID 0-Technologie und Transaktionsprotokolle mit RAID 1 einzurichten. Falls die Wiederherstellung sehr schnell ausgeführt werden muß (weil das System nur ganz kurze Ausfallzeiten erlaubt), empfiehlt sich RAID 5 für die Datenbankdateien und RAID 1 für die Transaktionsprotokolle zu verwenden.
20.4 Wiederherstellung von Datenbanken Die Wiederherstellung von Datenbanken kennzeichnet den Vorgang, bei dem eine inkonsistente Datenbank mit Hilfe der erstellten Archivierungen wieder in einen konsistenten Zustand gebracht wird. Ein SQL Server-System bietet zwei Möglichkeiten, um Inkonsistenzen einer Datenbank zu beheben: 왘 die automatische Wiederherstellung 왘 die vom Benutzer initiierte Wiederherstellung.
Die vom Benutzer initiierte Wiederherstellung kann weiter in bezug auf die unterschiedlichen Datenbanken oder in bezug auf verwendete SQL ServerKomponenten unterteilt werden. Die Wiederherstellung folgender Datenbanken ist für den Datenbank- bzw. den Systemadministrator relevant: 왘 Benutzerdatenbanken 왘 master-Datenbank 왘 msdb-Datenbanken.
Andererseits können die Benutzerdatenbanken auf zweierlei Art durchgeführt werden: 왘 mit Hilfe des SQL Enterprise Managers und 왘 der RESTORE DATABASE- bzw. RESTORE LOG-Anweisung.
In den folgenden Unterabschnitten werden wir sowohl die automatische als auch vom Benutzer initiierte Wiederherstellung beschreiben. Im Unterschied zum Archivierungsprozeß, der sowohl statisch als auch dynamisch ausgeführt werden kann, ist die Wiederherstellung ein statischer Prozeß. Das bedeutet, daß ein einziger Datenbank- bzw. Systemadministrator (ein Mitglied der sysadmin- bzw. db_owner-Rolle also) zu einem Zeitpunkt die Wiederherstellung einer Datenbank durchführen kann, und weitere Benutzer mit dem System nicht arbeiten können.
434
Wiederherstellung von Datenbanken
20.4.1
Die automatische Wiederherstellung
Die automatische Wiederherstellung kennzeichnet einen Mechanismus, bei dem einfachere Inkonsistenzen einer Datenbank (wie z.B. Fehler, die durch einen Systemabsturz entstanden sind), repariert werden können. Dieser Mechanismus wird jedesmal beim Hochfahren des SQL Server-Systems automatisch gestartet. Dabei wird vom SQL Server folgendes gemacht: 왘 alle Transaktionen, die vor dem Auftreten des Fehlers nicht abgeschlos-
sen waren, werden zurückgesetzt 왘 alle Transaktionen, die vor dem Auftreten des Fehlers abgeschlossen wa-
ren, werden ausgeführt. Im Zusammenhang mit der automatischen Wiederherstellung von Datenbanken steht der Begriff checkpoint. Ein checkpoint kennzeichnet den Zeitpunkt, zu dem eine Datenbank eines SQL Server-Systems in einen konsistenten Zustand gebracht wird. Bei dem checkpoint werden alle, seit dem letzten checkpoint geänderten physikalischen Seiten, die sich im Arbeitsspeicher befinden, auf die Platte geschrieben. Damit garantiert ein checkpoint die Konsistenz einer Datenbank. Ein checkpoint wird implizit nach einer vom System berechneten, aber konfigurierbaren spezifischen Zeitspanne für jede Datenbank ausgeführt. Das explizite Setzen eines checkpoints kann für die aktuelle Datenbank mit Hilfe des CHECKPOINTS-Kommandos durchgeführt werden. Die automatische Wiederherstellung von Datenbanken fängt zuerst mit der master-Datenbank an, gefolgt von Modell- und msdb-Datenbanken. Am Ende werden die Benutzerdatenbanken vom System wiederhergestellt. Ein Benutzer kann sich während der automatischen Wiederherstellung in das System einloggen, die Verwendung einer Datenbank ist aber erst nach dem Abschluß der automatischen Wiederherstellung möglich.
20.4.2
Die vom Benutzer initiierte Wiederherstellung – eine Einführung
Die vom Benutzer initiierte Wiederherstellung einer Datenbank bedeutet, daß die letzte volle Archivierung einer Datenbank geladen und danach alle bezüglich dieser Datenbank gesicherten Transaktionsprotokolle eingespielt werden. Die gesicherten Transaktionsprotokolle müssen in der Reihenfolge eingespielt werden, in der sie archiviert wurden. Danach befindet sich die Datenbank in dem (konsistenten) Zustand, in dem sie zum Zeitpunkt der Archivierung des letzten Transaktionsprotokolls war. Der Wiederherstellungsprozeß auf der Basis einer vollen Archivierung verläuft so, daß zuerst alle Datenbankdateien neu erstellt und an entsprechenden Speicherungsorten plaziert werden. Danach wird die Datenbank mit allen dazugehörigen Objekten erstellt.
435
Die Archivierung und Wiederherstellung von Datenbanken
20.4.3
Die Wiederherstellung einer Benutzerdatenbank
Eine Benutzerdatenbank kann mit Hilfe: 왘 des SQL Enterprise Managers 왘 der RESTORE DATABASE- bzw. RESTORE LOG-Anweisung
wiederhergestellt werden. Die folgenden beiden Unterabschnitte beschreiben die Wiederherstellung einer Benutzerdatenbank mit Hilfe der beiden oben genannten SQL ServerKomponenten. 20.4.3.1
Wiederherstellung einer Benutzerdatenbank mit Hilfe des Enterprise Managers
Um die Wiederherstellung einer durch die volle Archivierung gesicherten Datenbank zu veranlassen, müssen der Ordner Datenbanken (mit der linken Maustaste) und die entsprechende Datenbank (mit der rechten Maustaste) angeklickt werden. Nach der Auswahl der Funktionsfolge Alle Aufgaben und Datenbank wiederherstellen erscheint das in Abbildung 20.6 dargestellte Dialogfeld Datenbank wiederherstellen. Durch die explizite Auswahl der gesicherten Kopie wird die Datenbank wiederhergestellt. Abbildung 20.6: Das Dialogfeld Datenbank wiederherstellen: Allgemein
436
Wiederherstellung von Datenbanken
Vergessen Sie nicht, daß die Reihenfolge der gesicherten Dateien bei der Wiederherstellung entscheidend ist! Immer zuerst die zuletzt durchgeführte volle Archivierung der Datenbank laden und danach alle gesicherten Transaktionsprotokolle in der Reihenfolge einspielen, in der sie archiviert wurden! Um die entsprechenden Optionen bei der Wiederherstellung auszuwählen, muß zuerst die Registerkarte Optionen (Abbildung 20.7) ausgewählt werden. Im Rahmen Wiederherstellungsabshlusstatus muß eine der drei angebotenen Optionen angeklickt werden. Die erste Option (Datenbank weiter ausführen. Zusätzliche Transaktionsprotokolle können nicht hergestellt werden) veranlaßt den SQL Server, alle abgeschlossenen Transaktionen auszuführen und alle nicht abgeschlossenen zurückzusetzen. Nach der Auswahl dieser Option befindet sich die wiederhergestellte Datenbank im konsistenten Zustand und kann dementsprechend von den Benutzern verwendet werden. Diese Option entspricht der RECOVERY-Option der RESTORE DATABASE-Anweisung. (Für die Beschreibung der RESTORE DATABASE-Anweisung siehe den nächsten Abschnitt.) Abbildung 20.7: Das Dialogfeld Datenbank wiederherstellen: Optionen
Diese Option soll in folgenden Fällen benutzt werden: 왘 falls ausschließlich die volle Archivierung einer Datenbank für ihre Wie-
derherstellung verwendet wird 왘 bei der Wiederherstellung des zuletzt gesicherten Transaktionsprotokolls
437
Die Archivierung und Wiederherstellung von Datenbanken
Die zweite Option (Datenbank nicht weiter ausführen. Zusätzliche Transaktionsprotokolle können wiederhergestellt werden) führt ausschließlich alle abgeschossenen Transaktionen aus. (Die nicht abgeschlossenen Transaktionen werden nicht zurückgesetzt, weil der SQL Server erwartet, daß weitere Sicherungen des Transaktionsprotokolls eingespielt werden.) Nach der Ausführung dieser Option kann die Datenbank (noch) nicht benutzt werden. (Diese Option entspricht der NORECOVERY-Option der RESTORE DATABASE-Anweisung.) Diese Option soll in folgenden Fällen benutzt werden: 왘 wenn die differentielle Archivierung einer Datenbank als Teil des Wie-
derherstellungsprozesses verwendet wird 왘 bei der Wiederherstellung aller (bis auf den letzten) gesicherten Transak-
tionsprotokolle. Die dritte Option (Datenbank im schreibgeschützten Modus verwenden. Zusätzliche Transaktionsprotokolle können wiederhergestellt werden) spezifiziert die Datei (Im Dialogfeld Rückgängig-Datei), die in gewissen Zeitabständen verwendet wird, um die Wiederherstellung jedes Transaktionsprotokolls mit Hilfe des Produktionssystems zu ermöglichen. (Diese Option entspricht der STANDBY-Option der RESTORE DATABASE-Anweisung.) Die Wiederherstellung einer Datenbank auf der Basis der differentiellen Archivierung verläuft genauso wie die Wiederherstellung auf der Basis der vollen Archivierung, bis auf einen einzigen Unterschied: Bei der Wiederherstellung auf der Basis der differentiellen Archivierung kann nur die erste Option (Datenbank weiter ausführen. Zusätzliche Transaktionsprotokolle können nicht hergestellt werden) verwendet werden. Bei der Verwendung der differentiellen Archivierung für die Wiederherstellung einer Datenbank muß zuerst die existierende volle Archivierung eingespielt werden, bevor die differentielle Archivierung geladen wird. Im Unterschied zu der Benutzung der gesicherten Transaktionsprotokolle, muß bei der differentiellen Archivierung nur die zuletzt gespeicherte für den Wiederherstellungsprozeß verwendet werden. Um die Wiederherstellung einer existierenden Archivierung unter einem anderen Datenbanknamen durchzuführen, müssen der Server angeklickt und der Ordner Datenbanken ausgewählt werden. Danach wird die Datenbank (mit der rechten Maustaste) angeklickt. Im Dialogfeld Datenbank wiederherstellen, nach der Auswahl der Registerkarte Allgemein, (Abbildung 20.6) werden Von Medien und Medien auswählen angeklickt. Im Dialogfeld Wiederherstellungsmedien wählen (Abbildung 20.8) müssen die Schaltfläche Hinzufügen angeklickt und der Name der Archivierungsdatei, von der der Wiederherstellungsprozeß initiiert wird, eingetragen werden. Im Rahmen Parameter wird die Datenbank – Vollständig ausgewählt, falls die Wiederherstellung auf der Basis der vollen Archivierung ausgeführt
438
Wiederherstellung von Datenbanken
werden soll. Die Namen der neuen Datenbankdateien, die vor dem Wiederherstellungsprozeß erstellt werden sollen, muß in der Spalte Wiederherstellung als (Abbildung 20.6) eingetragen werden. Abbildung 20.8: Das Dialogfeld Wiederherstellungsmedien wählen
20.4.3.2
Wiederherstellung der Transaktionsprotokolle mit Hilfe des Enterprise Managers
Die Wiederherstellung der Transaktionsprotokolle wird genauso wie die Wiederherstellung der Datenbank durchgeführt. Der einzige Unterschied ist, daß im Parameter-Rahmen Transaktionsprotokoll ausgewählt wird. Im Dialogfeld Datenbank wiederherstellen (Abbildung 20.6) können bei der Registerkarte Optionen nur die ersten beiden Optionen (im Rahmen Wiederherstellungsabschlusstatus) ausgewählt werden. 20.4.3.3
RESTORE DATABASE- und RESTORE LOG-Anweisung
Alle Wiederherstellungsoperationen können mit Hilfe zweier Transact-SQLAnweisungen 왘 RESTORE DATABASE 왘 RESTORE LOG
durchgeführt werden. (Die Wiederherstellung einer Datenbank mit Hilfe dieser beiden Anweisungen kennzeichnet den Prozeß des Rücktransports einer Datenbank in den Zustand, den sie vor der entsprechenden Archivierung gehabt hat.)
439
Die Archivierung und Wiederherstellung von Datenbanken
Mit Hilfe der RESTORE DATABASE-Anweisung wird die archivierte Kopie einer Datenbank geladen. Diese Anweisung hat folgende Syntax: RESTORE DATABASE {db_name | @var1} [FROM medien_liste] [WITH options_liste]
Der SQL Server unterstützt aus Kompatibilitätsgründen zusätzlich zu der RESTORE DATABASE-Anweisung auch die LOAD DATABASE-Anweisung. Die beiden Anweisungen haben dieselbe Optionen. Wir empfehlen, ausschließlich die RESTORE DATABASE-Anweisung für die Wiederherstellung einer Datenbank zu verwenden, weil die LOAD DATABASE-Anweisung in einer der nachfolgenden SQL Server-Versionen nicht mehr unterstützt wird. db_name ist der Name der Datenbank, die wiederhergestellt (restauriert) werden soll. (Der Datenbankname kann auch mit Hilfe der Variablen @var1 ermittelt werden.) medien_liste in der FROM-Klausel spezifiziert ein oder mehrere Sicherungsmedien, wo die Datenbanksicherung, die für den Wiederherstellungsprozeß verwendet werden soll, gespeichert ist. medien_liste kann Namen von Plattendateien, Magnetbändern oder Named Pipes enthalten. Falls die FROM-Klausel nicht spezifiziert wird, wird die Fehlerbehebung (anstatt des Wiederherstellungsprozesses) gestartet. In diesem Fall muß eine der (unten beschriebenen) Optionen RECOVERY, NORECOVERY oder STANDBY angegeben werden. Diese Aktion wird für den Fall durchgeführt, daß die Arbeit von dem primären auf den standby-Rechner verlagert wird. options_liste umfaßt mehrere Optionen, die für unterschiedliche Archivierungstypen spezifiziert werden können. Die wichtigsten Optionen sind: 왘 RECOVERY / NORECOVERY 왘 STANDBY 왘 REPLACE 왘 PARTIAL
Die Option RECOVERY veranlaßt den SQL Server alle abgeschlossenen Transaktionen auszuführen und alle nicht abgeschlossenen zurückzusetzen. Nach der Auswahl dieser Option befindet sich die wiederhergestellte Datenbank im konsistenten Zustand und kann danach von Benutzern verwendet werden.
440
Wiederherstellung von Datenbanken
Diese Option soll nur dann verwendet werden, wenn die volle Archivierung einer Datenbank exklusiv für ihre Wiederherstellung benutzt wird oder bei der Wiederherstellung des zuletzt gesicherten Transaktionsprotokolls. Die Option NORECOVERY führt ausschließlich alle abgeschlossenen Transaktionen aus. (Die nicht abgeschlossenen Transaktionen werden nicht zurückgesetzt, weil der SQL Server erwartet, daß weitere Sicherungen des Transaktionsprotokolls eingespielt werden.) Nach der Ausführung dieser Option kann die Datenbank (noch) nicht benutzt werden. Die Option NORECOVERY soll entweder bei dem Wiederherstellungsprozeß auf der Basis der differentiellen Archivierung oder bei der Wiederherstellung aller (bis auf den letzten) gesicherten Transaktionsprotokolle verwendet werden. Die Option STANDBY ist eine Alternative zu den beiden oben genannten Optionen RECOVERY bzw. NORECOVERY. Sie spezifiziert die sogenannte undo-Datei, die für das Zurücksetzen gewisser Datenbankänderungen verwendet wird. Um die Option STANDBY und die undo-Datei zu verstehen, muß die Problematik eines standby-Rechners näher erläutert werden. Falls eine Datenbank im STANDBY-Modus (d.h. in dem Modus, in dem sie für den standby-Rechner vorbereitet wird) wiederhergestellt wird, muß der entsprechende Prozeß alle nicht beendeten Transaktionen zurücksetzen, weil nur in diesem Fall sich die Datenbank im konsistenten Zustand befindet. (Dieser konsistente Zustand kann dann für den standby-Rechner verwendet werden.) Mit Hilfe der before images, die in der undo-Datei gespeichert sind, werden die entsprechenden physikalischen Seiten zurückgesetzt und so der konsistente Zustand der Datenbank gewährleistet. Die REPLACE-Option überschreibt eine existierende Datenbank mit den archivierten Daten einer anderen Datenbank. In diesem Fall wird die existierende Datenbank gelöscht und alle Unterschiede in bezug auf Datenbankund Dateinamen werden ignoriert. (Falls die REPLACE-Option nicht explizit angegeben ist, überprüft der SQL Server, ob der Datenbank- und alle Dateinamen übereinstimmen. Falls dies nicht der Fall ist, wird der Wiederherstellungsprozeß abgebrochen.) Die PARTIAL-Option spezifiziert eine partielle Archivierung. Eine solche Archivierung ist manchmal notwendig, falls eine Anwendung einen isolierten Teil einer Datenbank beschädigt. (Die partielle Archivierung wird später in diesem Kapitel erläutert.) Die RESTORE DATABASE-Anweisung wird auch für die Wiederherstellung von einer differentiellen Archivierung verwendet. In diesem Fall werden dieselben Optionen angewendet, wie im Falle einer Wiederherstellung auf
441
Die Archivierung und Wiederherstellung von Datenbanken
der Basis einer vollen Archivierung. Während dieses Wiederherstellungsprozesses wird nur jener Teil der Datenbank restauriert, der seit der letzten vollen Archivierung geändert wurde. Deswegen ist es wichtig, die Wiederherstellung der vollen Archivierung auszuführen, bevor die Wiederherstellung der differentiellen Archivierung gestartet wird. Die RESTORE LOG-Anweisung lädt das archivierte Transaktionsprotokoll einer Datenbank. Diese Anweisung hat folgende Syntax: RESTORE LOG DATABASE {db_name | @var1} [FROM medien_liste] [WITH options_liste]
Der SQL Server unterstützt aus Kompatibilitätsgründen zusätzlich zu der RESTORE LOG-Anweisung auch die LOAD TRANSACTION-Anweisung. Die beiden Anweisungen haben dieselben Optionen. Wir empfehlen, ausschließlich die RESTORE LOG-Anweisung für die Wiederherstellung der Transaktionsprotokolle zu verwenden, weil die LOAD TRANSACTION-Anweisung in einer der nachfolgenden SQL Server-Versionen nicht mehr unterstützt wird. db_name, @var1 und medien_liste haben dieselbe Bedeutung wie die gleichnamigen Angaben in der RESTORE DATABASE-Anweisung. options_liste ist identisch mit der Liste der Optionen der RESTORE DATABASE-Anweisung bis auf drei zusätzliche Optionen 왘 STOPAT 왘 STOPATMARK 왘 STOPBEFOREMARK.
Die STOPAT-Option ermöglicht die Wiederherstellung der Datenbank in den (konsistenten) Zustand, den sie zu einem spezifischen Zeitpunkt gehabt hat. In diesem Fall restauriert der SQL Server alle abgeschlossenen Transaktionen, die vor dem angegebenen Zeitpunkt gesichert waren. Falls man eine Datenbank zu einem spezifischen Zeitpunkt restaurieren will, muß zuerst die RESTORE DATABASE-Anweisung mit der NORECOVERYKlausel verwendet werden. Danach wird die RESTORE LOG-Anweisung ausgeführt, um jedes gesicherte Transaktionsprotokoll zu benutzen. (Falls die archivierten Transaktionsprotokolle den angegeben Zeitpunkt nicht enthalten, wird die Wiederherstellung der Datenbank nicht ausgeführt.) Die STOPATMARK- und STOPBEFOREMARK-Klauseln spezifizieren die Wiederherstellung zu einer angegebenen Marke. Diese neue Funktionalität des SQL Server 2000 wird am Ende dieses Kapitels erläutert.
442
Wiederherstellung von Datenbanken
20.4.3.4
Partielle Wiederherstelluung
Der SQL Server erlaubt die Wiederherstellung von Teilen einer Datenbank. Diese Funktionalität ist besonders nützlich, falls aus Versehen gelöschte Tabellendaten wiederhergestellt werden sollen. Mit Hilfe der diferenziellen Archivierung oder der archivierten Version des Transaktionsprotokolls ist es möglich, die Tabelle zum Zeitpunkt vor der Löschung wiederherzustellen und sie dann an einem anderen Ort zu speichern. Danach kann die Tabelle an dem ursprünglichem Ort wieder geladen werden. Die partielle Wiederherstellung wird mit Hilfe der PARTIAL-Klausel der RESTORE DATABASE-Anweisung durdchgeführt.
20.4.4
Die Wiederherstellung der master-Datenbank
Die master-Datenbank spielt eine herausragende Rolle unter allen Datenbanken eines SQL Server-Systems. Dementsprechend hat die Inkonsistenz dieser Datenbank ganz andere Konsequenzen für das ganze System als die Inkonsistenz einer Benutzerdatenbank. (Damit ist die Datei, die die masterDatenbank enthält, ein Favorit für die Spiegelung mit Hilfe der RAID 1Technologie.) Folgende Fehler deuten auf die Zerstörung der master-Datenbank: 왘 das System kann nicht gestartet werden 왘 ein Ein-/Ausgabefehler tritt auf 왘 das Ergebnis der Ausführung der DBCC-Kommandos deutet auf einen
solchen Fehler hin. Falls die master-Datenbank zerstört ist und der SQL Server nicht gestartet werden kann, werden alle Systemdatenbanken mit Hilfe des Dienstprogramms rebuildm neu aufgebaut. Die master-Datenbank befindet sich jetzt in demselben Zustand wie gleich nach der Installation des SQL Servers. Um die Wiederherstellung dieser Systemdatenbank bis zum Zeitpunkt der letzten Archivierung zu erhalten, muß nach dem Starten des SQL Server-Systems die Sicherung der master-Datenbank geladen werden. (Falls es weitere Änderungen der master-Datenbank nach der letzten Sicherung gegeben hat, müssen diese manuell durchgeführt werden. Genauso müssen alle nach der letzten Sicherung erstellten Benutzerdatenbanken mit Hilfe der Systemprozedur sp_attach_db an das System angeschlossen werden.)
20.4.5
Die Wiederherstellung anderer Systemdatenbanken
Die Wiederherstellung anderer Systemdatenbanken verläuft ähnlich wie die Wiederherstellung der master-Datenbank. Wir werden diesen Prozeß am Beispiel der msdb-Datenbank zeigen. Die msdb-Datenbank, zusammen mit der SQL Server Agent-Komponente, verwaltet und speichert alle Planungsdaten
443
Die Archivierung und Wiederherstellung von Datenbanken
eines SQL Server-Systems. Dabei ermöglicht die SQL Server Agent-Komponente die Ausführung der Planungen, während die msdb-Datenbank den Speicherungsort der entsprechenden Daten darstellt. Die Inkonsistenz bzw. das Verlorengehen der msdb-Datenbank bedeutet, daß alle schon gespeicherten Planungsdaten verlorengehen und die zukünftige Speicherung solcher Daten nicht möglich ist. Die Wiederherstellung der msdb-Datenbank ist in zwei Fällen notwendig: 왘 nach der Wiederherstellung der master-Datenbank, (weil dabei der Inhalt
der msdb-Datenbank gelöscht wird) 왘 bei der Inkonsistenz der msdb-Datenbank selbst.
Um die Wiederherstellung dieser Systemdatenbank bis zum Zeitpunkt der letzten Archivierung zu erhalten, müssen alle ihre Sicherungen geladen werden. (Falls es weitere Änderungen dieser Systemdatenbank nach der letzten Sicherung gegeben hat, müssen diese manuell durchgeführt werden.) Eine Datenbank kann nicht wiederhergestellt werden in der Zeit, wo ein oder mehrere Benutzer auf sie zugreifen. Für die msdb-Datenbank bedeutet das, daß die SQL Server Agent-Komponente während der Wiederherstellung dieser Datenbank gestoppt werden muß. (Diese Komponente greift auf die msdb-Datenbank zu.)
20.4.6
Wiederherstellungsmodelle
Der SQL Server 2000 unterstützt drei Wiederherstellungsmodelle: 왘 volle Wiederherstellung 왘 bulk-logged Wiederherstellung 왘 einfache Wiederherstellung.
Das Standardmodell einer Datenbank ist identisch zu dem Modell, das für die model-Datenbank definiert wurde. Das Standardmodell kann mit Hilfe der RECOVERY-Option der ALTER DATABASE-Anweisung geändert werden. Mit der databasepropertyex-Funktion kann das aktuelle Wiederherstellungsmodell einer Datenbank gesichtet werden. Folgende Abschnitte beschreiben die drei Wiederherstellungsmodelle. 20.4.6.1
Volle Wiederherstellung
Die volle Wiederherstellung bedeutet, daß alle Datenbankoperationen bei der Archivierung ins Transaktionsprotokoll geschrieben und damit gesichert werden. Deswegen unterstützt dieses Wiederherstellungsmodell die volle Sicherheit vor Datenverlust. Zusätzlich dazu kann die Wiederherstellung von Daten zum beliebigen Zeitpunkt ausgeführt werden. Um das zu garantieren, werden auch solche Operationen wie SELECT INTO, CREATE INDEX und die Ausführung des bcp-Dienstprogramms voll archiviert.
444
Wiederherstellung von Datenbanken
20.4.6.2
Bulk-Logged Wiederherstellung
Die bulk-logged-Wiederherstellung bedeutet, daß besonders zeitintensive Datenbankoperationen bei der Archivierung in das Transaktionsprotokoll nur eingeschränkt gesichert werden. Folgende Operationen werden eingeschränkt archiviert: 왘 SELECT INTO 왘 die CREATE INDEX-Anweisug (einschließlich der indizierten Views) 왘 das bcp-Dienstprogramm 왘 die WRITETEXT- und UPDATETEXT-Anweisung.
Obwohl die oben genannten Operationen nicht voll gesichert werden, ist es nicht notwendig, jedesmal nach der Ausführung einer solchen Operation die volle Datenbankarchivierung durchzuführen, weil das Transaktionsprotokoll die Ergebnisse der Operation enthält. Die bulk-logged Wiederherstellung erlaubt die Wiederherstellung bis zum Ende eines Transaktionsprotokolls. Damit wird die Wiederherstellung zu einem spezifischen Zeitpunkt nicht untersützt. 20.4.6.3
Einfache Wiederherstellung
Die einfache Wiederherstellung bedeutet, daß das Transaktionsprotokoll für die Wiederherstellung von Daten einer Datenbank nicht verwendet werden kann. Deswegen kann im Falle vom Datenverlust nur die Wiederherstellung mit Hilfe der vollen und differentiellen Archivierung durchgeführt werden. Die Wiederherstellungsstrategie für dieses Modell ist recht einfach: Verwende die volle Archivierung, und danach, falls die mehrere Versionen der differentiellen Sicherung existieren, wende die letzte an. 20.4.6.4
Vergleich der Wiederherstellungsmodelle
Alle drei Modelle unterscheiden sich in bezug auf folgende Faktoren: 왘 die Menge der Daten, die bei einem Fehler verloren geht 왘 Performanz bzw. der notwendige Speicherplatz für die Archivierung
von Daten. Die volle Wiederherstellung garantiert die volle Sicherheit von Daten, d.h. in einem Fehlerfall gibt es (fast) keinen Datenverlust. Zusätzlich dazu kann die Wiederherstellung von Daten nur mit diesem Modell zum beliebigen Zeitpunkt ausgeführt werden. Nachteilig für dieses Modell ist, daß das Transaktionsprotokoll sehr umfangreich sein kann, besonders bei den Datenbanken, wo datenintensive Operationen ausgeführt werden. Als Fazit kann man sagen, daß dieses Modell wenig (oder keine) manuellen Änderungen verlangt. Die bulk-logged Wiederherstellung ermöglicht die Sicherung von datenintensiven Operationen mit minimalen Kosten. Der einzige Nachteil dieses Mo-
445
Die Archivierung und Wiederherstellung von Datenbanken
dells ist, daß alle datenintensiven Operationen, die nicht im letzten Transaktionsprotokoll gesichert sind, manuell ausgeführt werden müssen. Deswegen sollte dieses Modell verwendet werden, falls der Speicherplatz bei datenintensiven Operationen vermindert werden soll. Der Vorteil des einfachen Modells ist, daß die Ausführung der Operationen sehr performant ist, weil alle Operationen überhaupt nicht archiviert werden. Andererseits wird der Umfang der manuellen Ausführung im Falle eines Fehlers sehr hoch sein. 20.4.6.5
Wiederherstellungsmodelle und die Kompatibilität zu den früheren Versionen
Die Funktionalität des Wiederherstellungsmodells wurde in den früheren SQL Server-Versionen mit Hilfe von zwei Datenbankoptionen: 왘 trunc. log on chkpt 왘 select into bulk copy
gewährleistet. Die Funktionalität der einfachen Wiederherstellung entspricht dem Fall, wo die Datenbankoption trunc. log on chkpt aktiviert ist. (Der Zustand der anderen Option ist irrelevant.) Die Aktivierung der Option select into bulk copy und die Nichtaktivierung der Option trunc. log on chkpt entspricht der bulk-logged Wiederherstellung. Die letzte Kombination (beide Optionen nicht aktiviert) entspricht dem vollen Wiederherstellungsmodell.
20.4.7
Wiederherstellung zu einer Marke
Der SQL Server 2000 unterstützt die Wiederherstellung zu einer spezifizierten Marke. Eine Marke entspricht einem Eintrag in einer spezifischen Transaktion und wird in diese eingefügt, falls die Transaktion erfolgreich abgeschlossen wird. Damit wird die Marke mit einem festgelegten Teil der Anwendung in Zusammenhang gebracht und erlaubt dem Datenbankadministrator die Wiederherstellung vor bzw. nach der Marke auszuführen. Eine markierte Transaktion kann auch mehrere Datenbanken auf demselben Datenbank-Server umfassen. In diesem Fall wird der entsprechende Eintrag in allen durch die markierte Transaktion involvierten Transaktionsprotokollen gemacht. Die Funktionalität der BEGIN TRANSACTION-Anweisung ist im SQL Server 2000 erweitert worden. Diese Anweisung unterstützt jetzt die Erstellung von Marken. Mit der WITH MARK-Klausel wird eine Marke in das Transaktionsprotokoll eingefügt. (Für die Beschreibung der WITH MARK-Klausel siehe Kapitel 14.) Im Transaktionsprotokoll werden der Markenname, die Beschreibung, der Zeitpunkt, der Name des Benutzers und der Datenbank sowie die Nummer
446
Zusammenfassung
des Protokolls (LSN) gespeichert. (Jede Marke kann eindeutig mit Hilfe des Zeitpunktes identifiziert werden.) Die RESTORE LOG-Anweisung kann (entweder mit der STOPATMARKoder mit STOPBEFOREMARK-Klausel) benutzt werden, um die Wiederherstellung zu einer spezifizierten Marke durchzuführen. Die STOPATMARK-Klausel verursacht die Wiederherstellung aller Transaktionen bis einschließlich der Transaktion mit der Marke. Demgegenüber beinhaltet der Wiederherstellungsprozeß diese Transaktion nicht, falls die STOPBEFOREMARK-Klausel verwendet wird.
20.5 Zusammenfassung Die Archivierung kennzeichnet die Erstellung einer Kopie der Daten einer Datenbank. Der SQL Server unterstützt vier Archivierungstypen: volle Archivierung, differenzielle Archivierung, Archivierung des Transaktionsprotokolls und Archivierung von Dateien. Alle Archivierungsarten können auch dynamisch durchgeführt werden, d.h. sie können während der Zeit, wo das System aktiv (online) ist, archiviert werden. Die Wiederherstellung einer Datenbank kennzeichnet den Vorgang, bei dem eine inkonsistente Datenbank mit Hilfe der erstellten Archivierung wieder in den konsistenten Zustand gebracht wird. (Die einfacheren Konsistenzen werden mit Hilfe der automatischen Wiederherstellung, die jedesmal vom SQL Server beim Starten des Systems durchgeführt wird, behoben.) Im Unterschied zu der Archivierung ist die vom Benutzer initiierte Wiederherstellung nur offline (d.h. während der Zeit, wo keine weitere Benutzer auf die Datenbank zugreifen) möglich. Aufgaben
A.20.1
Erklären Sie die Unterschiede zwischen der differentiellen Archivierung und der Archivierung des Transaktionsprotokolls?
A.20.2
Wann soll eine Produktionsdatenbank archiviert werden?
A.20.3
Wie kann die differentielle Archivierung der master-Datenbank durchgeführt werden?
A.20.4
Erklären Sie, welche RAID-Technologien sich am besten für die Sicherung der Daten einer Datenbank und ihres Transaktionsprotokolls eignen?
A.20.5
Welche sind die wichtigsten Unterschiede zwischen der manuellen und der automatischen Wiederherstellung?
447
21
Der Transfer von Daten
In diesem Kapitel werden die Möglichkeiten gezeigt, wie Massendaten beim SQL Server geladen bzw. entladen werden können. Nach der allgemeinen Einführung wird zuerst das wichtigste SQL Server-Werkzeug – Data Transformation Services (DTS) – beschrieben, das mehrere Komponenten enthält, die alle den Datentransfer zu einem bzw. aus einem SQL Server-System unterstützt. Danach wird das Dienstprogramm bcp erläutert, das generell das Laden und Entladen von Daten unterstützt.
21.1 Einführung In der Praxis kommt es oft vor, daß ein Unternehmen sein existierendes Access-Datenbanksystem durch ein wesentlich mächtigeres Datenbanksystem (wie z.B. SQL Server) ersetzen will. Genauso kann es vorkommen, daß die Daten einer anderen Firmenabteilung, die woanders benötigt werden, mit einem anderen DBMS verwaltet werden, als die Daten der zweiten Abteilung. In den beiden (und allen ähnlichen) Fällen muß das Datenbanksystem (mindestens) ein Werkzeug unterstützen, das die Daten von einer Datenquelle zu einer anderen transferiert. Der Transfer von Daten beinhaltet das Laden bzw. das Entladen von Daten von einer Quelle zu einer anderen. Im Falle vom SQL Server bedeutet der Datentransfer, daß die Daten in das SQL Server-System geladen werden und/oder aus einem SQL Server-System entladen werden. Zwischen der Entlade- und Ladephase können Daten noch transformiert werden, um die Bedingungen für ihr anschließendes Laden zu erfüllen. Der Datentransfer kann folgende Aufgaben beinhalten: 왘 Laden bzw. Entladen von Daten 왘 Datenarchivierung 왘 Datenmigration.
Das Laden von Daten (Datenimport) kennzeichnet den Prozeß des Hinzufügens neuer Daten zu einer existierenden Datenbank. (Das gegensätzliche Verfahren heißt Datenexport.) In diesem Fall stellt gewöhnlich eine Datei, die Daten enthält, die Datenquelle dar. Die Datenarchivierung ist eine spezielle Form von Datenexport, bei der eine Kopie der Datenbank und/oder des Transaktionsprotokolls erstellt wird. Der gegensätzliche Prozeß – Wiederherstellung – ist eine Form des Datenimports. (Weder die Datenarchivierung noch die Wiederherstellung beinhalten irgendwelche Art der Datentransformation.)
449
Der Transfer von Daten
Der Prozeß der Datenmigration ist wesentlich komplexer als das Laden bzw. das Entladen von Daten, weil er mehrere Schritte enthält: die Identifikation der Datenquelle, den Datenexport (gewöhnlich in eine Datei), die Festlegung der Datensenke und den Datenimport. Zusätzlich dazu existiert zwischen dem Export und dem Import von Daten der Datentransformationsprozeß, der folgende Schritte enthält: 왘 die Änderung der Datendarstellung 왘 die Restrukturierung von Daten.
Die Änderung der Datendarstellung bezieht sich auf die Modifikation unterschiedlicher Datenformen. Falls die Daten z.B. auf einem Rechner in EBCDICode dargestellt sind und die Migration auf einen Rechner mit ASCII-Code durchgeführt wird, muß die Darstellung von Daten geändert werden. Die Restrukturierung von Daten ist ein Begriff, der bei Data WarehousingSystemen eine wichtige Rolle spielt. Um Anforderungen der Benutzer eines Data Warehousing-Systems zu erfüllen, ist es generell notwendig, Daten als Aggregate darzustellen und Berechnungen an vielen Reihen im voraus durchzuführen. Diese Operationen können Tausende (oder sogar Millionen) von Reihen als Ergebnis benutzen, um daraus einige wenige Ergebnisreihen zu erstellen, die dann in das Zielsystem geladen werden. (Die ganze Problematik der Data Warehousing-Systeme ist im vorletzten Teil dieses Buches, ab Kapitel 26 beschrieben.) Der Prozeß des Datentransfers kann beim SQL Server mit folgenden Mitteln durchgeführt werden: 왘 mit der INSERT- bzw. SELECT INTO-Anweisung 왘 mit Hilfe des bcp-Kommandos und der BULK INSERT-Anweisung 왘 mit Hilfe der Werkzeuge und Anweisungen für die Datenarchivierung
(siehe Kapitel 20) 왘 mit Data Transformation Services (DTS).
Mit der INSERT-Anweisung kann einer Tabelle meistens eine einzige Reihe hinzugefügt werden. Die SELECT INTO-Anweisung erstellt eine neue Tabelle und lädt Reihen, die mit Hilfe der SELECT-Anweisung ausgewählt wurden. Beide Anweisungen haben eine sehr restriktive Funktionalität und eignen sich deswegen nicht für das Laden von Massendaten. Das bcp-Kommando eignet sich für das Laden der Daten aus einer Datei in eine Tabelle bzw. für das Entladen von Daten aus einer Tabelle in eine Datei. Damit kann das bcp-Kommando auch für den Transfer von Daten zwischen den Datenbanken verschiedener Hersteller verwendet werden. Das bcpKommando wird in Abschnitt 21.3 beschrieben. Der nächste Abschnitt beschreibt die SQL Server-Komponente namens DTS.
450
Data Transformation Services (DTS)
21.2 Data Transformation Services (DTS) Data Transformation Services (DTS) ist ein Werkzeug, das aus mehreren Komponenten besteht, und für den Import, Export und die Transformation von Daten dient. Dieses Werkzeug unterstützt homogene und heterogene Systeme. Bei den homogenen Systemen stellt der SQL Server sowohl das Quell- als auch das Zielsystem dar. Die Komponente von DTS, die homogene Systeme unterstützt heißt DTS Objekt Transfer. Bei den heterogenen Systemen werden Daten zwischen dem SQL Server und einem anderen Microsoft-Produkt bzw. einem anderen DBMS transferiert. In diesem Fall muß die OLE DB-Architektur von Microsoft verwendet werden. Folgende Aufgaben kann DTS durchführen: 왘 das Kopieren der Daten und des Datenbankschemas zwischen den ho-
mogenen und heterogenen Systemen 왘 die Definition von Standardtransformationen 왘 die Durchführung der Daten-Extraktion und Datentransformation.
DTS überträgt das Datenbankschema und Daten zwischen heterogenen Datenbanksystemen. (Bei den homogenen Systemen werden zusätzlich Datenbankobjekte wie Trigger, Datenbankprozeduren und Integritätsregeln übertragen.) Standardtransformationen werden mit Hilfe von DTS-Paketen definiert. DTS-Pakete erlauben dem Benutzer komplexe Datentransformationen zu definieren, die dann in mehreren Schritten ausgeführt werden. (Für die Beschreibung der DTS-Pakete siehe den nächsten Unterabschnitt.) Daten-Extraktion und Datentransformation gehören zu der Konsolidierungsphase, die eine der frühen Phasen im Entwurf der Data Warehousingund Data Mart-Systeme darstellt. Um ein entsprechendes Data Warehousing-System zu entwerfen, müssen die notwendigen Transformationen in bezug auf Daten definiert werden. Vor der Datentransformation müssen die Daten in der entsprechenden Art und Weise extrahiert werden (möglicherweise aus mehreren heterogenen Systemen). Nach dem Transformationsprozeß werden die Daten geladen. DTS beinhaltet mehrere Komponenten, die dem Designer eines Data Warehousing-Systems ermöglichen die Daten aus den Quellsystemen zu extrahieren, sie zu transformieren und in das Analysis Services-System zu laden. (Für die Beschreibung von MS Analysis Services siehe Kapitel 28.)
21.2.1
DTS-Pakete
Ein DTS-Paket stellt eine komplette Beschreibung aller Aufgaben, die als Teil des Datentransfers und/oder der Datentransformation ausgeführt werden müssen, dar. Jede Operation ist als ein Schritt definiert, und alle Schritte werden nacheinander abgearbeitet. DTS-Pakete sind unabhängig davon, ob der SQL Server als Quell- oder Zieldatenbanksystem überhaupt verwendet wird. Mit anderen Worten, ein DTS-Paket beschreibt die Ausführungs-
451
Der Transfer von Daten
schritte zwischen zwei (oder mehreren) beliebigen Datenquellen. (Die einzige Voraussetzung für das Quell- und Zielsystem ist, daß sie OLE DB unterstützen.) Die Kommunikation zwischen den Datenquellen ist durch die Komponente namens Data Pump (siehe Abbildung 21.1) gewährleistet. Data Pump ist ein Dienst, der den Datentransfer und die Datentransformation durch die Verarbeitung von OLE DB-Reihenmengen zwischen dem Quell- und dem Zielsystem unterstützt. DTS Data Pump ist als unabhängiger COM-Dienst implementiert. Deswegen kann dieser Dienst getrennt vom SQL Server verwendet werden. Abbildung 21.1: DTS-Pakete und Data Pump
21.2.1.1
Die Erstellung von DTS-Paketen
DTS-Pakete können manuell oder mit Hilfe des DTS Assistenten erstellt werden. Die Voraussetzung für die manuelle Erstellung eines DTS-Paketes ist die Verwendung einer der Programmiersprachen, die OLE-Automation unterstützen, wie C++ und Visual Basic. Die einfachere Methode bietet der DTS Import/Export-Assistent. Mit ihm kann der Benutzer folgende Tätigkeiten ausführen: 왘 das Kopieren der Daten zwischen homogenen oder heterogenen Daten-
quellen 왘 das Kopieren einer gesamten Tabelle 왘 das Kopieren des Ergebnisses einer lokalen bzw. verteilten Abfrage
452
Data Transformation Services (DTS) 왘 das Festlegen der Transformationsregeln, die für das Kopieren von Daten
zwischen zwei Spalten mit unterschiedlichen Eigenschaften gelten 왘 das Sichern des erstellten DTS-Pakets in die msdb-Datenbank oder MS
Repository um dieses für spätere Verwendung bzw. Dokumentationszwecke zu benutzen. (Für die Beschreibung von MS Repository siehe Kapitel 27.) Der DTS Import/Export Assistent kann mit Hilfe: 왘 des Enterprise Managers 왘 des Dienstprogramms dtswiz
gestartet werden. Um den Assistenten mit Hilfe des Enterprise Managers zu starten, müssen der SQL Server und der Ordner Datenbanken ausgewählt und die entsprechende Datenbank (mit der rechten Maustaste) angeklickt werden. Im nächsten Schritt werden die Funktionen Alle Aufgaben und Daten importieren bzw. Daten exportieren ausgewählt werden. Danach wird der DTS Import/ Export-Assistent gestartet. Der Assistent startet mehrere Schritte hintereinander, in denen der Benutzer sämtliche Angaben bezüglich des Datenimportes bzw. Datenexportes eingeben muß. Das Dienstprogramm dtswiz tut nichts anderes, als den DTS Import- bzw. DTS Export-Assistenten zu starten. dtswiz hat folgende Syntax: dtswiz {/option parameter} ...
Die wichtigsten Optionen und dazu gehörenden Parameter sind in Tabelle 21.1 aufgelistet. Option
Beschreibung
/f datei- Speichert das erstellte DTS-Paket in die Datei namens dateiname. name /i
Spezifiziert den Datenimport für den SQL Server.
/x
Spezifiziert den Datenexport für den SQL Server.
Tabelle 21.1: Die wichtigsten Optionen des dtswiz-Dienstprogramms
/r provi- Spezifiziert den Namen des Systems, zu dem die Verbindung hergeder stellt werden soll.
Das Dienstprogramm dtswiz kann mit keiner oder mehreren Optionen aufgerufen werden. Falls keine einzige Option angegeben ist, wird das Dienstprogramm vom Anfang an gestartet.
453
Der Transfer von Daten
21.2.1.2
Die Ausführung eines DTS-Pakets
Nach der Erstellung kann jedes DTS-Paket auf unterschiedliche Weise ausgeführt werden. Folgende Möglichkeiten existieren: 왘 mit Hilfe des Enterprise Managers 왘 mit Hilfe des DTS Paket-Designers 왘 mit Hilfe des Dienstprogramms dtsrun.
Die Ausführung eines Pakets kann mit Hilfe des Enterprise Managers geplant werden, indem das gespeicherte Paket (mit der rechten Maustaste) angeklickt und die Funktion Paket ausführen ausgewählt wird. Die alternative Methode ist die Verwendung des Dienstprogramms dtsrun. dtsrun kann auch den Inhalt eines DTS-Pakets ausgeben, überschreiben oder löschen. Tabelle 21.2 stellt die wichtigsten Optionen des Dienstprogramms dtsrun dar. Tabelle 21.2: Die wichtigsten Optionen des dtsrun-Dienstprogramms
Option
Beschreibung
/n paket_name
Spezifiziert den Paketnamen.
~
Alle Parameter nach diesem Zeichen werden verschlüsselt angezeigt.
/f dateiname
Spezifiziert den Namen der DTS-Paketdatei.
/!x
Gibt den Inhalt des DTS-Pakets (namens dateiname) aus und überschreibt den Inhalt, ohne das Paket auszuführen.
/!d
Löscht den Inhalt des DTS-Pakets (namens dateiname).
21.2.2
Andere DTS-Komponenten
Neben dem DTS Import/Export-Assistenten umfaßt DTS auch die DTS Paket Designer-Komponente, die im folgenden Unterabschnitt beschrieben wird. 21.2.2.1
Der DTS Paket Designer
Der Paket Designer ist eine graphische Benutzeroberfläche, die den Entwurf eines DTS-Pakets ermöglicht. Dieses Werkzeug enthält den Werkzeugkasten und die Palette, die die Definition der Eigenschaften des Datentransfers und der Datentransformation ermöglichen. Der Aufruf des DTS Paket Designers mit Hilfe des Enterprise Managers erfolgt durch die Auswahl des Servers und das Anklicken (mit der rechten Maustaste) des Ordners Datentransformation. Danach müssen der Unterordner Lokale Pakete (mit der rechten Maustaste) und die Funktion Neues Paket (mit der linken Maustaste) ausgewählt werden. Die Arbeitsfläche (Abbildung 21.2) erscheint.
454
Das bcp-Kommando Abbildung 21.2: DTS Paket Designer
Folgende Objekte können auf der Arbeitsfläche dargestellt werden: 왘 Datenquelle (als Ikone), die sowohl für die Darstellung der Quellsysteme
als auch des Zielsystems verwendet werden kann 왘 Ein Pfeil, der den Datenfluß darstellt 왘 Ein Taskobjekt, das eine Standardtransformation darstellt 왘 Eine Marke, die den Namen eines Objektes darstellt 왘 Ein durchbrochener Pfeil, der die Reihenfolge der Ausführung unter-
schiedlicher Aufgaben definiert.
21.3 Das bcp-Kommando bcp (Bulk Copy Program) ist ein sehr nützliches Dienstprogramm, mit dem ein Benutzer die gewünschte Tabelle in einer Datei entladen bzw. aus einer Datei laden kann. Zusätzlich dazu kann das Format des Ladens bzw. Entladens nach den benutzerspezifischen Normen gewählt werden. Die Syntax dieses Dienstprogramms ist: bcp [[db_name.]ben_name.]tab_name {IN |OUT | FORMAT} datei_name [{-option parameter} ...]
db_name ist der Name der Datenbank, zu der die Tabelle tab_name gehört. IN bzw. OUT kennzeichnet die Richtung der Datenbewegung: IN bedeutet das Laden der Daten und OUT das Entladen. datei_name ist der Name der Datei, in der sich Daten befinden (beim Laden), bzw. wo die Daten gespei-
455
Der Transfer von Daten
chert werden (beim Entladen). Die FORMAT-Angabe erstellt eine Formatdatei, die auf der Basis der angegebenen Optionen erstellt wird. (Falls diese Angabe benutzt wird, muß die Option -f angegeben werden.) Das bcp-Kommando kann: 왘 interaktiv 왘 mit Hilfe der Formatdatei
verwendet werden. Falls bcp mit Hilfe von Optionen -n oder -c gestartet wird, wird der Transfer interaktiv ablaufen. Die Option -n verwendet das datenbankeigene Format für den Datentransfer. Diese Option soll verwendet werden, wenn die Datei von einem SQL Server-System in ein anderes SQL Server-System übertragen wird. Bei der Verwendung dieser Option werden unnötige Datenkonvertierungen eliminiert, was die Transferzeit verkürzt. Die Option -c verwendet das Zeichenformat (char-Format) für alle Spalten der Tabelle, das Tabulatorzeichen als Spaltenbegrenzer und das NL(new line)-Zeichen als Zeilenende. Durch die Verwendung dieser Standardkriterien können die Daten eines Textverarbeitungssystems (oder einer nicht SQL Server-Datenbank) im allgemeinen am einfachsten übertragen werden. Der nicht interaktive Transfer von Daten wird mit Hilfe einer im voraus erstellten Formatdatei durchgeführt (siehe die Beschreibung der FORMATAngabe oben). Beispiel 21.1 zeigt die Erstellung einer solchen Datei. Beispiel 21.1
bcp beispiel..abteilung out b.out
-t"|"
-r"\n"
-Sinf_ente
-Upetra
Mit dem bcp-Kommando in Beispiel 21.1 werden die Daten der Tabelle abteilung in der Datei b.out entladen. Die Option »-t« spezifiziert den Feldbegrenzer zwischen den einzelnen Daten jeder Tabellenreihe, während »-r« den Datensatzbegrenzer festlegt. Nach dem Aufruf des bcp-Kommandos hat der Benutzer die Möglichkeit, spezifische Angaben über das Format der Daten für die Datei b.out zu machen. Das System gibt für jede einzelne Spalte gewisse Angaben aus, die sich abhängig vom Datentyp der Spalte geringfügig unterscheiden: 왘 Geben Sie den Speichertyp des Feldes abt_nr[char]: 왘 Geben Sie die Präfixlänge des Feldes abt_nr[0]: 왘 Geben Sie die Länge des Feldes abt_nr[4]: 왘 Geben Sie das Feldtrennzeichen ein[|]:
Der Benutzer kann die Werte explizit angeben, oder die Standardwerte werden durch die Betätigung der RETURN-Taste automatisch übernommen. (Die obigen Angaben beziehen sich auf die Spalte abt_nr der Tabelle abteilung.)
456
Das bcp-Kommando
Falls die entladenen Daten als Textdatei gespeichert und diese anschließend von einem anderen Datenbanksystem gelesen werden sollen, empfiehlt es sich, jede Spalte als char-Spalte mit der Präfixlänge 0 zu spezifizieren. (Weitere Kennzeichen einer solchen Datei sind die Auswahl des Zeichens »|« als Datenbegrenzer und des Zeichenendes »\n« als Zeilenbegrenzer, so wie wir explizit im bcp-Kommando angegeben haben.) Der Benutzer kann die von ihm gemachten Angaben für jede Tabellenspalte in einer Datei speichern. Dies empfiehlt sich, wenn das Entladen bzw. das Laden von Tabellendaten öfter durchgeführt wird. Nach dem Entladen der Daten sieht der Inhalt der Datei b.out folgendermaßen aus: 왘 10102|p1|Projektleiter|1.Okt.1988 0:00 왘 10102|p3|Gruppenleiter|1.Jan.1989 0:00 왘 25348|p2|Sachbearbeiter|15.Feb.1988 0:00 왘 18316|p2||1.Jun.1989 0:00 왘 29346|p2||15.Dez.1987 0:00 왘 2581|p3|Projektleiter|15.Okt.1989 0:00 왘 9031|p1|Gruppenleiter|15.Apr.1989 0:00 왘 28559|p1||1.Aug.1988 0:00 왘 28559|p2|Sachbearbeiter|1.Feb.1989 0:00 왘 9031|p3|Sachbearbeiter|15.Nov.1988 0:00 왘 29346|p1|Sachbearbeiter|1.Apr.1989 0:00
Der SQL Server unterstützt eine neue Transact-SQL-Anweisung – BULK INSERT –, die eine Alternative zum bcp-Kommando darstellt. Diese Anweisung bietet eine ähnliche Funktionalität wie das bcp-Kommando mit einer wesentlich besseren Performance.
21.3.1
Die Verwendung der austauschbaren Medien
Der SQL Server erlaubt die Daten einer Datenbank mit Hilfe der austauschbaren Medien zu distribuieren. Folgende Medien können verwendet werden: 왘 CD-ROM 왘 WORM (Write Once Read Many)-Platten 왘 optische Platten.
Die Verwendung der austauschbaren Medien stellt eine Alternative zu der Datenreplikation (siehe Kapitel 25) dar, falls große Mengen von Daten in größeren Zeitabständen distribuiert werden sollen. (Falls die Daten innerhalb einer kurzen Zeitspanne auf dem Zielrechner zur Verfügung stehen sollten, empfiehlt es sich, die Datenreplikation zu verwenden.)
457
Der Transfer von Daten
Für die Verwendung der austauschbaren Medien müssen gewisse Voraussetzungen erfüllt werden. Eine Datenbank, die auf solchen Medien distribuiert werden soll, muß folgendes erfüllen: 왘 sie muß auf neuen Medien erstellt werden 왘 die Medien dürfen nur von dieser Datenbank verwendet werden 왘 die Datenbank braucht mindestens drei solcher Medien (eines für den
Systemkatalog, eines für das Transaktionsprotokoll und eines oder mehrere für die Daten). Die Erstellung einer solchen Datenbank wird mit Hilfe der Systemprozedur sp_create_removable durchgeführt. Diese Prozedur hat folgende Syntax: sp_create_removable db_name, med_log_name, 'med_phys_name', groesse, prot_log_name, 'prot_phys_name', {dat_log_name1, 'dat_phys_name1'} ...
db_name ist der Name der Datenbank und med_log_name bzw. med_phys_name der logische bzw. der physikalische Name des Mediums, das die Systemtabellen enthält. prot_log_name und prot_phys_name sind der logische und der physikalische Name des Mediums, das das Transaktionsprotokoll beinhaltet. Schließlich kennzeichnen dat_log_name1 und dat_phys_name1 den logischen und den physikalischen Namen des Mediums, das die Daten enthält. Nach der Erstellung der Datenbank muß sie noch überprüft werden. Diese Überprüfung muß u.a. gewährleisten, daß keine Zugriffsrechte definiert sind und der Systemadministrator der Datenbankeigentümer ist. Mit Hilfe der Systemprozedur sp_certify_removable können alle Überprüfungen durchgeführt werden. Nach dem Kopieren der erstellten Datenbank muß eine Kopie installiert werden. Die Installation beinhaltet die Erstellung der Datei(en), die den Systemkatalog und das Transaktionsprotokoll enthalten. (Die Datei mit den Daten kann auf dem austauschbaren Medium bleiben oder auf die Platte kopiert werden. Die Daten müssen immer im Nur-Lese-Modus bleiben.) Mit Hilfe der Systemprozedur sp_dbinstall kann die Installation des austauschbaren Mediums durchgeführt werden. Diese Systemprozedur kopiert das Medium auf die Platte. (Für jedes Medium muß die Systemprozedur einmal ausgeführt werden.) Die installierte Datenbank ist danach noch nicht aktiviert. Um sie zu aktivieren, muß sp_dboption db_name, OFFLINE, FALSE
ausgeführt werden, wobei db_name der Name der Datenbank ist.
458
Zusammenfassung
21.4 Zusammenfassung Der Transfer von Daten kennzeichnet den Prozeß des Ladens neuer Daten zu einer existierenden Datenbank bzw. des Entladens von Daten. Zusätzlich dazu können Daten zwischen diesen beiden Prozessen transformiert werden. Diese drei Prozesse können beim SQL Server mit dem Data Transformation Services (DTS) durchgeführt werden. DTS enthält mehrere Komponenten: 왘 DTS Import- und Export-Assistenten 왘 DTS Paket Designer.
Zusätzlich dazu kann für den Datentransfer von bzw. zu einem SQL ServerSystem entweder das bcp-Kommando oder die BULK INSERT-Anweisung verwendet werden. Das bcp-Kommando kann für das Laden von Daten aus einer Tabelle in eine Datei (und umgekehrt) verwendet werden. Die Transact-SQL-Anweisung BULK INSERT bietet eine ähnliche Funktionalität mit einer wesentlich besseren Performance als das bcp-Kommando. Aufgaben
A.21.1
Welches Werkzeug bzw. Kommando kann als Alternative zum bcp-Kommando benutzt werden um Daten einer Datenbank zu entladen?
A.21.2
Welches SQL Server-Werkzeug kann verwendet werden, falls während der Migration von Daten auch ihre Transformation notwendig wird?
A.21.3
Erstellen Sie das entsprechende bcp-Kommando, um Daten der Tabelle Orders der Northwind-Datenbank zu entladen.
459
22
Automatische Ausführung der Administrationsaufgaben
In diesem Kapitel werden die Administrationsaufgaben, die mit dem SQL Server automatisiert werden können, beschrieben. Im Einführungsteil wird die SQL Server-Komponente SQL Server Agent erläutert, die entsprechende Dienste für die Automatisierung der Aufgaben bietet. Danach wird die Erstellung und die Ausführung von Aufträgen und das Setzen der Auftragsoptionen beschrieben. Am Ende des Kapitels wird die Verwaltung von Warnungen dargestellt.
22.1 Einführung Die Vorteile des SQL Server-Systems im Vergleich zu anderen Datenbanksystemen liegen besonders in zwei Bereichen: 왘 der Existenz einer benutzerfreundlichen graphischen Oberfläche, die
dem Systemadministrator die Arbeit mit dem System erleichtert 왘 der Möglichkeit, administrative Aufgaben durch die Automatisierung
zu reduzieren und dadurch Kosten zu sparen. Folgende wichtige Administrationsaufgaben werden oft und/oder periodisch ausgeführt und können deswegen automatisiert werden: 왘 Archivierung von Datenbanken und Transaktionsprotokollen 왘 Datentransfer 왘 Löschen und Neuerstellung von Indizes 왘 Überprüfen der Datenintegrität.
Es existieren drei SQL Server-Komponenten, die bei den Automatisierungsprozessen eine Rolle spielen: 왘 SQLServer-Dienst 왘 Windows NT/2000-Ereignisprotokoll 왘 SQL Server Agent.
Der SQLServer-Dienst ist für die Automatisierung der Prozesse notwendig, um das Schreiben der Meldungen im Windows NT/2000 Ereignisprotokoll zu veranlassen. Einige Meldungen werden automatisch in das Ereignisprotokoll geschrieben, während andere explizit durch den Systemadministrator errichtet werden müssen (siehe die Beschreibung später in diesem Kapitel). Das Windows NT/2000-Ereignisprotokoll ist der Speicherungsort für alle Betriebssystem- und Anwendungsmeldungen eines Windows NT/2000-Systems. (SQL Server-Fehlermeldungen, die den Schwierigkeitsgrad zwischen
461
Automatische Ausführung der Administrationsaufgaben
19 und 25 haben, werden automatisch in das Ereignisprotokoll geschrieben.) Die Aufgabe des Ereignisprotokolls ist, den SQL Server Agent über die Existenz einer (Fehler-)Meldung zu informieren. (Für die Beschreibung des Windows NT/2000 Ereignisprotokolls und der Schwierigkeitsgrade siehe Kapitel 23.) SQL Server Agent ist ein weiterer Dienst, der mit dem SQLServer-Dienst und dem Windows NT/2000-Ereignisprotokoll verbunden ist. Die Aufgabe des SQL Server Agents im Automatisierungsprozess ist eine Aktion auszuführen, nachdem die entsprechende Meldung im Ereignisprotokoll geschrieben wurde. Abbildung 22.1 zeigt die drei SQL Server-Komponenten für die Automatisierung der Prozesse und ihre Interaktion. Abbildung 22.1: SQL Server-Komponenten für die Automatisierungsaufgaben
Weil die Aktivierung von SQL Server Agent die Voraussetzung sowohl für die Ausführung der Aufträge als auch für die Verwaltung von Warnungen ist, werden wir diese Komponente zuerst beschreiben.
22.2 SQL Server Agent Der SQL Server Agent stellt einen Dienst dar, der die Aufträge und die Warnungen ausführt. Wie wir in weiteren Abschnitten dieses Buches sehen werden, werden Aufträge und Warnungen separat definiert und können dementsprechend unabhängig voneinander ausgeführt werden. Andererseits ist es auch möglich, daß ein Auftrag eine Warnung ausführt und umgekehrt. Folgende beide Beispiele werden die oben beschriebenen Verbindungen zwischen den Aufträgen und den Warnungen verdeutlichen. Nehmen wir an, daß ein Auftrag existiert, mit dem das Auffüllen des Transaktionsproto-
462
SQL Server Agent
kolls über ein Limit festgestellt wird. Wenn dieses Ereignis passiert, wird die entsprechende Warnung ausgeführt, die dann den Systemadministrator über das Ereignis informiert. Ein anderes wichtiges Ereignis ist die fehlende Ausführung der Archivierung des Transaktionsprotokolls. In diesem Fall kann die dazugehörige Warnung einen Auftrag starten, der den Inhalt des Transkationsprotokolls leert (siehe die Beschreibung der NO_LOG-Option der BACKUP LOG-Anweisung in Kapitel 20). Diese Aktion ist sinnvoll, falls der Grund für den Archivierungsfehler im Auffüllen des Transaktionsprotokolls liegt. (Im Unterschied zu dem vorherigen zeigt dieses Beispiel, wie eine Warnung einen Auftrag ausführt.) Der SQL Server Agent verwendet die msdb-Datenbank für die Speicherung aller geplanten Aufträge und definierten Warnungen. Damit ist die Konsistenz der msdb-Datenbank Voraussetzung für die Ausführung der definierten Aufträge und für das Aktivieren der erstellten Warnungen.
22.2.1
Starten und Konfigurieren des SQL Server Agent
Eine weitere Voraussetzung für die Ausführung der definierten Aufträge und für das Aktivieren der Warnungen ist das Starten des SQL Server Agent. Dieser Dienst kann auf folgende Art und Weise durchgeführt werden: 왘 mit Hilfe des SQL Server Dienstmanagers 왘 mit Hilfe des Enterprise Managers 왘 mit Hilfe der Dienste (im Fenster Systemsteuerung) 왘 mit Hilfe des net-Kommandos.
Der SQL Server Agent ist unabhängig vom SQL Server und wird dementsprechend getrennt vom SQL Server gestartet bzw. gestoppt. Es empfiehlt sich, den SQL Server Agent automatisch beim Booten des Systems zu starten. Die Konfiguration des SQL Server Agent beinhaltet die Verifizierung der entsprechenden Benutzerkennung und der Konfiguration des Mail-Profils. Während der Installation des SQL Servers wird die Kennung für den SQL Server Agent (und für den SQL Server-Dienst auch) festgelegt. Der Systemadministrator kann sowohl lokale als auch Domänen-Benutzerkennungen verwenden. Wir empfehlen, eine Domänen-Benutzerkennung zu verwenden, weil sie generell Vorteile gegenüber einer lokalen Kennung aufweist. Während die lokale Kennung nur den Zugriff auf den lokalen Rechner ermöglicht, kann eine Domänen-Benutzerkennung, unter anderem, für die Ausführung der Multi-Server-Aufträge und das Verschicken der elektronischen Post zu den anderen Rechnern verwendet werden.
463
Automatische Ausführung der Administrationsaufgaben
Wie wir schon erläutert haben, kann die Ausführung einer Warnung eine Meldung an den Systemadministrator bzw. an den Operator per e-mail beinhalten. Windows NT/2000 enthält die Anwendung namens Windows Mail, mit der Windows NT/2000-Rechner Informationen austauschen können. Zusätzlich dazu verwendet der SQL Server eine Komponente namens SQL Mail, um Zeichenketten, Dateien oder Abfrageergebnisse zu anderen Rechnern zu verschicken. SQL Server Mail ist eine MAPI-Schnittstelle (Messaging Application Programming Interface), die das Verschicken und das Empfangen der Meldungen anderer Rechner unterstützt. (Die Voraussetzung für die Interaktion mit den anderen Rechnern ist, daß sie Windows Mail bzw. eine andere MAPI-Schnittstellte unterstützen.) Bevor das SQL Server-System die elektronische Post senden bzw. empfangen kann, muß es als Mail-Client konfiguriert werden. Dieser Prozeß beinhaltet die Konfiguration des Profilnamens für den SQL Server AgentDienst. (Der Profilname ist erforderlich, um die Mail-Sitzung zu starten und die Warnungen mit Hilfe der elektronischen Post zu verschicken.) Eine SQL Server Mail-Sitzung wird automatisch mit dem SQL Server Agent gestartet.
22.3 Erstellung von Aufträgen und Operatoren Die erste Aufgabe bei der Automatisierung eines Prozesses ist die Erstellung von Aufträgen. Ein Auftrag kann mit Hilfe: 왘 des Auftragserstellungs-Assistenten 왘 des SQL Server Enterprise Managers
erstellt werden. Der Auftragserstellungs-Assistent stellt die einfachste Methode dar, mit der Aufträge erstellt werden können. Generell gibt es drei Schritte für die Erstellung eines Auftrags: 왘 Auftragsschritte definieren 왘 Auftragshäufigkeit planen 왘 Operatoren über den Auftragsstatus benachrichtigen.
Die folgenden Unterabschnitte erläutern alle diese Schritte mit Hilfe eines Archivierungsbeispiels und des SQL Server Enterprise Managers.
22.3.1
Auftragsschritte definieren
Ein Auftrag muß einen oder mehrere Schritte enthalten. Ein Auftragsschritt kann mit folgenden Mitteln definiert werden: 왘 mit Hilfe von Transact-SQL-Anweisungen
464
Erstellung von Aufträgen und Operatoren 왘 durch die Ausführung eines Dienstprogramms 왘 durch den Aufruf eines Programms.
Die meisten Auftragsschritte in der Praxis enthalten Transact-SQL-Anweisungen. Falls z.B. eine Datenbank oder die dazugehörigen Transaktionsprotokolle archiviert werden sollen, wird die Transact-SQL-Anweisung BACKUP DATABASE bzw. BACKUP LOG verwendet. Einige andere Aufträge werden die Ausführung eines Dienstprogramms verlangen, das gewöhnlich mit Hilfe eines Betriebssystemkommandos gestartet wird. Falls z.B. der Import bzw. Export von Daten ausgeführt werden soll, wird der Systemadministrator das bcp-Kommando verwenden. Die dritte Alternative stellt die Verwendung eines Programms dar, das entweder in Visual Basic oder in einer anderen Programmiersprache geschrieben ist. In diesem Fall muß immer der Systemadministrator den absoluten Pfadnamen im Befehl-Feld (siehe Abbildung 22.3) eintragen, damit der SQL Server Agent die auszuführende Datei finden kann. Vor der Erstellung eines Auftrags muß entschieden werden, ob der Auftrag auf dem lokalen oder auf mehreren Rechnern ausgeführt werden soll. Diese Entscheidung beeinflußt den Entwurf jedes zu erstellenden Auftrags. (Für weitere Informationen bezüglich der Erstellung von Aufträgen für die Multi-Server-Umgebung siehe den letzten Abschnitt dieses Kapitels.) Falls ein Auftrag mehrere Schritte beinhaltet, ist es unbedingt notwendig festzulegen, welche Maßnahmen im Fehlerfall ergriffen werden sollten. Standardmäßig wird der nachfolgende Schritt nach der erfolgreichen Beendigung des vorherigen ausgeführt. Falls in einem Schritt ein Fehler auftritt, wird der ganze Auftrag beendet. Dementsprechend gibt es zwei Maßnahmen, die ein Systemadministrator im Fehlerfall ergreifen soll. Erstens, die Anzahl der Versuche, die im Fehlerfall durchgeführt werden, festzulegen, und zweitens, die Fehlerursache zu lokalisieren und zu beheben. Die Anzahl der Versuche, die im Fehlerfall ausgeführt werden sollen, hängt von dem Typ (Transact-SQL-Anweisungen, Dienstprogramm oder Programm) und dem Inhalt des Auftragsschrittes ab.
22.3.2
Auftrag erstellen
Dieser Abschnitt beschreibt die Erstellung eines Auftrags für die Archivierung der Beispieldatenbank. Um den Auftrag zu erstellen, müssen zuerst die entsprechende Datenbank und die Schaltfläche Neuer Auftrag in der Symbolleiste des SQL Server Enterprise Managers angeklickt werden. Danach erscheint das Dialogfeld Neuer Auftrag – Eigenschaften (siehe Abbildung 22.2). Nach der Auswahl der Registerkarte Allgemein können alle Auftragsattribute eingegeben werden. (Wie aus Abbildung 22.2 ersichtlich, ist der
465
Automatische Ausführung der Administrationsaufgaben
Name des Archivierungsauftrags beispieldb_sichern.) Jeder Auftrag muß bei der Erstellung durch das Markieren der entsprechenden Fläche aktiviert werden. Abbildung 22.2: Das Dialogfeld Neuer Auftrag – Eigenschaften
Alle Aufträge sind standardmäßig aktiviert. Der SQL Server Agent deaktiviert einen Auftrag, falls dieser für eine einmalige Ausführung in der Vergangenheit konzipiert ist oder falls das Enddatum einer periodischen Ausführung überschritten ist. In beiden Fällen muß ein solcher Auftrag manuell reaktiviert werden. Im Rahmen Quelle wird die Art der Auftragsausführung festgelegt. Abhängig davon, ob der Auftrag auf dem lokalen oder auf mehreren Rechnern ausgeführt werden soll, wird die entsprechende Stelle markiert. Falls der Auftrag auf mehreren Rechnern ausgeführt werden soll, müssen zusätzlich die Schaltfläche Ändern angeklickt und die entsprechenden Rechner ausgewählt werden. (Der Auftrag beispieldb_sichern ist ein lokaler Auftrag und wird dementsprechend auf dem lokalen Rechner ausgeführt.) In der Liste Kategorie wird eine der Auftragskategorien (falls existent) ausgewählt und in der Liste Benutzer der Auftragseigentümer spezifiziert. Der Systemadministrator soll verschiedene Kategorien erstellen, falls zahlreiche Aufträge für eine Datenbank existieren, um die Handhabung der Aufträge zu erleichtern. In unserem Beispiel wird der Auftrag beispieldb_sichern nicht kategorisiert, und der Auftragseigentümer ist der Benutzer, der den Auftrag erstellt hat. Optional kann eine Beschreibung des Auftrags in dem gleichnamigen Feld hinterlegt werden. Es ist empfehlenswert, die Aufträge zu katalogisieren, falls sie für eine Multi-Server-Umgebung erstellt werden sollen.
466
Erstellung von Aufträgen und Operatoren
Jeder Auftrag muß mindestens einen Schritt beinhalten. Für die Definition der Schritte müssen die Registerkarte Schritte im Dialogfeld Neuer Auftrag – Eigenschaften ausgewählt und die Schaltfläche Neu angeklickt werden. Das Dialogfeld Neuer Auftragsschritt erscheint (Abbildung 22.3). Der Name des Schrittes wird im Feld Schrittname eingetragen. (In unserem Fall heißt der erste und einzige Schritt des Archivierungsauftrags sichern.) Im Feld Typ wählen wir Transact-SQL-Script (TSQL) aus, weil die Archivierung der Beispieldatenbank mit Hilfe einer SQL-Anweisung ausgeführt wird. Im Feld Befehl wird die entsprechende Anweisung (BACKUP DATABASE) und im Feld Datenbank die Beispieldatenbank eingetragen. Abbildung 22.3: Das Dialogfeld Neuer Auftragsschritt
Eine Transact-SQL-Anweisung kann entweder direkt oder indirekt durch die Ausführung einer Datei angegeben werden. Im zweiten Fall muß die Schaltfläche Öffnen angeklickt und die Datei ausgewählt werden. (Die Schaltfläche Analysieren dient dem Testen der Syntax der eingegebenen Anweisung ohne diese auszuführen.) Ein Auftrag wird nach seiner Erstellung in der msdb-Datenbank gespeichert. Die Speicherung eines Auftrags ist nur möglich, falls der SQL ServerAgent-Dienst davor gestartet wird!
22.3.3
Planung der Auftragsausführung
Jeder erstellte Auftrag kann entweder manuell (seitens des Eigentümers) oder mit Hilfe eines oder mehrere Zeitpläne gestartet werden. Ein geplanter Auftrag kann entweder zu einer einmaligen und festgelegten Zeit oder periodisch ausgeführt werden.
467
Automatische Ausführung der Administrationsaufgaben
Jeder Auftrag kann mehrere Auftragspläne haben. Bei einer Produktionsdatenbank z.B. ist es durchaus möglich, zwei Zeitpläne, abhängig von der Tageszeit, zu erstellen. Der eine Plan kann für die Stoßzeiten und der andere für die Zeiten, wann das System nicht belastet wird, gelten. Die Erstellung der Auftragsplanung mit Hilfe des Enterprise Managers erfolgt durch die Auswahl des SQL Server Agent (im Ordner Verwaltung) und das Anklicken des Unterordners Aufträge. Danach muß der Auftrag in Detailansicht (mit der rechten Maustaste) angeklickt und die Funktion Eigenschaften ausgewählt werden. Im Dialogfeld Auftrag -Eigenschaften (Abbildung 22.3) erscheint durch die Auswahl der Registerkarte Zeitpläne und der Schaltfläche Neuer Zeitplan das Dialogfeld Neuer Zeitplan. Um die Archivierung der Beispieldatenbank auf jeden Freitag um 20 Uhr festzulegen, müssen Wiederholt und die Schaltfläche Ändern angeklickt werden. Das Dialogfeld Zeitplan für wiederkehrende Aufträge bearbeiten erscheint (Abbildung 22.4). In dem Dialogfeld werden im Häufigkeit-Rahmen Wöchentlich markiert und im Häufigkeit pro Tag-Rahmen Einmalig auf 20 Uhr gesetzt. Schließlich muß im Rahmen Dauer das Anfangs- und das Enddatum (bzw. kein Enddatum) festgelegt werden. Abbildung 22.4: Das Dialogfeld Zeitplan für wiederkehrende Aufträge bearbeiten
22.3.4
Operatoren und Benachrichtigungen erstellen
Nach der Beendigung eines Auftrags gibt es mehrere Möglichkeiten für die Benachrichtigung beteiligter Personen. Eine Möglichkeit ist, die Meldung in das Windows NT/2000-Ereignisprotokoll zu schreiben (und zu hoffen, daß der Systemadministrator diese Meldung lesen wird). Eine bessere Alternative ist die explizite Benachrichtigung eines oder mehrerer Operatoren.
468
Erstellung von Aufträgen und Operatoren
Bevor ein Operator eine Benachrichtigung empfangen kann, muß er erstellt werden. Die Erstellung eines Operators mit Hilfe des Enterprise Managers erfolgt durch die Auswahl des SQL Server Agent (im Ordner Verwaltung) und das Anklicken (mit der rechten Maustaste) des Unterordners Operatoren. Das Dialogfeld Neue Operatoreigenschaften (Abbildung 22.5) erfolgt nach der Auswahl der Funktion Neuer Operator. Im Feld Name wird der Name des neuen Operators eingetragen. Die Benachrichtigung des Operators kann mit Hilfe von e-mail, pager und/oder net send-Kommando durchgeführt werden. Alle drei Optionen werden im Dialogfeld angeboten, wobei die entsprechenden Adressen angegeben werden müssen. (Falls die Benachrichtigung via pager ausgewählt wird, können im Pager empfangsbereit am-Rahmen die Arbeitszeiten des Operators eingetragen werden. (Mit Hilfe des Schalters Test können die Testmeldungen an die eingetragenen Adressen abgeschickt werden.) Abbildung 22.5: Das Dialogfeld Neue Operatoreigenschaften
Um einen oder mehrere Operatoren über die (erfolgreiche bzw. fehlerhafte) Beendigung des Auftrags zu benachrichtigen, muß die Registerkarte Benachrichtigungen im Dialogfeld Operator Eigenschaften ausgewählt werden. Das entsprechende Dialogfeld (Abbildung 22.6) erscheint. In diesem Dialogfeld können Benachrichtigungen für die existierenden System- und benutzerdefinierte Warnungen markiert werden.
469
Automatische Ausführung der Administrationsaufgaben Abbildung 22.6: Das Dialogfeld Operator Eigenschaften: Registerkarte Benachrichtigungen
22.3.5
Auftragschronik
Zusätzlich zur Erstellung bzw. Modifizierung eines Auftrags ist es auch möglich, die Information über seine bisherige Ausführung anzuzeigen. Die gesamte Information bezüglich der Auftragsausführung wird Auftragschronik genannt. Die Auftragschronik beinhaltet u.a. den letzten Ausführungszeitpunkt, den Status der Ausführung und, ob eine e-mail-Nachricht gesendet wurde. Das SQL Server-System speichert die Information bezüglich der Auftragsausführung in der Systemtabelle namens sysjobhistory der msdb-Datenbank. Dementsprechend stellt diese Sytemtabelle den Speicherungsort der Auftragschronik dar. Die Information in der Systemtabelle sysjobhistory kann mit Hilfe des Enterprise Managers gesichtet werden, indem der Auftrag in Detailansicht (mit der rechten Maustaste) angeklickt und die Funktion Auftragschronik ausgewählt wird. Der Inhalt der Systemtabelle sysjobhistory wird in Detailansicht des SQL Server Enterprise Managers ausgegeben. Sie beinhaltet: 왘 Start des Auftrags (Datum und Uhrzeit) 왘 Ergebnis (erfolgreich bzw. fehlgeschlagen) 왘 Benachrichtigte Operatoren 왘 Ausführungsdauer.
470
Erstellung von Aufträgen und Operatoren
Standardmäßig ist die Gesamtgröße der Systemtabelle sysjobhistory auf 1000 Reihen beschränkt, wobei jeder Auftrag insgesamt 100 Einträge speichern kann. (Wenn die Systemtabelle voll ist, wird ihr Inhalt geleert.) Sowohl die Gesamtgröße als auch die maximale Anzahl der Reihen pro Auftrag können mit Hilfe des Enterprise Managers geändert werden. In dem Fall müssen der SQL Server Agent (mit der rechten Maustaste) angeklickt und die Funktion Eigenschaften ausgewählt werden. Durch die Auswahl der Registerkarte Auftragssystem erscheint das Dialogfeld SQL Server Agent-Eigenschaften (Abbildung 22.7). In diesem Dialogfeld können die Werte für die Gesamtgröße der Tabelle sysjobhistory (Maximale Länge des Auftragsverlaufsprotokolls) und Reihenanzahl pro Auftrag (Maximale Zeilenanzahl pro Auftrag in Auftragsverlauf) neu bestimmt werden. (Der Inhalt der Systemtabelle sysjobhistory kann durch das Anklicken der Schaltfläche Protokoll löschen geleert werden.) Abbildung 22.7: Das Dialogfeld SQL Server Agent – Eigenschaften
Die Markierung des Feldes Größe des Auftragschronikprotokolls beschränken soll auf keinen Fall entfernt werden! Falls Ihr System viele Aufträge hat, ist es durchaus möglich, daß die Tabelle sysjobhistory schnell wächst und dadurch der zur Verfügung stehende Speicherplatz für die msdb-Datenbank verbraucht wird. In diesem Fall kann nur die Wiederherstellung der msdb-Datenbank mit Hilfe ihrer Sicherung durchgeführt werden (siehe auch Kapitel 20).
471
Automatische Ausführung der Administrationsaufgaben
22.4 Warnungen Die Information über die Ausführung eines Auftrags und SQL Server-Fehlermeldungen werden im Windows NT/2000-Ereignisprotokoll gespeichert. Der SQL Server Agent-Dienst wertet dieses Protokoll aus und vergleicht die existierenden Meldungen mit allen Warnungen, die für das System definiert sind. Damit wird eine Warnung automatisch ausgeführt, falls das entsprechende Ereignis stattfindet. Bevor eine Warnung erstellt wird, muß der Systemadministrator folgende Schritte in der angegebenen Reihenfolge tun: 왘 Sich vergewissern, daß der SQL Server Agent-Dienst läuft 왘 Sich
vergewissern, daß die Protokollierung der Ereignisse im Windows NT/2000-Ereignisprotokoll aktiviert ist
왘 Für jede Warnung einen oder mehrere Operatoren erstellen 왘 Die Warnung erstellen 왘 Die notwendigen Warnungsoptionen setzen.
Alle Warnungen können in zwei Gruppen unterteilt werden: 왘 Standardwarnungen 왘 benutzerdefinierte Warnungen
Die Standardwarnungen betreffen allgemeine Warnungen, die im Zusammenhang mit den unterschiedlichsten Systemfehlern stehen. Zu den Standardwarnungen gehören u.a.: 왘 Ungenügender Speicherplatz für eine Datenbank 왘 Der SQL Server wurde wegen eines Fehlers beendet 왘 Die Datenbank beinhaltet inkonsistente Daten.
Die benutzerdefinierten Warnungen sind spezielle Warnungen, die gewöhnlich im Zusammenhang mit den Geschäftsprozessen des Benutzers stehen. Dementsprechend müssen solche Warnungen vom Benutzer selbst (gewöhnlich mit Hilfe von Triggern) definiert werden. In den folgenden beiden Unterabschnitten wird die Erstellung der Warnungen der oben genannten Gruppen erörtert. Sowohl die Standard- als auch die benutzerdefinierten Warnungen können mit Hilfe des Warnungserstellungs-Assistenten definiert werden. Die Erstellung der Warnungen mittels der Assistenten ist leicht nachzuvollziehen und wird deswegen in diesem Buch nicht beschrieben.
472
Warnungen
22.4.1
Die Erstellung von Standardwarnungen
Standardwarnungen können auf der Basis: 왘 einer SQL Server-Fehlernummer 왘 eines SQL Server Schwierigkeitsgrades
definiert werden. Die folgenden beiden Unterabschnitte beschreiben die Erstellung der entsprechenden Standardwarnungen mit Hilfe des Enterprise Managers. 22.4.1.1
Warnung auf der Basis einer SQL Server-Fehlernummer erstellen
Wir werden Beispiel 14.4 nehmen, um zu zeigen wie eine Standardwarnung auf der Basis einer SQL Server-Fehlernummer erstellt werden kann. In diesem Beispiel wird eine der beiden Transaktionen wegen der deadlock-Situation vom System abgebrochen und zurückgesetzt. Um die »geopferte« Transaktion wieder zu starten, könnte (neben den anderen existierenden Möglichkeiten) eine entsprechende Warnung erstellt werden. Die Erstellung einer Warnung für die deadlock-Situation (oder irgendein anderes Ereignis) erfolgt durch die Auswahl des SQL Server Agents (im Ordner Verwaltung) und das Anklicken (mit der rechten Maustaste) des Unterordners Warnungen. Im Dialogfeld Neue Warnung – Eigenschaften (Abbildung 22.8), das nach der Auswahl der Funktion Neue Warnung erscheint, muß zuerst der Name der Warnung eingegeben werden. Durch das Anklicken von Fehlernr. kann die entsprechende Fehlernummer eingetragen werden. (Im Falle von deadlock handelt es sich um die Nummer 1205. Diese Nummer spezifiziert, daß das System eine deadlock-Situation entdeckt hat und der Prozeß deswegen abgebrochen wird.) Das System gibt automatisch die entsprechende Fehlermeldung auf der rechten Seite der Fehlernummer aus. Schließlich wird im Feld Datenbankname der Name der Datenbank (in unserem Fall beispiel) eingetragen. Der zweite Teil der Warnungsimplementierung stellt die Definition der Antwort auf die Warnung. Zuerst müssen die Registerkarte Antwort (Abbildung 22.9) angeklickt und der entsprechende Auftrag ausgewählt bzw. neu definiert werden (im Feld Auftrag ausführen). (In unserem Beispiel muß ein neuer Auftrag definiert werden, indem das ...-Feld angeklickt und der neue Auftrag erstellt wird.) Im Rahmen Zu benachrichtigende Operatoren werden alle Operatoren aufgelistet und die Art der Benachrichtigung festgelegt.
473
Automatische Ausführung der Administrationsaufgaben Abbildung 22.8: Das Dialogfeld Warnung – Eigenschaften
Abbildung 22.9: Das Dialogfeld Warnung – Eigenschaften: Registerkarte Antwort
474
Warnungen
Die Erstellung einer Warnung auf der Basis einer SQL Server-Fehlernummer verlangt, daß die Nummer in das Windows NT/2000-Ereignisprotokoll geschrieben wird. Standardmäßig wird die Fehlernummer 1205 nicht in das Ereignisprotokoll geschrieben, weil sie einen niedrigen Schwierigkeitsgrad hat. (Nur die Fehlernummer mit den Schwierigkeitsgraden >=19 werden automatisch in das Ereignisprotokoll geschrieben.) Nach der Erstellung der Warnung wird man vom System aufgefordert, zu entscheiden, ob der Fehler in das Ereignisprotokoll geschrieben werden soll oder nicht. 22.4.1.2
Warnung auf der Basis eines SQL ServerSchwierigkeitsgrades erstellen
Eine Warnung kann auch auf der Basis eines SQL Server-Schwierigkeitsgrades erstellt werden. Der Schwierigkeitsgrad eines Fehlers wird in Form einer Nummer zwischen 0 und 25 dargestellt. Je höher die Zahl desto schwerwiegender ist der Fehler. Alle Fehler mit dem Schwierigkeitsgrad 19 oder höher stellen schwerwiegende Systemfehler dar und werden deswegen automatisch in das Windows NT/2000-Ereignisprotokoll geschrieben. Mindestens ein Operator sollte für jeden schwerwiegenden Systemfehler definiert werden! Das SQL Server-System stellt dem Systemadministrator die vordefinierten Warnungen für alle Schwierigkeitsgrade >= 19 (siehe Abbildung 22.10). Diese Warnungen sind nur als Schablonen definiert und sollten deswegen erweitert werden, um spezifische Anforderungen einer Datenbank zu berücksichtigen. Mit Hilfe der explizit definierten Warnung für den Schwierigkeitsgrad 24 werden wir zeigen, wie eine solche Warnung geändert und erweitert werden kann. Zuerst müssen (in Detailansicht des Enterprise Managers) die Warnung mit der rechten Maustaste angeklickt und die Funktion Eigenschaften ausgewählt werden. Das Dialogfeld Demo: Sev. Error 24 – Eigenschaften (Abbildung 22.11) erscheint. In diesem Feld können der neue Name für die Warnung vergeben und der Datenbankname ausgewählt werden. (Es ist möglich, eine Warnung für eine spezifische oder alle Datenbanken des Systems zu definieren.) Durch die Auswahl der Registerkarte Antwort sollte mindestens ein Operator (mit der entsprechenden Benachrichtigungsmethode) ausgewählt werden. Eine erstellte Warnung kann jederzeit geändert werden. Um dies zu tun, müssen die entsprechende Warnung in Detailansicht des Enterprise Managers angeklickt und die Änderungen durchgeführt werden. Eine existierende Warnung kann auch durch ihre Auswahl (mit der rechten Maustaste) und das anschließende Anklicken der Funktion Löschen gelöscht werden.
475
Automatische Ausführung der Administrationsaufgaben Abbildung 22.10: Vordefinierte Warnungen in Detailansicht des Enterprise Managers
Abbildung 22.11: Das Dialogfeld Demo: Sev. Error 24 – Eigenschaften
476
Warnungen
22.4.2
Benutzerdefinierte Warnungen
Zusätzlich zu den Standardwarnungen, die beim Auftreten einer Systemmeldung aktiviert werden, können auch benutzerdefinierte Warnungen erstellt werden. Diese Warnungen charakterisieren die Existenz einer vom Benutzer selbst definierten Fehlernummer. Sie werden meistens für die Überprüfung der Geschäftsprozesse verwendet. Die Erstellung einer benutzerdefinierten Warnung wird in drei Schritten durchgeführt: 왘 die Definition einer benutzerdefinierten Fehlernummer 왘 die Definition des Ereignisses, das der benutzerdefinierten Fehlernum-
mer entspricht 왘 die Erstellung der entsprechenden Warnung.
Wir werden die Erstellung einer benutzerdefinierten Warnung mit Hilfe eines praktischen Beispiels zeigen. Diese Warnung wird aktiviert, falls das Lieferdatum eines Produktes älter als sein Bestelldatum ist. (Für die Definition der entsprechenden Tabelle siehe Beispiel 4.20.) 22.4.2.1
Benutzerdefinierte Fehlernummer erstellen
Eine benutzerdefinierte Fehlernummer kann entweder mit Hilfe des Enterprise Managers oder der Systemprozedur sp_addmessage erstellt werden. Beispiel 22.1 erstellt eine Fehlernummer für das nachfolgende Beispiel (siehe Beispiel 22.2). Beispiel 22.1
sp_addmessage 50010,16,'Lieferdatum ist älter als das Bestelldatum','us_english','true'
Die Systemprozedur sp_addmessage in Beispiel 22.1 definiert eine benutzerdefinierte Warnung mit der Fehlernummer 50010 und dem Schwierigkeitsgrad 16. Alle benutzerdefinierten Warnungen sind in der Systemtabelle sysmessages der master-Datenbank gespeichert. Die Fehlernummer ist als 50010 deklariert, weil jede benutzerdefinierte Meldung größer als 50000 sein muß. (Alle Fehlermeldungen 0 begin if @i > 0 begin insert into position (position_nr, bestell_nr, einzelpreis, menge) values (@j, @i, @einzelpreis, @menge) set @i = @i -1 end else begin set @j = @j – 1 set @i = 3000 end end update position set menge = 15 where bestell_nr in (1511, 2678)
Beispiel 24.4 zeigt die SELECT-Anweisung, die wir für die Untersuchung der Performance verwenden werden.
499
Die Durchführung der Maßnahmen zur Verbesserung der Performance Beispiel 24.4
select bestellung.bestell_nr, bestell_datum, position.einzelpreis from bestellung, position where bestellung.bestell_nr = position.bestell_nr and position.menge = 15
Beide Tabellen werden nach der Erstellung der drei Indizes in Beispiel 24.5 in heaps gespeichert, weil keiner der Indizes ein clustered-Index ist. Beispiel 24.5
create unique index i_bestellung_bestellnr on bestellung(bestell_nr) create index i_position_posno on position (position_nr) create index i_pos_bestellnr on position (bestell_nr)
Abbildung 24.1 zeigt die textuelle Darstellung der Ausführung der Abfrage aus Beispiel 24.4 nach der die drei Indizes in Beispiel 24.5 erstellt wurden. Für die Darstellung der textuellen Form des Ausführungsplans muß die SHOWPLAN_TEXT- bzw. SHOWPLAN_ALL-Option der SET Anweisung aktiviert werden. (Um die Ausgabe des Ausführungsplans einer SELECTAnweisung graphisch darzustellen, muß die Ikone Geschätzten Ausführungsplan zeigen in der Symbolleiste des Query Analyzers angeklickt werden.) Der Ausführungsplan in Abbildung 24.1 muß von unten nach oben gelesen werden. Dementsprechend benutzt der SQL Server-Optimierer zuerst den erstellten Index i_bestellung_bestellnr für die Indexsuche über die Werte der Spalte bestell_nr in den Tabellen position und bestellung. Als nächster Operator ist der Bookmark Lookup-Operator angewendet worden. Bookmark Lookup stellt den Reihenidentifikator (Row IDentifier – RID) dar, der für das schnelle Suchen einer Reihe verwendet werden kann. In unserem Fall wird BOOKMARK Lookup 1000 für das Suchen der Reihen der Tabelle bestellung verwendet, während BOOKMARK Lookup 1002 die Suche der Reihen der Tabelle position ermöglicht. Zwischen den beiden Operationen führt der SQL Server-Optimierer das geschachtelte Loop Join-Verfahren (siehe Kapitel 10) durch, das für die Ausführung der Join-Operation in Beispiel 24.2 verwendet wird. Die physikalische Struktur der Tabellen bestellung und position kann durch die Einführung eines clustered-Index geändert werden. Beispiel 24.7 erstellt zwei clustered-Indizes für die Tabellen bestellung und position. Vor der Erstellung der neuen Indizes müssen die existierenden Indizes in Beispiel 24.5 gelöscht werden (siehe Beispiel 24.6)
500
Komponenten zur Überwachung der Performance
StmtText ---------------------------------------------------------------------|--Bookmark Lookup(BOOKMARK:([Bmk1000]), OBJECT:([beispiel]. [dbo].[bestellung])) |--Nested Loops(Inner Join, OUTER REFERENCES:([position].[bestell_nr])) |--Table Scan(OBJECT:([beispiel].[dbo].[position]), WHERE: ([position].[menge] = 15)) |--Index Seek(OBJECT:([beispiel].[dbo].[bestellung].[i_bestellung_bestellnr]), SEEK:([bestellung].[bestell_nr]=[position].[bestell_nr]) ORDERED FORWARD)
Abbildung 24.1: Die textuelle Darstellung des Ausführungsplans mit heap-Tabellen
Beispiel 24.6
drop index bestellung.i_bestellung_bestellnr drop index position.i_position_posno drop index position.i_pos_bestellnr Beispiel 24.7
create unique clustered index ci_bestellung_bestellnr on bestellung(bestell_nr) create clustered index ci_position_posnr on position (position_nr)
Die Erstellung der beiden clustered-Indizes in Beispiel 24.7 verursacht die Änderung der physikalischen Speicherung der beiden Tabellen. Damit werden alle Reihen der Tabelle bestellung nach den Werten der Spalte bestell_nr sortiert auf der Platte gespeichert. (Dasselbe gilt für die Reihen der Tabelle position: Sie werden nach den Werten der Spalte position_nr sortiert.) Abbildung 24.2 zeigt die textuelle Darstellung des neuen Ausführungsplans. Wie aus Abbildung 24.2 ersichtlich, wird die Anzahl der Operationen im Ausführungsplan reduziert (von 5 auf 3, falls die beiden clustered-Indizes, wie in Beispiel 24.7 verwendet werden). Diese Änderungen werden signifikante Performance-Gewinne für die Ausführung der Abfrage in Beispiel 24.7 mit sich bringen.
24.5.2
SQL Server spezifische Performance-Werkzeuge
Zusätzlich zu den in diesem Kapitel schon beschriebenen Sperren und Benutzerverbindungen, stellt die Protokollierung im Transaktionsprotokoll einen weiteren SQL Server spezifischen Performance-Faktor. Alle diese Performance-Faktoren können mit Hilfe des SQL Server Profilers, mehreren Systemprozeduren, entsprechenden Transact-SQL-Anweisungen und dem DBCC-Kommando überwacht werden.
501
Die Durchführung der Maßnahmen zur Verbesserung der Performance Abbildung 24.2: Die textuelle Darstellung des Ausführungsplans mit clustered-Tabellen
StmtText ---------------------------------------------------------------------select bestellung.bestell_nr, bestell_datum, position.einzelpreis from bestellung, position where bestellung.bestell_nr = position.bestell_nr and position.menge = 15 StmtText ---------------------------------------------------------------------|--Nested Loops(Inner Join, OUTER REFERENCES:([position].[bestell_nr])) |--Clustered Index Scan(OBJECT:([beispiel].[dbo].[position]. [ci_position_posnr]), WHERE: ([position].[menge]=15)) |--Clustered Index Seek (OBJECT:([beispiel].[dbo].[bestellung]. [ci_bestellung_bestellnr]), SEEK:([bestellung].[bestell_nr]=[position].[bestell_nr]) ORDERED FORWARD)
In diesem Abschnitt werden wir alle Systemprozeduren und Transact-SQLAnweisungen erörtern, die im Zusammenhang mit der Performance stehen. Der SQL Server Profiler wird zusammen mit dem Indexoptimierungsassistenten am Ende dieses Kapitels beschrieben. 24.5.2.1
Überwachen der SQL Server-Aktivitäten mit Hilfe der Systemprozeduren
Folgende Systemprozeduren können für die Überwachung der SQL ServerAktivitäten verwendet werden: 왘 sp_lock 왘 sp_helpindex 왘 sp_monitor 왘 sp_who 왘 sp_spaceused
Die beiden ersten Systemprozeduren sp_lock und sp_helpindex geben die gesamte Information bezüglich der Sperren bzw. Indizes aus. Diese Systemprozeduren sind in Kapitel 14 bzw. Kapitel 9 ausführlich beschrieben. Die Systemprozedur sp_monitor gibt SQL Server-Statistiken (Anzahl von Sekunden, die der Prozessor für die SQL Server-Aktivitäten verbraucht hat, Anzahl von Ein/Ausgabeoperationen des SQL Servers usw.) aus. Die Systemprozedur sp_who gibt die Information über aktuelle SQL ServerBenutzer, wie Systemprozeß-ID, Prozeßstatus, verwendete Datenbank usw. aus. Die Systemprozedur sp_spaceused ist eine Systemprozedur, die die Größe des für Daten und Indizes verwendeten Plattenspeichers ausgibt.
502
Komponenten zur Überwachung der Performance
24.5.2.2
Überwachen der SQL Server-Aktivitäten mit Hilfe der SQLAnweisungen
Zwei Transact-SQL-Anweisungen können verwendet werden, um SQL Server-Statistiken anzuzeigen: 왘 SET STATISTICS_TIME 왘 SET STATISTICS_I/O
Beide Anweisungen sind in Kapitel 10 ausführlich beschrieben. 24.5.2.3
Überwachen der SQL Server-Aktivitäten mit Hilfe des DBCCKommandos
Das DBCC-Kommando hat folgende beide Anwendungsgebiete: 왘 die Überprüfung und, falls notwendig, die Wiederherstellung der inkon-
sistenten logischen Datenbankobjekte und der physikalischen Datenstrukturen eines SQL Server-Systems 왘 die Überprüfung der Performance und der Aktivitäten des ganzen SQL
Server-Systems. Die Optionen des DBCC-Kommandos, die zum ersten Anwendungsgebiet benutzt werden können, sind in Kapitel 23 beschrieben. Folgende Optionen gehören zum zweiten Anwendungsgebiet: 왘 SHOW_STATISTICS 왘 MEMUSAGE 왘 PERFMON
Die SHOW_STATISTICS-Option berechnet die aktuellen Verteilungsstatistiken für einen Tabellenindex bzw. eine Spalte. Diese Option gibt die Anzahl der für die Berechnung der Verteilungsstatistiken verwendeten Reihen, die Anzahl der existierenden Histogrammwerte usw. aus. Die MEMUSAGEOption gibt die Information über den Verbrauch der Prozessorzeit zurück. Diese Option gibt den Inhalt des Arbeitsspeichers aus, der von den logischen Datenbankobjekten verwendet wurde. Falls die zusätzliche Angabe PROCEDURE verwendet wird, wird die gesamte Information über die zwölf größten Datenbankobjekte im Prozedur-Cache ausgegeben. Die PERFMON-Option gibt alle Typen der Performance-Statistiken aus: Platten Ein- und Ausgabe (mit Hilfe der IOSTATS-Angabe), Verwendung von Cache bzw. des Arbeitsspeichers (mit Hilfe der LRUSTATS-Angabe) und die Netzwerkaktivitäten (mit Hilfe der NETSTATS-Angabe).
24.5.3
Werkzeuge zur Überwachung der Systemressourcen
Alle Systemressourcen wie Arbeitsspeicher oder Plattenein- und ausgabe können mit zwei Werkzeugen untersucht werden:
503
Die Durchführung der Maßnahmen zur Verbesserung der Performance 왘 Windows NT/2000-Ereignisanzeige (Event Viewer) 왘 Systemmonitor
24.5.3.1
Windows NT/2000-Ereignisanzeige
Mit der Ereignisanzeige können Windows NT/2000-Ereignisprotokolle gesichtet werden. Der Aufruf dieser Komponente erfolgt durch die Auswahl der Funktionsfolge: Start -> Programme -> Verwaltung (Allgemein) -> Ereignisanzeige. (Windows NT/2000-Ereignisprotokolle sind in Kapitel 23 ausführlich beschrieben.) 24.5.3.2
Der Systemmonitor
Der Systemmonitor ist eine Windows NT/2000-Komponente, mit der sowohl die Aktivitäten des SQL Servers als auch die des Betriebssystems selbst überwacht werden können. Die Stärke des Systemmonitors ist, daß er eng in Windows NT/2000 integriert ist, und damit zuverlässige Performance-Aussagen liefert. Die Benutzung des Systemmonitors kann die Systemeffizienz verringern. Bei einer Einprozessormaschine verringert sich die Systemeffizienz um etwa 5%, während der Zeit, in der der Systemmonitor aktiv ist. Deswegen sollte in Erwägung gezogen werden, den Systemmonitor auf einem anderen Rechner, wo der erste Server registriert ist, laufen zu lassen. Um den Systemmonitor zu starten, muß Systemmonitor in der Microsoft SQL Server-Programmgruppe angeklickt werden. Danach erscheint das Dialogfeld »Systemmonitor«. Der Systemmonitor gibt u.a. die Information über folgende Parameter aus: 왘 Cache-Trefferquote 왘 E/A-Stapeleinträge pro Sek. 왘 E/A-Gelesene Seiten pro Sek. 왘 E/A-Seiten-Schreiboperationen pro Sek.
Die angezeigten Parameter geben ein unzureichendes Bild über die gesamte Performance des SQL Server-Systems. Der Systemmonitor ermöglicht auch die Anzeige weiterer Parameter.
24.5.4
Der SQL Server Profiler
Der SQL Server Profiler ist ein graphisches Werkzeug, mit dem der Systemadministrator viele Datenbank- und Server-Aktivitäten überwachen kann. Dieses Werkzeug kann entweder die aktuelle Information direkt ausgeben oder diese in Dateien für die spätere Verwendung speichern. Folgende Aktivitäten werden vom SQL Server Profiler überwacht:
504
Komponenten zur Überwachung der Performance 왘 Login-Id-Verbindungen, -Versuche und -Fehlverbindungen 왘 Prozessorzeit, die eine SQL-Anweisung braucht 왘 Alle DML-Anweisungen (SELECT, INSERT, UPDATE und DELETE) 왘 Die Anfangs- und die Endzeit einer Datenbankprozedur.
SQL Server Profiler ist der neue Name für das SQL Server 6.5-Werkzeug namens SQL Trace.
24.5.5
Der Indexoptimierungsassistent
Der Indexoptimierungsassistent ermöglicht den Auswahl- und Erstellungsprozeß für Indizes zu automatisieren. Dieser Assistent ist eng mit dem schon beschriebenen Werkzeug namens SQL Server Profiler verbunden. Die spezifische Funktionalität des SQL Server Profilers, die vom Indexoptimierungsassistenten verwendet wird, besteht in der Überwachung der benutzerdefinierten Anweisungsfolgen sowie in der Ausgabe der Performance-Information in bezug auf diese Folgen. Der SQL Server Profiler wird benutzt, um die notwendige Information in bezug auf eine SQL-Anweisungsfolge in die Datei mit dem Suffix ».trc« zu speichern. (Als Alternative zur Benutzung des SQL Server Profilers kann auch eine Datei verwendet werden, die SQL-Anweisungen enthält.) Die vom SQL Server Profiler erstellte Datei kann anschließend vom Indexoptimierungsassistenten gelesen und bearbeitet werden. Um den SQL Server Profiler zu starten, muß im Menü Extras der Symbolleiste des Enterprise Managers die Funktion SQL Profiler angeklickt werden. Die Oberfläche des SQL Server Profilers erscheint. Danach muß im DateiMenü Neu angeklickt und Ablaufverfolgung ausgewählt werden. Im Dialogfeld Ablaufverfolgungseigenschaften (Abbildung 24.3) muß der Ablaufverfolgungsname eingetippt und eine Ausgabedatei für die ProfilerInformation (im Feld In Datei speichern) ausgewählt werden. Nach der Auswahl der Schaltfläche Ausführen wird der Query Analyzer benutzt, um die in Beispeil 24.8 angegebene Abfrage auszuführen (siehe Abbildung 24.4). Schließlich wird der SQL Server Profiler durch das Anklicken von Ablaufverfolgung beenden im Menü Datei beendet. Wir werden ein Beispiel nehmen, um die Arbeit des Indexoptimierungsassistenten zu demonstrieren. Das Beispiel beinhaltet eine Abfrage (siehe Beispiel 24.8), die die beiden in Beispiel 24.1 erstellten Tabellen bestellung und position verwendet. Sie wird als Eingabe für den SQL Server Profiler verwendet. (Es wird angenommen, daß keine Indizes für die beiden Tabellen existieren.)
505
Die Durchführung der Maßnahmen zur Verbesserung der Performance Abbildung 24.3: Das Dialogfeld Ablaufverfolgungseigenschaften
Abbildung 24.4: Die Ablaufverfolgung der Abfrage in Beispiel 24.8
506
Komponenten zur Überwachung der Performance Beispiel 24.8
delete from position where bestell_nr in (1300, 1400) select bestellung.bestell_nr, bestellung.liefer_datum from bestellung where bestellung.bestell_nr between 806 and 1600 and not exists (select position.bestell_nr from position where bestellung.bestell_nr= position.bestell_nr)
24.5.5.1
Arbeiten mit dem Indexoptimierungsassistenten
Alles, was wir bis jetzt gemacht haben, waren Vorbereitungsarbeiten. Die Verwendung des Indexoptimierungsassistenten fängt erst jetzt an. Um diesen Assistenten zu benutzen, muß die Ikone Assistenten auswählen in der Symbolleiste des Enterprise Managers angeklickt, der Ordner Verwaltung geöffnet und der Indexoptimierungsassistent ausgewählt werden (siehe Abbildung 24.5). Abbildung 24.5: Indexoptimierungsassistent: Das Anfangsfenster
Im nächsten Schritt werden der Datenbank-Server und die Datenbank ausgewählt (siehe Abbildung 24.6). In diesem Schritt ist es auch möglich, die Optionen in bezug auf die Indexauswahl zu spezifizieren. Es existieren insgesamt drei Optionen: 왘 alle vorhandenen Indizes beibehalten 왘 indizierte Sichten hinzufügen 왘 Optimierungsmodus auswählen
507
Die Durchführung der Maßnahmen zur Verbesserung der Performance Abbildung 24.6: Das Dialogfeld Server und Datenbank auswählen
Die erste Option steht im Zusammenhang mit den existierenden Indizes und erlaubt ihre Einbeziehung bzw. Nichteinbeziehung in die Auswahl des Assistenten. Falls die existierenden Indizes einbezogen werden, ist es möglich, den Indexentwurf inkrementell zu ändern, während die zweite Alternative den ganzen Indexentwurf dem Assistenten überläßt. Die zweite Option steht im Zusammenhang mit den indizierten Views und bezieht die erstellten View-Indizes ein. Für große Datenbanken ist es oft erforderlich sehr viele Ressourcen bei der Indexerstellung zu verwenden. Der Indexoptimierungsassistent erlaubt dem Benutzer, über die Verwendung von Ressourcen zu entscheiden. Die drei Alternativen, die die dritte Option Optimierungsmodus bietet: 왘 schnell 왘 mittel 왘 gründlich
können verwendet werden, um zu entscheiden, ob viele oder wenig Ressourcen benutzt werden sollen. Die Option gründlich, die viele Ressourcen verwendet, ermöglicht eine ausführliche Analyse der Anweisungsfolge und damit eine genaue Auswahl von Indizes. Die Option schnell benutzt wenig Ressourcen und erstellt deswegen eine nicht so genaue Indexempfehlung. (Die Option mittel stellt eine mittlere Alternative dar.) Nach der Auswahl des Datenbank-Servers und der Datenbank muß die Ablaufverfolgungsdatei, die mit dem SQL Server Profiler erstellt wurde, dem Indexoptimierungsassistenten bekanntgemacht werden (siehe Abbildung 24.7).
508
Komponenten zur Überwachung der Performance Abbildung 24.7: Das Dialogfeld Arbeitsauslastung angeben
Neben der Bekanntgabe des Dateinamens erlaubt dieser Schritt zusätzliche Optionen anzuzeigen bzw. zu ändern (Abbildung 24.8). Zu diesen gehören: 왘 maximale Anzahl von Spalten in Indizes 왘 maximaler verfügbarer Speicherplatz für die empfohlenen Indizes 왘 maximale Anzahl von Abfragen aus der Ablaufverfolgungsdatei
Abbildung 24.8: Standard-Indexoptimierungsparameter anzeigen oder ändern
509
Die Durchführung der Maßnahmen zur Verbesserung der Performance
Im nächsten Schritt werden die zu optimierenden Tabellen ausgewählt (Abbildung 24.9). (Die beiden Tabellen bestellung und position werden markiert, weil sie für die Abfrage relevant sind.) Abbildung 24.9: Das Dialogfeld Zu optimierende Tabellen auswählen
Indexempfehlung ist der wichtigste Schritt bei der Arbeit des Indexoptimierungsassistenten. In diesem Schritt (Abbildung 24.10) werden vom Assistenten existierende sowie neue Indizes empfohlen. Für jeden Index werden der Name, die Spalten, die den Index bilden und der Typ (clustered oder Nichtclustered) angegeben. Für die Abfrage in Beispiel 24.4 empfiehlt der Indexoptimierungsassistent die Erstellung eines clustered-Index für die Spalte menge der Tabelle position und einen Nicht-clustered-Index für die Spalte bestell_nr der Tabelle bestellung. Im letzten Schritt ist es möglich die Empfehlungen des Indexoptimierungsassistenten zu akzeptieren oder abzulehnen. Falls die Empfehlungen akzeptiert werden, muß im Dialogfeld Termin für Auftrag für Indexaktualisierung planen (Abbildung 24.11) das Feld Änderungen übernehmen markiert werden. In diesem Fall werden die empfohlenen Indizes entweder sofort erstellt oder der Benutzer legt einen Plan für ihre Erstellung zu einem bestimmten Zeitpunkt fest. Zusätzlich dazu wird durch das Markieren des Feldes Skriptdatei speichern und die Angabe eines Dateinamens eine SQLSkriptdatei erstellt, die den ganzen Ablauf der Erstellung von empfohlenen Indizes enthält. Diese Datei kann später benutzt werden, um die Indizes auf einem anderen Rechner mit derselben Umgebung zu erstellen.
510
Komponenten zur Überwachung der Performance Abbildung 24.10: Das Dialogfeld Indexempfehlung
Abbildung 24.11: Das Dialogfeld Termin für Auftrag zur Indexaktualisierung planen
Beispiel 24.9 zeigt das vom Indexoptimierungsassistenten erstellte SQLSkript, das für die Erstellung von Indizes für die Abfrage (Beispiel 24.4) verwendet wird.
511
Die Durchführung der Maßnahmen zur Verbesserung der Performance Beispiel 24.9
/* Created by: Index Tuning Wizard */ /* Datum: 20.11.00 */ /* Uhrzeit: 12:49:13 */ /* Servername: NTB11904 */ /* Datenbankname: beispiel */ /* Arbeitsauslastungs-Dateiname: D:\sqlserver_2000_bsp\2000_sql2404.sql */ USE [beispiel] go SET QUOTED_IDENTIFIER ON SET ARITHABORT ON SET CONCAT_NULL_YIELDS_NULL ON SET ANSI_NULLS ON SET ANSI_PADDING ON SET ANSI_WARNINGS ON SET NUMERIC_ROUNDABORT OFF go DECLARE @bErrors as bit BEGIN TRANSACTION SET @bErrors = 0 CREATE NONCLUSTERED INDEX [bestellung2] ON [dbo].[bestellung] ([bestell_nr] ASC, [bestell_datum] ASC ) IF( @@error 0 ) SET @bErrors = 1 IF( @bErrors = 0 ) COMMIT TRANSACTION ELSE ROLLBACK TRANSACTION
24.6 Zusammenfassung Die Performance eines SQL Server-Systems kann durch folgende Systemkomponenten beeinflußt werden: 왘 Anwendungsprogramme 왘 Systemsoftware 왘 Systemressourcen
In bezug auf die Anwendungen spielen folgende Bereiche eine Rolle bei der Performance eines Systems: 왘 Benutzeranforderungen 왘 logisches bzw. physikalisches Design 왘 Benutzercode
512
Zusammenfassung
Die Komponenten der Datenbanksoftware, die die Performance beeinflussen, sind: 왘 der Optimierer 왘 Sperren
Die Systemressourcen, die die Performance beeinflussen können, sind: 왘 der Prozessor 왘 der Arbeitsspeicher 왘 die Plattenein- und ausgabe 왘 das Netzwerk
513
25
Datenreplikation
In diesem Kapitel wird die Möglichkeit gezeigt, wie der SQL Server gleiche Daten an mehreren Rechnern im Netz verarbeiten kann. Zuerst wird erläutert, wie die Datenreplikation funktioniert und welche unterschiedlichen Komponenten diesen Mechanismus bilden. Im zweiten Teil des Kapitels werden existierende Publikationstypen und Replikationsmodelle dargestellt.
25.1 Einführung In einigen EDV-Umgebungen ist es oft notwendig, Daten an mehreren Rechnern im Netz gleichzeitig verarbeiten zu können. Diese Eigenschaft kann heutzutage bei den Datenbanksystemen auf zwei unterschiedliche Arten gelöst werden: 왘 mit Hilfe des Zwei-Phasen-Commits 왘 mit Hilfe der Datenreplikation
Der Zwei-Phasen-Commit ist ein Mechanismus, der die Konsistenz aller an einer Transaktion beteiligten Datenbanken gewährleistet. Er wird verwendet, wenn innerhalb einer Transaktion Änderungen an zwei oder mehreren im Netz befindlichen Datenbanken durchgeführt werden. Die Voraussetzung für den Zwei-Phasen-Commit ist, daß alle beteiligten Datenbanken mit dem Transaktionsprotokoll erstellt wurden. Die Transaktion in einer solchen Umgebung muß immer einen Server haben, der die koordinierende Aufgabe übernimmt. MS Distributed Transaction Coordinator (DTC) ist die SQL Server-Komponente, die das Zwei-Phasen-Commit unterstützt.
Wir möchten an dieser Stelle noch einmal die wichtigsten Unterschiede zwischen dem Zwei-Phasen-Commit und der Datenreplikation hervorheben. Beim Zwei-Phasen-Commit handelt es sich um verteilte Datenbanken, wo nicht redundante Daten auf mehrere Knoten eines Netzes verteilt sind. Der Zwei-Phasen-Commit funktioniert immer synchron: Die Änderungen der Daten auf allen Servern im Netz werden gleichzeitig durchgeführt. Bei der Datenreplikation handelt es sich um mehrere Server im Netz, auf denen die von ihnen verwaltenden Daten (oder ein Teil davon) mehrfach vorhanden sind. Zusätzlich dazu werden alle Änderungen an den mehrfach vorhanden Daten asynchron (d.h. mit einer gewissen Zeitverzögerung zwischen den einzelnen Änderungen) durchgeführt.
515
Datenreplikation
Die Datenreplikation ist eine Alternative zum Zwei-Phasen-Commit, um die Konsistenz aller an einer Transaktion beteiligten Daten auf mehreren Servern im Netz zu gewährleisten. Im Unterschied zum Zwei-Phasen-Commit, wo alle Daten nur einmal vorkommen, existieren die Daten bei der Replikation mehrfach auf verschiedenen Servern im Netz.
25.1.1
SQL Server Datenreplikation – ein Überblick
Um die Datenreplikation bei den existierenden Datenbanksystemen zu ermöglichen, existieren zwei unterschiedliche Alternativen. Die Datenreplikation kann mit Hilfe: 왘 vonTransaktionsprotokollen 왘 von Triggern
implementiert werden. Der SQL Server verwendet beide Methoden, um Daten zu replizieren. Welche Methode verwendet wird, hängt vom Typ der Datenreplikation ab. (Die Definition der unterschiedlichen Replikationstypen wird später in diesem Kapitel gegeben.) Bei der Datenreplikation wird zwischen der sogenannten master/slaveund peer to peer-Konfiguration unterschieden. Die master/slave-Konfiguration kennzeichnet jenes Verfahren, wo zu jedem Zeitpunkt nur ein Server das Recht hat, Daten zu ändern. Bei der peer to peer-Konfiguration ist es möglich, daß mehrere Server zu demselben Zeitpunkt die replizierten Daten ändern. Der SQL Server 2000 unterstützt beide Konfigurationen. Die Datenreplikation beim SQL Server funktioniert auf der Basis des »Publizieren und Abonnieren«-Konzeptes. Der Quellserver publiziert die Daten, die die anderen Server im Netz abonnieren können. (Das Abonnieren kann für alle oder einen Teil der angebotenen Daten des Quellservers erfolgen.) Bevor wir uns mit den unterschiedlichen Rollen, die einzelne Server im »Publizieren und Abonnieren«-Konzept spielen können, beschäftigen, werden wir erläutern, was repliziert werden kann. Es existieren insgesamt zwei Arten von Daten, die eine Rolle bei der Datenreplikation spielen: 왘 Artikel 왘 Publikation
Ein Artikel ist die Basiseinheit des Replikationsprozesses und kann entweder eine Tabelle oder ein Teil einer Tabelle sein. Ein Artikel kann nicht publiziert werden, sondern existiert nur als Teil einer Publikation.
516
Einführung
Eine Publikation enthält eines oder mehrere der folgenden Elemente, die gleichzeitig Artikel darstellen: 왘 Tabelle 왘 vertikal partitionierte Tabelle 왘 horizontal partitionierte Tabelle 왘 vertikal und horizontal partitionierte Tabelle.
Eine Publikation darf folgendes nicht enthalten: 왘 eine der Systemdatenbanken 왘 die Systemtabellen der master-Datenbank.
25.1.2
Publikations-, Abonnement- und Verteilungsserver
Logisch gesehen existieren insgesamt drei Typen von Servern, die bei der Datenreplikation eine Rolle spielen: 왘 Publikationsserver (Verleger) 왘 Abonnementserver (Abonnent) 왘 Verteilungsserver (Verteiler)
Der Publikationsserver ist für die Verwaltung der replizierten Daten verantwortlich. Zusätzlich dazu schickt er alle zu replizierenden Daten an den Verteilungsserver, der anschließend diese Daten an die Abonnenten verteilt. Der Verteilungsserver ist für den Empfang und die Weiterverteilung der replizierenden Daten verantwortlich. Zu diesem Zweck wird vom Verteilungsserver eine Verteilungsdatenbank (distribution database) verwaltet, die alle zu replizierenden Daten enthält. Der Abonnementserver empfängt die für ihn vorgesehenen replizierten Daten und verwaltet sie anschließend. Verleger (Publikationsserver), Verteiler und Abonnent sind drei Rollen, die zum logischen Konzept beim SQL Server gehören. Ein Server kann eine oder mehrere dieser Rollen in einem spezifischen Replikations-Szenario spielen. Zum Beispiel stellt in vielen praktischen Fällen ein SQL Server sowohl den Publikations- als auch den Verteilungsserver dar. Genauso kann es vorkommen, daß ein Server alle drei Rollen in einer Konfiguration übernimmt. Abbildung 25.1 zeigt drei Server, wo jeder Server alle drei Replikationsrollen ausübt.
517
Datenreplikation Abbildung 25.1: SQL ServerSysteme, die mehrfache Verteiler und Abonnenten darstellen
25.2 Publikationstypen SQL Server unterstützt drei unterschiedliche Publikationstypen: 왘 transaktionale 왘 Snapshot 왘 Merge
Alle Publikationstypen können innerhalb einer Datenbank verwendet werden, weil unterschiedliche Publikationen einer Datenbank verschiedene Publikationstypen haben können. Folgende Unterabschnitte beschreiben alle drei Typen.
25.2.1
Transaktionale Publikation
Bei der transaktionalen Publikation wird das Transaktionsprotokoll der entsprechenden Datenbank für die Replikation von Daten verwendet. Alle Transaktionsprotokolle, die für die Datenreplikation benutzt werden sollen, sind vom System markiert. Alle Tabellen, die die transaktionale Publikation verwenden, müssen den Primärschlüssel explizit enthalten. Der Primärschlüssel ist notwendig, um Reihen einer publizierten Tabelle eindeutig identifizieren zu können. Die transaktionale Publikation kann Tabellen (bzw. ihre Teile) und/oder Datenbankprozeduren replizieren. Die Replikation mit Hilfe von Datenbankprozeduren erhöht die Performance, weil die Menge von transferierten Daten übers Netz wesentlich kleiner ist. (In so einem Fall wird anstatt Daten nur der Text der Datenbankprozedur übers Netz gesendet.)
518
Publikationstypen
Bevor die transaktionale Publikation zum ersten Mal gestartet werden kann, muß die entsprechende Datenbank auf jedem Abonnementserver wiederhergestellt werden. 25.2.1.1
Wie funktioniert die transaktionale Publikation?
Bei der Durchführung der transaktionalen Publikation spielen folgende Komponenten eine Rolle: 왘 der Protokoll-Leseagent (Log Reader Agent) 왘 die Verteilungsdatenbank (distribution database) 왘 der Synchronisationsprozeß 왘 der Verteilungsagent (Distribution Agent).
Die Transaktionen, die Daten für die Replikation beinhalten, werden vom Publikationsserver im Transaktionsprotokoll durch eine Markierung extra gekennzeichnet. Der Protokoll-Leseagent durchsucht das Transaktionsprotokoll nach solchen markierten Transaktionen und überträgt sie zum Verteilungsserver. Der Verteilungsserver speichert alle für die Replikation vorbereiteten Transaktionen in die Verteilungsdatenbank. Diese Transaktionen bleiben in der Datenbank erhalten, bis alle Abonnenten die ihnen zugehörigen Daten empfangen bzw. geholt haben. Der Synchronisationsprozeß wird bei der Erstellung der Replikation angewendet. Er gewährleistet, daß das Schema und die Daten der Datenbank auf der Abonnentenseite eine genaue Abbildung des Schemas und der Daten der zu replizierenden Datenbank auf der Verlegerseite sind. Der Synchronisationsprozeß wird immer bei neuen Abonnementservern angewendet. Nach der Initialisierung eines neuen Abonnenten durch den Synchronisationsprozeß wird keine weitere Synchronisation durchgeführt. Der Verteilungsprozeß verteilt alle zu replizierenden Publikationen, die sich in der Verteilungsdatenbank befinden, an alle Abonnenten. Jedem Abonnenten wird ein spezifischer Verteilungsprozeß zugewiesen. Nach der erfolgreichen Beendigung aller Verteilungsprozesse bezüglich einer Transaktion, wird der entsprechende Eintrag in der Verteilungsdatenbank entfernt. Der Verteilungsagent repliziert die Transaktionen an einzelne Abonnenten als SQL-Anweisungsfolge bzw. Datenbankprozeduren. Die Verwendung der SQL-Anweisungen (anstatt der Übertragung der modifizierten Daten) ist vorteilhaft, weil das Netz wesentlich weniger belastet wird. Diese Vorgehensweise erklärt auch, warum die Daten einer zu replizierenden Datenbank auf den Publikations- und den Abonnementservern vorher synchronisiert werden müssen.
519
Datenreplikation
25.2.2
Snapshot-Publikation
Die Snapshot-Publikation kennzeichnet die einfachste Form der Datenreplikation. Bei diesem Publikationstyp werden die zu publizierenden Daten vom Publikationsserver zu jedem Abonnenten kopiert. (Der Unterschied zwischen der Snapshot- und der transaktionalen Publikation ist, daß die Snapshot-Publikation alle zu publizierenden Daten verschickt, während die transaktionale nur die im Transaktionsprotokoll gespeicherten Daten sendet.) Die Snapshot-Publikation wird mit Hilfe des bcp-Dienstprogramms durchgeführt. Der Publikationsserver erstellt bei diesem Vorgang zwei Gruppen von Dateien: 왘 Schemadateien 왘 Datendateien
Schemadateien enthalten die Schemata aller Tabellen, die an der Publikation teilnehmen. Diese Dateien sind durch das Suffix ».sch« gekennzeichnet. Die Datendateien enthalten die zu replizierenden Daten. Sie sind durch das Suffix ».tmp« gekennzeichnet. Sowohl die Schema- als auch die Datendateien bilden die sogenannte Synchronisationsmenge. Transaktionale und Snapshot-Publikation stellen die schon beschriebene master/slave-Konfiguration dar. Daß heißt, daß bei diesen beiden Publikationstypen die Datenänderung nur auf dem Publikationsserver ausgeführt wird. Dementsprechend sind die Daten auf dem Abonnementserver nur zum Lesen da. (Die einzige Änderung der zu replizierenden Daten auf einem Abonnementserver wird durch den Replikationsprozeß verursacht.) Im Unterschied zu der transaktionalen verwendet die Snapshot-Publikation nicht den Primärschlüssel der zu replizierenden Tabelle. Der Grund ist einleuchtend: eine Snapshot-Publikation kopiert die ganze Datenbank und nicht, wie bei der transaktionalen, nur einzelne Reihen. Ein weiterer Unterschied zwischen diesen beiden Publikationstypen ist, daß der Zeitunterschied zwischen der Datensynchronisation bei der transaktionalen Publikation wesentlich kürzer ist als bei der Snapshot-Publikation. Der Grund dafür ist, daß die Snapshot-Replikation alle Daten repliziert. Die Snapshot-Publikation verwendet die Verteilungsdatenbank nicht!
25.2.3
Merge-Publikation
Die Merge-Publikation stellt die peer to peer-Konfiguration dar. Dieser Publikationstyp erlaubt sowohl dem Publikations- als auch dem Abonnementserver die zu replizierenden Daten zu ändern. Aus diesem Grund kann es bei diesem Publikationstyp zu Änderungskonflikten kommen.
520
Publikationstypen
Die Merge-Publikation ist wegen der Änderungskonflikte wesentlich schwieriger zu implementieren als die anderen beiden Publikationstypen. 25.2.3.1
Wie funktioniert die Merge-Publikation?
Bei der Durchführung einer Merge-Publikation spielen folgende Komponenten einer Rolle: 왘 Snapshot-Agent 왘 Arbeitsordner des Verteilers (distribution working folder) 왘 Merge-Agent.
Nach der Erstellung einer Publikation auf dem Publikationsserver bereitet der Snapshot-Agent die zu replizierenden Daten vor und speichert sie im Arbeitsordner des Verteilers. (Die zu replizierenden Daten enthalten in diesem Fall alle Tabellenschemata und die dazugehörigen Daten.) Der Synchronisationsprozeß verwendet dann eine weitere Komponente – den MergeAgenten –, der die modifizierten Daten zu allen Abonnenten sendet. Vor dem Sendeprozeß speichert der Merge-Agent alle notwendigen Informationen, die für eventuelle Änderungskonflikte später benutzt werden können. Die Merge-Publikation verwendet die Verteilungsdatenbank lediglich für die Speicherung des Zustandes des Publikationsprozesses. Bei einer Merge-Publikation führt das SQL Server-System drei sehr wichtige Änderungen an den zu replizierenden Daten durch: 왘 die Erstellung (bzw. die Identifizierung) einer Spalte mit eindeutigen
Werten für jede zu replizierende Reihe 왘 das Hinzufügen mehrerer Systemtabellen 왘 die Erstellung von Triggern für alle Tabellen, deren Daten repliziert wer-
den. Der SQL Server erstellt (bzw. identifiziert) immer eine Spalte mit eindeutigen Werten in der zu replizierenden Tabelle. Falls die zu replizierende Tabelle schon eine Spalte vom Typ UNIQUEIDENTIFIER mit der ROWGUIDCOL-Eigenschaft enthält, werden ihre Werte vom System für die eindeutige Identifizierung jeder einzelnen zu replizierenden Reihe verwendet. Falls eine solche Spalte nicht existiert, wird sie vom System erstellt. (Der Name der vom System erstellten UNIQUEIDENTIFIER-Spalte ist rowguid.)
521
Datenreplikation
Eine Spalte vom Typ UNIQUEIDENTIFIER kann durchaus mehrere identische Werte (auf verschiedenen Rechnern) enthalten. Die ROWGUIDCOL-Eigenschaft garantiert, daß alle Werte der entsprechenden Spalte für alle existierenden Rechner auf der ganzen Welt eindeutig sind. (Damit ist die Eindeutigkeit der Reihen für alle Server, die am Replikations-Szenario teilnehmen, gewährleistet.) Das Hinzufügen neuer Systemtabellen dient der Erstellung der Information, mit der die Änderungskonflikte gelöst werden können. Der SQL Server speichert alle Änderungen in bezug auf die zu replizierenden Daten in zwei Systemtabellen: msmerge_contents und msmerge_tombstone und verknüpft sie mit der replizierten Tabelle, um Änderungskonflikte aufzuheben. Der SQL Server erstellt Trigger an allen im Replikations-Szenario beteiligten Servern und für jede zu replizierende Tabelle, um Datenänderungen an den Reihen verfolgen zu können. Diese Trigger speichern die entdeckten Änderungen in den Systemtabellen msmerge_contents und msmerge_tombstone. Die Konfliktauflösung wird durch den Merge-Agenten durchgeführt. Der Merge Agent benutzt die gespeicherte Historie der zu replizierenden Reihen in der Systemtabelle msmerge_contents, um Konflikte entweder aufgrund der im Voraus gesetzten Prioritäten oder benutzerdefiniert zu lösen. Die Auflösung der Konflikte mit Hilfe der gesetzten Prioritäten bedeutet, daß jeder Konflikt vom System automatisch auf der Basis der speziell definierten Prioritäten aufgelöst wird. (Ein Beispiel dafür ist die »Erster gewinnt«-Methode, bei der die erstausgeführte Änderung in bezug auf die anderen Vorrang hat.) Die benutzerdefinierte Auflösung basiert auf zusätzlichen Triggern, die vom Benutzer auf der Basis spezifischer Geschäftsprozesse implementiert werden müssen. (Die erste Methode wird standardmäßig vom System angewendet.)
25.3 Replikationsmodelle Im vorherigen Abschnitt haben wir drei Replikationstypen (transaktionale, Snapshot und Merge) eingeführt. Diese drei Typen stellen die generelle Funktionalität, die vom System für die Publikation von Daten angeboten wird, dar. Demgegenüber werden die Replikationsmodelle von den Unternehmern verwendet, um ihre spezifische Datenreplikationen zu implementieren. Abhängig von den Anforderungen an das Replikations-Szenario existieren viele unterschiedliche Replikationsmodelle. In der Praxis aber werden meistens die folgenden drei Modelle verwendet:
522
Replikationsmodelle 왘 Zentraler Verleger mit dem Verteiler 왘 Zentraler Abonnent mit multiplen Verlegern 왘 Multiple Verleger mit multiplen Abonnenten.
Jedes Replikationsmodell kann theoretisch mit jedem Publikationstyp erstellt werden. Trotzdem gibt es für jedes Modell immer den passenden Publikationstyp.
25.3.1
Zentraler Verleger mit dem Verteiler
In diesem Modell gibt es einen Publikations- und einen Verteilungsserver. Der Verleger erstellt die Publikationen, die dann vom Verteiler an alle Abonnenten repliziert werden. Dieses Modell ist gleichzeitig das Standardmodell jedes SQL Server-Systems. Falls die Größe der zu replizierenden Daten gering ist, können der Verleger und der Verteiler auf demselben Rechner liegen. Andererseits empfiehlt es sich, separate Rechner (wegen der Performance) für diese zwei Aufgaben zu verwenden. (Bei den Replikations-Szenarien, wo sehr viele Daten repliziert werden sollen, stellt der Verteiler gewöhnlich den Flaschenhals dar.) Abbildung 25.2 zeigt das Modell mit dem zentralen Verleger und dem Verteiler. Abbildung 25.2: Zentraler Verleger mit dem Verteiler
523
Datenreplikation
Bei diesem Modell sind die Anforderungen gewöhnlich so, daß alle Abonnenten ausschließlich Nur-Lese-Daten enthalten. Deswegen wird in der Praxis dieses Modell meistens mit Hilfe des transaktionalen Publikationstyps implementiert. (Die Snapshot-Publikation stellt auch eine mögliche Alternative dar.)
25.3.2
Zentraler Abonnent mit multiplen Verlegern
Dieses Replikationsmodell kann am besten durch ein Beispiel dargestellt werden. Eine Firma beschäftigt mehrere regionale Vertriebsbeauftragte, die ihre Daten (z.B. über verkaufte Ware) tagsüber auf den Laptops speichern und abends im Hotel dem zentralen Firmenrechner die geänderten Daten senden. Für dieses Modell kann entweder die transaktionale oder die Merge-Publikation verwendet werden, abhängig davon, welche Daten auf dem Abonnementserver von jedem Verleger geändert werden können. Falls mehrere Verleger Änderungen auf den gleichen Daten durchführen können, muß unbedingt die Merge-Publikation angewendet werden. Andererseits ist es möglich auch die transaktionale Publikation zu benutzen. (Im zweiten Fall ist jede zu replizierende Tabelle horizontal fragmentiert und jeder Verleger hat den exklusiven Zugriff auf sein eigenes Tabellenfragment.)
25.3.3
Multiple Verleger mit multiplen Abonnenten
Das Replikationsmodell, in dem alle (oder einige) Server, die am Replikations-Szenario beteiligt sind, sowohl die Rolle des Verlegers als auch die Rolle des Abonnenten spielen, wird multiple Verleger mit multiplen Abonnenten genannt. In den meisten Fällen beinhaltet dieses Modell auch mehrere Verteiler, die zusammen mi dem jeweiligen Verleger auf demselben Rechner plaziert sind (siehe Abbildung 25.1). Für dieses Modell kann nur die Merge-Publikation verwendet werden, weil Publikationen auf allen Verteilern modifiziert werden können.
25.4 Datereplikationen verwalten Nachdem alle Voraussetzungen für eine spezifische Datenreplikation überprüft und ein entsprechendes Modell erstellt wurde, ist es möglich die Replikation auf den vorgesehenen Rechnern zu implementieren. Die Implementierung eines Replikations-Szenarios kann am einfachsten mit Hilfe mehrerer Assistenten und in mehreren Schritten ausgeführt werden. Diese Schritte enthalten das Setzen des Verteilers, des Verlegers und der Abonnenten.
524
Datereplikationen verwalten
Alle Rechner, die an einem Replikations-Szenario beteiligt sind, müssen vorher mit Hilfe des Enterprise Managers auf dem Publikationsserver registriert werden.
25.4.1
Setzen des Verteilungs- und Publikationsservers
Bevor die Datenbank, die zu replizierende Daten enthält, auf dem Publikationsserver installiert wird, muß der Verteilungsserver konfiguriert und die Verteilungsdatenbank erstellt werden. Der Verteilungsserver kann mit Hilfe von: 왘 Publizierungs- und Verteilungskonfigurations-Assistenten 왘 Systemprozeduren
erstellt und konfiguriert werden. 25.4.1.1
Publizierungs- und Verteilungskonfigurations-Assistent
Der Publizierungs- und Verteilungskonfigurations-Assistent erlaubt die Konfiguration des Verteilungsservers und die Erstellung der Verteilungsdatenbank. In einem weiteren Schritt wird auch der Publikationsserver konfiguriert. Abbildung 25.3: Der Schritt Verteiler auswählen
525
Datenreplikation
Mit diesem Assistenten werden: 왘 der lokale (oder ein anderer) Server als Verteilungsserver festgelegt 왘 die Eigenschaften des Verteilungsservers spezifiziert 왘 die Eigenschaften des Publikationsservers spezifiziert.
Nach der Festlegung des Verteilungsservers kann dieser Server mit Hilfe der Standard- bzw. benutzerdefinierten Optionen konfiguriert werden. Falls benutzerdefinierte Optionen verwendet werden, muß die Information über die Verteilungsdatenbank, den Verleger und die Publikationsdatenbank vorhanden sein (siehe Abbildung 25.3) Der Arbeitsordner für Replikationen muß auf dem Verteiler existieren, falls die Merge-Publikation verwendet wird. (Das Standardverzeichnis dieses Ordners ist /mssql/repldata.) 25.4.1.2
Verteiler und Verleger mit Hilfe von Systemprozeduren konfigurieren
Ein Verteiler, gemeinsam mit der Verteilungsdatenbank und dem Verleger, kann mit Hilfe folgender Systemprozeduren konfiguriert werden: 왘 sp_adddistributor 왘 sp_adddistributiondb 왘 sp_adddistpublisher
Die Systemprozedur sp_adddistributor konfiguriert den Verteilungsserver, indem sie eine neue Reihe in der Systemtabelle sysservers erstellt. Der einzige Parameter dieses Systemprozedur ist der Name des Servers. sp_adddistributiondb erstellt eine neue Verteilungsdatenbank und installiert das Verteilungsschema. Die Systemprozedur sp_adddistpublisher legt den Publikationsserver für den schon definierten Verteilungsserver fest. Die drei Systemprozeduren müssen in der Reihenfolge benutzt werden, in der sie beschrieben sind. Der SQL Server unterstützt drei weitere Systemprozeduren bezüglich des Publikationsservers: sp_changedistpublisher, sp_dropdistpublisher und sp_helpdistpublisher. Die erste Systemprozedur modifiziert die Eigenschaften eines spezifischen Verlegers, die zweite löscht den Verleger, der gleichzeitig als Verteilungsserver dient und die dritte gibt die Eigenschaften des angegebenen Verlegers zurück.
526
Datereplikationen verwalten
25.4.2
Setzen des Abonnementservers
Die Erstellung von Publikationen für einen oder mehrere Abonnenten muß immer auf dem Publikationsserver konfiguriert werden. Diese Aufgabe kann mit Hilfe des Enterprise Managers durchgeführt werden. In diesem Fall müssen die Schaltfläche Extras (in der Symbolleiste des Enterprise Managers) angeklickt und die Funktion Replikation ausgewählt werden. Durch die Auswahl der Unterfunktion Publizierung, Verteilung und Abonnenten konfigurieren können u.a., falls notwendig, neue Abonnenten (durch die Auswahl der Registerkarte Abonnenten und das Anklicken der Schaltfläche Neuer Abonnent) definiert werden (siehe Abbildung 25.4). Mit dieser Unterfunktion können auch folgende Aktivitäten durchgeführt werden: 왘 Verleger auswählen 왘 Publikationsdatenbank erstellen und/oder auswählen 왘 Benutzerkennungen für die Publikationszugriffsliste erstellen und/oder
verifizieren. Abbildung 25.4: Das Dialogfeld Verleger- und Verteilereigenschaften
527
Datenreplikation
25.4.2.1
Publizieren
Bevor die Publizierung von Daten gestartet werden kann, müssen eine oder mehrere Publikationen erstellt werden. Eine Publikation enthält einen oder mehrere Artikel, die ihrerseits Daten einer Tabelle beinhalten. Für jede Publikation gilt, daß sie Daten einer einzigen Datenbank enthalten kann. Der Publikationserstellungs-Assistent bietet die einfachste Methode, um eine Publikation zu erstellen. Dieser Assistent kann durch das Anklicken der Ikone Assistenten in der Symbolleiste des Enterprise Managers und der anschließenden Auswahl der Funktion Replikation gestartet werden. Mit Hilfe dieses Assistenten können: 왘 eine Publikation aus den Daten einer Datenbank erstellt werden 왘 Daten für die Publikation gefiltert werden 왘 Eigenschaften der Publikation definiert werden 왘 der Publikationstyp (transaktional, Snapshot, Merge) ausgewählt wer-
den. 25.4.2.2
Abonnieren
Bevor eine erstellte Publikation an die Abonnenten verschickt werden kann, müssen die Daten auf der Verleger- und Abonnentenseite synchronisiert werden. Dieser Prozeß wird gewöhnlich die Anfangssynchronisation genannt, die vom Snapshot-Agent durchgeführt wird. Nach der Synchronisation von Daten kann der Administrator zwischen dem pull- und dem push-Abonnement wählen. Der pull-Abonnement wird immer auf der Verlegerseite definiert, während ein push-Abonnement seitens des Abonnenten initiiert wird. Der SQL Server bietet: 왘 Pullabonnement-Assistenten 왘 Pushabonnement-Assistenten
um beide Abonnementarten zu definieren.
25.5 Zusammenfassung Die Datenreplikation ist beim SQL Server ein fester Bestandteil des Systems. (Bei den anderen Datenbankherstellern muß für diese Funktionalität extra bezahlt werden.) Der SQL Server verwendet das Transaktionsprotokoll, um die Daten zu replizieren. Es existieren insgesamt zwei Arten von Daten – Artikel und Publikation –, die beim SQL Server eine Rolle bei der Datenreplikation spielen. Eine Publikation enthält einen oder mehrere Artikel und stellt gleichzeitig die Replikationseinheit dar.
528
Zusammenfassung
Die Server, die bei der Datenreplikation teilnehmen, sind: 왘 Publikationsserver (Verleger) 왘 Verteilungsserver (Verteiler) 왘 Abonnementserver (Abonnent).
Der Publikationsserver ist für die Verwaltung von Daten verantwortlich. Der Verteilungsserver leitet die zu replizierenden Daten an die Abonnementserver weiter. Der Abonnementserver verwaltet die in Empfang genommenen Daten. SQL Server unterstützt drei Publikationstypen: 왘 transaktionale 왘 Snapshot 왘 Merge.
Jedes spezifische Replikations-Szenario kann theoretisch mit jedem Publikationstyp erstellt werden. Trotzdem gibt es für jedes Szenario immer einen Publikationstyp, der am besten geeignet ist. Aufgaben
A.25.1
Warum braucht man den Primärschlüssel bei dem Replikationsprozeß? Für welchen Replikationstyp ist der Primärschlüssel unbedingt erforderlich?
A.25.2
Wie kann man die Größe der Daten, die über das Netzwerk bei der Datenreplikation verschickt werden, mindern?
A.25.3
Änderungskonflikte sind nicht empfehlenswert. Wie kann man sie minimalisieren?
A.25.4
Wann benutzt der SQL Server den Log Reader Agent und wann den Merge Agent?
529
IV
Teil
MS Analysis Services
531
26
Data Warehousing-Systeme – eine Einführung
Der Zweck dieses Kapitels ist, eine allgemeine Einführung in das neue Gebiet des Data Warehousing zu geben. Der erste Teil des Kapitels erläutert die Unterschiede zwischen der OLTP-Technologie auf der einen und der Welt der Data Warehousing-Systeme auf der anderen Seite. Daten eines Data Warehousing-Systems können in einem Data Mart oder in einem Data Warehouse gespeichert werden. Die beiden Begriffe werden im zweiten Teil des Kapitels definiert und ihre Unterschiede erläutert. Am Ende des Kapitels wird auf den Entwurf der Data Warehousing-Systeme eingegangen.
26.1 OLTP- und Data WarehousingSysteme Relationale Datenkbanksysteme sind von ihrer Entstehung bis heute fast ausschließlich für die Verarbeitung der Daten auf der Basis von Transaktionen (wie z.B. Rechnungen bearbeiten) verwendet worden. Diese Konzentration auf die operationalen Daten eines Unternehmens hat Vor- und Nachteile. Ein Vorteil ist, daß sich die sehr schlechte Performance der frühen relationalen Datenbanksysteme (um 1985) im Laufe der Zeit zunehmend verbessert hat, so daß die heutigen Systeme Tausende von Transaktionen per Sekunde (auf den entsprechenden Hardwareplattformen) mühelos verarbeiten können. Andererseits hat das Setzen auf die Transaktionsverarbeitung von Daten die Sicht auf einen anderen, natürlichen Schwerpunkt der Datenbanksysteme versperrt: das Extrahieren der notwendigen Information aus allen Unternehmensdaten und ihre Verwendung für Analyse-Zwecke.
26.1.1
OLTP-Systeme
Wie wir schon erläutert haben, ist die Performance eine der wichtigsten Eigenschaften der Systeme, die auf der Transaktionsverarbeitung basieren. Solche Systeme werden OLTP-Systeme (OnLine Transaction Processing) genannt. Basierend auf der Performance haben die OLTP-Systeme einige weitere Eigenschaften: 왘 kurze Transaktionen (und damit einen hohen Durchsatz von Daten) 왘 viele Benutzer (möglicherweise Hunderte oder Tausende von Benutzern) 왘 stete Lese- und Schreiboperationen auf Daten, die auf einer kleinen An-
zahl von Reihen basieren 왘 Datenbanken mittlerer Größe.
533
Data Warehousing-Systeme – eine Einführung
Die Performance eines Datenbanksystems wird erhöht, falls die Transaktionen in den Datenbankanwendungen kurz sind. Der Grund dafür ist, daß die Transaktionen Sperren verwenden (siehe Kapitel 14), um das Auftreten von Dateninkonsistenzen wegen des konkurrierenden Datenzugriffs zu vermeiden. Falls Transaktionen generell lange dauern, erhöht sich die Anzahl und die Dauer der Sperren, was die Verfügbarkeit von Daten für andere Prozesse einschränkt und damit die Performance des Systems negativ beeinflußt. Große OLTP-Systeme haben viele Benutzer, die gleichzeitig auf Daten zugreifen. Das typische Beispiel eines solchen Systems ist die Reservierung von Flugkarten, das Tausende von Anfragen gleichzeitig bearbeiten muß. Von solchen Systemen wird erwartet, daß sie akzeptable Antwortzeiten für die Benutzeranfragen haben. Benutzer eines OLTP-Systems führen die DML-Anweisungen kontinuierlich durch, d.h. sie verwenden stets sowohl die Lese- als auch die Schreiboperationen. Daten eines OLTP-Systems sind dynamisch, weil sie ständig geändert werden. Die Ergebnisse der meisten Operationen auf Daten eines OLTP-Systems beziehen sich auf eine relativ kleine Datenmenge (obwohl es durchaus möglich ist, daß das Datenbanksystem für die Erstellung des Ergebnisses viele Reihen verarbeiten muß). In den letzten Jahren hat der Umfang der Daten, die in den operationalen Datenbanken (das sind die Datenbanken, die von OLTP-Systemen verwaltet werden) gespeichert sind, ständig zugenommen. Heutzutage gibt es viele operationale Datenbanken, die einige GB von Daten beinhalten. Trotzdem ist diese Größe wie wir gleich sehen werden, relativ klein im Vergleich zu den meisten Data Warehouses.
26.1.2
Data Warehouse-Systeme
Data Warehousing ist der Prozeß der Integration aller Daten eines Unternehmens in eine Datenbank, die dann für ad-hoc-Abfragen und die Erstellung von Berichten verwendet werden kann. Ein Data Warehouse ist also der Speicherungsort für die Daten, die von Endbenutzern analysiert werden können, um Entscheidungen in bezug auf ihre Geschäftsvorgänge zu treffen. Im Unterschied zu OLTP-Prozessen, die operativ genannt werden, werden die Data Warehousing-Systeme informative Systeme genannt, weil durch sie die Endbenutzer die notwendige Informationen für die zukünftigen Geschäftsentscheidungen bekommen. Die Ziele eines Data Warehousing-Systems unterscheiden sich von den Zielen eines OLTP-Systems. Aus diesem Grund hat ein Data Warehousing-System andere Eigenschaften als ein OLTP-System. Die wichtigsten Eigenschaften eines Data Warehousing-Systems sind:
534
Data Warehouse und Data Mart 왘 periodische Schreiboperationen mit anschließenden Abfragen, die auf ei-
ner sehr großen Auswahl von Reihen basieren 왘 eine (relativ) kleine Anzahl von Benutzern 왘 sehr große Datenmenge.
Die Schreiboperationen bei Data Warehousing-Systemen beschränken sich auf das Laden von Massendaten, die in regelmäßigen Zeitabständen (gewöhnlich täglich) ausgeführt werden. Alle anderen Operationen auf Daten eines solchen Systems sind Abfragen, d.h. Leseoperationen. (Aus diesem Grund hat ein Data Warehouse statische Daten.) Wie wir später in diesem Kapitel noch ausführlich erläutern werden, werden Daten eines Data Warehousing-Systems aus unterschiedlichen Quellen gesammelt, konsolidiert und schließlich in eine Datenbank namens Data Warehouse bzw. Data Mart gespeichert. Die konsolidierten und gespeicherten Daten werden nicht mehr modifiziert; d.h. die Endbenutzer verwenden ausschließlich unterschiedliche Formen der SELECT-Anweisung, um auf Daten zuzugreifen und damit die notwendige Informationen zu ermitteln. Die Anzahl der Benutzer, die ein Data Warehousing-System konkurrierend benutzen, ist relativ klein, weil diese Systeme nicht für die laufenden Geschäfte benutzt werden, sondern die Information über Geschäftsprozesse liefern. Benutzer eines Data Warehousing-Systems verwenden gewöhnlich Berichte, um verschiedene Faktoren in bezug auf unternehmensweite Daten zu ermitteln, oder sie führen komplexe Abfragen durch, um Daten zu vergleichen. Ein anderer wichtiger Unterschied zwischen OLTP- und Data Warehousing-Systemen liegt darin, wie beide Systeme im Tagesablauf verwendet werden. Ein OLTP-System wird ohne Unterbrechung bzw. ohne Unterbrechung während der Geschäftszeiten betrieben, während in ein Data Warehousing-System Daten zuerst geladen werden müssen, um es überhaupt benutzen zu können. Im Unterschied zu den OLTP-Systemen, die nur aktuelle Daten enthalten, muß ein Data Warehousing-System auch historische Daten speichern. Der Grund dafür ist, daß ein Data Warehousing-System Vergleiche zwischen Daten, die sich auf verschiedene Zeitperioden beziehen, durchführen muß.
26.2 Data Warehouse und Data Mart Data Warehouse kennzeichnet den Speicherungsort (also eine Datenbank) für alle Daten eines Unternehmens, die einheitlich von Benutzern verwendet werden können. Nach dieser kurzen Definition werden wir eine ausführliche Erklärung dieses Begriffs geben.
535
Data Warehousing-Systeme – eine Einführung
Alle Daten eines Unternehmens sind gewöhnlich in unterschiedlichsten Formen (Dateien, Datenbanken, Textdateien usw.) und zu verschiedenen Zeitpunkten gespeichert. Das bedeutet, daß ein Unternehmen für die Verwaltung solcher Daten unterschiedliche Datenbanksysteme bzw. eigene Programme (falls es sich um Dateien handelt) verwendet. Falls alle Datenquellen eines Unternehmens überprüft und in einer einheitlichen Form gespeichert sind, wird der neue Speicherungsort solcher Daten Data Warehouse genannt. Damit die Daten in einem Data Warehouse einheitlich sind, müssen sie vor der Speicherung »gesäubert« werden. (Diese »Säuberung« der Daten wird Datenkonsolidierung genannt.) Der Prozeß der Konsolidierung von Daten enthält mehrere Schritte: 왘 Daten aus verschiedenen Quellen sammeln 왘 Daten einheitlich darstellen 왘 Qualitätssicherung von Daten.
Alle Daten müssen zuerst aus den verschiedenen Datenquellen importiert werden. In diesem Prozeß werden die Daten extrahiert, danach in ein Zwischenschema konvertiert und schließlich in einen (temporären) Arbeitsbereich übertragen. (Bei der Datenextraktion müssen genau diejenigen Daten importiert werden, die für das Data Warehouse relevant sind.) Eine einheitliche Darstellung von Daten garantiert, daß alle Daten, die anschließend in das Data Warehouse importiert werden, eine einheitliche Form haben und sich im konsistenten Zustand befinden. Falsche Adressen bzw. falsche Einträge in verschiedenen Feldern sind Beispiele für nicht einheitliche Daten. (Für den Prozeß der einheitlichen Datendarstellung werden spezielle Werkzeuge verwendet.) Mit einem Beispiel werden wir den Prozeß der einheitlichen Datendarstellung erläutern. Nehmen wir an, daß zwei Datenquellen die Personaldaten der Mitarbeiter beinhalten und in beiden Quellen das Attribut Geschlecht existiert. In der ersten Datenquelle ist das Attribut als CHAR(8) definiert und die Werte sind »männlich und »weiblich«. Das gleichnamige Attribut in der zweiten Datenquelle wird als CHAR(1) deklariert und die Werte sind »m« bzw. »w«. Die Werte in den beiden Datenquellen sind konsistent, müssen aber für den Import der Daten in das Data Warehouse in der einheitlichen Form dargestellt werden, d.h. nur eine der beiden Darstellungen darf verwendet werden. Der letzte Teil des Datenkonsolidierungsprozesses – Qualitätssicherung von Daten – beinhaltet Datenvalidierung, d.h. das Einbringen der Daten in der Form, wie Endbenutzer sie haben wollen. Aus diesem Grund ist es empfehlenswert, Endbenutzer in diesen Prozeß einzubinden und eng mit ihnen zu arbeiten. Wegen seiner Eigenschaft (als Speicherungsort für unternehmensweite Daten) beinhaltet ein Data Warehouse eine sehr große Datenmenge. (Einige Data Warehouses können mehr als 500 GB groß sein.) Weil ein Unternehmen sehr groß sein kann (und viele Abteilungen und Filialen haben kann) dauern
536
Data Warehouse und Data Mart
der Entwurf und die Implementation eines Data Warehouse zwei bis drei Jahre. Aufgrund dieser beiden Nachteile (riesige Datenmenge und sehr lange Entstehungszeiten) entscheiden sich sehr viele Firmen in ihren ersten Data Warehouse-Projekten für kleinere Lösungen, die Data Marts heißen. Ein Data Mart ist der Speicherungsort für alle Daten eines Unternehmensteils (gewöhnlich eine Abteilung). Die Marketingabteilung eines Unternehmens z.B. kann alle Daten bezüglich ihres Firmenmarketing in ihrem eigenen Data Mart speichern. Genauso kann der Forschungs- und Entwicklungsbereich desselben Unternehmens seine (experimentellen) Daten in das Forschungs-Data Mart speichern. Aus diesem Grund hat ein Data Mart mehrere Vorteile im Vergleich zu einem Data Warehouse: 왘 begrenztes Anwendungsgebiet 왘 kürzere Entwicklungszeiten und dementsprechend geringere Kosten 왘 leichtere Wartung von Daten 왘 bottom-up-Entwicklung.
Wie wir schon früher erläutert haben, enthält ein Data Mart ausschließlich die Information bezüglich eines Unternehmensteils (gewöhnlich einer Abteilung). Aus diesem Grund können Daten für eine solch relativ kleine Organisationseinheit leichter für die Benutzerbedürfnisse vorbereitet werden. Die Entwicklungszeit eines Data Warehousing-Systems beträgt im Durchschnitt 2-3 Jahre und kostet etwa 5.000.000$. Demgegenüber betragen die Gesamtkosten für ein Data Mart c.a. 200.000$, und ein solches Projekt dauert nur 3-5 Monate. Deswegen sollte jede Organisation die Entwicklung eines Data Marts bevorzugen, besonders falls es sich um das erste Projekt solcher Art in einem Unternehmen handelt. Ein Data Mart enthält gewöhnlich 20-50 GB Daten (im Vergleich zu ca. 500 GB Daten bei einem großen Data Warehouse.) Die Operationen (wie Datenextraktion usw.) auf einer solch relativ kleinen Datenmenge sind generell leichter zu implementieren und durchzuführen. Genauso ist es grundsätzlich leichter, einen Entwurf für Abteilungsdaten als für alle Daten eines Unternehmens zu machen. (Der Entwurf eines Data Warehouse und eines Data Marts ist im nächsten Abschnitt dieses Kapitels beschrieben.) Nachdem mehrere Data Marts für verschiedene Abteilungen eines Unternehmens erfolgreich entworfen und implementiert sind, ist es möglich, sie zu einem großen Data Warehouse zusammenzuführen. Dieser bottom-upProzeß hat mehrere Vorteile im Vergleich zum Design und der Implementierung eines Data Warehouse. Erstens, mehrere Data Marts können ähnliche Tabellen enthalten, die dann leicht in das Data Warehouse zusammengeführt werden können. Zweitens gelten einige Abteilungsaufgaben unternehmensweit (wie z.B. das Sammeln der finanziellen Daten seitens der Verkaufsabteilung). Solche Daten können dann ohne irgendwelche Änderung auch in das Data Warehouse übernommen werden.
537
Data Warehousing-Systeme – eine Einführung
Wenn die existierenden Data Marts eines Unternehmens zusammengeführt werden sollen, um das unternehmensweite Data Warehouse zu bilden, muß unbedingt ein globaler Katalog erstellt werden. (Der globale Katalog enthält die Information über alle Daten, die sich sowohl in den Datenquellen als auch in der Zieldatenbank befinden.) Die Erstellung eines Data Warehouse auf der Basis mehrerer existierenden Data Marts kann u.U. sehr mühsam sein, weil die Struktur und der Entwurf einzelner Data Marts sehr unterschiedlich sein kann. (Unterschiedliche Unternehmensteile können verschiedene Datenmodelle und Datendarstellung haben.) Aus diesem Grund ist es empfehlenswert, eine allgemeine Richtlinie vor der Erstellung einzelner Data Marts eines Unternehmens zu spezifizieren.
26.3 Der Entwurf eines Data Warehouse Die Performance eines Datenbanksystems hängt sehr davon ab, wie die entsprechende Datenbank geplant und entworfen wurde (siehe Kapitel 24). Diese Aussage gilt natürlich für alle Datenbanken, egal ob es sich um relationale Datenbanken oder Data Warehouses handelt. Im Unterschied zu relationalen Datenbanken, die mit Hilfe des allgemein bekannten E/R-Modells (Entity/Relationship-Modell) entworfen werden, verwenden Designer für Data Warehouses und Data Marts das sogenannte dimensionale Modell. Der folgende Unterabschnitt erläutert das dimensionalle Modell, während das E/R-Modell in Kapitel 1 erläutert wurde.
26.3.1
Dimensionales Modell
Die Redundanz von Daten in relationalen Datenbanken wird mit Hilfe der Normalformen (siehe Kapitel 1) geregelt. Der Normalisierungsprozeß unterteilt eine Tabelle mit redundanten Daten in zwei separate Tabellen. Dieser Prozeß wird beendet, wenn alle Tabellen einer Datenbank ausschließlich nicht redundante Daten enthalten. Die normalisierten Tabellen sind sehr hilfreich für die Transaktionsverarbeitung, weil alle Transaktionen eines Programms kurz gehalten werden sollen. Andererseits führen Operationen auf ein Data Warehouse komplexe Abfragen auf riesigen Datenmengen durch, die weder einfach noch kurz sind. Aus diesem Grund eignet sich das E/R-Modell nicht für den Entwurf der Data Warehouse-Systeme, weil der Zweck eines solchen Systems generell anders als der Zweck eines OLTP-Systems ist. (Wir erinnern daran, daß ein Data Warehouse-System, im Unterschied zu einem OLTP-System relativ wenig parallel laufende Transaktionen durchführen muß, die aber jede für sich eine enorme Menge von Daten bearbeitet.)
538
Der Entwurf eines Data Warehouse
Es gibt einen weiteren wichtigen Grund, warum das E/R-Modell nicht für das Design eines Data Warehouse geeignet ist. Daten in einem Data Warehouse sind nicht strukturiert. Das bedeutet, daß die Benutzer gewöhnlich ad-hoc-Abfragen ausführen, die die Daten in verschiedensten Formen analysieren können. (Im Vergleich dazu verwenden OLTP-Systeme Abfragen, die in Datenbankanwendungen »fest verdrahtet« sind und deswegen nicht sehr oft modifiziert werden.) Das logische Modell für den Entwurf eines Data Warehouse bzw. eines Data Marts heißt dimensionales Modell. In diesem Modell existiert eine Tabelle, die alle Maße enthält und einige andere Tabellen, die Dimensionen beschreiben. Die erste Tabelle wird Fakt-Tabelle genannt, während die anderen Tabellen Dimensionstabellen darstellen. Profit z.B. ist ein typisches Attribut einer Fakt-Tabelle, während Zeit, Produkte und Mitarbeiter typische Dimensionen eines Data Warehouse darstellen. Abbildung 26.1 zeigt ein Beispiel eines dimensionalen Modells. Abbildung 26.1: Beispiel eines dimensionalen Modells
Jede Dimensionstabelle hat gewöhnlich ein einziges Attribut, das alle Reihen eindeutig identifiziert und dementsprechend den Primärschlüssel der Tabelle darstellt. Andererseits ist der Primärschlüssel einer Fakt-Tabelle immer die Kombination der Primärschlüssel aller Dimensionstabellen (die da-
539
Data Warehousing-Systeme – eine Einführung
mit in der Fakt-Tabelle als Fremdschlüssel existieren.) Damit spezifiziert die Anzahl der Dimensionen eines dimensionalen Modells gleichzeitig auch die Anzahl der Fremdschlüssel der Fakt-Tabelle. Die Formen aller spezifischen dimensionalen Modelle sind sich sehr ähnlich, weil die Fakt-Tabelle mit jeder einzelnen Dimensionstabelle durch den Fremdschlüssel verbunden ist. (Dimensionstabellen untereinander haben nie eine direkte Verbindung.) Weil diese Form einem Stern ähnelt, wird die entsprechende Struktur das Sternschema (star schema) genannt. Ein weiterer Unterschied zwischen den Daten in der Fakt- und den Dimensionstabellen liegt in ihrer Natur: Daten einer Fakt-Tabelle sind (fast) immer numerisch und deswegen auch additiv, während die Daten einer Dimensionstabelle textuelle Beschreibungen der jeweiligen Dimensionen darstellen. Daten einer Fakt-Tabelle müssen numerisch sein, um notwendige Berechnungen wie Summe aller Verkäufe usw. durchführen zu können. (In diesem Zusammenhang ist wichtig uns zu erinnern, daß eine typische Abfrage auf Daten eines Data Warehouse Millionen von Reihen bearbeitet und die Aggregatfunktionen (SUM, AVG, MIN usw.) die einzigen sinnvollen Operationen mit solchen enormen Datenmengen darstellen. Spalte wie Verkaufte_Produkt_Einheiten oder Kosten_in_DM sind typische Beispiele für numerische und additive Spalten einer Fakt-Tabelle. Demgegenüber werden die Spalten einer Dimensionstabelle für die Beschreibung der jeweiligen Dimension verwendet. Spalten wie Adresse, Standort oder Name kommen sehr oft in den Dimensionstabellen vor. (Diese Spalten werden gleichzeitig als Überschriften in den verschiedenen Berichten verwendet.) Eine weitere Konsequenz der textuellen Form der Spalten der Dimensionstabellen ist, daß ihre Verwendung in Abfragen die Erstellung vieler Indizes notwendig macht. (Eine Fakt-Tabelle hat gewöhnlich einen einzigen zusammengesetzten Index, der alle Fremdschlüssel in der Fakt-Tabelle umfaßt. Tabelle 26.1 stellt die wichtigsten Unterschiede zwischen Fakt- und Dimensionstabellen dar. Tabelle 26.1: Unterschiedliche Eigenschaften der Fakt- und Dimensionstabellen
540
Fakt-Tabelle
Dimensionstabelle
Eine (in einem dimensionalen Modell) Mehrere (maximal 12-15) Enthält die meisten Reihen eines Data Warehouse
Enthält gewöhnlich nur einen Bruchteil der gesamten Daten
Die Primärschlüssel aller Dimensionstabellen bilden den (zusammengesetzten) Primärschlüssel der Fakt-Tabelle
Gewöhnlich bildet eine einzige Spalte den Primärschlüssel
Spalten sind numerisch und additiv
Spalten sind textuell und beschreiben die entsprechenden Dimensionen
Der Entwurf eines Data Warehouse
Spalten einer Dimensionstabelle sind denormalisiert, d.h. viele Spalten einer Dimensionstabelle sind voneinander abhängig. Die denormalisierte Struktur einer Dimensionstabelle hat einen wichtigen Grund: Alle Spalten können als Überschriften in diversen Berichten verwendet werden. (Berichte, zusammen mit ad-hoc-Abfragen sind die wichtigsten Mittel, mit denen ein Data Warehouse abgefragt werden kann.) Falls die Denormalisierung von Daten in einer Dimensionstabelle nicht erwünscht ist, (um die Performance zu erhöhen oder den verwendeten Speicherplatz zu reduzieren), können Daten einer Dimensionstabelle normalisiert werden. Die Normalisierung von Daten führt dann zu der Entstehung von mehreren Tabellen, die zusammen mit der ursprünglichen Tabelle eine Hierarchie bilden. Die hierarchische Struktur einer normalisierten Dimensionstabelle wird snowflake-Schema genannt, weil die entstehende Form an die Struktur einer Schneeflocke erinnert. (Abbildung 26.2 zeigt das snowflakeSchema der Dimension PRODUKT, wo alle Subtabellen (wie KATEGORIE oder MARKE) eine Tabellenhierarchie mit der Dimensionstabelle PRODUKT bilden.) Abbildung 26.2: Das snowflakeSchema der Dimension PRODUKT
Die Transformation einer Dimensionstabelle in eine Hierarchie mehrerer Tabellen (d.h. die Umwandlung eines Sternschemas in ein snowflake-Schema) hat mehrere (kleinere) Vorteile (wie die Verringerung des verwendeten Speicherplatzes) und einen gravierenden Nachteil: Ein snowflake-Schema erlaubt nicht die Benutzung von Spaltennamen als Überschriften eines Berichtes. Alle Spalten also, die sich in den Subtabellen befinden, können nicht für die formatierte Ausgabe von Daten verwendet werden.
541
Data Warehousing-Systeme – eine Einführung
26.4 Multidimensionale Würfel und Speicherungsmodi Data Warehousing-Systeme unterstützen verschiedene Typen von Datenspeicherung. Einige dieser Typen basieren auf einer multidimensionalen Datenbank, die auch Würfel genannt wird. Ein Würfel stellt eine Untermenge aller Daten aus einem Data Warehouse dar, die als multidimensionale Struktur organisiert sind. Um einen Würfel zu definieren, müssen zuerst die relevanten numerischen Spalten aus der Fakt-Tabelle ausgewählt werden. Danach werden die Dimensionstabellen mit den entsprechenden Spalten festgelegt, die die Beschreibung der numerischen Spalten beinhalten. Wir werden diesen Prozeß mit einem Beispiel demonstrieren. Nehmen wir an, daß die Fakt-Tabelle u.a. Spalten Verkaufte_Fahrzeuge, Verkäufe_gesamt und Kosten beinhaltet, während Modelle, Quartal und Region die drei Dimensionstabelle bilden. Zuerst können wir eine Dimension mit Hilfe der Maße der Fakt-Tabelle aufbauen. Der Würfel in Abbildung 26.3 ist auf der Basis der zwei Dimensionen – Modelle und Quartal gebildet, während Abbildung 26.4 die dritte Dimension – Region – zeigt. Abbildung 26.3: Der Würfel mit den beiden Dimensionen Modelle und Quartal
542
Multidimensionale Würfel und Speicherungsmodi
In jeder Dimension existieren Werte, die Elemente (members) genannt werden. Die Dimension Region kann z.B. folgende Elemente enthalten: Alle, Nordamerika, Südamerika und Europa. (Das Element Alle spezifiziert die Gesamtheit aller Elemente einer Dimension.) Zusätzlich dazu kann jede Dimension mehrere Hierarchieebenen haben, die verfeinerte Abfragen des Benutzers erlauben. Die Dimension Region z.B. kann folgende Unterebenen haben: Staat, Bundesland, Bezirk und Stadt. Dementsprechend kann die Dimension Quartal Monat, Woche und Tag als Unterebenen enthalten. Abbildung 26.4: Die Würfel mit der zusätzlichen Dimension Region
26.4.1
MOLAP, ROLAP und HOLAP
MOLAP (Multidimensional OLAP) ist ein Typ der Datenspeicherung, bei dem die Daten und ihre Aggregate in der Form eines multidimensionalen Würfels gespeichert sind. Andererseits verwendet ROLAP (Relational OLAP) relationale Datenbanken als Speicherungsort der Daten eines Data Warehousing-Systems. Obwohl beide Speicherungstypen identischen Daten enthalten können, unterscheiden sie sich in einigen wichtigen Eigenschaften. Vorteile von ROLAP sind: 왘 Daten müssen nicht dupliziert werden 왘 für die Aggregationen können Views verwendet werden.
Falls die Daten in einer multidimensionalen Datenbank gespeichert werden sollen, muß eine gewisse Datenmenge sowohl in den (multidimensionalen) Würfel als auch in der relationalen Datenbank gespeichert werden. Diese Duplizierung von Daten ist beim ROLAP nicht notwendig. Genauso erlaubt ROLAP eine effiziente Bearbeitung der Aggregate, falls die entsprechenden Views existieren. MOLAP hat auch einige Vorteile im Vergleich zu ROLAP: 왘 kleinere Datenmenge 왘 Abfragen sind im allgemeinen performanter
543
Data Warehousing-Systeme – eine Einführung
Mit Hilfe von MOLAP ist es möglich, alle Maße der Fakt-Tabelle in demselben Datensatz zu speichern, so daß jede Tabellenreihe wesentlich weniger Speicherplatz als bei ROLAP braucht. Bei MOLAP sind der Datenbank-Server und die dazugehörige Datenbank besser aufeinander abgestimmt, was Abfragen generell performanter als bei ROLAP macht. HOLAP (Hybrid OLAP) ist, wie der Name schon sagt, eine Kombination aus MOLAP und ROLAP. Alle Aggregate sind in MOLAP gespeichert, während die Basisdaten sich in einer relationalen Datenbank befinden. Dieser Speicherungstyp hat damit Vorteile sowohl von ROLAP als auch von MOLAP: Die Daten werden nicht dupliziert (wie bei MOLAP) und für die Berechnung der Aggregate wird der existierende multidimensionale Würfel verwendet.
26.5 Zusammenfassung Die wichtigste Frage, die am Anfang eines Data Warehouse-Projektes beantwortet werden soll, ist was zu bauen: ein Data Warehouse oder ein Data Mart. Die beste Antwort wahrscheinlich ist, mit mehreren Data Marts anzufangen und diese dann, in einer späteren Phase zu einem Data Warehouse zusammenzuführen. Die meisten Data Warehouse-Produkte (wie Informatica z.B.) unterstützen diesen Weg. Im Unterschied zu den operationalen Datenbanken, die mit Hilfe des E/RModells entworfen werden, wird das Design eines Data Warehouse bzw. eines Data Marts mit Hilfe des dimensionalen Modells durchgeführt. Diese zwei konzeptionellen Modelle unterscheiden sich signifikant voneinander. Aus diesem Grund ist es für Benutzer, die das E/R-Modell schon kennen und ein Data Warehouse entwerfen wollen, ratsam, alles über das E/R-Modell zu vergessen und das neue Modell von Anfang an zu erlernen. Aufgaben
544
A.26.1
Erläutern Sie die Unterschiede zwischen OLTP- und Data Warehouse-Systemen.
A.26.2
Erläutern Sie die Unterschiede zwischen dem E/R und dem dimensionalen Modell.
A.26.3
Am Anfang eines Data Warehouse-Projekts existiert ein Prozeß namens ETL (E – extracting, T – transforming, L – loading). Erläutern Sie diese drei Subprozesse.
A.26.4
Erläutern Sie die Unterschiede zwischen einer Fakt- und einer Dimensionstabelle.
A.26.5
Erläutern Sie Vorteile jeder der drei Datenspeicherungstypen (ROLAP, MOLAP, HOLAP).
A.26.6
Was ist die Voraussetzung damit Daten in einer Fakttabelle aggregiert werden können?
27
Server-Komponenten des MS Analysis Services
Am Anfang dieses Kapitels wird eine allgemeine Einführung in die Microsoft Analysis Services gegeben und seine Architektur erläutert. Danach werden die wichtigsten Analysis Services-Komponenten: der Analysis Manager, der Katalog und Data Transformation Services (DTS) beschrieben.
27.1 Einführung Microsoft Analysis Services ist eine Sammlung von Komponenten, die alle der Verwaltung von in einem Data Warehouse-System gespeicherten Daten dienen. MS Analysis Services transformiert die Daten aus einem Data Warehouse-System in einen multidimensionalen Würfel mit Aggregaten (siehe Kapitel 26), um die Ausführung komplexer Abfragen und die Erstellung anspruchsvoller Berichte zu ermöglichen. Die wichtigsten Eigenschaften von MS Analysis Services sind: 왘 leichte Bedienbarkeit 왘 flexibles Datenmodell 왘 viele unterschiedliche Benutzerschnittstellen.
Die leichte Bedienbarkeit des Systems zeigt sich durch die Existenz vieler Assistenten, die fast alle Aufgaben in bezug auf den Entwurf und die Implementierung eines Data Warehouse unterstützen. Der Cube-Assistent z.B. wird benutzt, um multidimensionale Würfel, in denen die Aggregate gespeichert sind, zu erstellen, während der Dimensionsassistent die Erstellung der gemeinsamen und privaten Dimensionen ermöglicht. (Gemeinsame (shared) Dimensionen sind diejenigen Dimensionen, die von allen multidimensionalen Würfeln eines Systems verwendet werden können.) Als Beispiel für die leichte Bedienbarkeit des Systems kann man auch den Analysis Manager nehmen, der Endbenutzern und dem Systemadministrator die Erstellung der Datenbanken und anderer Objekte eines Data Warehouse-Systems auf einfache Art und Weise ermöglicht. Dieses Werkzeug, genauso wie der Enterprise Manager, basiert auf der MMC-Anwendung, was dem Benutzer die Einarbeitung wesentlich erleichtert. (Der Analysis Manager wird später in diesem Kapitel ausführlich beschrieben.) Im Unterschied zu den anderen Analysis-Servern erlaubt MS Analysis Services die Auswahl der geeignetsten Speicherungsform für ein spezifisches Data Warehouse. Bei MS Analysis Services ist es möglich, zwischen MOLAP, ROLAP und HOLAP zu wählen. MOLAP (Multidimensional OLAP) verwendet multidimensionale Würfel, um alle Aggregate zu speichern, was eine optimale Performance für ad-hoc-Abfragen bietet. ROLAP (Relational OLAP)
545
Server-Komponenten des MS Analysis Services
speichert alle Daten in relationalen Tabellen, womit man die Datenmenge reduzieren kann. Falls die Basisdaten eines Data Warehousing-Systems in den relationalen Tabellen und die Aggregate in multidimensionalen Würfeln gespeichert sind, reden wir vom HOLAP (Hybrid OLAP). MS Analysis Services unterstützt HOLAP, zusammen mit den virtuellen Würfeln und Partitionen. (Partitionen sind physikalische Teile eines multidimensionalen Würfels, die für die Berechnung verschiedener Aggregatefunktionen verwendet werden können. Virtuelle Würfel stellen Verknüpfungen zwischen mehreren Partitionen dar, die für die Erstellung der Abfragen auf Daten benutzt werden, welche aus verschiedenen multidimensionalen Datenquellen stammen.) Eine sehr wichtige Eigenschaft von MS Analysis Services ist, daß es OLE DB unterstützt. Damit können unterschiedliche Softwarelösungen von Drittanbietern als Clients implementiert und mit MS Analysis Services zusammen eingesetzt werden. Die Unterstützung des Datentransports, das auf OLD DB basiert, wird Universal Data Access genannt und ist ein Teil von Data Warehouse Framework – einer allgemeinen Beschreibung, die für Entwurf, Implementierung und Verwaltung der Data Warehousing-Systeme gilt. Mit Hilfe von DTS (Data Transformation Services) können Daten aus unterschiedlichen Datenquellen (Access, Oracle, SQL Server usw.) extrahiert, transformiert und in das Data Warehouse-System geladen werden.
27.2 Architektur von Analysis Services MS Analysis Services enthält mehrere Komponenten: 왘 Data Warehouse 왘 Server-Tier 왘 Client-Tier,
die in einer Drei-Tier-Architektur eingebettet sind. Drei-Tier-Architektur bedeutet, daß es drei unterschiedliche Server- bzw. Client-Ebenen gibt, wo die verschiedenen Komponenten eines Client/Server-Systems (Präsentation, Logik und Daten) verarbeitet werden. Abbildung 27.1 zeigt die Drei-Tier-Architektur von MS Analysis Services. Die folgenden Unterabschnitte beschreiben die drei Architekturebenen von MS Analysis Services.
27.2.1
Data Warehouse-Tier
Das Data Warehouse-Tier beinhaltet das Datenbanksystem, das die in Tabellen gespeicherten Daten verwaltet. Für MS Analysis Services ist dieses Datenbanksystem der SQL Server. Falls die Menge der zu speichernden Daten sehr groß ist (> 100 GB), ist es ratsam, die Benutzung eines anderen Datenbanksystems in Betracht zu ziehen.
546
Architektur von Analysis Services Abbildung 27.1: MS Analysis Services: Drei-TierArchitektur
27.2.2
Server-Tier
Das Server-Tier von MS Analysis Services enthält als Komponente den Analysis-Server (siehe Abbildung 27.1). Der MS Analysis-Server verwaltet den Puffer, in dem Ergebnisse der multidimensionalen Berechnungen dauerhaft gespeichert werden. Mit anderen Worten, der Analysis-Server ist ein Datenbank-Server, der die systemspezifische Speicherung von Daten, die für die Client-Software zur Verfügung steht, ermöglicht. Jeder Analysis-Server muß registriert werden, falls er vom MS Analysis Services verwaltet werden soll. Die Registrierung eines Analysis-Servers wird vom Analysis Manager durchgeführt. Die Voraussetzung für die Verwaltung von Daten mit Hilfe einer Client-Komponente ist, daß der AnalysisServer läuft. Sie können dies überprüfen, indem Sie die Funktion Dienst (in Einstellungen) wählen und danach den MSOLAPServer-Dienst starten. Die Daten für den Analysis-Server werden aus mehreren Quellen geholt und unterschiedlich gespeichert (abhängig davon, ob es sich um MOLAP, ROLAP oder HOLAP handelt): 왘 in Tabellen einer relationalen Datenbank (ROLAP) 왘 in multidimensionalen Dateien (MOLAP) 왘 in Tabellen einer relationalen Datenbank und in multidemnsionalen Da-
teien (HOLAP). Zusätzlich dazu werden die Metadaten in bezug auf den multidimensionalen Würfel (wie Dimensionen und existierende Attribute) vom Analysis-Server in den Katalog (Repository) gespeichert.
547
Server-Komponenten des MS Analysis Services
27.2.3
Client-Tier
Das Client-Tier enthält eine (oder mehrere) Client-Komponenten wie MS Excel oder Produkte der Drittanbieter. Zusätzlich dazu können benutzerdefinierte Anwendungen die Verbindung zum Server-Tier aufbauen, falls sie entweder das ADO-Objektmodell oder die OLE DB-Schnittstelle verwenden (siehe Abbildung 27.1) Das vorherige Kapitel erläutert ausführlich die möglichen Client-Komponenten von MS Analysis Services. 27.2.3.1
PivotTable-Dienst
Alle Client-Komponenten werden mit Hilfe des PivotTable-Dienstes mit dem Analysis-Server verbunden. Dieser Dienst bietet die Schnittstellen, um Operationen auf Daten ausführen zu können. Der PivotTable-Dienst speichert die Daten lokal auf dem Client (für die Datenanalyse ohne die Benutzung des Analysis-Servers) und erlaubt auch den online-Zugriff (mit Hilfe des Analysis-Server) auf Daten, die im multidimensionalen Würfel gespeichert sind. Der PivotTable-Dienst hat einige wichtige Merkmale: 왘 Er ermöglicht die lokale Datenspeicherung (damit die Client-Anwen-
dungen lokale multidimensionale Datenbanken erstellen und verwenden können). 왘 Er liefert Daten für relationale Datenquellen, die multidimensionale
Würfel implementieren. Diese Funktionalität wird mit Hilfe der OLE DBSchnittstelle mit MDX-Erweiterungen gewährleistet. (MultiDimensional eXpressions (MDX) ist eine Sammlung von SQL-ähnlichen Anweisungen, die für die Operationen auf den multidimensional gespeicherten Daten benutzt werden können. CREATE CUBE und DROP CUBE sind zwei Beispiele der MDX-Anweisungen.) 왘 Er spezifiziert den lokalen multidimensionalen Server. (Das bedeutet,
daß eine Client-Anwendung die allgemeine Datenanalyse durch die Verbindung zu Analysis Services gewährleistet, während die lokale Datenanalyse mit Hilfe des PivotTable-Dienstes durchgeführt wird. Der PivotTable-Dienst ist der Nachfolger des gleichnamigen Excel-Dienstes. (Die meisten Einschränkungen bezüglich des Speichers, die für den Vorgänger gegolten haben, sind behoben, so daß große multidimensionale Datenbanken erstellt werden können.) Weil der PivotTable-Dienst ein lokaler Server ist, hat er gewisse Einschränkungen in bezug auf die Performance und die Systemadministration. Dieser Dienst kann z.B. nur mit einer einzigen Partition (des multidimensionalen Würfels) arbeiten. Die typischen Systemadministrationsaufgaben, wie die Erstellung einer Kennung bzw. die Verwaltung der Zugriffsrechte werden von diesem Dienst nicht unterstützt.
548
Analysis Services-Komponenten
27.3 Analysis Services-Komponenten Bei MS Analysis Services existieren u.a. drei Komponenten: 왘 Katalog (Repository) 왘 Analysis Manager 왘 Data Transformation Services (DTS),
die für verschiedene Zwecke verwendet werden können.
27.3.1
Katalog
Der Katalog ist eine Datenbank, die für das System relevante Objekte und Daten enthält. (Diese Daten heißen Metadaten. ) Im Falle von MS Analysis Services sind Metadaten in einer relationalen Datenbank gespeichert, auf die mit Hilfe des Analysis-Servers und Decision Support Objects (DSO) zugegriffen werden kann. Decision Support Objects ist ein Objektmodell, das von MS Analysis Services unterstützt wird und Schnittstellen, Objekte und Methoden enthält. (Die Elemente von DSO können z.B. für so unterschiedliche Aufgaben wie die Erstellung eines mehrdimensionalen Würfels oder die Verwaltung der Systemsicherheit verwendet werden. DSO besteht aus mehreren Gruppen von Elementen, die hierarchisch strukturiert sind. (Der Baum in Abbildung 27.2 zeigt diese Objekthierarchie.) Analysis-Server Datenbank Würfel Partition Aggregation virtueller Würfel Würfel Partition Aggregation
Abbildung 27.2: Objekthierarchie im Decision Support Objects-Modell
Das Hierarchiemodell in Abbildung 27.2 kann folgendermaßen interpretiert werden: Der Analysis-Server (als Objekt) enthält als Unterobjekt Datenbanken, die ihrerseits multidimensionale und virtuelle Würfel enthalten. Ein multidimensionaler Würfel enthält Partitionen, die ihrerseits Aggregationen enthalten. Im Decision Support Objects-Modell existiert eine spezielle Sammlung genannt MDStore, die alle Objekte der Hierarchie unterhalb des Analysis-Servers beinhaltet. MDStore hat eine besondere Eigenschaft, d.h. dieses Objekt enthält Methoden (wie Hinzufügen, Suchen und Löschen), die auf alle Objekte der Hierarchie unterhalb von MDStore angewendet werden können.
549
Server-Komponenten des MS Analysis Services
27.3.2
Der Analysis Manager
Der Analysis Manager ist ein Werkzug des Analysis Services, das den interaktiven Zugriff auf den Analysis-Server und Katalog ermöglicht. Diese Komponente ist integriert mit Microsoft Management Console (MMC), die die Standardschnittstelle für alle Administrationsaufgaben darstellt. Das Starten des Analysis Managers erfolgt durch das Anklicken der StartSchaltfläche, der Markierung von Programme, sowie MS SQL Server und durch die Auswahl der Funktion Analysis Manager (unter Analysis Services). Abbildung 27.3 zeigt die Baumstruktur des Analysis Managers. Ähnlich dem Knoten Servergruppen beim Enterprise Manager (siehe Kapitel 2), enthält der Analysis Manager den Knoten MS Analysis-Server, der alle Analysis-Server des Systems umfaßt. Jeder existierende Analysis-Server enthält eine oder mehrere Datenbanken, die durch Subknoten des Server-Knotens dargestellt sind. (In Abbildung 27.3 handelt es sich um die Datenbank grocery, die ein Unterknoten des Servers NTB11900 ist.) Die Hierarchie unter dem Datenbankknoten enthält mehrere Ordner für die multidimensionalen Würfel der Datenbank. Abbildung 27.3: Die Baumstruktur des Analysis Managers
Jeder Würfel-Knoten enthält Elemente wie Datenquellen, Dimensionen und Measures (Maße). (Der Würfel der grocery-Datenbank wird grocery_cube genannt.) Jede Datenquelle enthält OLE DB-Provider, Server-Verbindungen
550
Analysis Services-Komponenten
und Sicherheitsfunktionen. Der Dimensionsordner des Würfels beinhaltet Subknoten für jede Dimension des Würfels. Eine private Dimension kann nur von dem spezifischen Würfel, den sie beinhaltet, verwendet werden. Andererseits kann jede gemeinsame Dimension von vielen multidimensionalen Würfel benutzt werden. ( Bei der Dimension Time in Abbildung 27.3 handelt es sich um eine gemeinsame Dimension.) Jede Dimension hat eine oder mehrere Hierarchieebenen, die für das drill-down-Verfahren benutzt werden können. (Das drill-down-Verfahren ermöglicht die Durchführung der Abfragen auf einer niedrigeren Hierarchieebene und damit die Verfeinerung der Datenanalyse.) In Abbildung 27.3 hat die Dimension Time drei Hierarchieebenen: Year, Quarter und Month. Neben dem Ordner Dimensionen existieren drei weitere Ordner: 왘 Measures 왘 Partitionen 왘 Rollen.
Der Ordner Measures enthält je einen Knoten für alle Maßattribute einer Tabelle. (Wir erinnern noch einmal daran, daß alle Massattribute zusammen mit den Primärschlüsseln aller Dimensionstabellen die Spalten der Fakt-Tabelle bilden.) Der Ordner Partitionen beinhaltet je einen Knoten für jede Partition des multidimensionalen Würfels, während der Ordner Rollen je einen Knoten für jede definierte Benutzergruppe enthält. Sowohl der Systemadministrator als auch jeder einzelne Endbenutzer können den Analysis Manager verwenden, um Datenbanken und Datenquellen zu definieren, Dimensionen zu erstellen und anzuzeigen und Sicherheitsaspekte des Systems festzulegen. Alle diese Merkmale werden in den folgenden Abschnitten beschrieben. 27.3.2.1
Datenbanken und Datenquellen definieren
Die Definition einer Datenbank mit Hilfe des Analysis Managers erfolgt durch die Auswahl des Analysis-Servers und das Anklicken (mit der rechten Maustaste) des entsprechenden Servers. Danach müssen die Funktion Neue Datenbank ausgewählt und der Datenbankname (im Dialogfeld Datenbanken) eingetragen werden. (Der Benutzer kann in diesem Dialogfeld optional weitere Datenbankangaben machen.) Die Definition einer Datenquelle erfolgt anders: Der Ordner Bibliothek der entsprechenden Datenbank muß angeklickt und der Unterordner Datenquelle (mit der rechten Maustaste) ausgewählt werden. Danach wird die Funktion Neue Datenquelle angeklickt. Das Dialogfeld Datenlinkeigenschaften (Abbildung 27.4) erscheint. Nach dem Anklicken der Registerkarte Provider und der Auswahl des OLE DB-Providers müssen die Registerkarte Verbindung angeklickt und die entsprechende Datenbank ausgewählt werden.
551
Server-Komponenten des MS Analysis Services Abbildung 27.4: Das Dialogfeld Datenlinkeigenschaften
Bei der Definition der Datenquelle müssen alle Quellen für Daten der entsprechenden Datenbank spezifiziert werden. 27.3.2.2
Dimensionen definieren
Eine Dimension ist eine Sammlung von logisch zusammenhängenden Attributen, die in einer Dimensionstabelle gespeichert sind. Jede Dimension kann mit Hilfe des Dimensionsassistenten definiert werden. Um den Assistenten zu starten, müssen der Ordner Bibliothek in der entsprechenden Datenbank ausgewählt und der Unterordner Gemeinsame Dimensionen (mit der rechten Maustaste) angeklickt werden. Danach müssen die Funktion Neue Dimensionen und der Assistent ausgewählt werden. Der Assistent ermöglicht die Erstellung einer Dimension aus einer einzigen bzw. aus mehreren, miteinander und mit der Join-Operation verknüpften Tabellen. Im zweiten Fall wird die Dimension auf der Basis der Tabellenhierarchien, die snowflake-Schema heißt, gebaut (siehe Kapitel 26 und Abbildung 26.3). Im nächsten Schritt müssen die Dimensionstabelle(n) ausgewählt und optional alle Hierarchieebenen der Dimension definiert werden. Die definierten Hierarchieebenen ermöglichen das drill-down-Verfahren, d.h. die Verfeinerung der Abfragen von einer höheren zu einer niedrigeren Hierarchieebene (z.B. von Jahr zu Monat).
552
Analysis Services-Komponenten
27.3.2.3
Dimensionen anzeigen
Der Dimensionseditor ermöglicht die Ausgabe einer Dimension mit allen ihren Hierarchieebenen. Um den Editor zu öffnen, müssen der Ordner Bibliothek (innerhalb der entsprechenden Datenbank) ausgewählt und Gemeinsame Dimensionen angeklickt werden. Schließlich müssen die entsprechende Dimension (mit der rechten Maustaste) angeklickt und die Funktion Bearbeiten ausgewählt werden. Der Dimensionseditor hat zwei Ansichten: 왘 Daten 왘 Schema.
Die Datenansicht gibt die Dimension mit allen ihren Hierarchieebenen in der Baumform aus. Durch das Anklicken einzelner Ebenen ist es möglich die unteren Ebenen anzuzeigen bzw. die Ausgabe dieser wieder rückgängig zu machen. Die Schemaansicht (Abbildung 27.5) gibt die Dimensionstabellen mit allen ihren Spalten aus, wobei die Verbindungslinien jeweilige Primärschlüssel mit den entsprechenden Fremdschlüsseln verbinden. Abbildung 27.5: Dimensionseditor: die Schemaansicht
27.3.2.4
Sicherheitsaspekte
Die Sicherheitsaspekte des MS Analysis Services entsprechen den Sicherheitsaspekten des SQL Servers. Das bedeutet, daß MS Analysis Services so-
553
Server-Komponenten des MS Analysis Services
wohl die Authentifizierung als auch die Benutzerzugriffsrechte unterstützt, aber in wesentlich kleinerem Umfang als der SQL Server. Die Authentifizierung definiert, welcher Benutzer den Zugriff zu einem Analysis-Server hat. Bei MS Analysis Services ist diese Problematik eng mit den Sicherheitsaspekten des Betriebssystems verknüpft. Mit anderen Worten, MS Analysis Services verwendet die Authentifizierung der Benutzer auf der Basis der entsprechenden Authentifizierung des Betriebssystems Windows NT/2000. MS Analysis Services verwaltet die Zugriffsrechte zu den Datenbank- bzw. Würfelobjekten mit Hilfe der folgenden beiden Rechte: 왘 Admin 왘 Nur-Lesen.
Das Admin-Zugriffsrecht erlaubt einer Benutzerkennung den Analysis Manager zu verwenden und die Daten zu verarbeiten. Das Nur-Lesen-Zugriffsrecht erlaubt die Leseoperation auf den Daten eines Analysis Managers durchzuführen. Die Sicherheit bei MS Analysis Services ist nur aktiv, falls der AnalysisServer auf Windows NT/2000 mit dem NTFS-Dateisystem installiert ist.
27.3.3
Data Transformation Services (DTS)
Data Transformation Services ist eine Sammlung mehrerer Komponenten, die den Datentransfer aus einer oder mehreren Datenquellen zu einem oder mehreren Zielsystemen ermöglicht. Neben dem Datentransfer unterstützt DTS auch die Transformation von Daten (zwischen dem Datenexport und dem Datenimport). Data Transformation Services ermöglicht den Datentransfer sowohl zwischen den homogenen (mehreren SQL Server-Systemen) als auch zwischen heterogenen Systemen (Oracle, Access, SQL Server usw.). Aus diesem Grund ist DTS das optimale Werkzeug für die Datenkonsolidierungsphase. (Die Datenkonsolidierung ist eine frühe Phase im Erstellungsprozeß von Data Warehouse-Systemen.) In dieser Phase werden die Daten transformiert, d.h. die Konsistenz der importierten Daten aus mehreren Datenquellen wird überprüft und falls notwendig einheitlich dargestellt. Schließlich werden die Daten in dieser Phase nach den existierenden Anforderungen überprüft. (Data Transformation Services ist ausführlich in Kapitel 21 beschrieben.)
554
Zusammenfassung
27.4 Zusammenfassung Mit Analysis Services bietet Microsoft eine integrierte Sammlung von Komponenten, die für die Analyse von Daten verwendet werden können. Mit Hilfe des Analysis Managers, der auf der standardisierten MMC-Schnittstelle basiert, ist es möglich auf einfache Weise Data Warehouse-Systeme zu entwerfen, zu implementieren und zu verwalten.
555
28
Client-Komponenten des Analysis Services
Alle Client-Komponenten für MS Analysis Services können in drei Gruppen unterteilt werden: 왘 SQL-Erweiterungen in bezug auf MS Analysis Services 왘 Microsoft Client-Werkzeuge 왘 Client-Software der Drittanbieter.
In den folgenden Abschnitten werden alle drei Gruppen beschrieben.
28.1 Transact-SQL-Erweiterungen in bezug auf Analysis Services Der SQL Server bietet einige Erweiterungen zu der SELECT-Anweisung, die speziell für Data Warehousing-Prozesse verwendet werden können. Zu diesen Erweiterungen gehören: 왘 CUBE-Operator 왘 ROLLUP-Operator 왘 TOP n-Klausel.
Die Aggregatfunktionen, die in Kapitel 5 beschrieben sind, liefern immer eine eindimensionale Ergebnismenge (d.h. einen Wert). Die Eigenschaft der beiden oben genannten Operatoren ist, daß sie n-dimensionale Ergebnismengen liefern.
28.1.1
Der CUBE-Operator
Die GROUP BY-Klausel definiert eine oder mehrere Spalten einer Tabelle als Gruppenkennzeichen, wonach die Reihen gruppiert werden. Falls in einer solchen GROUP BY-Klausel mit einer Aggregatfunktion die WITH CUBEAngabe spezifiziert wird, werden zu der Ausgabe eines Ergebniswertes auch zusätzliche Ergebnisreihen ausgegeben, die sich auf alle in der GROUP BY-Klausel angegebenen Spalten beziehen. (Diese werden beim SQL Server Super-Aggregate genannt.) Für jede mögliche Kombination der in der GROUP BY-Klausel erscheinenden Spalten (bzw. Ausdrücke) werden SuperAggregate gebildet. Beispiel 28.1 erstellt die Tabelle projekt_abt, die im weiteren Text als Basis für alle Abfragen benutzt wird.
557
Client-Komponenten des Analysis Services Beispiel 28.1
create table projekt_abt (abt_name char(20) not null, anz_mitarb_pro integer not null, pr_mittel money)
In Beispiel 28.1 wird eine Tabelle – projekt_abt – erstellt, die die Mitarbeiteranzahl und die Mittel jedes Projektes, das von einer Abteilung beaufsichtigt wird, ausgibt. Die Daten der Tabelle projekt_abt können folgendermaßen aussehen: abt_name anz_mitarb_pro pr_mittel -------- -------------- ----------------------------------Freigabe 5 50.000,00 Freigabe 10 70.000,00 Freigabe 5 65.000,00 Diagnose 5 10.000,00 Diagnose 10 40.000,00 Diagnose 6 30.000,00 Diagnose 6 40.000,00 Beratung 6 100.000,00 Beratung 10 180.000,00 Beratung 3 100.000,00 Beratung 5 120.000,00 (11 Reihen betroffen)
Folgendes Beispiel zeigt die Gruppierung der Spalten der Tabelle projekt_abt ohne die Verwendung des CUBE- bzw. ROLLUP-Operators. Beispiel 28.2
select abt_name, anz_mitarb_pro, sum(pr_mittel) summe_aller_mittel from projekt_abt group by abt_name, anz_mitarb_pro
In Beispiel 28.2 werden die Reihen der Tabelle projekt_abt nach den Abteilungsnamen und der Mitarbeiteranzahl gruppiert. Das Ergebnis dieses Beispiels ist: abt_name anz_mitarb_pro summe_aller_mittel -------------------------------------------------------Freigabe 5 15.000,00 Freigabe 10 70.000,00 Diagnose 5 10.000,00 Diagnose 10 40.000,00 Diagnose 6 70.000,00 Beratung 6 200.000,00 Beratung 10 180.000,00 Beratung 3 100.000,00 Beratung 5 120.000,00 (9 Reihen betroffen)
558
Transact-SQL-Erweiterungen in bezug auf Analysis Services
Im folgenden Beispiel wird die Verwendung des CUBE-Operators gezeigt. Beispiel 28.3
select abt_name, anz_mitarb_pro, sum(pr_mittel) from projekt_abt group by abt_name, anz_mitarb_pro with cube
summe_aller_mittel
Das Ergebnis ist: abt_name anz_mitarb_pro summe_aller_mittel -------- -------------- -----------------------------Beratung 3 100.000,00 Beratung 5 120.000,00 Beratung 6 100.000,00 Beratung 10 180.000,00 Beratung NULL 500.000,00 Diagnose 5 10.000,00 Diagnose 6 70.000,00 Diagnose 10 40.000,00 Diagnose NULL 120.000,00 Freigabe 5 115.000,00 Freigabe 10 70.000,00 Freigabe NULL 185.000,00 NULL NULL 805.000,00 NULL 3 100.000,00 NULL 5 245.000,00 NULL 6 170.000,00 NULL 10 290.000,00 (17 Reihe(n) betroffen)
Neben allen in Beispiel 28.2 ausgegebenen Reihen enthält das Ergebnis des Beispiels 28.3 auch alle Reihen mit Super-Aggregaten. Ein Super-Aggregat wird als NULL im Ergebnis ausgegeben, spezifiziert aber alle Werte. Die folgende Reihe: NULL
NULL
805.000,00
zeigt z.B. die Summe aller Mittel aller Projekte der Tabelle projekt_abt, während die folgende Reihe: NULL
3
100.000,00
die Summe aller Mittel der Projekte mit genau drei Beschäftigten ausgibt. Weil der CUBE-Operator alle möglichen Kombinationen der Super-Aggregate ausgibt, ist die Anzahl der ausgegebenen Reihen gleich, unabhängig von der Reihenfolge der in der GROUP BY-Klausel angegebenen Spalten.
559
Client-Komponenten des Analysis Services
28.1.2
Der Operator ROLLUP
Der Operator ROLLUP schränkt die Anzahl der erstellten Super-Aggregate im Vergleich zum CUBE-Operator ein. Damit wird mit der WITH ROLLUPAngabe in der GROUP BY-Klausel ein Auszug aller Aggregate erstellt. Beispiel 28.4
select abt_name, anz_mitarb_pro, sum(pr_mittel) summe_aller_mittel from projekt_abt group by abt_name, anz_mitarb_pro with rollup
Das Ergebnis ist: abt_name anz_mitarb_pro summe_aller_mittel -------- -------------- ---------------------------------Beratung 3 100.000,00 Beratung 5 120.000,00 Beratung 6 100.000,00 Beratung 10 180.000,00 Beratung NULL 500.000,00 Diagnose 5 10.000,00 Diagnose 6 70.000,00 Diagnose 10 40.000,00 Diagnose NULL 120.000,00 Freigabe 5 115.000,00 Freigabe 10 70.000,00 Freigabe NULL 185.000,00 NULL NULL 805.000,00 (13 Reihe(n) betroffen)
Bei der Anwendung des CUBE-Operators werden, wie aus dem Ergebnis des Beispiels 28.3 ersichtlich, alle möglichen Super-Aggregate berechnet. Das Ergebnis des Beispiels 28.4 ist eine Untermenge des Ergebnisses des Beispiels 28.3. In diesem Fall werden die Gesamtsumme sowie die Summen für jede einzelne Abteilung zusätzlich berechnet. Das folgende Beispiel zeigt, daß die Änderung der Reihenfolge der Spalten in der GROUP BY-Klausel die Ausgabe beinflußt. Beispiel 28.5
select abt_name, anz_mitarb_pro, sum(pr_mittel) summe_aller_mittel from projekt_abt group by anz_mitarb_pro, abt_name with rollup
560
Transact-SQL-Erweiterungen in bezug auf Analysis Services
Das Ergebnis ist: abt_name anz_mitarb_pro summe_aller_mittel -------------------- -------------- --------------------Beratung 3 100000.0000 NULL 3 100000.0000 Beratung 5 120000.0000 Diagnose 5 10000.0000 Freigabe 5 115000.0000 NULL 5 245000.0000 Beratung 6 100000.0000 Diagnose 6 70000.0000 NULL 6 170000.0000 Beratung 10 180000.0000 Diagnose 10 40000.0000 Freigabe 10 70000.0000 NULL 10 290000.0000 NULL NULL 805000.0000 (14 Reihe(n) betroffen)
Beispiel 28.5 unterscheidet sich von Beispiel 28.4 in der Reihenfolge der zum Gruppieren benutzten Spalten. Aus diesem Grund ist der Inhalt des Ergebnisses anders als der Inhalt des Ergebnisses in Beispiel 28.4.
28.1.3
Die TOP n-Klausel
Die TOP n-Klausel wird für die Ausgabe der ersten n Reihen des Ergebnisses, die auf Grund eines Kriteriums ausgewählt wurden, verwendet. Beispiel 28.6
select top 8 abt_name, pr_mittel from projekt_abt order by pr_mittel desc
Das Ergebnis ist: abt_name pr_mittel -------------------- --------------------Beratung 180000.0000 Beratung 120000.0000 Beratung 100000.0000 Beratung 100000.0000 Freigabe 70000.0000 Freigabe 65000.0000 Freigabe 50000.0000 Diagnose 40000.0000 (8 Reihe(n) betroffen)
561
Client-Komponenten des Analysis Services
Die Funktionalität der TOP n-Klausel kann mit Hilfe der entsprechenden korrelierten Abfrage implementiert werden, wie das folgende Beispiel zeigt. Beispiel 28.7
select abt_name, pr_mittel from projekt_abt pa1 where 8 > (select count(*) from projekt_abt pa2 where pa2.pr_mittel > pa1.pr_mittel) order by pr_mittel desc
Die TOP n-Klausel kann mit der zusätzlichen Option PERCENT verwendet werden. In diesem Fall wird der angegebene Prozentsatz der Reihen des Ergebnisses, die auf Grund eines Kriteriums ausgewählt wurden, ausgegeben. Eine weitere Option – WITH TIES – spezifiziert, daß zusätzliche Reihen im Ergebnis ausgegeben werden, falls der Wert der letzten auszugebenden Ergebnisreihe mehrmals vorkommt. Beispiel 28.8
Finden Sie sechs Projekte mit der kleinsten Angestelltenanzahl. select top 6 with ties * from projekt_abt order by anz_mitarb_pro
Das Ergebnis ist: abt_name anz_mitarb_pro pr_mittel --------------- ---------------- --------------------Beratung 3 100000.0000 Freigabe 5 50000.0000 Freigabe 5 65000.0000 Diagnose 5 10000.0000 Beratung 5 120000.0000 Diagnose 6 30000.0000 Diagnose 6 40000.0000 Beratung 6 100000.0000 (8 Reihe(n) betroffen)
Das Ergebnis des Beispiels 28.8 enthält acht Reihen, weil drei Projekte existieren, die sechs Angestellte beschäftigen.
28.2 Microsoft Client-Werkzeuge Folgende Microsoft-Software kann für die Datenanalyse verwendet werden: 왘 Excel 2000 왘 Analysis Manager.
562
Microsoft Client-Werkzeuge
28.2.1
Excel 2000
MS Excel ist ein allgemein bekanntes Werkzeug von Microsoft, das für die Tabellenkalkulation verwendet wird. Die neueste Version dieses Werkzeugs – Excel 2000 – ist mit MS Analysis Services abgestimmt und kann deswegen als Client-Komponente verwendet werden. Die Beschreibung dieses Werkzeugs gehört nicht zum Inhalt dieses Buches.
28.2.2
Analysis Manager
Der Analysis Manager ist eine Komponente von MS Analysis Services, die den Zugriff sowohl auf den Analysis Server als auch auf Metadaten der multidimensionalen Struktur ermöglicht. Falls dieses Werkzeug als Client verwendet wird, können Datenquellen, gemeinsame Dimensionen und Sicherheitsaspekte gesichtet werden. Der Analysis Manager unterstützt den Cube-Editor, mit dem multidimensionale Daten eines Würfels gesichtet und analysiert werden können. (Der Würfel muß aufbereitet werden, bevor Daten gesichtet werden können.) Mit Hilfe der Cubes-Komponente werden wir sehen, wie der Analysis Manager für das Sichten von multidimensionalen Daten verwendet werden kann. Wir werden die Sales-Würfel der Demodatenbank Foodmart2000 verwenden, um zu zeigen, wie man den drilling down- und drilling up-Prozeß innerhalb des Würfels durchführen kann. Der Cube-Editor wird durch das Anklicken des Ordners Analysis Servers, des Server-Ordners, der Foodmart2000-Datenbank und des Cubes-Ordners (in dieser Reihenfolge) geöffnet. Danach wird (mit der rechten Maustaste) der Sales-Würfel angeklickt und die Funktion Bearbeiten ausgewählt. Nach der Auswahl der Daten-Schaltfläche erscheint in Abbildung 28.1 dargestellte Dialogfeld. Der Cube-Editor hat zwei Teile. Im linken Teil werden die Dimensionen ausgegeben, während der rechte Teil (das Datengitter genannt) Daten enthält. Wie aus Abbildung 28.1 zu sehen ist, enthält der linke Teil des Editors 12 Dimensionen, während das Datengitter das Element Country der CustomerDimension und alle measures des Würfels (Unit Sale, Store Cost, Store Sales, Sales Count und Store Sales Net) umfaßt. Falls man die multidimensionalen Daten zweier Dimensionen im Gitter sichten möchte, müssen die entsprechenden Dimensionen durch das drag and drop-Verfahren zu den beiden Achsen des Gitters gebracht werden. Falls zum Beispiel die Product-Dimension auf die X-Achse gebracht wird (und damit measures des Würfels ersetzt), erscheinen im Gitter die Daten in bezug auf die beiden Dimensionen Customer und Product (siehe Abbildung 28.2).
563
Client-Komponenten des Analysis Services Abbildung 28.1: Der Cube Editor
Abbildung 28.2: Cube Editor mit den Dimensionen Customer und Product im Datengitter
564
Client-Software der Drittanbieter
Das Sichten der Daten im Gitter kann mit zwei unterschiedlichen Verfahren durchgeführt werden: 왘 drilling down 왘 drilling up.
Unter drilling down wird das Verfahren verstanden, bei dem die Daten einer bestimmten Hierarchieebene einer Dimension eine oder mehrere Detaillierungsstufen niedriger ausgegeben werden. Unter drilling up wird das gegensätzliche Verfahren verstanden. Falls man das drilling down-Verfahren innerhalb des Cube-Editors anwenden will, muß das entsprechende Element durch Doppelklick angeklickt werden. Danach erscheint die nächste Hierarchieebene des Elementes, falls existent. (Abbildung 28.3 zeigt die Daten, nachdem das drilling down-Verfahren auf das Country-Element angewendet wurde.) Das drilling up-Verfahren wird durch Doppelklick an das expandierte Element durchgeführt. Abbildung 28.3: Der Cube-Editor, nachdem das drilling down-Verfahren auf das CountryElement angewendet wurde
Der Analysis Manager wird primär als Administrationswerkzeug für die Erstellung der Datenbanken und Datenquellen eingesetzt. Deswegen sollte man generell Excel 2000 und die Software der Drittanbieter für das Sichten der Daten verwenden.
28.3 Client-Software der Drittanbieter MS Analysis Services ist ein Data Warehousing-System, das eine effiziente Analyse einer sehr großer Datenmenge ermöglicht. Microsoft bietet den Drittanbietern die Möglichkeit, mit Hilfe der OLE DB für OLAP ihre eigenen Softwareprodukte zu erstellen. (OLE DB definiert eine Sammlung von
565
Client-Komponenten des Analysis Services
Schnittstellen für den Zugriff auf verschiedene Datentypen, die in unterschiedlichen Datenquellen gespeichert sind.) Die Drittanbieter-Software kann deswegen auf der Basis von OLE DB für OLAP implementiert werden, um mit MS Analysis Services kommunizieren zu können. Auf diese Art und Weise können diverse Lösungen für komplexe Abfragen und anspruchsvolle Berichte den Benutzern von MS Analysis Services angeboten werden. Im Augenblick existieren mehrere Softwarelösungen verschiedener Firmen, die als Client-Komponenten für MS Analysis Services verwendet werden können: 왘 ProClarity, Fa. Knosys 왘 Active OLAP Suite (AOS), Fa. Application Consulting Group (ACG) 왘 Wired for OLAP, Fa. Appsource Corp. 왘 Platinum ERA Business Performance Suite, Fa. Epicor 왘 ECSDTool, Fa. Enterprise Computing Services 왘 Cizer Server, Fa. Cizer Software. 왘 Max, Fa. Maximal Corp. 왘 Comshare Decision, Fa. Comshare 왘 Seagate Worksheet, Fa. Seagate Software
Alle weiteren Informationen bezüglich der Software von Drittanbietern für Analysis Services kann unter der Adresse: http://www.microsoft.com/sql/productinfo gefunden werden.
28.4 Zusammenfassung Die für MS Analysis Services zur Verfügung stehenden Clients können drei unterschiedliche Formen haben: 왘 Tabellenkalkulationsprogramme 왘 Ad-hoc-Abfragen 왘 Berichtsgeneratoren.
Die Firma Microsoft bietet das Tabellenkalkulationsprogramm Excel an, das in seiner aktuellen Version – Excel 2000 –, die volle Unterstützung für MS Analysis Services bietet. Der SQL Server unterstützt auch einige TransactSQL-Erweiterungen bezüglich der SELECT-Anweisung, die sich für die Erstellung der speziellen Abfragen eignen. Schließlich können Benutzer von MS Analysis Services für komplexe Abfragen und anspruchsvolle Berichte Werkzeuge von Drittanbietern verwenden.
566
V
Teil
Erstellung der Softwarelösungen mit MS SQL Server
567
29
SQL Server und XML
Dieses Kapitel behandelt eines der wichtigsten neuen Themen im SQL Server 2000: die Unterstützung von Extended Markup Language (XML). In der Einführung wird eine allgemeine Erklärung zu den Themen WWW, Auszeichnungssprachen (markup languages) und die Stellung von XML innerhalb dieser Sprachen gegeben. Der zweite Teil des Kapitels zeigt die notwendigen Schritte, die gemacht werden müssen, um ein System XML-fähig zu machen. Schließlich werden unterschiedliche XML-Modi gezeigt.
29.1 Einleitung In den letzten Jahren hat das Internet seinen Weg vom kleinen Netzwerk, das exklusiv von einigen wenigen Wissenschaftlern verwendet wurde, zum umfassenden Kommunikations- und Informationsmedium, das praktisch von Millionen von Menschen verwendet wird, eingeschlagen. Die wichtigste Komponente von Internet heißt World Wide Web (WWW).
29.1.1
World Wide Web
WWW ist für das Internet enorm wichtig, weil diese Komponente für viele Aktivitäten verwendet werden kann. Sie umfaßt alle anderen Internet-Dienste (mit Hilfe einer einheitlichen Benutzeroberfläche). Generell hat WWW vier Teile: 왘 Web-Server 왘 Web-Browser 왘 HTML (Hypertext Markup Language) 왘 HTTP (Hypertext Transfer Protocol).
Der Web-Server schickt Web-Seiten (gewöhnlich HTML-Seiten) zum Netzwerk. Der Browser empfängt sie und zeigt sie auf dem Bildschirm an. (Microsoft Internet Explorer stellt einen Web-Browser dar.) HTML wird benutzt, um Web-Dokumente zu erstellen. Diese Sprache ermöglicht die Formatierung von Daten, die mit Hilfe des Web-Browsers angezeigt werden. Die Sprache ist sehr einfach. (Die Einfachheit der HTML-Sprache war einer der Gründe, warum das Internet in den letzten Jahren an Bedeutung gewonnen hat.) Der wichtigste Nachteil von HTML ist, daß mit dieser Sprache nur die Ausgabeform von Daten spezifiziert werden kann. Die Sprache erlaubt nicht, die Datenlogik zu ermitteln.
569
SQL Server und XML
HTML-Dokumente sind Textdateien mit sogenannten Marken (tags). Eine Marke wird immer innerhalb eines Klammerpaares geschrieben (siehe Beispiel 29.1). Der wichtigste Teil einer HTML-Sprache sind Hyperlinks. Mit Hilfe von Hyperlinks können andere (HTML-) Dokumente, die sich irgendwo im Internet befinden, referenziert werden. Damit ist es möglich, alle vernetzten Rechner der Welt zu adressieren. Aus diesem Grund heißt das Ganze World Wide Web, also weltweites Netz. HTTP ist ein Protokoll, das das Senden von Seiten von einem Browser zu einem Web-Server ermöglicht. Falls die Seite ein Hyperlink enthält, wird das Protokoll für die Herstellung der Verbindung zum Web-Server, der im Hyperlink adressiert ist, verwendet.
29.1.2
XML und verwandte Sprachen
XML ist eine Sprache, die für die digitale Darstellung von Dokumenten verwendet wird. Diese Sprache ist mit zwei anderen Sprachen verwandt: 왘 SGML (Standard General Markup Language) 왘 HTML.
SGML ist eine sehr mächtige Auszeichnungssprache, die für den Austausch von großen und/oder komplexen Dokumenten verwendet wird. (markup kennzeichnet spezielle Zeichen, die entweder für die Formatierung des Dokumentes oder für die Darstellung seiner logischen Inhalte verwendet werden. LaTEX ist ein Beispiel einer Auszeichnungssprache.) SGML wird für viele Anwendungsgebiete wie z.B. Flugzeugwartung verwendet. Wie wir noch zeigen werden, stellt XML eine Untermenge von SGML dar (»SGML light«), die für das Internet verwendet wird. Jedes HTML-Dokument ist ein SGML-Dokument mit einer festen Typbeschreibung. (Der Begriff der festen Typbeschreibung eines Dokumentes wird im nächsten Abschnitt erläutert.) Aus diesem Grund ist HTML nichts anderes als eine Instanz von SGML. HTML hat zwei wichtige Eigenschaften: 왘 die Sprache wird nur für die Formatierung eines Dokumentes verwendet 왘 sie ist keine erweiterbare Sprache.
HTML ist eine Auszeichnungssprache, die für die Beschreibung der Datenausgabe verwendet wird. Andererseits bietet diese Sprache mehr als die reine Präsentation von Daten wie z.B. LaTEX, weil ihre Elemente allgemeine Natur haben. (XML, im Unterschied zu HTML, beschreibt zusätzlich die logische Struktur eines Dokumentes.) HTML hat eine feste Anzahl von Elementen, d.h. sie ist nicht erweiterbar. Auf der anderen Seite ist XML, wie der Name schon besagt, eine erweiterbare Sprache. Das bedeutet, daß die Sprache für die Definition spezifischer
570
Einleitung
Elemente (Entitäten und Attribute) verwendet werden kann. (Alle neuen Begriffe, wie Entitäten und Attribute, werden im nächsten Abschnitt beschrieben.)
29.1.3
Grundkonzepte von XML
XML wird für die digitale Darstellung eines Dokumentes verwendet. Um diese Aufgabe zu bewältigen, muß die Struktur des Dokumentes bekannt sein. Nehmen wir ein Buch als Beispiel eines Dokumentes an: Zuerst können wir es in einzelne Kapiteln (mit Titeln) unterteilen. Jedes Kapitel umfaßt mehrere Abschnitte (mit ihren Titeln und dazugehörenden Abbildungen) und jeder Abschnitt hat einen oder mehrere Absätze. Alle Teile eines Dokumentes, die zu seiner logischen Struktur gehören, heißen Elemente. Deswegen stellt jedes Element in XML eine Komponente des Dokumentes dar. (Dementsprechend sind Kapitel, Abschnitte und Absätze Elemente eines Buches.) Jedes Element kann andere Elemente enthalten. (Teile eines Elementes, die nicht zu der logischen Dokumentenstruktur gehören, heißen character data. Einzelne Sätze oder Wörter eines Buches stellen z.B. character data dar.) Weil ein Element andere Elemente enthalten kann, bilden alle Elemente eines Dokumentes eine Hierarchie. Jede Hierarchiestruktur hat ein Element, das in keinem anderen Element enthalten ist. Dieses Element ist die Wurzel der Hierarchie. Dementsprechend existieren Elemente auf der niedrigsten Hierarchieebene, die keine Elemente enthalten. Diese werden Blätter genannt. (Falls wir das oben genannte Beispiel mit Buch betrachten, würde das Buch selbst das Wurzelelement sein und Absätze würden die Blätter darstellen.) Jedes Element kann zusätzliche Information enthalten, die es weiter beschreibt. Solche Information wird Attribut (des Elementes) genannt. Damit beschreibt ein Attribut Eigenschaften eines Elementes. Elemente und Attribute bilden die logische Struktur eines Dokumentes. Neben der logischen besitzt jedes Dokument auch eine physikalische Struktur. Die kleinste physikalische Einheit eines Dokumentes ist ein Zeichen. Mehrere logisch zusammenhängende Zeichen, die einen Namen tragen, werden Entität genannt. Wie wir schon erörtert haben, erlaubt XML die Definition der Struktur eines Dokumentes. Eine weitere XML-Komponente namens Typ-Definition eines Dokumentes (document type definition – DTD) wird für die Definition von Elementen, Attributen und Entitäten verwendet. Dementsprechend kann ein Dokument einer vorgegebenen Typ-Definition entsprechen oder nicht. Ein Dokument, das einer existierenden Typ-Definition entspricht, wird gültiges Dokument genannt.
571
SQL Server und XML
Neben der Beschreibung der logischen Struktur ist es auch wichtig die Formatierung von Daten eines Dokumentes zu beschreiben. (Das ist besonders wichtig, falls man keinen Web-Browser verwenden will.) Für diese Aufgabe bietet XML eine weitere Sprache namens XLS (Extensible Stylesheet Language). Alle Begriffe, die wir schon beschrieben haben, gehören zu der allgemeinen XML-Terminologie. Microsoft benutzt einen (spezifischen) Begriff namens template (Schablone). Ein template beschreibt einen strukturierten Block von XML-Code, der eine Transact-SQL-Anweisungsfolge enthält. Mit Hilfe von templates können Daten einer SQL Server-Datenbank gelesen werden, die dann als ein XML-Dokument ausgegeben werden (siehe Beispiele 29.3 und 29.4). Jedes template wird gewöhnlich in einer Datei gespeichert. Solche Dateien können in einem Dateiverzeichnis gespeichert werden, das in bezug zu einer virtuellen Wurzel (virtual root) steht. Danach können diese Dateien mit Hilfe eines ULR (Universal Resource Locator) ausgeführt werden. (Virtuelle Wurzeln werden im nächsten Abschnitt beschrieben.) Nachdem wir die drei wichtigsten Begriffe (XML, DTD und XSL) beschrieben haben, können wir ein Beispiel zeigen, das Beziehungen zwischen diesen Begriffen zeigt. Beispiel 29.1
DTD:
]>
XSL:
XML:
572
Einleitung
Beispiel 29.2 enthält eine URL-Adresse, die den Zugriff auf einen SQL Server namens NTB11901 mittels einer Abfrage ermöglicht. Die Abfrage wählt Reihen der Tabelle mitarbeiter aus. (Die Beschreibung der FOR XML RAW-Option, die in diesem Beispiel verwendet wurde, wird später in diesem Kapitel gegeben.) Beispiel 29.3
http://localhost/beispiel/queries/simpleselect.xml
Das Ergebnis ist: