RE: Keep pool
- From: "George Leonard" <leonarge@xxxxxxxxxxxxx>
- To: <oracle-l@xxxxxxxxxxxxx>
- Date: Mon, 15 Mar 2004 06:49:24 +0200
Hi there
If it Is swapping at OS level let your Sun admin have a look, remember
Solaris will always be ding swapping out and this is normal and not a
problem, the one you have to avoid is the swapping back, that is no
good.
George
________________________________________________
George Leonard
Oracle Database Administrator
Dimension Data (Pty) Ltd
(Reg. No. 1987/006597/07)
Tel: (+27 11) 575 0573
Fax: (+27 11) 576 0573
E-mail:george.leonard@xxxxxxxxxxxxx
Web: http://www.didata.co.za
You Have The Obligation to Inform One Honestly of the risk, And As a
Person
You Are Committed to Educate Yourself to the Total Risk In Any Activity!
Once Informed & Totally Aware of the Risk,
Every Fool Has the Right to Kill or Injure Themselves as They See Fit!
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Vasu Balla
Sent: 12 March 2004 19:09 PM
To: oracle-l@xxxxxxxxxxxxx
Subject: Re: Keep pool
Hi George,
even we have a 880 with 16GB ram solaris 9, what my question is how do
we use the other 10GB which is not being used. i feel that our system is
swapping too much , so want to use the rest. it hosts two Oracle Apps
11.5.9 instances.
your reply will be greatly appriciated
Vasu
George Leonard wrote:
hi there
database is 400GB, about 30 GB of new data in and 30 aged out.
tables that si causing the chaining are very active in ypdate and
deletes and all vey variable length. with the 8K block size we had at
min 7% row chaining that now decreased to 1 % (problem is actually
further caused by the fact that the large tables, 5GB + also has believe
it or not 700 columns +)
ye ye, if i was to redo DB then would redo it as a complete 16K block
size. the little space wastage for the small tables would def be worth
the trde of from running mutiple block size.
as for memory on the server, V880 8 CPU + 16 GB ram of which we are
currently only using 6 GB (64bit sparc config) tied to a ok'ish
performing/Configured EMC SAN.
George
________________________________________________
George Leonard
Oracle Database Administrator
Dimension Data (Pty) Ltd
(Reg. No. 1987/006597/07)
Tel: (+27 11) 575 0573
Fax: (+27 11) 576 0573
E-mail:george.leonard@xxxxxxxxxxxxx
Web: http://www.didata.co.za <http://www.didata.co.za/>
You Have The Obligation to Inform One Honestly of the risk, And As a
Person
You Are Committed to Educate Yourself to the Total Risk In Any Activity!
Once Informed & Totally Aware of the Risk,
Every Fool Has the Right to Kill or Injure Themselves as They See Fit!
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Lex de Haan
Sent: 12 March 2004 14:22 PM
To: oracle-l@xxxxxxxxxxxxx
Subject: RE: Keep pool
OK -- so it is all about avoiding row chaining... I think I
would still try to choose one block size for your database, and take
some chaining for granted. the problem with multiple block sizes is that
you have to segment your available SGA memory, resulting in less
efficiency and more maintenance. It is a great feature, but it was never
intended as a performance feature, although the thought may seem
appealing. It is meant to open up transportable tablespaces
possibilities.
are the rows of these wide tables all fixed length? and are all
columns defined as NOT NULL? maybe the 8KB block size would be good
enough ... and the advantages of a single block size would outweigh the
disadvantages of some chaining. after all, reading a single 16 KB block
is not that much cheaper than reading two 8 KB blocks, certainly not
when part of a multi-block I/O scan ...
cheers,
Lex.
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx]On Behalf Of George Leonard
Sent: vrijdag 12 maart 2004 13:08
To: oracle-l@xxxxxxxxxxxxx
Subject: RE: Keep pool
hi there
firstly the database was created as a 8k block size, I
have always found this a very good block size to use.
but I do have some very wide tables and I mean very wide
that just ended up better on a 16K block. so I am using /oracle9 feature
of mutiple block sizes depended on data requirements.
George
________________________________________________
George Leonard
Oracle Database Administrator
Dimension Data (Pty) Ltd
(Reg. No. 1987/006597/07)
Tel: (+27 11) 575 0573
Fax: (+27 11) 576 0573
E-mail:george.leonard@xxxxxxxxxxxxx
Web: http://www.didata.co.za
<http://www.didata.co.za/>
You Have The Obligation to Inform One Honestly of the
risk, And As a Person
You Are Committed to Educate Yourself to the Total Risk
In Any Activity!
Once Informed & Totally Aware of the Risk,
Every Fool Has the Right to Kill or Injure Themselves as
They See Fit!
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Lex de Haan
Sent: 12 March 2004 14:04 PM
To: oracle-l@xxxxxxxxxxxxx
Subject: RE: Keep pool
Hi George,
as far as I know, this is impossible. may I ask
why you have two different block sizes in a single database?
kind regards,
Lex.
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx]On Behalf Of George Leonard
Sent: vrijdag 12 maart 2004 12:52
To: oracle-l@xxxxxxxxxxxxx
Subject: Keep pool
Hi all
I have a mix of 8K and 16K tablespaces.
As such I have configured a 8K and 16K
cache pool via:db_cache_size and
db_16k_cache_size.
I have thus far configured a kep pool
via db_keep_cache_size, but I am
guessing this will only be used for the
default block size being 8K.
How do I configure (what si the
parameter name) for a 16K keep pool ?
thanks
George
________________________________________________
George Leonard
Oracle Database Administrator
Dimension Data (Pty) Ltd
(Reg. No. 1987/006597/07)
Tel: (+27 11) 575 0573
Fax: (+27 11) 576 0573
E-mail:george.leonard@xxxxxxxxxxxxx
Web: http://www.didata.co.za
You Have The Obligation to Inform One
Honestly of the risk, And As a
Person
You Are Committed to Educate Yourself to
the Total Risk In Any Activity!
Once Informed & Totally Aware of the
Risk,
Every Fool Has the Right to Kill or
Injure Themselves as They See Fit!
This e-mail is sent on the Terms and
Conditions that can be accessed by Clicking on this link
http://www.vodacom.net/legal/email.asp "
This e-mail is sent on the Terms and Conditions that
can be accessed by Clicking on this link
http://www.vodacom.net/legal/email.asp "
"This e-mail is sent on the Terms and Conditions that can be accessed by
Clicking on this link http://www.vodacom.net/legal/email.asp "
---------------------------------------------------------------- Please
see the official ORACLE-L FAQ: http://www.orafaq.com
---------------------------------------------------------------- To
unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx put
'unsubscribe' in the subject line. -- Archives are at
//www.freelists.org/archives/oracle-l/ FAQ is at
//www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
?This e-mail is sent on the Terms and Conditions that can be accessed by
Clicking on this link http://www.vodacom.net/legal/email.asp "
Other related posts:
