Cet article est la traduction d’un article de Jonathan Lewis publié sur son blog. L’article original en anglais se trouve ici

Sur Oracle, certains concepts sont si fondamentaux qu’on doit toujours les avoir en tête à chaque fois qu’on veut étudier un problème de performance. Et voici l’un d’eux:

Les histogrammes et les bind variables existent pour des raison diamétralement opposées: sans y prêter garde, ils ne fonctionneront pas bien ensemble.

Vous utilisez des bind variables parce que vous voulez que tout le monde partage le même plan d’exécution pour une requête SQL qui va être utilisé fréquemment. Tout le monde va faire la même charge de travail avec (charge normalement faible). Son plan d’exécution sera optimal pour tout le monde. Et vous ne voulez pas ré-optimiser cette requête à chaque fois, car cette réoptimisation utiliserait à elle seule plus de ressources qu’il n’en faut ensuite pour l’exécuter.

En général on utilise beaucoup les bind variables lorsqu’on est en transactionnel (OLTP) – sauf quelques cas particuliers où on préférera des valeurs littérales.

Et vous créez des histogrammes pour des requêtes qui, mêmes si elles sont similaires, vont faire un travail très différent les unes des autres. Elles ont besoin de plans d’exécution différents. Et de toute façon le travail d’optimisation est négligeable par rapport au travail d’exécution de la requête. Alors que si on utilise un plan d’exécution qui n’est pas optimal, on peut se retrouver à gaspiller beaucoup de ressources.

En général, on a besoin des histogrammes en datawarehouse, en BI, où les requêtes peuvent être très grosses et coûteuses.

C’est là qu’est la contradiction: on a une technologie qui est censée nous donner un seul plan d’exécution partagé par tout le monde, et une autre qui elle est censée trouver pour chacun le plan qui lui convient le mieux.

Gardez celà en mémoire, et vous vous rappellerez qu’il faut être très prudent lorsqu’on met des histogrammes sur une base transactionnelle (OLTP) et qu’il ne faut pas non plus transformer absolument toutes les valeurs littérales en bind variables.

A noter les commentaires de Doug Burns et Hemant K Chitale sur le fait qu’en 10g Oracle collecte par défaut des histogrammes avec la méthode ‘FOR ALL COLUMNS SIZE AUTO’ de dbms_stats.

Jonathan Lewis a mis les liens de l’article original et de la traduction sur son blog.

Ceci est une traduction de d’un ancien post de Jonathan Lewis sur forums.oracle.com, référencé récemment sur son blog. Il décrit le fonctionnement de la journalisation en mémoire (IMU – In Memory Undo), une optimisation introduite en 10g qui utilise des structures en mémoire pour diminuer la contention sur les blocs d’undo et le redo log buffer.

Le contenu des blocs d’undo et des fichiers de redo log sont quasiment les même que l’on utilise in-memory undo (et les private redo threads) ou que l’on utilise la journalisation ‘normale’.
La principale différence se trouve dans l’ordre où sont faites les choses.
Il y a aussi, avec in-memory undo, une diminution du nombre de redo records même si le nombre de change vectors reste le même.

Voici le séquencement d’une transaction courte avec gestion normale de la journalisation.

• Vous modifiez un bloc de table ou d’index. Un vecteur de changement (redo change vector) est généré pour cette modification.
• En même temps, vous devez enregistrer l’information nécessaire pour défaire (rollback) de cette modification. C’est un enregistrement d’annulation (undo record) qui est généré pour décrire ce qui a été altéré.
• Mais comme cet undo record est stocké dans un bloc d’undo (rollback segment), alors un vecteur de changement redo change vector est généré pour décrire cette modification du bloc d’undo
• Oracle combine ces deux redo change vector (vecteurs de changement du bloc de donnée et du bloc d’undo) dans en un enregistrement de redo (redo record), ce qui incrémente la statistique de session ‘redo entries’.
• Donc pour cette modification, Oracle doit acquérir de l’espace dans le tampon journalisation redo log buffer avec le latch ‘redo allocation’ et y copier l’enregistrement de redo avec le latch ‘redo copy’

Si l’on insère 10 lignes, une par une, dans une table qui a 4 indexes, alors on va générer 50 redo records et 50 undo records, et faire appel 50 fois au latches de redo: 5 redo record par ligne (un pour la table et un pour chaque index) pour 10 lignes.

Lorsque la fonctionnalité de journalisation en mémoire (in-memory undo) est activée, et parce que dans cet exemple il s’agit d’une petite transaction, voici ce qu’il se passe:

• A moment où on modifie la première ligne de la table, Oracle alloue dans la shared pool son propre buffer de redo privé (appelé redo strand) et son propre buffer de « undo ». En fait, ce buffer de « undo » contient du redo: c’est le redo qui décrit ce qui doit être modifié dans les bloc d’undo.
• Lors de la mise à jour de la table et des index, chaque change vector qui décrit la modification est écrit dans le buffer de redo privé.
• En même temps, les change vector qui décrivent le undo record correspondant sont écrits dans le buffer de « undo » privé.
• Le nombre total de change vectors, et leur contenu sont exactement les mêmes que pour les change vectors traditionnels.
• Au commit, oracle concatène ces 2 buffers pour faire un seul redo record et l’écrit dans le tampon de journalisation normal (redo log buffer)
• En même temps, ces 100 change vectors sont appliqués: 10 sur la table, 10 sur chaque index, et 50 sur les blocs d’undo. Et en dehors de cela, tout ce qui doit se faire lors d’un commit s’applique aussi.
• Le nombre de modification de blocs (« db block changes ») reste le même dans tous les cas
• La différence la plus significative dans le volume de redo généré vient de l’entête du redo record qui fait 12 octets. Avec la gestion ‘in-memory’ de l’undo il n’y qu’un seul redo record, donc un header de 12 octets, alors que la méthode traditionnelle en génère 50, donc 50*12=600 octets.

Il y a de nombreux détails et variations autour de ce qui se passe là. Par exemple au début et à la fin de la transaction, ou lorsque un des deux buffers est plein (puisqu’ils ne font que 64Ko ou 128Ko) mais la description faite ci-dessus couvre les différences essentielles.

