E-LSubject: RE: Big SGA...
... large burlap sack and a small bat
-Original Message-From: Loughmiller, Greg
[mailto:[EMAIL PROTECTED]Sent: Tuesday, March 04,
2003 7:39 AMTo: Multiple recipients of list
ORACLE-LSubject: RE: Big SGA...
Now you mention it, I have seen some other
operating system use a reference to 'large'
(4MB) pages.
I have heard some comments, though, about
one of the Solaris versions not being able
to use shared page tables (ISM) when the
SGA goes over a critical limit - but this could
be highly version-depen
Linux has two patches to deal with that. One is the "highpte" patch which
allows page table entries in "high memory" (i.e. after 1Gb). The other is
"bigpages" which allows larger pages (i.e. 4mb instead of 4kb), thus fewer
page table entries. Both patches are for Red Hat AS 2.1. I imagine that
Title: RE: Big SGA...
... applied to the parent who spoiled the child ...
Jerry Whittle
ASIFICS DBA
NCI Information Systems Inc.
[EMAIL PROTECTED]
618-622-4145
-Original Message-
From: Kevin Lange [SMTP:[EMAIL PROTECTED]
... large burlap sack and a small bat
A late-breaking thought - but it's not my area
of expertise, so others may laugh.
If you have a very large SGA, don't you end
up with a very large 'page table' at the O/S
level to map virtual memory to real memory.
And if you do, doesn't this affect the speed
and cost of a context switch. If so,
... large burlap sack and a small bat
-Original Message-From: Loughmiller, Greg
[mailto:[EMAIL PROTECTED]Sent: Tuesday, March 04, 2003
7:39 AMTo: Multiple recipients of list ORACLE-LSubject:
RE: Big SGA...
duct
tape
-Original Message-From: Tim
duct
tape
-Original Message-From: Tim Gorman
[mailto:[EMAIL PROTECTED]Sent: Monday, March 03, 2003 5:10
PMTo: Multiple recipients of list ORACLE-LSubject: Re:
Big SGA...
Sybase, Schmybase, Oracle, Schmoracle -- the
concepts are still the same. Developers create
anything, only
> > accomodated it by throwing resources at it.
> >
> > Pop quiz: Think of a parent with a spoiled child
> > who is making a scene in public. How do you quiet
> > the child? :-)
> > - Original Message -
> > From: Loughmiller, Greg
> accomodated it by throwing resources at it.
>
> Pop quiz: Think of a parent with a spoiled child
> who is making a scene in public. How do you quiet
> the child? :-)
> - Original Message -
> From: Loughmiller, Greg
> To: Multiple recipients of list ORACL
h a spoiled
child who is making a scene in public. How do you quiet the child?
:-)
- Original Message -
From:
Loughmiller, Greg
To: Multiple recipients of list ORACLE-L
Sent: Monday, March 03, 2003 2:28
PM
Subject: RE: Big SGA...
one
little piece of informat
Title: RE: Big SGA...
BINGO!!
The politics is definitely a key contributor to all projects here in this shop:-)
greg
-Original Message-
From: Stephen Lee [mailto:[EMAIL PROTECTED]]
Sent: Monday, March 03, 2003 3:39 PM
To: Multiple recipients of list ORACLE-L
Subject
ssage-From: Tim Gorman
[mailto:[EMAIL PROTECTED]Sent: Monday, March 03, 2003 2:02
PMTo: Multiple recipients of list ORACLE-LSubject: Re:
Big SGA...
Please start using STATSPACK now to gather and
keep statistics. You are certainly going to need "before" and "after"
I know of one system where it would have been
beneficial to have an 8GB buffer_pool_keep
(as you might guess, this was a specialised
telecomms system); but I think the general rule
should be to consider very large memory as a
requirement that has to be proved, rather than
an obvious easy option.
One additional consideration on this topic is the politics of the situation.
If your shop is one where development has undue influence on upper
management decisions (i.e. the tail wagging the dog), the politics might be
such that garbage is deployed and it's expected that the support people
(i.e.
CLE-L
Sent: Monday, March 03, 2003 10:59
AM
Subject: Big SGA...
hey folks..
Hoping
for a little feedback and opinion please. Having a discussion with the
development group ...
The development
group is thinking that a VERY LARGE SGA would solve some of their I/
We have SGA's as large as 22 Gb. I don't know that this solves any of the
inherent application problems, but it doesn't appear to cause any problems.
OS here is Tru64.
-Original Message-
One could suggest that they could "cache" some very large tables in the SGA;
but there seems to be so
]
[mailto:[EMAIL PROTECTED] On Behalf Of Loughmiller,
Greg
Sent: Monday, March 03, 2003 11:59
AM
To: Multiple recipients of list
ORACLE-L
Subject: Big SGA...
hey folks.. Hoping for a little feedback and opinion please.
Having a discussion with the development group ...
The development
hey folks..
Hoping for
a little feedback and opinion please. Having a discussion with the development
group ...
The development
group is thinking that a VERY LARGE SGA would solve some of their I/O problems.
For example, they believe that a SGA consisting of over 8GB of db block buffers
18 matches
Mail list logo
