1

错误地，我在informix 中使用dbaccess session 执行了这个查询。

Delete from table #without where condition

意识到我应该使用的错误，我TRUNCATE又犯了一个愚蠢的错误。
我杀死了dbaccess会话。但是该表被完全锁定，我无法对该表执行任何操作。

我可以采取哪些步骤来移除锁和truncate桌子。

1) Restart Informix server
2) onmode -z <sessionid>  # Does not work. 
                            I see hell lot of sessions created for the delete query

有没有其他简单的方法来解决这个问题？

4

1 回答 1

1

假设您没有使用 Informix SE...

是否记录了数据库？如果是这样，您是否在显式（BEGIN WORK）事务中运行了该语句？

分析

如果您有一个未记录的数据库，那么服务器删除的每一行都会消失。如果您停止 DELETE，它不会撤消部分完成的更改。使用未记录的数据库意味着您不希望有保证的语句级恢复。

如果您有一个定期记录的数据库并且没有显式事务，那么在 DB-Access 会话终止后，该语句可能仍在运行。因为它作为单例语句运行，所以它将完成并提交。在它这样做之前，如果你强行关闭服务器，那么快速恢复将回滚语句（事务）。鉴于我看到“5 小时前”，我担心您现在及时关闭服务器的机会是有限的。

如果你有一个带有显式事务的日志数据库，或者一个 MODE ANSI 数据库（你总是在一个事务中），那么当 DELETE 语句完成时，服务器将等待 COMMIT，意识到会话连接是终止，并将回滚未提交的工作。

恢复

如果您有一个未记录的数据库，则只能恢复到上一个​​存档。因为它是未记录的，所以您无法从逻辑日志中恢复它（但同一实例中记录的其他数据库可以恢复到最后一个逻辑日志）。

如果您有一个已记录的数据库，并且您可以在 DELETE 语句完成之前关闭服务器——最好是在控制之下，但如果有必要会使其崩溃，那么快速恢复将解决这个问题。

如果 DELETE 已完成并提交，并且您有良好的备份，则可以考虑对数据库进行时间点还原。在您执行此操作时它会使其脱机（但如果表中的数据全部丢失，则您的数据库将暂时无法正常工作）。

如果这些情况都不适用，那么您应该联系 IBM 技术支持，他们可能能够执行一些小（而且不是那么小）的奇迹。

但是，您可能已经注意到，很大程度上取决于数据库的类型（未记录、记录、MODE ANSI）以及运行语句时是否存在有效的显式事务。

DBMS 的问题在于它们信任生物。如果您被授权进行手术，他们会假设您打算做您说您想做的事情，他们会继续并尽其所能做到这一点。当你不要求它做你打算要求的事情时，生活就会变得棘手；DBMS 仍然信任您并执行您实际要求它执行的操作。

于 2012-09-25T18:23:09.950 回答