From MOS (Metalink) a search for “Patch Set – List of Bug Fixes by Problem” is a useful search, andother is “Availability and Known Issues”. Whenever you find some behaviour that looks like a bug, it’s worth checking the patch sets for the patches or release that are newer than the version that you’re running – you may find that your problem is a known bug with a patch that might be back-ported.
For ease of reference, here are some of the results I got (sorted in reverse order of version) from the searches; you will need a MOS account to follow the links:
I've been asked and agreed to contribute to "AllThingsOracle.com", a service set up by RedGate software for Oracle users.
I'll publish there complete articles not found on my blog and also sometimes just links to my blog. Furthermore I also plan to contribute some webinars, so stay tuned. In the meanwhile you may want to have a look at the archived video material already available where you for example can watch webinars featuring Cary Millsap and others.
Whereas on my blog I often focus on highlighting edge cases my articles and webinars on AllThingsOracle.com are more targeted towards explaining fundamentals.
You might think from the title that this little note is going to be about the index hash join – you would be half right, it’s also about how the optimizer seems to make a complete hash of dealing with index hash joins.
Let’s set up a simple data set and a couple of indexes so that we can take a closer look:
Lately I’ve been reading a lot more than writing as is evident by my low-frequency blogging. Here is some of the material I’ve been going through:
One of the tasks I am performing quite regularly is to deploy Oracle software in form of an RPM. In a previous post I described how this proces could work, based on a post by Frits Hoogland.
Employing the same method, I ran into problems with Oracle 11.2.0.x clients. A few facts to start with:
The problem described here is most likely applicable to other Oracle clients as well although I haven’t verified that.
The problem
January 30, 2012 As we have seen in the past, TKPROF output sometimes lies, and in a recent OTN thread I was reminded of another case or two where TKPROF output may be misleading. In the OTN thread, the original poster (OP) started the thread by asking a simple question about an execution plan that appeared [...]
In the past week I've been investigating how Oracle fires triggers with the Merge and Multi-Table-Insert statements. Also took a look at 'statement-level constraint consistency' with these two types of statements. My findings are here: http://rulegen.blogspot.com/2012/01/statement-level-constraint-validation.html
Normal transmission on harmful triggers should resume shortly.
While I was performing a three day seminar recently in Switzerland I came across this new option in cluvfy.
Normally you’d run cluvfy in preparation of the installation of Grid Infrastructure or a set of RAC binaries to ensure everything is ready for the next step in the RAC install process. Beginning with 11.2.0.3, there is another option that’s been sneaked in without too much advertisement: the healthcheck.
Part of the “comp” checks, it takes the following options:
cluvfy comp healthcheck [-collect {cluster|database}] [-db db_unique_name] [-bestpractice|-mandatory] [-deviations] [-html] [-save [-savedir directory_path]
The most extensive report is run without any options, as shown in the appendix (the output is too long to display at this stage of the post) You have the following options:
This is a really old idea – but it’s the first time I’ve seen it illustrated.
(The obvious flaw in the concept appears in comment 22.)
Recent comments
3 years 21 hours ago
3 years 12 weeks ago
3 years 16 weeks ago
3 years 17 weeks ago
3 years 21 weeks ago
3 years 43 weeks ago
4 years 11 weeks ago
4 years 41 weeks ago
5 years 25 weeks ago
5 years 25 weeks ago