自拍偷在线精品自拍偷,亚洲欧美中文日韩v在线观看不卡

SQL Server性能的提高,可通過DBCC DBREINDEX重建索引

數(shù)據(jù)庫 SQL Server
我們今天主要向大家描述的是DBCC DBREINDEX重建索引對SQL Server性能進(jìn)行提高的實(shí)際操作步驟,以及對索引類型的描述。

以下的文章主要介紹的是DBCC DBREINDEX重建索引對SQL Server性能進(jìn)行提高的實(shí)際操作步驟,大多數(shù)SQL Server數(shù)據(jù)庫表需要索引來對數(shù)據(jù)的實(shí)際訪問速度進(jìn)行提高,如果沒有索引,SQL Server要進(jìn)行表格掃描讀取表中的每一個(gè)記錄才能找到索要的數(shù)據(jù)。

索引可以分為簇索引和非簇索

 

引,簇索引通過重排表中的數(shù)據(jù)來提高數(shù)據(jù)的訪問速度,而非簇索引提高SQL Server性能則通過維護(hù)表中的數(shù)據(jù)

 

指針來提高數(shù)據(jù)的索引。

 

1. 索引的體系結(jié)構(gòu)

為什么要不斷的維護(hù)表的索引?首先,簡單介紹一下索引的體系結(jié)構(gòu)。SQL

 

Server在硬盤中用8KB頁面在數(shù)據(jù)庫文件內(nèi)存放數(shù)據(jù)。缺省情況下這些頁面及其包含的數(shù)據(jù)

 

是無組織的。為了使混亂變?yōu)橛行颍鸵伤饕?。生成索引后,就有了索引頁和?shù)據(jù)頁,

 

數(shù)據(jù)頁保存用戶寫入的數(shù)據(jù)信息。索引頁存放用于檢索列的數(shù)據(jù)值清單(關(guān)鍵字)和索引表

 

中該值所在紀(jì)錄的地址指針。索引分為簇索引和非簇索引,簇索引實(shí)質(zhì)上是將表中的數(shù)據(jù)排

 

序,就好像是字典的索引目錄。非簇索引不對數(shù)據(jù)排序,它只保存了數(shù)據(jù)的指針地址。向一

 

個(gè)帶簇索引提高SQL Server性能的表中插入數(shù)據(jù),當(dāng)數(shù)據(jù)頁達(dá)到100%時(shí),由于頁面沒有空間插入新的的紀(jì)錄,這

 

時(shí)就會(huì)發(fā)生分頁,SQL Server

 

將大約一半的數(shù)據(jù)從滿頁中移到空頁中,從而生成兩個(gè)半的滿頁。這樣就有大量的數(shù)據(jù)空間

 

。簇索引是雙向鏈表,在每一頁的頭部保存了前一頁、后一頁地址以及分頁后數(shù)據(jù)移動(dòng)的地

 

址,由于新頁可能在數(shù)據(jù)庫文件中的任何地方,因此頁面的鏈接不一定指向磁盤的下一個(gè)物

 

理頁,鏈接可能指向了另一個(gè)區(qū)域,這就形成了分塊,從而減慢了系統(tǒng)的速度。對于帶簇索

 

引和非簇索引的表來說,非簇索引的關(guān)鍵字是指向簇索引的,而不是指向數(shù)據(jù)頁的本身。

 

為了克服數(shù)據(jù)分塊帶來的負(fù)面影響,需要重構(gòu)表的索引,這是非常費(fèi)時(shí)的,因此只能在需要

時(shí)進(jìn)行。可以通過DBCC SHOWCONTIG來確定是否需要重構(gòu)表的索引提高SQL Server性能。

 

2. DBCC SHOWCONTIG用法 下面舉例來說明DBCC SHOWCONTIG和DBCC

REDBINDEX的使用方法。以應(yīng)用程序中的Employee數(shù)據(jù)表作為例子,在 SQL Server的Query

 

analyzer輸入命令:

 

use database_name declare @table_id int set @table_id=object_id(’Employee’) dbcc showcontig(@table_id)

輸出結(jié)果:

  1. DBCC SHOWCONTIG scanning ’Employee’ table... Table: ’Employee’   
  2. (1195151303); index ID: 1, database ID: 53 TABLE level scan performed. - Pages   
  3. Scanned................................: 179 - Extents   
  4. Scanned..............................: 24 - Extent   
  5. Switches..............................: 24 - Avg. Pages per   
  6. Extent........................: 7.5 - Scan Density [Best Count:Actual   
  7. Count].......: 92.00% [23:25] - Logical Scan Fragmentation ..................:   
  8. 0.56% - Extent Scan Fragmentation ...................: 12.50% - Avg. Bytes Free   
  9. per Page.....................: 552.3 - Avg. Page Density   
  10. (full).....................: 93.18% DBCC execution completed. If DBCC printed   
  11. error messages, contact your system administrator.  

通過分析這些結(jié)果可以知道該表的索引是否需要重構(gòu)。如下描述了每一行的意義: 信息

 

描述 Pages Scanned 表或索引中的長頁數(shù) Extents Scanned

 

表或索引中的長區(qū)頁數(shù) Extent Switches

 

DBCC遍歷頁時(shí)從一個(gè)區(qū)域到另一個(gè)區(qū)域的次數(shù) Avg. Pages per Extent

 

