If you consider the usage of Table Functions then you should be aware of some limitations to the optimizer calculations, in particular when considering a join between a Table Function and other row sources.
As outlined in one of my previous posts you can and should help the optimizer to arrive at a reasonable cardinality estimate when dealing with table functions, however doing so doesn't provide all necessary inputs to the join cardinality calculation that are useful and available from the statistics when dealing with regular tables.
Therefore even when following the recommended practice regarding the cardinality estimates it is possible to end up with some inaccuracies. This post will explain why.
Join Cardinality Basics
I made a blog entry yesterday entitled Recent SPARC T4-4 TPC-H Benchmark Results. Proving Bandwidth! But What Storage? wherein I discussed some recent Oracle SPARC T4 TPC-H benchmark results. I pointed out in the post that the T4-4 is an extreme high-bandwidth server as is evidenced by how closely it performs the same benchmark with only half the processors (sockets) as a recent HP Proliant DL980 result. I then glued in some screen shots of the disclosure reports to elaborate on the point of bandwidth versus latency. You can push a lot of work through a SPARC T4-4, but that doesn’t mean each individual unit of work is all that fast—relatively speaking. This was even more so the case with the T3 platform before it.
December 6, 2011 The Oracle OTN forums changed a bit a year or two ago, and in the process I stopped receiving email notifications when new entries were added to discussion threads. The absence of email notifications was not a significant loss, although at times it is a bit interesting to see how a post in some of [...]
I think I might be going mad. I was sure that when I joined Oracle UK back in 1991 that the massive “Oracle” sign above the main office on “The Ring” in Bracknell was blue. It was the building that looked like a load of cubes balanced on each other.
As I remember it, the office stationary had “Oracle UK” on it in blue and my business cards were similarly coloured. I can’t find any 20 year old stationary to prove it and I owe Bryn Llewellyn a bottle of wine if I turn out to be wrong.
I’m sure I also remember fellow consultants joking in around 1993, when the annual bonus was particularly poor, that it was due to all the money spent going from blue to red stationary and signs when our UK identity was absorbed into the parent beast…
On 30 November, 2011 Oracle published the second result in a recent series of TPC-H benchmarks. The prior result was a 1000GB scale result with a single SPARC T4-4 connected to 4 Sun Storage F5100 Flash Arrays configured as direct attached storage (DAS). We can ascertain the DAS aspect by reading the disclosure report where we see there were 16 SAS host bus adaptors in the T4-4. As an aside, I’d like to point out that the F5100 is “headless” which means in order to provision Real Application Clusters storage one must “front” the device with a protocol head (e.g., COMSTAR) such as Oracle does when running TPC-C with the SPARC SuperCluster.
The past few days, I’ve been troubleshooting an email alerting problem on an EMGC 11.1 install on a client site.
But this troubleshooting also includes setting up my own email server and reproducing the problem http://karlarao.tiddlyspot.com/#EmailNotificationsNotSending
Watching/digging on the EM web based interface is tedious so I devised a way to just mine on the MGMT views… thanks to the MOS 421499.1 EMDIAG REPVFY Kit – which is a good source for mining the EMGC repository.
This simple query from the MGMT views will output something like this
This is not directly Oracle related, but probably still of interest.
Out of curiosity I pulled the ssh login attempts from /var/log/messages an internet facing server, and the data corresponds to what was shown in the article.
What was interesting was that all ssh attempts that I saw were for root. In the past when I have looked at these there are a number of different accounts being attacked, but now the attacks are all for root.
Just finished my session. What a nightmare…
I was surprised anyone turned up as it was a late change to the schedule and there were some great sessions going on at the same time. Check out the photo.
It was kinda OK, until I got to the demo, which I screwed up. That was really disappointing because it really was the crux of the session. I thought I saw the issue and tried to salvage it, but it failed again so I gave up and moved on. I would like to say it was an OK recovery from a disastrous demo, but that would be a lie. Flipping crap.