Re: why rman?

Tim Smith wrote:
> Hi,
> We spent a fair bit of time getting our Oracle 7.3.2 backups running
> on AIX 4.2. Such that we divide our tablespaces up to fit exactly on
> the current (4) number of tapes. We use backup scripts to write
> directly to tape.
>
> Now we upgrade to Oracle 8.1 and I wonder do we have to redo
> everything to use RMAN - and if so what are the benefits of doing so.
> We can't really afford a completely automated enterprise solution -
> such as a backup server with some such expensive software interfacing
> with our server - so what else does RMAN give?

It's an Oracle utility, so it understands the concept of an Oracle block, and thus checks each of them for corruption at the time a backup is made. If your RMAN backup succeeds, it's a sure bet that it's clean.

You can do incremental and cumulative backups with RMAN (meaning that a particular backup takes less time, because it's only backing up the delta since the last backup).

Since it knows what an Oracle block is, it knows when one is totally empty -and skips it. Therefore, backups are smaller than they otherwise would be, because it doesn't include great swathes ofempty space. Smaller backups mean bigger backups.

It makes incomplete recoveries a two-command job: restore database, recover database.

In 9i only, the block becomes the smallest unit of restore and recover, so if one block in a 16GB file becomes corrupt, you restore just that one block. The other 15.99GB of datafile remains on line, and available for use. That's high availability.

In all versions, you can throttle RMAN: don't backup at an I/O rate greater than X KB/sec. Which means you can do backups whilst the database is in use during the day, and your users won't notice a massive reduction in performance.

You can parallelize backups (backup files 1,2 and 3 simultaneously).

The list goes on and on. And no, you don't need a dedicated backup server to make use of it. You need nothing more than familiarity with the RMAN scripting language, and a control file suitably mirrored to avoid loss.

Regards
HJR
>
> thanks!
>
> Tim
Received on Mon Jan 27 2003 - 06:59:34 CST