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ī)微信長按不能支付解決辦法:請將微信支付二維碼保存到相冊,切換到微信,然后點擊微信右上角掃一掃功能,選擇支付二維碼完成支付。
【本文對您有幫助就好】元
