it filled up the pga and then used 'swap' space on the hard drive. this filled up.
didnt realize this was a feature. yeah, I know i can 'tell' them to do it. I was hoping to disallow it though. > > From: "Bobak, Mark" <[EMAIL PROTECTED]> > Date: 2003/12/29 Mon PM 01:24:25 EST > To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]> > Subject: RE: large pl/sql table sucking up all memory on a server > > Ryan, > > First off, PL/SQL tables have nothing to do with the buffer cache. The > buffer cache is part of the SGA (shared memory) and is used to buffer > blocks of database datafiles. That's all that will ever be in the buffer > cache. > > PL/SQL tables are memory constructs that are allocated from the PGA (process > private memory). When you connect to an instance, (in dedicated server mode) > the background process on the server side that's allocated to serve your > connection has memory associated w/ it. That's your PGA (and UGA, for that > matter.) > > The best way to deal with this is to educate the developers. Teach them that > the LIMIT clause is their friend. Are you on 9i? PGA_AGGREGATE_TARGET may > help. I'm not sure, I've never tried that experiment on 9i. What happens > when PGA memory demand due to PL/SQL tables exceeds PGA_AGGREGATE_TARGET? > I'll have to try that test.... > > Anyhow, hope that helps, > > -Mark > > PS In the future, if this happens again, you shouldn't have to bounce the > server. Just kill the background process that's eating all the memory. > When you do that, that developers session will die, and things should quickly > return to normal. > > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Mon 12/29/2003 11:59 AM > To: Multiple recipients of list ORACLE-L > Cc: > Subject: large pl/sql table sucking up all memory on a server > One of our guys used a very large bulk collect into with a forall update. It sucked > up all the swap space on our solaris box and noone could connect to it. So we had to > bounce the server. > > I was under the impression that pl/sql tables go into the buffer cache and cannot go > large than its size? Oracle typically holds your hand with memory usage issues. Are > there any parameter settings I can use that limit the size of pl/sql tables? > > Or are they just dynamic arrays that can grow as large as you want. > > I know your supposed to use a 'limit' command on them. I didnt write it. I just > dont want it to happen again. > > -- > Please see the official ORACLE-L FAQ: http://www.orafaq.net > -- > Author: <[EMAIL PROTECTED] > INET: [EMAIL PROTECTED] > > Fat City Network Services -- 858-538-5051 http://www.fatcity.com > San Diego, California -- Mailing list and web hosting services > --------------------------------------------------------------------- > To REMOVE yourself from this mailing list, send an E-Mail message > to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in > the message BODY, include a line containing: UNSUB ORACLE-L > (or the name of mailing list you want to be removed from). You may > also send the HELP command for other information (like subscribing). > > > > >
<encoded content removed -- binaries not allowed by ListGuru>Content-Type: application/ms-tnef;
The previous attachment was filtered out by the ListGuru mailing software at fatcity.com because binary attachments are not appropriate for mailing lists. If you want a copy of the attachment which was removed, contact the sender directly and ask for it to be sent to you by private E-mail. This warning is inserted into all messages containing binary attachments which have been removed by ListGuru. If you have questions about this message, contact [EMAIL PROTECTED] for clarification.
The previous attachment was filtered out by the ListGuru mailing software at fatcity.com because binary attachments are not appropriate for mailing lists. If you want a copy of the attachment which was removed, contact the sender directly and ask for it to be sent to you by private E-mail. This warning is inserted into all messages containing binary attachments which have been removed by ListGuru. If you have questions about this message, contact [EMAIL PROTECTED] for clarification.
