The only thing I can think of is an example I saw recently in 11.2 (I think) where the cardinality of a select statement was 1 when the query used a UNION ALL in an inline view joined to some other table, but a better (ca. 80M) cardinality when the UNION ALL was changed to a UNION. There isn’t any information in your example that would make it reasonable to suggest that your example is linked – but I suppose it’s a possibility, and it’s possible that CTAS results in a limited range of execution paths being examined that bypass the code that hits the cardinality error.

I have been investigating a performance issue regarding the use of OR. Changing the query to use UNION ALL improved performance(minutes to seconds) by changing the plans to use indexes instead of full scans which the OR version caused. Here’s the bit I’ve found strange, while trying to do various testing I wrap a create table as select around the slow query(with the “OR”) and the CBO decides to pick the fast explain plan i.e the one with the indexes. I’ve assumed some form of dynamic sampling maybe in play but can’t see anything in the 10046 trace that obviously suggests this or anything on the web to suggest DDL will change an explain plan. Have you seen this behavior before?

I suggested the use of lnnvl() in a thread on OTN recently – and the user found that they got Oracle error “ORA-013207: incorrect use of the [LNNVL] operator”. I hadn’t realised that there were any limitations on the predicates you could apply the function to, and their predicate was:

tr_status not in (‘C’,'R’)

You could work around this by expanding the lnnvl() predicate to:

lnnvl(tr_status =’C') and lnnvl(tr_status = ‘R’)

but this is a little counter-intuitive and possibly difficult to work out – and my original argument for using the lnnvl() operator was that it made the code easier to understand. So in this case I’d go for:

not (nvl(tr_status,’X') in (‘C’,'R’))

did some tests and it looks great for me.
for example

select null from dual
where lnnvl(lnnvl(exists(select null from dual where lnnvl(null=null))));

do I miss something ?
why don’t they propose it as workaround ?

select ‘Line 1′ as is_true
from dual
where lnnvl(1=null)
union
select ‘Line 2′ as is_true
from dual
where lnnvl(1=0)
union
select ‘Line 3′ as is_true
from dual
where lnnvl(1=1)
union
select ‘Line 4′ as is_true
from dual
where lnnvl(lnnvl(1=null))
union
select ‘Line 5′ as is_true
from dual
where lnnvl(lnnvl(1=0))
union
select ‘Line 6′ as is_true
from dual
where lnnvl(lnnvl(1=1))