分享大師的blog，并且把主要內(nèi)容寫出來，不敢翻譯，以備看了之后忘記可以溫習(xí)，也推廣一下大師的博客
Importance of choosing the right LOB storage technique
本文大意：
? ? N/CHAR：當(dāng)數(shù)據(jù)長度都是固定的比較好用，并且可以用來限制列的大小，避免太長而分頁導(dǎo)致碎片生產(chǎn)，缺點應(yīng)用程序比較難辨認(rèn)，如果數(shù)據(jù)長度比列定義的小，那么就可能會造成磁盤空間浪費，io量變大，內(nèi)存空間浪費
? ? ?N/VARCHAR (1-8000)：對于varchar小于8000個字節(jié)，那么已經(jīng)避免了浪費空間的缺點，但是如果大小變化會造成分頁導(dǎo)致碎片，在sql server2005以后，一個表的列字節(jié)和可以超過8060個字節(jié)，超過的部分會被保存溢出頁中，那么當(dāng)讀取這個數(shù)據(jù)的時候，就會多一次io，也會導(dǎo)致判斷是在數(shù)據(jù)頁中還是在溢出頁中造成困難，若這個數(shù)據(jù)比較大，將近8000個字節(jié)，那么一個頁中只能保存很少的頁，如果這個數(shù)據(jù)不太常用，那么就不太高效了。
? ? ?N/VARCHAR (MAX) column in-row：這個類型基本和上面的差不多，多了一個好處就是可以超過8000個字節(jié)，當(dāng)大于8000個字節(jié)后自動保存在溢出頁，訪問它需要額外的io，和FILESTREAM比這個字節(jié)上限為2GB，如果表中有LOB數(shù)據(jù)列，那么聚集索引重建不能再online模式下。
? ? ?N/VARCHAR (MAX) column out-of-row：這個類型的缺點是訪問需要額外的io，當(dāng)對這一列排序是就會出現(xiàn)大量io。如果不是很常用放在溢出頁是比較好的選擇，但是任然有24字節(jié)大小的指針，還有一個好處是通過TEXTIMAGE_ON可以把溢出頁放到另外一個文件組中，這樣2邊的io就可以做到不影響。
? ? ? N/TEXT column in-row：已經(jīng)被放棄使用，效果和 N/VARCHAR (MAX)非溢出頁一樣
? ? ? N/TEXT column out-of-row：已經(jīng)放棄使用和上面一樣
? ? ?使用分開的表，需要的時候使用join獲取：這個方法對于不太使用到的很有好處，但是需要更多的前端設(shè)計和復(fù)雜的sql，另外一個好處是主表可以使用online索引創(chuàng)建
? ? ?FILESTREAM column：這個類型當(dāng)列數(shù)據(jù)超過1mb時使用FILESTREAM，從文件系統(tǒng)中獲取數(shù)據(jù)比從buffer pool中獲取要快，詳細(xì)可以看
白皮書
本文大意：
? ? ?ghost記錄清理進程是后臺運行的，主要是清理在聚集表下，記錄被刪除后形成的ghost記錄。當(dāng)在聚集索引下刪除記錄，并沒有真正的刪除只是標(biāo)記為ghost記錄，這樣刪除會變得更快，回滾只需要撤銷標(biāo)記。當(dāng)事務(wù)提交后后臺有g(shù)host清理程序來清理這些被標(biāo)記為ghost記錄。并且會保留最后一個數(shù)據(jù)頁的最有一條ghost記錄以免頁沒釋放。當(dāng)記錄被刪除會在pfs上標(biāo)記ghost，在數(shù)據(jù)頁頭上也會標(biāo)記。但是pfs上的標(biāo)記并不會通知處理程序處理。只有到下一次掃描到這個頁時才會處理，或者等到每5秒一次的清理進程激活，清理進程就會掃描pfs頁，并對ghost頁處理。若沒有需要清理的了就跳入下一個數(shù)據(jù)庫。若這次掃描沒有發(fā)現(xiàn)有g(shù)host記錄，那么會設(shè)置上一個標(biāo)記，下5秒喚醒就跳過這個數(shù)據(jù)庫。
本文大意：
? ? ?作者使用一個例子說明當(dāng)啟動快照隔離級別是heap表的刪除或產(chǎn)生ghost記錄。當(dāng)刪除heap中的記錄，這條記錄會被標(biāo)記為ghost并且長度變?yōu)?4個字節(jié)（6（xsn）+8（tempdb中文件，頁，行的實際指針））。之后很快就會被當(dāng)成ghost數(shù)據(jù)清理（稍微詳細(xì)的也可以看sql server 技術(shù)內(nèi)幕系列）
本文大意：
? ? ?（sql server 2008中g(shù)host清理工具沒10秒執(zhí)行）可以使用tf661來關(guān)閉ghost清理工具的運行，這樣會減少因為清理需要把頁保存在buffer pool，生產(chǎn)日志，造成物理io。如果對于delete量比較大的數(shù)據(jù)庫可以啟用tf661，這樣ghost頁就不會被清理。
本文大意：
? ? ?指出了sql server2008 internals 里面的關(guān)于in-place update的錯誤，但是我沒找到，里面指出對于索引key的修改不會有使用 in-place update 應(yīng)該是 out-place update。作者做了一個測試說明對key修改不會發(fā)生in-place update，而是使用out-place update（也就是先delete 再insert）。當(dāng)對一個慢的頁進行out-place update時，會發(fā)生分頁現(xiàn)象。從事務(wù)日志的角度分析全過程：
? ? ?0.把更新的記錄設(shè)置為ghost
? ? ?1.分配一個新頁a(將作為root頁或索引頁) a，修改IAM頁。
? ? ?2.格式化這個頁（也就是格式化96位的頭等等）
? ? ?3.把原數(shù)據(jù)頁的索引插入到頁a中
? ? ?4.把也a設(shè)置為root頁或者索引頁
? ? ?5.分配一個新頁b（講作為葉子節(jié)點）
? ? ?6.講第二行移動到頁b中
? ? ?7.把修改的記錄插入到頁b中
作者說隨后就會把原先頁中的ghost清理，但是我的測試中始終都沒有被清理
本文大意：
? ? ?有2個方法可以跟蹤每個列的被修改次數(shù)sys.sysrccol需要使用DAC才能訪問到這個元數(shù)據(jù)表。還有一個是sys.system_internals_partition_columns不需要使用DAC但是是非歸檔的視圖。有流傳可以使用sysindex中的rowmodctr顯然是不行的這個在統(tǒng)計信息更新的時候會被清空掉。
本文大意：
? ? ?很多dba都會備份系統(tǒng)數(shù)據(jù)庫并且在另外一個服務(wù)器上面還原來檢查備份的正確性，并使用dbcc checkdb進行檢查。當(dāng)master數(shù)據(jù)庫被還原并使用dbcc checkdb 檢查時會出現(xiàn)1:10 的一致性錯誤，因為1:10 保存的是config塊是master特有的，報錯的原因是這個頁被分配但是找不到所屬的單元。里面存放了sp_configure的內(nèi)容。在sql server 啟動時會讀入這個頁的內(nèi)容，如果讀不到就會報錯。
New script: When were the sp_configure options last changed?
本文大意：
? ? ?作者分享了關(guān)于獲取最后一次修改sp_configure的時間。使用dbcc config 可以看到sp_configure cfgupddate，cfgupdtime更新日期和更新時間。其中cfgupddate是從1900.1.1到最后一次更新日期的偏移。cfgupdtime中的單位是3.3ms。只有當(dāng)服務(wù)重啟，或者有重大改變（不太清楚什么樣的改變是重大改變）時才會修改config塊。
本文大意：
? ? ?sql server 2012 開始fn_dblog就帶上父事務(wù)的id，好處是可以直接看fn_dblog就可以知道sql server內(nèi)部做了什么操作兒不是靠猜測。本文最后，出現(xiàn)一條事務(wù)id是0000:00000000的記錄，主要操作是吧在pfs設(shè)置為頁空不是事務(wù)的一部分，也不可能讓事務(wù)來維護這個設(shè)置，如果讓事務(wù)維護必將照成堵塞。
本文大意:
? ? ?create/alter index指定了maxdop的時候，如果是非分區(qū)表上DOP =?MIN(64, CPUs)在分區(qū)表上dop=MIN(Partitions, MIN(64, CPUS))
更多文章、技術(shù)交流、商務(wù)合作、聯(lián)系博主
微信掃碼或搜索：z360901061
微信掃一掃加我為好友
QQ號聯(lián)系： 360901061
您的支持是博主寫作最大的動力，如果您喜歡我的文章，感覺我的文章對您有幫助，請用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧，狠狠點擊下面給點支持吧，站長非常感激您！手機微信長按不能支付解決辦法：請將微信支付二維碼保存到相冊，切換到微信，然后點擊微信右上角掃一掃功能，選擇支付二維碼完成支付。
【本文對您有幫助就好】元
