Non default blocksize - how handled by Solaris?
DBAsupport.com Forums - Powered by vBulletin
Results 1 to 9 of 9

Thread: Non default blocksize - how handled by Solaris?

  1. #1
    Join Date
    Dec 2001
    Location
    Keene, NH
    Posts
    510

    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.

  2. #2
    Join Date
    Nov 2000
    Location
    greenwich.ct.us
    Posts
    9,092
    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
    marist89@yahoo.com
    http://marist89.blogspot.com/
    Get Firefox!
    "I pledge to stop eating sharks fin soup and will not do so under any circumstances."

  3. #3
    Join Date
    May 2002
    Posts
    2,645
    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.

  4. #4
    Join Date
    Dec 2001
    Location
    Keene, NH
    Posts
    510
    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!

  5. #5
    Join Date
    Aug 2002
    Location
    Colorado Springs
    Posts
    5,253
    note also that DB_FILE_MULTIBLOCK_READ_COUNT relates to the database default block size, not the individual tablespace block size.
    David Aldridge,
    "The Oracle Sponge"

    Senior Manager, Business Intelligence Development
    XM Satellite Radio
    Washington, DC

    Oracle ACE

  6. #6
    Join Date
    Dec 2001
    Location
    Keene, NH
    Posts
    510
    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?

  7. #7
    Join Date
    Aug 2002
    Location
    Colorado Springs
    Posts
    5,253
    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.
    David Aldridge,
    "The Oracle Sponge"

    Senior Manager, Business Intelligence Development
    XM Satellite Radio
    Washington, DC

    Oracle ACE

  8. #8
    Join Date
    Dec 2001
    Location
    Keene, NH
    Posts
    510
    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).

  9. #9
    Join Date
    Dec 2002
    Location
    Bangalore ( India )
    Posts
    2,434
    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
  •  


Click Here to Expand Forum to Full Width