Dans l’article précédent à propos des limites de SQL Performance Analyzer, j’ai souligné le fait que certaines informations comme la configuration NLS ou les informations de session n’étaient pas conservées lorsque vous ré-exécutiez les ordres capturés dans des SQL Tuning Set. Le résultat peut être que les différences constatées entre 2 exécutions ne viennent pas des changements réalisés comme la création d’un index ou le changement de version d’Oracle, mais de la méthode elle-même, y compris dans le cas de l’utilisation de SQL Performance Analyzer. Un autre exemple assez frappant est l’utilisation de la VPD comme vous allez le découvrir ci-après.
Le même exemple
L’exemple utilisé est identique à celui de l’article précédent :
- Un schema demo
- Une table T
- Une requête marquée avec le commentaire MARKER
Après avoir créé et inséré les données dans la table et avant d’exécuter la requête, activez la VPD avec une fonction et une politique de « Row Level Security » comme celle créé dans le script ci-dessous :
connect / as sysdba
create or replace function maskall(object_schema VARCHAR2,
object_name VARCHAR2)
return varchar2 as
retval varchar2(200);
begin
if user='DEMO' then
retval:='2=1';
end if;
return retval;
end;
/
BEGIN
dbms_rls.add_policy(object_schema => 'demo',
object_name => 't',
policy_name => 'mask T',
policy_function => 'maskall');
END;
/
Le résultat
Utilisez SQL Performance Analyzer et imprimez le rapport comme ci-dessous :
Comme vous pouvez le constater, la VPD n’est pas déclenchée dans le cas de SQLPA et cela même si on aurait aimé avoir le même résultat que lors de l’exécution initiale. Bien sur, vous vous dites pourquoi ne pas utiliser sys_context(‘userenv’, ‘current_schema’) dans la fonction de la VPD ? La vérité est que la VPD n’est de toute façon pas déclenchée dans le cas d’utilisateurs comme SYS ou les utilisateurs ayant le privilege EXEMPT ACCESS POLICY.
Note: Pour les exceptions qui concernent la VPD, reportez-vous à la section suivante d’Oracle 11.2 Security Guide
