标签: rollback

四天前，一个用户在一个有 400,000,000 行的表上运行了下面的命令。它仍在运行，日志文件的大小也在增加。

delete from [table-name]

该表确实有一个未启用检查的外键约束，我知道另一个表中不存在任何行。

数据库正在启用“Is Read Committed Snapshot On”并处于简单恢复模式下运行。

在这运行了几个小时之后，我发出了一个终止会话命令，因为我们的日志文件磁盘空间不足。我添加了另一个日志文件以允许系统继续运行。

日志文件继续增长，当我使用 statusonly 运行 kill session 时，它返回此消息：

SPID 123: transaction rollback in progress. Estimated rollback completion: 0%. Estimated time remaining: 0 seconds.

我不知道如何处理这个查询以使其回滚并且也只是了解正在发生的事情，任何人都可以建议我可以查看什么？

Postgres 监控脚本check_postgres.pl警告我数据库服务器上正在发生大量回滚。如何调查正在回滚的查询？我曾尝试搜索 Postgres 日志文件，但它不包含任何“回滚”一词的实例，而且我在 Postgres 手册中看不到任何有关启用回滚日志记录的内容。

我想TRUNCATE和INSERT数据到MySQL的InnoDB表。

我想确保如果事务中的任何语句失败，数据都不会受到影响。

如果出现故障，我不能有一个空的或损坏的表。

这就是我打算这样做的方式。

1. BEGIN TRANSACTION
2. TRUNCATE TABLE table_name
3. INSERT INTO table_name
4. COMMIT

然后我了解到这TRUNCATE TABLE table_name 会导致隐式 COMMIT，这使得整个交易毫无意义。

然后我TRUNCATE TABLE table_name用一种DELETE FROM table_name方法替换了，这并不理想 - 但这也会导致隐式 COMMIT！

DROP TABLE table_name并且CREATE TABLE table_name还会导致隐式 COMMIT！

什么方法/逻辑最适合执行我想要做的事情？

使用运行在 Windows Server 2008 R2 上的 MySQL 5.6.17 64 位服务器

我有一个查询需要 6000 万行，将它们复制到一个新表中，对它们进行一些更新，然后将它们插入到另一个新表中。这一切都包含在一个事务中。一开始我认为这会很好，但意识到这是一个愚蠢的错误。

虽然它在我的本地实例机器上运行了 7 个小时，但在生产数据库上运行了 2 天多！厌倦了等待并意识到我的解决方案可能不是执行此操作的最佳方法，我关闭了查询窗口并终止了该过程。现在，它正在回滚。

同时，我运行了这个：KILL 60 WITH STATUSONLY 和 EXEC sp_who2 'active'。状态显示“SPID 60：正在进行事务回滚。估计回滚完成：62%。估计剩余时间：31849 秒”。秒和磁盘正在上升，所以我知道它正在尝试进行回滚。它非常缓慢，并且每隔几个小时就会完成一个百分比。

我的问题是，由于我的操作，数据库变得很大并且占用了磁盘空间。此外，我不关心我试图复制到的这两个新表。我想截断/删除它们，然后用更好的方法来解决这个问题。但是，我不能在回滚过程中截断/删除它们？我不太关心这些新表会发生什么。它们也位于自己的文件组和 .ndf 文件中。我只想尽快删除这些，这样我就可以恢复我更好的方法。我正在使用 SQL 2014 并且需要紧急帮助，因为今天是星期六，我不想打扰我的老板！:)

是否可以回滚已提交的事务？

我已经删除了表中的所有数据。delete 语句在 Begin Transaction 中，我已经使用 commit transaction 命令提交了事务。现在是否可以回滚并取回数据？

我有一个非常繁忙的数据库，我被要求寻找回滚的事务。

我使用 SQL Server Profiler 来监视TM: RollbackTran Completed 事件，这表明每分钟都会发生几十个这样的事件，但它没有给我任何关于正在回滚的事务、回滚影响的对象的任何指示，或者回滚发生的原因。简而言之，它的用途似乎非常有限。

例如，如果我还尝试进行监控，以便为SQL:StmtStarting回滚提供一些上下文，那么在这个繁忙的环境中只会有太多噪音，无法识别哪个语句负责回滚。

我也试过运行语句

SELECT *
FROM fn_dblog (NULL, NULL)
WHERE Operation = 'LOP_ABORT_XACT';

但这并没有返回任何结果（考虑到 SQL Profiler 报告的回滚次数，这似乎很奇怪）。

有什么方法可以生成显示已回滚事务的报告？

蒂亚！

这可能是一个简单的问题，但我想检查回滚事务的机制。

据我了解，步骤如下：

1. BEGIN TRANSACTION （或同等学历）
2. 一个或多个 SQL 语句
3. COMMIT 或者 ROLLBACK

据我所知，如果其中一个 SQL 语句失败，例如无效INSERT或UPDATE.

这表明上述过程，直到提交可以在手动输入的语句集合中。

但是，我在哪个阶段做出回滚的决定？这是否表明ROLLBACK在程序中会发生更多的事情？换句话说，有人会手动回滚吗？

通过过程，我不一定指的是存储过程。我想某些应用程序可能会做同样的事情。

我认为这个问题一般适用于任何 SQL 数据库（当然，前提是它支持事务）。

它已建议该DDL在逻辑上进行这样的事情：

begin
    COMMIT;
    perform any appropriate pre-DDL trigger code;
    do the ddl;
    perform any appropriate post-DDL trigger code;
    COMMIT;
exception
    when others then
         ROLLBACK;
         raise;
end;

这表明触发器中的任何错误都会导致 DDL 回滚。是这种情况吗？

在 SQL Server 2008 R2 中工作时，我试图将一组 DDL 语句作为一个组回滚（想想数据库的升级脚本），但遇到了麻烦。

取以下代码：

begin try

begin tran

create table foo (i int)
alter table foo add x dog
insert into foo select 1,1
insert into foo select 1,1,1

commit tran

end try

begin catch

rollback tran
print @@error

end catch

我期待尝试在更改表语句上失败，下降到捕获，回滚事务，并打印错误消息。但是，如果您检查对象/表，您会看到 foo 仍然存在（因此创建表没有正确回滚）。

select * from sys.objects where name = 'foo'

我在这里做错了什么？

当一个事务在 SQL Server 中打开时，它可以回滚的所有方式是什么？我们目前正在使用一个 3rd 方应用程序，该应用程序经常在查询处于睡眠状态时显示打开的事务，有时会持续数天（通过 sp_WhoIsActive 显示）。这使我相信应用程序中某处存在错误，不允许提交事务。这些事务可能回滚的所有方式是什么？

1. 客户端超时（如果指定）
2. 客户端关闭或重新启动应用程序
3. 手动终止 SPID
4. 还要别的吗？

我应该对已经打开数小时或数天的交易做些什么吗？如果他们无论如何都要回滚或超时，那么终止进程有什么害处吗？