Hello Dennis
1) Fight! Do not let developers into production.
2) Offer to build semi production DB and copy data daily/weekly
to this DB. The developers can see production data but can not
hurt production.
3) I all else fails (RTFM :-) ) grant them only READ access to the database
and
Do you have a good test system that is identical to your production environment? If
so run the query there and do a trace on it. Be wary of ad-hoc anything from
duhvelopers.
Dave
-Original Message-
Sent: Tuesday, May 28, 2002 5:25 PM
To: Multiple recipients of list ORACLE-L
Hi
One thing to add to that:
they must supply some sort of change request doc with MANAGEMENT/USER
sign-off on it before you run the changes.
just supplying a piece of paper doesn't do it for me. I've had
developers (yes, developers not duhvelopers) who still say oh I tested
it but I want
I agree with Rachel.
I worked in one environment that had these sorts of zaps (as they called
them) happening so often that the DBAs built a zaptool. The zaptool was
implemented in X-windows and took a SQL statement as input. It recorded
everything possible about the SQL statement: who used
Dennis - I agree with Jared and Rachel. One suggestion I haven't seen yet is
to export the tables that will be affected just before you make the changes.
This also helps emphasize the seriousness of the situation to the
developers.
Dennis Williams
DBA
Lifetouch, Inc.
[EMAIL PROTECTED]
Dennis,
That helps, but only if you have the time. Try exporting a 2 million row
table in less than 2 minutes. Now If the statement is an update or insert I
like to save off the rowid's. Otherwise I like to save off the deleted rows to
a backup table.
Dick Goulet
Hi folks -
I have received a stream of requests from developers/production support (
yep, same group, dont ask ) to do ad-hoc data massaging in the production
databases. Since I don't know the applications that well, it's hard for me
to push back these requests when told that if the script don't
Dennis,
If management is Ok with this ( have you asked? ) you need to
take some steps to protect your database, your job and your reputation.
'cuz the duhvelopers will do their best to destroy all three.
1. You need a test database with a reasonable amount of test data
2. Your duhvelopers
