MS-SQL 2000:在存储过程期间关闭日志记录

发布于 2024-07-12 00:11:37 字数 473 浏览 10 评论 0原文

这是我的场景:

我有一个简单的存储过程,它从表中删除一组特定的行(我们假设大约 30k 行),然后插入大约相同数量的行。 这通常只需要几秒钟; 但是,该表上有一个触发器,用于监视插入/删除,并尝试模仿另一台服务器上的链接表所发生的情况。

由于触发器的原因,这个过程又慢得难以忍受,并且在此过程中表也被锁定。 所以这是我的两个问题:

  1. 我猜速度放缓的很大一部分是由于事务日志造成的。 有没有办法让我在存储过程中指定我不希望记录过程中的内容?
  2. 有没有办法让我执行“DELETE FROM”和“INSERT INTO”命令,而无需在整个过程中锁定表?

谢谢!

编辑 - 感谢您的回答; 我认为情况确实如此(无法执行上述任一操作),但想确定一下。 该触发器是很久以前创建的,看起来效率不高,所以看来我的下一步将是深入研究并找出需要什么以及如何改进。 谢谢!

Here's my scenario:

I have a simple stored procedure that removes a specific set of rows from a table (we'll say about 30k rows), and then inserts about the same amount of rows. This generally should only take a few seconds; however, the table has a trigger on it that watches for inserts/deletes, and tries to mimic what happened to a linked table on another server.

This process in turn is unbareably slow due to the trigger, and the table is also locked during this process. So here are my two questions:

  1. I'm guessing a decent part of the slowdown is due to the transaction log. Is there a way for me to specify in my stored procedure that I do not want what's in the procedure to be logged?
  2. Is there a way for me to do my 'DELETE FROM' and 'INSERT INTO' commands without me locking the table during the entire process?

Thanks!

edit - Thanks for the answers; I figured it was the case (not being able to do either of the above), but wanted to make sure. The trigger was created a long time ago, and doesn't look very effecient, so it looks like my next step will be to go in to that and find out what's needed and how it can be improved. Thanks!

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

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

发布评论

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

评论(5

风流物 2024-07-19 00:11:37

1) 不,您也没有执行 TRUNCATE 或 BULK INSERT 等最小日志记录操作

2) 不,否则您将如何防止损坏?

1) no, also you are not doing a minimally logged operation like TRUNCATE or BULK INSERT

2) No, how would you prevent corruption otherwise?

深海里的那抹蓝 2024-07-19 00:11:37

我不会自动假设性能问题是由于日志记录造成的。 事实上,触发器的编写方式很可能会导致性能问题。 我鼓励您修改原来的问题并显示触发器的代码。

I wouldn't automatically assume that the performance problem is due to logging. In fact, it's likely that the trigger is written in such a way that is causing your performance problems. I encourage you to modify your original question and show the code for the trigger.

风苍溪 2024-07-19 00:11:37

修改数据时无法关闭事务完整性。 当你使用 select * from table (nolock) 选择数据时,你可以忽略锁; 但是,您需要非常小心并确保您的应用程序可以处理脏读。

You can't turn off transactional integrity when modifying the data. You could ignore locks when you select data using select * from table (nolock); however, you need to be very careful and ensure your application can handle doing dirty reads.

孤独患者 2024-07-19 00:11:37

它对您的触发器没有帮助,但锁定问题的解决方案是以较小的批次执行事务。

而不是

DELETE FROM Table WHERE <Condition>

做类似的事情

WHILE EXISTS ( SELECT * FROM table WHERE <condition to delete>)
BEGIN
  SET ROWCOUNT 1000
  DELETE FROM Table WHERE <Condition>
  SET ROWCOUNT 0
END

It doesn't help with your trigger, but the solution to the locking issue is to perform the transactions in smaller batches.

Instead of

DELETE FROM Table WHERE <Condition>

Do something like

WHILE EXISTS ( SELECT * FROM table WHERE <condition to delete>)
BEGIN
  SET ROWCOUNT 1000
  DELETE FROM Table WHERE <Condition>
  SET ROWCOUNT 0
END
流星番茄 2024-07-19 00:11:37

您可以暂时禁用触发器,运行您的过程,然后以更有效的方式执行触发器正在执行的任何操作。

-- disable trigger
ALTER TABLE [Table] DISABLE TRIGGER [Trigger]
GO

-- execute your proc
EXEC spProc
GO

-- do more stuff to clean up / sync with other server
GO

-- enable trigger
ALTER TABLE [Table] ENABLE TRIGGER [Trigger]
GO

You can temporarily disable the trigger, run your proc, then do whatever the trigger was doing in a more efficient manner.

-- disable trigger
ALTER TABLE [Table] DISABLE TRIGGER [Trigger]
GO

-- execute your proc
EXEC spProc
GO

-- do more stuff to clean up / sync with other server
GO

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