Re: ad-hoc update check
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 put them on low resource group so one Cartesian select will not bring the production to halt. Yechiel Adar Mehish - Original Message - To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] Sent: Wednesday, May 29, 2002 12:25 AM 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 get run today, marketing department won't be able to use the system etc. I wonder if other people on the list have the same problem and I am thinking about coming up with a document for the developers to fill out making sure the request won't hose up the database. I wonder how other shops deal with issues like these and can you let me know what you can do to check for potential issues with a sql script. TIA Dennis Meng Database Administrator Focal Communications Corp. -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: INET: [EMAIL PROTECTED] Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051 San Diego, California-- Public Internet access / Mailing Lists To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Yechiel Adar INET: [EMAIL PROTECTED] Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051 San Diego, California-- Public Internet access / Mailing Lists To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
RE: ad-hoc update check
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 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 get run today, marketing department won't be able to use the system etc. I wonder if other people on the list have the same problem and I am thinking about coming up with a document for the developers to fill out making sure the request won't hose up the database. I wonder how other shops deal with issues like these and can you let me know what you can do to check for potential issues with a sql script. TIA Dennis Meng Database Administrator Focal Communications Corp. -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: INET: [EMAIL PROTECTED] Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051 San Diego, California-- Public Internet access / Mailing Lists To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Farnsworth, Dave INET: [EMAIL PROTECTED] Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051 San Diego, California-- Public Internet access / Mailing Lists To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
Re: ad-hoc update check
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 something that proves someone other than the developer looked at the results. If this is going to be an ongoing process, create change control forms for it. Rachel --- Jared Still [EMAIL PROTECTED] wrote: 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 need to develop their data massage routines against the test database. 3. When they think they have it right, run the query on the QA database. If resource/time constraints demand it, this might be your test database. 4. They need to check their results. This means that an actual user that is very familiar with the application will use the application against the QA database, and sign off on the results. 5. Don't give them an account on the production database. They must supply you the DBA with script that you will run. They must supply documentation with the script. If the docs are imcomplete, don't run the script until the docs are complete. Anyway, this is what makes me happy. :) Jared On Tuesday 28 May 2002 15:25, [EMAIL PROTECTED] wrote: 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 get run today, marketing department won't be able to use the system etc. I wonder if other people on the list have the same problem and I am thinking about coming up with a document for the developers to fill out making sure the request won't hose up the database. I wonder how other shops deal with issues like these and can you let me know what you can do to check for potential issues with a sql script. TIA Dennis Meng Database Administrator Focal Communications Corp. -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Jared Still INET: [EMAIL PROTECTED] Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051 San Diego, California-- Public Internet access / Mailing Lists To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Rachel Carmichael INET: [EMAIL PROTECTED] Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051 San Diego, California-- Public Internet access / Mailing Lists To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
Re: ad-hoc update check
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 it, when, where, duration, etc. The zaptool was available only to DBAs who were part of the 24x7 on-call rotation, and usually one was referred directly to the DBA currently on-call. Those DBAs, knowing that they were being held accountable for its use (and that bending the rules might result in a sleepless night), demanded written sign-off from a director-level manager before the tool could be used, certifying that the zap was necessary and that it was safe. That's all. They just said No. Not without a director-level signature -- any director-level signature and their manager backed them up. And as it turned out, this chain of accountability was all that was needed... It didn't take long for all of the other good things to fall into place: a realistic test environment, some real concern by upper-management over safety and accuracy, working harder on app design to prevent zaps, etc. Most immediately, it brought home to the director who took full responsibility the full range of things that could go wrong, and made them place their own career and reputation into the hands of a 20-something who was hired only last month. It provided the flexibility for a director to take a chance in the event that a real crisis was brewing, but that same type of reckless behavior also spawned a culture among the other directors of trying to prevent the crisis, instead of letting the crisis ride you into the abyss... - Original Message - To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] Sent: Wednesday, May 29, 2002 7:08 AM 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 something that proves someone other than the developer looked at the results. If this is going to be an ongoing process, create change control forms for it. Rachel --- Jared Still [EMAIL PROTECTED] wrote: 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 need to develop their data massage routines against the test database. 3. When they think they have it right, run the query on the QA database. If resource/time constraints demand it, this might be your test database. 4. They need to check their results. This means that an actual user that is very familiar with the application will use the application against the QA database, and sign off on the results. 5. Don't give them an account on the production database. They must supply you the DBA with script that you will run. They must supply documentation with the script. If the docs are imcomplete, don't run the script until the docs are complete. Anyway, this is what makes me happy. :) Jared On Tuesday 28 May 2002 15:25, [EMAIL PROTECTED] wrote: 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 get run today, marketing department won't be able to use the system etc. I wonder if other people on the list have the same problem and I am thinking about coming up with a document for the developers to fill out making sure the request won't hose up the database. I wonder how other shops deal with issues like these and can you let me know what you can do to check for potential issues with a sql script. TIA Dennis Meng Database Administrator Focal Communications Corp. -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Jared Still INET: [EMAIL PROTECTED] Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051 San Diego, California-- Public Internet access / Mailing Lists To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command
RE: ad-hoc update check
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] -Original Message- Sent: Tuesday, May 28, 2002 11:53 PM To: Multiple recipients of list ORACLE-L 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 need to develop their data massage routines against the test database. 3. When they think they have it right, run the query on the QA database. If resource/time constraints demand it, this might be your test database. 4. They need to check their results. This means that an actual user that is very familiar with the application will use the application against the QA database, and sign off on the results. 5. Don't give them an account on the production database. They must supply you the DBA with script that you will run. They must supply documentation with the script. If the docs are imcomplete, don't run the script until the docs are complete. Anyway, this is what makes me happy. :) Jared On Tuesday 28 May 2002 15:25, [EMAIL PROTECTED] wrote: 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 get run today, marketing department won't be able to use the system etc. I wonder if other people on the list have the same problem and I am thinking about coming up with a document for the developers to fill out making sure the request won't hose up the database. I wonder how other shops deal with issues like these and can you let me know what you can do to check for potential issues with a sql script. TIA Dennis Meng Database Administrator Focal Communications Corp. -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Jared Still INET: [EMAIL PROTECTED] Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051 San Diego, California-- Public Internet access / Mailing Lists To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: DENNIS WILLIAMS INET: [EMAIL PROTECTED] Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051 San Diego, California-- Public Internet access / Mailing Lists To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
Re:RE: ad-hoc update check
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 Reply Separator Author: DENNIS WILLIAMS [EMAIL PROTECTED] Date: 5/29/2002 7:18 AM 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] -Original Message- Sent: Tuesday, May 28, 2002 11:53 PM To: Multiple recipients of list ORACLE-L 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 need to develop their data massage routines against the test database. 3. When they think they have it right, run the query on the QA database. If resource/time constraints demand it, this might be your test database. 4. They need to check their results. This means that an actual user that is very familiar with the application will use the application against the QA database, and sign off on the results. 5. Don't give them an account on the production database. They must supply you the DBA with script that you will run. They must supply documentation with the script. If the docs are imcomplete, don't run the script until the docs are complete. Anyway, this is what makes me happy. :) Jared On Tuesday 28 May 2002 15:25, [EMAIL PROTECTED] wrote: 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 get run today, marketing department won't be able to use the system etc. I wonder if other people on the list have the same problem and I am thinking about coming up with a document for the developers to fill out making sure the request won't hose up the database. I wonder how other shops deal with issues like these and can you let me know what you can do to check for potential issues with a sql script. TIA Dennis Meng Database Administrator Focal Communications Corp. -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Jared Still INET: [EMAIL PROTECTED] Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051 San Diego, California-- Public Internet access / Mailing Lists To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: DENNIS WILLIAMS INET: [EMAIL PROTECTED] Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051 San Diego, California-- Public Internet access / Mailing Lists To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: INET: [EMAIL PROTECTED] Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051 San Diego, California-- Public Internet access / Mailing Lists To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
ad-hoc update check
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 get run today, marketing department won't be able to use the system etc. I wonder if other people on the list have the same problem and I am thinking about coming up with a document for the developers to fill out making sure the request won't hose up the database. I wonder how other shops deal with issues like these and can you let me know what you can do to check for potential issues with a sql script. TIA Dennis Meng Database Administrator Focal Communications Corp. -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: INET: [EMAIL PROTECTED] Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051 San Diego, California-- Public Internet access / Mailing Lists To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
Re: ad-hoc update check
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 need to develop their data massage routines against the test database. 3. When they think they have it right, run the query on the QA database. If resource/time constraints demand it, this might be your test database. 4. They need to check their results. This means that an actual user that is very familiar with the application will use the application against the QA database, and sign off on the results. 5. Don't give them an account on the production database. They must supply you the DBA with script that you will run. They must supply documentation with the script. If the docs are imcomplete, don't run the script until the docs are complete. Anyway, this is what makes me happy. :) Jared On Tuesday 28 May 2002 15:25, [EMAIL PROTECTED] wrote: 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 get run today, marketing department won't be able to use the system etc. I wonder if other people on the list have the same problem and I am thinking about coming up with a document for the developers to fill out making sure the request won't hose up the database. I wonder how other shops deal with issues like these and can you let me know what you can do to check for potential issues with a sql script. TIA Dennis Meng Database Administrator Focal Communications Corp. -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Jared Still INET: [EMAIL PROTECTED] Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051 San Diego, California-- Public Internet access / Mailing Lists To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
