Table of Contents
Overview
When a Datical/Liquibase Enterprise/Liquibase Business deployment process is aborted or killed before it finishes, its database process lock table (DATABASECHANGELOGLOCK) is left with a lock record that prevents subsequent packaging or deployment jobs from being able to run. In order to allow future processes to proceed, the table needs to be cleared out by manually updating the column to 0 (zero). This can happen with any of the supported database platforms.
If the target is an Oracle database the DATICAL_SPERRORLOG
table might also be held open. The DATICAL_SPERRORLOG
table is used to capture output for scripts executed using sqlplus
during a deployment.
Newer versions of Datical have better ways of handling the locks, so we recommend upgrading to Datical DB version 7.3 or higher for the smoothest handling of the locks. Please see below for different instructions for different versions of Datical.
Sample Error
Below is sample text you may see in the Deploy Report if there is a lock on the databasechangeloglock table:
...
The instructions for 7.3 and higher are simpler, because the hammer command works for both the DATABASECHANGELOGLOCK table and the Oracle DATICAL_SPERRORLOG table. We recommend upgrading to 7.3 or higher if you sometimes need to interrupt deploys and then use the releaseLocks command before running another deploy.
Code Block | ||||
---|---|---|---|---|
| ||||
hammer releaseLocks <dbDef> |
...
Code Block | ||||
---|---|---|---|---|
| ||||
hammer releaseLocks <dbDef> |
...
If you are using Oracle with Datical version 7.2 and you need to manually terminate a packager job or a deploy job, the DATICAL_SPERRORLOG table may be held open on your Datical tracking schema. You may need to disconnect the session for the user that runs Datical. The DATICAL_SPERRORLOG
table is used to capture output for scripts executed using sqlplus
during an Oracle deployment.
Here is how you can disconnect the session:
- Run a query to find the process
Code Block |
---|
SELECT s.inst_id, s.sid, s.serial#, p.spid, s.username, s.program FROM gv$session s JOIN gv$process p ON p.addr = s.paddr AND p.inst_id = s.inst_id; |
- Disconnect the session with the following statement.
Code Block |
---|
ALTER SYSTEM DISCONNECT SESSION 'sid,serial#' IMMEDIATE; |
...
If you are using Oracle with Datical version 7.0 and you need to manually terminate a packager job or a deploy job, the DATICAL_SPERRORLOG table may be held open on your Datical tracking schema. You may need to disconnect the session for the user that runs Datical. The DATICAL_SPERRORLOG
table is used to capture output for scripts executed using sqlplus
during an Oracle deployment.
Here is how you can disconnect the session:
- Run a query to find the process
Code Block |
---|
SELECT s.inst_id, s.sid, s.serial#, p.spid, s.username, s.program FROM gv$session s JOIN gv$process p ON p.addr = s.paddr AND p.inst_id = s.inst_id; |
- Disconnect the session with the following statement.
Code Block |
---|
ALTER SYSTEM DISCONNECT SESSION 'sid,serial#' IMMEDIATE; |
...
Note that if you update the DATABASECHANGELOGLOCK table manually, for Oracle you may also need to disconnect the session for the user that runs Datical. The DATICAL_SPERRORLOG
table is used to capture output for scripts executed using sqlplus
during an Oracle deployment.
Here is how you can disconnect the session:
- Run a query to find the process
Code Block |
---|
SELECT s.inst_id, s.sid, s.serial#, p.spid, s.username, s.program FROM gv$session s JOIN gv$process p ON p.addr = s.paddr AND p.inst_id = s.inst_id; |
- Disconnect the session with the following statement.
Code Block |
---|
ALTER SYSTEM DISCONNECT SESSION 'sid,serial#' IMMEDIATE; |
...