dba_hist_sqlstat : colonnes parsing_schema_id et parsing_user_id
Hello,
J'ai un souci sur une base où visiblement un user A arriverait à faire un INSERT dans la table d'un user B sans préfixer celle-ci...
Le user UA exécute un code ressemblant à :
Code:
INSERT INTO T1 VALUES (1);
et dans le Cloud Control, je vois dans l'écran de monitoring de l'ordre SQL, onglet Plan, les données suivantes :
Parsing Schema : UA
Object : UB.T1
ce qui montre que UA a fait son INSERT dans UB.T1 mais sans utiliser de nom de schéma.
Je sais qu'il existe l'instruction
Code:
ALTER SESSION SET CURRENT_SCHEMA = 'UB';
qui pourrait expliquer ce comportement mais je n'ai pas accès au code pour valider cette hypothèse.
En regardant dans la table DBA_HIST_SQLSTAT, je vois qu'il existe deux colonnes, parsing_schema_id <> parsing_user_id.
La doc n'est pas claire du tout : Oracle semble faire la distinction entre SCHEMA et USER...
"PARSING_SCHEMA_ID : Schema ID that was used to originally build the child cursor
PARSING_USER_ID : User ID that was used to originally build the child cursor"
Si je regarde plus avant, voilà ce que je vois : chaque fois que j'ai une différence entre les deux, parsing_user_id vaut 0.
Code:
1
2
3
4
5
6
7
8
9
10
11
12
| select parsing_schema_id, parsing_user_id from dba_hist_sqlstat where parsing_schema_id <> parsing_user_id and rownum < 11 order by 1;
PARSING_SCHEMA_ID PARSING_USER_ID
81 0
81 0
81 0
81 0
87 0
109 0
109 0
170 0
170 0
170 0 |
Code:
1
2
3
4
5
6
7
8
9
10
11
12
| select parsing_schema_id, parsing_user_id from dba_hist_sqlstat where parsing_schema_id = parsing_user_id and rownum < 11 order by 1;
PARSING_SCHEMA_ID PARSING_USER_ID
0 0
0 0
0 0
0 0
0 0
77 77
87 87
87 87
121 121
176 176 |
Code:
1
2
3
| select username from dba_users where user_id = 0;
USERNAME
SYS |
Est-ce que vous pouvez me valider le fait que ce comportement est lié à l'utilisation du paramètre CURRENT_SCHEMA?
Et comment je dois comprendre ces deux colonnes de la table DBA_HIST_SQLSTAT?
