NOTE: There’s a link to the full article at the end of this post.
I recently submitted a manuscript to the EMC XtremIO Business Unit covering some compelling lab results from testing I concluded earlier this year. I hope you’ll find the paper interesting.
There is a link to the full paper at the bottom of this block post. I’ve pasted the executive summary here:
We went over a few of the Java “tuning” options last time, so let’s go onto the OMS tier for this post.
I wrote about the Code Based Access Control (CBAC) stuff in Oracle Database 12c a while back.
I’ve recently “completed the set” by looking at the INHERIT PRIVILEGES and BEQUEATH CURRENT_USER stuff for PL/SQL code and views respectively.
A few months ago I wrote about some MySQL on Oracle Linux migrations we were working through. It’s been a long time coming, but last weekend was the go-live for this batch of migrations. So far so good!
Most of the elapsed time since my last post on this subject has been spent with the developers and users testing the migrations.
Here’s a thread from Oracle-L that reminded of an important reason why you still have to hint SQL sometimes (rather than following the mantra “if you can hint it, baseline it”).
I have a query that takes 77 seconds to optimize (it’s not a production query, fortunately, but one I engineered to make a point). I can enable sql plan baseline capture and create a baseline for it, and given the nature of the query I can be confident that the resulting plan will always be exactly the plan I want. If I have to re-optimize the query at any time (because it runs once per hour, say, and is constantly being flushed from the library cache) how much time will the SQL plan baseline save for me ?
The answer is NONE.
The first thing that the optimizer does for a query with a stored sql plan baseline is to optimize it as if the baseline did not exist.
This is a quick response to a question on an old blog post asking how you can adjust the high value if you’ve already got a height-balanced histogram in place. It’s possible that someone will come up with a tidier method, but this was just a quick sample I created and tested on 22.214.171.124 in a few minutes. (Note - this is specifically for height-balanced histograms, and it’s not appropriate for 12c which has introduced hybrid histograms that will require me to modify my “histogram faking” code a little).
I’ve already written about the 12cR3 to 12cR4 upgrade here. I did a few run through’s at home to practice it and it all seemed good.
Setting The Scene
Just to set the scene, for our production environment we run Cloud Control in a VMware virtual machine, using Oracle Linux 6.5 as the quest OS. With that setup, we can use a simple installation (DB and OMS on the same VM) and use VMware to provide our failover, rather than having to worry about multiple OMS installations and any DB failover technology etc. If there’s one thing I’ve learned about Cloud Control, it’s Keep It Simple Stupid (KISS)! As far as our managed servers go, most of our databases and all our middle tier stuff runs on VMware and Oracle Linux too. We have a handful of things still hanging around on HP-UX and Solaris, which will hopefully be migrated soon…
I’ve already talked about the recommendations we make for properly sizing an Enterprise Manager 12c and many already know about tuning a database, but let’s look at the tuning that may be a bit foreign to DBAs. We’ll start with Java.
We all know that it’s part of the EM12c architecture, but we often don’t realize that it requires attention to assist in Enterprise Manager running efficiently.
WebLogic 12cR3 was released towards the end of last week, so this weekend I had an install-fest.
I also did some minor amendments to some existing articles.