Oracle Guru's?

[TCL]

prstat

Thats the one!. Was dredging my memory but all it came up with was psrinfo which ain't much help

[Liability]

Then they should be walked out the door. This is bread+butter stuff for a Unix admin:


vmstat 3 (ignore the first line)
top (not standard utility in most Unixes (Unices? Uniii?))
sar


Seriously, find another/better Unix admin.

It is what I have said - noone wants to take responsibility! And their Permi Lifers!. Trying to get any kind of assistance is extremely painful!

[Liability]

You probably need to run the AWR reports. These are normally snapshot reports which take a snapshot each hour. They can also be run on demand.

These show to SQL, top activity, memory, IO waits etc.. quite handy see what's going on...or not.

Tell your DBA the time range you need the report and he should be able to generate the report and send it on to you.

Ill try that also! Thanks!

[b0redom]

It is what I have said - noone wants to take responsibility! And their Permi Lifers!. Trying to get any kind of assistance is extremely painful!

Sounds like you want a very short term contractor to come in and help troubleshoot.

[adestor]

Basically - have a solution [help desk] that is really slow. The issue isnt network, client machine, or client software but actually getting the data back and refreshing. Ive done the troubleshooting and the server resources are peaking at various times but that isnt the only issue


Now the Oracle DBA says that Unix will show 90% RAM utilisation as it reserves the allocated memory. He is viewing this in the Oracle Management Software. He says alot of other systems are like this and its just the OS reserving it but he cant see how much is actually being used within the 90% of XXGB RAM. The Management software always shows 90%+ memory reservation/utilisation regardless of time [and out of hours the system isnt used]

Went over to Unix guys and asks for paging stats - and they seem to be a little lost

So what is the problem ? Is it some poorly performing query ?
I've been in the database dev / dev DBA game for much too long and only once in all that time was a problem caused by hardware on a dev /prod machine.
You've got to remember that 9.9 times out of 10 the problem is caused by the code itself and not the server / hardware generally.