對於tempdb來說，還原模式為簡單模式也只能是簡單模式，不需要從故障中恢復，tempdb只會重建，所以tempdb沒有必要做恢復，不需要自動checkpoint。 所以說在乙個比較繁忙的例項中，使用者資料庫的checkpoint比tempdb頻繁，所以在tempdb中會有比較多的髒資料。
結論：
自動觸發的checkpoint不會對tempdb影響髒資料沒有寫入，所以髒資料比較多。
dbcc checkdb錯誤離奇消失：主要可能存在的問題是當索引重建時在checkdb，導致一致性問題。
從2000公升級到2008 tempdb上可能會遇到什麼問題：有一下4點會產生比較打的行版本資訊：
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輸出其中最大的乙個。
到底什麼樣的延遲好，或者不好，可能每個人心中都有乙個標準：
關鍵點是，是否到達了可以接受的邊界，先不要管延遲，要先注意，效能是否在可以接受的範圍內。
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
WinRar相關文章
類別 伺服器 軟體 瀏覽 1186 2007 4 3 10 37 00 rem 解釋 rar檔案 壓縮 包括子資料夾 採用儲存壓縮模式 排除 bak檔案 排除 rar檔案 對所有的回答選擇是 到yyy.rar裡 滿足什麼條件 多個條件用空格隔開 還有乙個比較xx的例子 把在肉機上所有聊天記錄打包 c...
wifidog openwrt相關文章
1,2,openwrt下實現portal認證 web認證 3,wiki 4,openwrt使用wifidog實現強制認證的wifi熱點 5,wifidog english 6,hotspot builder utility安裝指南 7,openwrt wifidog wiwiz 安裝 8,openw...
程式設計相關文章
2016 6 libevent學習 fast portable non blocking network programming with libevent libevent原始碼分析 the way to go go入門指南 nginx開發從入門到精通 nginx模組開發入門 redis原始碼分析...