Re: How-To or Good Practices on Code Releases

You do not have to reinvent the wheel.
If you want to check the scripts just do the following:

1) Get the DBATool from DataBee www.databee.com
2) Do export no data from the target system.
3) Read the export into the DBATool
4) Create DDL for the schema
5) Run the DDL and create the schema in test db.
6) Run your script against the empty schema.

All syntax error and logical error will show up. It will not check for data dependent error, like adding unique constrain to a column with data that have multiple occurrences of the same value but it will save you a lot of time and development.

Yechiel Adar (who does not have any hidden/unhidden connections to DataBee) Mehish
----- Original Message -----
To: Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com> Sent: Wednesday, November 13, 2002 9:23 PM

> 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_at_LIFE To: Multiple recipients of
> list ORACLE-L <ORACLE-L_at_fatcity.com>
> TOUCH.COM> cc:
>
> Sent by: Subject: RE: How-To or Good
> Practices on Code Releases
> root_at_fatcity.co
>
> 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.
> dwilliams_at_lifetouch.com
>
>
> -----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 <ORACLE-L_at_fatcity.com>
> SE_at_CHASE cc:
>
> Sent by: Subject: Re: How-To or Good
> Practices on Code Releases
> root_at_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" <Rajendra.Jamadagni_at_espn.com>@fatcity.com on
> 11/13/2002 09:29:47 AM
>
> Please respond to ORACLE-L_at_fatcity.com
>
>
>
> Sent by: root_at_fatcity.com
>
>
> To: Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com>
> 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: Rajesh.Rao_at_jpmchase.com
>
> 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: ListGuru_at_fatcity.com (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: Bill.Magaliff_at_lendware.com
>
> 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: ListGuru_at_fatcity.com (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: adar76_at_inter.net.il

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: ListGuru_at_fatcity.com (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).