Why does the buffer pool contain so many dirty tempdb pages?
?
本文大意：
? ? ? ? ? 對于tempdb來說，還原模式為簡單模式也只能是簡單模式，不需要從故障中恢復(fù)，tempdb只會(huì)重建，所以tempdb沒有必要做恢復(fù)，不需要自動(dòng)checkpoint。?所以說在一個(gè)比較繁忙的實(shí)例中，用戶數(shù)據(jù)庫的checkpoint比tempdb頻繁，所以在tempdb中會(huì)有比較多的臟數(shù)據(jù)。
?
結(jié)論：
? ? ? ? ? 自動(dòng)觸發(fā)的checkpoint不會(huì)對tempdb影響臟數(shù)據(jù)沒有寫入，所以臟數(shù)據(jù)比較多。
?本文大意：
? ??
?dbcc checkdb錯(cuò)誤離奇消失
：主要可能存在的問題是當(dāng)索引重建時(shí)在checkdb，導(dǎo)致一致性問題。
? ? ?
從2000升級到2008 tempdb上可能會(huì)遇到什么問題
：有一下4點(diǎn)會(huì)產(chǎn)生比較打的行版本信息：
? ? ? ? ? 1.在線索引重建
? ? ? ? ? 2.DML觸發(fā)器
? ? ? ? ? 3.MARS
? ? ? ? ? 4.快照隔離界別
? ? ?
填充因子是否可以減少分頁，并可以實(shí)例級別的設(shè)置
：填充因子確實(shí)可以減少分頁，填充因子就是在頁上保留了一定比例的空閑空間，以便于插入數(shù)據(jù)或者行記錄擴(kuò)展，以減少分頁的發(fā)生。對于OLTP沒有一個(gè)很好的答案，每個(gè)表可能因?yàn)樨?fù)載的不同需要不同的填充因子。對于OLAP可以使用100%以提高IO效率。
? ? ?
FILESTREAM的性能問題
：1.FILESTREAM是保存在windows的ntfs文件，因此調(diào)整ntfs簇大小（分配單元）很重要
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?2.確定文件的大小研究表明小于256KB，是放在sql server 中比較好。256kb-1mb性能差不多
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?3.FILESTREAM數(shù)據(jù)不能給修改只能被覆蓋重寫。
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?4.FILESTREAM不能和數(shù)據(jù)庫鏡像兼容（sql server 2008）
本文大意：
? ? ?1.TF 1118標(biāo)記打開之后原本是從SGAM分配前8個(gè)頁的，代替為直接分配一個(gè)專用區(qū)。這樣的好處就是減少了SGAM的沖突。
? ? ?2.專區(qū)分配給了一個(gè)表并不是把8個(gè)頁都分配給了這個(gè)表，只是這個(gè)分區(qū)為這個(gè)表保留，不能用與其他表。
? ? ?3.在sql server 2005之后分配系統(tǒng)被優(yōu)化，當(dāng)創(chuàng)建用戶對象時(shí)，先和以前一樣創(chuàng)建一個(gè)IAM頁，插入數(shù)據(jù)時(shí)分配數(shù)據(jù)頁。單刪除對象是并不是釋放掉，而是緩存起來以便下次使用。
? ? ?4.TF1118在sql server2005后的版本中還存在是為了提供方法減輕SGAM的使用，也可以使用多個(gè)文件的方式緩解沖突，SQLPASS2011上有人建議若內(nèi)核數(shù)量少于8個(gè)使用8個(gè)文件，若有8個(gè)以上內(nèi)核，先嘗試使用8個(gè)文件，若還是有沖突再加4個(gè)文件
? ? ?5.使用了標(biāo)記后dbcc ind還是返回2頁，但是來自專區(qū)不是混合區(qū)
本文大意
：
? ? ?在log文件到達(dá)70%時(shí)，和recovery interval時(shí)限到是會(huì)做checkpoint，但是在tempdb中只有l(wèi)og文件超過70%才會(huì)checkpoint，阻止了log文件可能的增長，因?yàn)樵趖empdb中簡單恢復(fù)模式會(huì)截?cái)嗳罩尽Ｗ詣?dòng)checkpoint在tempdb不會(huì)像所有用戶數(shù)據(jù)庫會(huì)寫入所有的臟數(shù)據(jù)，當(dāng)手動(dòng)運(yùn)行時(shí)也會(huì)寫入臟數(shù)據(jù)
本文大意
：
? ? ?當(dāng)使用動(dòng)態(tài)游標(biāo)打開時(shí)，會(huì)位結(jié)果集中的每行生成一個(gè)checksum，當(dāng)讀取下一行時(shí)會(huì)去基表中查詢記錄，因此就會(huì)在執(zhí)行計(jì)劃中有個(gè)key lookups操作
本文大意
：
? ? ?有時(shí)候會(huì)出現(xiàn)tempdb中日志文件和數(shù)據(jù)文件的巨大差異。在用戶數(shù)數(shù)據(jù)庫中是不可能出現(xiàn)的。這個(gè)是因?yàn)閠empdb只記錄undo日志，不會(huì)生成redo日志，減少的日志的寫入量。從而導(dǎo)致日志文件和數(shù)據(jù)文件的巨大差異。作者使用了一個(gè)證明這個(gè)問題。在tempdb中使用2612B的日志空間記錄了256kb的排序，并假設(shè)如果是90G的內(nèi)容需要排序。在tempdb中只會(huì)生成90G/256K=368640,368640*2612B=~918M的日志。
本文大意
：
? ? ?dbcc checkdb會(huì)先生成叫做facts的東西并保存在很大的worktable中，dbcc checkdb使用按分配的順序讀取用戶數(shù)據(jù)文件來生成fact（最快的方式）。讀取任務(wù)是分散到很多線程進(jìn)行的，所以dbcc checkdb很消耗io的原因。fact生成好之后查詢處理器吧結(jié)果返回給dbcc checkdb讓它去匹配，若某個(gè)fact匹配不到相關(guān)信息，那么可能就會(huì)報(bào)一致性錯(cuò)誤。
? ? ?現(xiàn)在能用WITH ESTIMATEONLY評估dbcc checkdb在tempdb中的空間使用。dbcc checkdb并不是一次性檢查整個(gè)數(shù)據(jù)庫（除非有tf 2562），檢查是分批次的。使用2個(gè)條件來劃分，1：出現(xiàn)512個(gè)或者更多的索引。2：這批的大小超過了32MB。fact的大小評估如下，1：分區(qū)上的所有頁*2,2：聚集索引中hobt頁數(shù)*3,3：表中LOB列數(shù)*2,4：若為heap，表行數(shù)*2,5：最大行大小*hobt頁數(shù)。WITH ESTIMATEONLY輸出其中最大的一個(gè)。
Are I/O latencies killing your performance?
本文大意：
? ? ?到底什么樣的延遲好，或者不好，可能每個(gè)人心中都有一個(gè)標(biāo)準(zhǔn)：
- Excellent: < 1ms
- Very good: < 5ms
- Good: 5 – 10ms
- Poor: 10 – 20ms
- Bad: 20 – 100ms
- Shockingly bad: 100 – 500ms
- WOW!: > 500ms
? ? ?關(guān)鍵點(diǎn)是，是否到達(dá)了可以接受的邊界，先不要管延遲，要先注意，性能是否在可以接受的范圍內(nèi)。
? ? ?
? ? ?tempdb文件：如果真的不可以接受那么又以下4個(gè)方面：
? ? ? ? ? 1.增加一個(gè)比較快速的io子系統(tǒng)
? ? ? ? ? 2.查看tempdb所在的位置，如，a.網(wǎng)絡(luò)或者路徑問題，b.不正確的SAN設(shè)置，c.多用戶共享，d.是否使用多個(gè)tempdb文件來增加性能
? ? ? ? ? 3.減少tempdb的使用，a.plan中的hash，sort，exchange，b.減少不必要的數(shù)據(jù)放入的臨時(shí)表中，c.索引重建中SORT_IN_TEMPDB,d.快照隔離級別
? ? ? ? ? 4.綜合2,3,然后再增加快速io子系統(tǒng)
? ? ?
?????tempdb log 文件:log文件的寫入延遲，會(huì)影響日志提交，進(jìn)而產(chǎn)生吞吐量的問題，對于log文件的讀取，一般不會(huì)影響吞吐量，但是會(huì)影響log reader
同時(shí)作者推薦了3篇文章:
- Trimming the Transaction Log Fat ?- common problems that lead to poor transaction log performance.
- Trimming More Transaction Log Fat ?- more subtle problems that contribute to poor transaction log performance.
- Transaction Log Configuration Issues ?– self-explanatory.
更多文章、技術(shù)交流、商務(wù)合作、聯(lián)系博主
微信掃碼或搜索：z360901061
微信掃一掃加我為好友
QQ號聯(lián)系： 360901061
您的支持是博主寫作最大的動(dòng)力，如果您喜歡我的文章，感覺我的文章對您有幫助，請用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧，狠狠點(diǎn)擊下面給點(diǎn)支持吧，站長非常感激您！手機(jī)微信長按不能支付解決辦法：請將微信支付二維碼保存到相冊，切換到微信，然后點(diǎn)擊微信右上角掃一掃功能，選擇支付二維碼完成支付。
【本文對您有幫助就好】元
