La commande db2look se termine correctement |avec les bases de données qui utilisent des espaces table de stockage |automatique. Toutefois, elle n'affiche pas les informations d'espace table |spécifiques aux espaces table de stockage automatique.
Lorsque la fonction de table SNAP_GET_DB est invoquée dans un environnement de partitionnement de base de données (environnement DPF) avec la valeur d'entrée -2 (cliché global), cette fonction renvoie des résultats incomplets pour les quatre colonnes suivantes :
Ces éléments ne peuvent pas être agrégés pour un cliché global. Pour extraire l'ensemble complet des valeurs pour ces éléments de cliché, la fonction de table SNAP_GET_DB doit être appelée individuellement sur chaque partition.
L'option REPLACE de la commande IMPORT ne respecte pas la clause NLI (NOT LOGGED INITIALLY) de l'instruction CREATE TABLE ou la clause ACTIVATE NOT LOGGED INITIALLY de l'instruction ALTER TABLE.
Si une importation avec l'action REPLACE est effectuée dans la même opération qu'une instruction CREATE TABLE ou ALTER TABLE où la clause NLI est invoquée, l'importation ne respectera pas la clause NLI. Toutes les insertions seront consignées.
Cette restriction s'applique à DB2 UDB version 7 et DB2 UDB version 8.
Au cours d'une réorganisation de table interne, ou en ligne, les données de champ étendu et de grand objet ne peuvent pas être réorganisées. Elles peuvent l'être à l'aide d'une réorganisation de table classique, ou hors connexion, en indiquant le paramètre LONGLOBDATA avec la commande REORG TABLE. Toutefois, même si la réorganisation des données de champ étendu et de grand objet permet de récupérer de l'espace libre, elle n'améliore pas la mise en cluster et peut augmenter considérablement le temps nécessaire pour terminer la réorganisation.
Dans l'isolement d'une stabilité du curseur (CS), la ligne associée à la position actuelle du curseur sur le serveur de base de données est toujours verrouillée. Lors d'un accès groupé aux données, plusieurs lignes sont renvoyées vers une seule mémoire tampon. Dans la plupart des cas, la dernière ligne traitée par le serveur ne va pas s'insérer exactement et sera segmentée entre deux mémoires tampon. L'application distinguera cette segmentation de ligne uniquement à la réception de la seconde mémoire tampon. Par conséquent, aucune des lignes renvoyées à l'application ne sera verrouillée.
Dans les rares cas où la dernière ligne traitée par le serveur s'ajuste exactement, la position du curseur restera sur la dernière ligne dans la mémoire tampon, ce qui signifie que la dernière ligne renvoyée à l'application sera verrouillée.
L'exportation de données avec ODBC vers le programme d'entrepôt de données du fichier ne prend pas en charge les types de données Sybase suivants :
Les types de données suivants ne sont pas pris en charge dans le débogueur SQL intégré au Centre de développement :
Le Centre de développement ne prend plus en charge la création des types structurés.
Le débogage de procédures mémorisées Java sur un serveur 64 bits n'est pas pris en charge par le Centre de développement. Le débogage de procédures mémorisées SQL est pris en charge sur les systèmes d'exploitation Windows 64 bits. Le développement de fonctions utilisateur OLE DB ou XML n'est pas pris en charge pour les serveurs 64 bits.
Vous ne pouvez pas utiliser le Centre de développement pour déboguer des procédures mémorisées Java s'exécutant sur l'une des distributions Linux (32 bits, 64 bits, Intel, zSeries ou iSeries).
Le Centre de développement ne prend pas en charge le débogage des procédures mémorisées comportant des guillemets (") dans le nom de procédure mémorisée, le schéma ou le nom spécifique.
Le Centre de développement ne peut pas compiler de routines Java s'il ne sait pas où sont installées les versions du kit du développeur. Leurs répertoires par défaut seront écrits dans votre fichier $HOME/.ibm/db2/dc/DB2DC.settings lors du premier démarrage du Centre de développement. Vous pouvez les copier dans votre fichier $USER.settings et les modifier via un éditeur Unicode, ou créer des liens symboliques vers les répertoires du kit du développeur dans les emplacements par défaut.
Le Centre de développement ne prend pas en charge l'exécution et le débogage simultanés de procédures mémorisées Java. Dans le Centre de développement, vous pouvez exécuter plusieurs procédures mémorisées Java simultanément ou déboguer une procédure mémorisée Java ; il n'est pas possible de d'exécuter une procédure mémorisée Java tout en en déboguant une autre. Par défaut, le mot clé de configuration du gestionnaire de base de données KEEPFENCED a la valeur KEEPFENCED=YES, ce qui est requis pour déboguer les procédures mémorisées SQL. Lorsque le mot clé KEEPFENCED a la valeur par défaut YES, le processus de routine reste actif et des conflits relatifs au port JVM se produiront. Les procédures mémorisées Java généreront une exception JVM et échoueront dans les cas suivants si le paramètre de configuration du gestionnaire de bases de données KEEPFENCED=YES par défaut est utilisé :
Pour remédier à ces limitations, vérifiez que le mot clé de configuration du gestionnaire de bases de données KEEPFENCED a la valeur KEEPFENCED=NO en exécutant la commande suivante :
db2 update dbm cfg using KEEPFENCED NO db2stop db2start
Si le mot clé KEEPFENCED a la valeur NO, le processus db2fmp s'arrête lorsqu'un appel de procédure mémorisée Java se termine et DB2 Universal Database démarre un nouveau processus db2fmp pour gérer le prochain appel de routine. Ceci garantit l'absence de JVM en mode débogage au début du débogage d'une procédure mémorisée Java.
Le paramètre KEEPFENCED=YES est requis pour créer des procédures mémorisées SQL pour le débogage et afin de déboguer ces dernières. Lorsque le paramètre KEEPFENCED=NO est défini, vous pouvez tout de même créer et exécuter des procédures mémorisées SQL, mais vous ne pouvez pas les déboguer.
La méthode DB2 Universal JDBC Driver DB2SystemMonitor.getServerTimeMicros() n'est actuellement pas prise en charge par DB2 Universal Database pour les serveurs Linux, UNIX et Windows. La méthode DB2SystemMonitor.getServerTimeMicros() renvoie la valeur 0 lors de la connexion à DB2 Universal Database pour les serveurs Linux, UNIX et Windows.
Vous devez disposer de la configuration suivante avant d'installer DB2 64 bits sur des systèmes Linux on iSeries et pSeries :
http://www.ibm.com/support/docview.wss?uid=swg24007906ou procédez comme suit :
La version 8.2.2 de DB2 Universal Database (UDB) (équivalente de la version 8.1, FixPack 9) pour Linux AMD64 ne prend pas en charge le pilote Universal JDBC Driver Type 2. La prise en charge est prévue dans un prochain FixPack. Dans la version 8.2.2, la prise en charge JDBC est assurée à l'aide de Universal JDBC Driver Type 4 et du pilote Legacy JDBC Type 2 (COM.ibm.db2.jdbc.app.DB2Driver).
Lorsque l'interpréteur PHP crée un curseur pour une application, celui-ci est créé par défaut en tant que curseur flottant défini par une clé. Dans certains cas, les résultats renvoyés peuvent être inattendus. Afin d'éviter ceci, spécifiez de façon explicite la clause "FOR READ ONLY" pour toutes les instructions SELECT utilisées pour mettre à jour les données. Parmi les autres possibilités, vous pouvez aussi définir les paramètres de configuration CLI "Patch2=6", "Patch2=42" ou "DisableKeysetCursor=1". Cependant, pour chacun d'eux d'autres conséquences sont possibles. Pour obtenir plus d'informations concernant ces mots clé de configuration, reportez-vous à la documentation Guide et Référence CLI.
Le mot clé ConnectNode ne concerne pas le Centre de contrôle. Le Centre de contrôle se connecte toujours au noeud catalogue auquel se réfère le paramètre SQL_CONN_CATALOG_NODE.
La fonction SQLColumns() ne prend pas en charge les données renvoyées par l'alias d'un alias. Lorsqu'elle est appelée sur un alias d'un alias, la fonction SQLColumns() renvoie un ensemble de résultats vide.
Certaines options de définition des accès peuvent ne pas fonctionner lors de la définition d'accès de modules CLI avec l'un des fichiers suivants : db2cli.lst, ddcsmvs.lst, ddcs400.lst, ddcsvm.lst ou ddcsvse.lst. Etant donné que les modules CLI sont utilisés par les applications CLI, ODBC, JDBC, OLE DB, .NET et ADO, toute modification apportée à ces modules affecte toutes les applications de ce type. Par conséquent, seul un sous-ensemble d'options de définition d'accès est pris en charge par défaut lors de la définition d'accès des modules CLI. Ces options sont : ACTION, COLLECTION, CLIPKG, OWNER et REPLVER. Toutes les autres options qui impactent les modules CLI sont ignorées.
Afin de créer des modules CLI avec des options de définition d'accès non prises en charges par défaut, spécifiez pour l'option COLLECTION un ID collection différent de l'ID par défaut, NULLID. Toute option de définition d'accès ainsi spécifiée est acceptée. Par exemple, pour créer des modules CLI avec l'option KEEPDYNAMIC YES, non prise en charge par défaut, lancez la commande suivante :
db2 bind @db2cli.lst collection newcolid keepdynamic yes
Pour que les applications CLI/ODBC puissent accéder aux modules CLI créés dans la nouvelle collection, attribuez le mot clé CurrentPackageSet CLI/ODBC du fichier d'initialisation db2cli.ini au nouvel ID collection.
Afin d'écraser les modules CLI existant sous un ID collection spécifique, effectuez l'une des actions suivantes :
L'utilitaire CLI LOAD ne prend pas en charge les marqueurs de paramètres si l'instruction SQL préparée pour l'insertion de données contient une clause SELECT.
Avant le FixPak 3 de la version 8.2 (équivalente de la version 8.1, Fixpak 10), l'utilitaire CLI LOAD ne permet pas d'indiquer les colonnes cibles dans l'instruction INSERT qui contient une clause VALUES.
Toutefois, à partir du FixPak 3 de la version 8.2 (équivalente de la version 8.1, Fixpak 10), l'utilitaire CLI LOAD permet d'indiquer les colonnes cibles dans une instruction INSERT ayant une clause VALUES. Par exemple, l'instruction suivante est désormais prise en charge par l'utilitaire CLI LOAD :
INSERT into tableA (col1, col2, col3) VALUES (?, ?, ?)
La création de la base de données du catalogue des outils sur une instance DB2 Universal Database (UDB) 64 bits sous Linux (AMD64) n'est pas prise en charge. Ne tentez pas de créer le catalogue des outils sous une instance 64 bits via l'une des méthodes suivantes :
La création de la base de données du catalogue d'outils sur une instance 32 bits sous Linux (AMD64) est prise en charge à partir de la version 8.1.4.
La création du catalogue d'outils n'est pas prise en charge pendant l'installation de DB2 Universal Database (UDB) sur des instances 64 bits situées sur des plateformes 64 bits hybrides. Les plateformes hybrides sont les suivantes :
Si vous souhaitez créer un catalogue d'outils sur une instance 64 bits, ceci est possible après après l'installation de DB2 UDB. Pour ce faire, vous utiliserez l'interpréteur de commandes, en employant la commande CREATE TOOLS CATALOG CLP, ou le Centre de contrôle. Cette opération nécessite également l'installation d'IBM Developer Kit pour Java (64 bits). Consultez la section DB2 Administration Server du DB2 Administration Guide pour obtenir davantage d'informations.
Il existe des limites de mémoire pour les produits suivants :
Lors de la planification de l'exécution d'un processus d'entrepôt à intervalles réguliers, vous devez déterminer la durée maximale nécessaire à la réalisation de toutes les étapes de production du processus, puis planifier les intervalles en fonction de cette information. Si l'exécution d'un processus excède l'intervalle prévu à cet effet, toutes les occurrences de ce processus planifiées ultérieurement ne seront ni exécutées ni replanifiées.
DB2 Universal Database (UDB) Enterprise Server Edition (ESE) version 8 (systèmes d'exploitation Windows et UNIX) et DB2 Connect Enterprise Edition (CEE) version 8 (systèmes d'exploitation Windows et UNIX) ne prennent plus en charge ce qui suit :
Lors du développement de plug-ins de sécurité à déployer dans des clients DB2, sur des systèmes d'exploitation Windows, ne déchargez pas les bibliothèques auxiliaires dans la fonction d'arrêt du plug-in. Cette restriction s'applique à tous les types de plug-in de sécurité client, dont le groupe, l'ID utilisateur et le mot de passe, le kerberos et les plug-ins GSS-API.
Cette restriction est due à un problème de déchargement des plug-ins de sécurité par DB2 Universal Database dans les clients DB2, sous Windows.
Dans le cadre d'une authentification au niveau du système d'exploitation AIX, DB2 Universal Database (UDB) tente de signaler la réussite d'une identification sous AIX si l'authentification a abouti. Dans les versions antérieures au FixPack 5 de la version 8, si DB2 UDB ne parvenait pas à signaler la réussite d'une identification, la connexion échouait même si l'utilisateur était bien authentifié. A compter du FixPack 5 de la version 8, la connexion est tout de même établie et l'erreur est consignée dans le fichier db2diag.log.
L'ID utilisateur en deux parties pour l'instruction CONNECT et la commande ATTACH, par exemple nom_domaine\nom_utilisateur, n'est pas pris en charge sous Windows ME.
Si vous utilisez l'assistant de chargement ou le bloc-notes d'importation pour configurer le chargement ou l'importation à partir d'un fichier d'entrée IXF contenant des caractères à double octet, la page Colonnes n'affiche pas correctement les noms de colonnes contenus dans le fichier.
| | |Les outils d'interface graphique livrés avec DB2 Universal |Database (UDB) sont des utilitaires graphiques basés sur Java. Voici |quelques exemples d'outils d'interface graphique DB2 UDB :
|Puisque les systèmes d'exploitation Linux sur AMD64 ne disposent pas |actuellement de Java SDK ou Runtime Environment 64 bits, vous devez |exécuter ces outils à partir d'une instance DB2 UDB 32 bits.
|Vous pouvez toujours utiliser ces outils pour gérer les bases de données |des instances 64 bits locales et distantes. Par exemple, vous devez |commencer par créer une instance 32 bits pour utiliser |le Centre de contrôle. Après la création d'une instance 32 bits, vous |devez cataloguer manuellement l'instance 64 bits locale que vous |souhaitez administrer.
|Vous trouverez plus d'informations sur DB2 pour Linux sur AMD64 à l'adresse |suivante :
|ftp://ftp.software.ibm.com/software/data/pubs/papers/linuxamd64.pdf
Pour pouvoir utiliser correctement les outils à interface graphique tels que le Centre de contrôle, vous avez besoin d'une résolution d'écran de 800 x 600 et d'une palette d'affichage de 32 couleurs au minimum.
Si des caractères de la norme de codage de caractères chinois GB18030 apparaissent dans la barre de titres d'une fenêtre, ils peuvent être affichés sous la forme de points d'interrogation ou de carrés.
Les tables utilisées par le gestionnaire de catalogues d'informations doivent se trouver dans une seule partition de base de données. Il existe plusieurs méthodes pour mettre les tables dans une seule partition. La procédure suivante est une approche efficace.
CREATE DATABASE PARTITION GROUP nom_groupe_partitions
ON DBPARTITIONNUM numéro_partitionCREATE REGULAR TABLESPACE nom_espace_table
IN DATABASE PARTITION GROUP nom_groupe_partitions
MANAGED BY SYSTEM USING ('nom_c')Query Patroller ne peut effectuer les actions qui suivent lorsque le paramètre de configuration de base de données DYN_QUERY_MGMT est désactivé :
Si vous essayez de libérer une requête de la mise en suspens, ou de transformer une requête d'avant-plan en requête d'arrière-plan lorsque DYN_QUERY_MGMT est paramétré en DISABLE, un message d'erreur sera affiché et l'état de la requête ne sera pas modifié. Si les requêtes en suspens sont planifiées pour s'exécuter et que DYN_QUERY_MGMT est désactivé au moment où elles s'exécutent, un message d'erreur apparaît dans le fichier qpdiag.log et les requêtes sont laissées en suspens.
A partir du FixPack 5, toutes les nouvelles tables de résultats sont créées dans le schéma DB2QPRT plutôt que dans le schéma de l'émetteur.
Le privilège DROPIN du schéma DB2QPRT est accordé aux opérateurs dont les profils ont été créés avant l'installation de FixPack 5 et comportent l'un des privilèges suivants :
Le privilège DROPIN du schéma DB2QPRT est accordé la première fois que Query Patroller crée une table de résultats dans ce schéma.
Les opérateurs disposant du privilège MONITORING avec droit d'édition ou le privilège HISTORICAL ANALYSIS avec droit d'édition après l'installation de FixPack 5 disposent également du privilège DROPIN sur le schéma DB2QPRT lors de la création ou mise à jour de leurs profils.
Le moniteur de santé ne peut pas exécuter d'actions pour l'indicateur de santé db2.db2_op_status si ce dernier est inactif. Cet état peut survenir, par exemple, lorsqu'une instance contrôlée par l'indicateur devient inactive en raison d'une demande d'arrêt explicite ou à un arrêt anormal. Pour que l'instance redémarre automatiquement après un arrêt anormal, vous devez configurer le moniteur pour que l'instance reste à l'état hautement disponible.
[ Début de page |Page précédente | Page suivante | Table des matières ]