Question: Supposons que je démarre l’instance et effectue quelques mises à jour. J’ai donc un buffer privé de redo et un buffer privé de undo, créés en shared pool. Immédiatement après le système se plante et rien n’est encore écrit dans les fichiers de redo ni dans les blocs d’undo. Dans cette situation comment fait Oracle pour récupérer les données d’undo ?

Il y a deux chose que vous devez prendre en compte dans ma description:

• la précision: ‘Il y a de nombreux détails et variations’
• la partie qui montre que les modifications faites dans les blocs tables et index est tout à la fin.

Si la session a fait un commit, elle a écrit le redo privé dans le redo thread public, qui doit être écrit sur disque avant que le commit ne soit terminé. Donc il n’y a rien de différent au niveau du recovery.

Maintenant, si la session n’a pas encore fait de commit, alors du point de vue des autres utilisateurs, rien ne s’est encore passé (ils ne sont censés voir que les effets des transactions commitées). Du coup, cela n’a pas d’importance que les redo et undo privés aient disparu.

Mais voici où ca devient plus complexe: Comment les autres sessions voient que vous êtes en train de modifier les mêmes blocs qu’elles, si vous ne les mettez à jour que lorsque vous faites le commit de votre transaction ? Comment Oracle fait pour minimiser le temps que prennent toutes les modifications de blocs qui doivent être faites lors du commit ? J’ai quelques réponses à ces questions, mais elles ne sont ni exactes, ni complètes, alors je ne préfère pas les publier.

Cependant, un point clé de ce mécanisme, c’est le fait qu’il ne s’applique qu’à des petites transactions. Les zones privées ne font que 64Ko ou 128Ko suivant qu’on est en 32 ou 64 bits, et dès que la transaction devient trop grande, Oracle les écrit dans les redo buffer et poursuit avec le mécanisme normal.

Ceci est une traduction de d’un post de Jonathan Lewis sur son blog – la quatrième et dernière partie d’une série de quatre sur la fragmentation (original en anglais). Il est conseillé de lire avant: Fragmentation – Introduction, Fragmentation – Disque et Tablespace, Fragmentation – Table

Fragmentation Index

La fragmentation en extents multiples et la fragmentation due à ASSM que j’ai décrit dans la note précédente à propos des tables s’appliquent aussi aux indexes, bien sûr, et nous importe de la même manière, c’est à dire presque jamais. Lorsque les gens parlent de fragmentation d’index, ils pensent en général au problème des blocs avec un faible taux de remplissage (sparsely populated blocks) qui est aussi un phénomène que j’ai décrit à propos de la fragmentation des tables, mais il y a quelques différences entre une table et un index, que nous allons examiner tout de suite.
Il est intéressant de considérer aussi un autre sens possible pour la fragmentation d’un index, que nous allons aussi examiner: c’est l’effet de bord de la division d’un bloc feuille (leaf block splitting) qui fait que des blocs qui sont logiquement à la suite se retrouvent physiquement dispersés.

Nous allons commencer avec une suppression en masse, et étudier les mêmes cas représentatif que nous avons vu à propos des tables (c’est à dire 20% des blocs ayant 100% de leurs ligne supprimées, et 100% des blocs ayant 20% de leur lignes supprimées). Et quand on fait ça, il faut garder à l’esprit que la suppression dans un index est différente de la suppression dans une table, d’où une différence de comportement dans ce qui suit.
Lorsqu’une transaction supprime une ligne d’une table (DELETE) la ligne est réduite à un stub de quelques octets, avant que ne se fasse le commit, et elle peut réutiliser immédiatement l’espace libéré dans le bloc de la table. Mais lorsqu’une transaction supprime une ligne d’un index, il doit laisser en place l’entrée d’index entière, et la marquer comme supprimée. Elle ne peut pas réutiliser l’espace immédiatement, mais cela doit attendre que le commit soit fait.

Une autre différence majeure entre une table et un index est le fait que dans un index chaque entrée a sa place et doit aller au bon endroit. Ce qui fait que lorsqu’un bloc d’index a de l’espace libre, sans être complètement vide, il n’y a que les lignes qui correspondent exactement à cette partie de l’index (à cette plage de valeurs) qui peuvent réutiliser cet espace.

De plus, lorsqu’un bloc feuille devient complètement vide, il reste toujours chaîné dans la même position de la structure de l’index, même s’il est aussi référencé par la freelist. (Mon hypothèse là dessus est qu’il est probablement plus facile de gérer les problèmes de lecture cohérente – read consistency – mais cela peut aussi être lié à des problèmes de rollback et au coût de la modification de 3 pointeurs dans la structure de l’index.) Ce qui veut dire que si on a un index qui a eu une large suppression des valeurs les plus basses, alors une requête qui demande la valeur minimum va devoir faire un range scan d’un grand nombre de blocs vides avant de trouver le bloc feuille qui contient une donnée présente. C’est pour cela qu’il faut toujours penser à faire un ALTER INDEX … COALESCE sur un index lorsqu’on supprime fréquemment les premières entrées. Et de manière plus générique, même si c’est moins courant, lorsque on un supprime un grand nombre de valeurs consécutives n’importe où dans l’index.

Dans le cas plus général d’un suppression en masse, on peut se retrouver avec un espace libre important dans tous les blocs feuilles et, contrairement à l’espace libre des tables, on ne peut pas faire en sorte qu’Oracle le réutilise en choisissant une valeur idéale pour PCTUSED puisque ce paramètre n’a pas de sens pour un index. Donc, dans le cas des index, la question que l’on doit se poser est: à quel point cet espace libre a un impact sur l’application.

