When I wrote this article for The Register in October 2010, there was a torrent of naysayers and witch hunters spewing their opinions in the comments section. I don't have a problem with that, I was only expressing an opinion myself, after all. I don't actually own a time machine and so any of my […]
There are a couple of posts on the blog describing problems with updateable join views or, to be more precise, join views which were key-preserved but which the optimizer did not recognize as key-preserved. Both scenarios are addressed in 12c:
And finally, part three!
And finally, part three!
XMLIndex support for Hash Partitioning is now also supported in Oracle 12c. In Oracle 11 there was already support for RANGE and LIST partitioning, but not yet for HASH partitioning. Some examples for the later two: LIST Partitioning on XMLType -- -- Create partitioned LIST partitioned XMLType table -- DROP TABLE list_part_xml PURGE;
There is a new default in town. Mark my words, you will encounter the following during your 12c life-cycle… From the Oracle 12c Reference manual PGA_AGGREGATE_LIMIT: PGA_AGGREGATE_LIMIT PGA_AGGREGATE_LIMIT specifies a limit on the aggregate PGA memory consumed by the instance. There is no difference in behavior between PGA_AGGREGATE_LIMIT being explicitly set or being set to
The TIMESTAMP WITH TIME ZONE data type that got introduced a long time ago is known for some oddities, for example Tony Hasler has a nice summary of some of them here.Here is another oddity that shows up when trying to aggregate on such a data type. Have a look at the following simple example:
create table t
rownum as id
, date '2000-01-01' + rownum - 1 as some_date
, cast(date '2000-01-01' + rownum - 1 as timestamp) as some_timestamp
, cast(date '2000-01-01' + rownum - 1 as timestamp with local time zone) as some_timestamp_with_local_tz
, cast(date '2000-01-01' + rownum - 1 as timestamp with time zone) as some_timestamp_with_timezone
I’ll be co-speaking with Tyler Muth at E4 and we will be talking about Performance Visualization…
some of you may already know that I’m really a big fan of Tableau and just to give you an example on what the tool can do I’ve consolidated all the different viz that I’ve done during my sizing & performance gigs here http://goo.gl/xZHHY and Tyler has also been doing a lot of Exadata performance & benchmarking gigs lately and there were a couple of times where we collaborated on specific viz (him doing it on R) just to validate each other’s work. In short, we are passionate about this stuff. And we are going to be awesome :)
Some time ago – actually a few years ago – I wrote a note about the hint /*+ gather_plan_statistics */ making some informal comments about the implementation and relevant hidden parameters. I’ve recently discovered a couple of notes from Alexander Anokhin describing the feature in far more detail and describing some of the misleading side effects of the implementaiton. There are two parts (so far): part 1 and part 2.
Dominic Brooks published a note recently about some very nasty SQL – originally thinking that it was displaying a run-time problem due to the extreme number of copies of the lnnvl() function the optimizer had produced. In fact it turned out to be a parse-time problem rather than a run-time problem, but when I first read Dominic’s note I was sufficiently surprised that I decided to try modelling the query.
Unfortunately the query had more than 1,000 predicates, (OR’ed together) and some of them included in-lists. Clearly, writing this up by hand wasn’t going to be a good idea, so I wrote a script to generate both the data, and the query, as follows – first a table to query: