Hi,
That compatibility mode message actual pre-dates compatibility mode :-), it does not mean compatibility mode is on. It could mean basic_optimization is on (but doesn't in this case).
For all queries with 7 or more tables, they will go down an alternate initial greedy costing using the legacy 12.5.4 optimizer, the general idea being if it times out and the search engine hasn't found anything better it times out and falls back on that plan. This generally also explains the abstract plan messages saying that a full AP has been specified.
You can disable this algorithm by running:
set alternative_greedy_search off
This might help given it does appear that at least one of the reformats is coming from the legacy optimizer. It gets very murky from this point.
It also appears that the legacy AP is preventing deferred parallel from kicking in so it could help there too.
When running these diagnostics, run with:
set show_sqltext on --also needs redirecting with 3604
..also, that way folk can see what you've run in the output.
In terms of the reformats on 15x, whilst not relevant to this query they can pop up under many circumstances, not just when there is not a satisfactory index.
They can be selected when the optimizer believes it can reduce the row set of a given scan using the predicate and build a smaller index, in these instances it can actual use a non-filtering or filtering index scan under the store operator. I have also seen a covered filtering index scan under the store operator. It can happen that it can use the index you want it to use to actual build a new index! On earlier versions you generally saw that a reformat scanned the whole table and built an index on it.
It can also select a reformat on an intermediate result of a join within a plan, i.e .reformat AxB to join to C. Also you see reformats for sub-queries for time to time.
Cheers,
Simon