Catégories: Méthode, Conception (design), Datawarehouse, Performance (tuning)

Il n'a a pas eu beaucoup d'articles traduits ces derniers mois. Pour patienter, voici un lien sur une présentation:
Interpreting AWR Report - Straight to the Goal en anglais, mais très visuel...

C'est parfois difficile d'aborder un rapport AWR ou Statspack qui comprends 50 pages de statistiques, dont seulement quelques unes sont utiles dans un contexte donné. J'ai vu plusieurs personnes qui ne savent pas vraiment par où commencer. Et sans une approche méthodique, c'est facile de perdre du temps sur des choses qui ne feront pas gagner un un temps significatif dans l'amélioration du temps de réponse.

Cette présentation montre une approche méthodique: en partant du temps passé en base de données (DB time) pour voir si le rapport est pertinent ou pas, puis en prenant les éléments du 'Top 5 events' en montrant où aller chercher les détails qui permettent de comprendre la raison d'un problème de performance, comment le résoudre, et estimer le gain en temps de réponse que peut apporter la résolution.

Cet article est la traduction d'un article de Greg Rahn publié sur son blog. L'article original en anglais est: The Core Performance Fundamentals Of Oracle Data Warehousing – Set Processing vs Row Processing. Cet article fait partie d'une série sur les principes fondamentaux des datawarehouse, mais s'applique à tous les traitements de type batch.

Durant 6 ans à faire des Proof Of Concept et des Benchmarks sur des datawarehouse pour les clients, il y a un domaine qui s'est toujours montré problématique: les traitements par lots (batch). La plupart du temps, ces batchs prennent la forme de procédures et packages PL/SQL, qui font du chargement de donnée, de la transformation, du traitement, ou quelque chose de similaire.
La raison pour laquelle c'est souvent problématique, c'est que les développeurs y ont codé en dur la lenteur du traitement. Je suis certain que les développeurs ne savaient pas qu'ils faisaient cela, lorsqu'ils ont codé leur PL/SQL, mais en tout cas, c'est ce qui est arrivé.

Alors comment ont-ils codé 'en dur' cette lenteur en PL/SQL ?

» Lire la suite!

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'un article de Greg Rahn publié sur son blog. L'article original en anglais est:The Core Performance Fundamentals Of Oracle Data Warehousing – Partitioning. Cet article fait partie d'une série sur les principes fondamentaux des datawarehouse.

Le partitionnement est une fonctionnalité majeure pour les performance d'un datawarehouse sous Oracle, car l'élagage des partition (partition pruning) va la plupart du temps faire en sorte qu'il y ait moins de données à lire sur une table. Le résultat, c'est qu'il y a besoin de moins de ressources système, et que les requêtes sont plus performantes.
Quelqu'un m'a dit un jour "les I/O les plus rapides sont ceux que l'on ne fait jamais" C'est précisément la raison pour laquelle le partitionnement est ce qu'il y a de mieux pour un datawarehouse: il permet de réduire les I/O.
Je parle souvent de l'élagage des partitions (partition pruning) comme d'un anti-index. Un index est utilisé pour trouver la faible quantité de données qui est nécessaire, alors que le partitionnement est utilisé pour éliminer une grande quantité de données qui n'est pas nécessaire.

Principales utilisations du partitionnement

Je vois quatre raisons pour l'utilisation du partitionnement dans un datawarehouse Oracle:

• Élimination de données
• Jointures partition par partition (Partition-Wise Joins)
• Maintenabilité (chargements par échange de partitions, indexes locaux, etc.)
• Cycle de vie des données (Information Lifecycle Management - ILM)

» Lire la suite!

Cet article est la traduction d'un article de Cary Millsap publié sur son blog. L'article original en anglais est:Throughput versus Response Time. C'est un commentaire sur l'article de Doug Burns Time Matters: Throughput vs. Response Time. Cary Millsap est un spécialiste de la performance, du tuning Oracle et a beaucoup écrit sur les files d'attentes.

