Re: Incremental Backup and Change Block Tracking Questions

3. In 10g, compression is quite CPU intensive. However, if your backups are extremely I/O bound (or network bound), OR if you have an abundance of CPU available during your backup window, RMAN compression can definitely be worthwhile.

At one client, I have a large (>400GB) database on NFS. Backups are written to NFS, too. RMAN compression appears to reduce backup time by about 50%, although testing is not yet complete there.

At another client, I have (fast!) fibre-channel disks, and a small (< 20 GB) database. Backups are to disk. The server has about 16 CPU cores, which are all dead idle during backups. RMAN compression reduces backup time from about 18 minutes to around 12 minutes. (Although, frankly, I wonder why I bother..) With compression, though, I *am* able to keep more backup cycles on disk.

4. BCT is an EE feature in 10g, as I recall. RMAN compression too, no doubt. But neither comes at "extra cost"; you either get it or you don't depending on the database edition. "Oracle Secure Backup" however, is separately licensed, I think, probably for >= 2 tape drives. I've never been especially interested in it, so I haven't bothered to look closely at the rules though.

If it is what I think it is, the "product editions" link mentioned earlier in this thread does a great job of describing which backup feautures are bundled with which editions. Aside from Oracle Secure Backup, though they are *never* extra cost; if you are on SE and you need an EE backup feature, the only way to get it is to upgrade to EE. (Doubtless, somebody will soon respond with an exception, but this is at least a good general rule...)

If in doubt, talk to your Oracle sales rep. Answering questions like these is what they get paid for. And they are even probably pretty reliable, too. :-)

5. Well, if you backup directly to tape, AND your tape drives are directly attached to the database server, AND you have no significant I/O bottlenecks between the tape drive and the database, then using the tape drive's hardware compression is almost a no-brainer.

Sadly, however, it has been *at least* 10 years since I last saw a tape drive directly attached to a database server. Maybe 15. It seem much more common that tape drives (when they are present at all) are separated from the database server by one or more segments of TCP/IP network. This seems to be as popular with PHBs as OLTP databases on RAID-5 storage. (Why is my database/backup so slow? But, hey! Look at all the money I saved!)

If you are backing up over a network (unless -- maybe -- it is a dedicated Gbit network) software compression can significantly improve throughput, even if the tape drives at the other end of the wire *are* capable of "faster" hardware compression. Providing you can afford the CPU hit, that is.

On Fri, Feb 22, 2008 at 8:52 AM, Sam Bootsma <sbootsma_at_georgebrown.ca> wrote:

> Hello all,
>
>
>
> Oracle 10.2.0.3, Enterprise Edition, on AIX 5.3.
>
>
>
> I am preparing to change our RMAN backups to use Incremental Backups and
> Change Block Tracking. I am also considering to use compression. But first
> I have a few questions that I hope you can assist with.
>
>
> ...
>
> 3. How much of a performance hit using the Change Block Tracking feature?
> What about Oracle compression?
>
>
>
> 4. Do you know if any of these features are additional cost? Do you know
> if there is a view in Oracle that outlines what features come with EE and
> what features are additional cost?
>
>
>
> 5. We also have the option to do compression at the tape drive level. Is
> anybody aware of any reason that Oracle compression (during backup) would be
> better or worse than letting the tape drive do it?
>
>
> ...
>

-- 
Cheers,
-- Mark Brinsmead
  Senior DBA,
  The Pythian Group
  http://www.pythian.com/blogs

--
http://www.freelists.org/webpage/oracle-l