Nouveautés de la présente édition

Lors de la création d'une base de données, DB2^(R) Universal Database (UDB) vous permet désormais d'établir une taille de page par défaut supérieure à la précédente taille de page par défaut égale à 4 096 octets (ou 4 ko). Une fois que vous avez créé la nouvelle base de données avec une taille de page explicite, celle-ci devient la nouvelle taille de page par défaut pour tous les pools de mémoire tampon et espaces table que vous créez dans cette base de données. Les espaces table initiaux de la base de données (SYSCATSPACE, TEMPSPACE1 et USERSPACE1), tout comme le pool de mémoire tampon du système (IBMDEFAULTBP), utilisent la nouvelle taille de page par défaut. Toutefois, après que cette taille de page par défaut a été établie, vous pouvez toujours créer explicitement d'autres pool de mémoire tampon et espaces table avec une taille de page différente de la taille de page par défaut.

La nouvelle taille de page par défaut peut avoir pour valeur 4 096 octets (4 ko), 8 192 octets (8 ko), 16 384 octets (16 ko) ou 32 768 octets (32 ko).

Si vous créez une base de données avec une taille de page supérieure à 4 ko, vous ne pourrez pas migrer cette base de données vers une base de données utilisant une taille de page différente.

Les éléments du moniteur d'événements d'interblocage fournissent davantage d'informations

Plusieurs nouvelles clauses ont été ajoutées à l'instruction CREATE EVENT MONITOR qui fournissent des informations détaillées sur les instructions. Il s'agit notamment d'informations d'historique sur les instructions et les valeurs d'instruction dans le cas d'interblocages.

L'instruction CREATE EVENT MONITOR a été modifiée afin que DEADLOCKS WITH DETAILS puisse utiliser l'option HISTORY pour enregistrer des informations d'historique sur les instructions dans l'unité d'oeuvre courante ainsi que des informations sur l'environnement de compilation de l'instruction. En outre, l'option VALUES peut être précisée pour enregistrer des valeurs de données pour toute variable d'entrée de chaque instruction SQL.

Lorsqu'un moniteur d'événements d'interblocage est actif et utilise les nouvelles options HISTORY ou VALUES, les performances s'en trouvent affectées car les valeurs de données sont copiées et la mémoire utilisée pour le stockage des données. Le niveau de dégradation des performances dépendra du nombre d'applications et de partitions de base de données impliqués dans le scénario d'interblocage. Un autre facteur affectant les performances est le nombre d'instructions et de valeurs de données figurant dans les listes d'historique d'instruction.

Les utilitaires d'importation et d'exportation prennent en charge les alias

Utilitaire d'importation

Avant la version 8.2.2, l'utilitaire d'importation ne prenait pas en charge l'utilisation des alias.

Avec la version 8.2.2, IMPORT INTO NICKNAME (table distante) est désormais pris en charge avec toutefois les restrictions suivantes :

L'encapsuleur fédéré, qui gère les opérations sur l'alias doit être l'un des encapsuleurs relationnels suivants :
- DB2 DRDA^(R)
- Oracle NET8
- Sybase CTLIB
- SQL Server MSSQLODBC3
- Informix^(R)
- Teradata
Les encapsuleurs ODBC et OLEDB ne sont pas pris en charge.
La cible distante, sur laquelle est défini l'alias, doit être une table.
Le type de fichier doit être IXF, ASC ou DEL.
Le mode d'importation en ligne doit être utilisé. En particulier, la clause ALLOW WRITE ACCESS doit être indiquée.
Le mode COMMITCOUNT AUTOMATIC n'est pas admis. COMMITCOUNT n doit être indiqué, où n est un nombre valide différent de zéro.
INSERT et INSERT_UPDATE sont les seules opérations admises.
Les types de colonne suivants ne sont pas pris en charge :
- Liaisons de données
- LOB
- Colonnes générées
Les modificateurs de type de fichier suivants ne sont pas pris en charge :
- indexixf ou indexschema
- dldelfiletype
- nodefaults ou use defaults
- no_type_idfiletype
- generatedignore, generatedmissing, identityignore ou identitymissing
- lobsinfile
Les tables hiérarchiques (tables basées sur un type structuré) ne sont pas prises en charge.
Si la base de données a été créée avant l'installation de la version 8.2.2 de DB2 UDB, le programme utilitaire db2updv8 doit être exécuté sur la base de données cible avant migration. Cette condition crée deux nouvelles procédures mémorisées requises par l'utilitaire d'importation.

Le non respect des restrictions listées ci-avant génère une erreur avec le code SQL -27999 :

SQL27999N The requested IMPORT operation
into a remote target
          (nickname) cannot be performed.
          Reason code = "<reason-code>".

Remarque :

Actuellement, l'importation dans un alias pour une table distante DB2/VM ne fonctionne pas correctement pour les colonnes de données binaires (FOR BIT DATA).

Utilitaire d'exportation

Avant la version 8.2.2, l'utilitaire d'exportation ne prenait pas en charge l'utilisation des alias.

Avec la version 8.2.2, EXPORT INTO NICKNAME (table distante) est désormais pris en charge avec toutefois les restrictions suivantes :

La description de la table cible nécessaire pour exécuter l'opération d'importation CREATE n'est pas sauvegardée dans le format de fichier IXF. Si nécessaire, vous devrez recréer manuellement la table cible et l'alias avant d'exécuter la commande IMPORT.
Les types de fichiers pris en charge sont IXF et DEL.

Variable de registre DB2_SKIPINSERTED

