2013-08-19 37 views
1

在Windows XP SP3下,MS SQL Server 2008 R2中有數百萬條記錄數據庫。ODBC DSN降低MSSQL的超時時間

我的同事編寫了一個.Net應用程序,它直接連接到這個數據庫並運行合理數量的查詢。我不知道.Net,但我確定這個應用程序不使用ODBC連接到數據庫。

另一方面,我寫了一個命令行python(CPython版本2.7.5)應用程序,它連接到這個數據庫並運行簡單的查詢來通過互聯網將數據發送到別的地方。數據庫連接使用pyodbc 3.0.7(http://www.lfd.uci.edu/~gohlke/pythonlibs/的安裝程序)和使用SQL Server Native Client 10.0驅動程序的DSN進行。我試過在windows Data Sources (ODBC) applet的Connection Pooling選項卡上爲此驅動程序禁用和啓用連接池。該腳本從數據庫發送100條記錄,然後關閉連接並休眠2分鐘,然後再次運行。

這兩個程序都和db一樣在同一臺機器上運行。

問題是.net應用程序運行良好,當我刪除定義的DSN(當然python腳本沒有運行)。當我再次定義DSN並啓動python腳本並行運行.Net應用程序時,大概5個小時沒有問題。但隨後python腳本逐漸好起來,.Net應用程序開始從db中獲取超時。

發生這種情況會出現什麼問題?

編輯:

python腳本(連接使用ODBC)運行正常,所有的時間。但.Net應用程序在幾個小時後就會落後於通常的性能。當我關閉python腳本時,.Net應用程序仍然滯後。但是當我刪除我爲python腳本定義的ODBC DSN時,.Net應用程序會恢復正常性能。這很奇怪。正如我所說我不知道​​.Net,所以這可能是.Net應用程序的非標準代碼的結果,可能是打開的交易,鎖定,太多的連接等。爲了使案件陌生,切割通過刪除記錄和重建索引來將數據庫大小減半,似乎已經解決了.Net應用程序問題。

編輯2:

只有兩個查詢了Python腳本運行,分別是:

SELECT TOP 100 FROM tbl_data WHERE id > ? ORDER BY id 

SELECT * FROM tbl_data WHERE id = ? 

的第一個查詢通常只在蟒每次運行運行一次腳本。第二個最多運行100次。 id是主鍵,因此被索引。正如你所看到的那樣,查詢並不簡單。對於第一個查詢,我讀取程序中的整個結果集,以防止在DB服務器上打開遊標。另外,我已經關閉了ODBC applet中的連接池,供我使用的驅動程序使用,因此每次腳本運行後,數據庫連接都應該已經處理完畢,並且數據庫服務器上的所有資源都應該已經釋放。該劇本睡了2分鐘,然後重複此操作。

.Net應用程序運行的查詢要複雜得多,並與數據庫上的一些觸發器結合在一起。奇怪的是它本身運行得很好。但是當定義DSN時,它會開始在單個插入語句中等待很長時間,這有時會導致超時。

另外我應該說Windows和MSSQL沒有使用微軟的最新補丁更新,所以如果它是ODBC驅動程序或MSSQL本身的錯誤,它可能已經爲其他人解決了。

編輯3

表被聚集在PK索引上。該數據表現在包含大約150萬條記錄。數據庫大小約爲160GB。服務器沒有高規格。英特爾酷睿i7 2600,4GB內存,普通1TB SATA磁盤驅動器。

+0

非常感謝您的更新。主鍵是羣集還是非羣集?此服務器(內存,CPU等)有多大? –

+0

我編輯了問題 – aalizadeh

+1

根據您所描述的一切,看起來您的python(ODBC)應用程序由於資源爭用而阻止.Net應用程序。超時只能由一些事情引起,資源爭用,長時間運行的查詢和阻塞是常見的嫌疑人。當性能下降時,您是否查看了活動連接以查看是否存在阻塞問題。 –

回答

1

有許多事情可能會影響性能。有可能是資源爭奪,次優的SQL Server配置,慢磁盤,缺失索引等...

我會從兩個進程運行時監視系統資源開始。您可以使用perfmon來監視OS和SQL計數器。我會通過ProcessorInformation /%ProcessorTime

邏輯磁盤/平均磁盤秒/讀取

邏輯磁盤/平均磁盤秒/寫

內存/可用兆字節看着

  • 開始

    SQLServerBufferManager/BufferCacheHitRatio

    SQLServerBufferManager/PageLifeExpectency

下面是使用性能監視器一個偉大的文章,http://www.brentozar.com/archive/2006/12/dba-101-using-perfmon-for-sql-performance-tuning/

下一步是優化查詢和SQL Server的性能。

查詢性能,http://technet.microsoft.com/en-us/magazine/2007.11.sqlquery.aspx SQL Server性能,

的一點是,有可能會影響你的數據庫這麼多的可能性,這是幾乎不可能根據所提供的信息,以確定您的問題。我建議您仔細閱讀這些項目,以確定系統運行不理想的原因。

+0

感謝您提供有用的信息,但正如我所說的,當沒有ODBC DSN時,.Net應用運行良好。所以我想這個問題應該與ODBC有關。與此同時,我正在使用pssssql庫重寫腳本以直接連接到mssql,該庫使用mssql C API。如果可行的話,那麼**必須對ODBC有點腥意。 – aalizadeh

+0

是什麼讓你相信ODBC DSN可能是罪魁禍首?你是否通過ODBC DSN執行查詢並直接在SQL Server中運行它?如果是的話,它跑得快得多嗎?我試圖弄清楚你是如何得出這個結論的。你的結論可能是正確的,我只是想了解你有沒有嘗試過。 –

+0

我編輯了問題 – aalizadeh