Re: Incremental Backup and Change Block Tracking Questions
- From: "Mark Brinsmead" <pythianbrinsmead@xxxxxxxxx>
- To: sbootsma@xxxxxxxxxxxxxx
- Date: Mon, 25 Feb 2008 22:19:07 -0700
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@xxxxxxxxxxxxxx>
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
Other related posts:
