如何正确使用数据库索引

如何正确使用数据库索引,第1张

问题补充:能不能具体点,新建一个索引就可以了吗

基本上可以这么说,不过你也可以修改索引。

记住:

索引其实关键目的是为了加快检索速度而建立的,所以,怎么用索引是数据库系统本身的事情,作为数据库设计或使用者,设计并创建好索引然后体验加上索引后的查询变快的感觉就行了。所以,索引怎么用就变为了“怎么创建合适的索引”

以下回答是否符合你的要求?你还有什么问题?

第一次回答:

一、索引是什么

索引是与表或视图关联的磁盘上结构,可以加快从表或视图中检索行的速度。索引包含由表或视图中的一列或多列生成的键。这些键存储在一个结构(B 树)中,使 SQL Server 可以快速有效地查找与键值关联的行。

表或视图可以包含以下类型的索引:

* 聚集

o 聚集索引根据数据行的键值在表或视图中排序和存储这些数据行。索引定义中包含聚集索引列。每个表只能有一个聚集索引,因为数据行本身只能按一个顺序排序。

o 只有当表包含聚集索引时,表中的数据行才按排序顺序存储。如果表具有聚集索引,则该表称为聚集表。如果表没有聚集索引,则其数据行存储在一个称为堆的无序结构中。

* 非聚集

o 非聚集索引具有独立于数据行的结构。非聚集索引包含非聚集索引键值,并且每个键值项都有指向包含该键值的数据行的指针。

o 从非聚集索引中的索引行指向数据行的指针称为行定位器。行定位器的结构取决于数据页是存储在堆中还是聚集表中。对于堆,行定位器是指向行的指针。对于聚集表,行定位器是聚集索引键。

o 您可以向非聚集索引的叶级添加非键列以跳过现有的索引键限制(900 字节和 16 键列),并执行完整范围内的索引查询。

聚集索引和非聚集索引都可以是唯一的。这意味着任何两行都不能有相同的索引键值。另外,索引也可以不是唯一的,即多行可以共享同一键值。

每当修改了表数据后,都会自动维护表或视图的索引。

索引和约束

对表列定义了 PRIMARY KEY 约束和 UNIQUE 约束时,会自动创建索引。例如,如果创建了表并将一个特定列标识为主键,则 数据库引擎自动对该列创建 PRIMARY KEY 约束和索引。有关详细信息,请参阅创建索引(数据库引擎)。

二、索引有什么用

与书中的索引一样,数据库中的索引使您可以快速找到表或索引视图中的特定信息。索引包含从表或视图中一个或多个列生成的键,以及映射到指定数据的存储位置的指针。通过创建设计良好的索引以支持查询,可以显著提高数据库查询和应用程序的性能。索引可以减少为返回查询结果集而必须读取的数据量。索引还可以强制表中的行具有唯一性,从而确保表数据的数据完整性。

设计良好的索引可以减少磁盘 I/O *** 作,并且消耗的系统资源也较少,从而可以提高查询性能。对于包含 SELECT、UPDATE、DELETE 或 MERGE 语句的各种查询,索引会很有用。例如,在 AdventureWorks 数据库中执行的查询 SELECT Title, HireDate FROM HumanResources.Employee WHERE EmployeeID = 250。执行此查询时,查询优化器评估可用于检索数据的每个方法,然后选择最有效的方法。可能采用的方法包括扫描表和扫描一个或多个索引(如果有)。

扫描表时,查询优化器读取表中的所有行,并提取满足查询条件的行。扫描表会有许多磁盘 I/O *** 作,并占用大量资源。但是,如果查询的结果集是占表中较高百分比的行,扫描表会是最为有效的方法。

查询优化器使用索引时,搜索索引键列,查找到查询所需行的存储位置,然后从该位置提取匹配行。通常,搜索索引比搜索表要快很多,因为索引与表不同,一般每行包含的列非常少,且行遵循排序顺序。

查询优化器在执行查询时通常会选择最有效的方法。但如果没有索引,则查询优化器必须扫描表。您的任务是设计并创建最适合您的环境的索引,以便查询优化器可以从多个有效的索引中选择。SQL Server 提供的数据库引擎优化顾问可以帮助分析数据库环境并选择适当的索引。

三、索引怎么用

