Following on from last weeks book competition, the kind people at Packt have offered another prize. This time 2 e-book copies of
Oracle E-Business Suite R12 Integration and OA Framework Development and Extension Cookbook by Andy Penver.
Things have certainly been busy lately so I haven’t had much of a chance to get back here for a while. Busy at work, busy at home, busy at play and even busy with a new David Bowie album to enjoy !! And yes, “The Next Day” is an absolutely stunning album by the great […]
Iron Man blew me away when I first saw it. Iron Man 2 was good, but not as good as the first. Iron Man 3 was better than Iron Man 2, but not as good as Iron Man or The Avengers movie, in my opinion. Don’t take this as a major criticism, because all of these films are very cool. It’s a relative thing…
Some days are just too good to be true :) I ran into an interesting problem trying to install 184.108.40.206.0 Grid Infrastructure for a two node cluster. The storage was presented via iSCSI which turned out to be a blessing and inspiration for this blog post. So far I haven’t found out yet how to create “shareable” LUNs in KVM the same way I did successfully with Xen. I wouldn’t recommend general purpose iSCSI for anything besides lab setups though. If you want network based storage, go and use 10GBit/s Ethernet and either use FCoE or (direct) NFS.
Here is my setup. Storage is presented in 3 targets using tgtd on the host:
Materialized views open up all sorts of possibilities for making reporting more efficient – but at the same time they can introduce some “interesting” side effects when you start seeing refreshes taking place. (Possibly one of the most dramatic surprises appeared in the upgrade that switched many refreshes into “atomic” mode, changing a “truncate / append” cycle into a massively expensive “delete / insert” cycle).
If you want to have some ideas of the type of work that is involved in the materialized view “fast refresh”, you could look at a recent pair of articles by Alberto Dell’Era on (very specifically) outer join materialized views (which a link back to a much older article on inner join materialized view refresh):
My Oracle Support had a fairly lengthy outage today right in the middle of the Australian business day.
But I’m not going to blog about that. One thing I’ve learnt from many client sites is that people will understand and forgive things like outages, or errors, or crashes, or just plain wrong software, as long its evident that you are passionately working for the benefit of the user, that you were not lazy or flippant or learning from mistakes…
But one thing, perhaps the biggest thing, that customers will NOT tolerate, is when you don’t listen to what they’re trying to tell you
And that’s where MOS is suffering – not from outages, not from errors, but from not listening….
I logged this SR:
It’s been over 20 years since I finished my finals for my first degree, but this time of year never fails to affect my already terrible sleeping patterns. I’ve started waking up in the morning panicking about an exam, which I’ve forgotten to revise for. It takes a few minutes for me to realize there is no exam, so I’ve got nothing to worry about…
Like I said, this happens every year, but I think the fact I’m currently working for University has reinforced the panic in me. I sense a few more weeks of exam panic induced insomnia, before I settle back into my normal insomnia.
In this post, we are going to complete part 1 illustrating the (considerably more complex) general case of a fast refresh from a master inner table without a unique constraint on the joined column(s).
To recap, now the outer slice can be composed of more than one row, for example:
and hence, both the DEL and INS step must consider (and read) the whole outer slice even if only a subset of the inner rows have been modified. This requires both more resources and a considerably more complex algorithm. Let's illustrate it (the mandatory test case is here).
The DEL macro step
This sub step (named DEL.del by me) is performed first: