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 126.96.36.199 version to 188.8.131.52. 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:
Of course you already noticed document “Strategies for Scalable, Smarter Monitoring using Oracle Enterprise Manager Cloud Control 12c”, for those of you that didn’t you might want to check it out Strategies for Scalable, Smarter Monitoring using Oracle Enterprise Manager Cloud Control 12c
Found this on Twitter today.
Big Data has now entered the Trough of Disillusionment. Just ahead of it are In Memory databases. Cloud Computing is starting to come out of the trough on its way to the Slope of Enlightenment.
The 184.108.40.206 patchset has been out for a bit now. I am just now finding time to be able to take my first look at it. I’m interested, like many others, in looking at the In Memory database option. But I need to upgrade my Grid Infrastructure before I can upgrade my database.
The upgrade went smoothly. The only thing I thought was odd was a prerequisite check failed on the panic_on_oops kernel parameter. I was upgrading from 220.127.116.11 to 18.104.22.168 so this is a brand new check. The OUI provided a fixup script which I ran and then proceeded without any other upgrade issues.
Enterprise Manager 22.214.171.124 has now been released for a few weeks, as well as the 126.96.36.199 OMS Bundle patches (also known as System patches). If you plan to apply these bundle patches to your 188.8.131.52 OMS, and you are concerned about the downtime, then, you can reduce the downtime by referring to this whitepaper that contains patching instructions to reduce downtime.