I have an issue with the 19c data pump export and I'm wondering if there is a data pump export parameter or some other strategy for resolving it.

When a table's primary key is created as part of the create table statement, a unique index is automatically created with the same name as the primary key.

The 11g data pump exports this unique index separately prior to recreating the constraint.
The 19c data pump does not export the unique index. When the constraint is applied, the index is created automatically.

This creates a problem when an existing (non-unique) index exists that can be used as the index for the primary key constraint. In this case, the constraint is created but it references the incorrect index.

The change manifests itself when the data pump tries to re-import stats into the primary key index. An error is thrown because the primary key index with the expected name (same as the constraint) does not exist.

ORA-20000: Unable to set values for index PK_TABLE_NAME: does not exist or insufficient privileges

Further investigation narrowed down the error to the undocumented flag all_indexes.constraint_index. In 19c, any table that creates the primary key as part of the create table statement has a value of "YES" in this column. This prevents the data pump from creating the index separately.

If the primary key index and constraint are both created separately from the create table statement via the USING clause, all_indexes.constraint_index set to "NO" and the primary key index will be exported by the data pump.

Finally, any table exported by 11g will have the all_indexes.constraint_index set to "NO" regardless of how the primary key index was created. All subsequent exports work as expected. I've confirmed that the all_indexes.constraint_index stays set to "NO".

The attached LiveSQL script recreates the scenario when run on 19c. The schema then needs to be exported / imported to see the issue.

So the problem only happens with tables directly created on 19c AND a pseudo-covering index exists for the primary key constraint. (I say pseudo because the index does not need to be unique and I discovered that the keys can be reversed.) The workaround exists to rewrite the create table statement to not include inline primary key creation but that is impractical for large existing applications. Only rewriting the create table statements for the small number of problematic tables is possible but leaves open the possibility that a future index will cause this scenario to happen.

The ideal solution is a way to either flag the data pump to force the export of all primary key indexes or some way to update all_indexes.constraint_index = "NO". (Effectively two ways of describing the same thing.)