Did you check the alert.log?
Did you check the event viewer on NT
Did you monitor task manager while it was pinned, you can sort the "processes" by CPU consumption, this should point you in the right direction.
1. Did you check the alert.log?
The alert.log look fine, there are no strange errors on my log file.
2. Did you check the event viewer on NT
Look in this and there is nothing strange.
3. Did you monitor task manager while it was pinned, you can sort the "processes" by CPU consumption, this should point you in the right direction.
I look into the CPU and everytime I do an insert to the table in one database, that database will use most of the CPU.
any insert or update process would hog the CPU. I talked to the ADMIN guy in my company and he said that b/c we have only one processor so that every time when the user do any DML would hog the CPU. To me , that make no sense b/c he is telling me that everybody had to wait until that DML finish ???
Is that true, Jeff???
Should I create a profile and grant that profile to each user so I can limit the CPU_PER_SESSION, and SPU_PER_CALL ???
Do you think it would help ???
Where have you been ??? This forum has been quiet lately without any experience people.
Sure, on a single processor box, any DML operation will burn some CPU. However, a tuned insert or update statement should not consume 100% of the cpu for a long time.
When I say "WHICH Process", I mean which one of the oracle background processes is running the CPU to 100%? Each of the processes might indicate a different problem. If the process is a user process (not the statement, but the dedicated backend proceess) then it is probably a poorly tuned query. If the process is the DBWR, you may have db_block_buffers issues. If the process is LGWR, you may have I/O contention issues. It really depends on WHICH process is hanging.
On Solaris, you can use /usr/ucb/ps -aux | head to see exactly which process is consuming 100% of the CPU. Surely on Windoz there is a similar command/program that will show you which process is hung.