>IBM richtet all seine /

Transkript

1 Anwendung sent wicklung 2077 Die neue DB2 Pures XML und einfache Verwaltung Im Bereich Datenbanken scheint sich wieder etwas Neues zu bewegen. Rechtzeitig zum zehnjährigen XML-Jubiläum erweitert IBM mit der DB2-Version 9.1 Projektname Viper seinen Datenbank-Zoo um eine hybride Variante. Die integrierte, native XML-Unterstützung innerhalb des Datenbankkerns wurde bereits im ersten Teil dieser Artikel-Serie (IT-Fokus 5/6-2006) vorgestellt. In diesem Teil wollen wir die weiteren Besonderheiten der neuen Version, wie die optimierte Unterstützung für SAP, die vereinfachte Administration und die Möglichkeit, dass sich das System im laufenden Betrieb selbst optimiert, vorstellen. Die XML-Funktionen sind eher für Entwickler und Architekten interessant, wohingegen die letzteren Funktionen für Administratoren interessant sind. Im Folgenden werden wir auf die neuen Funktionen von DB2 9.1 und ihren Nutzen für die Kunden eingehen. SOA: Informationen als Service Nach der E-Business-Initiative hat IBM jetzt alle seine Produkte auf SOA ausgerichtet. So wundert es nicht, dass auch DB2 hier eine bedeutende Rolle, nicht nur als Webservices-Provider und Verbraucher von Webservices über SOAP, spielt. Deswegen gibt es auch eine abgespeckte WebSphere Federation Server (vorher DB2 Information Integrator) Version. Alternativ kann jedoch auch TOMCAT oder der WebSphere-Applicationserver eingesetzt Dieser wird auch für die DB2 Data Warehouse Edition (DWE) Administration Console verwendet, die komplett portalbasiert ist. Selbstverwaltende Systeme (Autonomic Computing) Hinter dem Schlagwort Autonomic Computing verbergen sich Werkzeuge der Kategorien selbst-überwachend, selbstkonfigurierend, selbst-optimierend und selbst-wartend. DB2 vereinfacht und automatisiert viele Administrationstätigkeiten, sodass dafür immer weniger Zeit und Know-how benötigt wird. All diese Maßnahmen sollen helfen die TCO (total cost of ownership) zu reduzieren. Hinter der Service-on-Demand-Initative von IBM steckt letztendlich die Vision der sich selbst überwachenden und optimierenden Systeme. Dazu bietet die neue DB2-Version verschiedene Erweiterungen (Adaptive Self-Tuning Memory, Memory Visualizer, Indoubt Transaction Manager) an. Damit soll der Administrator entlastet und die Verfügbarkeit des Systems erhöht Die bereits in der Version enthaltenen SMART(SelfMa nagingandressourcetuning)-werkzeuge (Health Center, Automatic Database Diagnostic Monitor, Configuration Advisor, Design Advisor, Automatic Database Memory Management und die Option für das Automatic Storage Management) wurden noch mal verbessert, da jetzt noch mehr Speicherbereiche überwacht Auto-Konfiguration Bis zur Version 8 musste der Konfigurationsadvisor manuell aufgerufen werden, um sich Vorschläge zu Verbesserung der Konfiguration von Datenbank und Datenbank-Manager (Instanz) errechnen zu lassen. DB2 Viper startet den Konfigurationsadvisor automatisch und übernimmt einige grundlegende Empfehlungen. So werden zum Beispiel die Größe des Default-Bufferpools und die Anzahl der I/O-Cleaner und I/O-Server konfiguriert. Damit bleibt IBM richtet all seine Produkte, auch die DB2, auf SOA aus.< 24 11/

