> 1) The TR defines a sequence in which all tablespaces are
> placed into hot backup mode. It has been suggested that this step might take
> an extended period of time. Our tests to date have been on relatively small data
> volumes and the "ALTER TABLESPACE <name> BEGIN BACKUP;" steps
> have been almost instantaneous.
> Is it likely that this step would end up taking longer (say
> tens of minutes) for large DBs ?
>
No, the Alter Tablespace command will always be virtually instantaneous. It does not depend on the size of the tablespace. That command is simply setting a "flag" in the control file and in the database so that the database is aware of what datafiles are being backed up, and so additional logging occurs for transactions associated with those datafiles.
Of course if you have hundreds of tablespaces, then the sum can add up. In other words, hundreds of tablespaces could take more than a couple of seconds. The good news is that with ONTap version 6.x, the SnapShot creation is virtually instantaneous as well, so even if it took 60 seconds to alter all the tablespaces, the database would be in hot backup mode only a minute or so.
> During testing we have found that recovering the entire
> snapshot (with all data files from all schemas) works fine. But when we have
> recovered only the single datafile related to one schema, we have run into
> problems. I feel we may be overlooking some basic issue here.
Not sure what you might be overlooking. Oracle is extremely recoverable. In order to accomplish what you want, it should be very straightforward. I have recovered individual datafiles and tablespaces with SnapShots many times with no problems.
Doing that should not affect any other users, providing that individual schemas are in seperate tablespaces. You need to take the affected tablespace offline, replace the affected datafile(s) from the proper SnapShot directory (simply copy them over the originals) then run recovery using either the "datafile" or "tablespace" directive. As in
alter database recover datafile '/oradata/foo.dbf';
or
alter database recover tablespace foo;
You can issue either of those commands when the database is open providing that the tablespace is offline.
Hope that helps.
-tom