Home » RDBMS Server » Server Administration » Recommendations for maintaining Prod support DB
icon5.gif  Recommendations for maintaining Prod support DB [message #293726] Mon, 14 January 2008 14:53 Go to next message
jssc
Messages: 1
Registered: January 2008
Location: Irvine, CA
Junior Member
Recommendations for maintaining Production Support DB

I'm investigating available methods for maintaining a production support DB. It needs to contain all production data, kept current or refreshed nightly. It will only be used when we need to determine the resolution for a (rare) production data issue. However, when we have issues, we may have them a couple days in a row, so the time required to re-sync the DB after using for production support is important.
The DB is currently 400GB and growing. There seems to be several techniques that may be used, any comments/suggestions would be appreciated.
1) setup a Data Guard standby database. If needed to investigate an issue,would we be able to disable DG replication with no impact to the production side? After the issue was resolved, what steps would be needed to resume data guard (assume we had to modify some data)
2) Use Oracle streams to maintain current data in the PS DB. Could we 'pause' the streaming replication while researching an issue? After the issue was resolved, what steps would be needed to resume the replication?
3) I've had very little exposure to RMAN. Does it have features that I might take advantage of for this purpose?
4) any other tecniques?
Re: Recommendations for maintaining Prod support DB [message #293729 is a reply to message #293726] Mon, 14 January 2008 15:01 Go to previous messageGo to next message
Michel Cadot
Messages: 64132
Registered: March 2007
Location: Nanterre, France, http://...
Senior Member
Account Moderator
1) is the most appropriate.
If you have to open the standby in read-write mode to solve your problem then you have to recreate it (with RMAN for instance).
If you can solve the problem in read only more then you just have to return in recovery mode.

Regards
Michel
Re: Recommendations for maintaining Prod support DB [message #293788 is a reply to message #293726] Tue, 15 January 2008 00:20 Go to previous messageGo to next message
mkbhati
Messages: 93
Registered: February 2007
Location: Mumbai
Member
If you have issues with RMAN than Streams may suit your requirement. In streams you have full control over replication. Streams Replication are little complex to setup but one done properly it goes on for years without problems. Also it has low network overhead if long distances are involved. One fine thing you have option to replicate selected schema/schemas or table/tables or full database as per your need. I hope your requirement is only one way replications. I am giving below some fine pointers for you to explore but best pointer is Oracle documentation.

http://www.psoug.org/reference/streams_demo1.html
http://www.psoug.org/reference/streams_demo2.html

Regards

Manjit Kumar [mkbhati]



[Updated on: Tue, 15 January 2008 00:21]

Report message to a moderator

Re: Recommendations for maintaining Prod support DB [message #293898 is a reply to message #293726] Tue, 15 January 2008 09:36 Go to previous message
MikeSanders
Messages: 6
Registered: December 2007
Junior Member
Hi.

I had similar problem. I'm trying a different approach:
Cloning the 'reference-area' only to the support DB, and when problems encountered in Production copy only relevant applicative data.
[Edit]
The reference area (assuming it's read-only for your processes)doesn't need to be cloned - you could just use synonyms from your support DB.

This potentially saves the storage needed for a full clone and the time it takes to do it.

For more on this - check my post in this same category.
http://www.orafaq.com/forum/t/93564/116146/

[Updated on: Tue, 15 January 2008 09:48]

Report message to a moderator

Previous Topic: dbms_aw package creation
Next Topic: full temp tablespace at startup
Goto Forum:
  


Current Time: Wed Dec 07 14:49:04 CST 2016

Total time taken to generate the page: 0.17419 seconds