Home
All Oracle Error Codes
Oracle DBA Forum

Frequent Oracle Errors

TNS:could not resolve the connect identifier specified
Backtrace message unwound by exceptions
invalid identifier
PL/SQL compilation error
internal error
missing expression
table or view does not exist
end-of-file on communication channel
TNS:listener unknown in connect descriptor
insufficient privileges
PL/SQL: numeric or value error string
TNS:protocol adapter error
ORACLE not available
target host or object does not exist
invalid number
unable to allocate string bytes of shared memory
resource busy and acquire with NOWAIT specified
error occurred at recursive SQL level string
ORACLE initialization or shutdown in progress
archiver error. Connect internal only, until freed
snapshot too old
unable to extend temp segment by string in tablespace
Credential retrieval failed
missing or invalid option
invalid username/password; logon denied
unable to create INITIAL extent for segment
out of process memory when trying to allocate string bytes
shared memory realm does not exist
cannot insert NULL
TNS:unable to connect to destination
remote database not found ora-02019
exception encountered: core dump
inconsistent datatypes
no data found
TNS:operation timed out
PL/SQL: could not find program
existing state of packages has been discarded
maximum number of processes exceeded
error signaled in parallel query server
ORACLE instance terminated. Disconnection forced
TNS:packet writer failure
see ORA-12699
missing right parenthesis
name is already used by an existing object
cannot identify/lock data file
invalid file operation
quoted string not properly terminated

Re: PGA usage

Yavor Ivanov

2007-07-10

Replies:

 Hello, frits

 Yes, the /3GB switch is set. And I am using the folowing query to identify who is eating the PGA:
select sysdate q_time, s.sid, n.name, s.value
from v$statname n, v$sesstat s
where n.statistic# = s.statistic#
and n.name in ('session pga memory')
order by 4 desc, 2;

 The report is just one nasty query, which joins lots of tables and calls some very basic pl/sql functions about a gazillion times - no arrays, no cursors, nothing special. Just big sorts and lots of hash joins in the plan, and basically everything you can think of when you think about nightmare execution plans. And no hints, by the way.
 But, even if it will be much slower, I just can't understand why is all this happening in memory and not in TEMP. This leads to whole database instability - any session can get ora-4030 during the report, when the memory reaches 3 GB.

--
Regards,
Yavor Ivanov
Senior Database Expert
Stemo Ltd

On Tue, 10 Jul 2007 17:14:57 +0300, Frits Hoogland <frits.hoogland@(protected):

> Yavor,
>
> I assume the /3GB switch is set (otherwise the memory available in userspace
> is limited to 2GB)
>
> The PGA memory can be monitored per session using v$sesstat. Can you
> elaborate on what the report is actually doing? (I suspect a pl/sql table is
> populated, which is kept in the PGA and doesn't get to the assigned
> temporary tablespace like sort data or hash data.)
>
> AFAIK, the amount of PGA memory which can be allocated by a session is only
> limited to operating system imposed limits.
>
> frits
>
> On 7/10/07, Yavor Ivanov <Yavor_Ivanov@(protected):
>>
>>      Hello, gurus
>>
>>      I have some problems with Oracle 10.2.0.3 on Windows 2003 32-bit.
>> We have PGA_AGGREGATE_TARGET set to 350 MB and a SGA of 2200 MB. Some of the
>> sessions are shared server ones (which take memory from the large pool), and
>> others are dedicated. Sometimes, when some big-fat report is running, the
>> actual PGA allocated grows up to 550 MB and more. Then we are getting
>> ora-4030, because we hit the 3 GB limit of 32 bit windows.
>>      In this cases I can see that one dedicated connection (the one
>> running the big report) has allocated up to 280 MB PGA (this is, one
>> session!). We are not using parallel things, if it matters at all.
>>      I know PGA_AGGREGATE_TARGET is just a target, not a limit. But I
>> wonder is there any way to limit how much PGA can a single session consume.
>> I thought there is a rule stating no session can eat more than 10% than the
>> total target, but this proved to be wrong.
>>
>> --
>> Regards,
>> Yavor Ivanov
>> Senior Database Expert
>> Stemo Ltd
>> --
>> http://www.freelists.org/webpage/oracle-l
>>
>>
>>
>

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