相關(guān)區(qū)域中的頁數(shù) Scan Density[Best Count:Actual Count] Best

 

Count是連續(xù)鏈接時(shí)的理想?yún)^(qū)域改變數(shù),Actual Count是實(shí)際區(qū)域改變數(shù),Scan

 

Density為100%表示沒有分塊。 Logical Scan Fragmentation

 

掃描索引頁中失序頁的百分比 Extent Scan Fragmentation

 

不實(shí)際相鄰和包含鏈路中所有鏈接頁的區(qū)域數(shù) Avg. Bytes Free per Page

 

掃描頁面中平均自由字節(jié)數(shù) Avg. Page Density (full)

 

平均頁密度,表示頁有多滿

 

從上面命令的執(zhí)行結(jié)果可以看的出來,Best count為23 而Actual

Count為25這表明orders表有分塊需要重構(gòu)表索引。下面通過DBCC

 

DBREINDEX來重構(gòu)表的簇索引。

 

3. DBCC DBREINDEX 用法 重建指定數(shù)據(jù)庫中表的一個(gè)或多個(gè)索引。

語法 DBCC DBREINDEX ( [ ’database.owner.table_name’ [ , index_name [ ,

fillfactor ] ] ] )

 

參數(shù) ’database.owner.table_name’

是要重建其指定的索引的表名。數(shù)據(jù)庫、所有者和表名必須符合標(biāo)識(shí)符的規(guī)則。有關(guān)更多信

 

息,請參見使用標(biāo)識(shí)符。如果提供 database 或 owner 部分,則必須使用單引號(hào) (’)

 

將整個(gè) database.owner.table_name 括起來。如果只指定 table_name,則不需要單引號(hào)。

 

index_name 是要重建的索引名。索引名必須符合標(biāo)識(shí)符的規(guī)則。如果未指定 index_name

或指定為 ’ ’,就要對表的所有索引進(jìn)行重建。

 

fillfactor 是創(chuàng)建索引時(shí)每個(gè)索引頁上要用于存儲(chǔ)數(shù)據(jù)的空間百分比。fillfactor

替換起始填充因子以作為索引或任何其它重建的非聚集索引(因?yàn)橐阎亟ň奂饕┑男履?/p>

 

認(rèn)值。如果 fillfactor 為 0,DBCC DBREINDEX 在創(chuàng)建索引提高SQL Server性能時(shí)將使用指定的起始

 

fillfactor。

 

同樣在Query Analyzer中輸入命令:

  1. dbcc dbreindex(’database_name.dbo.Employee’,’’,90) 

然后再用DBCC SHOWCONTIG查看重構(gòu)索引提高SQL Server性能后的結(jié)果:

  1. DBCC SHOWCONTIG scanning   
  2. ’Employee’ table... Table: ’Employee’ (1195151303); index ID: 1, database ID: 53   
  3. TABLE level scan performed. - Pages Scanned................................: 178   
  4. - Extents Scanned..............................: 23 - Extent   
  5. Switches..............................: 22 - Avg. Pages per   
  6. Extent........................: 7.7 - Scan Density [Best Count:Actual   
  7. Count].......: 100.00% [23:23] - Logical Scan Fragmentation ..................:   
  8. 0.00% - Extent Scan Fragmentation ...................: 0.00% - Avg. Bytes Free   
  9. per Page.....................: 509.5 - Avg. Page Density   
  10. (full).....................: 93.70% DBCC execution completed. If DBCC printed   
  11. error messages, contact your system administrator. 

通過結(jié)果我們可以看到Scan Denity為100%。

【編輯推薦】

  1. SQL Server刪除重復(fù)數(shù)據(jù)的2個(gè)實(shí)用方案
  2. 快速對SQL Server鎖機(jī)制進(jìn)行掌握的竅門
  3. SQL Server存儲(chǔ)圖像數(shù)據(jù)大閱兵
  4.  SQL Server重復(fù)數(shù)據(jù)刪除的2個(gè)操作方案
  5. SQL Server游標(biāo)實(shí)例演示,不得不看!

 

 

責(zé)任編輯:佚名 來源: 51CTO.com
相關(guān)推薦

2011-08-10 15:11:23

SQL Server整理索引碎片重建索引

2011-04-01 15:36:24

索引SQL Server

2011-04-02 13:37:05

SQL Server 索引視圖

2010-06-17 10:43:21

SQL Server

2010-07-15 15:42:38

2010-07-07 09:27:15

SQL Server索

2011-08-04 16:20:39

SQLServer數(shù)據(jù)索引碎片DBCC ShowCo

2010-07-08 17:28:02

2010-07-09 17:25:14

SQL Server數(shù)

2011-08-19 11:10:54

SQL Server DBCC OPENTR會(huì)話查詢事務(wù)

2010-05-26 08:47:00

索引SQL Server

2010-07-02 12:51:35

SQL Server

2011-09-01 19:00:08

SQL ServerDBCC語句

2010-07-16 13:48:08

SQL Server合

2011-06-27 16:03:19

DBCCSQL Server

2010-07-14 09:41:26

SQL Server數(shù)

2010-06-30 13:49:02

SQL Server數(shù)

2010-07-15 15:25:15

SQL Server性

2010-07-16 11:30:06

SQL Server

2010-07-19 16:43:07

SQL Server選
點(diǎn)贊
收藏

51CTO技術(shù)棧公眾號(hào)