I am working on upgrading all of our production databases to the Oracle 188.8.131.52 version. My company’s most important database serves a custom, in-house developed application so we have the luxury (and sometime the curse) of having complete control over the application source code. If I discover a version-specific issue with a their party application, I file a trouble ticket with the vendor to get the issue fixed. But for our own application, I often have to diagnose the problem and determine how to get the issue fixed.
Oracle Enterprise Manager 12c Consolidation Planner is a great tool that helps you plan and consolidate multiple targets on to a single machine such as Oracle Exadata. This solution helps you visualize what you have running in your environment and where you can take advantage of consolidation in order to maximize resources and lower IT operational costs. Watch the demo below to get a better understand of how Consolidation Planner works.
I found this nice blog entry today:
When performing database upgrades, adequate testing is important to understand the impacts, both positive and negative, the database upgrade has on the application. I have been preparing to upgrade databases from the 184.108.40.206 version to 220.127.116.11. One weekend, myself and another DBA spent some time upgrading about half of our production databases to the new target version. First thing on Monday morning I got a call from a Developer who had a query that was now running slowly. Why did we upgrade just half of the dev databases? For this specific reason.
I was playing around with the Result Cache the other day…I know…this isn’t a new feature and has been available for awhile. Unfortunately, it can take a while to get to things I guess.
In my simple test, I had a query that exhibited this behaviour: