Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Forbid performing Clean command against all system schemas in Oracle #1559

Merged
merged 3 commits into from Mar 20, 2017

Conversation

@voidunit
Copy link
Contributor

@voidunit voidunit commented Mar 18, 2017

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.

vosolovskiy added 3 commits Mar 12, 2017
…urrent schema/current user confusion in OracleSchema.
Moved tests from OracleSchemaSmallTest to OracleMigrationMediumTest, because they require a proper connection.
Removed EnterpriseDBSchemaSmallTest, because it was mistakenly cloned from OracleSchemaSmallTest and doesn't contain any proper tests for EnterpriseDB.
@axelfontaine axelfontaine added this to the Flyway 4.2.0 milestone Mar 20, 2017
@axelfontaine axelfontaine merged commit bef4a68 into flyway:master Mar 20, 2017
axelfontaine added a commit to flyway/flywaydb.org that referenced this pull request Mar 20, 2017
@axelfontaine
Copy link
Contributor

@axelfontaine axelfontaine commented Mar 20, 2017

Merged. Thanks!

@voidunit voidunit deleted the voidunit:oracle-forbid-clean-for-system-schemas branch Mar 30, 2017
@configman
Copy link

@configman configman commented May 9, 2017

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
Copy link
Contributor

@axelfontaine axelfontaine commented May 9, 2017

@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
Copy link

@configman configman commented May 10, 2017

@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
Copy link
Contributor Author

@voidunit voidunit commented May 11, 2017

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
Copy link

@larsulv larsulv commented May 12, 2017

@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
Copy link

@configman configman commented May 12, 2017

@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
Copy link

@larsulv larsulv commented May 12, 2017

@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
Copy link

@configman configman commented May 12, 2017

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

dohrayme pushed a commit to dohrayme/flyway that referenced this pull request Feb 3, 2020
…or-system-schemas

Forbid performing Clean command against all system schemas in Oracle
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

4 participants