如何進(jìn)行數(shù)據(jù)庫性能事件的技術(shù)總結(jié)

這篇文章將為大家詳細(xì)講解有關(guān)如何進(jìn)行數(shù)據(jù)庫性能事件的技術(shù)總結(jié)，文章內(nèi)容質(zhì)量較高，因此小編分享給大家做個參考，希望大家閱讀完這篇文章后對相關(guān)知識有一定的了解。

1. 使用select * from sys.sysprocesses where spid > 50 and kpid <> 0查看當(dāng)前有多少正在有對應(yīng)線程的連接。在SQL Server中SPID大于50的連接表示用戶連接，同時kpid表示對應(yīng)的線程ID。當(dāng)對應(yīng)的連接需要有操作運(yùn)行時，SQL Server會給它分配一個線程供給CPU調(diào)度。發(fā)現(xiàn)系統(tǒng)中當(dāng)前已有分配線程的連接很少，說明當(dāng)前系統(tǒng)比較空閑。

2. 使用select sum(open_tran) from sys.sysprocesses where spid > 50查看當(dāng)前  
系統(tǒng)中有多少的活動事務(wù)。當(dāng)前系統(tǒng)中的活動事務(wù)只有50上下，并沒有SQC報告的那么高。

3. 使用select * from sys.sysprocesses where spid > 50 and blocked <> 0查看當(dāng)前系統(tǒng)中有沒有阻塞。在SQL Server中，如果系統(tǒng)發(fā)生阻塞blocked列會填入阻塞其他連接的SPID。在當(dāng)前的環(huán)境中，沒有發(fā)現(xiàn)阻塞。

4. 在收集的PSSDIAG中，并沒有發(fā)生任何的阻塞，系統(tǒng)整體上沒有任何的性能相關(guān)瓶頸。

5. 在PSSDIAG提供的信息中，我們沒有發(fā)現(xiàn)SQL Server有影響到我們應(yīng)用程序的阻塞  
(BLOCK)，并且在PSSDIAG中經(jīng)過統(tǒng)計，其中我們關(guān)注的UPDATE語句（排名第二），在10分鐘抓取信息的過程中共執(zhí)行了133565次，平均每條用時0.000807S。我們關(guān)注的SELECT語句（排名第四）共執(zhí)行了133592次，平均每條執(zhí)行時間0.000193S。另外一條INSERT語句未能排名前十。

6. 整體上來說，SQL Server中沒有明顯的性能瓶頸。所有相關(guān)的語句執(zhí)行速度都很  
快。如果抓取PSSDIAG時問題正在發(fā)生，從PSSDIAG看性能的問題應(yīng)該不在SQL Server端。

關(guān)于如何進(jìn)行數(shù)據(jù)庫性能事件的技術(shù)總結(jié)就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，可以學(xué)到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。