Contrôle de contention des fichiers base de données

niveau de contrôle sont une fonction du traitement de base de données interne, et pas une action du programme d’application.

L’application de Company aBc traite un mix de jobs. Parfois, des jobs non critiques et de faible priorité ont besoin d’ajouter un enregistrement à l’un des fichiers physiques base de données. Dans certains cas, les besoins de traitement supplémentaires sont liés aux fichiers logiques associés aux fichiers base de données et à la journalisation. Toute l’activité de changement des fichiers physiques s’assure que les fichiers logiques sont mis à jour à la fin de chaque changement. Pendant qu’un job de faible priorité maintient les fichiers logiques, tous les autres jobs qui doivent changer le fichier, y compris ceux de haute priorité, doivent attendre.

Si la CPU du système est utilisée à 100 % et si le job de faible priorité (celui qui contrôle l’objet) est retardé parce qu’il ne peut pas parvenir à la CPU rapidement, tout job en attente de l’objet subit un délai plus long que celui du job qui détient le contrôle.

Avant la V5R3, le mécanisme Seize/Lock Contention Priority Adjust du système se chargeait de la plus grande partie du contrôle de contention des fichiers base de données. En termes simples, cet algorithme promeut le détenteur d’une faible priorité à la priorité du demandeur de plus haute priorité, jusqu’à ce que le job de plus faible priorité libère l’objet. Tout se passe bien, mais dans une application à forts volumes, la longueur du chemin d’instruction affecte le temps de réponse. L’utilisation de Seize/Lock a été changée pour certaines conditions en V5R3, pour utiliser les files d’attente internes ou les attentes QQu. Le mécanisme d’ajustement de priorité de cet algorithme ne promeut la priorité du détenteur que sous certaines conditions. Tout se passe bien, sauf quand la CPU est utilisée à 100 % pour des jobs dont la priorité est supérieure à celle du détenteur. Dans ce cas, le détenteur doit attendre beaucoup plus longtemps pour atteindre la CPU, faire son traitement et libérer l’attente QQu.

Sur tout système, la CPU sera utilisée à 100 % à certains moments. Pour que la performance reste homogène au moment du pic, IBM a besoin de réduire le temps d’attente de disponibilité de la CPU pour le job détenteur. Cela pourrait se faire en améliorant le mécanisme d’ajustement de priorité de l’attente QQu, peut-être en utilisant l’algorithme Seize/Lock ou en développant une nouvelle solution. Entre temps, les administrateurs dont les applications ont besoin d’une variation minime du temps de réponse de transaction, doivent être au courant des situations de pointe et éviter tout conflit en éliminant les changements de fichiers base de données simultanés par un travail en faible priorité pendant ces périodes.

Quand le système fonctionne très bien en charge maximale ou moyenne, le travail s’effectue sans incident notable. Soudain, un ou plusieurs jobs de mise à jour de fichiers (ou toute autre opération de changement de fichiers) doivent attendre longtemps la réponse à une demande partagée pour le contrôle des fichiers.

Si cela se produit alors que l’outil iDoctor Job Watcher d’IBM est actif, vous ne verrez probablement aucun traitement inhabituel. Mais Job Watcher pourrait afficher de nombreux jobs en attente d’une saisie « intent exclusive » pour un fichier physique spécifique, qu’un job spécifique tient actuellement partagé. Au bout d’un certain temps, le job détenteur relâche sa prise sur le fichier et chaque job en attente obtient sa part et effectue un peu de traitement.

Si la fonction du système d’exploitation détient une saisie exclusive sur un fichier physique, essayez d’abord d’utiliser Job Watcher et son analyse, et ses vues de contention d’objets. Si cela ne marche pas, essayez d’utiliser PEX Task Swicth Trace and analysis (très onéreux) ou la trace interne de Performance Tool et la commande Print Transaction Report (PRTTNSRPT) pour l’analyse (montre le détenteur et celui qui attend).