我們正在嘗試追查性能問題的原因。針對DB2表的性能事務處理範圍
我們有一個包含主鍵和計數器的單行表。在一個事務中,我們讀取計數器的值,將值增加1並保存新值。
使用實體框架完成讀取和更新,我們使用可序列化的事務範圍,我們需要確保只讀取一次計數器值。
大部分時間需要0.1秒,然後有時需要1秒以上。我們還沒有找到任何模式來解釋爲什麼會發生這種情況。
使用事務範圍時是否有其他人遇到過變量性能?是否有助於放棄使用事務範圍並直接在連接上設置事務?
我們正在嘗試追查性能問題的原因。針對DB2表的性能事務處理範圍
我們有一個包含主鍵和計數器的單行表。在一個事務中,我們讀取計數器的值,將值增加1並保存新值。
使用實體框架完成讀取和更新,我們使用可序列化的事務範圍,我們需要確保只讀取一次計數器值。
大部分時間需要0.1秒,然後有時需要1秒以上。我們還沒有找到任何模式來解釋爲什麼會發生這種情況。
使用事務範圍時是否有其他人遇到過變量性能?是否有助於放棄使用事務範圍並直接在連接上設置事務?
我們現在已經解決了這個問題。
問題的根源在於DB2提供程序不支持事務提升。這導致事務範圍使用MSDTC分佈式事務進行處理。
我們將交易範圍的使用替換爲數據庫連接上設置的交易。
包括問題中的代碼的複合服務從3秒減少到0.3秒。
我記得很久以前就評論過這個問題,但最近我店裏的一些開發者已經開始使用TransactionScope,並且也遇到了性能問題。在嘗試使用search for some information時,Google搜索結果中的數據相當高。
我們碰到的問題是,使用TransactionScope(至少在我們正在運行的版本上,Client v9.7.4.4連接到DB2 z時,顯然鏈接命令(插入等)與BeginChain不起作用/ OS v 10)。
我以爲我會爲我們遇到的問題留下一個解決方法(在TransactionScope下運行多個[1k +] INSERT時速度很慢,但在範圍被移除並允許鏈接時運行正常)。我不確定它是否會直接幫助原始問題,但如果您查看允許使用DB2DataAdapter和基礎DataTable更新行的IBM.Data.DB2.dll類,則可以選擇一些選項。
下面是VB.NET一些示例代碼:
Private Sub InsertByBulk(tableName As String, insertCollection As List(Of Object))
Dim curTimestamp = Date.Now
Using scope = New TransactionScope
'Something that opens a connection to DB2, may vary
Using conn = GetDB2Connection()
'Dumb query to get DataTable from the ResultSet
Dim sql = String.Format("SELECT * FROM {0} WHERE 1=0", tableName)
Using adapter = New DB2DataAdapter(sql, conn)
Using table As New DataTable
adapter.FillSchema(table, SchemaType.Source)
For Each item In insertCollection
Dim row = table.NewRow()
row("ID") = item.Id
row("CHAR_FIELD") = item.CharField
row("QUANTITY") = item.Quantity
row("UPDATE_TIMESTAMP") = curTimestamp
table.Rows.Add(row)
Next
Using bc = New DB2BulkCopy(conn)
bc.DestinationTableName = tableName
bc.WriteToServer(table)
End Using 'BulkCopy
End Using 'DataTable
End Using 'DataAdapter
End Using 'Connection
scope.Complete()
End Using
End Sub
這不是一個真正的答案(因此,評論),但你爲什麼要儲存和在表中的值遞增,當DB2有[序列](http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/topic/com.ibm.db2.luw.admin.dbobj.doc/doc/c0023175.html),這將避免所有的併發問題? – bhamby 2012-08-07 03:52:02
@bhamby,感謝您的評論,我們發現訪問EF序列的唯一方法是調用存儲過程,到目前爲止我們已經避免使用存儲過程,但是如果沒有其他解決方案,我們可能不得不使用存儲過程。 – 2012-08-07 08:24:59
這個整體解決方案對於製造瓶頸已經成熟。最有可能的是,有些東西被包含在事務處理範圍中,這導致它需要更長的時間(儘管取決於具體情況,1秒並不是那麼糟糕)。不管怎麼說,我會和序列一起去,因爲@ bhamby建議,只是因爲它是一個更清晰的意圖聲明。 – 2012-08-07 16:02:59