Fragmentation РTable, par Jonathan Lewis (3̬me partie)

Publié le par
Répondre

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.
Lire la suite →

Fragmentation – Introduction, par Jonathan Lewis

Publié le par
Répondre

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:

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.
Lire la suite →

Fragmentation РDisque et Tablespace, par Jonathan Lewis (2̬me partie)

Publié le par
Répondre

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.
Lire la suite →

Niveaux d’isolations, par Tom Kyte

Publié le par
1

Cet article est la traduction d’un article de Tom Kyte publié dans Oracle Magazine en Novembre 2005. L’article original en anglais se trouve ici.
Il peut être utile de lire avant Lectures cohérentes et multi-versionnage (traduit aussi de Tom Kyte).

Question posée sur AskTom:

J’ai lu le manuel ‘Database Concepts’ de la documentation Oracle, au chapitre « Data Concurrency and Consistency » mais je n’ai pas vraiment compris la différence entre les niveaux d’isolation serializable et read-committed. Pouvez-vous donner des exemples qui expliquent cela clairement ?

Réponse de Tom Kyte:

Avant de lire ce qui suit, vous pouvez aller voir l’article d’Oracle Magazine de Mai/Juin 2005 (en anglais) où je décris la fonctionnalité que j’ai toujours préféré dans Oracle: le multi-versioning. Sa compréhension est cruciale pour réussir avec Oracle, mais il vous aidera aussi à comprendre les concepts décrits ci dessous. (Voir la traduction d’un article similaire ici)

[La suite est un extrait de ‘Expert Oracle Database Architecture: 9i and 10g Programming Techniques and Solutions‘]

Lire la suite →

Fonctionnalités Objet-Relationnel d’Oracle, par Tom Kyte

Publié le par
2

Cet article est la traduction d’une réponse Tom Kyte à des questions sur les fonctionnalités Objet-Relationnel d’Oracle
(L’article original en anglais se trouve sur AskTom ici).

Tom Kyte donne son avis sur l’utilisation de ces fonctionnalités (Tables Relationnelles, vues Objet-Relationnel, Tables Objet-Relationnel)

Question:

Bonjour Tom,

J’ai quelques questions sur les fonctionnalités Objet-Relationnel d’Oracle.

J’ai la structure suivante:
Lire la suite →

Ecritures coh̩rentes Рcons̩quences pour le d̩veloppeur, par Tom Kyte (3̬me partie)

Publié le par
Répondre

Cet article est la traduction d’un article de Tom Kyte sur son blog (L’article original en anglais se trouve ici).
Lectures cohérentes et multi-versionnage, par Tom Kyte


Il est conseillé lire préalablement les premières partie:

La première chose qui vient à l’esprit, c’est que le trigger se déclenche deux fois. On avait une table avec une seule ligne, et un trigger BEFORE FOR EACH ROW qui se déclanche pour chaque ligne. Un a fait un update sur une seule ligne et le trigger s’est déclanché deux fois.

Vous devez penser aux conséquentes de cela. Si vous faites dans votre trigger quoi que ce soit qui ne soit pas transactionnel, vous pouvez avoir un problème assez sérieux.
Lire la suite →

Ecritures cohérentes – observation d’un redémarrage, par Tom Kyte (2ème partie)

Publié le par
Répondre

Cet article est la traduction d’un article de Tom Kyte sur son blog (L’article original en anglais se trouve ici).


Il est conseillé lire préalablement la première partie:

Voir un redémarrage d’une requête update est plus plus facile qu’on ne pense.
En fait, nous allons même en voir un avec une simple table d’une seule ligne.
Lire la suite →

Ecritures cohérentes, par Tom Kyte (1ère partie)

Publié le par
Répondre

Cet article est la traduction d’un article de Tom Kyte sur son blog (L’article original en anglais se trouve ici). L’article est en 3 parties (il s’agit ici de la partie 1) et il est extrait de son livre Expert Oracle Database Architecture.

Il peut être utile de (re)lire avant:

Nous avons étudié précédemment (en français ici) la lecture cohérente: la capacité d’Oracle à utiliser les informations d’undo pour fournir des requêtes non-bloquantes et cohérentes (c’est à dire correctes) pour une lecture. Nous savons que lorsque Oracle lit des blocs pour notre requête, dans le buffer cache, il s’assure que la version du bloc est assez ‘vieille’ pour que notre requête puisse le voir.

Mais cela soulève la question suivante: Qu’en est-il des écritures/modifications ? Qu’est-ce qui se passe lorsque vous exécutez l’instruction UPDATE suivante: UPDATE T SET X = 2 WHERE Y = 5;
et que, pendant que cette requête est en cours d’exécution, quelqu’un modifie une ligne en faisant passer la valeur de Y de 5 vers 6, et commite cette modification, avant que nôtre requête n’ait lu cette ligne ?

Autrement dit, lorsque votre mise à jour a commencé, certaines lignes ont Y=5. Et comme votre mise à jour fait des lectures cohérentes, elle voit pour cette ligne Y=5, puisque c’est la valeur qu’il y avait au moment où votre update a démarré. Cependant, la valeur actuelle de Y est maintenant 6, et non plus 5, et avant de mettre à jour la valeur de X, Oracle va vérifier si la valeur de Y est toujours 5. Maintenant que doit-il se passer ? Et comment cela impacte les update ?

De toute évidence, nous ne pouvons pas modifier une ancienne version d’un bloc: quand on va modifier une ligne, il faut modifier la version actuelle du bloc. En outre, Oracle ne peut pas simplement ignorer cette ligne, car ce serait une lecture incohérente et imprévisible. Ce que nous allons découvrir, c’est que dans ce cas, Oracle va redémarrer à zéro l’écriture des modification.
Lire la suite →

Verrous et signification du mode (lock mode), par Jonathan Lewis

Publié le par
Répondre

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.

Lire la suite →

Le ROWID et la place qu’il prend, par Jonathan Lewis

Publié le par
Répondre

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 ?
Lire la suite →