v3.0.5: ORA-01000: maximum open cursors exceeded (not on v2.0.5)


I’ve upgraded to 3.0.5 (because indexExists says ‘yes’ in 2.0.5 to a not-nullable FK column without an index, but ‘no’ on 3.0.5), and found that when changeset nr. 210 is executing, I get an ‘ORA-01000: maximum open cursors exceeded’ error. If I run these changesets (in total about 260) on 2.0.5, I don’t get the error (but also not the indexes on non-nullable FK columns…hence the upgrade)

This is on an empty DB. If I re-run this (with the dbchangelock removed), it continues, and finalises successfully.

I realise there is a similar topic for this, but that one is older than v3.0.5 is. This other post is:




I haven’t seen that, even with a large number of changesets. It may depend on what you have in your changeSets though. Do you have many custom changes or any extensions? What type of calls are you making in the few changesets leading up to 210?

Any chance you could send me the changelog? You could send it directly to nathan.voxland@liquibase.org if it helps.



I’m experiencing the same problem as described above: when I’m executing huge number of changeSets I need to execute update twice, due to Filip

I created https://liquibase.jira.com/browse/CORE-1597 to take a look at this issue for 3.0.8


Sorry for the late reply.

First changeset contains an sql file with the base of the DB; after that only relatively simple stuff like new columns, a constraint or index, and every now and then a new table.

From 200 or so there are about fifty sets of which each contains the addition of an index, including precondition which checks if the index exists.

Just about all sets have a precondition, and if needed a rolback.

The changesets are stored in files containing the version number of our application. On average about 4 or 6 or so changes/changesets. So all together the changes where stored into 30 different files or so, which are included in one master file.

Can’t send you the source for now.

The workaround has been to re-read the current, stable state from oracle into an sql file, and use that in changeset number 1; from there we have been extending again using Liquibase.