Rollback and before-images¶
Edition: Community and Enterprise
Every fix can be undone, and undoing it exposes no more data than the fix did.
The before-image¶
Right before a fix changes anything, the executor reads the rows the statements will change, in the same transaction, with the same bound values, and locks them. That copy is the before-image. The executor seals it to its own key, like the values, and stores it with the execution.
A before-image holds each row's key and the columns that change (whole rows for a DELETE).
It can hold more customer data than the values themselves, which is why it is sealed too.
A table without a primary or unique key
Without a key, sealfix cannot tell which row to restore. Check W1 warns the DBA reviewer: such a fix cannot be rolled back.
A rollback is a request¶
flowchart LR
F["Executed fix"] -->|"Request rollback, with a reason"| RB["Rollback request<br/>built from the sealed before-image"]
RB --> DR["Dry run"] --> AP["Same approvals<br/>as any fix"] --> EX["Executor restores the rows"]
EX --> RF["Original fix shows<br/>Rolled back"]
classDef box fill:#E9EEF6,stroke:#23407A,color:#13202D
class F,RB,DR,AP,EX,RF box
- The requester of an executed fix asks for the rollback, with a reason.
- The rollback has its own dry run and needs the same approvals. Its page shows how many rows the before-image holds, never what they contain, to anyone, the requester included.
- If the rows changed since the fix ran, the rollback is refused at its dry run and again at execution, so it never overwrites someone else's later change.
- Only one rollback of a fix can be open at a time.
Triggers and side effects¶
A trigger can change other tables, or reach outside the database, when the fix runs. A rollback restores the fix's own rows only. That is why the dry run lists every trigger the fix fires, and the requester decides per trigger: let it run, or (where the policy allows it) disable it inside the transaction. A trigger with effects outside the database is always refused.