Analyser l’extension de l’espace de fichiers base de données.

de trace PEX ASM, n’est généralement pas aussi perturbant que d’utiliser la trace PEX Disk I/O ou Task Switch. Avec quelques centaines d’entrées ASM par seconde, vous pouvez collecter suffisamment d’entrées de données (de 1 à 2 millions) pour avoir une bonne idée des objets les plus actifs et des fonctions système causant les entrées de trace ASM, sans souffrir d’un overhead excessif pour le transfert et la première analyse.

Avec Job Watcher ou Collection Services, vous pouvez voir les effets du traitement étendu ASM. Recherchez les jobs qui présentent beaucoup d’activité d’écriture dans la base de données, dans une courte période. Job Watcher permet un large éventail de temps d’échantillonnage de collecte. Si l’on collecte des valeurs dans un intervalle de 1 à 10 secondes, il est beaucoup plus facile d’obtenir des résultats d’analyse pertinents que si l’on utilise le temps d’échantillonnage de 15 minutes par défaut de Collection Services.

Nombreuses sont les applications qui ajoutent des enregistrements à des fichiers base de données. Ainsi, un fichier de sortie séquentiel, du genre fichier log, pourrait voir beaucoup d’enregistrements ajoutés en peu de temps, au point d’épuiser l’espace disponible du fichier. Le prochain ajout ne pourra se faire que si de l’espace supplémentaire a été alloué au fichier. Dans une telle situation, la fonction SLIC ASM étend l’espace disque du fichier pour accepter les enregistrements supplémentaires.

Le traitement étendu ASM est intensif et ne peut pas être interrompu par une autre demande d’espace provenant d’un job plus prioritaire. La requête en cours doit être terminée avant que la requête suivante soit prise en considération. ASM trouve l’espace disque disponible en lisant, en traitant et en réécrivant les répertoires d’espace sans disque comme une partie intégrante de la requête. Si les répertoires ne sont pas réécrits immédiatement et si le système s’arrête, il pourrait y avoir danger et le système nécessiterait un démarrage à froid. ASM fait tout son possible pour éviter cette éventualité. L’espace alloué à un fichier se voit attribuer une adresse virtuelle unique et des trames de pages de mémoire principale, sollicitant du même coup davantage le Main Storage Management pour trouver, effacer et attribuer des trames de pages aux fichiers à partir du pool de stockage principal du job demandeur. Pour couronner le tout, il y a beaucoup d’overhead en utilisation de CPU, activité d’allocation de trames de pages de mémoire principale, et opérations d’I/O disque. Plus le système est actif, et plus l’overhead est évident.

Il existe un moyen simple et direct d’éviter le ralentissement qu’ASM peut causer en ajoutant de l’espace à un fichier base de données : utiliser l’option ALLOCATE *YES sur la commande Create or Change Physical File pour les fichiers présentant une forte activité d’ajout d’enregistrements. Ce paramètre alloue l’espace nécessaire au fichier quand il est créé, quand un nouveau membre lui est ajouté et la prochaine fois où un enregistrement ajouté a besoin d’une extension, ce qui pourrait bien se produire à un moment de forte occupation. Si l’espace de fichier est épuisé pendant le traitement d’un fichier pré-alloué, le fichier s’étend plutôt que d’arrêter le traitement. A noter que la pré-allocation de l’espace disque n’est pas utilisée pour les fichiers logiques indexés, pour les index racines, ou pour les EVI (encoded vector indexes).

Chez Company aBc, la pré-allocation de l’espace disque est appliquée quand la majorité de l’activité du fichier log de transactions ajoute des enregistrements. Pour optimiser la performance d’ajout d’I/O disque, utilisez la pré-allocation des fichiers conjointement à une définition de fichiers en sortie seulement dans le programme qui est supplanté, avec un blocage d’enregistrement de sortie de 128 Ko.