Options 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ées au cours du processus d'activation de l'optimisation client pureQuery et pendant l'exécution :
  • Fichier de propriétés de configuration de 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 de 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 un référentiel d'une base de données, dans un système de fichiers 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 exécutez l'utilitaire pureQuery ManageRepository pour accéder aux données pureQuery et les stocker 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 établir des plans appropriés 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 interrompre les applications en cours.
  • Un référentiel géré de manière centrale permet d'utiliser un seul exemplaire des fichiers de propriétés pureQuery et des fichiers XML par les applications déployées sur plusieurs serveurs d'applications.
  • Une application en cours d'exécution peut être configurée pour rechercher régulièrement les mises à jour des fichiers de propriétés pureQuery et des fichiers XML et commencer immédiatement à 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é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 (entrée)
  • données SQL capturées par 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 au cours de 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 d'enregistrement de capture de sortie, envisagez de placer la base de données du référentiel sur le serveur d'applications 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. Dans ces cas, vous devriez 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 inviter pureQuery Runtime à 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 au cours de 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.

Intervalle automatique entre les actualisations
Vous pouvez activer cette fonctionnalité pureQuery pour actualiser automatiquement les propriétés de pureQuery Runtime et de pureQueryXML des applications qui s'exécutent pendant une période prolongée et des connexions mises en mémoire cache en utilisant la propriété propertiesRefreshInterval. Même si cette fonctionnalité est désactivée par défaut, vous pouvez activer l'interrogation périodique et l'actualisation en spécifiant un entier positif, lequel précise le nombre de minutes écoulées entre deux tentatives d'actualisation.

Les applications qui reçoivent des mises à jour de maintenance fréquentes et les infrastructures qui continuent à générer les données SQL non capturées au préalable sont de bons candidats pour l'actualisation. 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 quotidienne (en spécifiant l'option propertiesRefreshInterval avec une valeur de 1440) est suffisante.

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

Dans de nombreux cas, vous souhaiterez laisser cette fonctionnalité désactivée. 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. De même, s'il est facile pour vous de redémarrer l'application et le serveur d'applications chaque fois que vous souhaitez que pureQuery Runtime reconnaisse les nouvelles propriétés d'exécution ou pureQueryXML, il n'est pas nécessaire d'utiliser la fonctionnalité d'actualisation automatique.

Si vous avez activé l'actualisation automatique et que vous souhaitez ultérieurement modifier l'intervalle d'actualisation pendant l'exécution de l'application, vous pouvez le faire en modifiant la valeur de la propriété dans le référentiel de base de données. pureQuery détectera le changement au prochain intervalle et basculera ensuite sur la nouvelle valeur.


Commentaires