Les considérations habituelles s’appliquent ici, bien sûr: un plus gros volume à sauvegarder lors des backup et plus de blocs à garder en buffer cache. Mais nous devons voir si le fait d’avoir un grand nombre de blocs feuilles faiblement remplis n’a pas un impact plus direct et plus significatif sur les performances.
La réponse est dépendante de l’application, bien sûr. Mais en général un index est utilisé pour lister les valeurs clés et les regrouper dans un faible espace. Et en gardant cela à l’esprit, on peut voir que le plus gros du travail de la plupart des requêtes est passé à aller voir les lignes de la table après avoir récupéré un certain nombre de valeurs clés dans l’index. Par conséquent, le travail supplémentaire venant du fait qu’il y a une grand quantité d’espace libre dans les blocs feuilles de l’index n’est qu’une petite fraction du travail total de la requête. Et on peut donc décider de ne pas dépenser des ressources à réorganiser les index sauf s’ils sont vraiment très faiblement remplis. (Un index B-Arbre typique avec une arrivée aléatoire va tourner avec un taux d’utilisation de 70%, donc 30% d’espace libre, dans les blocs feuilles. Je ne suis pas particulièrement inquiet des performances d’un index avant que le taux d’utilisation ne passe en dessous de 50%, sauf si j’ai une preuve que cet index contribue significativement au temps d’exécution d’un ensemble de requêtes critiques.)

Il y a cependant deux autres problèmes de ‘fragmentation’ spécifiques aux index, et qui n’existent pas avec les tables.

Le premier est le fait qu’on ne met pas à jour une entrée d’index: on supprime l’entrée correspondant à l’ancienne valeur, et on ajoute la nouvelle entrée correspondant à la nouvelle valeur. Si ces mises à jours se font de manière aléatoire, alors il n’y a aucun des problèmes associés aux suppressions de masse. Mais si il y a un pattern de modification lié au temps, par exemple si vous avez un index sur une colonne ‘dernière_modification’ alors vous pouvez vous retrouver avec le pire effet d’un index partiellement rempli. Dans un cas comme celui-ci, vous allez supprimer (lentement) des entrées vers le début de l’index pour les insérer tout à la fin. Et l’espace libéré par les suppression ne sera jamais réutilisé puisque les lignes ne peuvent pas êtres modifiées dans le passé. En plus, si vous continuez à modifier des lignes du passé vers le futur, vous continuez à visiter des blocs faiblement remplis. Et si c’est un système transactionnel où les utilisateurs modifient une ou deux lignes à chaque fois, la recherche de l’entrée et la mise à jour dans l’index peut prendre une proportion significative du travail effectué par chaque requête d’update. Vous devez au moins être au courant de ce type d’activité afin de prévoir comment en mesurer l’impact sur les performances et adopter une stratégie pour y faire face.

Le deuxième type de fragmentation propre aux index, pour lequel le terme de fragmentation semble le plus approprié, vient des divisions des blocs feuilles (leaf block split). Si vous voulez ajouter une entrée dans un bloc feuille qui est plein, alors Oracle doit trouver un bloc vide quelque part, y déplacer à peu près la moitié des données du bloc courant, puis lier ce bloc à sa bonne place dans la structure de l’index. Par consequent, les blocs qui sont ‘logiquement’ adjacents ne sont pas nécessairement ‘physiquement’ adjacents. Cela veut dire que lorsque vous faites un index range scan assez large (ou un index full scan) vous vous retrouvez à faire beaucoup de lectures aléatoires de blocs.

C’est ici que SQL Server (et probablement sybase et peut-être DB2) entrent en jeu. La manière dont SQL Server gère l’espace libre pour les tables non clusterisées (heap tables) n’est pas très efficace. Donc c’est presque un article de foi (voire un dogme) que toutes les tables dans SQL Server doivent être construites en index cluster (clustered indexes), ce qui veut dire dans les termes Oracle, que toutes les tables sont des IOT (index organized tables tables organisées en index). Si vous avez essayé de regrouper (cluster) vos données, et y avez réfléchi soigneusement et délibérément, alors les divisions des blocs feuilles (leaf block split) détruisent votre effort de garder ensemble les données liées. Il n’est donc pas surprenant que les DBA qui ont une expérience en SQL Server (et Sybase et DB2) soient si favorables à l’idée de reconstruire les index fréquemment. Si vous reconstruisez un index cluster, vous ramenez les enregistrements là où vous voulez. Heureusement, cela ne nécessite pas de reconstruire tous les autres indexes de la table puisque, comme les index secondaires des IOT d’Oracle, les autres indexes en SQL Server utilisent la clé unique (ou rendue unique) comme identifiant de la ligne.

Pour Oracle, ce type de fragmentation ne pose généralement pas de problème, à condition qu’il concerne des index B-arbre standard, vu que, comme c’est précisé plus haut, la plupart des requêtes passent la plus grande partie de leur temps à visiter la table. Mais le cas de SQL Server donne une indication du cas où vous devrez considérer plus sérieusement les effets de la ‘fragmentation’ et le besoin de reconstruire les index. Si, en tant que DBA Oracle vous avez crée une table en IOT, alors vous aviez probablement une bonne raison de faire ce choix, et il s’agissait probablement de s’assurer que les données qui arrivent dans un certain ordre sont stockées dans un autre ordre, afin de garder ensemble des données qui sont liées.

Si vous avez crée une IOT pour garder les données regroupées, alors les divisions de blocs feuilles vont amener les données à être un peu dispersées. Avant de s’inquiéter, il faut étudier l’importance de cette dispersion, et le bénéfice, peut-être marginal, d’y faire quelque chose. Pour illustrer cela, imaginez que vous ayez une requête sur une table IOT importante qui récupère 200 lignes de 200 octets. Comme sur une table normale cela aurait demandé à lire 200 blocs différents dispersés aléatoirement, vous avez décidé d’implémenter la table en IOT. Si l’on prends le cas le pire pour le divisions de blocs feuilles (50/50 avec aucun re-remplissage) alors les 200 lignes vont aller dans la IOT avec environ 20 lignes par blocs sur un total de 10 blocs feuilles. A cause du moment où chaque division de bloc feuille a lieu, on peut penser que ces 1à blocs vont finir dispersés assez aléatoirement dans tout le segment d’index. Si vous reconstruisez l’index, vous allez pouvoir compacter les données sur seulement 5 blocs, et ces 5 blocs vont souvent être adjacents dans le segment plutôt que dispersés. Et ce regroupement ca probablement faire que vous aurez un petit bénéfice de performance si l’index range scan doit aller sur disque. Note: SQL Server travaille avec des tailles d’extents de 8 blocs de 8 KB et le logiciel de base de donnée peut coopérer avec le système d’exploitation pour négocier une lecture en avance (readahead) de l’extent complet dans ce genre de situation. Cet ensemble de détails font que la réorganisation d’index dans ces circonstances et plus bénéfique sur SQL Server que ce cerait le cas sur Oracle.