索引其实关键目的是为了加快检索速度而建立的,所以,怎么用索引是数据库系统本身的事情,作为数据库设计或使用者,设计并创建好索引然后体验加上索引后的查询变快的感觉就行了。所以,索引怎么用就变为了“怎么创建合适的索引”,以下说明这个问题:

索引设计不佳和缺少索引是提高数据库和应用程序性能的主要障碍。设计高效的索引对于获得良好的数据库和应用程序性能极为重要。为数据库及其工作负荷选择正确的索引是一项需要在查询速度与更新所需开销之间取得平衡的复杂任务。如果索引较窄,或者说索引关键字中只有很少的几列,则需要的磁盘空间和维护开销都较少。而另一方面,宽索引可覆盖更多的查询。您可能需要试验若干不同的设计,才能找到最有效的索引。可以添加、修改和删除索引而不影响数据库架构或应用程序设计。因此,应试验多个不同的索引而无需犹豫。

SQL Server 中的查询优化器可在大多数情况下可靠地选择最高效的索引。总体索引设计策略应为查询优化器提供可供选择的多个索引,并依赖查询优化器做出正确的决定。这在多种情况下可减少分析时间并获得良好的性能。若要查看查询优化器对特定查询使用的索引,请在 SQL Server Management Studio 中的“查询”菜单上选择“包括实际的执行计划”。

不要总是将索引的使用等同于良好的性能,或者将良好的性能等同于索引的高效使用。如果只要使用索引就能获得最佳性能,那查询优化器的工作就简单了。但事实上,不正确的索引选择并不能获得最佳性能。因此,查询优化器的任务是只在索引或索引组合能提高性能时才选择它,而在索引检索有碍性能时则避免使用它。

建议的索引设计策略包括以下任务:

1. 了解数据库本身的特征。例如,它是频繁修改数据的联机事务处理 (OLTP) 数据库,还是主要包含只读数据的决策支持系统 (DSS) 或数据仓库 (OLAP) 数据库?

2. 了解最常用的查询的特征。例如,了解到最常用的查询联接两个或多个表将有助于决定要使用的最佳索引类型。

3. 了解查询中使用的列的特征。例如,某个索引对于含有整数数据类型同时还是唯一的或非空的列是理想索引。筛选索引适用于具有定义完善的数据子集的列。

4. 确定哪些索引选项可在创建或维护索引时提高性能。例如,对现有某个大型表创建聚集索引将会受益于 ONLINE 索引选项。ONLINE 选项允许在创建索引或重新生成索引时继续对基础数据执行并发活动。

5. 确定索引的最佳存储位置。非聚集索引可以与基础表存储在同一个文件组中,也可以存储在不同的文件组中。索引的存储位置可通过提高磁盘 I/O 性能来提高查询性能。例如,将非聚集索引存储在表文件组所在磁盘以外的某个磁盘上的一个文件组中可以提高性能,因为可以同时读取多个磁盘。

或者,聚集索引和非聚集索引也可以使用跨越多个文件组的分区方案。在维护整个集合的完整性时,使用分区可以快速而有效地访问或管理数据子集,从而使大型表或索引更易于管理。有关详细信息,请参阅已分区表和已分区索引。在考虑分区时,应确定是否应对齐索引,即,是按实质上与表相同的方式进行分区,还是单独分区。

# 设计索引。

索引设计是一项关键任务。索引设计包括确定要使用的列,选择索引类型(例如聚集或非聚集),选择适当的索引选项,以及确定文件组或分区方案布置。

# 确定最佳的创建方法。按照以下方法创建索引:

* 使用 CREATE TABLE 或 ALTER TABLE 对列定义 PRIMARY KEY 或 UNIQUE 约束

SQL Server 数据库引擎自动创建唯一索引来强制 PRIMARY KEY 或 UNIQUE 约束的唯一性要求。默认情况下,创建的唯一聚集索引可以强制 PRIMARY KEY 约束,除非表中已存在聚集索引或指定了唯一的非聚集索引。默认情况下,创建的唯一非聚集索引可以强制 UNIQUE 约束,除非已明确指定唯一的聚集索引且表中不存在聚集索引。

还可以指定索引选项和索引位置、文件组或分区方案。

创建为 PRIMARY KEY 或 UNIQUE 约束的一部分的索引将自动给定与约束名称相同的名称。

