DYNAMIC_SAMPLING Hint Ignored when CONCATENATION operation is used (10g)

Question

Using 10g (10.2.0.3) I ran into an interesting scenario that really messed up query performance. I found that when the optimizer chose to use CONCATENATION it ignores the DYNAMIC_SAMPLING hint. Has anyone else suffered from this or know of a work-around for this.
We legitimately use the DYNAMIC_SAMPLING hint because have some correlated columns that are used in the WHERE clause and that is how we get the right cardinality.
The easiest way to test this is to use this pattern in your WHERE clause:
WHERE
text_column like 'A%'
or text_column like 'B%'
and any_corrleated_column = <some value>
That pattern makes the query eligible for the CONCATENATION operation. To force it for testing purposes you have to use the USE_CONCAT hint.
Our specific data had to do with healthcare. Specifically looking at a specific diagnosis code for a given patient type (inpatient, emergency, observation, etc.)
The diagnosis code was heavily correlated with the patient type so initial cardinality estimates were off. The DYNAMIC_SAMPLING hint fixed that until the optimizer chose to use CONCATENATION in which case it drastically underestimated the cardinality and used nested loops where it should not have and query performance was hurt.
Of course the work-around is to use the NO_MERGE hint, but I really don't like using hints that "force" specific access paths because at some point the data may change such that a merge would be appropriate.
Has anyone tried this on 11g and is the DYNAMIC_SAMPLING preserved?

Answer 1

Dion, Thanks for your reply.
We have a lot of analysts who execute their queries directly (OLAP) and that is a conscious choice and we accept the lack of control with performance and tuning individual queries with hints..
I mention that because in my mind if Oracle is the one that transforms the query from a single table query to use a CONCATENATION operation it should pass on the DYNAMIC_SAMPLING hint to each of the factored queries.
I agree, there is a lot that could be done with hints, but I really try to avoid hints that lock Oracle into a specific execution path. What I like about DYNAMIC_SAMPLING is I can tell Oracle to challenge its assumptions because I know there are heavily correlated columns in the query.
When Oracle then samples the data it still has all of the options available to it as far as valid access paths and join types. That is a hint that I will not necessarily have to revisit. Now I could use extended statistics with 11g and that should yield the same effect and maybe I'll just have to wait for us to upgrade to 11g. I really don't want to propagate a lot of hints that I have to think about on every version upgrade.
Again, thanks for adding to this discussion.