-
Non default blocksize - how handled by Solaris?
Given (Solaris 8, version 9.2):
if db_block_size = 8k, then 8k blocks are stored in the default buffer pool. The size of the default buffer pool is defined by db_cache_size.
if db_16k_cache_size = 100M , then the size of the non-default buffer pool for tablespaces defined as 16k blocksize would be 100M.
Question 1:
If Solaris is configured with an 8K operating system block, how will Solaris handle read/write operations (physical disk I/O) when Oracle is working with a 16K (non default) blocksize?
Question 2 (what I want to do):
Utlimately, I would rather have a 16K blocksize. What I'm thinking is that I move tables 1-by-1 into a 16K tablespace. Would this have the same effect as if I were to rebuild the database with a 16K db_block_size? I really don't want to rebuild the dB!
As always, thanks you for your time.
-
1. you'd read two disk blocks instead of just 1
2. I have some older databases that were built with 2k block size (disclaimer: before I got here). That's the way I'm planning on dealing with them once I get them to 9i. You may need more memory because you are basically using two buffer caches, but it's a heck of a lot better than export/import for a 300G database.
Jeff Hunter
-
1) that is why Oracle says to use block sizes that are integer multiples of the OS block size
2) what does rebuild the database mean to you? To me, that means the schema needs to be re-designed (roles, RI constraints, procedures/packages re-engineered, etc.) If you mean re-create the database, then why not? export/import, transportable tablespace.
-
Yes, "re-create" the database.
import implies a multiple hours outage - perhaps it can be arranged.
Transportable tablespaces is something I had not thought of but now will.
Thanks again!
-
note also that DB_FILE_MULTIBLOCK_READ_COUNT relates to the database default block size, not the individual tablespace block size.
-
Originally posted by slimdave
note also that DB_FILE_MULTIBLOCK_READ_COUNT relates to the database default block size, not the individual tablespace block size.
Wow! That's food-for-thought! A reason to consider the re-create because our dB is a hybrid of OLTP and DSS and I need that DB_FILE_MULTIBLOCK_READ_COUNT for the DSS aspect.
Any work around for this?
-
not really -- it just means that on a db with different block sizes per tablespace, there will still only be a single size of multiblock i/o at the o/s level.
-
oh, oh, oh.....I mis-interpreted what u said in ur 1st post. I thought it would just work on tablespaces with default (not the case, I miss-understood).
"there will still only be a single size of multiblock i/o at the o/s level"
so the size of the i/o would remain DB_BLOCK_SIZE * DB_FILE_MULTIBLOCK_READ_COUNT. This may cause me to re-think and benchmark the value of this parameter (ie. bump it higher).
-
Originally posted by gopi
so the size of the i/o would remain DB_BLOCK_SIZE * DB_FILE_MULTIBLOCK_READ_COUNT.
There is some thing called I/O throughput, i.e max blocks a OS can fetch into memory from Disks per I/O. So if your "DB_BLOCK_SIZE * DB_FILE_MULTIBLOCK_READ_COUNT" > I/O throughput of OS..then guess which will dominate?
Abhay.
funky...
"I Dont Want To Follow A Path, I would Rather Go Where There Is No Path And Leave A Trail."
"Ego is the worst thing many have, try to overcome it & you will be the best, if not good, person on this earth"
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|