共計 1807 個字符，預計需要花費 5 分鐘才能閱讀完成。
這期內容當中丸趣 TV 小編將會給大家帶來有關 IIS 日志導入 SQLSERVER 的實例分析，文章內容豐富且以專業的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。
一直使用 URCHIN 分析日志，這款 google 的日志分析工具無論從功能或效率都沒的說。
但還是有些特殊的分析需求還是不能完成。因此決定把日志導入到 SQLSERVER 中進行分析
開始想象的比較簡單。嵌套一個循環基本可以完成
一個大循環讀取某文件夾下的所有日志文件
里邊的小循環逐行讀取日志，里邊 split 開來，插入 sql 即可。
根據數據表建立 tableadapter ，使用 insert 存儲過程逐條插入數據。
第一個問題來了，發現一個日志文件大約 200W 行需要執行 3 個小時！！！
效率太低了，開始考慮開啟多線程，后來發現執行效率應該和線程無關，主要在 tableadapter 的插入操作上。
這個插入方法實際上是每次執行連接 - 插入 - 斷開操作。
解決方法是使用內存，少進行 IO 操作。
先建立一個 datatable。使用 tableadapter 中的強類型對象初始化這個 datatable。
然后將數據讀入 datatable.
最后使用.net 對象中的 sqkbulkcopy 填充數據庫。
這樣數據填充的速度問題解決了。幾乎 200W 的數據在 5 分鐘之內可以導完。
但實際調試中，第二個問題來了。（一直也沒弄明白）
我使用的服務器是 2003 64 位系統內存 16G。
一個數據文件大概 500M，每次填充 datatable 的時候，一個文件沒導完就會報 outofmemory 的錯誤，內存溢出了！！
很奇怪，按說 64 位的系統應該可以管理很多內存，不存在 32 為的 AWE 的問題。
于是繼續嘗試在循環內建立小循環，每次導入 datatable 100W 條數據。
導入第一批 100W 成功了，可循環到第二個 100W 的時候還是同樣的錯誤。
看代碼，每次導入完成之后，我使用 table.dispose() 清理，可觀察資源管理器，內存并沒有釋放掉。
于是使用 table.rows.clear()
或者使用 table.clear()??
+ GC.collect()
這樣基本可以解決內存無法釋放的問題，但在實際使用中還是發現內存一直在漲，因為 sqlbulkcopy 時候 sqlserver 也會占用很多內存。
少量日志導入應該不會有問題，但不知道連續導入時會出現什么樣的情況
主要代碼
Private Sub readLogfile(ByVal log As FileInfo)
Dim reader As StreamReader = New StreamReader(log.FullName)
While Not reader.EndOfStream
For j As Int32 = 0 To 1000000
If Not reader.EndOfStream Then
handleLine(reader.ReadLine())
i += 1
Console.WriteLine(j)
Else
Exit While
End If
Next
bulkcopy(table1)
table1.Rows.Clear()
table1.Clear()
GC.Collect()
Console.WriteLine(——————————————— i)
End While
Private Sub bulkcopy(ByVal newtable As DataTable)
Using sqlbulk As SqlBulkCopy = New SqlBulkCopy(Configuration.ConfigurationManager.ConnectionStrings( logAnalysis.My.MySettings.logDBConnectionString).ConnectionString)
sqlbulk.DestinationTableName = logDB .dbo.Table_1
sqlbulk.BulkCopyTimeout = 108000
sqlbulk.WriteToServer(newtable)
sqlbulk.Close()
End Using
End Sub
上述就是丸趣 TV 小編為大家分享的 IIS 日志導入 SQLSERVER 的實例分析了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關知識，歡迎關注丸趣 TV 行業資訊頻道。