2 2077 Anwendung sent wicklung manchem unbedarften Nutzer eine unliebsame Überraschung erspart, weil dieser nicht wusste, dass die Startkonfiguration noch mit Standardwerten aus den Anfängen von DB2 bestückt wird. Self Tuning Memory Management (STMM) Eine wesentliche Verbesserung in der Selbstkonfiguration ist das Self Tuning Memory Management (STMM). Dabei verteilt DB2 den zur Verfügung stehenden Hauptspeicher je nach Bedarf auf Bufferpools, Sort-Bereiche, Package Cache und Sperrlisten. Auf Windows- und AIX-Plattformen kann STMM den gesamten Speicherbedarf überwachen und entsprechend die Shared Memory-Bereiche von DB2 optimieren. Dabei nimmt DB2 sich mehr Hauptspeicher oder gibt ihn wieder frei je nach Last. Wenn DB2 lastabhängig seine Speicherbereiche anpassen kann, entlastet es nicht nur den DBA bei der Konfiguration, sondern es optimiert auch dynamisch seine Performance. Die Vorteile von STMM sind insbesondere groß, wenn das Lastprofil hinsichtlich der Speicheranforderungen unbekannt ist, das Lastprofil stark schwankende Speicheranforderungen über die Zeit ausweist, der Server viel freien Speicher zur Verfügung hat, die Datenbank mehrere Bufferpools mit unterschiedlichen Page-Größen besitzt, der DBA recht unerfahren ist. Weniger sinnvoll ist der Einsatz von STMM, wenn das Lastprofil mit seinen Speicheranforderungen wohl bekannt ist, die Speicheranforderungen statisch sind, für die Datenbank nur ein begrenzter Speicherbereich zur Verfügung steht, der DBA erfahren mit den Speicherbereichen des DB2 ist. STMM ist aber keinesfalls dazu bestimmt, Mängel in der Anwendungsentwicklung (nicht performantes SQL) oder in den Datenbank-Strukturen (etwa fehlende Indizes) durch Vergrößerung der Bufferpools auszugleichen! Design Advisor Die eigene Tuningarbeit wird durch den Design Advisor unterstützt, der Vorschläge beispielsweise für Indizes, materialisierte Sichten (MQTs), mehrdimensionale Cluster- Tabellen (MDC-Tabellen), Tabellenpartitionierung macht, indem er den Optimierer, den Workload und die Datenbankstruktur berücksichtigt. Der Design Advisor dient der Verbesserung der bestehenden Datenbankstrukturen in Bezug auf einen definierten Workload. Er bedient sich intern des erweiterten Optimierers, der die Last für verschiedene Konfigurationsvarianten durchrechnet. Die Verbesserungsvorschläge werden dem Datenbank-Administrator zur Begutachtung angezeigt. Auto Maintenance Bei den selbstwartenden Funktionen schaltet DB2 V9 jetzt standardmäßig das Sammeln von Katalogstatistiken (RUNSTATS) ein. Die selbstwartenden Funktionen können mithilfe eines Assistenten (Wizard) angepasst So können, wie schon in der Version 8, Sicherungen und Reorganisationen automatisiert Standardmäßig wird Bild 1: Die DB2 SMART-Werkzeuge. zwar die Notwendigkeit überwacht, eine Sicherung oder Reorganisation durchzuführen, es wird aber nur eine Benachrichtigung darüber verschickt. Optional kann der automatische Start der Dienstprogramme konfiguriert Auch hinsichtlich der Funktionalität von Backup/Restore hat es einige Verbesserungen gegeben: Die Wiederherstellung (Recovery) ist nun restart-fähig: RECOVER setzt automatisch dort wieder auf, wo es zuvor gestoppt hat. Eine Datenbank kann auch durch Tablespace-Sicherungen vollständig wiederaufgebaut Damit entfällt die Notwendigkeit für eine Komplett-Sicherung der Datenbank (Full Backup). Automatic Storage Management Die automatische Speicherverwaltung, die in Version eingeführt wurde, wird in Version 9 ausgebaut. Für neue Datenbanken unter V9 wird sie standardmäßig eingeschaltet. Die Tablespaces werden als DMS-Tablespaces angelegt. Die manuelle Überwachung der Container-Belegung und das Hinzufügen neuer Container oder Tablespaces entfallen. Es ist nun möglich, beim Definieren einer Datenbank mehrere Speicherpfade für die Tablespaces der Datenbank anzuge- IT FOKUS 11/

3 Anwendung sent wicklung 2077 ben. Weitere Speicherpfade können auch noch nachträglich definiert werden: Bei neuen Tablespaces werden keine Container mehr spezifiziert, sondern nur MANAGED BY AUTOMATIC STORAGE angegeben (wird derzeit im Control-Center GUI noch nicht unterstützt). Für Wachstum und Grenzen können explizite Angaben (Policies) gemacht werden: CREATE TABLESPACE USER _ 2 INITIALSIZE 1000K INCREASESIZE 300K MAXSIZE 20M Neue DMS-Tablespaces werden standardmäßig als large angelegt, dass heißt, sie arbeiten mit 6 Bytes langen RIDs (row identifier), was mehr Pages je Tablespace und mehr Zeilen je Page ermöglicht als mit den alten 4 Bytes langen RIDs. Damit wird die maximale Tablespace-Größe auf 2 bis 16 TB je nach Page-Größe (4 KB 32 KB) gesteigert. Die automatische Speicherverwaltung unterstützt jetzt auch partitionierte Datenbanken. Neu ist in DB2 V9 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 und verbesserte Verfügbarkeit bei Operationen wie CREATE, DROP ALTER TABLE AT- TACH/ DETACH oder Reorganisation. 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 aufgenommen (Angabe MINVALUE). Ein Versanddatum nach dem 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 , PARTITION Q306 STARTING , PARTITION Q406 STARTING ENDING ); Wird versucht, doch Daten mit einem unerlaubten Versanddatum aufzunehmen, werden sie mit SQLCode -327 abgewiesen: Bild 2: Die vom Design Advisor berücksichtigten Quellen. INSERT INTO VAUFTRAG VALUES (77, , DIES IST EIN TEST MIT PARTITIONIERTEN TABELLEN ) SQL0327N THE ROW CANNOT BE INSERTED INTO TABLE DB2INST9.VAUF- TRAG BECAUSE IT IS OUTSIDE THE BOUNDS OF THE DEFINED DATA PARTITION RANGES. 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). Die Tabellenpartitionen können wie eigenständige Tabellen behandelt werden und in unterschiedlichen Tablespaces oder einem angelegt So können Partitionen einzeln gesichert oder wiederhergestellt werden statt der gesamten Tabelle. Performance-Vorteile resultieren aus 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 Die Partition bildet dann eine eigenständige Tabelle, die anschließend archiviert werden kann /

