Parts I an II of this series can be found here and here.
My previous installments in this series delved into how Orion does not interact with the operating system in any way similar to a database instance. This is a quick blog entry about CALIBRATE in that same vein.
On a system with 32 logical CPUs (e.g., 2s8c16t) we see CALIBRATE spawn off 32 background processes called ora_cs* such as the following ps(1) output screenshot:
I picked one of the processes and straced it to reveal the fact that CALIBRATE uses several processes each performing large-batch asynchronous I/O to do its job:
This should be a revelation to the purists out there. In my assessment I think CALIBRATE may even deviate worse from the goal of mimicking instance I/O than does Orion!
Nobody really cares about platforms though. So this is one of those “for what it’s worth” posts
Hi,
nice to read from You 🙂 .
So , what is the proper syscall for asynch i/o which actually mimics Oracle engine behaviour ?
Regards
GregG
That is the correct API call, but it is not used in the manner CALIBRATE is using it for the purpose CALIBRATE is using it. In short, it is incorrectly using the correct API to incorrectly synthesize database I/O 🙂