Forbid performing Clean command against all system schemas in Oracle

[voidunit]

This PR is to forbid cleaning system schemas in Oracle. Currently Flyway forbids Clean only against SYSTEM schema, but not others. (See issue #1550)

This PR includes PR #1558. Only commits starting from https://github.com/vosolovskiy/flyway/commit/f900b760f1603ebb705a915f0a543f471c760081 are related to the mentioned change.

The list of system schemas is determined based on Oracle Documentation and the data dictionary of the target database.

One test class for EnterpriseDB was removed, because it was mistakenly created and didn't contain any proper tests.

[axelfontaine]

Merged. Thanks!

[configman]

This change is likely to prevent us from upgrading beyond V4.1.2 of flyway in our production environment (and hence in any environment) because we have a large number of schemas that are in the 12c root container, hence seen as system schemas. They are there because the default behaviour on upgrade from 11g appears to leave all existing schemas in the root container.

Because this is going to break existing implementations using prior versions of flyway in a way that may require considerable effort there should ideally be a switch that would allow the previous less rigorous definition of what is a system schema to be used. This would allow us time to migrate a large estate into a pluggable DB container(s).

[axelfontaine]

@configman I don't get why you need to use clean in your production environment. However, @vosolovskiy what are your thoughts on the root container after upgrade issue?

[configman]

@axelfontaine You are right, I got my logic a little confused, the point is that the change prevents use on 12c root container schemas, which we have, and therefore prevents upgrade from V4.1.2. My point about production is really that we would like to use the latest but that the inability to use the same version in lower environments would prevent that.

As things stand we would be required to migrate all schemas into a PDB, which is doable, but will require planning and effort. We would also be unable to upgrade until the last schema has been migrated. This is why I think that we need to be able to manage this process and allow the clean on these schemas in some way until all the migrations are complete.

[voidunit]

Will be able to check it not earlier than next week.
@configman how do these schemas look in ALL_USERS after migration? is ORACLE_MAINTAINED set to Y for them?

[larsulv]

@configman I am curious on how you ended up with your application schemas in the root container of the CDB?
After an upgrade of an 11g database the resulting 12c database will be a Non-CDB database. Then, to switch to the multitenant architecture, the Non-CDB database can be migrated to a PDB as described here: https://docs.oracle.com/database/121/ADMIN/cdb_plug.htm#ADMIN13598 or here: https://oracle-base.com/articles/12c/multitenant-migrate-non-cdb-to-pdb-12cr1

@vosolovskiy I think the logic implemented in this PR is correct. Clean should not touch any of the system schemas. ALL schemas in the root container is to be considered as system schemas. See https://docs.oracle.com/database/121/CNCPT/cdblogic.htm for reference.

[configman]

@larsulv I am completely in agreement with the principle that the clean should not touch system schemas in the root container. My point is simply that in introducing a breaking change such as this it would be sensible to allow an option to maintain the previous behaviour.

[larsulv]

@configman That can be a point.
But the answer to @vosolovskiy question is interesting.: "how do these schemas look in ALL_USERS after migration? is ORACLE_MAINTAINED set to Y for them?"

[configman]

I am not involved in migration, but I can see some schemas for which the ORACLE_MAINTAINED flag is set to Y.