| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> RE: looking for a good way to change manage oracle
Agree totally with the use of scripts to make database changes. One idea is to base your development on a 3-database model. Production, staging, and test (or development). Update the test and staging as required by cloning production. This way you are guaranteed to have an exact copy of production.
Ideally you clone by recovering a backup. That way you frequently test your backups.
Staging acts as a buffer between test and production. Often you can't refresh the test database because of various developer activities in progress, so staging is where you test the changes before they hit production.
This method is from ITIL. The only way to combat a massive force like SOX is to pit it against another massive institution.
Dennis Williams
DBA
Lifetouch, Inc.
-----Original Message-----
From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org]
On Behalf Of Powell, Mark D
Sent: Friday, December 10, 2004 7:54 AM
To: oracle-l_at_freelists.org
Subject: RE: looking for a good way to change manage oracle
I think Tom has a good point; however, the request tracking works best if the environments are all in sync when the process is started otherwise you do not have an explanation for why differences exist. I think Ryan's first problem is to identify and re-sync those elements that should be the same. As this is done then change tracking must be implemented to maintain a record of the changes.
Ryan, one idea that might be of use if your application is basically limited to using the basic objects: tables, views, indexes, synonyms, etc... might be to extract the owner, object_name, and object_type from dba_objects along with a database identifier and load this into one database. Then a simple pl/sql script could identify objects in one database environment but not others. Using dba_tab_columns you could identify differences in tables and views. If you do not worry about identifying the exact differences in code but just identify the objects that require review the code is pretty simple.
Obviously this is not a purely automated technique but the coding is simple, the cost is cheap, and it may be good enough. I used the above for comparing tables/views between our test environments and production so that we could rebuild test tables where the column list/order did not match production.
-----Original Message-----
From: oracle-l-bounce_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org]On Behalf Of Mercadante, Thomas F
Sent: Friday, December 10, 2004 8:05 AM
To: 'ryan_gaffuri_at_comcast.net'; oracle-l_at_freelists.org
Subject: RE: looking for a good way to change manage oracle
Ryan,
It seems that your approach is always playing catch-up. Here, we developed a very simple Database Request system. Developers cannot make any changes anyplace - they have to request a change be made via the request system. The application tracks all changes and what level of the database they have been applied to (Dev, Staging or Production). Simple reports can be generated showing what changes are in Dev, but not in staging yet.
I'm really talking about managing your change requests a little better. If you manage your requests better, then you don't need a schema compare functionality.
Hope this helps.
Tom
-----Original Message-----
From: ryan_gaffuri_at_comcast.net [mailto:ryan_gaffuri_at_comcast.net]
Sent: Thursday, December 09, 2004 5:01 PM
To: oracle-l_at_freelists.org
Subject: looking for a good way to change manage oracle
We have 13 development databases, 8 parallel development tracks, and 2
concurrent sustainment releases all developing at the same time. We are
having alot of trouble with change management. I am looking for an easy way
to do the following:
take a snapshot of the metadata of a database at a point in time.
compare it at a later point in time or to another database and see the
differences.
What we have tried
1. Designer and change manager(OEM) are really slow. 2. Toad does not appear to be complete 3. Writing code with dbms_metadata is a major task. 4. export won't work, because the order of the objects in the file could bedifferent in different databases, do to different releases applied at different times.
 |
 |