如何跟踪 SQL 更新的进度?

发布于 2024-10-13 06:46:44 字数 226 浏览 9 评论 0原文

假设我有一个更新,例如:

  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 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

花开柳相依 2024-10-20 06:46:44

您可以使用 sysindexes 表,它跟踪索引的更改量。因为这是在原子更新中完成的,所以它没有机会重新计算统计信息,因此 rowmodctr 将继续增长。有时,这在小表中并不明显,但对于数百万人来说,它会显示出来。

-- create a test table
create table testtbl (id bigint identity primary key clustered, nv nvarchar(max))

-- fill it up with dummy data. 1/3 will have a trailing ':'
insert testtbl
select
    convert(nvarchar(max), right(a.number*b.number+c.number,30)) + 
    case when a.number %3=1 then ':' else '' end
from master..spt_values a
inner join master..spt_values b on b.type='P'
inner join master..spt_values c on c.type='P'
where a.type='P' and a.number between 1 and 5
-- (20971520 row(s) affected)

update testtbl
set nv = left(nv, len(nv)-1)
where nv like '%:'

现在在另一个查询窗口中,连续运行以下命令并观察 rowmodctr 的不断上升。如果您知道 rowmodctr 需要最终到达的位置,那么 rowmodctrrows 可以让您了解自己的进展情况。在我们的例子中,这一数字是刚刚超过 200 万的 67%。

select rows, rowmodctr
from sysindexes with (nolock)
where id = object_id('testtbl')

在更新表本身时,请不要运行(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.

-- create a test table
create table testtbl (id bigint identity primary key clustered, nv nvarchar(max))

-- fill it up with dummy data. 1/3 will have a trailing ':'
insert testtbl
select
    convert(nvarchar(max), right(a.number*b.number+c.number,30)) + 
    case when a.number %3=1 then ':' else '' end
from master..spt_values a
inner join master..spt_values b on b.type='P'
inner join master..spt_values c on c.type='P'
where a.type='P' and a.number between 1 and 5
-- (20971520 row(s) affected)

update testtbl
set nv = left(nv, len(nv)-1)
where nv like '%:'

Now in another query window, run the below continuously and watch the rowmodctr going up and up. rowmodctr vs rows gives you an idea where you are up to, if you know where rowmodctr needs to end up being. In our case, it is 67% of just over 2 million.

select rows, rowmodctr
from sysindexes with (nolock)
where id = object_id('testtbl')

Please don't run (nolock) counting queries on the table itself while it is being updated.

倾`听者〃 2024-10-20 06:46:44

不是真的...您可以使用 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...)

岁月染过的梦 2024-10-20 06:46:44

数据库查询,特别是数据操作语言(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.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文