Les principes fondamentaux d’un datawarehouse – Le Partitionnement, par Greg Rahn

Publié le par
1

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 →

Performance: Temps de réponse vs. Débit, par Cary Millsap

Publié le par
Répondre

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

Courbe charge/temps de réponse

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 →

Temps passé en file d’attente, 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.

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 →

Performance: Mesurer le temps de réponse ou le débit, par Doug Burns

Publié le par
Répondre

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 →

Construire des requêtes SQL efficaces: Une approche visuelle, d’après Jonathan Lewis

Publié le par
Répondre

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 →

Compression SQL*Net, 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.

Il montre un fonctionnalité peu connue: la compression des données transférées par SQL*Net lorsque il y a répétition de valeurs d’une ligne à l’autre. Et l’avantage de récupérer ces données triées sur ces colonnes répétitives.

Voici une petite démonstration que j’avais l’intention d’écrire depuis ces dernières années.
C’est très simple: je crée une table, et je l’interroge plusieurs fois.

Lire la suite →

Opération INDEX JOIN (jointure entre indexes), par Franck Pachot

Publié le par
Répondre

En général lorsqu’il y a plusieurs indexes qui peuvent répondre aux prédicats d’une requête, Oracle va choisir l’index le plus selectif, et les autres conditions seront vérifiées au moment d’aller lire l’enregistrement complet dans la table.
Ceci peut nous amener à créer un index concaténé, en combinant toutes les colonnes sur lesquelles il y a des prédicats, afin que l’index soit plus sélectif.

Mais ajouter un index a un coût et va pénaliser les insert/deletes ainsi que les updates qui touchent aux colonnes indexées.

Il y a cependant des cas où Oracle peut combiner deux indexes.
C’est le cas par exemple des indexes bitmap. On peut avoir un index bitmap sur chaque colonne, et Oracle va combiner les bitmaps avant d’aller voir la table (en utilisant des opérateurs binaire AND et OR sur les bitmaps). Mais ce n’est pas le sujet de cet article.

Il y a aussi un cas particulier avec les indexes ‘normaux': c’est le chemin d’accès ‘INDEX JOIN‘: les 2 indexes sont lus, et sont réunis, comme si l’on faisait une jointure sur le rowid, et la sortie de cette opération est équivalente à un index qui contiendrait toutes les colonnes.

Voici un exemple de cette opération ‘index join’, le but de cet exemple était de répondre à la question suivante, sur le forum dba-village: ‘Que signifient les indexes index$_join$_9 et index$_join$_8′ dans un plan d’exécution, et ‘comment les remplacer par mes propres indexes ?‘
Lire la suite →

Paramétrage optimal pour PCTFREE, PCTUSED et INITRANS, par Tom Kyte

Publié le par
Répondre

Cet article est la traduction d’une réponse Tom Kyte à une question sur le paramétrage idéal de PCTFREE, PCTUSED et INITRANS (L’article original en anglais se trouve ici).

PCTFREE

Si vous avez une table qui ne subit que des inserts, mettez PCTFREE à 0, parce que vous n’avez rien à réserver pour les updates.

si vous savez une table dont les lignes doublent de taille, c’est une bonne idée de mettre PCTFREE à 50, pour réserver de la place pour les updates.

Vous devez comprendre comment les données grossissent dans le temps. Si vous faites des inserts, puis sur 10% de ces lignes vous faites des updates qui augmentent leur taille de 20%, alors vous devez:

  • savoir combien de lignes par bloc vous avez en moyenne
  • calculer ce que les 20% d’une ligne représentent en pourcentage de bloc.
  • utiliser ce pourcentage de bloc comme PCTFREE

PCTUSED

Et utilisez ASSM (automatic segment space management), la gestion automatique de l’espace libre des segments, et vous n’avez pas à vous soucier de PCTUSED, FREELISTS, FREELIST GROUPS.

INITRANS

Pour INITRANS, vous devez vous baser sur le nombre maximum de modifications concurrentes qu’il peut y avoir sur un bloc. Si vous avez une table qui ne reçoit que des inserts, et que vous êtes en ASSM, ne vous inquiétez pas et laissez la valeur par défaut. Si vous avez plutôt une petite table que vous updatez comme un fou, alors vous devez y réfléchir.
Lire la suite →

Description du mode de backup à chaud (BEGIN BACKUP), par Franck Pachot

Publié le par
Répondre

Ce document tente d’expliquer exactement ce qui arrive lorsque vous utilisez ALTER TABLESPACE ... BEGIN BACKUP et ALTER TABLESPACE  ...  END BACKUP, et pourquoi il est obligatoire de l’utiliser lorsque la sauvegarde à chaud se fait avec un outil qui est extérieur à Oracle (tels que les sauvegardes faites à partir de l’OS utilisant cp, tar, la BCV, etc)
Il donne également une réponse aux questions suivantes, fréquemment posées:

  • Est-ce qu’ Oracle continue d’écrire dans les fichiers (datafiles) lorsque la tablespace est en mode backup ?
  • A quoi sert la commande ALTER DATABASE BEGIN BACKUP ?
  • Pourquoi le mode backup n’est pas utilisé avec RMAN ?
  • Que se passe-t-il si vous faites une sauvegarde sans avoir fait le BEGIN BACKUP ?
  • Que faire si l’instance se plante alors que vous êtes en mode backup ?
  • Comment vérifier quels datafiles sont en mode backup ?
  • Quels sont les archive logs minimum à garder avec la sauvegarde à chaud?
  • Pourquoi utiliser des backups par des commandes OS au lieu de RMAN?
  • Pourquoi la commande BEGIN BACKUP peut prendre du temps ?

Lire la suite →