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