I think it was the smallest group so far which is not surprising considering that Monday has been the least popular day in our internal poll. We had a tad less than 20 people but very good size for the informal discussion of Oracle 11g adoption that took place at the second half of the meetup.
Turned out that there are very few people running 11g in production. Besides us at Pythian with number of clients on 11g, we’ve had only couple people I think including Carl Young from Metcash. Carl shared their experience of running a multi-terabyte data-warehouse on Oracle 11g and how the migration happened. Thanks a lot Carl for your insights!
If you haven’t seen the case study from Oracle about this migration — see what benefits Metcash had with 11g migration. I myself took note of few areas — Query Cache helped a lot on dimension tables lookups and some popular reports, Materialized Views invalidation problems reduced, CBO becomes smarter.
Some of the things to pay attention to in 11g — Oracle Warehouse Builder 11g (220.127.116.11) has actually less features than the latest OWB 10g release. If you look at 18.104.22.168’s list of bugs fixed (Metalink Note 601739.1), you would see a few dozen bugs on “Wrong Results” — those bugs are most worrying, of course. Many of them occur at the very specific circumstances. Particular attention for DW environment are bugs related to predicate push — can make your materialized views end up with wrong aggregates! Well, very few excuses to stick to 22.214.171.124 now.
Regarding the even in general, if I may borrow a response from one of the members to quote here:
Illuminating presentation by Alex, good questions and answers from participants. I was uncertain whether to go from 9i to 10g or 11g. This information and experience from other users has now helped me come to a decision to go straight to 11g.
Well, I should say mission accomplished!
For those of you who are not in Sydney or haven’t had a chance to attend, here are the slides from the meetup. I should note that the content is based on Christo Kutrovsky’s presentation that he delivered at the Oracle Open World 2007. Christo was scheduled to give a modified version at the IOUG Collaborate 2008 but couldn’t attend it being in Dubai at that time so I was doing it instead and took his slides as the basis. But I digress…
:) Thank you for mentioning my name Alex.
To be precise some not all combinations of Linux Windows (32/64 bits) Physical Standby are supported, however you should carefully check your target combinations in the mentioned note. For example:
The following are supported
– Microsoft Windows (64-bit Itanium) Microsoft Windows (x86)
– Microsoft Windows (x86) Linux x86 # In fact it seams the only Win/Linux combination supported
But the following are not supported
– Microsoft Windows (64-bit Itanium) Linux x86
– Microsoft Windows (64-bit Itanium) Linux Itanium
Jurijs Velikanovs suggested Metalink Note 413484.1 (updated very recently as I see). There are limitations on cross-platform physical standby.
So physical standby’s platform can be different only very little. In particular, slide 21 is pretty much wrong. :-) No SPARC-Linux or Linux-Windows physical standby.
The 32 bit and 64 bit seems to be supported for many platform. However, some PL/SQL incompatibilities needs to be taken care of.
Nice pitch…useful stuff.
I think you may have misspelt Wolfgang’ name…I believe it’s Breitling, not Brightling.
Thanks Jeff. Misspelled the name, you are right!
…oh, and I like the way you left the “what about indexes on defaulted NOT NULL columns” hanging…
I’m looking at that now!
@Jeff: Oh great! Make sure you keep us posted here! :)
…I looked at this briefly and basically when it builds the index, it has to either get the value of the column from the row, or the dictionary stored default…but in either case, once it’s got the value, it just builds a normal index…I don’t think there is anything new here in terms of indexes on such columns…it’s all about the table really.
Maybe I’m wrong, but that’s what I found. If I get time, I’ll blog it, but at the moment I’m stacked with work.
Thanks Jeff. I guess the easiest is to dump the data block but I would expect nothing new with indexes indeed.