|
Die wichtigste Neuerung in der Version 9 ist zweifellos die Integration
von XML. Darüber hinaus gibt es eine Reihe von Verbesserungen und neuen
Funktionen im relationalen Teil von DB2. Da sich die meisten Veröffentlichungen
zur Version von DB2 for LUW mit den XML-Erweiterungen ausführlich beschäftigt
haben, konzentrieren wir uns hier einmal auf die anderen Neuerungen:
Table Partitioning
Bisher kannte DB2 for LUW nur die Partitionierung auf Datenbankebene
über mehrere Rechnerknoten hinweg. Jeder Knoten besitzt dabei eine DB2-Instanz
und einen Teil der Datenbank, auf den nur er zugreifen kann (Shared-nothing-Prinzip).
Neu ist nun die Partitionierung von Tabellen an einem Rechnerknoten.
Diese Möglichkeit ist schon länger in DB2 for z/OS bekannt. Die Funktionalität
in DB2 for LUW ist aber nicht identisch mit den Möglichkeiten in DB2 for
z/OS (Version 8) und betrifft nur Tabellen, keine Indizes.
Dennoch gibt es im Zusammenhang mit Tabellenpartitionierung auch für
Indizes Fortschritte: Bei nicht partitionierten Tabellen werden alle Indizes
in demselben Speicherobjekt angelegt, das bei DMS (Data Managed Storage)
in einem anderen Tablespace liegen kann. Für partitionierte Tabellen wird
jeder Index in einem eigenen Speicherobjekt angelegt. Jeder Index kann
somit in einem anderen Tablespace liegen. Die Vorteile davon sind
- effizienterer konkurrierender Zugriff
- verbesserte Verfügbarkeit bei Operationen wie CREATE, DROP ALTER TABLE/
DETACH oder Reorganisation.
Die Tabellenpartitionen können wie eigenständige Tabellen behandelt werden
und in unterschiedlichen Tablespaces oder einem angelegt werden. So können
Partitionen einzeln gesichert oder wiederhergestellt werden statt der
gesamten Tabelle. Performance-Vorteile resultieren aus der Parallelverarbeitung
von Partitionen in Abfragen oder dem Ausschluss von Partitionen beim Table-Scan.
Beispiel:
Die Vorteile der Partitionierungsfunktion werden an einem Beispiel mit
zeitbezogenen Daten wie Versand-Aufträgen deutlich. Die Tabelle VAUFTRAG
wird nach dem Versanddatum (VDATUM) partitioniert. Je Quartal ist eine
Partition vorgesehen. In die erste werden aber alle Daten mit einem Versanddatum
vor dem 1.1.2006 aufgenommen (Angabe MINVALUE). Ein Versanddatum nach
dem 31.12.2006 ist nicht erlaubt.
create table VAUFTRAG(oid int not null primary key,
VDATUM date not null,
VERSTEXT varchar(3200))
partition by range(VDATUM) (
partition q405 starting minvalue,
partition q106 starting '01.01.2006',
partition q206 starting '01.04.2006',
partition q306 starting '01.07.2006',
partition q406 starting '01.10.2006' ending '31.12.2006');
Ein besonders interessanter Aspekt der Partitionierung ist die Möglichkeit,
Partitionen rollieren zu lassen. Werden die Daten von 2005 nicht mehr
in der Tabelle VAUFTRAG benötigt, so können sie per DETACH abgehängt werden.
Die Partition bildet dann eine eigenständige Tabelle, die anschließend
archiviert werden kann.
alter table VAUFTRAG detach partition q405 into VAUFTRAG4q05
Die betroffenen Indizes werden im Hintergrund asynchron angepasst (Asynchronous
Index Cleanup AIC).
Analog ist es möglich, eine Tabelle mit kompatibler Struktur per ATTACH
als neue Partition zu integrieren. Hierbei muss der Befehl SET INTEGRITY
nach dem ATTACH ausgeführt werden, um die Operation zu vollenden. SET
INTEGRITY prüft die Einhaltung des Partitionsbereiches und sonstiger Bedingungen
und pflegt die Indizes.
Für neue Daten wie die Aufträge im ersten Quartal 2007 kann eine Partition
mit ADD hinzugefügt werden:
alter table VAUFTRAG
add partition q107 starting '01.01.2007' ending '31.03.2007';
Table Partitioning kann mit den bisher bekannten Möglichkeiten der Datenanordnung
wie Database Partitioning oder Multidimensional Clustering (MDC) kombiniert
werden.
Datenkompression
Für DB2 for z/OS ist Datenkompression eine bewährte Funktion, die bei
klassischen kaufmännisch-administrativen Anwendungen Kompressionsraten
von 50-80 % erzielt. Mit Version 9 wird die Datenkompression auch in DB2
for LUW verfügbar.
Die Bitmuster-Kompression (mit dem Lempel-Ziv -Algorithmus) benötigt
ein Dictionary zur Umsetzung. Dieses Dictionary gilt für die gesamte Tabelle
und wird im gespeicherten Objekt abgelegt. Diese wird beim CREATE TABLE
oder mit ALTER TABLE eingeschaltet.
Die Vorteile der Kompression liegen
- in der Einsparung von belegtem Speicher,
- in weniger I/Os,
- in mehr gelesener Zeilen je physischen Zugriff
- geringerer Bufferpool-Belegung bei verbesserter Hit-Ratio.
Der mit der Datenkompression verbundene Nachteil ist die zusätzliche
CPU-Belastung für die Komprimierung und Dekomprimierung.
Beispiel:
Die Tabelle DB2INST9.EMPLOYEE belegt 14,9 MB mit 172032 Zeilen in 3825
Pages. Zur Abschätzung des Komprimierungseffekts kann der INSPECT-Befehl
genutzt werden:
inspect rowcompestimate table name employee
results keep empcomp;
INSPECT gibt seine Schätzung in einem internen Format in die Datei empcomp
aus. Die Aufbereitung erfolgt mit Programm db2inspf:
db2inspf empcomp compempf
Das formatierte Ergebnis steht in Datei compempf und sieht wie
folgt aus:
DATABASE: TESTV9
VERSION : SQL09000
2006-06-09-13.51.07.045534
Action: ROWCOMPESTIMATE TABLE
Schema name: DB2INST9
Table name: EMPLOYEE
Tablespace ID: 2 Object ID: 18
Result file name: empcomp
Table phase start (ID Signed: 18, Unsigned: 18; Tablespace ID: 2)
: DB2INST9.EMPLOYEE
Data phase start. Object: 18 Tablespace: 2
Row compression estimate results:
Percentage of pages saved from compression: 78
Percentage of bytes saved from compression: 78
Percentage of rows ineligible for compression due to small row size: 0
Compression dictionary size: 23680 bytes.
Expansion dictionary size: 32768 bytes.
Data phase end.
Table phase end.
Processing has completed. 2006-06-09-13.51.13.901962
Es wird also eine Ersparnis von 78 % geschätzt, sodass sich die Komprimierung
lohnt. Mit ALTER TABLE wird sie definiert:
ALTER TABLE DB2INST9.EMPLOYEE COMPRESS YES
Mit einer Reorganisation (REORG TABLE) wird sie durchgeführt. Nur das
Dienstprogramm REORG kann das Dictionary aufbauen. Danach belegt die Tabelle
DB2INST9.EMPLOYEE noch 3,2 MB mit unverändert 172032 Zeilen in 809 Pages.
LBAC - Label Based Access Control
Steigende Benutzeranforderungen und rechtliche Regelungen bezüglich des
Datenschutzes beantwortet IBM in DB2 V9 mit der Label Based Access Control
(LBAC) und einem neuen Berechtigungsprofil, dem Security Administrator
(SECAM).
Der Security Administrator definiert Label Based Access Control und vergibt
oder widerruft Label-Berechtigungen. Dazu ist kein anderes Profil berechtigt,
auch nicht SYSADM.
Logische Voraussetzung für die Nutzung von LBAC ist ein Sicherheitskonzept
(Security Policy), das die Kriterien beschreibt, wonach ein Nutzer Zugriff
auf bestimmte Daten erhält. Aufgrund dieses Konzepts werden Security Labels
definiert und Daten zugeordnet. Benutzer erhalten Zugriff auf die geschützten
Daten durch die Zuordnung von Security Labels. Durch den Vergleich der
Security Labels von Benutzer und Daten wird festgestellt, ob dieser zum
Zugriff berechtigt ist. Ist der Benutzer nicht zum Zugriff berechtigt,
behandelt DB2 die Daten in einem solchen Fall, als ob sie nicht existieren.
Auch Funktionen wie COUNT() oder SUM() berücksichtigen nur die Daten,
für deren Zugriff der Benutzer berechtigt ist.
- Die Regeln (Rules) für den Vergleich von Benutzer- und Daten-Label
sind derzeit in DB2 fest vorgegeben (DB2LBACRULES)
- Eine Security Policy besteht aus maximal 16 Komponenten, in denen
die Sicherheitsstufen definiert werden. Es gibt drei Strukturen dafür:
- Set (Aufzählung)
- Array (geordnete Aufzählung, einfache Hierarchie)
- Tree (Baumstruktur, komplexe Hierarchie)
- In Labels werden Werte dieser Komponenten definiert und DB2-Objekten
oder Benutzern zugeordnet.
- Durch die Labels können Spalten oder Zeilen einer Tabelle oder eine
Kombination aus Spalten und Zeilen gegenüber unbefugten Zugriffen geschützt
werden.
Zum Beispiel kann es sinnvoll sein, die Personalstammdaten eines Unternehmens
so zu schützen, dass nur bestimmte Sachbearbeiter die Datensätze eines
Bereichs lesen oder pflegen dürfen. Weiterhin ist die Bearbeitung von
AT-Angestellten und Führungskräften besonderen Sachbearbeitern oder Gruppenleitern
vorbehalten. Der Vorstand wird nur vom Leiter der Personalabteilung betreut.
Dieses Beispiel erfordert eine Zugriffskontrolle auf Zeilenebene.
Sollen jedoch bei den Personaldaten Name, Organisationseinheit und Telefon
für jeden abfragbar sein, die übrigen Spalten mit Geburtsdatum, Ausbildung
und Gehalt nur der Personalabteilung vorbehalten bleiben, ist eine Zugriffskontrolle
auf Spaltenebene notwendig.
Wenn jetzt noch für die der Personalabteilung vorbehaltenen Daten die
Beschränkungen nach Bereichszugehörigkeit und Dienststellung gelten, ist
eine Kombination von zeilen- und spaltenbezogener Zugriffskontrolle notwendig.
Vorgehensweise:
Die Umsetzung eines Sicherheitskonzepts ist recht aufwendig und zu komplex,
um es in einem Überblick über DB2 V9 darstellen zu können. Daher beschreiben
wir nur die prinzipielle Vorgehensweise: Zuerst müssen die Sicherheitsanforderungen
analysiert und in einem Konzept festgehalten werden. Dann kann die Umsetzung
in DB2-Defintionen durch den Security Administrator mit der Beschreibung
der Komponenten beginnen:
CREATE SECURITY LABEL COMPONENT ...
Die Komponenten werden zu einer Policy zusammengefasst:
CREATE SECURITY POLICY ... COMPONENTS .... WITH DB2LBACRULES
Dann werden die Labels mit ihren Werten definiert:
CREATE SECURITY LABEL . COMPONENT . 'wert' .
Und an Benutzer vergeben:
GRANT SECURITY LABEL .TO USER ... FOR
Benutzer können jeweils für lesenden oder schreibenden Zugriff nur ein
Security Label erhalten.
Eine bestehende Tabelle wird um die Security Policy und für den Zugriffsschutz
auf Zeilenebene um eine Spalte ergänzt:
ALTER TABLE ... ADD ... SECURITY POLICY ....
ADD COLUMN .... DB2SECURITYLABEL
Dann müssen die Zeilen das vorgesehene Security Label erhalten
UPDATE TABLE ... SET ... = SECLABEL_BY_NAME( ...)
WHERE ...
Drei Funktionen ermöglichen das Setzen und Lesen der Labels:
SECLABEL()
SECLABEL_BY_NAME()
SECLABEL_TO_CHAR()
Es sei noch darauf hingewiesen werden, dass die LBAC der DB2 UDB Version
9 sich hinsichtlich ihrer Implementierung deutlich von der Labeled Security
Protection in DB2 z/OS Version 8 unterscheidet.
Diese drei oben erläuterten Erweiterungen sind
leider der Enterprise Server Edition (ESE) von DB2 vorbehalten.
Weitere Verbesserungen
Bezüglich der Installation von DB2 wird die Flexibilität durch Version
9 deutlich verbessert:
- Es können mehrere Kopien der DB2-Software auf einem Server installiert
werden.
- Der Installationspfad kann frei gewählt werden.
- Die installierten DB2-Systeme sind bezüglich ihrer FixPak-Levels voneinander
unabhängig.
- Ein neuer ODBC/CLI-Treiber ist unabhängig von DB2-Server- oder Client-Paketen
und kann auch mehrfach installiert werden.
Diese Verbesserungen helfen Software-Häusern, DB2 in ihre Anwendungen
zu integrieren und in einem Paket dem Kunden auszuliefern.
|
