par Jean Driscoll
Consultant technique principal, Syntax
Parfois, tu arrives un lundi matin et rien ne fonctionne. Soudainement, tu as un P1 et beaucoup d’utilisateurs et leurs gestionnaires qui appellent. La plupart des travailleurs en TI ont été appelés au milieu de la nuit ou sont arrivés au travail en entrant dans cette situation.
La croissance des données est généralement graduelle et peut être surveillée et les disques nettoyés ou ajoutés pour maintenir les opérations en mouvement. On ne s’attend pas à un problème de disque.
Je n’aime jamais voir le SQL0901 message quand ça pointe vers un problème de base de données. J’espère que cette discussion sera bénéfique en décrivant certaines commandes qui vous aideront à mieux comprendre votre base de données et à tenir un journal.
Pour suivre les ajouts, modifications et suppressions SQL, et permettre une opération de retour en arrière SQL (au cas où la mise à jour ne serait pas permise), JD Edwards Enterprise One commence à tenir un journal sur la base de données iSeries. La revue est définie dans le JDE. INI. Il utilise des objets récepteurs journal pour conserver les images avant et après des mises à jour des enregistrements.
Normalement, ces récepteurs journals sont gérés par le système – les sauvegardent et les suppriment à intervalles définis. Cependant, des problèmes peuvent survenir qui empêchent de sauvegarder et/ou supprimer les destinataires du journal. Si personne ne surveille ou n’est au courant de ce problème, ces récepteurs de journaux peuvent s’accumuler dans le système et causer des ravages.
Lorsqu’on utilise une iSeries comme serveur d’entreprise et base de données, les services JDE cessent de fonctionner si l’utilisation du disque dépasse un pourcentage défini par l’utilisateur du système. Les utilisateurs recevront des messages lorsqu’ils essaient de se connecter et les journaux afficheront une erreur SQL0901. Ce message peut indiquer que vous manquez d’espace disque, ou qu’il y a des problèmes de journalisation dans la base de données.
Lorsque vous recevez des messages SQL dans les journaux Enterprise One, le code peut être consulté sur l’iSeries à l’aide de la commande : I
Blog Web d’Enterprise One montrant SQL0901
Journal du serveur d’entreprise Enterprise One montrant SQL0901
Si vous regardez les messages de l’opérateur système, vous verrez des messages comme celui-ci qui vous indiquent que votre disque est plein. Ces messages devraient être configurés sur un moniteur iSeries.
CPI099B 90 Condition critique de stockage existe.
CPI099C 90 Limite inférieure de stockage critique atteinte.
DSPMSG QSYSOPR :
Utilisez WRKSYSSTS pour voir le pourcentage d’utilisation du disque (si vous utilisez plusieurs ASP, utilisez DSPASPBRM).
Pour savoir ce qui utilise le disque, un rapport système iSeries doit être généré. Deux processus sont nécessaires pour obtenir ce rapport – RTVDSKINF/PRTDSKINF.
- La commande RTVDSKINF devrait être configurée sur l’ordonnanceur de tâches iSeries – WRKJOBSCDE job QEZDKWKMTH. Si cette tâche n’est pas configurée sur un planificateur, cette commande doit être exécutée depuis la ligne de commande. Même si la tâche s’exécute sur l’ordonnanceur, pour voir le rapport d’utilisation du disque mis à jour avec les informations actuelles, cette commande doit être exécutée.
- La commande PRTDSKINF vous donne le rapport, basé sur les données sauvegardées par la commande RTVDSKINF. Vous voudrez peut-être lancer cette commande d’abord, pour voir l’espace disque utilisé, puis exécuter le RTVDSKINF, puis exécuter ce PRTDSKINF une deuxième fois pour voir l’utilisation actuelle. PRTDSKINF RPTTYPE(*LIB) MINSIZE(1000)
- WRKJOB Option 4 : Après avoir lancé le rapport, ça t’aide à le retrouver. Parcourez le rapport vers le bas pour voir la taille des récepteurs de revues sur le système, puis la taille des bibliothèques.
- Après avoir débarrassé les récepteurs des revues, soumettez à nouveau les commandes RTVDSKINF et PRTDSKINF pour voir la différence.
- Le problème de disque complet pourrait aussi être dû à un rapport qui devient incontrôlable. Vous verrez ceci comme « Bobine » sur le rapport. Utilisez WRKOUTQ pour visualiser toutes les files d’attente de sortie, sélectionnez chaque file d’attente avec des fichiers et examinez le nombre de pages dans les rapports pour vous assurer que ce n’est pas le problème.
En haut du rapport, vous pouvez voir à quelle date a été diffusée la RTVDSKINF. Page Down pour voir où le disque est utilisé.
Dans la plupart des cas de problèmes de disque sur iSeries pour une installation JD Edwards, le problème est qu’un programme a ajouté/mis à jour/supprimé beaucoup de données et que les récepteurs journal ont augmenté trop rapidement, ou peut-être que la sauvegarde n’a pas été lancée et qu’un message existe quelque part disant que les récepteurs journal ne pouvaient pas être supprimés.
Le journal par défaut utilisé pour les tables mises à jour via JDE se trouve dans le JDE. INI sur le serveur d’entreprise. Utilisez WRKLNK « E920SYS/INI » et l’option 5 pour consulter le fichier jde.ini. Mettez « Journ » sur la ligne de contrôle et appuyez sur F16 pour trouver le journal par défaut.
Cependant, ce n’est pas toujours le journal utilisé par les tables. Si le client utilise la réplication MIMIX, il peut avoir assigné un journal différent pour différentes bibliothèques ou objets. Utilisez la commande DSPFD sur la ou les tables qui ont été ajoutées/mises à jour/supprimées pour savoir quel journal est utilisé.
DSPFD CRPDTA/F0911 :
Roulez vers le bas ou tapez « ourn » dans la file de recherche et appuyez sur F16 pour voir quel journal est utilisé.
Une fois que vous savez quelle revue est utilisée, utilisez la commande WRKJRNA pour trouver dans quelle bibliothèque se trouvent les récepteurs de revues.
WRKJRNA OWJRNL/OW_JRNL
F17 – attributs du récepteur de revue – pour déterminer dans quelle bibliothèque trouver les récepteurs de revues.
Pour voir les récepteurs et déterminer si c’est un problème, utilisez la commande WRKOBJ et l’option 8 pour voir la taille. Faites la page vers le bas à travers quelques écrans pour déterminer combien de ces écrans existent.
WRKOBJ OWJRNL/*tous *JRNRCV :
Pour supprimer les récepteurs, utilisez la commande DLTJRNRCV.
DLTJRNRCV JRNRCV(OWJRNL/O*) DLTOPT(*IGNINQMSG)
Vous pouvez recevoir le message « CPA7025 – Récepteur OWJRNR0000 dans OWJRNL Never Fully Saved. » (I C) ».
Selon l’utilisation des récepteurs de journaux, vous ne voudrez peut-être pas supprimer les récepteurs immédiatement. Si les récepteurs sont utilisés dans MIMIX pour mettre à jour les données sur un système séparé, il se peut que vous deviez permettre à l’application de données de se compléter avant de pouvoir supprimer les récepteurs.
Réponds par « I » pour ignorer le message et supprimer le destinataire du journal.
Les récepteurs de journaux sont numérotés de 0000 à 9999. Les récepteurs doivent être supprimés dans l’ordre. La commande DLTJRNRCV essaiera de les supprimer à partir de 0000.
Cependant, une fois que le récepteur 9999 est créé et plein, il tentera de créer à nouveau 0000 afin que les récepteurs journal puissent être hors séquence. Dans cet exemple, j’ai essayé de supprimer un récepteur de journal, OWJRNR0008. Comme 0001-0007 existe toujours, je ne peux pas faire celui-ci.
Pour voir l’erreur complète, placez le curseur directement sur le message et appuyez sur F1.
Entretien des récepteurs de journaux :
Pour la commande WRKJRNA ci-dessus, il y a une option pour définir comment les récepteurs sont gérés. Cela doit être réglé sur *SYSTEM et l’option Supprimer les récepteurs sur *OUI. Utilisez la commande CHGJRN pour les configurer. Si vous avez dû supprimer plusieurs destinataires de journaux, assurez-vous qu’ils sont sauvegardés et supprimés régulièrement.
CHGJRN JRN(OWJRNL/OW_JRNL) MNGRCV(*SYSTÈME) DLTRCV(*OUI)
WRKJRNA OWJRNL/OW_JRNL
Vérifie la sauvegarde pour t’assurer que les récepteurs sont en secours.
DSPLOGBRM TYPE(*BKU) PÉRIODE((*DISPONIBLE 121022))
SQL0901 avec le recul :
L’erreur de SQL0901 peut survenir pour d’autres raisons que le simple fait que le disque est plein. Chez un client, cette erreur s’est produite lorsque la taille des récepteurs de journaux dépassait le seuil. Dans ce cas, il faudrait supprimer les récepteurs de journal ou mettre à jour le seuil pour en permettre davantage.
Parfois, une nouvelle table sera ajoutée manuellement au lieu de passer par le client de développement EnterpriseOne. La façon dont une table est créée peut ne pas commencer le journal sur la table. Cela générera aussi une erreur de SQL0901.
Quand je vois cette erreur, le premier élément que je vérifie est l’espace disque. Si ce n’est pas un problème d’espace disque, vous devrez enregistrer la tâche avec l’erreur. Dans bien des cas, il s’agit d’un travail de base de données comme QSQSRVR ou QZDASOINIT. Vous pouvez chercher n’importe lequel de ces emplois dont le statut est MSGW, mais parfois ils sont cachés et il faut continuer à chercher.
Résultats/rapports du programme :
Si supprimer les récepteurs journal ne vous rend pas l’espace disque, utilisez la commande WRKOUTQ pour visualiser les files d’attente de sortie. Parfois, un travail devient fou et commence à créer beaucoup de fichiers bobines ou un gros fichier bobinage qu’il faut supprimer.
Faites un roll through et utilisez l’option 5 pour voir des files de sortie spécifiques qui peuvent contenir des fichiers spool à supprimer.
Conclusion :
EnterpriseOne exige que les tables aient le journaling activé lors de l’utilisation d’iSeries comme base de données. Par conséquent, ces récepteurs de revues doivent être entretenus. Que ce soit manuel ou par le système, quelqu’un devrait les surveiller, par des messages de surveillance ou des vérifications manuelles.
Commandes utiles pour comprendre d’éventuels problèmes de base de données :
WRKMSGD, MSGID (SQLxxxx), MSGF(QSQLMSG)
DSPMSG, QSYSOPR
WRKSYSSTS
RTVDSKINF, PRTDSKINF
WRKLNK 'E920SYS/INI'
DSPFD CRPDTA/F0911
WRKJRNA OWJRNL/OW_JRNL
WRKOBJ OWJRNL/*tous *JRNRCV
DLTJRNRCV JRNRCV(OWJRNL/O*) DLTOPT(*IGNINQMSG)
CHGJRN JRN(OWJRNL/OW_JRNL) MNGRCV(*SYSTÈME) DLTRCV(*OUI)
WRKJRNA OWJRNL/OW_JRNL
PÉRIODE DE TYPE DSPLOGBRM (BKU)
WRKOUTQ