* 使用 CREATE INDEX 语句或 SQL Server Management Studio 对象资源管理器中的“新建索引”对话框创建独立于约束的索引

必须指定索引的名称、表以及应用该索引的列。还可以指定索引选项和索引位置、文件组或分区方案。默认情况下,如果未指定聚集或唯一选项,将创建非聚集的非唯一索引。若要创建筛选索引,请使用可选的 WHERE 子句。

# 创建索引。

要考虑的一个重要因素是对空表还是对包含数据的表创建索引。对空表创建索引在创建索引时不会对性能产生任何影响,而向表中添加数据时,会对性能产生影响。

对大型表创建索引时应仔细计划,这样才不会影响数据库性能。对大型表创建索引的首选方法是先创建聚集索引,然后创建任何非聚集索引。在对现有表创建索引时,请考虑将 ONLINE 选项设置为 ON。该选项设置为 ON 时,将不持有长期表锁以继续对基础表的查询或更新。

Hash Global分区索引介绍

HASH-Partitioned Global索引是Oracle 10g开始提供的新特性。而在以前的版本中

,Oracle只支持Range-Partitioned Global索引。HASH-Partitioned Global索引的好处如下:

比Range-Partitioned Global索引易于实施。HASH-Partitioned Global索引是根据

索引字段值,通过Oracle内部的HASH算法自动均匀散列到定义的分区中。而

Range-Partitioned Global索引需要根据索引字段值的范围进行分区,因此实施和

维护的难度都大。

HASH-Partitioned Global索引适合于在并发量、吞吐量很大的交易系统(OLTP)

中,对某些字段的访问冲突。尤其是sequence字段值。

HASH-Partitioned Global索引适合于大批量的数据查询。HASH-Partitioned Global索引不仅可以提供分区之间的并行查询,

而且在分区内也可进行并行查询的处理。

建立分区索引必须指定表空间,并且指定的表空间要与数据表空间分开,

这样便于管理,同时尽可能分开索引和数据的IO访问,提高效率

from askmaclean

很多时候你或者因为性能问题而使用表分区技术,将一些数据放到不同的分区,而这些数据实际上是被逻辑的放到不同的文件组里

大家知道:不管是索引还是数据,文件组都是这些索引和数据存放的最小逻辑单位

文件组是文件的命名集合,用于简化数据存放和管理任务(例如,备份和还原 *** 作,文件组备份和文件组还原)

MSDN 使用文件和文件组 :http://msdn.microsoft.com/zh-cn/library/ms187087(v=sql.90).aspx

那么假如我有一个表使用了表分区技术,如下图

表中索引和数据放在这3个文件组中,其中历史数据/归档数据放在文件组1,索引放在文件组2,当前数据放在文件组3

当然,真实环境中的大型数据库会有更多的文件组用来存放不同的历史数据和索引!!

对于使用了分区表机制的数据库,对于存储历史数据的分区文件组,由于数据本身已经不会发生修改,我们可以把文件组类型设成只读模式,

防止任何误修改。

步骤一:

我们可以对文件组1进行一次DBCC CHECKFILEGROUP检查,如果没有错误,就将文件组1设置为只读,

这样以后就不用再执行DBCC CHECKFILEGROUP检查了,因为文件组1是只读的,不会再对它进行修改

我们使用下面SQL语句检查文件组1是否有错误

1 USE [partionTest]2 GO3 DBCC CHECKFILEGROUP(1)4 GO

