In this post, I will share with you something related to the max_dump_file_size parameter that i came across sometime earlier...
There was a requirement from our IT team to increase the maximum allowed user trace file size from 50 MB (the trace files would max out at 50MB) to 500 MB. I took up the request from the developer and started working on this. Interestingly, I observed the max_dump_file_size was set to 102400. As a matter of fact, I was not part of the original team that set up the databases/instances I am currently maintaining, so i am not too sure about the history of why this parameter was set as 102400 in our environment.
Now, when the size is not described with a suffix eg., K (KB) or M (MB), the size is considered as maximum size in operating system blocks. I wanted to find out the operating system block size in our windows environment (though reverse engineering from the maxed out trace file would reveal 512 ). A quick check on the windows operating system revealed the logical size (cluster size) as 4K (4096 Bytes). However, the database files in our environment are on a mounted volume which is raw partition and hence it appears that oracle is using the physical block size - 512 bytes to calculate the max size. A select on the lebsz column of sys.x$kccle revealed the size of 512 bytes, which is also the size that oracle database is picking up.
So, in our environment the max trace file size was being calculated as follows, despite the windows cluster size being at 4K:
102400*512=52428800 bytes.
This would translate to 50MB.
- Aravind Kamath
Friday, September 14, 2007
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment