Home

19. Mai 2013

Release V5R4M0

Neues in Datenbank und SQL

In den letzten Releases hat IBM die Datenbank, die im Betriebssystem der iSeries (System i) integriert ist, von Grund auf verändert und wichtige Erweiterungen implementiert. Der Schwerpunkt der Entwicklung liegt dabei auf SQL (Structured Query Language). Allerdings kamen beim nativen Dateizugriff und der Definition von Datenbankobjekten über DDS (Data Description Specification) nur geringfügige Änderungen hinzu. Mit Release V5R4 hat sich dieser Trend ungebrochen fortgesetzt.

Mit dem Erfolg, dass die DB2 UDB for iSeries die erste Datenbank ist, die den von ISO (International Organization for Standardization) festgelegten Standard für SQL (aktuell SQL-2003 http://www.sigmod.org/sigmod/record/issues/0403/E.JimAndrew-standard.pdf)zu hundert Prozent abdeckt. Auf die wichtigsten Neuerungen – wie OLAP- (OnLine Analytical Processing-) Ranking-Funktionen, RCTE (Recursive Common Table Expression), Instead Of Triggers, neue beziehungsweise erweiterte Analyse-Tools unter der iSeries Navigator-Datenbank – werden wir in einer Reihe von Artikeln näher eingehen. In diesem Artikel wollen wir uns zunächst mit den erweiterten Datenbanken-Limits beschäftigen – sowie mit den SQL-Statements, die ab Release V5R4 von der SQL Query Enginge (SQE) verarbeitet werden können.

Erweiterte Datenbanken-Limits

Um ein Maximum an Portabilität und Flexibilität zu erreichen, wurden einige der bisherigen Datenbank-Beschränkungen beträchtlich erweitert:

Spaltennamen
Spaltennamen waren bis einschließlich Release V5R3 auf 30 Zeichen beschränkt, während für die Namen der Datenbankobjekte (zum Beispiel Tabellen, Indices, Stored Procedures) bis zu 128 Zeichen verwendet werden konnten. Ab Release V5R4 wurde das Limit für Spaltennamen ebenfalls auf 128 Zeichen erweitert. Die Systemnamen bleiben weiterhin auf 10 Zeichen begrenzt.

Anzahl der verknüpften Dateien
Ab Release V5R4 können in einem einzigen SQL-Statement bis zu 1.000 Tabellen verknüpft werden. Die bisherige Grenze lag bei 256 Tabellen. Diese Grenze gilt auch weiterhin für die Anzahl von Verknüpfungen innerhalb von Datenbankobjekten – wie Views oder MQTs (Materialized Query Tables).

Maximale Länge eines SQL-Statements
Die maximale Länge eines SQL-Statements wurde von 65.535 Byte auf 2 Gigabyte erhöht. Damit ist es möglich, noch wesentlich komplexere Stored Procedures, Trigger oder User Defined Functions (UDF) zu codieren. Obwohl diese Statements sich aus einzelnen auszuführenden Befehlen zusammensetzen können, werden die SQL-Anweisungen – CREATE PROCEDURE, CREATE TRIGGER oder CREATE FUNCTION – mit allem was dazugehört, jeweils als ein einzelnes Statement betrachtet.

Anzahl Spalten bzw. Länge der Spalten in einer Order By-Anweisung
Während unter Release V5R3 nur maximal 1.000 Spalten mit einer Gesamt-Länge von bis zu 1.000 Bytes in einer Order By-Anweisung angegeben werden konnten, können unter Release V5R4 maximal 32.766 Spalten mit einer Gesamtlänge von bis zu 32.766 Byte verwendet werden.

Anzahl Parameter in Stored Procedures
Ab Release V5R4 ist es möglich, für SQL beschriebene Stored Procedures bis zu 1.024 Parameter zu definieren. Die Anzahl der maximal zulässigen Parameter für externe Stored Procedures dagegen ist zum Einen abhängig von den Restriktionen in den einzelnen Programmiersprachen, in denen die Prozeduren geschrieben wurden, und zum Anderen vom verwendeten Parameter-Style:

Parameter-Style GENERAL: 1.024 Parameter
Parameter-Style GENERAL WITH NULLS: 1.023 Parameter
Parameter-Style SQL oder DB2SQL: 508 Parameter
Parameter-Style JAVA oder DB2GENERAL: 90 Parameter

Die Anzahl der übergebenen Parameter für SQL-beschriebene und externe User Defined Functions (UDF) bleibt weiterhin auf 90 beschränkt.

Von der Classic Query Engine (CQE) zur SQL Query Engine (SQE)

In den letzten Releases wurde Schritt für Schritt eine neue Query Engine zur Verarbeitung von SQL-basierten Datenbankabfragen eingeführt: SQL Query Engine (SQE). Die neue Query Engine wurde im OO- (= objektorientiert) Design erstellt und kann dadurch wesentlich flexibler agieren als die klassische (classic) Query Engine (CQE). Sämtliche Neuentwicklungen im Bereich von SQL-Abfragen und deren Optimierung erfolgen in und für die neue SQE. Abfragen, die mit CQE bearbeitet werden müssen, können von diesen Neuerungen nicht profitieren. Die Entscheidung, durch welche der beiden Query Engines die Bearbeitung einer Abfrage erfolgt, trifft der Query Dispatcher, an den sämtliche Datenbankenabfragen zunächst geleitet werden. Die einzige Möglichkeit, auf die Entscheidungen des Query Dispatchers Einfluss zu nehmen, ist über die Art, wie eine SQL-Abfrage erstellt wird – zum Beispiel: die Syntax oder die Vermeidung von Features, die SQE nicht verarbeiten kann. Mit jedem neuen Release wurden der SQE neue Funktionalitäten zugefügt, sodass immer weniger Abfragen von der CQE bearbeitet werden müssen. Mit Release V5R4 können nun auch Abfragen mit den folgenden Funktionalitäten von der SQE verarbeitet werden:

• SQL-Abfragen mit LIKE-Prädikaten oder Substring-Funktionen
• SQL-Abfragen mit Zugriff auf Large Object- (LOB-) Spalten
• SQL-Abfragen mit Live-Datenverarbeitung
Für einige Abfragen ist es unbedingt erforderlich, mit Live-Daten und nicht mit einer temporären Kopie der Daten zu arbeiten. Diese Live-Verarbeitung kann innerhalb von Programmen oder Prozeduren auf zwei Arten erzwungen werden:
o Durch die Definition eines sensitiven Cursors.
Nach dem Öffnen des Cursors werden alle Änderungen (zum Beispiel durch Hinzufügen oder Löschen von Datensätzen) im Result-Set aktualisiert.
o Die Option ALWCPY (Allow Copy) wird entweder im Compile Command oder über ein SET OPTION-Statement auf *NO gesetzt.

SQL-Abfragen, in denen die folgenden Funktionalitäten verwendet werden, können noch nicht von der SQE verarbeitet werden:

• SQL-Abfragen, mit speziellen skalaren Funktionen
SQL-Abfragen, in denen skalare Funktionen zur Konvertierung von alphanumerischen Zeichen – wie UPPER, LOWER oder TRANSLATE – verwendet werden, müssen weiterhin von der CQE ausgeführt werden.

• SQL-Abfragen mit NLSS (National Language Sort Sequence) und CCSID (Coded Character Set Identifier) Konvertierung
Die Default-Sortierreihenfolge ist *HEX. Dabei werden kleine Buchstaben vor großen Buchstaben vor Ziffern sortiert. Ist eine Sortierung unabhängig von Groß- und Kleinschreibung erforderlich, kann dies durch Änderung der Sortierreihenfolge auf *LANGIDSHR oder *LANGIDUNQ erfolgen. Der Unterschied zwischen diesen beiden Sortierreihenfolge liegt in der Wertigkeit der einzelnen Zeichen. Bei Sortierreihenfolgen *LANGIDSHR haben große und kleine Buchstaben die gleiche Wertigkeit, während sie bei *LANGIDUNQ unterschiedliche Wertigkeit besitzen. Im Klartext heißt das: Wird in den Where-Bedingungen LIKE ’%Meier%’ angegeben, werden bei Sortierreihenfolge *LANGIDUNQ alle Meiers selektiert (großes „M“ kleine „eier“), bei *LANGIDSHR werden dagegen alle Meiers, unabhängig von Groß- oder Kleinschreibung ausgewählt – also sowohl „Meier“ als auch „MEIER“ als auch „meier“ usw.

Ist für eine Abfrage eine andere Sortierreihenfolge als *HEX erforderlich, wird diese Abfrage bis dato von der CQE verarbeitet. Eine Unterstützung durch die SQE ist für zukünftige Releases geplant.

• SQL-Abfragen, in denen User Defined Table Functions (UDTFs) verwendet werden
Funktionen zeichnen sich dadurch aus, dass ein Ergebnis in Form eines Rückgabewertes ausgegeben wird. User Definied Functions (UDF), können entweder direkt in SQL oder in jeder beliebigen ILE-Programmier-Sprache (ILE RPG, ILE COBOL, ILE C) oder auch in JAVA geschrieben sein. Funktionen, die nicht in SQL geschrieben wurden, müssen über den SQL-Befehl CREATE FUNCTION als UDF registriert werden und können dann über jedes SQL-Interface aufgerufen werden.

User Defined Table-Funktionen sind eine besondere Art von Funktionen. Statt eines einzigen Rückgabewertes können mehrere Rückgabewerte in Form einer Tabelle ausgegeben werden – das heißt: Das Ergebnis kann aus einer oder mehreren Zeilen bestehen, die wiederum in verschiedene Spalten unterteilt sein können. UDTFs werden in Select-Statements wie andere Tabellen (physische Dateien) verwendet und durch das Schlüsselwort TABLE gekennzeichnet.

Im folgenden Select-Statement wird das Ergebnis aus einer User Defined Table Function verarbeitet.

Select * 

   from  Table(GetAddress('Hessen')) as MyUDTF

   Where Stadt = 'Frankfurt'

   Order by NachName, PLZ, Strasse

Zum Seitenanfang

© 2010 | ITP VERLAG GmbH | Alle Rechte vorbehalten.