Collecte et analyse des journaux des requêtes

• Accès aux journaux des requêtes
• Niveau de journalisation des requêtes
• Lecture d'un journal de requête
  • Requête SQL logique
  • Demande logique
  • Plan d'exécution
  • Demandes physiques ou de base de données
  • Statistiques récapitulatives
• Remarques relatives aux journaux des requêtes
• Accès aux journaux des requêtes d'un classeur

Accès aux journaux des requêtes

Niveau de journalisation des requêtes

• Le niveau de journalisation détermine les détails et la quantité de journaux générés.

• Vous pouvez définir le niveau de journalisation au niveau du système, de la session ou du rapport.

• Vous pouvez définir le niveau de journalisation global de votre modèle sémantique (RPD) à l'aide de la propriété Niveau de journalisation système (sous Outils, Option, Référentiel) ou utiliser la variable de session.

  
  .jpg

• Vous pouvez remplacer le niveau de journalisation d'un rapport en ajoutant la variable LOGLEVEL à la propriété Préfixe, disponible dans l'onglet Avancé du rapport.

• Pour vous assurer que vous obtenez des journaux complets en évitant les accès réussis au cache, vous pouvez inclure la variable DISABLE_CACHE_HIT=1 avec LOGLEVEL.

  
  .jpg

• Les valeurs du niveau de journalisation (LOGLEVEL) sont comprises entre 0 et 7.

  • LOGLEVEL=0 signifie que la journalisation est désactivée.
  • LOGLEVEL=7 est le plus haut niveau de journalisation, utilisé principalement par l'équipe de développement d'Oracle.
  • LOGLEVEL=2 convient au réglage des performances et aux utilisateurs disposant de compétences de base.
  • LOGLEVEL=3 est requis pour résoudre les problèmes relatifs aux filtres de sécurité de données au niveau des lignes.

• En fonction du niveau de journalisation, le journal de requête contient des informations sur la requête, notamment la demande logique, le plan de navigation et d'exécution, la requête physique générée, la durée d'exécution, les lignes et les octets extraits au niveau des différents noeuds d'exécution ainsi que des informations relatives au cache.

Les administrateurs peuvent extraire les journaux des requêtes à partir de la page Emettre une requête SQL de la console en exécutant la requête avec la variable LOGLEVEL et les paramètres de variable appropriés.

Lecture d'un journal de requête

La page Session et cache de requête répertorie toutes les requêtes et sessions actuellement actives. Les administrateurs peuvent accéder à cette page à partir de la console.

Chaque entrée sur la page fournit un accès au journal de requête d'une requête en particulier, au niveau défini (c'est-à-dire au niveau du modèle sémantique, de la session ou du rapport).

.jpg

Chaque demande dispose d'une valeur requestid unique dans Oracle Analytics.

Requête SQL logique

Voici un exemple de requête SQL logique dans Oracle Analytics.

Voici quelques variables courantes que vous pouvez voir dans une demande SQL logique :

• QUERY_SRC_CD : origine de la requête (Invite, Rapport, DV, Emettre une requête SQL, etc.).
• SAW_SRC_PATH : si la requête est enregistrée, chemin de la requête dans le catalogue.
• SAW_DASHBOARD : si la requête est incluse dans un tableau de bord, chemin du tableau de bord dans le catalogue.
• SAW_DASHBOARD_PG : nom de la page du tableau de bord.

Demande logique

La demande logique est la transposition d'une requête de la couche de présentation vers le modèle de gestion et la couche de correspondance après avoir ajouté des filtres de sécurité, le cas échéant.

En fonction de la demande logique, Oracle Analytics détermine si la requête accède à un cache existant ou si elle doit être extraite de la base de données.

Plan d'exécution

Le plan d'exécution est la transformation de la demande logique réelle en un plan optimisé pour l'exécution. Il inclut un plan d'envoi pour chaque opération et détermine si l'exécution est réalisée dans la base de données ou dans Oracle Analytics. Lorsqu'une opération est traitée dans Oracle Analytics, le journal de requête indique [for database 0:0,0].

Lors de l'exécution de la requête, Oracle Analytics parcourt précisément cette arborescence. Dans les journaux détaillés, les informations sur les lignes traitées sont disponibles au niveau de chaque noeud de l'arborescence d'exécution.

Demandes physiques ou de base de données

En fonction du plan d'exécution, Oracle Analytics génère la requête SQL physique à exécuter dans la base de données indiquée. Plusieurs demandes peuvent être envoyées à plusieurs bases de données.

Pour chaque demande physique envoyée à la base de données, il existe un journal contenant le nombre de lignes et d'octets extraits.

Lorsqu'il existe plusieurs requêtes, vous pouvez utiliser l'ID de requête (dans cet exemple, 1914627) pour rechercher la requête exacte journalisée dans la section Sending query to the database. Vous pouvez ainsi mettre en correspondance la requête avec les lignes extraites lorsqu'il existe plusieurs demandes de base de données.

Un seul rapport peut envoyer plusieurs requêtes à plusieurs bases de données en fonction de sa structure et de la définition de modèle sémantique. Par exemple, dans ce journal de requête, 3 requêtes physiques ont été envoyées à la base de données.

Le journal fournit des informations similaires sur les lignes traitées pour tous les noeuds du plan d'exécution. Enfin, les lignes envoyées au client sont journalisées.

Le journal inclut également un récapitulatif final des statistiques avec la durée d'exécution totale. Vous pouvez mettre en corrélation cette durée pour analyser et étudier les problèmes de performances.

Statistiques récapitulatives

Remarques relatives aux journaux des requêtes

• Activité monothread. Dans des circonstances défavorables, vous pouvez constater un goulet d'étranglement des performances pour les niveaux de journalisation supérieurs à 2.

• Les heures répertoriées et calculées correspondent au moment où les entrées sont écrites dans le journal et il s'agit presque toujours du moment où l'événement survient (c'est-à-dire, l'activité à l'origine de l'entrée de journal). Sinon, d'autres goulets d'étranglement peuvent avoir une incidence sur la journalisation.

• La journalisation des requêtes est un outil de diagnostic et n'est pas conçue pour la collecte d'informations sur l'utilisation. Pour en savoir plus sur le suivi de l'utilisation, reportez-vous à Suivi de l'utilisation.

Accès aux journaux des requêtes d'un classeur

Seuls les administrateurs peuvent accéder aux journaux via la page Session et cache de requête de la console. Cependant, les auteurs de contenu peuvent accéder aux informations de journal des requêtes de visualisation dans leurs classeurs par le biais du menu Développeur. Il s'agit d'un outil utile pour les auteurs qui veulent résoudre les problèmes de performances de requête. Afin d'accéder à l'outil de performances pour les classeurs (option de menu Développeur), les utilisateurs doivent activer Activer les options de développeur dans le menu Avancé sous Mon profil.

Lorsque l'option est activée, l'option de menu Développeur apparaît dans le menu du classeur.

L'option Développeur permet aux utilisateurs d'afficher et d'analyser à la volée divers journaux pour toute visualisation sur un canevas. Un cadre distinct apparaît sous le canevas avec différents onglets pour chaque type d'information. Par défaut, les journaux ne sont pas remplis ni actualisés lors de l'exécution de la visualisation.

Sélectionnez la visualisation à analyser et cliquez sur Actualiser pour générer les journaux. Une fois la visualisation actualisée, différentes informations la concernant apparaissent et vous pouvez analyser les informations de journal correspondantes. Pour analyser plusieurs visualisations, vous devez les actualiser individuellement et les analyser les unes après les autres.