Cet article est la traduction d’une réponse de Tom Kyte sur son site AskTom décrivant rapidement les points à considérer lorsqu’on a une table a fort volume transactionnel et forte concurrence (L’article original en anglais se trouve ici).

Question

Que puis-je faire du point de vue du design physique pour maximiser les performances et la concurrence lorsque une table va être la cible de centaines de milliers de select et probablement autour de 80000 insert, autant d’update et delete par heure, de manière transactionnels sur une base OLTP.
Ces débits de insert/update/delete sont juste un exemple. En réalité ils seront beaucoup plus élevés, même si on ne sait pas à quel point ils seront plus élevés car nous sommes toujours en phase de design.

Je suis à la recherche de quelques lignes directrices que je pourrais essayer sur mon application.

Réponse

On pourrait écrire un livre là dessus Le mien est ‘Expert Oracle Database Architecture’ et vous serez surement intéressé par de nombreux chapitres, plus particulièrement ceux sur les types de données, les tables et les index.

• Vous pourriez avoir besoin de partitionner: répartir les inserts sur de nombreux segments, afin d’éviter des contentions sur la partie droite des index (sur les dates ou les séquences par exemple)…
• Vous pourriez avoir besoin d’IOT (tables organisées index), plus lent pour les insert dans la plupart des cas, mais si vous faites des requêtes qui ramènent de nombreuses lignes qui sont arrivées dans la table à des moments différents dans le temps, l’IOT peut permettre de regrouper (cluster) ces lignes afin de rendre plus efficace le fait de les récupérer ensembles.
• Vous pourriez aussi utiliser ASSM (Automatic segment space management) pour améliorer la concurrence, pour éviter de chercher les bonnes valeurs de PCTUSED, FREELISTS et FREELIST GROUP (mais vous devez comprendre ce qu’il y a de différent entre ASSM et MSSM…)
• Vous pourriez chercher à comprendre comment les types de données sont stockés physiquement, réfléchir à PCTFREE, et comment maximiser les performances possibles sur les LOB, si vous les utilisez, etc.

En bref, vous voulez comprendre comment fonctionnent les choses à un certain niveau. Le concepts guide de la documentation Oracle et un bon point de départ. Si vous aimez ma manière d’écrire, vous pouvez commencer aussi par ‘Expert Oracle Database Architecture’.

Vous aurez besoin de réfléchir à la concurrence, aux choses comme ASSM, le partitionnement, voire les technique de regroupement de données (clustering): IOT, hash/btree clusters.

Vous aurez besoin de réfléchir sur l’archivage des données dans le temps.

Vous devrez peut-être envisager la nécessité de faire une réorganisation des tables à l’occasion, et donc prévoir le design qui permettra de le faire: à nouveau le partitionnement.

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 →

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:

• Ecritures cohérentes, par Tom Kyte (1ère partie)
• Ecritures cohérentes – observation d’un redémarrage (2ème 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 →

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:

• Lectures cohérentes et multi-versionnage, par Tom Kyte
• Statistiques ‘db block gets’ et ‘consistent gets’, par Jonathan Lewis

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 →

Cet article est la traduction d’une réponse Tom Kyte à une question sur les vues cohérentes (L’article original en anglais se trouve ici).

Question:

J’ai lu qu’Oracle garantit une vue cohérente en lecture. Je l’ai lu, mais je n’ai pas l’impression que c’est très clair.
Pouvez-vous expliquer, avec vos mots, ce qu’est une vue cohérente ?

Réponse:

J’ai fais cela dans « Expert One on One Oracle« .
J’ai écrit beaucoup là dessus et voici un court extrait (il y a beaucoup plus dans le livre).

Extrait de ‘Expert One on One Oracle’ de Tomas Kyte – Apress

Multi-Versionnage et Concurrence

Le Multi-versionnage (multiversioning) est un sujet lié au contrôle de concurrence d’accès aux données, car qu’il est à la base de ce mécanisme: Oracle implémente la concurrence d’accès en faisant des lecture multi-versions cohérentes (multi-version read consistent concurrency model). Dans le chapitre suivant ‘Ce que vous devez savoir’, nous allons parler des aspects techniques de manière plus détaillée, mais dans l’essentiel, il s’agit du mécanisme fourni par Oracle pour:

• faire des lectures cohérentes (Read-consistent queries): les requêtes donnent un résultat cohérent à un instant donné.
• Requêtes non bloquantes (Non-blocking queries): les requêtes en lecture ne sont jamais bloquées par les écritures, contrairement à ce qui se passe avec d’autres SGBD.

Lire la suite →