Physical Data Guard as Test Database?

Question

I am in a new shop and the first DBA in the shop. On the first day I see that they have ‘tablespace full’ problems because people are running test jobs on the production database – reports, I hope!
This is a 10g database on hp/ux.
I will suggest that I create a proper test database as a physical standby database from production. The amount of data in the production database is not enormous. There is just a need to create a test system good enough to pull the testers off the production system.
But what about the day that someone mangles the test system? How do you get a physical standby database back in sync? Restore from backup and reapply logs? Recreate the standby from production? Or is there a better way to do all this than physical standby?
TYIA

Answer 1

1) Running reports should never cause tablespaces to fill up. Selecting data doesn't cause any data to be written to tablespaces. You might get errors related to exhausting the TEMP tablespace if the reports are doing a lot of sorts, but it doesn't sound like that's what you're seeing.
2) You would not normally create a test database as a standby of the primary database. Normally, you would take a backup of the production database and restore that backup on to the test server, rename the database, and open it up as the test system. Assuming you're using RMAN to back up the production database, this should be relatively straightforward.
3) Normally, you would then schedule a regular restore of the production backup to the test server in order to refresh the test system. That's normally something that's done roughly monthly, but that depends on the frequency of your builds and how frequently you need pristine and/or updated data in the test system. In addition to providing a test system, doing regular restores is a great way to validate your backup and recovery strategy in a relatively low-stress environment-- it's much nicer to discover that the process that writes to tape has been broken for 3 weeks when you're attempting to refresh the test database than when the production database has failed and angry users are standing outside your cube demanding that you get the database up now.
4) Going back to #1, though, if data tablespaces are filling up, that would seem like something that should be investigated in addition to the lack of a test environment.
Justin