La vue de performance dynamique V$REDO_DEST_RESP_HISTOGRAM est un outil essentiel pour les administrateurs de bases de données Oracle (DBA) souhaitant diagnostiquer les performances du transport des journaux Redo. Elle fournit une répartition statistique, sous forme d'histogramme, du temps de réponse pour chaque destination d'archivage, qu'elle soit locale ou distante (Data Guard).

1. Structure et colonnes principales

Cette vue permet de visualiser comment les temps de réponse se répartissent dans différents "buckets" temporels. Voici une description des colonnes clés :

Note technique : La valeur TIME = 5 signifie que l'intervalle couvre les réponses allant jusqu'à 50 millisecondes.

2. Cas d'utilisation critiques

• Diagnostic Data Guard : Identifier si la latence réseau ou disque sur le site de secours impacte la base primaire.
• Optimisation du mode SYNC : En mode de transport synchrone, chaque transaction attend la confirmation de la destination. L'histogramme permet de voir si des pics de latence ralentissent les commits.
• Évaluation du stockage : Comparer les performances d'écriture entre les disques locaux et les serveurs d'archivage distants.

3. Requêtes SQL d'enalyse

A. Vue d'ensemble de la distribution par destination

Cette requête formate les données pour rendre les seuils de temps lisibles en millisecondes.

SELECT 
   dest_id AS id_dest,
   time * 10 AS seuil_ms,
   count AS nb_operations,
   frequency AS frequence_pct,
   cumulative_frequency AS cumul_pct
FROM v$redo_dest_resp_histogram
WHERE count > 0
ORDER BY dest_id, time;

B. Identification des goulots d'étranglement (latence > 500ms)

Pour isoler les lenteurs significatives qui pourraient affecter les performances globales, on peut agréger les données sur les seuils élevés.

SELECT 
   dest_id,
   SUM(CASE WHEN time * 10 >= 500 THEN count ELSE 0 END) AS ralentissements_majeurs,
   ROUND(AVG(time * 10), 2) AS latence_estimee_moyenne
FROM v$redo_dest_resp_histogram
GROUP BY dest_id
HAVING SUM(CASE WHEN time * 10 >= 500 THEN count ELSE 0 END) > 0;

C. Rapport de performance catégorisé

Ce script segmente les performances en catégories (Rapide, Moyen, Lent) pour faciliter l'interprétation par les équipes d'exploitation.

SELECT 
   dest_id,
   CASE 
       WHEN time * 10 <= 20 THEN '0-20ms (Rapide)'
       WHEN time * 10 <= 100 THEN '21-100ms (Normal)'
       WHEN time * 10 <= 1000 THEN '101ms-1s (Lent)'
       ELSE '>1s (Critique)'
   END AS categorie_latence,
   SUM(count) AS total_obs
FROM v$redo_dest_resp_histogram
WHERE dest_id IS NOT NULL
GROUP BY 
   dest_id, 
   CASE 
       WHEN time * 10 <= 20 THEN '0-20ms (Rapide)'
       WHEN time * 10 <= 100 THEN '21-100ms (Normal)'
       WHEN time * 10 <= 1000 THEN '101ms-1s (Lent)'
       ELSE '>1s (Critique)'
   END
ORDER BY dest_id, total_obs DESC;

4. Mécanismes internes et architecture

Le transport Redo repose sur des processus spécifiques :

• LNS (Log Network Server) : Envoie les données vers les destinations distantes en mode synchrone ou asynchrone.
• ARCH (Archiver) : Gère l'archivage local et distant des fichiers redo logs remplis.

Les données de V$REDO_DEST_RESP_HISTOGRAM proviennent directement des structures en mémoire de l'instance (SGA), plus précisément des tables internes X$. Ces compteurs sont réinitialisés à chaque redémarrage de l'instance Oracle. Pour une analyse historique, il est recommandé de capturer ces données périodiquement via des snapshots personnalisés.

5. Recommandations pour l'administration

Lors de l'analyse des résultats, gardez à l'esprit les points suivants :

1. Transport Synchrone vs Asynchrone : Une latence élevée dans cet histogramme est beaucoup plus dommageable en mode SYNC, car elle se répercute directement sur le temps de réponse des utilisateurs (Wait Event LGWR any worker group ou LNS wait on SENDREQ).
2. Impact Réseau : Si une destination distante présente une répartition vers la droite (temps longs) alors que la destination locale est rapide, le réseau est le suspect principal.
3. Saturation I/O : Si toutes les destinations, y compris locales, montrent des temps de réponse élevés, le sous-système de stocakge est probablement saturé.