MSandico wrote:Do NOT make any parameter changes until after the DB resides on 64-bit OS & 64-bit Oracle software.
Thanks for the replies everyone and sorry for the late reply..
We are using Windows 2003 Ent Ed. 32-bit (though we are going to upgrade to Win 2008 R2 64-bit very soon..)
MSandico wrote:Don't think about SQL server. It works differently, has different performance limitations - locking and consistency methods, in particular.
Yes we are having performance issues and from OS perfmon counters, there is nothing i can see (cpu, memory, etc..). So i was looking to see if there were any application-level specific perfmon counters i can look at (again im thinknig about how i can tell from SQL server perspective..).
One of my first inclinations was to investigate the available memory on the server (10GB), and when i noticed SGA was set to maxsize of 1GB, i wondered if it should be configured to take advantage of the memory on that dedicated db server. A quick look in EM reports that Oracle says to increase SGA to 1250MB (still not the 8-9GB i was initially thinking). I always figure that the more the memory, the happier a db server can be..whether it needs it or not..it may want that extra juice ;)Not true at all. There are a number of bottlenecks and internal tuning features that can give surprising results to the uninitiated. Adding more memory to a 32 bit server that is already using as much as it can is like adding a building to your office - doesn't help you much if you are stuck in the same cubicle. Adding more memory to a server that can use it can change the bottlenecks around to make performance worse, for example, you might have more data in memory, making your cpu overloaded trying to thrash through it all, when before it could have a breather while waiting on I/O. Like adding a new building to your office, moving you to a bigger cubicle in the new building, then you have to walk twice as far to all those dang meetings.