4 2077 Anwendung sent wicklung ALTER TABLE VAUFTRAG DETACH PARTITION Q405 INTO VAUFTRAG4Q05 Die betroffenen Indizes werden im Hintergrund asynchron angepasst (AIC = Asynchronous Index Cleanup). 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 ENDING ; Table Partitioning kann mit den bisher bekannten Möglichkeiten der Datenanordnung wie Database Partitioning oder Multidimensional Clustering (MDC) kombiniert Datenkompression Für DB2 for z/os ist Datenkompression eine bewährte Funktion, die bei klassischen kaufmännisch-administrativen Anwendungen Kompressionsraten von 50% bis 80 % erzielt. Mit Version 9 wird die Datenkompression auch in DB2 for LUW verfügbar. Die Bitmusterkompression (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 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 (standardmäßig im unter DIAGPATH definierten Verzeichnis). Die Aufbereitung erfolgt mit Programm db2inspf: DB2INSPF EMPCOMP COMPEMPF Das formatierte Ergebnis steht in Datei COMPEMPF und sieht wie folgt aus: DATABASE: TESTV9 VERSION : SQL 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: bytes. Expansion dictionary size: bytes. Data phase end. Table phase end. Processing has completed Es wird also eine Ersparnis von 78% geschätzt, sodass sich die Komprimierung lohnt. Mit ALTER TABLE wird sie definiert: ALTER TABLE DB2INST9.EMPLOYEE COM- PRESS 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 Zeilen in 809 Pages. 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. 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 Zu- IT FOKUS 11/

5 Anwendung sent wicklung 2077 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. Bild 3: Standard-Einstellung der Automatic Maintenance. ordnung 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. tion aus Spalten und Zeilen gegenüber unbefugten Zugriffen geschützt Zum Beispiel kann es sinnvoll sein, die Personalstammdaten eines Unternehmens so zu schützen, dass nur bestimmte Sachbearbeiter die Datensätze eines Bereichs Vorgehensweise Die Umsetzung eines Sicherheitskonzepts ist recht aufwändig 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 Dann kann die Umsetzung in DB2-Defintionen durch den Security Administrator mit der Beschreibung der Komponenten beginnen: Die Regeln (Rules) für den Vergleich von Benutzer- und Daten-Label sind derzeit in DB2 fest vorgegeben (DB2LBACRU- LES). Eine Security Policy besteht aus Komponenten, in denen die Sicherheitsstufen definiert 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 Kombina- Bild 4: Standardeinstellungen für Sicherungen und Reorganisationen /

6 2077 Anwendung sent wicklung 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 IIR2 1/2 Seite 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. Referenzen: DB2 Produktinformationen: DB2 online Dokumentation: Understanding DB2 9 Security: Rebecca Bond (und andere), Pearson Education, January 2007 IBM DB2 Version 9 New Features, Paul C. Zikopolous, George Baklarz, McGraw-Hill,January 2007 DB2 9 purexml (redbook SG ): Don Chamberlin (und andere), June 2006 IT FOKUS 11/

7 Anwendung sent wicklung 2077 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 Der Installationspfad kann frei gewählt 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 Diese Verbesserungen helfen Software- Häusern, DB2 in ihre Anwendungen zu integrieren und in einem Paket dem Kunden auszuliefern. Unter Windows ist nun die Installation durch Nicht-Admin-User mit Elevated Privileges möglich. DB2 V 9 unterstützt auch das IPv6-Protokoll, das in naher Zukunft das bisherige Internet-Protokoll (IPv4) ersetzen soll. Bild 5: Automatische Speicherverwaltung ist Standard. Ausblick und Fazit Die neue Version ist, wenn man die neuen Funktionen nutzen möchte, ein weiterer Baustein hin zu einer modernen IT- Infrastruktur. Sie bietet jedoch, auch für Entwickler und Architekten, eine interessante Möglichkeit, um serviceorientierte Architekturen besser aufzubauen. Das wird auch dadurch begünstigt, dass sich DB2 mit seiner Entwicklungsumgebung und seinen Schnittstellen immer besser integrieren läßt. Damit kann die neue DB2-Version noch universeller eingesetzt Für Administratoren wird die Verwaltung und Konfiguration von DB2 erheblich vereinfacht, sodass die Ressourcen besser genutzt werden können, und die Verfügbarkeit der Datenbank erhöht wird. Damit wird DB2 auch für die Integration in Standardsoftware, nicht nur bei SAP, interessant. Frank Pientka frank.pientka@impaq-pluralis.com, Heinz Axel Pürner Heinz Axel Pürner info@puerner.com Bild 6: Hinzufügen von neuen Speicherpfaden für eine Datenbank (Bilder: IBM) /