Sql-server – What should be excluded from a virus scan on a Microsoft based server (IIS, MSSQL, etc.)

I believe you have other factors to consider.

• How often are the PCs left switched on when not in use?
• Are the PCs used 24/7, or do they sit idle for 16 hours a day?
• Does your AV software's real time scanning, scan on change only, or all reads/writes? (or not at all?) - How reliable is it?
• Will your AV software reschedule a missed scan because a computer is switched off?
• Who is using the computer? (Single user / Multi user)?
• How much do you trust the people using the computers?
• How much data is stored on each computer (hopefully none, as it should all be on the network)
• Do any users have elevated rights on the systems?

Personally, here I perform daily overnight scans (when a PC is left on). But I think that suits our set up. All our machines are dataless (so there isn't a lot of scanning required on each machine), and PCs are mostly switched off when not in use anyway. The answer is probably subjective IMHO.

Heavy PL/SQL calls should block the thread - so the CPU usage should drop.

My first port of call for a slow application server is to check the gc logs - looking for frequent major collections (which indicate either a memory leak or that the JVM simply eeds more memory).

The systems I look after became a lot more stable after switching from the thick Oracle drivers to the lightweight jdbc drivers - although the issues had mainly manifested as the container crashing.

The logs should be a good indicator of any problems on the system - but a lot depends on what the developers choose to write in there. Slow SQL could result in the connection pool being exhausted - make sure that the pool is logging connection stats. Also make sure the ulimit is set correctly for the JVM.

Since you're running 9i at the DB tier you wont have the AWR functionality - you'll have to run the statspack (but this should already be standard practice for your sites performance management) to identify what's causing problems at the DB.

THe gradual degrading of performance is indicative of a memory leak in the application - usually this is caused by objects not being de-referenced and hence eligible for garbage collection - i.e. a programming issue. This should be apparent from most Java profiling tools.

ı noticed that there are some threads showing as a hogging

Unless you're testing this with a realistic workload the results are pretty much useless.