Oracle OpenWorld 2012 is just over a month away, and yes, we are organizing the Annual Oracle Bloggers Meetup — one of your top favorite events of OpenWorld.
What: Oracle Bloggers Meetup 2012
When: Wed, 3-Oct-2012, 5:30pm
Here’s a (camouflaged) constraint definition I came across a little while ago in a production system:
create table t1 ( v1 varchar2(10), constraint c1 check (v1 = 'A' or v1 = null) );
Quick question – will the following insert statement work or return an error ?
insert into t1 values('B');
The answer is that the row gets inserted – and that’s probably not an intended result.
It’s amazing how often NULL rears its ugly head as the cause of unexpected behaviour. Remember that a constraint accepts a value if the constraint does not evaluate to false. If you put ‘B’ into the constraint definition above, we get:
'B' = 'A' or 'B' = null hence FALSE or NULL hence NULL
I’ve commented in the past about the strange stories you can find on the internet about how Oracle works and how sometimes, no matter how daft those stories seem, there might be something behind them. Here’s one such remark I came across a little while ago – published in two or three places this year:
“An index that enforces referential integrity cannot be rebuilt online.”
Hello all fellow Oracle geeks and technology enthusiasts! Long time no see ;-)
In the hacking session about Oracle full table scans and direct path reads I explained how the direct path read decision is not done by the optimizer, but instead during every execution, separately for every single segment (partition) scanned in the query. I also explained how the _small_table_threshold parameter and the X$KCBOQH.NUM_BUF(which keeps track of how many buffers of any segment are currently cached) are used for determining whether to scan using direct path reads or not.
Last week I published some code that demonstrated how a fast refresh of an aggregate materialized view could fail because of the internal use of the sys_op_map_nonnull() function. In some ways it was an easy problem to explain because all you had to do was trace the call to refresh and see what was going on. Today’s bug is completely different – it’s virtually impossible to see the connection between the failure and its cause. Here (as a cut-n-paste) is an example of what happens when the bug appears:
execute dbms_stats.gather_schema_stats(user) * ERROR at line 1: ORA-01760: illegal argument for function ORA-06512: at "SYS.DBMS_STATS", line 13336 ORA-06512: at "SYS.DBMS_STATS", line 13682 ORA-06512: at "SYS.DBMS_STATS", line 13760 ORA-06512: at "SYS.DBMS_STATS", line 13719 ORA-06512: at line 1
There is a lot of information in the public domain that aids in making educated guesses as to what Big News(tm) will emerge from Oracle OpenWorld 2012.
I recently posted a sneak peek based on information disclosed at Enkitec’s E4 conference. I’d like to reiterate that I do not disclose Oracle confidential information nor have I ever. I signed a binding agreement with Oracle back in 2007 and I honor that agreement. The topic of non-disclosure is fresh on my mind after reading today about the former Navy Seal in hot water for what actually reads just like the legalese I subjected myself to back in 2007. I had no idea service members signed that sort of thing these days. But I digress.
MySQL management plugin for EM 12c has been long overdue. I’ve initially migrated the older plugin to EM 12c about 6 months ago, and few dozen people received this as the initial beta of the plugin. It worked OK but didn’t use any of the new 12c features, and its home page was a bit of a mess in the EM 12c Cloud Control web interface.
I’ve given examples in the past of how you can be suprised by Oracle when a mechanism that has “always worked” in the past suddenly just doesn’t work because some unexpected internal coding mechanism hits a boundary condition. One example I gave of this was rebuilding indexes online – where a limitation on the key size of index organized tables made it impossible to do an online rebuild of an index on a heap table because of an ORA-01450 (maximum key length) error that was raised against the (index-organized) journal table that Oracle creates internally to support the rebuild.
This blog is a little bit self serving and I’d normally not post it but I think that it would be an awesome deal for those of you who are thinking of buying an Oracle Database Appliance now. We have
several just two left brand new, unopened ODAs left in our inventory that we need to move. Half of them are gone to our customers but there are few still left. We are not really interested in holding on to them while somebody else can put them to good use so we have very very (did I say very?) good price. :) Limited time offer as they say.