Après avoir passé un peu de temps à réfléchir à ce genre de scénario, il est plus facile de comprendre comment évaluer le bénéfice que vous pouvez tirer de la réorganisation d’une IOT. Quelle est la rédution du nombre total de visites de blocs que vous aurez à faire ? Combien de ces visites seraient des I/O disque distincts ? Quel serait le bénéfice du point de vue d’Oracle, du système d’exploitation, des drivers hardware, capable d’implémenter un readahead qui réduit le temps de lecture de ces blocs ? Gardez à l’esprit la remarque importante que j’ai fait dans l’article sur la fragmentation de disque: même si deux blocs aparaissent comme adjacent du point de vue des fichiers Oracle, l’introduction du stripping, et du load balancing peuvent faire que ces deux blocs sont sur des disques différents.

Fin de la série

Ceci est une traduction de d’un post de Jonathan Lewis sur son blog – la troisième partie d’une série de quatre sur la fragmentation (original en anglais). Il est conseillé de lire avant: Fragmentation – Introduction, Fragmentation – Disque et Tablespace

Fragmentation Table

Dans l’introduction nous avons parlé d’un type de fragmentation au niveau table qui, en général, ne pose pas de problème: la fragmentation d’une table en plusieurs extents. Et il y a une chose amusante, c’est que ASSM (Automatic Segment Space Management – la gestion automatique de l’espace libre dans les segments) a introduit une nouvelle forme de fragmentation, mais qui ne pose généralement pas de problème non plus.

En ASSM, lorsqu’un processus Oracle vérifie le bitmap qui garde la trace de l’espace libre d’un objet, et qu’il ne trouve pas assez d’espace libre pour insérer de nouvelles données, alors il va formater 16 blocs quelque part dans l’extent en cours (après avoir alloué un nouvel extent si nécessaire). Ces 16 blocs peuvent être n’importe où dans l’extent (du moment que le numéro du bloc de départ par rapport à l’extent soit un multiple de 16).
L’emplacement de cet ensemble de 16 blocs est déterminé par l’identifiant du processus (le PID – process id), de même que le choix du bloc à utiliser parmi ces 16. Ce qui veut dire si vous créez une table dans un tablespace qui a des extents uniformes de 1Mo, vous pouvez vous retrouver à ce que la première ligne que vous insérez se retrouve dans le tout dernier bloc de son extent.
Cela n’a généralement pas d’importance parce que:

• la plupart des accès I/O se font bloc par bloc plutot que par full scan, et donc l’emplacement du bloc dans l’extent n’a pas beaucoup d’importance.
• ce ‘désordre’ ne se retrouve en principe que sur le dernier extent de la table
• en cas de full scan, pour savoir quel morceaux de 16 blocs doivent être traités de manière spéciale, Oracle utilise un mécanisme qui minimise le surcoût de cette vérification, en utilisant les LHWM (low high water mark) and HHWM (high high water mark).

Le type de fragmentation de table le plus important, et le plus courant, vient des données qui sont supprimées, et on peut alors se préoccuper des blocs qui ont un faible taux de remplissage. Lorsqu’on crée une table, on précise l’espace qui doit être réservé dans chaque bloc afin de garder une marge pour les lignes qui vont être modifiées (UPDATE) et – explicitement en freelist ou implicitement en ASSM – on précise aussi l’espace libre que doit contenir un bloc pour qu’il puisse être à nouveau la cible d’une nouvelle insertion de données (INSERT).

Si on regarde tous les scénarios possibles qui doivent être pris en compte avec avec des insertions de données, des modifications et des suppressions, on se rend compte à quel point il peut être difficile pour Oracle d’écrire du code qui gère l’espace libre de façon efficace et opportune. On voit aussi à quel point il est difficile, en tant que développeur ou DBA, de préciser des limites raisonnables pour la gestion de l’espace afin de minimiser les problèmes de performances dans des cas extrêmes. Au final, il est possible de se retrouver avec une table qui a une quantité importante d’espace libre dans chaque bloc, et il faut alors se poser les questions suivantes: Comment ce espace libre est arrivé là ? Est-ce qu’il pose un problème de performance ? Est-ce que vous allez pouvoir le réutiliser ? Est-ce que vous allez pouvoir le réutiliser en temps opportun ? Si vous arrivez à le réutiliser, est-ce que ca n’introduit pas un autre type de problème de performance ?

Prenez le cas où vous purgez la première année de données après que votre système ait tourné pendant 5 ans. Cela va probalement faire que les 20% premiers blocs de la table seront complètement vides. Il iront en freelist. Ou en ASSM, à l’exception de quelques bugs, ils seront marqués comme ayant de l’espace libre. Et cet espace libre pourra donc être réutilisé plus tard. De plus, si les performances de votre application dépendent du fait que les données qui arrivent au même moment se retrouvent ensembles (clustering par rapport à la date/heure d’arrivée) alors de la manière dont l’espace libre est rempli, le clustering va normalement rester intact.
Par une bizarrerie de l’implémentation, les blocs vont être utilisés dans l’ordre inverse en gestion freelist et dans l’ordre normal en ASSM (et une question me traverse l’esprit à ce moment à propos de l’impact de cet ordre inverse sur les indexes non-uniques qui ont peu de valeurs distinctes).

Cependant, pour un bon moment, avant cette réutilisation, les full scan de la table vont prendre 20% de temps en plus de ce qui est nécessaire. Et vous pouvez vous retrouver à faire un backup d’un fichier plus gros que ce dont vous avez réellement besoin. Ces considérations peuvent alors vous décider à faire une réorganisation de la table (et d’un rebuild des index) en la déplaçant vers un autre tablespace. Et elles peuvent aussi vous amener a réfléchir au partitionnement de la table.

Imaginez le cas d’un système de vente par internet où les utilisateurs remplissent leur panier, paniers qui à la fin deviennent une commande. Inévitablement, certains utilisateurs vont remplir un panier sans passer la commande par la suite. Alors vous avez peut-être un programme en tâche de fond qui regarde les vieux paniers et le supprime de la base. Il y a deux imperfections dans cette implémentation, mais ce genre d’erreur se voit souvent sur des systèmes en production. Alors dans ce cas, vous vous retrouvez avec une table qui subit constamment des delete sur le passé récent, de telle sorte que si vous analysez la table, vous verrez qu’en moyenne elle a, disons, 20% d’espace libre dans chaque bloc, à l’exception des quelques blocs qui contiennent les paniers récents.

Si vous êtes en ASSM, ces 20% ne seront jamais réutilisés (sauf si en recréant la table) parce que la granularité de ASSM fait qu’il faut au moins 25% d’espace libre dans un bloc avant que son statut ne passe de ‘plein’ à ‘0% – 25% libre’. Mais si vous êtes en freelist alors vous avez peut-être prévu le coup en mettant PCTUSED à un peu plus que 80. Dans ce cas, les blocs reviennent en freelist dès que l’espace libre atteint 20%, et l’espace va être réutilisé.
Cela semble être une bonne idée, sauf qu’il y a un autre problème à prendre en considération.

Peut-être que les bonnes performances de votre application venaient du fait que les paniers des derniers jours sont stockés dans les N derniers blocs de la table. Du fait que vous libérez 20% de l’espace des blocs du passé, alors les paniers qui étaient stockés sur N blocs sont maintenant répartis sur 5 fois plus de blocs. Et cela veut dire que, si vous voulez garder le même niveau de performance, vous allez avoir besoin de plus de mémoire en buffer cache.

La conclusion générale est la suivante. Une fois que vous avez résolu une fois pour toutes le problème de la taille des extents d’une table, le seul problème de ‘fragmentation’ qui vous reste à prendre en compte est celui des blocs qui ne sont que partiellement remplis. Et il y a des patterns de suppression de données qui peuvent amener à cette situation de blocs sous-utilisés. Dans certains cas, il n’est possible de récupérer cet espace que par une réorganisation de la table (et dans tous les cas, c’est le partitionnement de la table qui peut faire que cette option est viable). Mais il y a aussi des patterns de suppression de données qui font que l’espace libre est réutilisable, mais que vous ne voulez pas toujours réutiliser cet espace, car cela peut amener un autre type de problème.

La suite: Fragmentation – Index

Ceci est une traduction d’un post de Jonathan Lewis sur son blog – la première partie d’une série de quatre sur la fragmentation (original en anglais)

Cet article a commencé comme une note brève, jusqu’à ce que je réalise que ça allait être plus important, et que j’en fasse plutôt une série de quatre articles:

• Fragmentation – Introduction
• Fragmentation – Disque et Tablespace
• Fragmentation – Table
• Fragmentation – Index

Introduction

Le mot ‘fragmentation‘ donne l’idée de quelque chose qui est cassé en plusieurs morceaux, mais il a aussi une connotation émotionnelle qui fait penser qu’il y a beaucoup de petits morceaux. Dans le contexte d’une base Oracle, vous devez savoir ce que vous entendez par ‘morceau’, ainsi que la granularité de ces morceaux, et leur impact possible sur les performances.

Vu qu’il est possible de parler de fragmentation au niveau disque (disque logique), ou au niveau fichier, niveau tablespace, niveau segment, niveau extent ou niveau block, il est important de savoir très clairement ce que vous essayez de dire lorsque vous faites un commentaire du genre ‘Mon tablespace est fragmenté’ ou ‘Mon index est fragmenté’

Partons sur un exemple: Je crée un nouveau tablespace et je déplace une table dedans (ALTER TABLE … MOVE).
Lorsque je regarde DBA_EXTENTS, ma table a 100 extents. Il est évident qu’il y a ‘fragmentation’ dans le sens premier de ce mot, puisque j’ai 100 différents morceaux. Mais d’autre part, puisque cette table est la première chose que j’ai créé dans ce tablespace, je vois que ces extents sont adjacents. On pourrait alors dire que la table est ‘logiquement fragmentée‘ mais ‘physiquement contiguë ‘.

Est-ce que ce type de fragmentation a un impact sur les performances du système ?

Vu qu’Oracle fait la plupart des I/O par bloc (nous lisons des blocs vers le buffer cache, nous écrivons des blocs dans les fichiers), et vu qu’il n’y a pas de conséquences au fait qu’un bloc appartienne à extent plutôt qu’un autre, alors la réponse est probablement: non.
Cependant, il y a des fois où on essaie de lire plusieurs blocs contigus en un seul I/O (full table scan et index fast full scan), alors y a-t-il des conséquences au fait que notre table ‘physiquement contiguë’ soit ‘logiquement fragmentée’ en un grand nombre d’extents ?

Que se passe-t-il si les extents font, disons, 64Ko chacun. Est-ce que cela limite la taille d’une lecture multi-bloc (db file multiblock read) ? Ou bien ces lectures peuvent-elles être à cheval sur deux extents ? Et si le tablespace a deux datafiles ou plus, dans ce cas l’allocation des extents se fait généralement en alternant les datafiles (round-robin), est-ce que cela affecte la manière dont les lectures pourront se faire ? Et si on fait des full table scan en parallel query (parallel tablescan), est-ce qu’il y a des restrictions différentes pour les lectures directes (direct-path reads) ?

Si vous faites tourner un datawarehouse qui passe beaucoup de son temps à faire ce type d’opérations, alors ce sont quelques unes des questions auquelles vous devrez savoir répondre. Voir, par exemple, une note que j’ai écrit il y a trois ans à propos d’anomalies dans les tailles d’I/O lorsqu’on est en parallel query, et l’amélioration faite là dessus en 11G qui a été décrite ici par Christian Antognini il y a quelques années.

Vous ne pouvez commencer à comprendre les problèmes posés par la fragmentation, et si elle a un impact - ou non - sur les performances, que lorsque vous aurez commencé à définir de manière claire ce que vous entendez par ‘fragmentation’. Dans la deuxième partie, je vais faire quelques commentaires sur la manière de réfléchir à la fragmentation au niveau disque et au niveau tablespace.

La suite: Fragmentation – Disque et Tablespace

Ceci est une traduction de d’un post de Jonathan Lewis sur son blog – la deuxième partie d’une série de quatre sur la fragmentation (original en anglais). Il est conseillé de lire avant: Fragmentation – Introduction

