Liquibase-Sperre - Gründe?

Question

Ich bekomme das, wenn ich viele liquibase-Skripte gegen einen Oracle-Server laufen lasse. Irgendein Computer bin ich.

Waiting for changelog lock.... 
Waiting for changelog lock.... 
Waiting for changelog lock.... 
Waiting for changelog lock.... 
Waiting for changelog lock.... 
Waiting for changelog lock.... 
Waiting for changelog lock.... 
Liquibase Update Failed: Could not acquire change log lock. Currently locked by SomeComputer (192.168.15.X) since 2013-03-20 13:39 
SEVERE 2013-03-20 16:59:liquibase: Could not acquire change log lock. Currently locked by SomeComputer (192.168.15.X) since 2013-03-20 13:39 
liquibase.exception.LockException: Could not acquire change log lock. Currently locked by SomeComputer (192.168.15.X) since 2013-03-20 13:39 
     at liquibase.lockservice.LockService.waitForLock(LockService.java:81) 
     at liquibase.Liquibase.tag(Liquibase.java:507) 
     at liquibase.integration.commandline.Main.doMigration(Main.java:643) 
     at liquibase.integration.commandline.Main.main(Main.java:116) 

Könnte es sein, dass die Anzahl gleichzeitiger Sitzungen/Transaktionen erreicht wird? Hat jemand irgendwelche Ideen?

Answer 1

Das Problem war die fehlerhafte Implementierung von SequenceExists in Liquibase. Da die Änderung mit diesen Anweisungen sehr lange dauerte, wurde sie versehentlich abgebrochen. Dann versuchen Sie das nächste Mal, die liquibase-Skripte auszuführen, die die Sperre enthielt.

<changeSet author="user" id="123"> 
    <preConditions onFail="CONTINUE"> 
     <not><sequenceExists sequenceName="SEQUENCE_NAME_SEQ" /></not> 
    </preConditions> 
    <createSequence sequenceName="SEQUENCE_NAME_SEQ"/> 
    </changeSet> 

A Arbeit um Klar SQL verwendet diese anstatt zu überprüfen:

<changeSet author="user" id="123"> 
    <preConditions onFail="CONTINUE"> 
      <sqlCheck expectedResult="0"> 
       select count(*) from user_sequences where sequence_name = 'SEQUENCE_NAME_SEQ'; 
      </sqlCheck> 
    </preConditions> 
    <createSequence sequenceName="SEQUENCE_NAME_SEQ"/> 
    </changeSet> 

Lockdata in der Tabelle DATABASECHANGELOCK gespeichert ist. Um die Sperre loszuwerden, ändern Sie einfach 1 zu 0 oder lassen Sie die Tabelle fallen und erstellen Sie sie neu.

Answer 2

Wenn die Update-Anwendung abrupt gestoppt wird, bleibt die Sperre manchmal hängen.

Dann

UPDATE DATABASECHANGELOGLOCK SET LOCKED=FALSE, LOCKGRANTED=null, LOCKEDBY=null where ID=1; 

gegen die Datenbank hilft läuft.

Oder Sie können einfach die DATABASECHANGELOGLOCK Tabelle fallen lassen, es wird neu erstellt.

Answer 3

Ich weiß zu schätzen, dass dies nicht das Problem des OP war, aber ich stieß vor kurzem mit einer anderen Ursache auf dieses Problem. Als Referenz benutzte ich das Liquibase Maven Plugin (liquibase-maven-plugin: 3.1.1) mit SQL Server.

Wie auch immer, ich hatte irrtümlich kopiert und eingefügt eine SQL Server "use" -Anweisung in eines meiner Skripte, die Datenbanken wechselt, so liquibase lief und aktualisiert die DATABASECHANGELOGLOCK, die Sperre in der richtigen Datenbank erwerben, aber dann Datenbanken wechseln um die Änderungen zu übernehmen. Nicht nur konnte ich meine Änderungen oder liquibase in der richtigen Datenbank NICHT sehen, aber natürlich, als ich liquibase wieder lief, konnte es die Sperre nicht erwerben, da die Sperre in der "falschen" Datenbank veröffentlicht worden war und so war immer noch in der "richtigen" Datenbank gesperrt. Ich hätte erwartet, dass liquibase überprüfen würde, ob die Sperre noch angewendet wurde, bevor es veröffentlicht wird, und vielleicht ist das ein Fehler in liquibase (ich habe das noch nicht überprüft), aber es könnte in späteren Versionen angesprochen werden! Das heißt, ich denke, es könnte als ein Merkmal betrachtet werden!

Ziemlich ein Schuljungen Fehler, ich weiß, aber ich hebe es hier für den Fall, dass jemand in das gleiche Problem läuft!

Answer 4

Es ist möglicherweise wegen eines getöteten liquibase-Prozesses, der seine Sperre auf der DATABASECHANGELOGLOCK-Tabelle nicht freigibt. Dann,

DELETE FROM DATABASECHANGELOGLOCK; 

könnte Ihnen helfen.

Bearbeiten: @Adrian Ber Antwort bietet eine bessere Lösung als diese. Tun Sie dies nur, wenn Sie Probleme mit seiner Lösung haben.

Answer 5

Manchmal Abbrechen oder Löschen der Tabelle DATABASECHANGELOGLOCK funktioniert nicht. Ich benutze PostgreSQL-Datenbank und stieß oft auf dieses Problem. Ich lösche die vorbereiteten Anweisungen, die im Hintergrund für diese Datenbank ausgeführt werden. Versuchen Sie, alle vorbereiteten Anweisungen rückgängig zu machen, und versuchen Sie erneut, Änderungen an der liquibase vorzunehmen.

SQL:

SELECT gid FROM pg_prepared_xacts WHERE database='database_name'; 

Wenn obige Aussage jeden Datensatz zurückgibt, Rollback dann die vorbereitete Anweisung mit SQL-Anweisung folgt.

ROLLBACK PREPARED 'gid_obtained_from_above_SQL';