Re: Database Change Control Process

From: Dba DBA <oracledbaquestions_at_gmail.com>
Date: Thu, 27 Feb 2014 11:56:35 -0500
Message-ID: <CAE-dsOK5d6+xF=CDoPc9a617G6OgFxg8Lqn+cjLoQa6bzswcxg_at_mail.gmail.com>

Enabling Flashback DB and having enough space for your Archive logs is critical for non-prod change management. Its pretty common in non-prod to do a build and then the build changes. The ability to flashback is critical to handle this.

however, in non-prod you often run into archive log space issues and developers/testers could generate alot of archive log space. This is often better handled on DBs that do not have flashback on. This can require alot of cloning. The 2 easiest ways to handle this in non-prod

1. run DBs in VM and clone the entire VM. Save the VM before the test and restore that. This is for when developers/testers need to do stuff that generates more archive than you can sit on dev/test. You have very little space. if not you will be doing alot of RMAN clones which can a hassle(since builds changes multiple times before a release).
2. SAN level utilities like Flash copy or BCVs if your company has the hardware for this are great. I was on a project with a 10+ TB prod DB. The SAs made us scripts that we had execute privileges on so we can do a BCV sync and restore to grab current copies of production for testing. We had the whole recovery scripted. It was great for testing builds against production prior to a release and for performance testing.

most shops wont have #2.

On Thu, Feb 27, 2014 at 8:05 AM, rjamya <rjamya_at_gmail.com> wrote:

> You can also look at Datical for a packaged solution built around
> Liquibase with multiple additional features.
> I have no ties with them but have seen their demo.
>
> Raj
>

--
http://www.freelists.org/webpage/oracle-l

Received on Thu Feb 27 2014 - 17:56:35 CET