Le cache de plan lui-même peut être considéré comme un objet semi-permanent. Vous pouvez le considérer comme un objet permanent pendant que votre serveur est opérationnel, mais il est supprimé dès que vous arrêtez ou redémarrez le serveur. L’objet cache de plan SQL est créé automatiquement à partir de zéro
Gestion du cache
pendant un IPL système. Un ralentissement temporaire peut se produire après un IPL, pendant que le cache de plan est repeuplé avec les plans d’accès.
On l’a vu, le cache de plan SQE est autogéré et donc DB2 alloue automatiquement l’espace pendant IPL et surveille la taille du cache pendant que le système fonctionne. Dès qu’on approche de la taille limite, DB2 supprime des plans en se fondant sur le nombre de fois qu’un plan d’accès a été utilisé et à quand remonte sa dernière utilisation. En V5R4, le cache de plan a une taille maximale de 512 Mo – de quoi accepter environ 12 000 à 20 000 instructions, selon leur taille et leur complexité.
IBM a introduit un nouvel outillage iSeries Navigator dans la V5R4 pour permettre aux utilisateurs de surveiller la taille du cache et d’analyser le contenu. Si le cache de plan SQL de votre système atteint la limite de taille maximale, vous pouvez archiver le contenu du cache dans un objet permanent appelé instantané pour capturer tous les plans qui serviront à des analyses de performances ultérieures, avant de supprimer les plans du cache.
Téléchargez cette ressource
Une DSI « broker de services » ? Recettes de Scale-ups à l’usage des grandes entreprises
Réalisé en partenariat avec Alliancy, découvrez dans ce carnet d’expériences les conseils et bonnes pratiques de DSI et CTO d'organisations qui ont mené et mènent leur transformation pour devenir des brokers de services accomplis. Choix technologiques et organisationnels, types de services apportés, vitesse du changement, rapport aux métiers… ils détaillent la nature et les potentiels écueils de cette métamorphose.
Les articles les plus consultés
A travers cette chaîne
A travers ITPro
