我将对Server数据库运行一些查询,然后是delete。理想情况下,所有这些都发生在事务内部(即原子)。
但实际上,由于数据早已从缓冲区中清除,Server必须执行大量物理IO才能完成事务处理的to。这可能是一个问题,因为如果整个批处理运行时间超过30秒,那么用户将遇到超时问题。
我注意到,如果我分段运行我的select,每次运行越来越多的最终SQL,让Server用越来越多的所需数据填充缓冲区。例如:
首次运行
BEGIN TRANSACTION
SELECT ... WHERE ...
ROLLBACK第二次运行
BEGIN TRANSACTION
SELECT ... WHERE ...
SELECT ... WHERE ...
ROLLBACK..。
第n次运行
BEGIN TRANSACTION
SELECT ... WHERE ...
SELECT ... WHERE ...
...
SELECT ... WHERE ...
ROLLBACK当我到达最终运行时,
BEGIN TRANSACTION
SELECT ... WHERE ...
SELECT ... WHERE ...
...
SELECT ... WHERE ...
DELETE FROM ... WHERE ...
COMMIT由于缓冲区是预先填充的,整个批处理运行得很快。
是否有一种Server模式(即SET NOEXEC ON)会导致Server不执行任何实际的数据修改,不接受任何锁,而是用所需的数据填充缓冲区?例如:
SET NOEXEC ON
EXECUTE ThatThingYouDo
SET NOEXEC OFF
EXECUTE ThatThingYouDo或
SET DRYRUN ON
EXECUTE ThatThingYouDo
SET DRYRUN OFF
EXECUTE ThatThingYouDo发布于 2010-03-03 20:07:03
不是的。
假设您已经插入,然后是插入行的更新。您永远无法模拟更新,因为插入的行不存在。现在,在这种情况下,为什么您的选择在事务中?默认情况下(即除非使用HOLDLOCK或类似的),您不会在事务期间锁定行。
如果你认为缓冲池。(数据缓存)是“满的”,那么您需要更多的RAM或其他升级/升级。
发布于 2010-03-03 20:02:20
我发现,每当你试图做一些异常的事情来解决一个问题,你的基本设计最有可能是问题。这是非常不正常的。
也许您可以提供更多关于delete (表大小、活动、索引、要删除的行、正在运行的其他进程等)的信息,这样就会有一个传统的解决方案,使用索引或锁定等等来解决这个问题。
https://stackoverflow.com/questions/2374457
复制相似问题