Regrouper et analyser les journaux d'interrogations

• Accès aux journaux d'interrogations
• Niveaux de journalisation d'interrogation
• Lecture d'un journal d'interrogation
  • Interrogation SQL logique
  • Demande logique
  • Plan d'exécution
  • Demandes physiques ou de base de données
  • Statistiques sommaires
• Points à considérer pour le journal d'interrogation
• Accès aux journaux d'interrogations pour un classeur

Accès aux journaux d'interrogations

Niveaux de journalisation d'interrogation

• Le niveau de journalisation détermine les détails et la quantité de données du journal généré.

• 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 pour votre modèle sémantique (RPD) à l'aide de la propriété Niveau de journalisation du 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 être certain d'obtenir des journaux complets en évitant les présences dans la mémoire cache, vous pouvez inclure la variable DISABLE_CACHE_HIT=1 à côté de LOGLEVEL.

  
  .jpg

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

  • LOGLEVEL=0 signifie que la journalisation est désactivée.
  • LOGLEVEL=7 est le niveau de journalisation le plus élevé. Il est utilisé principalement par l'équipe de développement d'Oracle.
  • LOGLEVEL=2 convient au réglage de la performance et à la compréhension de base.
  • LOGLEVEL=3 est requis pour dépanner les filtres de sécurité des données au niveau de la rangée.

• En fonction du niveau de journalisation, les journaux d'interrogations contiennent des informations sur l'interrogation, notamment la demande logique, le plan de navigation et d'exécution, l'interrogation physique générée, le temps d'exécution, les rangées et les octets extraits au niveau des différents noeuds d'exécution, ainsi que des informations associées à la mise en cache.

Les administrateurs peuvent extraire les journaux d'interrogations de la page Émettre un énoncé SQL de la console en exécutant l'interrogation avec le paramètre LOGLEVEL et le paramètre de variable appropriés.

Lecture d'un journal d'interrogation

La page Sessions et journaux d'interrogations répertorie toutes les interrogations et sessions actives. Les administrateurs peuvent accéder à cette page depuis la console.

Chaque entrée de la page donne accès au journal d'une interrogation particulière, au niveau défini (modèle sémantique, session ou rapport).

.jpg

Chaque demande a un ID requestid unique dans Oracle Analytics.

Interrogation SQL logique

Voici un exemple d'interrogation SQL logique dans Oracle Analytics.

Voici quelques variables communes pouvant figurer dans une interrogation SQL logique :

• QUERY_SRC_CD : Origine de l'interrogation : Invite, Rapport, DV, Émettre un énoncé SQL, etc.
• SAW_SRC_PATH : Si l'interrogation est enregistrée, il s'agit du chemin d'accès à l'interrogation dans le catalogue.
• SAW_DASHBOARD : Si l'interrogation est incluse dans un tableau de bord, il s'agit du chemin d'accès au tableau de bord dans le catalogue.
• SAW_DASHBOARD_PG : Nom de la page de tableau de bord.

Demande logique

La demande logique est la traduction d'une interrogation à partir de la couche de présentation vers le modèle d'affaires et la couche de mappage après l'ajout de filtres de sécurité, le cas échéant.

En fonction de la demande logique, Oracle Analytics décide si l'interrogation représente des présences dans une mémoire cache existante 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 s'agit notamment d'un plan d'expédition pour chaque opération, et de savoir si l'opération est effectuée dans la base de données ou dans Oracle Analytics. Lorsqu'une opération est traitée dans Oracle Analytics, le journal d'interrogation indique [for database 0:0,0].

Lors de l'exécution de l'interrogation, Oracle Analytics parcourt exactement cet arbre. Dans les journaux détaillés, les informations sur les rangées traitées sont disponibles au niveau de chaque noeud de l'arbre d'exécution.

Demandes physiques ou de base de données

En fonction du plan d'exécution, Oracle Analytics génère un script SQL physique à exécuter dans la base de données spécifiée. Une ou plusieurs demandes peuvent être envoyées à une ou plusieurs bases de données.

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

Lorsqu'il y a plusieurs interrogations, vous pouvez utiliser l'ID interrogation (dans cet exemple, il s'agit de 1914627) qui correspond exactement à l'interrogation journalisée dans la section Sending query to the database. Cela vous permet de mapper l'interrogation aux rangées extraites lorsqu'il y a plusieurs demandes de base de données.

Un rapport peut envoyer plusieurs interrogations à une ou plusieurs bases de données en fonction de la structure de rapport et de la définition de modèle sémantique. Par exemple, dans ce journal d'interrogation, 3 interrogations physiques ont été envoyées à la base de données.

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

Le journal contient également un sommaire final des statistiques comprenant le temps d'exécution complet. Vous pouvez corréler le temps ici pour analyser et examiner les problèmes de performance.

Statistiques sommaires

Points à considérer pour le journal d'interrogation

• Activité à unité d'exécution unique. Dans des circonstances défavorables, les niveaux de journalisation supérieurs à 2 peuvent entraîner un goulot d'étranglement au niveau de la performance.

• Les temps répertoriés et calculés correspondent au moment où les entrées sont écrites dans le journal et c'est presque toujours à ce moment-là que l'événement s'est produit (activité qui a lancé la création de l'entrée de journal). Sauf s'il existe d'autres goulots d'étranglement qui ont une incidence sur la journalisation.

• L'enregistrement des interrogations est un outil de diagnostic et n'est pas destiné à recueillir des informations sur l'utilisation. Pour en savoir plus sur le suivi de l'utilisation, voir Suivi de l'utilisation.

Accès aux journaux d'interrogations pour un classeur

Seuls les administrateurs peuvent accéder aux journaux depuis la page Sessions et journaux d'interrogations de la console. Toutefois, les auteurs de contenu peuvent accéder aux informations de journal pour les interrogations de visualisation dans leurs classeurs à l'aide du menu Développeur. C'est outil est utile pour les auteurs souhaitant dépanner le rendement des interrogations. Pour accéder à l'outil de rendement pour les classeurs (option de menu Développeur), les utilisateurs doivent cliquer sur Activer les options relatives au développeur dans le menu Avancé sous Mon profil.

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

L'option Développeur permet aux utilisateurs de voir et d'analyser divers journaux à la volée pour les visualisations d'un canevas. Un cadre distinct apparaît sous le canevas, avec des onglets différents pour chaque type d'informations. Par défaut, les journaux ne sont pas alimentés ni actualisés lorsque la visualisation est exécutée.

Sélectionnez la visualisation à analyser et cliquez sur Actualiser pour générer les journaux. Une fois l'actualisation terminée, diverses informations relatives à la visualisation s'affichent et vous pouvez analyser les informations de journal pour cette visualisation. Pour analyser plusieurs visualisations, vous devez les actualiser individuellement et les analyser l'une après l'autre.