Informix 12.0脚本可逆性问题：能否通过脚本T回滚至S执行前状态？

首先明确：不是所有脚本S都能找到对应的脚本T，将数据库完全恢复到S执行前的初始状态，具体分以下情况分析：

你提到的保存点回滚方案的局限性 #

你的第一种方案（事务+保存点回滚）仅在满足以下全部条件时有效：

• S的所有操作都处于未提交的事务中，且S里没有执行COMMIT语句——一旦提交，保存点和整个事务的回滚能力就会失效。
• S中没有执行数据库不支持回滚的操作：
  • 多数数据库的部分DDL操作不可回滚，比如DROP DATABASE、CREATE TABLESPACE、TRUNCATE TABLE（不同数据库有差异，比如PostgreSQL 12+支持TRUNCATE回滚，但MySQL的InnoDB对TRUNCATE仍视为不可回滚操作）。
  • 部分数据库的特定DML或系统操作也无法回滚，比如MySQL中MyISAM引擎表的写操作本身不支持事务。
• S没有触发任何数据库外部的副作用：比如调用存储过程修改了服务器文件系统、发送了外部消息、调用了第三方API等——这些操作不在事务管辖范围内，回滚数据库无法逆转外部影响。

无法通过任何脚本T逆转的场景 #

如果S存在以下任一情况，原则上不可能通过脚本T完全恢复初始状态：

1. 包含不可回滚的DDL操作：比如执行了DROP TABLE且没有提前备份表结构和数据，此时没有任何脚本能凭空恢复已删除的表。
2. 提交了事务：如果S里有COMMIT，之前的所有操作都已持久化到数据库，保存点回滚完全无效，除非用日志恢复（但这本质是备份/日志恢复方案，你提到该方案不可行）。
3. 依赖执行时的动态数据：比如S里有INSERT INTO table VALUES(RAND())这类生成随机值的操作，或者依赖当前时间、会话变量的操作，无法准确生成反向脚本将数据还原到初始状态。
4. 修改了系统级元数据：比如修改了数据库用户权限、配置参数（部分参数修改后即时生效且不可回滚），这类操作无法通过普通事务回滚恢复。

总结 #

只有当S的所有操作都支持事务回滚、未提交事务、且无外部副作用时，你提到的ROLLBACK WORK TO SAVEPOINT TXN1才能作为有效的T脚本。一旦S触及上述任何不可逆转的操作，就无法通过脚本T实现完全恢复。

内容的提问来源于stack exchange，提问作者Ddll