RE: *****SPAM***** RE: Any performance benefits in going to db_16k_cache_size or db_32k_cache_size

From: Hameed, Amir <Amir.Hameed_at_xerox.com>
Date: Wed, 10 Jan 2007 11:55:57 -0500
Message-ID: <77A4D80DB2ADD74EB5D7F1D31626F0C0038A7CD4@usa0300ms03.na.xerox.net>

If the OS block size is 8k and the primary DB block size is also 8k then if you introduce an additional buffer of size, say either 2k or 16k then how would it impact the way OS is reading the blocks?

---

        From: oracle-l-bounce_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Tanel Poder

	Sent: Wednesday, January 10, 2007 11:36 AM
	To: cary.millsap_at_hotsos.com; mark.powell_at_eds.com;
oracle-l_at_freelists.org
	Subject: *****SPAM***** RE: Any performance benefits in going to

db_16k_cache_size or db_32k_cache_size                  

        Yeah, I agree with Cary and Mark and would add a comment that a tricky thing like changing block size (thinking about granularity of buffer locking) should be tested with simulating real concurrency.          

        E.g. your single session index lookup might run faster due lower index height, but on the other hand you could have more buffer busy waits in high-concurrency environments, etc..                    

        Tanel.                  

---

                From: oracle-l-bounce_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Cary Millsap

		Sent: Thursday, January 11, 2007 00:13
		To: mark.powell_at_eds.com; oracle-l_at_freelists.org
		Subject: RE: Any performance benefits in going to

db_16k_cache_size or db_32k_cache_size                                  

                I have the same opinion as the one Mark describes here.                  

                One more comment: Why guess, when you can KNOW.                  

                If you need to know, test it, and measure the performance.                                    

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

Received on Wed Jan 10 2007 - 10:55:57 CST