RE: Problem with large SGA

Daniel,  

Start using Rman. Begin/End backup is so passé. :-)  

Obviously you can roll your init.ora params back down to a level where the backups can complete in a more reasonable window.  

You can also have two sets of init.ora params. One for performing backups and one for normal operations. Bounce the database, reset your params to a smaller value, and perform your backups. Kind of defeats the purpose off keeping the database up all the time, but I think you shot yourself in the foot with this one.  

Seriously, look into using Rman. If you absolutely need your cache values to be this high, then you may not have a workaround (you heard it from Oracle - expected behavior for a database release that they will not patch anymore).  

Hope this helps!  

Tom  

From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of daniel.hubler_at_aurora.org Sent: Friday, October 07, 2005 2:24 PM
To: oracle-l_at_freelists.org
Subject: Problem with large SGA  

Oracle v8.1.7.4
OpenVMS 7.3-2

We recently increased the size of our SGA from 40gig to over 100gig by increasing our shared pool and block buffer cache. Everything has gone very well.

One side effect we have encountered is that the time it takes to put all our tablespace into HOT backup (ALTER TABLESPACE xxxxx BEGIN BACKUP;)
has gone from 1 hour to about 3.5 hours. In retrospect, this makes some sense as the buffer cache is examined for blocks from the specific tablespace to be written to disk; more cache to examine so it takes more time.

Oracle has confirmed this. We have received the "expected behavior" answer regarding this issue.

Anybody have any ideas on how to minimize the impact of this?

Dan Hubler
Database Administrator
Aurora Healthcare
daniel.hubler_at_aurora.org

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