Hash partitioning the index is a good strategy (if you’ve got the license) for reducing buffer busy waits on the high-values end of a sequential or time-based index; and if you do need to rebuild the index from time to time it’s nice to be able to rebuild it in parts; but partitioning doesn’t affect the SQL used to check for uniqueness.

As Pete points out – a billion generally defaults to the US standard of 10e9.

That’s a brilliant workaround.
I think the ORA-30389 is a re-interpretation of the underlying ORA-32023 because Oracle tests the validity of the destination statement by attempting to parse a statement of the form:

(old_statement)
union all
(new_statement)

-- example

select object_id from user_objects
union all
with v1 as (select data_object_id  from user_objects)

Conveniently your workaround hides the factored subquery from the union all.

Thanks to Jonathan for the posts on Oracle-L and this blog entry.

Pete

Oh, and since you’re a Brit, does “Billion with a B” mean 1e9 or 1e12 (which would be a trillion to us Yankees)? If the latter, hash partitioning the index sounds like an even better idea.

*
ERROR at line 1:
ORA-30353: expression not supported for query rewrite
ORA-06512: at "SYS.DBMS_ADVANCED_REWRITE", line 29
ORA-06512: at "SYS.DBMS_ADVANCED_REWRITE", line 185
ORA-06512: at line 13

SQL> begin
  2          sys.dbms_advanced_rewrite.declare_rewrite_equivalence(
  3                  name             => 'TEST_HINT2',
  4                  source_stmt      => 'select * from usr.t1 where n1 = 15',
  5                  destination_stmt =>
  6                          'with a as (select /*+ index(v1.t1) */ * from usr.v1 where n1 = 15) select * from a',
  7                  validate         => false,
  8                  rewrite_mode     => 'general'
  9          );
 10  end;
 11  /
 
begin
        sys.dbms_advanced_rewrite.declare_rewrite_equivalence(
                name             => 'TEST_HINT2',
                source_stmt      => 'select * from usr.t1 where n1 = 15',
                destination_stmt =>
                        'with a as (select /*+ index(v1.t1) */ * from usr.v1 where n1 = 15) select * from a',
                validate         => false,
                rewrite_mode     => 'general'
        );
end;
 
ORA-30389: the source statement is not compatible with the destination statement
ORA-32034: unsupported use of WITH clause
ORA-06512: at "SYS.DBMS_ADVANCED_REWRITE", line 29
ORA-06512: at "SYS.DBMS_ADVANCED_REWRITE", line 185
ORA-06512: at line 3

SQL> begin
  2          sys.dbms_advanced_rewrite.declare_rewrite_equivalence(
  3                  name             => 'TEST_HINT2',
  4                  source_stmt      => 'select * from usr.t1 where n1 = 15',
  5                  destination_stmt =>
  6                          'select * from (with a as (select /*+ index(v1.t1) */ * from usr.v1 where n1 = 15) select * from a)',
  7                  validate         => false,
  8                  rewrite_mode     => 'general'
  9          );
 10  end;
 11  /
 
PL/SQL procedure successfully completed

a great post, and very practical, too. I imagine that it could have a much wider application than making PK validation faster — it’s probably not the only place in Oracle internal code where an inefficient plan is hardwired for a maintenance operation. E.g. I hate the way Oracle implemented redefinition of multiple columns in one ALTER TABLE (in my case Oracle was doing as many full table scans as the number of columns to be modified) — and even though in this particular case the tricks you described won’t work, I would tend to believe there are dozens similar cases when they might help.

Best regards,
Nikolay

I *hope* it leads to Oracle performing pk constraint validations explicitly by treewalk(not fast) full index scan when over size X. Where you only have to keep 1 previous value (and the start of the next section if parallel) in memory per parallel thread, and even with exception tracking only the duplicates need to get written. Parallel scan points could be picked from the starting node and a thread finishing would pick up a point not yet assigned, which would make the finishing times similar for all but the most pathological cases (which would be indicated as one of those few “you need an index rebuild” cases.)

Size X would default to the size of hash that could be held in memory routinely, and might be something you could tune or a hint could be applied to the constraint enablement to use the special procedure instead of standard set aggregation code. Sigh.

I too never tested this. Thanks for quickly addressing this issue. Once again the hallmark of an actual expert is to publicly and cogently correct any discovered error. And you’ve gone on in great depth depict the actual lay of the land.

Nice work, my friend.