SQL Server內(nèi)存的一個(gè)重要部分已經(jīng)分開了，這樣一來就造成了性能退化。持續(xù)時(shí)間：%n秒、工作組(KB)：%w、committed (KB):：%c、內(nèi)存利用：%u。
SQL Server遇到了%o IO請(qǐng)求事件用15秒以上的時(shí)間在數(shù)據(jù)庫[%d] (%i)里的[%f]文件上完成。OS文件處理為%h。偏移的最新IO 長度為: %l.。
但是這并不是這些錯(cuò)誤被報(bào)告的唯一的一次，所以你需要和性能監(jiān)控器metric一起使用來測(cè)定內(nèi)存是否真的太低。
在處理SQL Server內(nèi)存問題方面也有一些解決辦法，最簡(jiǎn)單的就是解決辦法就是擴(kuò)大服務(wù)器內(nèi)存增加可使用的buffer cache的數(shù)量。這樣做就增加了內(nèi)存數(shù)據(jù)量、減少了你的disk I/O。其他的解決辦法包括遷移大空間表的集群式索引以及只使用這些表的非集群式的索引，包括Primary Key。
在集群式索引用于查找并且使用了集群式的index seeks時(shí)就不同了。如果使用了另一個(gè)索引，它就不可能減輕任何內(nèi)存壓力，因?yàn)榧菏降乃饕]有在內(nèi)存里。如果使用了集群式的index scans，那么在不遷移索引的情況下一個(gè)新的非集群式的索引可能會(huì)有用。
如何監(jiān)控CPU對(duì)列（CPU queuing）
CPU是硬件的另一個(gè)部分，它能夠?qū)е聺撛诘男阅軉栴}。大多數(shù)人只看CPU的速度或數(shù)量。然而就如同磁盤一樣，CPU能夠成為瓶頸。如果出現(xiàn)了CPU瓶頸，你可能100%不會(huì)去查看CPU的性能。CPU擁有命令對(duì)列的方式就如同I/O對(duì)列一樣。命令被下載到CPU隊(duì)列中，并且執(zhí)行之前的操作程序等待CPU變得可以使用。由于CPU的速度變得更快了，我們?cè)贑PU里面做任何事情的速度也就加快了，但是我們一次也只能做同樣多的事情。現(xiàn)在我們可以使用雙核、三核、四核以及多核的CPU。這樣我們一次能夠執(zhí)行更多的命令。
你可以利用SQL Server性能監(jiān)控器監(jiān)控你的CPU。你會(huì)在System目標(biāo)下面發(fā)現(xiàn)PerfMon，它有一個(gè)計(jì)算器的名字“處理機(jī)隊(duì)列長度”。幾乎任何其他大于零的隊(duì)列長度都表明你需要增加一些操作程序，這些操作程序是SQL Server都能同時(shí)執(zhí)行的。但是這并不表明需要一個(gè)更快的CPU，而是需要一個(gè)更多核的CPU。今天最新的服務(wù)器每臺(tái)服務(wù)器都支持32核，一些高級(jí)的服務(wù)器支持64核（當(dāng)chase按比例范圍共同支持64核時(shí)）也可以創(chuàng)建（僅僅是某些廠商）。
在第一部分和第二部分里，我已經(jīng)指出了硬件里的一些地方。這些技巧不是解決性能問題最全面的、最終的解決方案。表的設(shè)計(jì)和索引的調(diào)整經(jīng)常是并且長期是非常重要的。今天的SQL Server有望在更長的時(shí)間內(nèi)做更多的事情，這樣才能使硬件調(diào)整對(duì)數(shù)據(jù)庫平臺(tái)更加重要。用arsenal里的一些工具解決性能問題，這樣你就能從還未或已經(jīng)行最小限度升級(jí)的現(xiàn)存的每項(xiàng)硬件性能。但是當(dāng)你的確需要購買時(shí)，這些技巧有助于你作出正確的決策，做到物有所值。
更多文章、技術(shù)交流、商務(wù)合作、聯(lián)系博主
微信掃碼或搜索：z360901061
微信掃一掃加我為好友
QQ號(hào)聯(lián)系： 360901061
您的支持是博主寫作最大的動(dòng)力，如果您喜歡我的文章，感覺我的文章對(duì)您有幫助，請(qǐng)用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧，狠狠點(diǎn)擊下面給點(diǎn)支持吧，站長非常感激您！手機(jī)微信長按不能支付解決辦法：請(qǐng)將微信支付二維碼保存到相冊(cè)，切換到微信，然后點(diǎn)擊微信右上角掃一掃功能，選擇支付二維碼完成支付。
【本文對(duì)您有幫助就好】元
