DDL does *not* belong in the developers hands.
DDL scripts should *not* be accepted from developers. this is what DBA's
are for. DBA's should be responsible for the health and well-being of
database tables. if a table needs DDL transactions applied, a request needs
to be sent to the DBA who is then responsible for tracking and applying
these changes to the database at appropriate times.
anything else, the the DBA should run away from the project as fast as they
can. because something bad is gonnaq happen.
Tom Mercadante
Oracle Certified Professional
-----Original Message-----
Sent: Wednesday, November 13, 2002 3:06 PM
To: Multiple recipients of list ORACLE-L
I also have been burnt by an simple "alter table add column default string"
script. A pretty simple script. The developers tested it, the QA team too
approved it. Was expected to run in a matter of minutes. The problem was
the data in production was 100 times over. Missed out on volume testing.
Took 2 cuppas and 3 smokes before it was done.
Raj
"Magaliff, Bill"
<Bill.Magaliff@len To: Multiple recipients of
list ORACLE-L <[EMAIL PROTECTED]>
dware.com> cc:
Sent by: Subject: RE: How-To or
Good Practices on Code Releases
[EMAIL PROTECTED]
November 13, 2002
02:23 PM
Please respond to
ORACLE-L
one of the things I'm experimenting with right now, based on a request from
clients, is a pre-run analysis script to report on likely errors that the
actual script would generate. this gives me a chance to trap the silly
errors and continue (e.g., modify column to NOT NULL that is already NOT
NULL, drop a column that's not there, etc.) and provide feedback to the
client on the more serious errors that will need their attention - e.g.,
changing a column datatype or reducing a column_size, where the existing
data won't work; creating a FK, where there are missing parent records;
etc.) This analysis script tests for the existance of new columns or data
that are to be added, checks max(lengths) of fields that need to be
shortened, etc. The client can then execute the analysis script, evaluate
the output, and decide on a course of action.
As others have said, though, this REALLY SHOULD first be run in a UAT,
staging, or other test env first - if for no other reason than a sanity and
syntax check.
My objective with this is to PREVENT the need to roll back the script, save
for unexpected errors (whereby something significant changed between the
time the analysis script was run and the actual delta) and *critical*
errors
(crash, out of disk space, etc.) . . . in which case I would revert back to
the backup they should have taken just before the script was executed
HTH
bill
-----Original Message-----
Sent: Wednesday, November 13, 2002 1:20 PM
To: Multiple recipients of list ORACLE-L
As an example, something that yours truly was involved with, and still have
the scars to show for it. A migration from a lower version of Oracle, to a
higher version, on a completely new server. The scripts ran fine, and the
implementation plan worked fine. However, the application started reporting
intermittent connection problems. This was a web application, and it took
the developers a day to realize that the one of the components in the
application was not fully certified with Oracle 8i. Also, there were memory
leak issues with that version of Oracle 8i. Whereby we needed to fall back
to the old server, with the new data. The rollback strategy in the
implementation plan was a one liner, to fall back to the old server. This
was good for an immediate fallback after the implementation. Had to go the
export import way, which had some additional outage for hours.
So, the next time this was implemented, we had a quick rollback strategy to
rollback after n number of days. If memory serves me right, I think we had
a standby database created on the old server with the new release, and a
downgrade plan. This was tested and approved by the developers and the QA
team, though I never had to use it. Since then, I tend to be paranoid about
any changes to production databases. You live and learn.
Regards
Raj
DENNIS WILLIAMS
<DWILLIAMS@LIFE To: Multiple recipients of
list ORACLE-L <[EMAIL PROTECTED]>
TOUCH.COM> cc:
Sent by: Subject: RE: How-To or Good
Practices on Code Releases
[EMAIL PROTECTED]
m
November 13,
2002 12:15 PM
Please respond
to ORACLE-L
Raj - Can you provide more details? Is this an automated script, or just a
line on the form that says that you have some idea of how to rollback the
change in case anything goes wrong?
Dennis Williams
DBA, 40%OCP
Lifetouch, Inc.
[EMAIL PROTECTED]
-----Original Message-----
Sent: Wednesday, November 13, 2002 10:54 AM
To: Multiple recipients of list ORACLE-L
And have a similarly tested and signed off rollback strategy in place. An
immediate rollback, as well as a rollback strategy after n number of days.
Raj
One attachment (0k)
Reginald W.
Bailey/JPMCHA To: Multiple recipients of
list
ORACLE-L <[EMAIL PROTECTED]>
SE@CHASE cc:
Sent by: Subject: Re: How-To or Good
Practices on Code Releases
root@fatcity.
com
November 13,
2002 11:15 AM
Please
respond to
ORACLE-L
The releases should be tried in the Development environment first. Then a
UAT (User Acceptance Test) environment, then production. The UAT
environment is usually a duplicate of the production environment. This is
the environment that you implement the changes , then test to see if the
changes worked and if there are any side effects.
The end user , project manager, information owner, or test manager signs
off that the changes were implemented correctly. Then approval is given and
the change is implemented in the production environment. This is usually
accompanied by some sort of change control management. Also, use some sort
of source code control to keep the DML and DDL scripts in. Oracle's SCM
Repository (once part of Oracle Designer), TrueChange by TrueSoft, PVCS,
etc. are candidates for this.
By implementing the scripts in the UAT environment, any dependencies become
evident. Also, the developers should submit the changes in fully runnable
SQL scripts, with
appropriate comments. If the scripts are dependent upon some other script
or database object, this should be listed in the SQL file comment header,
along with the authors name and a description of the file.
Hopefully this will get you going.
RWB
"Jamadagni, Rajendra" <[EMAIL PROTECTED]>@fatcity.com on
11/13/2002 09:29:47 AM
Please respond to [EMAIL PROTECTED]
Sent by: [EMAIL PROTECTED]
To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]>
cc:
Friends ...
I have a (sort of) problem ... what are the best practices to manage code
releases to production environment ...
currently we get a bunch of scripts from development team, and we release
code to production on the schedule (currently twice a month). But this is
not complete. The scripts we get consists of various DML and DDL
statements.
We do not have a mechanism to roll-back these changes in place and I am
seeking your opinion on ways to achieve these. Also we would like to
implement script dependencies (which we manage manually right now) and
rollback mechanism.
Are there any good practices papers? I know these would be site specific,
but I am looking for common methods.
Hope I make myself clear ... (and if it matters it is Oracle 9.2 and
Forms/Reports) application.
Raj
______________________________________________________
Rajendra Jamadagni MIS, ESPN Inc.
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author:
INET: [EMAIL PROTECTED]
Fat City Network Services -- 858-538-5051 http://www.fatcity.com
San Diego, California -- Mailing list and web hosting services
---------------------------------------------------------------------
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: Magaliff, Bill
INET: [EMAIL PROTECTED]
Fat City Network Services -- 858-538-5051 http://www.fatcity.com
San Diego, California -- Mailing list and web hosting services
---------------------------------------------------------------------
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 http://www.fatcity.com
San Diego, California -- Mailing list and web hosting services
---------------------------------------------------------------------
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: Mercadante, Thomas F
INET: [EMAIL PROTECTED]
Fat City Network Services -- 858-538-5051 http://www.fatcity.com
San Diego, California -- Mailing list and web hosting services
---------------------------------------------------------------------
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).