1 partionTest的 DBCC 结果。 2 sys.sysrowsetcolumns的 DBCC 结果。 3 对象 'sys.sysrowsetcolumns' 的 5 页中有 552 行。 4 sys.sysrowsets的 DBCC 结果。 5 对象 'sys.sysrowsets' 的 1 页中有 84 行。 6 sysallocunits的 DBCC 结果。 7 对象 'sysallocunits' 的 1 页中有 95 行。 8 sys.sysfiles1的 DBCC 结果。 9 对象 'sys.sysfiles1' 的 1 页中有 6 行。10 sys.syshobtcolumns的 DBCC 结果。11 对象 'sys.syshobtcolumns' 的 5 页中有 552 行。12 sys.syshobts的 DBCC 结果。13 对象 'sys.syshobts' 的 1 页中有 84 行。14 sys.sysftinds的 DBCC 结果。15 对象 'sys.sysftinds' 的 0 页中有 0 行。16 sys.sysserefs的 DBCC 结果。17 对象 'sys.sysserefs' 的 1 页中有 95 行。18 sys.sysowners的 DBCC 结果。19 对象 'sys.sysowners' 的 1 页中有 14 行。20 sys.sysprivs的 DBCC 结果。21 对象 'sys.sysprivs' 的 1 页中有 120 行。22 sys.sysschobjs的 DBCC 结果。23 对象 'sys.sysschobjs' 的 1 页中有 50 行。24 sys.syscolpars的 DBCC 结果。25 对象 'sys.syscolpars' 的 7 页中有 424 行。26 sys.sysnsobjs的 DBCC 结果。27 对象 'sys.sysnsobjs' 的 1 页中有 1 行。28 sys.syscerts的 DBCC 结果。29 对象 'sys.syscerts' 的 0 页中有 0 行。30 sys.sysxprops的 DBCC 结果。31 对象 'sys.sysxprops' 的 0 页中有 0 行。32 sys.sysscalartypes的 DBCC 结果。33 对象 'sys.sysscalartypes' 的 1 页中有 27 行。34 sys.systypedsubobjs的 DBCC 结果。35 对象 'sys.systypedsubobjs' 的 1 页中有 1 行。36 sys.sysidxstats的 DBCC 结果。37 对象 'sys.sysidxstats' 的 2 页中有 151 行。38 sys.sysiscols的 DBCC 结果。39 对象 'sys.sysiscols' 的 2 页中有 263 行。40 sys.sysbinobjs的 DBCC 结果。41 对象 'sys.sysbinobjs' 的 1 页中有 23 行。42 sys.sysobjvalues的 DBCC 结果。43 对象 'sys.sysobjvalues' 的 24 页中有 151 行。44 sys.sysclsobjs的 DBCC 结果。45 对象 'sys.sysclsobjs' 的 1 页中有 20 行。46 sys.sysrowsetrefs的 DBCC 结果。47 对象 'sys.sysrowsetrefs' 的 1 页中有 4 行。48 sys.sysremsvcbinds的 DBCC 结果。49 对象 'sys.sysremsvcbinds' 的 0 页中有 0 行。50 sys.sysxmitqueue的 DBCC 结果。51 对象 'sys.sysxmitqueue' 的 0 页中有 0 行。52 sys.sysrts的 DBCC 结果。53 对象 'sys.sysrts' 的 1 页中有 1 行。54 sys.sysconvgroup的 DBCC 结果。55 对象 'sys.sysconvgroup' 的 0 页中有 0 行。56 sys.sysdesend的 DBCC 结果。57 对象 'sys.sysdesend' 的 0 页中有 0 行。58 sys.sysdercv的 DBCC 结果。59 对象 'sys.sysdercv' 的 0 页中有 0 行。60 sys.syssingleobjrefs的 DBCC 结果。61 对象 'sys.syssingleobjrefs' 的 1 页中有 138 行。62 sys.sysmultiobjrefs的 DBCC 结果。63 对象 'sys.sysmultiobjrefs' 的 1 页中有 102 行。64 sys.sysdbfiles的 DBCC 结果。65 对象 'sys.sysdbfiles' 的 1 页中有 6 行。66 sys.sysguidrefs的 DBCC 结果。67 对象 'sys.sysguidrefs' 的 1 页中有 4 行。68 sys.sysqnames的 DBCC 结果。69 对象 'sys.sysqnames' 的 1 页中有 91 行。70 sys.sysxmlcomponent的 DBCC 结果。71 对象 'sys.sysxmlcomponent' 的 1 页中有 93 行。72 sys.sysxmlfacet的 DBCC 结果。73 对象 'sys.sysxmlfacet' 的 1 页中有 97 行。74 sys.sysxmlplacement的 DBCC 结果。75 对象 'sys.sysxmlplacement' 的 1 页中有 17 行。76 sys.sysobjkeycrypts的 DBCC 结果。77 对象 'sys.sysobjkeycrypts' 的 0 页中有 0 行。78 sys.sysasymkeys的 DBCC 结果。79 对象 'sys.sysasymkeys' 的 0 页中有 0 行。80 sys.syssqlguides的 DBCC 结果。81 对象 'sys.syssqlguides' 的 0 页中有 0 行。82 sys.sysbinsubobjs的 DBCC 结果。83 对象 'sys.sysbinsubobjs' 的 0 页中有 0 行。84 sys.queue_messages_1977058079的 DBCC 结果。85 对象 'sys.queue_messages_1977058079' 的 0 页中有 0 行。86 sys.queue_messages_2009058193的 DBCC 结果。87 对象 'sys.queue_messages_2009058193' 的 0 页中有 0 行。88 sys.queue_messages_2041058307的 DBCC 结果。89 对象 'sys.queue_messages_2041058307' 的 0 页中有 0 行。90 无法处理对象 "testPartionTable" (ID 2073058421)、索引 "testPartionTable" (ID 0)的行集 ID 72057594038321152,因为它驻留在文件组 "FileGroup001" (ID 2)中,但未选中该文件组。 91 无法处理对象 "testPartionTable" (ID 2073058421)、索引 "testPartionTable" (ID 0)的行集 ID 72057594038386688,因为它驻留在文件组 "FileGroup002" (ID 3)中,但未选中该文件组。 92 无法处理对象 "testPartionTable" (ID 2073058421)、索引 "testPartionTable" (ID 0)的行集 ID 72057594038452224,因为它驻留在文件组 "FileGroup003" (ID 4)中,但未选中该文件组。 93 无法处理对象 "testPartionTable" (ID 2073058421)、索引 "testPartionTable" (ID 0)的行集 ID 72057594038517760,因为它驻留在文件组 "FileGroup004" (ID 5)中,但未选中该文件组。 94 无法处理对象 "aa" (ID 2105058535)、索引 "aa" (ID 0)的行集 ID 72057594038583296,因为它驻留在文件组 "FileGroup001" (ID 2)中,但未选中该文件组。 95 无法处理对象 "rr" (ID 2121058592)、索引 "rr" (ID 0)的行集 ID 72057594038648832,因为它驻留在文件组 "FileGroup001" (ID 2)中,但未选中该文件组。 96 CHECKFILEGROUP 在数据库 'partionTest' 中发现 0 个分配错误和 0 个一致性错误。97 DBCC 执行完毕。如果 DBCC 输出了错误信息,请与系统管理员联系。