Fragmentation Disque

Les tablespaces sont composés de fichiers, et les fichiers sont stockés sur disque. Il s’agit la plupart du temps de disques logiques (logical volumes) plutôt que de vrais disques directement (real devices).
Lorsqu’on fait une lecture sur un vrai disque, la taille des données qu’on peut lire en une seule opération physique est quelque chose comme 400Ko ou 500Ko. C’est le contenu d’une seule piste sur un seul plateau d’un disque physique. Une lecture plus large continue en passant sur un autre plateau (ce n’est pas un mouvement physique des têtes, mais une commutation ‘électronique’) , ou bien en passant sur une autre piste (c’est alors un mouvement physique, mouvement latéral de la tête), ou encore en passant sur un autre disque. Passer sur un autre disque, c’est rejoindre une autre file d’attente de disque, et dans ce cas le logiciel du SAN, ou l’équivalent, aura probablement anticipé les disques dont vous aurez besoin et aura lancé en parallèle ces demandes de lectures dans les files d’attentes correspondantes.

Lorsque vous créez un datafile sous Oracle, vous ne savez pas à quel point le fichier est dispersé sur les disques physiques du système. Au mieux, une lecture de 1Mo va impliquer 3 ou 4 rotations d’un même disque, avec seulement des passage d’un plateau à l’autre (commutations ‘électroniques’). Et au pire, j’ai déjà vu un seul I/O impliquer jusqu’à 32 opérations différentes sur les disques, à cause des nombreuses couches de logicielles utilisés pour stripper sur les disques, puis sur les groupes de disques (diskgroup), puis sur les volumes logiques (logical volumes), etc.
Si on est tout seul sur le SAN, ce dernier cas où la lecture est parallélisée sur tous les disques est vraiment optimal pour les performances. Mais sur un système en production, c’est une calamité pour les files d’attentes. C’est pour cette raison que c’est une bonne stratégie de présenter des disques ‘bruts’ à ASM, en ayant une seule couche logicielle entre Oracle et les disques, et il s’agit en plus d’une couche logicielle qui connaît le comportement et les données d’Oracle.

A retenir: Ne pas mettre trop de couches de logiciels ‘intelligents’ entre Oracle et les lecteurs de disque.

Fragmentation Tablespace

Bien sûr, vous pouvez créer un tablespace avec plusieurs fichiers. Alors, par définition, le tablespace est fragmenté, même si il n’y a à la base rien de négatif avec ce type de fragmentation. Mais comme je l’ai précisé dans la note précédente (introduction), cela peut avoir des effets de bord sur la disposition des extents d’un segment, et arriver à des cas où vous voulez faire une seule lecture d’un gros volume de données, et vous retrouver en fait à faire plusieurs I/O plus petits – avec pour conséquence une augmentation de l’attente sur les I/O.

Le cas de fragmentation que la plupart des gens ont à l’esprit quand ils parlent de fragmentation de tablespace, c’est à dire le fait qu’il y ait des ‘trous’ d’espace libre au milieu de l’espace alloué, est quelque chose qui a aussi été appelé ‘gruyèrisation’ (ou en anglais honey-combing ou bubbling). C’est un effet de bord lorsqu’on supprime (DROP) ou réduit (SHRINK) des objects, qu’on déplace des tables (MOVE) ou qu’on reconstruit des indexes (REBUILD). On finit par avoir des morceaux d’espace libre dispersés sur tout le tablespace. Chaque fois que vous réorganisez un objet, vous allez probablement remplir certains de ces morceaux, mais en laisser d’autres vides là où se trouvait l’objet avant.

Fondamentalement, il est rare que ce type de fragmentation pose un problème, parce que cet espace vide n’entraîne pas de travail supplémentaire, sauf lorsque on fait un backup du fichier. Si vous pensez que le temps passé à copier cet espace vide lors d’un backup a un impact important sur la durée de la sauvegarde (dans le cas où le backup dépasse la fenêtre de temps permise avant le prochain cycle de chargement de données, par exemple), alors vous pouvez prévoir de déplacer des objets de telle sorte que l’espace libre se trouve à la fin de fichiers. Cela permet ensuite de réduire la taille des fichiers: voir par exemple cette note sur la réduction de la taille des tablespaces (en anglais).
Par contre, il faut garder à l’esprit qu’il peut y avoir des effets indésirables lors de cette réorganisation. Il y avait cette question sur le forum OTN il y a quelques années où un DBA s’est aperçu que déplacer des tables les a rendu plus volumineuses. j’ai écrit une note (en anglais) à propose de cela, en reprenant la question et la réponse (réponse que j’avais publiée dans ‘Practical Oracle 8i’).

Les difficultés liées à cette fragmentation ‘gruyère’ on été en grande partie un effet secondaire du paramètre PCTINCREASE d’Oracle qu’on pouvait spécifier pour les segments de données, amplifié par l’idée reçue qu’il vaut mieux réduire les objets à un seul extent. Mais depuis l’introduction des tablespaces dont l’espace libre est géré localement (LMT – Locally Managed Tablespaces), qui simplifient les options de dimensionnement des extents (surtout pour la taille d’extent UNIFORM), la seule question est quand l’espace libéré va être réutilisé et non comment est gérée cette réutilisation.

Pour en lire un peu plus là dessus: une histoire ancienne que j’ai publié bien avant qu’Oracle n’introduise les Locally Managed Tablespaces avec une taille d’extent uniforme, republié il y a 2 ans.

La suite: Fragmentation – Table

Cet article est la traduction d’un article de Jonathan Lewis publié sur son blog. L’article original en anglais se trouve ici.

Pour une description complète des modes de verrous, vous pouvez lire aussi: Les verrous sur les table, et leurs modes (S/X/RS/RX/SRX)

A propos des verrous (locks) et de leur mode (dans les colonnes LMODE et REQUEST de la vue V$LOCK par exemple), je raisonne souvent avec leur numéro. Et je m’apercois que je n’arrive jamais à retenir la correspondance entre le numéro et le lien, sauf pour le mode 6 = exclusive. Donc j’ai finalement mis ici la table de correspondance pour que je puisse la retrouver facilement.

