Essayer de savoir quelles tables sont exécutées dans l'application externe oracle

Le suivi des requêtes exécutées par une application logicielle active peut prendre un certain temps. En tant que tel, il peut être plus facile d'extraire les données d'une autre manière:

Vous voulez savoir quelle table et quelle colonne contiennent certaines données, comme un prénom d'utilisateur.

Générez quelque chose d'unique, comme un GUID ou un nom impossible qui n'apparaît jamais dans votre base de données (comme 'a87d5iw78456w865wd87s7dtjdi') et entrez-le comme prénom à l'aide de l'interface utilisateur. Sauvegardez les données

Exécutez cette requête sur oracle:

TABLE_NAME        COLUMN_NAME
crm_contacts_info first_name

Ceci est "un SQL qui écrit un SQL" - Il générera un jeu de résultats qui est essentiellement une liste d'instructions SQL comme celle-ci:

UNION ALL SELECT 'tablename', 'columnname' FROM tablename WHERE columnname = 'a87d5iw78456w865wd87s7dtjdi'
UNION ALL SELECT 'table2name', 'column2name' FROM table2name WHERE column2name = 'a87d5iw78456w865wd87s7dtjdi'
UNION ALL SELECT 'table3name', 'column3name' FROM table3name WHERE column3name = 'a87d5iw78456w865wd87s7dtjdi'

Il y aura une requête pour chaque colonne de chaque table de la base de données. Au fait, seules les colonnes CHARacter seront recherchées

Supprimez le premier UNION ALL

Exécutez-le et attendez un long moment pendant qu'oracle recherche essentiellement toutes les colonnes de chaque table, dans la base de données, pour votre nom étrange.

Finalement, il produit une sortie comme:

SELECT 
  REPLACE(REPLACE(
    'UNION ALL SELECT ''{t}'', ''{c}'' FROM {t} WHERE {c} = ''a87d5iw78456w865wd87s7dtjdi'' ',
    '{t}', table_name),
    '{c}', column_name
  )  
FROM USER_TAB_COLUMNS WHERE data_type like '%char%'

Donc vous connaissez votre nom a87d5iw78456w865wd87s7dtjdi a été enregistré, par l'interface utilisateur, dans crm_contacts_info.first_name

Si c'est possible, comment pourrais-je obtenir l'identifiant de session du type vous utilisez l'application oracle E-BUSINESS-SUITE?

Oui, c'est certainement possible. Tout d'abord, vous devez déterminer quel schéma / nom d'utilisateur "le gars" utilise. Si vous ne savez pas, vous pouvez demander au gars ou lui demander d'exécuter une requête simple (quelque chose comme sélectionner l'utilisateur à partir de dual; fonctionnera) pour obtenir cette information.

Une fois vous avez le nom du schéma, vous pouvez interroger la table V $ SESSION pour déterminer l'ID de session. Demandez au gars de se connecter, puis interrogez la table V $ SESSION . Votre requête ressemblerait à ceci: select * from v $ session where username = '[SCHEMA]'; où [SCHEMA] est le nom de schéma utilisé par le gars pour vous connecter. Cela vous donnera le SID, le numéro de série, le statut, etc. Vous aurez besoin de cette information pour suivre la session du gars.

La génération d'un fichier de trace pour la session est relativement simple. Vous pouvez démarrer une trace pour toute la base de données ou juste pour une session. Puisque vous n'êtes intéressé que par la session du gars, il vous suffit de tracer celle-là. Pour commencer la trace, vous pouvez utiliser une commande qui ressemble à ceci: EXEC DBMS_MONITOR.session_trace_enable (session_id => [SESSIONID], serial_num => [SERIAL #]); où [SESSIONID ] et [SERIAL #] sont les chiffres que vous avez obtenus à l'étape précédente. Gardez à l'esprit que le gars devra être connecté pour que la trace de session vous donne des résultats .

Une fois que le gars est connecté et que vous avez activé la trace de session, demandez au gars d'exécuter toutes les commandes de la suite E-Business qui vous intéressent. Sachez que plus le gars (ou l'application ) fait pendant que la trace est activée, plus vous aurez d'informations à parcourir pour trouver ce que vous recherchez. Cela peut être une tonne de données avec des applications. Je vous préviens juste à l'avance.

Une fois que le gars a terminé ses tâches, vous devez désactiver la trace. Cela peut être fait en utilisant le package DBMS_MONITOR comme précédemment, mais légèrement différent. La commande ressemblerait à ceci: EXEC DBMS_MONITOR.session_trace_disable (session_id => [SESSIONID], serial_num => [SERIAL #]); en utilisant le même [SESSIONID] et [SERIAL #] comme avant.

En supposant que tout a été fait correctement, cela générera le fichier de trace. La raison pour laquelle @thatjeffsmith a mentionné l'accès au serveur est que vous devrez accéder au (x) serveur (s) sur lequel vit la base de données afin d'obtenir le fichier de trace. Si vous n'avez pas accès au serveur, vous devrez travailler avec un DBA ou une personne ayant accès pour l'obtenir. Si vous avez juste besoin d'aide pour savoir où se trouve le fichier de trace, vous pouvez exécuter la requête suivante en utilisant le [SESSIONID] d'avant:

SELECT p.tracefile
FROM   v$session s
       JOIN v$process p ON s.paddr = p.addr
WHERE  s.sid = [SESSIONID];

Ceci devrait renvoyer un répertoire qui ressemble à ceci: /u01/app/oracle/diag/rdbms/[databaseletter/[instance circular/trace/[instance circular_ora_010719.trc

Accédez simplement à ce répertoire, extrayez le fichier de trace en utilisant WinSCP, FileZilla ou l'application de votre choix, et cela devrait le faire.

Bonne chance et j'espère que cela vous aidera!

Les SQL exécutés depuis le frontend EBS sont généralement trop rapides pour être vus dans v $ session. Si un SQL est plus lent qu'une seconde (ou si le timing de l'instantané est correct), vous le verriez dans v $ active_session_history, qui capture un instantané de toutes les sessions actives chaque seconde.

À la place, vous devriez regarder v $ sqlarea, ce qui peut être fait par SQL, via Toad en utilisant l'option de menu Database-> Monitor-> SGA Trace / Optimization ou par notre Blitz Report https://www.enginatics.com/reports/dba-sga-sql-performance-summary/ .

Cependant, ces données contiennent des informations sur le module (c'est-à-dire quelle page OAF, formulaire, simultané, etc.) et le niveau de responsabilité (colonne d'action) uniquement et ne contiennent pas d'informations sur la session ou l'application.

La clé unique est sql_id et plan_hash_value, ce qui signifie que pour les SQL exécutés par différents modules et de différentes responsabilités, seul le module qui l'exécute en premier sera affiché.

Si vous triez les données par last_active_time et filtrez pour le module en question, c'est presque aussi bon qu'une trace. Les valeurs de liaison utilisées peuvent être récupérées à partir de v $ sql_bind_capture, ce que fait également le rapport Blitz ci-dessus.