Since every file has its own URL, you can also directly executed them in SQL*Plus. For example:
I’m sorry for the delay!
Some of you will be aware of the LOB – London Oracle Beers. It is an informal group of us London- based people who work in the Oracle sphere and who also like to have a pint (be it beer, cider, larger or diet coke). We mostly just catch up as friends and talk rubbish and, amongst that, discuss topics related to Oracle technologies. Something we occasionally talk about it whether we should make it a little more formal and have presentations on Oracle topics.
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.
#555555;">I’ve always wanted some sort of calendar view of load where I could see patterns across the same days of the week and same hours of the day and then be able to pick different periods and diff them:
#555555;">The first step of such a display would be selecting the data in such a way to represent the graphic. A graphic should be harder to do than a similar, though less powerful, ascii representation.
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.
I recently was involved in an investigation on a slow-running report on an Exadata system. This was rather interesting, the raw text file with the query was 33kb in size, and SQL Developer formatted the query to > 1000 lines. There were lots of interesting constructs in the query and the optimiser did its best to make sense of the inline views and various joins.
A new version 4.1 of the XPLAN_ASH utility is available for download.
This version in particular supports now the new 12c "Adaptive" plan feature - previous versions don't cope very well with those if you don't add the "ADAPTIVE" formatting option manually.
Here are the notes from the change log:
- GV$SQL_MONITOR and GV$SQL_PLAN_MONITOR can now be customized in the
settings as table names in case you want to use your own custom monitoring repository that copies data from GV$SQL_MONITOR and GV$SQL_PLAN_MONITOR in order to keep/persist monitoring data. The tables need to have at least those columns that are used by XPLAN_ASH from the original views
We have a fairly common query process, where we run a MERGE command to compare a remote table to a local copy of it, as "poor mans" Golden Gate to bring that table up to date on a regular basis. [Editors note: Writing MERGE's is more complicated but a lot cheaper than Golden Gate :-)]
After an upgrade to 12c, the performance of some of the MERGE’s went very bad…and you can see what happened with the (sanitised) example below:
The bold part is a join that we’ll be executing on the remote database (mydb). It’s been hinted to run in a particular way.
I played a lot of volleyball in a bygone life :-) and subsequently ruined my knees to the extent that I needed surgery. I got a shock when the surgeon (after a series of x-rays and checks) said to me: "Of course, we’ll only know once we’re in there".
So here’s a body part (a knee) that’s had hundreds of thousands of years to evolve, so you’d expect that knees are pretty much the same world wide, yet an experienced and qualified surgeon puts the "we cant be 100% sure" caveat before chopping me open.