如何跟踪 SQL 更新的进度?
假设我有一个更新,例如:
UPDATE [db1].[sc1].[tb1]
SET c1 = LEFT(c1, LEN(c1)-1)
WHERE c1 like '%:'
此更新基本上将遍历数百万行并修剪冒号(如果 c1 列中有冒号)。
我如何跟踪表中的进展情况?
谢谢
这是sql server 2008
Let's say I have an update such as:
UPDATE [db1].[sc1].[tb1]
SET c1 = LEFT(c1, LEN(c1)-1)
WHERE c1 like '%:'
This update is basically going to go through millions of rows and trim the colon if there is one in the c1 column.
How can I track how far along in the table this has progressed?
Thanks
This is sql server 2008
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
您可以使用 sysindexes 表,它跟踪索引的更改量。因为这是在原子更新中完成的,所以它没有机会重新计算统计信息,因此 rowmodctr 将继续增长。有时,这在小表中并不明显,但对于数百万人来说,它会显示出来。
现在在另一个查询窗口中,连续运行以下命令并观察 rowmodctr 的不断上升。如果您知道
rowmodctr
需要最终到达的位置,那么rowmodctr
与rows
可以让您了解自己的进展情况。在我们的例子中,这一数字是刚刚超过 200 万的 67%。在更新表
本身
时,请不要运行(nolock)计数查询。You can use the sysindexes table, which keeps track of how much an index has changed. Because this is done in an atomic update, it won't have a chance to recalc statistics, so
rowmodctr
will keep growing. This is sometimes not noticeable in small tables, but for millions, it will show.Now in another query window, run the below continuously and watch the rowmodctr going up and up.
rowmodctr
vsrows
gives you an idea where you are up to, if you know whererowmodctr
needs to end up being. In our case, it is 67% of just over 2 million.Please don't run (nolock) counting queries on the table
itself
while it is being updated.不是真的...您可以使用 nolock 提示和相同的 where 进行查询,但这会占用资源
当然这不是带有前导通配符的最佳查询...)
Not really... you can query with the nolock hint and same where, but this will take resources
It isn't an optimal query with a leading wildcard of course...)
数据库查询,特别是数据操作语言(DML),是原子的。这意味着插入/更新/删除要么成功发生,要么不成功。没有办法查看正在处理哪些记录——对于数据库来说,一旦在 UPDATE 后发出 COMMIT,它们都已更改。即使您能够查看正在处理的记录,当您看到该值时,查询也将继续处理其他记录。
了解流程中哪个位置的唯一方法是将查询编写为在循环内发生的脚本,因此您可以使用计数器来了解处理了多少个查询。这样做很常见,因此定期提交大型数据集,以最大限度地降低需要重新运行整个查询的失败风险。
Database queries, particularly Data Manipulation Language (DML), are atomic. That means that the INSERT/UPDATE/DELETE either successfully occurs, or it doesn't. There's no means to see what record is being processed -- to the database, they all had been changed once the COMMIT is issued after the UPDATE. Even if you were able to view the records in process, by the time you would see the value, the query will have progressed on to other records.
The only means to knowing where in the process is to script the query to occur within a loop, so you can use a counter to know how many are processed. It's common to do this so large data sets are periodically committed, to minimize the risk of failure requiring having to run the entire query over again.