1) HP OS block size is always been 1K. Easiest way is to check size of OS block is to query log writer write block size.
In most platform, it is 512 and in HP, it is 1K. 1* select lebsz from x$kccle where rownum <2 / LEBSZ ---------- 512 2) Bigger question of ASMASM is great for performance reasons. Avoids file system based I/O (avoiding double buffering, double copy etc), appropriate striping, avoids kernel level file locking, provides asynch I/O capabilities, costs almost nothing and avoids CFS issues etc. In a pure performance point of view, ASM is superior to many file system based products. And I personally have recommended and upgraded few small clients to use ASM.
But, reasons many of us (including some of the best DBA minds I know) doesn't want to use ASM, is non-technical: 1) Organization behavior ( responsibility splits along team lines) 2) We have always done this way and so we have no reasons to change it. 3) We know file systems better and understand it. 4) We have clear visibility in to file systems, but ASM obscures much of that functionality 5) We have invested enormous money in scripting the backups & restores. 6) Our SAs doesn't like ASM. 7) Learning curve of DBAs/SAs.
We see an industry trend: Small clients tend to use ASM and avoid file system. Big clients and Fortune 500 companies, tend to stay away form ASM. Reasons above.
This almost sounds like old threads discussing rman vs file system backups etc. Many of us stayed with user managed backup (aka hot) and avoided RMAN for longest time. Now, we see almost many clients are using RMAN in one way or other.
Cheers Riyaj The Pythian Group http://www.pythian.com blog: http://orainternals.wordpress.com VIVEK_SHARMA wrote:
Thanks Folks for the support*MWF* wrote -> Unless your underlying physical media is ssd, flash, or those fancy new 4K sector drives, it is likely whatever you are looking at is assembled from 512 byte “sectors.”HP who co-anchor this benchmark gave the following:- HP-UX B.*11.31* system device block size(think this is the O.S. block size) = 1K Base page size = 4K. DB_block_size = 8KThis seemingly indicates an *O.S. Block size of 1K *though I have never before heard of such a size… usually knew O.S. Block size to be 512 Bytes (1/2 KB).*MWF* wrote -> Greg bases his opinions on measured facts, and if you have some facts about your choice I would also like to hear them. That is not a slap, but a genuine question.*My Reasons* for preferring Mounted F.S. over ASM in a NON-RAc scenario are mostly the same as given by Jared:-* F.S. are a Comfort zone & I have historically & traditionally used them for a while.* Additional instance for ASM * file management is simpler * storage admins have easy direct access to see what's on disk. Cheers Vivek **************** CAUTION - Disclaimer *****************This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system.***INFOSYS******** End of Disclaimer ********INFOSYS***
-- //www.freelists.org/webpage/oracle-l
