Restriction de drop table

Bonjour à tous,
sous oracle 12C je souhaiterai restreindre le drop table afin d' éviter de grosses déconvenues.
sur DB2/mainframe je sais que l'on peut faire un 'restrict on drop table'
mais sur oracle je n'ai pas trouvé de possibilité identique a part revoir les privilèges accordé aux différents user
ou créer un trigger.
connaissez-vous d'autres possibilités plus globales.
merci de vos réponses.
Cordialement.

Bonjour,

Je pense qu'il faut plutôt se poser la question sur le fait que des utilisateurs puissent dropper des tables. Soit ils ont le privilège DROP ANY TABLE, soit ils se connectent en tant qu'utilisateurs propriétraires des tables. Il faut donc revoir ces privilèges. Sinon à part un trigger système, il n'y a pas de solutions simples pour empêcher de dropper une table à celui qui a le droit de le faire.

Bonjour,

merci pour votre réponse
il est possible de créer le trigger au niveau base de données ?? et pas pour chaque schéma
auriez-vous un exemple de trigger système.
Cordialement.

Quelque chose du genre:

Code:

---

1 2 3 4 5 6 7 8

create or replace trigger prevent_drop_trg before drop on database begin if ora_dict_obj_type = 'TABLE' then raise_application_error (-20001, 'Suppression de tables non autorisée'); end if; end; /

---

Vous pouvez ajouter des conditions sur le propriétaire ou d'autres points si besoin.

Bonjour
le script fonctionne bien mais le msg d'erreur n'apparait pas dans l'alert log
aussi comment puis-je faire pour logger dans un fichier ou une table temporaire
je ne maitrise pas le code :oops:
merci pour votre aide

Bonjour,

Pour logger dans le fichier alert.log il faut utiliser le package non documenté DBMS_SYSTEM. Un exemple ici :

https://www.databasejournal.com/feat...race-files.htm

Attention le package DBMS_SYSTEM est assez puissant, il faut donc donner les droits d'exécution qu'à un utilisateur DBA.

Merci
mais je crois que je vais mettre cela dans 1 table

Bonjour,

Pour moi, la bonne pratique consiste à créer 3 comptes Oracle (CREATE USER) :
- le premier USER1 sur lequel on se connecte ne sert uniquement qu'à la livraison des objets (tables, index, vues, procédures stockées, etc, etc).
- le second USER2 sert aux traitements applicatifs (batchs, serveurs Web) avec des droits en lecture et écriture sur les objets de USER1
- le troisième USER3 n'a que des droits de lecture. Il est souvent utilisé par des personnes privilégiées ayant accès aux données (je pense surtout à la production), ou bien pour faire du reporting via des logiciels comme BO, Cognos ou autres


Cette façon de faire nécessite de :
- de donner les bons droits, via des rôles et non pas en direct. Ainsi USER3 aura un rôle ne regroupant que des privilèges de type GRANT SELECT sur les tables et vues de USER1. Quant à USER2, toujours via un rôle, il aura des privilèges de type GRANT SELECT, INSERT, UPDATE, DELETE sur les tables et les vues de USER1, ainsi que des privilèges de type GRANT EXECUTE pour les procédures et fonctions stockées en PL/SQL
- de créer des synonymes sur USER2 et USER3 pour éviter de préfixer les objets avec USER1. Et pour des raisons de sécurité, surtout si la base Oracle est mutualisée avec d'autres projets, il vaut mieux créer des synonymes privés sur USER2 et USER3, plutôt que de créer des synonymes publics.

De cette manière, à part les personnes en charge des livraisons applicatives, personne d'autre ne connaît le mot de passe de USER1 et personne ne peut donc s'y connecter pour dropper les tables.

Qu'en pensez-vous SVP ?