This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
Hello all, About 2 months ago we upgraded our Oracle 8.1.5 database to 9.0.1. We also moved the db over to a new server that has more than twice the hoarse power than the original (dual SPARC 900MHz processors). Immediately we saw performance gains on certain database operations. However, this was for a few users. After we went LIVE we discovered server performance issues. After a long fight with oracle we cleared up some of them. But, there still is a general slow down of our transactional system. Since then we have been trying to figure out why the database IS SLOWER. We are still working with oracle but that is becoming a dead end. We have tried... The latest jdbc drivers (18.104.22.168 and 9.0.1). An oracle fix for a LATCH issue. Increased various database parameters. All of which have had minor performance improvements. I am more on the application/app server side of the development team and as such have been reading through the Websphere e-fixes/technotes and have come across some things specific to WAS's connection pooling that might help. I have also been running some statistics (top and vmstat) on the appserver and it "looks" like there are Java processes that are either orphaned or just kind of hanging around longer that necessary. The only thing is that the DATABASE/jdbc drivers are the only things that have changed in this entire process. So the only thing I can think of that would cause WAS to be the issue is the way the Data Source connection pool uses the JDBC drivers. My questions are ... Has anyone seen this type of behavior with WAS 3.5.4 and Oracle 9i? And has anyone used the "Cumulative e-fix for connection pooling" APAR: PQ56607. If so, what was your issue, and did it help? Thanks in advance for any knowledge you can share. [ July 30, 2002: Message edited by: Heath Lilley ]