Par défaut, la fonction de redirection automatique du client effectue de |nouvelles tentatives de connexion à une base de données plusieurs fois pendant 10 minutes. Toutefois, |vous pouvez configurer un comportement de relance précis à l'aide de l'une ou |des deux variables de registre suivantes :
|Si DB2_MAX_CLIENT_CONNRETRIES est défini, mais que |DB2_CONNRETRIES_INTERVAL ne l'est pas, le paramètre DB2_CONNRETRIES_INTERVAL |est défini sur 30 par défaut.
|Si DB2_MAX_CLIENT_CONNRETRIES n'est pas défini alors que DB2_CONNRETRIES_INTERVAL |l'est, le paramètre DB2_MAX_CLIENT_CONNRETRIES est défini sur 10 par défaut.
|Si aucun des paramètres DB2_MAX_CLIENT_CONNRETRIES et |DB2_CONNRETRIES_INTERVAL n'est défini, la fonction de redirection |automatique du client reprend son comportement par défaut décrit précédemment.
|Remarque :
|Les utilisateurs de connectivité de type 4 avec le pilote JDBC DB2 |Universal doivent utiliser les deux propriétés de source de données suivantes |afin de configurer la redirection automatique du client :
|La variable de registre DB2TIMEOUT n'est plus prise en charge. Ce |paramètre permettait de contrôler le délai d'inactivité pour les |clients Windows 3.x et Macintosh au cours des longues requêtes SQL. Il a |été désactivé par défaut.
| | |.Lors de la création de conteneurs d'espace table, DB2 UDB crée tous |les niveaux de répertoire qui n'existent pas.
|Par exemple, si un conteneur est indiqué comme |/project/user_data/container1 et que le répertoire |/project n'existe pas, DB2 UDB crée les répertoires |/project et /project/user_data.
|A compter de la version 8.2 de DB2 UDB, FixPak 4, tous |les répertoires sont créés par DB2 UDB à l'aide de la fonction PERMISSION 700. Cela |signifie que seul le propriétaire dispose des droits d'accès en lecture, |en écriture et en exécution.
|Lors de la création d'instances multiples, le scénario suivant s'applique :
|Puisque DB2 UDB a créé des niveaux de répertoire |/project/user_data avec PERMISSION 700 à la première |requête, l'utilisateur 2 ne dispose pas des droits d'accès à ces niveaux de |répertoire et ne peut pas créer de container2 dans ces répertoires. | Dans ce cas, l'opération CREATE TABLESPACE échoue.
|Deux méthodes permettent de résoudre ce conflit :
|Le format des noms pour les conteneurs a été modifié de telle sorte que l'ID espace table et l'ID conteneur ont également été modifiés. Le nouveau format est le suivant :
<chemin de stockage>/<instance>/NOEUD#### /T####### /C#######.<EXT>
où :
Avec la version 8.2.2 de DB2 Universal Database (équivalent de la version 8.1, FixPak 9), les colonnes générées peuvent désormais être utilisées dans des index à entrées uniques.
Les colonnes générées ne peuvent pas être utilisées dans les contraintes, les contraintes référentielles, les clés primaires et les tables temporaires globales. Une table créée avec LIKE et des vues matérialisées n'hérite pas des propriétés de colonne générée.
Lorsque vous avez défini DB2WORKLOAD=SAP, l'espace table utilisateur SYSTOOLSPACE et l'espace table utilisateur temporaire SYSTOOLSTEMPSPACE ne sont pas créés automatiquement. Ces espaces table sont utilisés pour les tables créées automatiquement par les assistants, utilitaires ou fonctions suivants :
Sans les espaces table SYSTOOLSPACE et SYSTOOLSTEMPSPACE, vous ne pouvez pas utiliser ces assistants, utilitaires ou fonctions.
Pour pouvoir utiliser les assistants, utilitaires ou fonctions, effectuez l'une des opérations suivantes :
CREATE REGULAR TABLESPACE SYSTOOLSPACE
IN IBMCATGROUP
MANAGED BY SYSTEM
USING ('SYSTOOLSPACE')Après avoir effectué au moins l'une de ces opérations, créez un espace table utilisateur temporaire (sur le noeud catalogue uniquement, si vous utilisez DPF). Par exemple :
CREATE USER TEMPORARY TABLESPACE SYSTOOLSTMPSPACE
IN IBMCATGROUP
MANAGED BY SYSTEM
USING ('SYSTOOLSTMPSPACE')
Dès que l'espace table SYSTOOLSPACE et l'espace table temporaire SYSTOOLSTEMPSPACE sont créés, vous pouvez utiliser les assistants, utilitaires ou fonctions mentionnés ci-avant.
Le type d'authentification DATA_ENCRYPT_CMP permet aux clients d'une édition antérieure qui ne prend pas en charge le chiffrement de données de se connecter à un serveur à l'aide de l'authentification SERVER_ENCRYPT au lieu de DATA_ENCRYPT. Cette authentification n'est pas possible dans les cas ci-dessous :
Dans ce cas, le client ne peut pas se connecter au serveur. Pour permettre la connexion, mettez votre client à jour en fonction de la version 8, ou mettez la passerelle à niveau en fonction de Version 8 FixPack 6 ou antérieur.
Les entrées-sorties en accès direct (DIO) améliorent les performances de la mémoire car celle-ci ignore la mise en cache au niveau du système de fichiers. Ceci a pour effet de réduire la charge de l'UC et de libérer de la mémoire pour l'instance de la base de données.
Les entrées-sorties concurrentes (CIO) présentent les mêmes avantages que les DIO et allègent la sérialisation des accès en écriture.
DB2 Universal Database (UDB) prend en charge les DIO et les CIO sous AIX ; et les DIO sous HP-UX, dans l'environnement d'exploitation Solaris, sous Linux et Windows.
Les mots clés NO FILE SYSTEM CACHING et FILE SYSTEM CACHING font partie des instructions SQL CREATE et ALTER TABLESPACE pour vous permettre d'indiquer si les DIO ou les CIOdoivent être utilisées sur chaque espace table. Lorsque NO FILE SYSTEM CACHING est actif, DB2 UDB tente d'utiliser les E-S concurrentes chaque fois que cela est possible. Dans les cas où les CIO ne sont pas prises en charge (par exemple, si JFS est utilisé), le mode DIO est utilisé à la place.
Pour plus d'informations, voir l'article «Improve database performance on file system containers in IBM DB2 UDB Stinger using Concurrent I/O on AIX» à l'adresse suivante :
http://www.ibm.com/developerworks/db2/library/techarticle/dm-0408lee/
Les informations suivantes sont extraites du guide Administration Guide: Implementation, Annexe B «Using automatic client rerouting»:
Dans DB2 Universal Database pour Linux, UNIX, et Windows, la fonction de redirection automatique du client permet aux applications client de récupérer à la suite d'une perte de communication avec le serveur (en rétablissant automatiquement la connexion base de données-serveur-client) et de continuer à fonctionner après une interruption minimale.
En cas d'échec de la connexion client/serveur, les demandes de connexion du client sont transmises à un ensemble de systèmes par un distributeur ou un répartiteur comme WebSphere EdgeServer
Vous pouvez utiliser la technologie de distribution (Distributor Technology) dans un environnement semblable au suivant :
Client --> Distributor Technology --> (DB2 Connect Server 1 ou DB2 Connect Server 2) --> DB2 z/OS
où :
Le client est catalogué à l'aide de DThostname afin d'utiliser la technologie de distribution pour accéder à l'un des serveurs DB2 Connect. La technologie en question opte pour l'utilisation de GWYhostname1 ou de GWYhostname2. Une fois ce choix arrêté, le client dispose d'une connexion socket directe vers l'une de ces deux passerelles DB2 Connect. Lorsque la connectivité par socket est établie vers le serveur DB2 Connect, une connectivité typique client - serveur DB2 Connect - DB2 z/OS est instaurée.
Supposons, par exemple, que le distributeur choisisse GWYhostname2. On obtient l'environnement suivant :
Client --> Serveur 2 DB2 Connect --> DB2 z/OS
En cas d'échec de la communication, le distributeur n'essaye pas de la rétablir. Pour activer la fonction de redirection automatique du client d'une base de données dans ce type d'environnement, le serveur de remplacement de la base de données (ou des BD) associée de DB2 Connect Server (DB2 Connect Server 1 ou DB2 Connect Server 2) doit être configuré en tant que distributeur (DThostname). Ainsi, en cas de blocage de DB2 Connect Server 1, la fonction de redirection automatique du client est déclenchée et de nouvelles tentatives de connexion ont lieu entre le client et le distributeur (serveur 1 ou serveur 2). Cette option permet de combiner et de gérer les fonctions du distributeur avec la fonction de redirection automatique du client de DB2. L'attribution au serveur de remplacement d'un autre nom d'hôte que celui du distributeur ne désactive pas la fonction de redirection automatique du client, mais le client établira des connexions directes avec le serveur de remplacement et n'utilisera pas la technologie de distribution, ce qui dépouille le distributeur de toute utilité.
La fonction de redirection automatique du client intercepte les codes sql suivants :
Tenez compte des éléments ci-dessous impliquant une connectivité de serveur de remplacement avec le serveur DB2 Connect :
Les applications qui s'exécutent dans le cadre d'un compte système local (LSA) sont prises en charge sur toutes les plateformes Windows, à l'exception de Windows ME.
L'instruction CONNECT et la commande ATTACH prennent en charge les ID utilisateur en deux parties. Le qualificatif de l'ID utilisateur compatible SAM est le nom de style NetBIOS dont la longueur maximale est de 15 caractères. Cette fonction n'est pas prise en charge sous Windows ME.
Vous pouvez remplacer le nom principal du serveur Kerberos utilisé par le serveur DB2 Universal Database (UDB) sous les systèmes d'exploitation UNIX et Linux. Pour ce faire, définissez la variable d'environnement DB2_KRB5_PRINCIPAL avec le nom principal souhaité entièrement qualifié pour le serveur. L'instance doit être redémarrée, le nom principal du serveur étant reconnu par DB2 UDB uniquement après que la commande db2start a été exécutée.
La documentation fait état des composants prérequis du support Linux Kerberos de manière imprécise. Le plug-in de sécurité Kerberos DB2 fourni est pris en charge avec Red Hat Enterprise Linux Advanced Server 3 avec le client IBM Network Authentication Service (NAS) 1.4.
Pour les connexions à zSeries et iSeries, la base de données doit être cataloguée avec le paramètre AUTHENTICATION KERBEROS et le nom de paramètre TARGET PRINCIPAL doit être précisé de manière explicite.
Ni zSeries ni iSeries ne prennent en charge l'authentification mutuelle.
En outre, dans tous les cas, le journal d'administration de DB2 ou le fichier db2diag.log indique que la connexion n'a pas abouti ou qu'elle est refusée.
Impossible de contacter l'autorité de sécurité localeL'erreur est due au fait que Windows localise l'utilisateur local en premier. La solution est de qualifier intégralement l'utilisateur dans la chaîne de connexion. Par exemple :
nom@DOMAINE.IBM.COM
Pour déterminer si les comptes Windows sont configurés pour utiliser le chiffrement DES, voir Propriétés du compte dans Répertoire actif. Il peut s'avérer nécessaire de redémarrer le système si les propriétés du compte ont été modifiées.
hôte/<nom_hôte_serveur>@<nom_domaine_serveur>Par exemple :
hôte/monhôte.domain.ibm.com@DOMAIN.IBM.COMSinon, vous devez démarrer le service DB2 sous un compte de domaines valide.