大數(shù)據(jù)量下的SQL Server數(shù)據(jù)庫自身優(yōu)化
博客園 發(fā)表于:13年01月22日 00:44 [轉(zhuǎn)載] 51CTO
優(yōu)化③:分布式數(shù)據(jù)庫設計
分布式數(shù)據(jù)庫系統(tǒng)是在集中式數(shù)據(jù)庫系統(tǒng)的基礎上發(fā)展起來的,理解起來也很簡單,就是將整體的數(shù)據(jù)庫分開,分布到各個地方,就其本質(zhì)而言,分布式數(shù)據(jù)庫系統(tǒng)分為兩種:1.數(shù)據(jù)在邏輯上是統(tǒng)一的,而在物理上卻是分散的,一個分布式數(shù)據(jù)庫在邏輯上是一個統(tǒng)一的整體,在物理上則是分別存儲在不同的物理節(jié)點上,我們通常說的分布式數(shù)據(jù)庫都是這種2.邏輯是分布的,物理上也是分布的,這種也成聯(lián)邦式分布數(shù)據(jù)庫,由于組成聯(lián)邦的各個子數(shù)據(jù)庫系統(tǒng)是相對“自治” 的,這種系統(tǒng)可以容納多種不同用途的、差異較大的數(shù)據(jù)庫,比較適宜于大范圍內(nèi)數(shù)據(jù)庫的集成。
分布式數(shù)據(jù)庫較為復雜,在此不作詳細的使用和說明,只是舉例說明一下,現(xiàn)在分布式數(shù)據(jù)庫多用于用戶分區(qū)性較強的系統(tǒng)中,如果一個全國連鎖店,一般設計為每個分店都有自己的銷售和庫存等信息,總部則需要有員工,供應商,分店信息等數(shù)據(jù)庫,這類型的分店數(shù)據(jù)庫可以完全一致,很多系統(tǒng)也可能導致不一致,這樣,各個連鎖店數(shù)據(jù)存儲在本地,從而提高了影響速度,降低了通信費用,而且數(shù)據(jù)分布在不同場地,且存有多個副本,即使個別場地發(fā)生故障,不致引起整個系統(tǒng)的癱瘓。 但是他也帶來很多問題,如:數(shù)據(jù)一致性問題、數(shù)據(jù)遠程傳遞的實現(xiàn)、通信開銷的降低等,這使得分布式數(shù)據(jù)庫系統(tǒng)的開發(fā)變得較為復雜,只是讓大家明白其原理,具體的使用方式就不做詳細的介紹了。
優(yōu)化④:整理數(shù)據(jù)庫碎片
如果你的表已經(jīng)創(chuàng)建好了索引,但性能卻仍然不好,那很可能是產(chǎn)生了索引碎片,你需要進行索引碎片整理。
什么是索引碎片?
由于表上有過度地插入、修改和刪除操作,索引頁被分成多塊就形成了索引碎片,如果索引碎片嚴重,那掃描索引的時間就會變長,甚至導致索引不可用,因此數(shù)據(jù)檢索操作就慢下來了。
如何知道是否發(fā)生了索引碎片?
在SQLServer數(shù)據(jù)庫,通過DBCC ShowContig或DBCC ShowContig(表名)檢查索引碎片情況,指導我們對其進行定時重建整理。
通過對掃描密度(過低),掃描碎片(過高)的結(jié)果分析,判定是否需要索引重建,主要看如下兩個:
Scan Density [Best Count:Actual Count]-掃描密度[最佳值:實際值]:DBCC SHOWCONTIG返回最有用的一個百分比。這是擴展盤區(qū)的最佳值和實際值的比率。該百分比應該盡可能靠近100%。低了則說明有外部碎片。
Logical Scan Fragmentation-邏輯掃描碎片:無序頁的百分比。該百分比應該在0%到10%之間,高了則說明有外部碎片。
解決方式:
一是利用DBCC INDEXDEFRAG整理索引碎片
二是利用DBCC DBREINDEX重建索引。
兩者區(qū)別調(diào)用微軟的原話如下:
DBCC INDEXDEFRAG 命令是聯(lián)機操作,所以索引只有在該命令正在運行時才可用,而且可以在不丟失已完成工作的情況下中斷該操作。這種方法的缺點是在重新組織數(shù)據(jù)方面沒有聚集索引的除去/重新創(chuàng)建操作有效。
重新創(chuàng)建聚集索引將對數(shù)據(jù)進行重新組織,其結(jié)果是使數(shù)據(jù)頁填滿。填滿程度可以使用 FILLFACTOR 選項進行配置。這種方法的缺點是索引在除去/重新創(chuàng)建周期內(nèi)為脫機狀態(tài),并且操作屬原子級。如果中斷索引創(chuàng)建,則不會重新創(chuàng)建該索引。也就是說,要想獲得好的效果,還是得用重建索引,所以決定重建索引。