RMAN for vldb

Question

I have a 3.2TB database. The majority of the data resides in 18 partitioned tablespaces, 9 for data and 9 for index. The rest of the database is quite small, by comparison. Most of the data is input with no logging, but when in archivelog mode this database generates a huge amount of logs.
What we envision is to:
- put the database in archivelog mode, for the duration of the backup only.
- put the partitioned tablespaces in read-only mode
- export the data and index partitions as transportable tablespaces.
- copy the datafiles to a secondary disk location (takes about 15-20 hours)
- perform an incremental rman backup for the remaining database
- put the tablespaces back in read-write
- put the database in noarchivelog mode.
does this make sense? are there any serious flaws in the logic here?
all suggestions greatly appreciated.
.

Answer 1

since you are using emc, emc has its own utility for doing mirroring -- it used to be called timefinder, but it's changed to something else now -- i just can't think of it offhand. basically what happens is that the whole database goes into backup mode and then the mirrors are split, then you take your primary database out of backup mode and just keep going. when the backups are finished, you repeat the process of putting the database in backup mode and then the disks, primary and mirror, are re-synced. this can be handled in a script -- usually run by root.
the split process happens in a couple of minutes. it's not a big deal. the main concern about mirroring however is that it requires 2x the number of disks since everything is duplicated between the 2 sets. one thing that is kind of nice is that if your administrators set it up correctly, you can mount the mirrored database to another like host and copy it off. like i said, it's not cheap but if your availability requirements are such that you need to have that kind of high availability, you might persuade your management to go down such a path. hitachi also has mirroring capabilities as does the ibm shark (i think). i have worked with both emc and hitachi with decent results. the mirror split is a function of the disk software not the o/s.
you can also use mirrors as your primary backup and eliminate the need to do RMAN or user-managed backups. it just all depends on how you set them up. like i said, if you can afford it, it's a very effective way to go.
we don't have mirrors here... in fact getting storage at all is a major undertaking. so here's what i managed to do. bear in mind that the 2nd array is not the same hardware as the first, so mirroring was not an option.
i moved the files to a different set of disks connected by san to the same host. they just added a 6920 array to our san and that is where i built our duplicate database and copied the files for the transportable tablespaces. our san is not configured well and the admins don't seem to know how to fix it, so our through-put is kind of bad. we are lucky to get 50M/second. we did write a copy command that avoids using the o/s cache -- it makes the copies take a bit longer, but you don't have lrud hogging the cpu the whole time so the system doesn't grind to a complete halt.
i have written directly to tape before. you will need 3rd party APIs to do it. i used Tivoli and the API is called ODP (oracle data protection) which is supplied by Tivoli (the storage/tape management vendor). how well writing to tape works is a function of where the tapes are connected (direct connect versus network connected), how many drives you have access to and what speed they are. if you are using mirrors, it may not be that big a concern how long it takes to backup to tape, but if you aren't and with the size of your database, that can be a problem. at a previous employer, the databases that weren't mirrored backed up to a disk pool and that was backed up to tape for offsite storage. if you do go directly to tape using the API, RMAN can keep track of what tape is needed to do the restore. if you back up to disk first, you will have to know what tapes are needed and restore manually to disk before you can get RMAN to restore. there are tradeoffs depending on the route you take.
so hopefully that covers your questions. if i left anything out or if you think of something else, just let me know.
GL