Re: Keep pool

From: Vasu Balla <vballa_at_triniti.com>
Date: Fri, 12 Mar 2004 22:39:12 +0530
Message-ID: <4051EEB8.8070803@triniti.com>

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:

Message
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@za.didata.com
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@freelists.org [mailto:oracle-l-bounce@freelists.org] On Behalf Of Lex de Haan
Sent: 12 March 2004 14:22 PM
To: oracle-l@freelists.org
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@freelists.org [mailto:oracle-l-bounce@freelists.org]On Behalf Of George Leonard
Sent: vrijdag 12 maart 2004 13:08
To: oracle-l@freelists.org
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@za.didata.com
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@freelists.org [mailto:oracle-l-bounce@freelists.org] On Behalf Of Lex de Haan
Sent: 12 March 2004 14:04 PM
To: oracle-l@freelists.org
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@freelists.org [mailto:oracle-l-bounce@freelists.org]On Behalf Of George Leonard
Sent: vrijdag 12 maart 2004 12:52
To: oracle-l@freelists.org
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@za.didata.com
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@freelists.org 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 ----------------------------------------------------------------- Received on Fri Mar 12 2004 - 11:08:45 CST