View Code

从结果中可以看到只检查了文件组1里的错误

如果是检查文件组2的话就用下面的SQL语句,将1改为2就行了

1 USE [partionTest]2 GO3 DBCC CHECKFILEGROUP(2)4 GO

1 partionTest的 DBCC 结果。 2 sys.sysowners的 DBCC 结果。 3 对象 'sys.sysowners' 的 0 页中有 0 行。 4 sys.sysschobjs的 DBCC 结果。 5 对象 'sys.sysschobjs' 的 0 页中有 0 行。 6 sys.syscolpars的 DBCC 结果。 7 对象 'sys.syscolpars' 的 0 页中有 0 行。 8 sys.sysnsobjs的 DBCC 结果。 9 对象 'sys.sysnsobjs' 的 0 页中有 0 行。10 sys.syscerts的 DBCC 结果。11 对象 'sys.syscerts' 的 0 页中有 0 行。12 sys.sysscalartypes的 DBCC 结果。13 对象 'sys.sysscalartypes' 的 0 页中有 0 行。14 sys.systypedsubobjs的 DBCC 结果。15 对象 'sys.systypedsubobjs' 的 0 页中有 0 行。16 sys.sysidxstats的 DBCC 结果。17 对象 'sys.sysidxstats' 的 0 页中有 0 行。18 sys.sysbinobjs的 DBCC 结果。19 对象 'sys.sysbinobjs' 的 0 页中有 0 行。20 sys.sysclsobjs的 DBCC 结果。21 对象 'sys.sysclsobjs' 的 0 页中有 0 行。22 sys.sysremsvcbinds的 DBCC 结果。23 对象 'sys.sysremsvcbinds' 的 0 页中有 0 行。24 sys.sysrts的 DBCC 结果。25 对象 'sys.sysrts' 的 0 页中有 0 行。26 sys.syssingleobjrefs的 DBCC 结果。27 对象 'sys.syssingleobjrefs' 的 0 页中有 0 行。28 sys.sysmultiobjrefs的 DBCC 结果。29 对象 'sys.sysmultiobjrefs' 的 0 页中有 0 行。30 sys.sysguidrefs的 DBCC 结果。31 对象 'sys.sysguidrefs' 的 0 页中有 0 行。32 sys.sysqnames的 DBCC 结果。33 对象 'sys.sysqnames' 的 0 页中有 0 行。34 sys.sysxmlcomponent的 DBCC 结果。35 对象 'sys.sysxmlcomponent' 的 0 页中有 0 行。36 sys.sysxmlplacement的 DBCC 结果。37 对象 'sys.sysxmlplacement' 的 0 页中有 0 行。38 sys.sysasymkeys的 DBCC 结果。39 对象 'sys.sysasymkeys' 的 0 页中有 0 行。40 sys.syssqlguides的 DBCC 结果。41 对象 'sys.syssqlguides' 的 0 页中有 0 行。42 sys.sysbinsubobjs的 DBCC 结果。43 对象 'sys.sysbinsubobjs' 的 0 页中有 0 行。44 sys.queue_messages_1977058079的 DBCC 结果。45 无法处理对象 "sys.queue_messages_1977058079" (ID 1993058136)、索引 "queue_clustered_index" (ID 1)的行集 ID 72057594037927936,因为它驻留在文件组 "PRIMARY" (ID 1)中,但未选中该文件组。 46 无法处理对象 "sys.queue_messages_1977058079" (ID 1993058136)、索引 "queue_secondary_index" (ID 2)的行集 ID 72057594037993472,因为它驻留在文件组 "PRIMARY" (ID 1)中,但未选中该文件组。 47 对象 'sys.queue_messages_1977058079' 的 0 页中有 0 行。48 sys.queue_messages_2009058193的 DBCC 结果。49 无法处理对象 "sys.queue_messages_2009058193" (ID 2025058250)、索引 "queue_clustered_index" (ID 1)的行集 ID 72057594038059008,因为它驻留在文件组 "PRIMARY" (ID 1)中,但未选中该文件组。 50 无法处理对象 "sys.queue_messages_2009058193" (ID 2025058250)、索引 "queue_secondary_index" (ID 2)的行集 ID 72057594038124544,因为它驻留在文件组 "PRIMARY" (ID 1)中,但未选中该文件组。 51 对象 'sys.queue_messages_2009058193' 的 0 页中有 0 行。52 sys.queue_messages_2041058307的 DBCC 结果。53 无法处理对象 "sys.queue_messages_2041058307" (ID 2057058364)、索引 "queue_clustered_index" (ID 1)的行集 ID 72057594038190080,因为它驻留在文件组 "PRIMARY" (ID 1)中,但未选中该文件组。 54 无法处理对象 "sys.queue_messages_2041058307" (ID 2057058364)、索引 "queue_secondary_index" (ID 2)的行集 ID 72057594038255616,因为它驻留在文件组 "PRIMARY" (ID 1)中,但未选中该文件组。 55 对象 'sys.queue_messages_2041058307' 的 0 页中有 0 行。56 testPartionTable的 DBCC 结果。57 无法处理对象 "testPartionTable" (ID 2073058421)、索引 "testPartionTable" (ID 0)的行集 ID 72057594038386688,因为它驻留在文件组 "FileGroup002" (ID 3)中,但未选中该文件组。 58 无法处理对象 "testPartionTable" (ID 2073058421)、索引 "testPartionTable" (ID 0)的行集 ID 72057594038452224,因为它驻留在文件组 "FileGroup003" (ID 4)中,但未选中该文件组。 59 无法处理对象 "testPartionTable" (ID 2073058421)、索引 "testPartionTable" (ID 0)的行集 ID 72057594038517760,因为它驻留在文件组 "FileGroup004" (ID 5)中,但未选中该文件组。 60 对象 'testPartionTable' 的 2 页中有 126 行。61 aa的 DBCC 结果。62 对象 'aa' 的 0 页中有 0 行。63 rr的 DBCC 结果。64 对象 'rr' 的 0 页中有 0 行。65 CHECKFILEGROUP 在数据库 'partionTest' 中发现 0 个分配错误和 0 个一致性错误。66 DBCC 执行完毕。如果 DBCC 输出了错误信息,请与系统管理员联系。

