Watch out for the “alter session” command.

>>if by “load” you mean CPU consumption
Not just CPU consumption.. I am looking at CPU utilization (%usr and %sys ) , CPU load ( load average & queue length in vmstat)

nothing tells me I am anywhere close to reaching max limit. (in other words, no pattern where cpu utilization is running at beyond 80% ..and no huge pile up on run-queue either)

But there are occasions where some operations take longer and being a simple dba (scope strictly limited to database) I cannot seem to find a justification.

Perhaps, I can take your lead on this “A task that avoids stalling a thread can effectively take over the core.” & see if I can simulate some operation within a db, that on system-side would run continuously on a thread without letting the core to be shared by anyone else.

Thanks again for your time.

This isn’t my specialist subject either – when I’m stuck on CPUs etc. I talk to people like Kevin Closson and James Morle to help me out.

Basic sketch: a single chip – plugged into a single socket – can contain multiple CPU Cores; a single CPU Core may be able to operate in a multi-threaded fashion (2 threads being fairly common nowadays) – and Oracle typically reports each possible thread as a CPU. So my laptop (for example) is reported by Oracle as 1 socket, 4 Cores and 8 CPUs (because it runs two threads per core).

A multi-threaded Core is, however, only capable of doing one thing at a time. Just as your operating system can appear to be doing many things at once because of time-slicing and scheduling, your core is switching between threads to give the impression of multiple threads running simultaneously.

In the case of the core, though, the switches only take place (I believe, though I may be out of date) when a thread “stalls” – by analogy, think of an Oracle session running for while, then having to wait for a “db file sequential read”, the session “stalls”, and the O/S switches to running another session. In the case of the thread stalling, an equivalent task would be loading a page of main memory into the processor cache – the thread stalls, so a different thread starts. A task that avoids stalling a thread can effectively take over the core.

As far as your shared hardware is concerned – if by “load” you mean CPU consumption, then it is perfectly feasable that one of your databases could be using a far larger percentage of the available CORE time than the CPU statistics suggests, leading to the behaviour you’re seeing.

Johathan –
Apologies for asking system side naive question..am not a systems guy and not understanding the core vs thread difference.
Can you throw some light into the above statement?

(dealing with similar situation.. more than 1 db running on solaris box.. the overall load is always reported low..but from experience I have noticed, performance on 1 database varies depending on what is run on other database.. understand its all using same physical resources..but I am trying to get some pointers, it *is* a concern even if system is not running under max resource utilization )

Thanks

The problem with the “Old Believers” is that that old beliefs don’t get unpublished on the internet, and there are plenty of people who “tune by google” who find it, and then republish it just to have something in their blogs.

In fact every sort of monstrosity and perversion that Oracle experts have been railing against for the past 15 years still has its set of “Old Believers”, sad to say.

“Cold backup” – long time since I’ve done one of those ;)
Still, no matter how bizarre an experiment I come up with, someone always comes up with an example of why it might make sense occasionally.

No great significance in slipping in the ANSI – it just happened to be the case, and ANSI SQL does make it that little bit harder to generate the necessary SQL Baseline.