Update with lots of already executed changesets incredibly slow (liquibase 3.0.2, oracle 10g)

General Discussion
1

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 FROM 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?

2

It shouldn’t be doing that. That should only be ran when it is doing a snapshot, and could really be avoided completely on oracle since it is trying to determine if a column is autoincrement which is going to always be false in oracle.


I created https://liquibase.jira.com/browse/CORE-1401 to track the fix.


Nathan

3

No workaround currently. I’m going to be looking at it next week, hopefully with a 3.0.5 version out later in the week to address the problem.


Nathan

4

We are having the same problem since we upgraded to 3.0.2 (from 2.0.5)

Our Oracle 11g database has approximately 760 tables in the applicable schema and there are over 19500 change sets that have already been run against it.

Even for a small update (1 change set) it is taking about 40 min to pre-scan the database, read databasechangelog etc. The actual update only takes a few seconds. This gets very frustrating (and almost unusable) if we are debugging our change sets.

Is there any workaround to this (until the defect is fixed)?

5

I’ve been making a lot of progress this week. I have a sample database with 4000 tables and about 8000 changesets and it is now taking just a few seconds to execute. In final testing phase now, I’ll probably have the new release out late today or monday.


Nathan

6

Hi,
is there any progress on this? We’re facing the same problem - with very few changesets though.
Thanks in advance for a short status update.
Joe

7

Thanks Nathan! Looking forward to 3.0.5.

8

We have gotten some interesting feedback from liqiubase when we run 3.0 changesets.

12:41:31 INFO 9/19/13 12:41 PM:liquibase: Unknown default value: value '(0) ’ type NUMBER (3), assuming it is a function 12:41:35 INFO 9/19/13 12:41 PM:liquibase: Unknown default value: value '‘0’ ’ type NUMBER (3), assuming it is a function 12:41:36 INFO 9/19/13 12:41 PM:liquibase: Unknown default value: value '(1) ’ type NUMBER (3), assuming it is a function 12:41:39 INFO 9/19/13 12:41 PM:liquibase: Unknown default value: value '(0) ’ type NUMBER (3), assuming it is a function 12:41:44 INFO 9/19/13 12:41 PM:liquibase: Unknown default value: value 'NULL ’ type NUMBER (3), assuming it is a function 
When we ran the changeset in debug mode we discovered which columns liquibase was
complaining about and agreed with liquibase’s assessment of those columns.

However we are also wondering if we can supress this validation since the validations
were being done on database elements that were untouched by our changesets.
Is this the same issue as the others in this thread?

9

In pre-3.0.5 releases, Liquibase was snapshotting more than it needed to and so you saw a lot more of the "https://liquibase.jira.com/browse/CORE-1352 on deck to try to better parse/handle default values.


Nathan