View Code

从结果中可以看到只检查了文件组2里的错误

步骤二:

如果发现文件组1有错误,我们需要使用DBCC CHECKDB来修复错误或者还原文件组备份

1 DBCC CHECKDB([partionTest],REPAIR_ALLOW_DATA_LOSS)

步骤三:设置文件组1为只读文件组

设置文件组1为只读文件组之前需要断开所有对业务数据库的连接

1 USE master2 GO3 ALTER DATABASE [partionTest] SET OFFLINE4 5 --语法6 ALTER DATABASE [partionTest] MODIFY FILEGROUP 文件组名 READONLY7 8 ALTER DATABASE [partionTest] MODIFY FILEGROUP FileGroup001 READONLY

步骤四:对于存储当前的数据的分区文件组(不是历史数据),每个星期或者一星期两次的DBCC CHECKFILEGROUP即可

因为表中的索引和表中的现有数据是随时变化的,今年2013年还没有过完,所以文件组3中的数据和文件组2中的索引肯定会变化的

这个只能定期做DBCC CHECKFILEGROUP了

小结:

对于大型数据库,SQLSERVER针对是否使用了多个文件组的数据库提供了比较灵活的DBCC CHECKDB的方法

如果使用了多个文件组,就使用DBCC CHECKFILEGROUP

