Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Mailing Lists -> Oracle-L -> RE: Problem with large SGA

RE: Problem with large SGA

From: Mercadante, Thomas F (LABOR) <Thomas.Mercadante_at_labor.state.ny.us>
Date: Fri, 7 Oct 2005 15:43:33 -0400
Message-ID: <ABB9D76E187C5146AB5683F5A07336FF35FCC9@EXCNYSM0A1AJ.nysemail.nyenet>


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
Received on Fri Oct 07 2005 - 14:47:53 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US