Option de stockage des données pureQuery

Lorsque vous exécutez des applications activées avec l'optimisation client pureQuery, vous pouvez spécifier l'emplacement où pureQuery Runtime récupère les informations de configuration d'exécution, ainsi que les informations pureQueryXML. Lorsque vous capturez les données SQL, vous pouvez spécifier l'endroit où les données sont stockées.
Vous créez généralement les fichiers suivants qui sont utilisés au cours du processus d'activation de l'optimisation client pureQuery et pendant l'exécution :
  • Fichier de propriétés de configurations pureQuery Runtime
  • Fichier pureQueryXML contenant les données SQL utilisées lors de l'exécution
  • Fichiers de propriétés de configuration et fichier de propriétés de liaison
  • Fichiers pureQueryXML contenant les données SQL capturées
Vous devrez décider de l'emplacement où stocker les propriétés et les données pureQuery. Vous pouvez utiliser l'emplacement pureQuery Runtime par défaut ou spécifier un emplacement.
Système de fichiers local (comportement par défaut)
Par défaut, pureQuery Runtime recherche les propriétés et les données sur le système de fichiers local. Sous ce modèle, les propriétés pureQuery Runtime pureQueryXml et outputPureQueryXml spécifient les fichiers contenant les données pureQuery. Ces deux propriétés peuvent être spécifiées à différents endroits, notamment dans des fichiers nommés pdq.properties et pdq.appwide.properties.
Spécifiez un système de fichiers ou un référentiel dans une base de données
Vous pouvez cependant spécifier que les données pureQuery et les propriétés d'exécution se trouvent dans le référentiel d'une base de données, dans un système de fichier ou dans une combinaison des deux. Utilisez les propriétés pureQuery Runtime finalRepositoryProperties et outputXmlRepository pour spécifier l'emplacement.

Lorsque vous utilisez une application activée avec l'optimisation client pureQuery et que vous stockez les données pureQuery dans un référentiel, vous utilisez l'utilitaire pureQuery ManageRepository pour accéder et stocker les données pureQuery dans le référentiel. L'utilitaire ManageRepository peut être utilisé pour créer un référentiel et gérer et entretenir le référentiel.

Le stockage des données et des propriétés pureQuery dans un référentiel présente des avantages, mais vous devez prévoir en conséquence pour créer et entretenir le référentiel.

Avantages de l'utilisation d'un référentiel

L'utilisation d'un référentiel dans une base de données comme magasin central pour les données pureQuery présente différents avantages :
  • Les données pureQuery peuvent être consultées ou mises à jour sans interruption des applications en cours.
  • Un référentiel géré de manière centrale permet d'utiliser une seule copie des fichiers de propriétés pureQuery et des fichiers XML par les applications déployées sur plusieurs serveurs d'application.
  • Une application en cours d'exécution peut être configurée pour rechercher périodiquement les mises à jour des fichiers de propriétés pureQuery et des fichiers XML et commencer automatiquement à utiliser les nouvelles données.
  • L'autorisation d'accès et de mise à jour des données pureQuery peut être appliquée par la base de données.
  • Un administrateur peut examiner plus facilement le fichier pureQueryXML pour inspecter les instructions SQL pour une application et voir les informations d'emplacement du code source pour toute instruction SQL présentant un problème.

Considérations relatives à la configuration du référentiel

Lorsque vous utilisez une base de données pour stocker des artefacts pureQuery, vous disposez d'une certaine flexibilité en termes de configuration. Les principaux points de décision sont les suivants :
  • Où résidera (résideront) la ou les bases de données contenant les données pureQuery ?
  • Comment une application doit-elle réagir quand elle ne peut pas accéder au référentiel au cours de l'initialisation ?
  • Une application doit-elle utiliser la fonctionnalité d'actualisation automatique ? Dans ce cas, quel est l'intervalle recommandé pour interroger la base de données DBMQ du référentiel à la recherche des mises à jour ?
Déterminez l'emplacement de la base de données du référentiel
Les deux types de données sont les données d'entrée et les données de sortie :
  • Données d'exécution et de configuration pureQuery Runtime (entrée)
  • Données SQL capturées pureQuery (sortie)
Il est possible de configurer l'environnement d'exécution de l'application pour l'utilisation de différents emplacements pour les données d'entrée et de sortie. Vous pouvez localiser chaque type de données dans :
  • La base de données où l'application procède aux transactions (la base de données de transaction)
  • Une base de données qui s'exécute au même emplacement que le serveur d'applications
  • Une base de données distante, séparée de l'application ou du serveur de base de données de transaction
Recommandation par défaut :
Créez un seul référentiel dans la base de données de transaction pour les données d'entrée et de sortie. Cela présente deux avantages :
Simplicité
Cette approche offre une grande simplicité car elle évite la nécessité de créer et d'entretenir les données dans une base de données distincte.
Disponibilité
Les applications peuvent être configurées pour échouer si le référentiel de base de données pureQuery n'est pas disponible durant l'initialisation. Dans ce type de cas, l'utilisation de la base de données de transaction tend à augmenter la disponibilité de l'application car la base de données de transaction bénéficie normalement d'une excellente disponibilité et d'autres caractéristiques de qualité de service. L'utilisation d'un serveur distinct présentant des caractéristiques similaires augmente les points de défaillance possibles.
Autres considérations relatives à l'emplacement de la base de données :
  • Si vous êtes inquiet à l'idée d'augmenter l'activité de la base de données de transaction ou du réseau en raison de l'actualisation automatique de pureQuery ou de l'écriture des enregistrements de capture de sortie, envisagez de placer la base de données du référentiel sur le serveur d'application ou sur un autre serveur.
  • Votre site peut également avoir des critères relatifs aux types de données autorisés dans la base de données de transaction. Ces exigences peuvent aussi vous inciter à choisir un serveur distinct pour la base de données.
  • Vous pouvez envisager un compromis : placer le référentiel de données d'entrée sur la base de données de transaction et créer un référentiel sur un serveur distinct où stocker les enregistrements de capture de sortie.
  • Les configurations qui impliquent une combinaison de données d'entrée dans un référentiel de base de données et de données de sortie sur un système de fichiers local ou distant sont également admises.
Comportement à adopter lorsque le référentiel est indisponible
Il est important d'envisager à l'avance la manière dont vous souhaitez que l'application se comporte au cas où les données pureQuery seraient indisponibles au démarrage de l'application. La propriété de temps de pureQuery Runtime repositoryRequired contrôle ce comportement.

Le paramètre par défaut no incite pureQuery Runtime à revenir au comportement par défaut pour toutes les propriétés d'optimisation client pureQuery. Cela signifie que l'application s'exécutera à l'aide du SQL dynamique. Si cette rétromigration est préférée à l'échec de l'application au démarrage, conservez le comportement par défaut.

Toutefois, dans certains cas, par exemple lors de l'exécution statique des instructions SQL, il peut être problématique, voire impossible, d'exécuter l'application avec les comportements par défaut. Par exemple, l'autorisation de préparer et d'exécuter les instructions SQL en mode dynamique peut ne pas être en place pour tous les utilisateurs de l'application. Si de tels cas se présentent, vous devez spécifier la propriété pureQuery Runtime repositoryRequired avec la valeur atStartUp.

De même, si la capture des données de sortie est critique lorsque l'application est en cours d'exécution, vous pouvez demander à pureQuery Runtime de vérifier la disponibilité de la base de données de sortie lorsque l'application démarre en spécifiant la propriété repositoryRequired avec la valeur forOutput. Dans la plupart des cas, ce paramètre n'est pas nécessaire. Si la base de données de sortie devient disponible durant l'exécution de l'application, pureQuery détecte le changement et commence à écrire la sortie.

Si vous souhaitez vous assurer que les bases de données pureQueryXML d'entrée et de sortie sont disponibles, vous pouvez spécifier la propriété repositoryRequired avec la valeur atStartupAndForOutput. Ce paramètre peut aussi être une option utile au cours d'une configuration initiale, pour s'assurer que tout est correctement configuré et éviter d'exécuter l'application pendant une période prolongée avant de découvrir que quelque chose n'a pas été configuré correctement.

Actualisation automatique des informations pureQuery
Par défaut, pureQuery Runtime vérifie la présence de mises à jour des informations pureQuery pour une version du groupe d'exécution après l'activation de la version du groupe d'exécution. Si la version du groupe d'exécution est activée et que les données pureQuery de la version du groupe d'exécution sont à jour, pureQuery Runtime actualise les données.

Les applications qui reçoivent des mises à jour de maintenance fréquentes et les infrastructures qui continuent à générer les instructions SQL non capturées au préalable sont de bonnes candidates pour l'actualisation automatique. L'intervalle spécifié dépendra de la rapidité à laquelle vous souhaitez que les mises à jour soient prises en compte. Pour de nombreuses applications, une actualisation par jour suffit.

Au cours de la configuration initiale de l'application, y compris pendant la capture et lors du premier basculement de dynamique à statique, vous pouvez souhaiter des intervalles plus fréquents, (par exemple, 2 minutes), afin que les modifications soient plus rapidement prises en compte.

Dans certains cas, vous souhaitez peut-être désactiver la fonction d'actualisation automatique. Si votre application reçoit peu ou aucune mise à jour de maintenance après son déploiement et que la plupart des instructions SQL ont été capturées et liées, il n'est pas vraiment nécessaire de la faire fonctionner en mode de capture continue ni d'activer l'actualisation automatique.

Les propriétés pureQuery Runtime runtimeGroupActivationCheckInterval et propertiesRefreshInterval contrôlent l'actualisation automatique des informations pureQuery pour les versions du groupe d'exécution :
  • La propriété runtimeGroupActivationCheckInterval contrôle le moment où pureQuery Runtime vérifie les versions de groupe d'exécution activées. La propriété doit être définie pour qu'elle s'applique à toutes les instances pureQuery Runtime qui exécutent une machine virtuelle Java.
  • La propriété propertiesRefreshInterval peut être utilisée pour indiquer un intervalle spécifique pour vérifier les mises les mises à jour apportées aux informations pureQuery pour une version de groupe d'exécution. La propriété peut également être définie de façon à désactiver toutes les vérifications d'informations pureQuery mises à jour pour la version du groupe d'exécution, y compris la vérification qui se produit lorsqu'une version de groupe d'exécution est activée.

Pour plus d'informations sur les propriétés, voir Propriété runtimeGroupActivationCheckInterval, et Propriété propertiesRefreshInterval.


Commentaires