Vous pouvez utiliser la variable de registre DB2_SKIPINSERTED pour ignorer les lignes insérées non validées pour les niveaux d'isolement Cursor Stability (CS) et Read Stability (RS).

Les variables de registre DB2_SKIPDELETED et DB2_EVALUNCOMMITTED sont utilisées pour ignorer les suppressions non validées et les mises à jour non validées. Sinon, les niveaux d'isolement CS et RS requièrent le traitement des données validées uniquement.

Si vous décidez que vous pouvez ignorer toutes les lignes verrouillées parce qu'il s'agit de lignes insérées non validées, vous pouvez activer la variable de registre DB2_SKIPINSERTED afin de pouvoir ignorer ces lignes. L'activation de cette variable de registre engendre une plus grande concurrence et s'avère être le choix de prédilection pour la plupart des applications.

Il existe toutefois des cas pour lesquels il n'est pas souhaitable d'ignorer les insertions non validées. Par exemple :

Activation E-S en accès direct et en accès concurrentiel étendue aux espaces table temporaires

Avec la version 8.2.2 de DB2 Universal Database^(TM) (UDB), l'activation des E-S en accès direct sur toutes les plateformes et des E-S en accès concurrentiel sous AIX^(R) est désormais étendue pour inclure les espaces table temporaires SMS et DMS. Comme dans la version 8.2 de DB2 UDB, cette fonction peut être activée à l'aide du mot clé NO FILE SYSTEM CACHING dans les instructions SQL CREATE et ALTER.

Images d'installation pour le noyau Linux 2.6

Avec la version 8.2.2 de DB2 Universal Database (UDB) pour Linux^(TM), un nouvel ensemble d'images d'installation est désormais disponible pour les distributions Linux basées sur le noyau 2.6 et ce, pour les architectures suivantes :

Les nouvelles images d'installation activent automatiquement les améliorations de performances d'E-S en mode asynchrone et en mode vecteur pour DB2 UDB pour Linux.

Vous pouvez installer ces nouvelles images d'installation uniquement sur les distributions Linux basées sur un noyau 2.6, y compris Red Hat Enterprise Linux 4 et SuSE Linux Enterprise Server 9. Les images d'installation pour le noyau 2.6 incluent l'intitulé "noyau 2.6" dans le label du CD afin de les différencier des images d'installation pour le noyau 2.4.

Si vous avez installé une précédente version de DB2 UDB pour Linux sur une distribution basée sur un noyau 2.6, vous devez installer le FixPak pour DB2 UDB pour Linux (noyau 2.6) pour mettre à niveau votre installation DB2 UDB pour la version 8.2.2 ou une version supérieure.

Configuration d'un mécanisme shell distant plus sécurisé pour les produits DB2 DPF (UNIX)

Avant la version 8.2.2, les produits de partitionnement de base de données DB2 (DPF) sous UNIX^(R) s'appuyaient sur rsh comme mécanisme shell distant pour l'exécution des commandes sur des noeuds DB2 distants. Par exemple, lors de l'exécution de la commande db2start, les noeuds distants recevaient la commande start du gestionnaire de base de données via le programme shell distant rsh.

Avec la version 8.2.2, le mécanisme shell distant peut désormais être configuré via une nouvelle variable de registre DB2RSHCMD. Cette variable de registre vous permet d'indiquer le nom de chemin complet d'une commande de shell distant plus sécurisée, par exemple /usr/bin/ssh. Lorsque vous définissez DB2RSHCMD, toutes les commandes envoyées aux noeuds distants utilisent le programme shell distant indiqué. Le programme shell distant doit être configuré de telle façon que le propriétaire de l'instance soit autorisé à exécuter ce programme dans chaque noeud DB2 sans avoir à fournir une authentification supplémentaire telle qu'un mot ou une phrase de passe.

Variable de registre DB2NOLIOAIO remplacée par DB2LINUXAIO (Linux)

L'utilisation de la variable de registre DB2NOLIOAIO est déconseillée à partir de la version 8.2.2 de DB2 Universal Database. Pour les utilisateurs Linux, la variable de registre DB2NOLIOAIO a été remplacée par DB2LINUXAIO.

Nouvelle fonction de table pour l'interrogation du fichier historique de base de données

Avant la version 8.2.2 de DB2 Universal Database, la commande LIST HISTORY de l'interpréteur de commandes (CLP) ou des API en C étaient requises pour l'interrogation du fichier historique pour la partition de base de données à laquelle vous étiez connecté.

Avec la version 8.2.2, vous pouvez désormais utiliser la fonction de table ADMIN_LIST_HIST() pour interroger le fichier historique de base de données. Dès que vous êtes connecté à une base de données, ADMIN_LIST_HIST() renvoie le contenu du fichier historique de base de données dans un format de table pour la partition de base de données à laquelle vous êtes connecté.

Amélioration des requêtes et des performances de régénération pour DB2 Cube Views Optimization Advisor

Les tables récapitulatives recommandées par l'assistant d'optimisation (Optimization Advisor) dans DB2 Cube Views offrent une meilleure couverture de requête et des performances de régénération améliorées. Les tables récapitulatives recommandées ont été améliorées de telle façon qu'elles offrent une meilleure couverture du modèle de cube et qu'elles améliorent les performances d'un plus grand nombre de requêtes que dans les éditions précédentes. Les scripts de régénération recommandés utilisent désormais la fonction de chargement de curseur lorsque cela est possible pour réduire le temps nécessaire à la régénération des données dans une table récapitulative.