Evidemment, c’st un peu irritant que certains modes de verrous aient 2 noms et 2 abréviations. Et certains documents utilisent un nom avec l’autre abréviation (par exemple pen parlant des row-exclusives, puis de l’abréviation SX). Les fichiers de traces relatifs aux locks on tendance à utiliser SS, SX, and SSX plutôt que RS, RX and SRX.

Cet article est la traduction d’un article de Jonathan Lewis publié sur son blog. L’article original en anglais se trouve ici.

Le ROWID identifie un enregistrement d’une table dans la base de données, à partir de l’adresse physique du bloc et du numéro d’enregistrement dans le bloc. Il est utilisé principalement dans les indexes pour pointer sur l’enregistrement de la table, et dans les tables pour les pointeurs des chained rows. C’est le moyen le plus direct car il permet d’aller directement sur le bloc qui contient l’enregistrement.

Jusqu’à Oracle 7, l’adresse physique d’un bloc était constitué du numéro du fichier de la base (absolute file_number, AFN ou FILE_ID ou FILE#) et du numéro de bloc relatif au fichier (block_number ou BLOCK_ID ou BLOCK#). L’ensemble est appelé DBA: Data Block Address. Le ROWID utilise cela pour identifier le bloc, et y ajoute le numéro d’enregistrement dans le bloc (ROW_NUMBER ou ROW#).

A partir d’Oracle 8, l’identification des fichiers est relative au tablespace. Cela permet de supporter plus de fichiers dans une base, et de rendre les tablespaces plus indépendants. On parle alors de numéro de fichier relatif à la tablespace (relative file_number, RFN ou RELATIVE_FNO ou RFILE#). Avec le numéro de bloc relatif au fichier, l’ensemble constitue le RDBA: Relative Data Block Address. Pour les bigfile tablespaces, ne comportant qu’un seul fichier, il s’agit seulement du block#.
Pour trouver un bloc dans la base, il est donc nécessaire de connaître aussi le tablespace. Plutôt que d’ajouter le numéro de tablespace dans le ROWID, c’est le DATA_OBJECT_ID (DATAOBJ# ou OBJD ou OBJ ou OBJECT_NUMBER) qui est utilisé. Il s’agit de l’identifiant de l’objet physique, c’est à dire du segment, contrairement à l’OBJECT_ID (OBJ# ou OBJN) qui est l’identifiant de l’objet logique. Le DATA_OBJECT_ID permet d’identifier le tablespace grâce au dictionnaire, puisque un segment se trouve dans un et un seul tablespace.
Ainsi, le ROWID ne comprends que des informations physiques pour identifier le bloc (segment, datafile, block). C’est ce qui rend optimal les tablespaces transportables ainsi que l’échange de partitions, car ils n’ont pas à modifier le contenu des blocs mais seulement les méta-données du dictionnaire.

L’ancien ROWID est appelé le Restricted ROWID, il est affiché sous la forme block#.row#.file# et celui qui inclut le data_objet_id est appelé Extended ROWID, il est affiché encodé (6 caractères pour dataobj#, 9 caractères pour file#/block#, 3 caractères pour row#).

Cet article de Jonathan Lewis explique la taille nécessaire au stockage du ROWID dans différents cas, ce qui peut être utile pour estimer la taille d’un index par exemple.

Dans une récente discussion sur le blog un article de Charles Hooper , j’ai fait un commentaire disant qu’il est difficile d’être précis et non-ambigu lorsqu’on estime l’espace nécessaire au stockage du ROWID. Je vais donc essayer d’énumérer tous les cas possible que l’on peut rencontrer. Franchement, je ne suis pas sûr d’être exhaustif dès le premier jet.

Alors, quelle place prend un ROWID ?

Disons que je suis un enregistrement d’une table normale (heap table – nous n’allons pas prendre en compte le cas des IOT, tables organisées comme des indexes, parce que leurs enregistrements sont adressés par la clé primaire et non par le ROWID). Alors je me trouve dans un bloc de données, et ce bloc enregistre dans son entête le data object id, le relative file number, et le block id. C’est la première composante de mon adresse. La seule autre ichose qui m’est nécessaire de connaître est le numéro de l’entrée que j’occupe dans la liste des enregistrements du bloc(row directory) Et comme le row directory peut contenir jusqu’à 4096 entrées, ce numéro prends 2 octets. Donc – de mon point de vue – la taille de mon rowid est de deux octets seulement.

Mais qu’en est-il des autres personnes qui ont besoin de mon adresse ? Combien d’espace doivent-ils allouer pour stocker mon ROWID ? Techniquement, ils ont besoin du data object id (pour leur permettre de trouver le numéro du tablespace), du numéro de fichier dans le tablespace (relative file number), du numéro de bloc dans le fichier (block number), et du numéro de l’entrée dans le row directory (row number). Il s’agit de 4 octets pour le data object id, 2 octets pour le row number. Le numéro de bloc et le numéro de fichier sont stockés ensembles sur 4 octets.
Il y a deux formats pour cette dernière partie:

• Pour les ‘bigfile tablespaces’ qui n’ont toujours qu’un seul fichier par tablespace, les 4 octets sont tous utilisés pour le numéro de bloc.
• Pour les tablespaces traditionnels, 10 bits sont réservés pour le numéro relatif de fichier ce qui permet jusqu’à 1022 fichiers par tablespace, et le reste est pour le numéro de bloc dans le fichier.

Donc dans le cas général, un rowid prends dix octets.

Mais différentes parties du code peuvent se comporter différemment, plus ou mois efficaces pour la gestion de l’espace.

Si mon rowid est stocké dans une autre table, dans une colonne de type ROWID (ce qui est très souvent une mauvaise idée), ou s’il est stocké temporairement dans une variable d’un programme de type ROWID alors la table ou la variable va devoir stocker les dix octets.

Pour l’utilisateur final, le rowid doit être affiché sous forme lisible de sorte que le rowid de dix octets est transformé en une chaîne de 18 caractères.

Si mon rowid doit être stockée dans un index de ma table, alors il y a plusieurs cas.

Si la table n’est pas partitionnée, alors le code interne peut déduire mon data object id du fait que l’index ne peut pointer que sur le segment de ma table. Du coup, l’index n’a pas à stocker les 4 octets du data object id.

Dans ce cas, si c’est un index unique alors le rowid est stocké comme une valeur de taille fixe, associée à la clé primaire, et il prends 6 octets. Si l’index n’est pas unique, alors le rowid est stocké comme une colonne supplémentaire à la fin de l’index. Toute valeur de colonne est précédée par un octet qui donne sa taille (length byte). Ce qui veut dire que la taille nécessaire à son stockage est de 7 octets.

Si ma table est une table partitionnée, alors la même logique de déduction du data object id peut toujours s’appliquer pour un index local: Par définition, la partition n de l’index local pointe obligatoirement vers la partition n de la table. Donc de la même manière, suivant que l’index est unique ou non, le stockage est toujours de 6 ou 7 octets.

Mais si c’est un index global ou global/partitionné, alors n’importe quelle entrée de l’index peut pointer sur n’importe quelle partition de la table. Dans ce cas, l’entrée d’index doit inclure les 4 octets du data object id de la partition dans laquelle se trouve l’enregistrement. Et dans ce cas, suivant que l’index est unique ou non, la taille du rowid est de 10 ou 11 octets.

Je pense cela couvre à peu près tous les cas. Mais si vous voulez vous creuser un peu la tête, vous pouvez réfléchir à ce qu’il se passe dans un index cluster et si cela introduit un type de rowid différent.

Cet article est la traduction d’un article de Jonathan Lewis publié sur son blog. L’article original en anglais se trouve ici.

J’ai traduit récemment un article de Doug Burns sur un concept très important lorsqu’on étudie les performances d’un système: améliorer le temps de réponse d’un traitement individuel, et améliorer le débit (throughput) d’un ensemble de traitement sont 2 objectifs différents, et souvent contradictoires.

Doug Burns donnait un exemple concret en différenciant la mesure du temps de réponse d’une session individuelle (response time) et la mesure du débit d’une charge globale (throughput). Jonathan Lewis montre ici de manière simple la théorie qu’il y a derrière. Pour aller plus loin dans la théorie, je traduirais prochainement les commentaires de Cary Millsap là dessus.

Je n’ai pas l’intention de rentrer dans la technique des files d’attentes (Queuing Theory) qui est plutôt le domaine de Cary Millsap, mais je voudrais juste donner un exemple pour montrer de quelle manière la théorie des files d’attentes (Queues) s’applique à Oracle, en répondant à la question suivante que m’a posé un client récemment:

« Comment peuvent-ils se plaindre que le temps de réponse a empiré, alors que le débit (throughput) global a augmenté de 5% ? »

La réponse malheureusement est: oui, bien sûr, le temps de réponse est peut-être pire et ceci vient justement du fait que le débit est meilleur, et je vais donner un exemple dans cette note, construit pour montrer comment cela peut se produire.

• Supposons que vous ayez une machine avec une seule CPU.
• Supposons que vous ayez deux programmes en parallèle, qui se réveillent périodiquement pour faire un certain travail.
• Le programme 1 exécute une tâche qui utilise 0,1 secondes de CPU (et aucune d’autre ressource). Il produit un résultat de N (unités de mesure de la production). Et il se réveille toutes les secondes pour s’exécuter.
• Le programme 2 exécute une tâche qui utilise 0,5 secondes de CPU (et aucune autres ressource), produit un résultat 5N (5 fois plus important que le programme 1), et se réveille toutes les cinq secondes pour s’exécuter.

Sur une durée de dix secondes, chaque programme (s’exécutant tout seul sur la machine) utilise 10% de CPU et produit 10N unités de production, et le temps de réponse est égal au temps CPU.

Mais que se passe-t-il lorsque les deux programme démarrent à peu près en même temps ?

Si vous êtes chanceux le programme 2 va commencer son travail peu de temps après que le programme 1 ne vienne de terminer le sien, et il va terminer à son tour son travail peu de temps avant le programme 1 ne recommence sa prochaine exécution.

Si vous n’avez pas cette chance les deux programme vont commencer à faire leur travail en même temps, et un seul d’entre eux aura la CPU. A ce moment là, une machine typique va utiliser des tranches de temps pour faire comme si les 2 programme s’exécutaient simultanément. Donc les 2 programme vont commencer à s’échanger la CPU (context switching), disons toutes les 0,01 secondes. La conséquence de cela (à peu près), c’est que le programme 1 va terminer son travail au bout de 0,2 secondes (0,1 pour travailler en CPU et 0,1 pour attendre) et que le programme 2 va terminer son travail au bout de 0,6 secondes (0,5 secondes de CPU et 0,1 d’attente – puisque le programme concurrent a passé 0,1 seconde en CPU).

Les temps de réponse se sont dégradés, et de manière spectaculaire dans le cas du programme 1. Nous avons beaucoup de CPU inutilisée (80%, en fait), mais le temps de réponse de chaque job va être très variable en fonction du moment ou arrivent les jobs.

Dans le cas de mon client, il y avait beaucoup plus de programme comme le programme 1 qui étaient en train de d’exécuter, et qui faisaient passer beaucoup plus de tâches de 0,1 secondes en utilisant la capacité disponible de la machine. Donc le débit (throughput) était amélioré, mais cela augmentait la probabilité que ces programme entre en collision avec celui de 0,5 secondes (ou même entre eux) et donc le temps de réponse individuel s’est dégradé.

Pour passer de mon exemple trivial à un modèle plus réaliste correspondant au monde réel, vous avez besoin de la théorie des files d’attentes (queuing theory). J’ai rendu mon exemple aussi simple que possible avec un taux d’arrivée fixe, pour deux tâches de durée fixe, se déclenchant à intervalles réguliers. Pour modéliser le monde réel, vous devez prendre en compte des tâches de durée variable, qui arrivent à des intervalles répartis de manière aléatoire – et les calculs seront alors un peu plus complexes.

Mais vous n’avez pas besoin de ces détails mathématiques pour en comprendre les conséquences importantes:

• le temps de réponse peut varier considérablement en fonction de l’heure d’arrivée, et ce même si la machine est loin chargée au maximum,
• et temps de réponse peut se détériorer, même si (ou peut-être parce que) le débit s’améliore.

Pour de plus amples commentaires sur le dilemme temps de réponse/débit, voir cet article par Doug Burns .