注意:这里除了表分区会用到多个文件组之外,不用表分区也可以使用多个文件组,在创建表的时候或者创建索引的时候

可以指定表和索引建立在哪个文件组上!!

没有使用表分区技术的数据库或者只有一个默认文件组的数据库

可以使用下面几个语句把DBCC CHECKDB里的关键任务分解在每天运行

周一到周三:每天运行一组,假如32张GPOSDB表,32/3=10张表/每天

1 DBCC CHECKTABLE()

周四: DBCC CHECKALLOC(gposdb) + 一组 DBCC CHECKTABLE()

1 DBCC CHECKALLOC(gposdb) 2 DBCC CHECKTABLE()

周五周六:每天运行一组 DBCC CHECKTABLE()

1 DBCC CHECKTABLE()

周日: DBCC CHECKALLOC(gposdb) + DBCC CHECKCATALOG(gposdb) + 一组DBCC CHECKTABLE()

1 DBCC CHECKALLOC(gposdb) 2 DBCC CHECKCATALOG(gposdb) 3 DBCC CHECKTABLE()

SQLSERVER提供给大家的一些DBCC CHECKDB选项

并行检查对象

若要限制DBCC检查可使用的处理器的最大数目,请使用

1 EXEC sys.sp_configure @configname = 'max degree of parallelism', -- varchar(35)2 @configvalue = 0 -- int

使用跟踪标识 /T 2528 可以禁用并行检查

PHYSICAL ONLY

对大表使用physical_only可以节省时间,检查索引,noindex可以让SQL不用去做费事费力的

非聚集索引检查

1 DBCC CHECKDB(GPOSDB,NOINDEX) WITH physical_only

除了DBCC CHECKDB之外,DBCC CHECKFILEGROUP和DBCC CHECKTABLE也有PHYSICAL ONLY和noindex选项

详细的可以看msdn

CHECKFILEGROUP:http://msdn.microsoft.com/zh-cn/library/ms187332.aspx

CHECKTABLE:http://msdn.microsoft.com/zh-cn/library/ms174338(v=sql.105).aspx

CHECKCATALOG:http://msdn.microsoft.com/zh-cn/library/ms186720(v=sql.105).aspx

CHECKALLOC:http://msdn.microsoft.com/zh-cn/library/ms188422(v=sql.90).aspx

总结

个人感觉其实SQLSERVER的东西挺灵活的,提供的选项也比较多,关键是你怎麽去用,你知道他内部的一些原理有多少

就像DBCC CHECKDB这个简单的命令其实也可以做得很灵活,一些不会用的人对于大型数据库随便

执行DBCC CHECKDB,结果就是无限期的等待

就像徐老师在《SQLSERVER企业级平台管理实践》里说的

根据2009年的经验,一个大于1TB的数据库如果没有错误,CHECKDB在某些机器上用20小时就能够跑完

,而一个有上百上千错误的数据库,哪怕只有两三百GB,有可能一天都跑不完。这个区别很显著


欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/sjk/10041037.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-05-04
下一篇 2023-05-04

发表评论

登录后才能评论

评论列表(0条)

保存