J'ai apprécié le post de Doug Burns Performance: Mesurer le temps de réponse ou le débit sur son blog. Si vous ne l'avez pas encore lu, vous devriez. L'article et les commentaires sont excellents.
La courbe de rendement (temps de réponse en fonction de la charge du système) fait un coude, au point où le temps de réponse, presque constant, devient tout d'un coup exponentiel lorsque le système atteint une certaine charge.

Exemple de courbe de rendement tiré de Optimizing Oracle performance
- En abscisse (ρ): la charge (ou utilisation),
- En ordonnée (R): le temps de réponse.
- Les 3 courbes correspondent à un degré de parallélisme de 1,2 et 8

Le 'coude' ('knee'), est le point correspondant à la charge pour laquelle le rapport temps de réponse / utilisation est minimal.
Il peut être déterminé aussi par la tangente à la courbe, passant par le point d'origine des axes.
Ce 'coude' se décale vers la droite lorsque le degré de parallélisme augmente.

» Lire la suite!

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.

» Lire la suite!

Cet article est la traduction d'un article de Doug Burns publié sur son blog. L'article original en anglais se trouve ici.
C'est une réflexion sur la principale métrique de performance: le temps de réponse, ou le débit (nombre de transaction par unité de temps) en fonction de ce qui est étudié: requête d'une session individuelle, ou charge globale d'un système (workload).

J'ai été incité à écrire cet article a la suite du commentaire suivant que Niall Litchfield a fait dans un email:
"... Je remarque qu'une fois qu'on commence à définir une charge globale de travail (workload), ou un ensemble de transactions, dans des termes métier (du genre 'j'ai besoin d'effectuer toutes ces choses, qu'est-ce qui marche le mieux ?') alors le temps de réponse de la charge de travail complète ^* a un sens, d'une part comme métrique, mais surtout comme un objectif de tuning. J'ai l'impression que depuis ces 10 dernières années, les discussions sur les performances se font autour des requêtes, ou de l'optimisation d'une session, en supposant que si on améliore les performances d'une requête particulière, alors on va aussi améliorer la charge de travail complète, telle que le voit le métier. C'est souvent vrai, mais c'est souvent faux aussi. Les mesures de performances seront toujours basées sur le temps de réponse, mais il pourrait y avoir des d'autres méthodes de tuning. Ça pourrait être aussi simple que de définir la première étape du tuning comme 'Définir la charge de travail (workload) la plus importante important pour le métier' au lieu de 'définir la tâche importante pour le métier'

Je suis d'accord avec Niall, particulièrement sur le fait actuellement on met plus l'accent sur l'optimisation de sessions individuelles, ou des requêtes isolées, plutôt que l'optimisation de la charge de travail globale.

Je vais dire cela d'une autre manière: si vous essayez d'avoir le meilleur débit pour toute la charge de travail (workload throughput) alors l'objectif le plus important n'est peut être pas le meilleur temps de réponse d'une session individuelle.C'est pourquoi j'ai quelques slides d'un cours que j'ai écris auparavant pour Oracle et qui définissent plusieurs façons d'évaluer les performances du système, incluant:

• le temps de réponse (response time)
• le débit (throughput)
• et l'évolutivité (scalability)

» Lire la suite!

Cet article est la traduction d'un article de Jonathan Lewis. L'article original en anglais se trouve ici. J'ai cependant traduit l'exemple de requête dans une syntaxe Oracle, et l'idée d'index cluster de SQL Server correspond à celle d'IOT sous Oracle.
Jonathan Lewis décrit ici une démarche visuelle pour comprendre une requête SQL en faisant un schéma des tables impliquées.

C'est parfois intéressant de s'éloigner du clavier lorsqu'on se bat avec une requête peu performante et assez complexe, et de prendre un papier et un crayon à la place. En faisant un schéma qui montre les tables impliquées, les jointures, les volumes de données manipulées, et les indexes, vous pourrez comparer plus facilement l'efficacité des différents chemins d'exécution que la requête peut prendre pour passer d'une table à une autre.

» Lire la suite!