Skip to Main Content

Breadcrumb

Question and Answer

Tom Kyte

Thanks for the question, Robert.

Asked: August 20, 2008 - 2:04 pm UTC

Last updated: August 21, 2008 - 9:59 pm UTC

Version: 10.2.0.4

Viewed 1000+ times

You Asked

Hi Tom,

As we are in the process of implementing Data Guard, we are having a discussion here among DBA's, SA's, and APPDEV about whether to have a dedicated DG DEVELOPMENT environment which is configured similarly to production.

We have a 3 level environment... DEV, QA, and PROD

DEV - single db on separate server (no data guard)
QA - single db on separate server
QA-dg single db on separate server (data guard standby for QA)
PROD - single db on separate server
PROD-dg single db on separate server (data guard standby for PROD)

The discussion is whether to have the DEV environment set up identically to QA and PROD... a separate server dedicated to a DEV-dg database.
This would give us 3 entire DG environments.

I think it is a good idea because it gives DBA's extra practice and training with data guard in a 'real' environment... also there is the fringe benefit of allowing database and o/s patches to be applied (during the day) while developers are working with minimal downtime.

Others are saying it is a waste of money because we already have a QA data guard environment for data guard testing. And if we wanted a DEV data guard standby database it could share a server with another database.

I think you should have all environments as close to same as possible. (e.g. if you train like you fight, you will fight like you train).

I would welcome your thoughts on this discussion and even more on any general philosophical considerations you have on the entire subject on dev/qa/prod environments, etc.

Thank you,

Robert.

and Tom said...

I have an opinion on this (surprise surprise :) )

My thought is - there is no such thing as a non-production database. They are all production databases.

Your development environment - it should probably be running in archive log mode with regular backups. If it failed for whatever reason - could you afford to lose a day (or more) of development work? Is that "free" - the development efforts cost nothing? What do the developers do while this system is down - other than mourn the loss of the days work?

Having a data guard instance - for the reasons you state - would make sense. The developers would be working in the actual environment they'll deploy into, the DBA's get the "practice", you become more experienced with it, and it is there if you need it.

Unless it was totally cost prohibitive - I would be a supporter of the idea, yes. Definitely have it in archive log mode with regular backups - and if the data guard fits into your scheme, there is nothing wrong with doing it.

Rating

  (3 ratings)

Is this answer out of date? If it is, please let us know via a Comment

Comments

How about RAC?

Robert Wood, August 21, 2008 - 11:53 am UTC

Tom,

<hoping this follow up falls into same category>

What about a RAC implementation in the same environment?

I am reading that there is a significant (potential) impact on the way SQL/code runs
in a RAC environment.

Our current plan is to only have RAC in the QA environment, but I think the Developers will wind up doing too much 'trial and error' debugging of their RAC performance in QA.

It seems even more so with RAC that there should be a separate DEV environment(?)

Would you please comment on this?

Thanks!

Robert.
Tom Kyte
August 21, 2008 - 9:59 pm UTC

I would definitely want RAC all of the way down.

definitely on that.

Robert, August 21, 2008 - 10:09 pm UTC


What do the developers do while this system is down - other than mourn the loss of the days work?

Sokrates, August 22, 2008 - 6:59 am UTC

reading asktom maybe ?
more

Connor and Chris don't just spend all day on AskTOM. You can also catch regular content via Connor's blog and Chris's blog. Or if video is more your thing, check out Connor's channel and Chris's channel from their Youtube channels. And of course, keep up to date with AskTOM via the official twitter account.