運算力永遠不足

這兩天透過先前買的兩台 i7 8G RAM 加一個 SSD 三個一般 HD 的運算力,一台跑 SQL 2008,另一台跑 PowerPivot for Excel 2010,分析 5 千 9 百萬筆的 SQL Trace Log,分析效果不錯,但跑好久…

再度執行

INSERT tbTrace SELECT * FROM fn_trace_gettable(‘F:DB Log1t1_5584.trc’,1000)

再刪除全是 NULL 的欄位

DECLARE cur CURSOR FAST_FORWARD FOR
SELECT Name FROM sys.syscolumns where id=OBJECT_ID(‘tbTrace’) –AND length > -1

DECLARE @Name SYSNAME,@sql varchar(500),@ExecSql varchar(500)
SET @sql=’
IF NOT EXISTS(SELECT * FROM dbo.tbTrace WHERE @Name IS NOT NULL)
    ALTER TABLE dbo.tbtrace DROP COLUMN @Name

OPEN cur
FETCH NEXT FROM cur INTO @Name
WHILE @@FETCH_STATUS=0
BEGIN
    SET @ExecSql=REPLACE(@sql,’@Name’,@Name)
    –PRINT @ExecSql
    EXEC(@ExecSql)
    FETCH NEXT FROM cur INTO @Name
END
CLOSE cur
DEALLOCATE cur 

DB放在 SSD 似乎比 DB 檔跨在兩個硬碟還快…但一個多小時過去了,依然跑不出來,也無法知道進度。很早,透過資源監視器就可以知道讀入 .trc 檔的工作已經結束,但就看著 IO 在 tempdb 和目標資料庫間輪流帳跌,tempdb 的大小維持不動,目標資料庫持續增長…

透過  sys.dm_exec_requests 傳回的 percent_complete 和 estimated_completion_time 都是 0…僅能憑 sys.sysindexes 猜測進度

但慘的是 SSD 太小了,兩次硬碟空間用完,導致轉入失敗

不知 SQL Server 為何大量用 TempDB (可能是我有啟用 DB 的資料表壓縮之關係,所以過程中會大量寫入資料到tempdb,而後又從 tempdb 大量讀出資料寫入到目的資料庫)和 Log File,何時才可以指定單一句話不要有交易😦

image

2個小時又 15 分鐘後轉了 9 百萬筆紀錄…應該是設了 clustered index、一般 index 和壓縮同時做,導致變慢的吧…

用原先 6 千 9 百萬筆紀錄分析,而臨時隨機的分析 PowerPivot 果然好用

image

尖峰值時,SQL Server 光是執行完畢的 RPC:Completed(Event ID=10) 數,10 分鐘達 533740 次,哇…

發表迴響

在下方填入你的資料或按右方圖示以社群網站登入:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / 變更 )

Twitter picture

You are commenting using your Twitter account. Log Out / 變更 )

Facebook照片

You are commenting using your Facebook account. Log Out / 變更 )

Google+ photo

You are commenting using your Google+ account. Log Out / 變更 )

連結到 %s

%d 位部落客按了讚: