Comments on: Combinations

By: Jonathan Lewis

Jonathan Lewis — Thu, 02 Aug 2007 15:38:56 +0000

Dominic,
My take on that one is that as soon as you start to combine features – especially new or enhanced features – you need to start taking wild leaps of imagination into “if A is going to break B, where is it going to break”, and then try to devise appropriate test cases.

Gary,
It’s one of the common problems with seeing a problem – how far do you go, and how much more time do you spend, in trying to put exact boundaries on it. In our case (end-user land) we usually stop early; in Oracle’s case we would like to think they keep on to the complete solution.

For example – this report showed a problem with a 16KB block size: but was that a coincidence: is there a problem only when the data block size is larger than the undo block size, or is it the absolute size of the data block; or is it specifically a 16KB data block with an 8KB undo block … and so on.

By: Connor

Connor — Tue, 31 Jul 2007 14:18:48 +0000

Reminds me of an issue when we discovered (on 9.2 I think) )that a fast refresh on a single table aggregate materialized view would not work if you had a local copy of DUAL in your schema, and that DUAL was an IOT not a heap table….

I remember the project manager ranting and raving…”Why don’t Oracle test this stuff!?!?!?”

bit harsh I thought :-)

By: Gary

Gary — Mon, 23 Jul 2007 22:39:33 +0000

Interesting that it doesn’t say that flashback query never works with a db_block_size bigger than 8K. It suggests there’s another condition for the failure (maybe it tries to read the block into a chunk of memory that isn’t necessarily big enough, maybe it only reads the first 8k of the block and it works if the record is in that first 8k).

By: Mark Rittman

Mark Rittman — Mon, 23 Jul 2007 20:52:21 +0000

Jonathan, I don't know if you saw a similar point in my recent blog posting ("Look before you Leap"), and it was a bit of advice from you, at the 3-day Optimising Oracle seminar I attended a couple of years ago, that alerted me to this potential "gotcha". As you say, whilst a new feature in itself may well have been tested exhaustively prior to release, it's unlikely that it's been tested in combination with all the other new features coming out at the same time, hence the potential for issues. It was good advice and something I've borne in mind ever since, especially when I'm basing a project on a completely new area of functionality within a major release. -- regards, Mark

By: David Aldridge

David Aldridge — Mon, 23 Jul 2007 19:27:39 +0000

>> “How on earth are you supposed to guess that flashback query and blocksizes would have anything to do with each other?”

That’s probably why it didn’t get tested by Oracle :)

By: Dominic Delmolino

Dominic Delmolino — Mon, 23 Jul 2007 16:33:03 +0000

I’m guessing the opposite is true too — the best way to avoid bugs is to not combine different bits of technology? I’m not trying to be snarky here, but generally the more options required for something, the more places for things to go wrong…

By: Paul

Paul — Mon, 23 Jul 2007 01:15:56 +0000

I guess in a perfect world, you shouldn’t need to guess because this would have been rooted out by QA a long time ago.
You would hope that test scripts used by QA are being written with full input from development on the dependencies and boundary conditions that apply. Theoretically, static analysis of flashback query code could have uncovered some block-size dependency…
…and then there’s what happens in the real world;)