Subscribe to Blog via Email
Follow me on TwitterMy Tweets
Let’s say you have a database that everything can be recreated just by re-running a process and no nightly backups are required- the database would be quicker to recreate from the backup running on it’s source database than restoring from a nightly backup or taking the performance hit of doing so. Let’s say you have three tablespaces that are on I/O fusion cards that aren’t protected by hardware mirroring and losing these three could be more of a challenge than the business would like to have.
What options could you come up with to protect those tablespaces?
Now you realize that the data that resides on these tablespaces are NEVER written to post their initial creation- they are read only objects!
This was a solution that we came up due to this unique scenario-
Most DBA’s are a bit obsessive compulsive and I performed numerous tests, verifying that I could alter the tablespaces to read only and then perform all the standard processing that would occur in a normal day.
I then had a lot of fun copying the files over, deleting a few from the original location and attempting the processing again, watching the database shrill in complaint as it could not locate one or another datafile.
Testing involved ensuring that I performed a cycle of the database to a restricted mode to alter the tablespaces to read only, as any access to the objects could create a situation where the alter statement could hang, waiting till it had sole access to all datafiles involved. Tasks such as cycling through logs, creating other objects and re-starting the process, having the database act as if nothing was amiss to begin with is a bit bizarre. It almost seemed too simple at times, but this gives us the recoverability we need for our I/O fusion card data, but doesn’t impact the best performance and best choice for a unique database environment.