Creating Trigger to prevent dropping/truncating tables [message #315785] |
Tue, 22 April 2008 15:12 |
bogey
Messages: 53 Registered: February 2006
|
Member |
|
|
We ran into a problem today when a user notified us that they dropped a table withing their scheama. Since they are the owners of the schema they have total control. I was wondering if its wise to create a before trigger to prevent the user(s) from dropping/truncating tables. What I have below will notify admins if a user does try this.
-
-- TRIGGER_DATABASE_TRUNC_DROP (Trigger)
--
CREATE OR REPLACE TRIGGER TRIGGER_DATABASE_TRUNC_DROP
BEFORE DROP OR TRUNCATE
ON DATABASE
DECLARE
SENDER VARCHAR2(200);
RECIPIENTS VARCHAR2(200);
CC VARCHAR2(200);
BCC VARCHAR2(200);
SUBJECT VARCHAR2(200);
MESSAGE VARCHAR2(200);
MIME_TYPE VARCHAR2(200);
PRIORITY BINARY_INTEGER;
BEGIN
SENDER := 'xxx';
RECIPIENTS := 'xxx';
CC := NULL;
BCC := NULL;
SUBJECT := 'xxx';
MESSAGE := 'Errors drop/trunc';
MIME_TYPE := NULL;
PRIORITY := NULL;
SYS.UTL_MAIL.SEND ( SENDER, RECIPIENTS, CC, BCC, SUBJECT, MESSAGE, MIME_TYPE, PRIORITY );
RAISE_APPLICATION_ERROR(-20000, 'DROPPING OR TRUNCATING IS NOT ALLOWED IN PRODUCTION DATABASE');
COMMIT;
END;
/
|
|
|
|
Re: Creating Trigger to prevent dropping/truncating tables [message #315795 is a reply to message #315790] |
Tue, 22 April 2008 15:47 |
|
Littlefoot
Messages: 21823 Registered: June 2005 Location: Croatia, Europe
|
Senior Member Account Moderator |
|
|
And you, of course, have yesterday's backup, haven't you?
Besides, is it a good idea to forbid dropping tables? (Some) developers tend to create "temporary" tables now and then in order to save some data and easily recover from changes (which weren't done the way they supposed to be), change their mind (drop a few tables, create another few) etc. Who will clean up this mess if they can't clean up this "garbage" themselves?
[Updated on: Tue, 22 April 2008 15:47] Report message to a moderator
|
|
|
|
Re: Creating Trigger to prevent dropping/truncating tables [message #315999 is a reply to message #315836] |
Wed, 23 April 2008 08:10 |
bogey
Messages: 53 Registered: February 2006
|
Member |
|
|
"Since they are the owners of the schema they have total control"
They own the schema so they can do what they want.
"And you, of course, have yesterday's backup, haven't you?"
Sure, but if a user drops a table I cannot do a point in time recovery in a production database.
"Who will clean up this mess if they can't clean up this "garbage" themselves? "
My whole point here is to limit what a user can do in a production database. There seems to be no consensus on this. Do we let users do what they want e.g. Create, Drop, Alter, Truncate.....?
|
|
|
|
|
|
|
Re: Creating Trigger to prevent dropping/truncating tables [message #316119 is a reply to message #316029] |
Wed, 23 April 2008 16:24 |
|
Littlefoot
Messages: 21823 Registered: June 2005 Location: Croatia, Europe
|
Senior Member Account Moderator |
|
|
It seems that only @bogey doesn't understand that PRODUCTION database isn't a developer's playground. They may create/drop/truncate/whatever in a development database, prepare testing environment for people who will actually test what they've done and, when it's approved, changes are applied to the production database. There's no reason for developer to put their fingers into production.
|
|
|