tempdb相關文章

 本文大意：

          對于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輸出其中最大的一個。

     到底什麼樣的延遲好，或者不好，可能每個人心中都有一個标準：

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篇文章: