Lorsque la commande export est lancée avec un format de fichier IXF et une clause SELECT *, les informations d'indexation sont collectées, le cas échéant.
Si les noms de colonnes indiqués dans l'index contiennent des caractères - ou +, les informations d'indexation ne seront pas collectées et vous recevrez un code SQL SQL27984W. L'exportation se termine et les données exportées ne seront pas affectées. Toutefois, les informations d'indexation ne seront pas sauvegardées dans le fichier IXF.
Si vous envisagez de recréer la table à l'aide de la commande import avec le paramètre CREATE, les index ne seront pas recréés. Vous pouvez utiliser l'utilitaire db2look pour créer les index séparément.
L'appel de l'API db2ReadLog à partir d'une application génère une erreur lorsque l'application se déconnecte de la base de données si une validation ou une instruction de récupération amont n'est pas effectuée avant la déconnexion :
Pour les applications SQL non-imbriquées, activez le mode validation automatique avant d'appeler l'API db2ReadLog.
Lancez une instruction COMMIT ou ROLLBACK après avoir appelé l'API db2ReadLog et avant de vous déconnecter de la base de données.
La commande db2gcf lance, arrête ou surveille une instance DB2 Universal Database (UDB), généralement à partir d'un script automatisé, comme dans un cluster à haute disponibilité (HA).
L'exécution de la commande système db2gcf avec le paramètre -k échoue dans DB2 UDB Workgroup Server.
La commande "db2gcf -k" fonctionne uniquement dans DB2 UDB Enterprise Server Edition, et non dans DB2 UDB Workgroup Server Edition.
Si un serveur DB2 Universal Database (UDB) 32 bits est installé sur un système AIX et qu'une application installée sur le même système comporte plusieurs connexions de base de données locales via l'encapsuleur DRDA, l'application peut alors renvoyer l'erreur suivante :
SQL1822N Un code d'erreur "-1224" inattendu a été renvoyé par la source de données "W3_SERVER2". Associated text and tokens are func="DriverConnect" msg="SQL1224N Un agent de base de données n'a pas pu être démarré pour satisfaire une demande ou a été interrompu à la suite d'un arrêt normal du système ou d'une commande FORCE. " SQLSTATE=560BD
Pour que cette erreur ne se produise pas, placez l'entrée suivante dans le fichier de configuration fédéré (répertoire_instance/cfg/db2dj.ini) :
EXTSHM=ON
Par ailleurs, vous pouvez cataloguer la base de données DB2 UDB locale comme étant sur un noeud TCP/IP. Par exemple :
CATALOG TCPIP NODE mon_noeud REMOTE mon_hôte SERVER 123; CATALOG DB mabd AT NODE mon_noeud; CREATE WRAPPER drda; CREATE SERVER mon serveur TYPE DB2/UDB VERSION 8 WRAPPER drda AUTHORIZATION "mon_id" PASSWORD "mon_mdp" OPTIONS(ADD DBNAME 'MYDB');
Si les touches d'accès rapide ne fonctionnent pas dans Microsoft Visual Studio .NET Framework 1.1, vous pouvez télécharger un correctif sur le site Web de Microsoft. Le correctif est disponible dans la Microsoft Knowledge Base, article Q836745.
AIX a modifié la page de codes associée à l'environnement local en chinois simplifié, Zh_CN, sous :
La page de codes a été modifiée de GBK (page de codes 1386) en GB18030 (page de codes 5488 ou 1392). Du fait que DB2 Universal Database (UDB) pour AIX prend en charge nativement la page de codes GBK et la page de codes GB18030 via Unicode, DB2 UDB définit par défaut la page de codes de l'environnement local Zh_CN en ISO 8859-1 (page de codes 819) et, dans certaines opérations, définira aussi Etats-Unis (US) comme pays par défaut de l'environnement local.
Pour contourner cette limitation, vous disposez de deux solutions :
Pour utiliser la première option, exécutez les commandes suivantes :
db2set DB2CODEPAGE=1386 db2set DB2TERRITORY=86 db2 terminate db2stop db2start
Si vous décidez d'utiliser la deuxième option, remplacez l'environnement local Zh_CN par ZH_CN ou zh_CN. La page de codes de l'environnement local ZH_CN est Unicode (UTF-8), alors que celle de l'environnement local zh_CN est eucCN (page de codes 1383).
Red Hat, version 8 et suivantes (dont Red Hat Enterprise Linux [RHEL] versions 2.1 et 3), a remplacé la page de codes par défaut du chinois simplifié GBK (page de codes 1386) par GB18030 (page de codes 5488 ou 1392).
Du fait que DB2 Universal Database (UDB) pour Linux prend en charge nativement la page de codes GBK et la page de codes GB18030 via Unicode, DB2 UDB définit par défaut sa page de codes en ISO 8859-1 (page de codes 819) et, dans certaines opérations, spécifiera aussi Etats-Unis (US) comme pays.
Pour contourner cette limitation, vous disposez de deux solutions :
Pour utiliser la première option, exécutez les commandes suivantes :
db2set DB2CODEPAGE=1386 db2set DB2TERRITORY=86 db2 terminate db2stop db2start
Pour utiliser la seconde option, exécutez l'une des commandes suivantes :
export LANG=zh_CN.gbk export LANG=zh_CN export LANG=zh_CN.utf8
où la page de codes associé à zh_CN est eucCN ou la page de codes 1383, et à zh_CN.utf8 est associée la page de codes 1208.
Des incompatibilités ont été détectées dans le cadre du support Unicode lorsque Merant Driver Manager accède au pilote ODBC DB2 sous UNIX. Ces incompatibilités peuvent entraîner Merant Driver Manager à utiliser Unicode, que l'application ait demandé ce format ou non. Cela peut poser des problèmes avec des composants tels que Data Warehouse Center, Information Catalog Manager et MQSI, qui nécessitent la prise en charge par Merant Driver Manager de sources de données non IBM. Vous pouvez utiliser une autre bibliothèque de pilotes ODBC DB2 sans activer le support Unicode jusqu'à ce qu'une solution définitive soit disponible.
Une bibliothèque de pilotes ODBC DB2 sans support Unicode activé est fournie avec DB2 Universal Database (UDB) version 8.1 pour AIX, HP-UX et l'environnement d'exploitation Solaris. Pour utiliser cette bibliothèque, vous devez en créer une copie, en lui affectant le nom de la bibliothèque de pilotes ODBC DB2 d'origine.
Pour utiliser la bibliothèque ODBC non Unicode sous AIX, HP-UX ou l'environnement d'exploitation Solaris, reportez-vous aux instructions ci-après. S'agissant d'un processus manuel, vous devez le réaliser à chaque mise à jour de votre produit, y compris après l'application de FixPacks successifs ou des niveaux de modification.
Pour créer la bibliothèque de remplacement sous AIX, procédez comme suit :
cp db2_36.o db2.o -r--r--r-- bin:bin for db2.o
Pour revenir à l'objet d'origine, suivez la même procédure en utilisant le fichier de sauvegarde au lieu du fichier db2_36.o.
Pour créer la bibliothèque de remplacement dans l'environnement d'exploitation Solaris, procédez comme suit :
cp libdb2_36.so.1 libdb2.so.1 -r-xr-xr-x bin:bin libdb2.so.1
Pour revenir à l'objet d'origine, suivez la même procédure en utilisant le fichier de sauvegarde au lieu du fichier libdb2_36.so.1.
Pour créer la bibliothèque de remplacement sous HP-UX PA-RISC, procédez comme suit :
cp libdb2_36.sl libdb2.sl -r-xr-xr-x bin:bin for libdb2.sl
Pour revenir à l'objet d'origine, suivez la même procédure en utilisant le fichier de sauvegarde au lieu du fichier libdb2_36.sl.
Pour créer la bibliothèque de remplacement sous HP-UX sous IA64, procédez comme suit :
cp libdb2_36.so libdb2.so -r-xr-xr-x bin:bin pour libdb2.so
Pour revenir à l'objet d'origine, suivez la même procédure en utilisant le fichier de sauvegarde au lieu du fichier libdb2_36.so.
Veuillez prendre contact avec le support IBM si vous avez besoin d'assistance dans le cadre de l'utilisation de DB2 UDB et de Merant Driver Manager sur d'autres systèmes d'exploitation UNIX.
L'APAR IY32512 NFS 5 AIX peut engendrer l'échec de la commande db2stop sur des systèmes dotés d'un grand nombre de partitions.
Sur un serveur recevant un très grand nombre de demandes de groupage des verrous de fichiers déjà verrouillés, il est possible que le démon de verrouillage ne réponde plus. Cela se produit lorsque toutes les unités d'exécution verrouillées disponibles sont allouées à des unités d'exécution attendant que des verrous deviennent disponibles, par conséquent il ne reste aucune unité d'exécution disponible pour réaliser la tâche lorsque la demande de déverrouillage est effectuée.
Lorsque cela se produit, les noeuds arrêtés doivent être redémarrés. Il existe une solution palliative DB2 Universal Database à cette situation, qui consiste à arrêter les noeuds un par un via l'option NODENUM de la commande db2stop.
Si l'option de précompilation SQLFLAG(STD) est activée, elle entraîne l'erreur suivante : Abend C6 occurred while running Precompile program DSNHPC (Un arrêt s'est produit pendant l'exécution du programme de précompilation DSNHPC)
Supprimez l'option de précompilation SQLFLAG (STD) lors de l'utilisation du Centre de développement pour créer des procédures mémorisées SQL à exécuter sous DB2 Universal Database pour z/OS, version 8.
Lorsque le membre du DDF connecté au groupe de partage de données sur OS390 est arrêté, DB2 Connect n'achemine pas les connexions vers un autre membre d'un DDF (Distributed Data Facility). Lorsque Sysplex est activé, DB2 Connect achemine les connexions vers un autre membre du DDF en fonction de la liste de serveurs.
La version 8 de DB2 Connect Sysplex a été conçue pour le regroupement d'agents. La liste de serveurs Sysplex est libérée si elle ne contient pas d'agent ni de connexion à une base de données. Par conséquent, un agent au moins doit être conservé afin de maintenir la liste de serveurs Sysplex.
Activez le regroupement de connexions en exécutant les commandes suivantes :
db2 update dbm cfg using num_poolagents nombre db2stop db2start
où nombre est le nombre maximal d'agents autorisés à être regroupés dans l'instance DB2. Le pool de connexion est activé lorsque le paramètre nombre est supérieur à 0.
Définissez le paramètre num_poolagents sur -1, qui constitue la moitié de la valeur attribuée dans le paramètre de configuration maxagents
Bien qu'il soit présenté dans le manuel DB2 Connect User's Guide, l'assistant personnalisé de DB2 Connect n'est plus pris en charge dans la version 8.2.
L'incident survient également lors de l'installation du FixPack 7 de DB2 UDB version 8.1 si vous avez mis à jour manuellement le paramètre de configuration jdk_path du serveur d'administration DB2 pour qu'il pointe vers HP-UX SDK 1.4, ou si vous avez supprimé, puis recréé le serveur d'administration DB2 (DAS). L'incident survient parce que, dans un de ces cas, le paramètre de configuration jdk_path pointe vers HP-UX SDK 1.4.
Une instance 32 bits de DB2 UDB version 8.2 a besoin de HP-UX SDK 1.3 pour fonctionner.
db2 update admin config using JDK_PATH /opt/java1.3
db2admin stop db2admin start
Si vous rencontrez des problèmes lors de l'affichage des caractères Indic quand vous utilisez les outils d'interface graphique de DB2, il se peut que vous n'ayez pas les bonnes polices sur votre poste.
DB2 Universal Database (UDB) fournit les polices Indic proportionnelles IBM TrueType et OpenType suivantes. Ces polices figurent dans le répertoire polices sur l'un des CD suivants :
Ces polices doivent être utilisées avec DB2 UDB uniquement. Vous ne pouvez pas entreprendre de vente ou de distribution générale de ces polices :
Famille | Poids | Nom du fichier de police |
---|---|---|
Devanagari MT pour IBM | Moyen | devamt.ttf |
Devanagari MT pour IBM | Gras | devamtb.ttf |
Tamil | Moyen | TamilMT.ttf |
Tamil | Gras | TamilMTB.ttf |
Telugu | Moyen | TeluguMT.ttf |
Telugu | Gras | TeleguMTB.ttf |
Vous trouverez des instructions détaillées sur l'installation des polices et la façon de modifier le fichier font.properties dans la section Internationalisation de la documentation du kit de développement IBM pour Java.
De plus, les produits Microsoft suivants sont livrés avec des polices Indic utilisables avec les outils d'interface graphique DB2 :
Hormis l'assistant d'installation de DB2, les outils d'interface graphique ne fonctionnent pas sur les serveurs zSeries exécutant le système d'exploitation Linux. Cette restriction porte sur tous les éléments pouvant être normalement lancés à partir du tableau de bord d'installation, comme le Tour d'horizon.
Si vous voulez utiliser les outils d'interface graphique avec l'un de ces systèmes, installez les outils d'administration sur un système client ayant une configuration système différente et utilisez ce client pour vous connecter au serveur zSeries.
Pour obtenir des résultats de recherche plus précis dans le Centre de documentation DB2, vous devez placer les termes recherchés contenant des nombres entre guillemets.
Par exemple, si vous recherchez le terme suivant, vous n'obtenez aucun résultat :
1.4.1
Mais si vous placez ce terme entre guillemets, les résultats souhaités s'affichent :
"1.4.1"
La recherche du terme ci-après renvoie des rubriques supplémentaires :
DB20000I
Mais la recherche suivante fonctionne correctement :
"DB20000I"
Si un fichier journal du Centre de gestion des catalogues d'informations n'est pas généré lors de l'importation des fichiers de langage de marques vers le Centre de gestion des catalogues d'informations, effectuez l'une des étapes de résolution d'incident suivantes :
db2javit -j:com.ibm.db2.common.icm.tag.IcmImport -w: -i: -o:"-Xmx128m -Xms32m" -g:"d:\temp\myimport.trc" ...
Si la définition des accès aux modules de Query Patroller n'est pas effectuée après l'application d'un FixPack, le message d'erreur ci-après peut s'afficher lorsqu'un utilisateur sans droit DBADM ni privilège Query Patroller adéquat utilise le Centre Query Patroller ou la ligne de commande Query Patroller :
SQL0001N - La définition des accès (BIND) ou la précompilation n'a pas abouti.
Si vous utilisez le Centre Query Patroller, l'erreur SQL0001N est consignée dans le fichier qpdiag.log. Si vous utilisez la ligne de commande Query Patroller, le message SQL0001N est renvoyé à la console
Le code de définition d'accès automatique permet de lancer la définition d'accès automatique. Cependant cette dernière échoue lorsque l'utilisateur connecté ne dispose pas des privilèges nécessaires pour exécuter toutes les instructions dans les modules Query Patroller. Le fait que des dossiers manquent dans le Centre Query Patroller est l'un des symptômes de ce problème.
Pour éviter ce problème, la définition des accès aux modules qpserver.lst doit être effectuée manuellement par un utilisateur doté du droit DBADM ou des privilèges nécessaires après l'application d'un FixPack.
Les requêtes soumises dans Query Patroller peuvent recevoir un code SQL -29007 lorsqu'aucun port n'est disponible sous Windows XP ou Windows 2003. La probabilité de cette erreur augmente au fur et à mesure du nombre croissant de clients qui accèdent à Query Patroller.
Les variables de registre Windows à définir sont les suivantes :
MaxUserPort=65534 TcpTimedWaitDelay=30
puis redémarrez votre système pour que les modifications prennent effet.
Vous trouverez des informations détaillées concernant la configuration des variables de registre Windows sur le site Web Aide et support de Microsoft à l'adresse suivante : http://support.microsoft.com/.
Des problèmes de droit d'accès aux fichiers peuvent survenir si vous utilisez DB2 Universal Database (UDB) sous Windows sans être l'administrateur du système Windows. Si vous recevez un message d'erreur SQL1035N, SQL1652N ou SQL5005C, les causes possibles d'erreur ainsi que les solutions palliatives sont présentées ci-après :
Attribuez aux utilisateurs, au minimum, le droit de MODIFICATION du répertoire rép_instance au niveau du système de fichiers.
Certains programmes exemples de l'Extension XML ont le même nom que d'autres programmes installés. Or l'appel par erreur d'un autre programme du même nom qu'un programme exemple de l'Extension XML peut endommager vos fichiers XML. La liste suivante recense les anciens programmes exemples de l'Extension XML, ainsi que les noms de nouveaux programmes de remplacement moins à même de provoquer des incompatibilités. Veillez bien à utiliser les noms des nouveaux programmes exemples et non les anciens afin de ne pas endommager vos fichiers XML.
Ancien programme (Ne pas utiliser) | Nouveau programme (A utiliser) |
---|---|
insertx.exe | dxxisrt.exe |
retrieve.exe | dxxretr.exe |
retrieve2.exe | dxxretr2.exe |
retrievec.exe | dxxretrc.exe |
shred.exe | dxxshrd.exe |
tests2x.exe | dxxgenx.exe |
tests2xb.exe | dxxgenxb.exe |
tests2xc.exe | dxxgenxc.exe |
Ancien programme (Ne pas utiliser) | Nouveau programme (A utiliser) |
---|---|
insertx | dxxisrt |
retrieve | dxxretr |
retrieve2 | dxxretr2 |
retrievec | dxxretrc |
shred | dxxshrd |
tests2x | dxxgenx |
tests2xb | dxxgenxb |
tests2xc | dxxgenxc |
Le code source (fichiers .sqx) pour les exécutables listés précédemment se trouve dans le répertoire samples\db2xml\c de votre installation. Les fichiers source sont toujours libellés avec leurs anciens noms. Si vous effectuez des changements dans le code source, copiez les exécutables nouvellement compilés (avec les anciens noms) dans le répertoire sqllib\bin.
Sous Windows, vous devez effectuer une copie supplémentaire, la renommer à l'aide du nouveau nom indiqué ci-dessus et la copier dans le répertoire bin. Les deux copies remplacent les fichiers existants dans le répertoire bin. Par exemple, après la compilation de la nouvelle version de shred.exe, vous devez effectuer deux copies et remplacer les fichiers dans le répertoire bin : un libellé shred.exe et l'autre renommé dxxshrd.exe.
Sur les plateformes Linux et UNIX, il vous suffit de remplacer le fichier portant l'ancien nom par la version nouvellement compilée. Si vous créez des fichiers exécutables à partir de ces modèles, vous devez copier les nouveaux fichiers du répertoire \SQLLIB\samples\db2xml\c\ vers le répertoire \SQLLIB\bin\ puis en faire une copie supplémentaire et les renommer comme indiqué dans le tableau précédent.
Vous pouvez désormais décomposer des documents contenant des attributs ou des noms d'éléments non uniques qui mappent vers des colonnes différentes (de tables identiques ou différentes) sans recevoir l'erreur DXXQ045E. L'exemple suivant est celui d'un document XML comportant des attributs et des noms d'éléments non uniques :
<Order ID="0001-6789"> <!-- Note: attribute name ID is non-unique --> <Customer ID = "1111"> <Name>John Smith</Name> </Customer> <!-- Note: element name Name is non_unique --> <Salesperson ID = "1234"> <Name>Jane Doe</Name> </Salesperson> <OrderDetail> <ItemNo>xxxx-xxxx</ItemNo> <Quantity>2</Quantity> <UnitPrice>12.50</UnitPrice> </OrderDetail> <OrderDetail> <ItemNo>yyyy-yyyy</ItemNo> <Quantity>4</Quantity> <UnitPrice>24.99</UnitPrice> </OrderDetail> </Order>
Le fichier DAD d'accompagnement qui mappe les éléments et attributs en double vers différentes colonnes, ressemble à ce qui suit :
<element_node name="Order"> <RDB_node> <table name="order_tab" key="order_id"/> <table name="detail_tab"/> <condition> order_tab.order_id=detail_tab.order_id </condition> </RDB_node> <!--ID attribut dupliqué ci-dessous, mais mappé vers une colonne différente --> <attribute_node name="ID"> <RDB_node> <table name="order_tab" /> <column name="order_id" type="char(9)"/> </RDB_node> </attribute_node> <element_node name="Customer"> <!--ID attribut dupliqué ci-dessus, mais mappé vers une colonne différente --> <attribute_node name="ID"> <RDB_node> <table name="order_tab" /> <column name="cust_id" type="integer"/> </RDB_node> </attribute_node> <!--nom d'élément dupliqué ci-dessous, mais mappé vers une colonne différente --> <element_node name="Name"> <text_node> <RDB_node> <table name="order_tab" /> <column name="cust_name" type="char(20)" /> </RDB_node> </text_node> </element_node> </element_node> <element_node name="Salesperson"> <!--ID attribut dupliqué ci-dessus, mais mappé vers une colonne différente --> <attribute_node name="ID"> <RDB_node> <table name="order_tab" /> <column name="salesp_id" type="integer"/> </RDB_node> </attribute_node> <!--nom d'élément dupliqué ci-dessus, mais mappé vers une colonne différente --> <element_node name="Name"> <text_node> <RDB_node> <table name="order_tab" /> <column name="salesp_name" type="char(20)" /> </RDB_node> </text_node> </element_node> </element_node> <element_node name="OrderDetail" multi_occurrence="YES"> <element_node name="ItemNo"> <text_node> <RDB_node> <table name="detail_tab" /> <column name="itemno" type="char(9)"/> </RDB_node> </text_node> </element_node> <element_node name="Quantity"> <text_node> <RDB_node> <table name="detail_tab" /> <column name="quantity" type="integer"/> </RDB_node> </text_node> </element_node> <element_node name="UnitPrice"> <text_node> <RDB_node>detail_tab" /> <table name="detail_tab" /> <column name="unit_price" type="decimal(7,2)"/> </RDB_node> </text_node> </element_node> </element_node> </element_node>
Le contenu des tables ressemble à l'exemple qui suit, une fois le document ci-dessus décomposé :
ORDER _TAB: ORDER_ID CUST_ID CUST_NAME SALESP_ID SALESP_NAME 0001-6789 1111 John Smith 1234 Jane Doe DETAIL_TAB: ORDER_ID ITEMNO QUANTITY UNIT_PRICE 0001-6789 xxxx-xxxx 2 12.50 0001-6789 yyyy-yyyy 4 24.99
Lors d'une connexion à un système OS/390 via SNA, la couche VTAM hôte émet automatiquement une validation à l'établissement de chaque nouvelle connexion. Avec cette validation automatique, l'unité d'exécution côté hôte passe immédiatement à l'état inactif.
En revanche, lorsque la connexion à un système OS/390 s'effectue via TCP/IP, il n'existe pas de validation automatique. C'est l'application elle-même qui doit émettre une validation explicite une fois la connexion établie pour que l'unité d'exécution côté hôte passe à l'état inactif. Sans cette validation explicite, l'unité d'exécution risque de basculer à l'état de veille passé un certain délai.
La solution proposée consiste à réécrire l'application de sorte qu'elle exécute une validation explicite au cas où la connexion, une fois établie, passe à l'état de veille.
[ Début de page |Page précédente | Page suivante | Table des matières ]