Unnecessary snapshot on liquibase update


From http://forum.liquibase.org/topic/update-with-lots-of-already-executed-changesets-incredibly-slow-liquibase-3-0-2-oracle-10g#49382000000827004

I'm using liquibase 3.0.2 to update an Oracle 10g database. There are about 1300 changesets in the xml file. The first time it runs normal. No performance problems. When I run the same file again it takes a very long time to finish. The only thing it should have to do is check if the changeset has been executed and compare the checksums as far as I know.

When I monitor the database I see that all the columns of all the tables are being checked (SELECT <columnname> FROM <tablename> WHERE 0=1). With almost 1300 tables this takes quite a long time. I see no reason for doing this since there are no preconditions in the xml file at all. Anyone know if there's a specific reason for doing this or is this a bug?


Oracle (probably others)


Nathan Voxland
August 22, 2013, 7:09 PM

Oracle should not even need to do the query since it is to check for autoincrement columns.

Nathan Voxland
August 26, 2013, 9:15 PM

Issue appears to be related to how the snapshot types are managed. When you have an example type, all the containing types are added including up to schema, then the includeNested logic on schema picks up all the objects heading back down

Nathan Voxland
August 28, 2013, 3:34 PM


DEBUG 01/08/13 14:17:liquibase: Executing QUERY database command: select uc.constraint_name, uc.table_name,uc.status,uc.deferrable,uc.deferred,ui.tablespace_name from all_constraints uc, all_cons_columns ucc, all_indexes ui where uc.constraint_type='U' and uc.index_name = ui.index_name and uc.constraint_name = ucc.constraint_name and uc.table_name = 'APP_SETTINGS_CONFIG' and uc.owner = 'U609101_COMMN' and ui.table_owner = 'U609101_COMMN' and ucc.owner = 'U609101_COMMN'

as taking a long time as well

Nathan Voxland
September 23, 2013, 9:38 PM

Fixed in 3.0.5


Nathan Voxland

Fix versions

Affects versions