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: So how big is your buffer cache ?

Tim Gorman

2004-08-28

Replies:
Richard,

AWE only allows addressability to 16Gb, so I'm not sure where Mr Burleson
calculated "working sets of 30-gig" or how he did so (or why), as that
certainly won't fit into AWE-enabled SGAs. Hopefully, he's not simply
summarizing the virtual-memory numbers for all the processes in a database
instance, as that double-counts things like the text of the Oracle
executable and the shared SGA?

The mention of the phrase "working sets" to me suggests sorting, which is an
activity performed in the PGA, not the SGA. Since Mr Burleson's recent book
"Creating a Self-Tuning Oracle Database" (first chapter, first page, first
sentence, first paragraph) claims that the UNIX function call "malloc()" is
used to create the SGA, I can see where his confusion between the SGA
(created on UNIX with the "shmat()" and related system calls) and the
PGA/UGA (created on UNIX using the "brk()" system call) exists. It is
possible that the SGA could be utilized for sorting if one uses a regular
tablespace as their temporary tablespace (i.e. tablespace not created as
TEMPORARY), but I'm sure that this isn't under discussion.

As the AWE extension can only benefit the Buffer Cache (not anything else in
the SGA) and certainly not the PGA, I'm really confused as to what the
phrase "working sets" is intended to mean. No matter, anyway...

The claim of "ALWAYS with great results" would also benefit from better
substantiation since the use of the parameter "use_indirect_data_buffers"
(required for AWE) is also incompatible with all of the SGA management
functionality of 9i, such as dynamically changing the sizes of the Buffer
Cache, Shared Pool, Large Pool, Buffer Cache Advise, etc. I'm pretty sure
I've seen articles by Mr Burleson touting these features in equally
superlative terms? And the name of the parameter, mentioning "indirect data
buffers" (which is a rare example of excellent naming by Oracle development
:-) ), also provides insight into some of the performance overhead incurred
by the use of the feature that the acronym "AWE" (i.e. address windowing
extensions?) certainly doesn't convey.

So, right away, there are at least two caveats to the claim of "ALWAYS with
great results": need to give up 9i SGA management functionality and need
sufficient CPU resources to accommodate the additional processing of
indirection when referencing buffers in the Buffer Cache using AWE.

Anyway, it appears that the original poster in question tuned a couple SQL
statements and all his concerns and problems subsided, so the approach of
"understand first, then fix" seems to have won a rare victory over the
approach of feeding more resource to a resource-consumption problem as first
principles instead of as a last resort.

Thanks!

-Tim



on 8/28/04 5:56 AM, Richard Foote at richard.foote@(protected):

> Hi All,
>
> In an interesting insight into how Don Burleson performs tuning at the
> c.d.o.s newsgroup
> (http://groups.google.com/groups?dq=&hl=en&lr=&ie=UTF-8&th=73f606eef5e7e99f)
> . Don suggests he has "no problem throwing hardware at crappy code when the
> client doesn't want to tune it". He's also basically recommending using AWE
> and utilising all available RAM on 32bit windows, whether you need to or
> not. I mean, AWE has no disadvantages right ... :)
>
> However, he also makes the claim that "It's not uncommon to see working sets
> of frequently-referenced data of for than 30-gig for a large database. AWE
> is a great techniques for 32-bit Windows databases and I do it for dozens
> of databases every year, ALWAYS with great results."
>
> So my question to you all is how large are your largest buffer caches ? How
> many of you have a buffer cache that is 30G+ ? And on 32bit windows ?
>
> Love to know !!
>
> Cheers
>
> Richard
>
>
> ----------------------------------------------------------------
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> ----------------------------------------------------------------
> To unsubscribe send email to: oracle-l-request@(protected)
> put 'unsubscribe' in the subject line.
> --
> Archives are at http://www.freelists.org/archives/oracle-l/
> FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
> -----------------------------------------------------------------

----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to: oracle-l-request@(protected)
put 'unsubscribe' in the subject line.
--
Archives are at http://www.freelists.org/archives/oracle-l/
FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------