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