2009-10-21 37 views
2

我正在將SQL Enterprise Manager 2000上的作業放在一起以複製和刪除幾個數據庫表中的記錄。我們運行了一個直接批量複製和刪除存儲過程,但它可能會在數百萬行中運行它,因此會掛起服務器。我有興趣嘗試一次運行100-ish記錄塊,因此服務器不會停下來(這是一個活動的Web數據庫)。我希望這個服務每晚運行一次,這就是爲什麼我把它放在代理工作中。有什麼方法可以將調用循環到實際進行復制和刪除的存儲過程,然後在每次調用之間「休眠」以使服務器有時間趕上?我知道有WAITFOR命令,但我不確定這是否會保持處理器或讓它在此期間運行其他查詢。使用SQL代理作業調用循環中的過程

謝謝!

回答

2

「刪除塊」是刪除過量數據而不會增加事務日誌文件的首選方法。 BradC的帖子就是一個合理的例子。

管理這樣的循環最好在單個存儲過程中完成。隨着時間的推移,爲了傳播這些工作,我仍然保留在程序中。如果您認爲有必要處理可能發生的併發問題,則在循環中插入WAITFOR會在每次刪除之間設置一個「暫停」。使用SQL代理作業確定過程何時開始 - 如果需要確保過程停止一段時間,則將其應用到循環中。

我對這個代碼旋轉將是:

-- NOTE: This is a code sample, I have not tested it 
CREATE PROCEDURE ArchiveData 

    @StopBy DateTime 
    -- Pass in a cutoff time. If it runs this long, the procedure will stop. 
AS 

DECLARE @LastBatch int 

SET @LastBatch = 1 
-- Initialized to make sure the loop runs at least once 


WHILE @LastBatch > 0 
BEGIN 

    WAITFOR DELAY '00:00:02' 
    -- Set this to your desired delay factor 

    DELETE top 1000 -- Or however many per pass are desired 
    from SourceTable 
    -- Be sure to add a where clause if you don't want to delete everything! 

    SET @LastBatch = @@rowcount 

    IF getdate() > @StopBy 
     SET @LastBatch = 0 

END 

RETURN 0 

嗯。重新讀你的帖子意味着你想在刪除它之前先將數據複製到某個地方。爲此,我將設置一個臨時表,並在循環內首先截斷臨時表,然後複製TOP N項的主鍵,通過連接到臨時表中插入到「存檔」表中,然後通過加入臨時表來刪除源表。 (只是比直接刪除更復雜一點,不是嗎?)

+0

你是對的。在兩個表格中,我在技術上將數據「歸檔」,如將數據複製到同一服務器上的另一個數據庫,然後刪除現有記錄。在另一張表中,我只是刪除了某個日期之前創建的所有記錄。 我想過使用臨時表來協助轉移,我最終可能會這樣做。我會試試看你的建議,看看結果如何。謝謝! – Kevin 2009-10-21 14:52:17

0

WAITFOR會讓其他進程「走開」。我已經使用這種技術來阻止大DELETE鎖定機器。創建一個WHILE循環,刪除一行數據塊,然後等待幾秒鐘(或者更少,只要是合適的)。

1

不要擔心在循環之間等待,SQL服務器應該處理維護作業和服務器上常規活動之間的爭用。

在這些類型的情況下,真正導致問題的原因是整個刪除過程在一次事務中同時發生。這會炸燬數據庫的日誌,並可能導致您聽到的各種問題,如您所遇到的情況。

使用這樣一個循環來刪除管理的塊:

DECLARE @i INT 
SET @i = 1 

SET ROWCOUNT 10000 

WHILE @i > 0 
BEGIN 
    BEGIN TRAN 
     DELETE TOP 1000 FROM dbo.SuperBigTable 
     WHERE RowDate < '2009-01-01' 
    COMMIT 

    SELECT @i = @@ROWCOUNT 
END 
SET ROWCOUNT 0 

您可以使用類似的邏輯,你的副本。

+0

感謝您的反饋。如果此代碼是在存儲過程中執行的(並從代理作業中調用)還是僅在代理作業本身中執行? – Kevin 2009-10-21 14:33:16

+0

不,不是真的。只是個人喜好/公司政策。 – BradC 2009-10-21 14:43:10