Sicherheitserweiterungen
Wie in Version 9 von DB2 for z/OS bereits geschehen, sind nun auch in Version 9.5 von DB2 for LUW die Sicherheitskomponenten Trusted Context und Rolle eingeführt. Eine Datenbankrolle ist eine virtuelle Berechtigungs-ID, die einem Benutzer oder einer Gruppe zugeordnet ist. Sie ist ein Datenbankobjekt, in dem eine oder mehrere Berechtigungen zusammengefasst sind. Damit wird die Verwaltung von Berechtigungen vereinfacht. Es lassen sich für Benutzer mit gleichen Aufgaben Berechtigungsprofile erstellen, ohne dass Benutzergruppen außerhalb von DB2 zum Beispiel im Betriebssystem definiert werden müssen. Ein Trusted Context definiert eine gesicherte Verbindung zwischen einer DB2-Datenbank und einer externen Einheit wie einem Client oder einem Middleware- beziehungsweise Application-Server.
Das Problem bestand bislang darin, dass sich Application-Server mit einer DB2-Datenbank häufig über eine einzige User-ID verbinden, um darunter alle Anforderungen an DB2 zu stellen. Diese User-ID muss sämtliche administrativen Berechtigungen für den Server sowie diejenigen, die für die Ausführung der Anwendungen notwendig sind, besitzen. Die eigentliche Identifikation des Benutzers, der diese Anforderungen stellt, wird dabei nicht an DB2 weitergereicht. Eine Protokollierung oder Überwachung, welcher Benutzer welche Vorgänge in der Datenbank ausführt, ist also nicht möglich. Trusted Context erlaubt es nun, von der initiierenden User-ID des Servers auf die eigentliche User-ID des Endbenutzers umzuschalten.
Performance
Version 9.5 enthält zudem zahlreiche Performance-Verbesserungen. Dies gilt zum Beispiel für die Antwortzeiten komplexer Abfragen bezüglich Zeitreihen, Raumdaten oder LOBs (Large Objects). Als Alternative zu den bisher üblichen Sperren hat IBM eine "optimistische Concurrency-Kontrolle" eingeführt. Das optimistische Sperrverhalten dient der Vermeidung von Deadlocks und der Steigerung des Durchsatzes durch reduzierte Wartezeiten. Für Tabellenbereiche ist NO FILE SYSTEM CACHING Standard. Für neue Tablespace Container, die in Version 9.5 erstellt werden, versucht der Database Manager, wo immer möglich die Funktion Concurrent I/O (CIO) zu nutzen. Bei Systemkonfigurationen, die CIO nicht unterstützen, wird stattdessen Direct I/O (DIO) oder Buffered I/O benutzt. Parallelverarbeitung beim Index-Aufbau ist unabhängig vom Konfigurationsparameter für Intra-Parallelität standardmäßig aktiviert.
|
Identifier Name |
Länge in Version 9.1 (Bytes) |
Länge in Version 9.5 (Bytes) |
|
Attribute |
18 |
128 |
|
Authorization-ID (Authid) |
30 |
128 |
|
Column |
30 |
128 |
|
Constraint |
18 |
128 |
|
Cursor |
18 |
128 |
|
Database Partition Group |
18 |
128 |
|
Event Monitor |
18 |
128 |
|
Group |
30 |
128 |
|
Package |
8 |
128 |
|
Schema |
30 |
128 |
|
Specific Name |
18 |
128 |
|
SQL Path |
254 |
2048 |
|
Statement |
18 |
128 |
|
Trigger |
18 |
128 |
|
User-defined Type |
18 |
128 |
Applikationsentwicklung
Für die Anwendungsentwicklung wurden ebenfalls neue Features beziehungsweise Erweiterungen eingeführt, die der Vereinfachung etwa in Form einer besseren Portabilität dienen. Ein neuer Datentyp DECFLOAT (DECIMAL FLOAT) soll den bisher genutzten Datentyp DECIMAL (die "gepackte" Dezimalzahl des Mainframe) ablösen, weil dieser auf der LUW-Hardware nicht direkt unterstützt, sondern nur als Software-Datentyp dargestellt wird. Eine Hardware-Unterstützung für einen dezimalen Gleitkomma-Datentyp ist angekündigt. Besseren Support gibt es für Programmiersprachen wie PHP, Ruby on Rails, Perl sowie Microsoft Visual Studio 2005.
Die maximalen Längen der Identifier (Objektnamen) betragen jetzt 128 Bytes, was auch die Portierung von DDLs anderer Hersteller erleichtert, weil eine Kürzung der Objektnamen nicht mehr notwendig ist. Dies gilt jedoch nicht für die klassischen Programmiersprachen Embedded SQL, C und Cobol, weil die SQL DA noch die alten Begrenzungen behält: 8 Bytes für Schema-Namen von benutzerdefinierten Datentypen (UDTs), 18 Bytes für UDT-Namen und 30 Bytes für Spaltennamen. Ferner wurde die DB2 Developer Workbench in Data Server Developer Tool umbenannt.
|
Threshold |
Bedeutung |
Schutz vor … |
|
Elapsed Time |
abgelaufene Zeit zwischen Start und Beendigung einer Aktivität |
Langläufer |
|
Idle Time |
abgelaufene Zeit, in der die Verbindung untätig war (idle) |
uneffizienter Ressourcenverbrauch und Wartestati |
|
Estimated Cost |
geschätzte Kosten des DB2-Optimizer |
verhindert den Start von aufwendigen SQL-Befehlen |
|
Rows Returned |
Anzahl der Zeilen, die vom aktuellen SQL-Befehl zurückgegeben wurden |
extensive Ausgaben |
|
Temporary Space |
Verbrauch von temporärem Speicher in einer Partition |
Behinderung anderer durch übermäßigen Speicherverbrauch |
|
Concurent Workload Occurences |
Anzahl aktiver Ausprägungen eines Workloads auf einer koordinierenden Partition (coordinator partition) |
Überladung durch eine Quelle |
|
Total Database Partition Connections |
Anzahl Verbindungen zu einer bestimmten Partition |
Schutz der Partition vor Überlastung |
|
Total Service Class Connections |
Anzahl Verbindungen zu einer Partition innerhalb einer Service-Klasse |
Schutz der Partition vor Überlastung (verfeinert) |
|
Concurrent Workload Activities |
Anzahl von Aktivitäten innerhalb eines Workloads |
begrenzt die Workload-Objekte |
|
Concurrent Database Activities |
Anzahl von Aktivitäten innerhalb eines Workloads |
begrenzt die Aktivitäten innerhalb eines Workload-Objekts |
Backup, Logging und Recovery
Zu den Verbesserungen im Bereich der Datensicherung zählen unter anderem die doppelten Log-Kontroll-Dateien (SQLOGCTL.LFH), die die Ausfallsicherheit erhöhen. Zur leichteren Sicherung und Wiederherstellung von mehreren Partitionen gibt es die neue Single-System-View–Sicherung. Das automatische Löschen von Sicherungen und alten Log-Dateien, die nicht mehr benötigt werden, vereinfacht das Objekt-Management. (ue)