博客园_我爱菊花

DBA的价值及其发展方向

2011-05-18T13:23:00Z

看看时间大概已经有半年没有来博客园了,最近半年好像一直都忙碌着.也不知道忙些什么.

最近偶然间在思考一个问题:DBA的价值及其发展方向?

圈子里面也应该有好多DBA吧,或者有志于做DBA方面的工作, 我也在想弄清楚DBA的价值及其发展方向. 前几天看过一篇帖子说DBA的价值不仅仅在于维护数据库本身, 而应该在数据存储方案的选择上作出最专业的判断, 这是DBA最大的价值所在.

DBA可以分为以下几个方面: 系统管理, 数据存储, 数据库开发与设计, 企业数据架构, 商业智能等等等等.

做DBA难, 需要了解掌握的东西太多了,包括软件,硬件都要了解.应该是在某个方面熟悉精通之后才开始拓展到另外的一个方面.

请教园子里大牛们有何高见?

本文链接

SQL Server性能调校系列(7)--RAID

2010-10-21T03:12:00Z

一: RAID简介

RAID(Redundant Array of Independent Disk 独立冗余磁盘阵列)是一项数据保护策略.

二: RAID的几种常用级别

1. RAID 0：

通过并行读取来提高数据I/O, 读取操作效率很高, 但是不提供数据容错及保护. 不推荐作为SQL Server使用.

2. RAID 1：

镜像保护,有两个驱动器,一个做主驱动器,一个做镜像, 所以是实际需要两倍的驱动器,第二个所为冗余使用. 使用RAID 1我们的存储容量应该是（n*s/2）。

一次写操作写入到两个磁盘, 所以虽写入速度会稍微有影响, 但是读取速度几乎是大多数情况下的两倍. 因为在读取操作过程中驱动器可以并行地进行访问，从而提高了吞吐量。RAID 1限制于两个驱动器。

3. RAID 5:

带校验的磁盘条带。在这种类型的RAID中，数据以复杂条带的形式写入到阵列中的所有驱动器中，同时所有驱动器中都有分布数校验块。这样RAID 5就可能使用三个或者更多磁盘组成的任意大小的阵列，只牺牲相当于一个磁盘的存储容量用于校验。但是这种校验是分布式的，并不单独存在于任何一个物理磁盘中.

RAID 5由于在大型阵列中牺牲的存储容量较少，所以它具有成本效益的特点，从而被人们所广泛使用。与镜像不同的是，带有校验的条带要求必须在磁盘之间进行针对每个写入条带的计算，这造成了一部分的开销。因此，吞吐量并不总是一个容易计算的项目，它在很大程度上取决于系统在做校验计算时候的计算能力。

计算RAID 5的容量非常简单：就是（（n-1）*s）。RAID 5阵列可以避免这列中任何单个磁盘的丢失.

对RAID5的每一次写操作, 都会涉及到多个读用于计算并且存储. 对SQL Server有很多的写操作,并且要求很高效率的时, RAID 5并不是一个很好的选择.

4. RAID 6

带双重校验的磁盘条带。RAID 6与RAID 5非常相似，但它的每个条带使用两个校验块，而不是一个，这加强了应对磁盘故障的保护能力。

RAID 6是RAID家族中的新成员。RAID 6是其他几个RAID类型实现标准化几年之后增加的。RAID 6比较特殊，因为它可以承受阵列中任意两个驱动器的故障，同时防止数据丢失。但是为了配合额外的冗余度，RAID 6阵列需要牺牲阵列中相当于两个驱动器的容量，并要求真列中最少有四个驱动器。RAID 6的容量可以用（（n-2）*s）来计算。

5. RAID 10:

带条带的镜像。从技术上来说，RAID 10是一种混合的RAID，包括存在于一个非校验条带（RAID 0）中的一对RAID镜像。

当一个阵列中只有两个驱动器的时候，很多厂商会称其为RAID 10（或者RAID 10+），但从技术上来说这应该是RAID 1，因为阵列中至少有四个驱动器才会发生条带化。对于RAID 10来说，驱动器必须是一对一对添加的，因此阵列中的驱动器数量只可能是偶数。

RAID 10可以在丢失近半数驱动器组的情况下正常运转，同时最多只能承受每个驱动器中一个驱动器发生故障或者丢失。RAID 10不包含校验计算，这使得它相对RAID 5和RAID 6来说具有一定的性能优势，而且阵列对计算能力的要求也更低。RAID 10提供了超过任何一种常见类型RAID的读取性能，因为在读取操作中阵列中的所有驱动器都可同时使用。但是RAID 10的写入性能要低很多。RAID 10的容量计算方法和RAID 1相同，都是（n*s/2）。

RAID性能比较:

读效率: 因为是并行读取, 读取效率都很高.

写效率: RAID 0 > RAID 1 > RAID 10 > RAID 5

磁盘利用率: RAID 0 > RAID 5 > RAID 1 = RAID 10

容错能力: RAID 10 = RAID 1 > RAID 5 > RAID 0

作为SQL Server 的DB Server建议使用RAID 1 或RAID10.

三: RAID与SQL Server

DB server physical disk design with separate RAID volumes for data, log, tempdb and backup files.

磁盘架构:

C: OS [要求很好的数据读写效率, 并且有很强的容错能力, 提供数据保护]

D: 做RAID10, 存储DB数据文件 [要求读的效率高, 写效率比较低一些, 容错能力要强,如果数据文件很大, 要求节约磁盘空间]

E: 做RAID1, 存储DB日志文件 [在DB运行过程中, 日志读写比较频繁, 需要很高的数据读写效率]

F: 做RAID10, 存储数据库的tempdb [存放临时数据库]

G(可选): 做RAID1, 数据备份,建议数据备份在远端

SSD硬盘:SSD的英文全称是Solid State Disk/Drive, 中文翻译为固态硬盘. 可以广泛应用于服务器、台式机、笔记本、移动设备、游戏机等, 加速启动, 提高性能, 同时降低功耗.

优点:

速度快(高I/O).
耐用防震
无噪音
重量轻
SQL Server搭配SSD硬盘可以取得很好的I/O性能

缺点:

价格高,容量小,做RAID会进一步损失容量, 所以性价比不高. 对于不考虑价格的公司就另当别论.
技术还不是太成熟

四: 总结

针对不同的功能,建立不同的RAID架构可以提高数据效率和利用率.

(以上只是自己对RAID的一点浅显的理解,如有错误或者不当的地方,欢迎提出指正. 谢谢!)

>>>SQL Server性能调校系列入口地址

本文链接

SQL Server数据库表锁定原理以及如何解除表的锁定--示例演示

2010-10-12T06:12:00Z

<<接上篇:SQL Server数据库表锁定原理以及如何解除表的锁定>>

有几个朋友留言建议结合例子来演示一下, 上篇已经说过锁的几种类型, 可以利用系统动态视图sys.dm_tran_locks查看到,重要的栏位如下:

resource_type	被锁的资源类型(Database, FILE, Object,PAGE,KEY,EXTENT,RID,APPLICATION,METADATA,HOBT,APPOCATION_UNIT)
request_mode	锁的类型(共享锁,更新锁,排它锁, 架构锁等)
resource_description	资源描述
request_session_id	Request session ID

一: 下面以AdventureWorks2008为示例数据库做简要的说明,过滤掉一般的数据库的共享锁, 作为示例必须要看到锁, 所以用WITH(HOLDLOCK)来保持锁.

1. Shared locks (S) 共享锁

USE AdventureWorks2008

BEGIN TRAN
select * from Sales.SalesOrderHeader WITH(HOLDLOCK)
where SalesOrderID='43662'

SELECT resource_type, request_mode, resource_description,request_session_id, DB_NAME(resource_database_id)as resource_database
FROM sys.dm_tran_locks
WHERE resource_type <> 'DATABASE'

--ROLLBACK TRAN

在事务回滚之前, 查看锁的类型:

其他session对Table只读, 不能更新, 在开一个新的session测试:

select * from Sales.SalesOrderHeader where SalesOrderID='43662'

go
update Sales.SalesOrderHeader set OrderDate=GETDATE() where SalesOrderID='43662'

select可以正常执行, update语句一直处于等待状态, 等待上面的session释放锁.

2. Update locks (U): 更新锁是共享锁和独占锁的组合.用UPDLOCK保持更新锁

USE AdventureWorks2008

BEGIN TRAN
select * from Sales.SalesOrderHeader WITH(UPDLOCK)
where SalesOrderID='43662'

SELECT resource_type, request_mode, resource_description,request_session_id,DB_NAME(resource_database_id)as resource_database
FROM sys.dm_tran_locks
WHERE resource_type <> 'DATABASE'

ROLLBACK TRAN

查看到锁的信息:

3.Exclusive locks (X): 独占锁是为了锁定数据被一个session修改的数据, 而不能够被另外的session修改. 只能指定NOLOCK来读取.

USE AdventureWorks2008

BEGIN TRAN

update Sales.SalesOrderHeader set ShipDate=GETDATE() where SalesOrderID='43662'

SELECT resource_type, request_mode, resource_description,request_session_id,DB_NAME(resource_database_id)as resource_database--,*
FROM sys.dm_tran_locks
WHERE resource_type <> 'DATABASE'

ROLLBACK TRAN

查看锁:

4.Intent locks (I): 意向锁用于建立锁的层次结构. 意向锁包含三种类型：意向共享 (IS)、意向排他 (IX) 和意向排他共享 (SIX)。

数据库引擎使用意向锁来保护共享锁（S 锁）或排他锁（X 锁）放置在锁层次结构的底层资源上。意向锁之所以命名为意向锁，是因为在较低级别锁前可获取它们，因此会通知意向将锁放置在较低级别上。

意向锁有两种用途：

防止其他事务以会使较低级别的锁无效的方式修改较高级别资源。
提高数据库引擎在较高的粒度级别检测锁冲突的效率。

5. Schema locks (Sch): 架构锁

Schema stability lock(Sch-S): 保持架构稳定性,用在生成执行计划时,不会阻止对数据的访问.
Schema modification lock (Sch-M):用在DDL操作时.当架构正在被改变时, 阻止对对象数据的访问.

USE AdventureWorks2008

BEGIN TRAN
CREATE TABLE MyTable (ID INT, NAME VARCHAR(20),COUNTRY VARCHAR(15))

SELECT resource_type, request_mode, resource_description
FROM sys.dm_tran_locks
WHERE resource_type <> 'DATABASE' order by request_mode

ROLLBACK TRAN

6. Bulk Update locks (BU)

数据库引擎在将数据大容量复制到表中时使用了大容量更新 (BU) 锁, 并指定了 TABLOCK 提示或使用 sp_tableoption 设置了 table lock on bulk load 表选项. 大容量更新锁（BU 锁）允许多个线程将数据并发地大容量加载到同一表, 同时防止其他不进行大容量加载数据的进程访问该表.

7. Key - Range locks

在使用可序列化事务隔离级别时, 对于 Transact-SQL 语句读取的记录集, 键范围锁可以隐式保护该记录集中包含的行范围. 键范围锁可防止幻读. 通过保护行之间键的范围, 它还防止对事务访问的记录集进行幻像插入或删除.

二: 死锁与死锁解除

1. 死锁

使用或管理数据库都不可避免的涉及到死锁. 一旦发生死锁, 数据相互等待对方资源的释放,会阻止对数据的访问, 严重会造成DB挂掉. 当资源被锁定, 无法被访问时, 可以终止访问DB的那个session来达到解锁的目的(即 Kill掉造成锁的那个进程).

在两个或多个任务中，如果每个任务锁定了其他任务试图锁定的资源，此时会造成这些任务永久阻塞，从而出现死锁。例如：

事务 A 获取了行 1 的共享锁。
事务 B 获取了行 2 的共享锁。
现在，事务 A 请求行 2 的排他锁，但在事务 B 完成并释放其对行 2 持有的共享锁之前被阻塞。
现在，事务 B 请求行 1 的排他锁，但在事务 A 完成并释放其对行 1 持有的共享锁之前被阻塞。

事务 B 完成之后事务 A 才能完成，但是事务 B 由事务 A 阻塞。该条件也称为循环依赖关系：事务 A 依赖于事务 B，事务 B 通过对事务 A 的依赖关系关闭循环。

除非某个外部进程断开死锁，否则死锁中的两个事务都将无限期等待下去。 Microsoft SQL Server 数据库引擎死锁监视器定期检查陷入死锁的任务。如果监视器检测到循环依赖关系，将选择其中一个任务作为牺牲品，然后终止其事务并提示错误。这样，其他任务就可以完成其事务。对于事务以错误终止的应用程序，它还可以重试该事务，但通常要等到与它一起陷入死锁的其他事务完成后执行。

2. 死锁检测

2.1 SQL Server 数据库引擎自动检测 SQL Server 中的死锁循环。数据库引擎选择一个会话作为死锁牺牲品，然后终止当前事务（出现错误）来打断死锁。

2.2 查看DMV: sys.dm_tran_locks

2.3 SQL Server Profiler能够直观的显示死锁的图形事件.

三: 锁兼容性

锁兼容性控制多个事务能否同时获取同一资源上的锁。如果资源已被另一事务锁定，则仅当请求锁的模式与现有锁的模式相兼容时，才会授予新的锁请求。如果请求锁的模式与现有锁的模式不兼容，则请求新锁的事务将等待释放现有锁或等待锁超时间隔过期。例如，没有与排他锁兼容的锁模式。如果具有排他锁（X 锁），则在释放排他锁（X 锁）之前，其他事务均无法获取该资源的任何类型（共享、更新或排他）的锁。另一种情况是，如果共享锁（S 锁）已应用到资源，则即使第一个事务尚未完成，其他事务也可以获取该项的共享锁或更新锁（U 锁）。但是，在释放共享锁之前，其他事务无法获取排他锁。

四: 总结

锁的原理比较抽象,对用户来说是透明的,不用过多的关注. 应用程序一般不直接请求锁. 锁由数据库引擎的一个部件（称为“锁管理器”）在内部管理. 当数据库引擎实例处理Transact-SQL 语句时, 数据库引擎查询处理器会决定将要访问哪些资源. 查询处理器根据访问类型和事务隔离级别设置来确定保护每一资源所需的锁的类型. 然后, 查询处理器将向锁管理器请求适当的锁. 如果与其他事务所持有的锁不会发生冲突, 锁管理器将授予该锁.

本文链接

SQL Server 2008高可用性(High Availability)简介(3)—Log Shipping

2010-09-13T03:34:00Z

一：简介

日志传送将事务日志不间断地从一个数据库（主数据库）发送到另一个数据库（辅助数据库）。不间断地备份主数据库中的事务日志，然后将它们复制并还原到辅助数据库，这将使辅助数据库与主数据库基本保持同步。目标服务器充当备份服务器，并可以将查询处理从主服务器重新分配到一个或多个只读的辅助服务器。日志传送可与使用完整或大容量日志恢复模式的数据库一起使用。

二：日志传送操作

日志传送由三项操作组成：

在主服务器实例中备份事务日志。
将事务日志文件复制到辅助服务器实例。
在辅助服务器实例中还原日志备份。

日志可传送到多个辅助服务器实例。在这些情况下，将针对每个辅助服务器实例重复执行操作 2 和操作 3。日志传送配置不会自动从主服务器故障转移到辅助服务器。如果主数据库变为不可用，可手动使任意辅助数据库联机。

三：日志传输架构

1.主服务器

作为生产服务器的SQL Server数据库引擎实例。主数据库必须使用完整恢复模式或大容量日志恢复模式，将数据库切换为简单恢复模式会导致日志传送停止工作。

2.辅助服务器

保留主数据库备用副本的服务器。一台辅助服务器可以包含多台不同主服务器中数据库的备份副本。辅助数据库必须通过还原主数据库的完整备份的方法进行初始化。还原时可以使用 NORECOVERY 或 STANDBY 选项。

3.监视服务器

监视服务器是可选的，它可以跟踪日志传送的所有细节，包括：

主数据库中事务日志最近一次备份的时间。
辅助服务器最近一次复制和还原备份文件的时间。
有关任何备份失败警报的信息。

4. 上图所阐释的备份作业、复制作业以及还原作业所执行步骤，如下所示：

主服务器实例执行备份作业以在主数据库上备份事务日志。然后，该服务器实例将日志备份放入主日志备份文件（此文件将被发送到备份文件夹中）。在此图中，备份文件夹位于共享目录（“备份共享”）下。
全部三个辅助服务器实例都执行其各自的复制作业，以将主日志备份文件复制到它本地的目标文件夹中。
每个辅助服务器实例都执行其还原作业，以将日志备份从本地目标文件夹还原到本地辅助数据库中。

5. 四个日志传送作业

备份作业
复制作业
还原作业
警报作业

四：应用实例

下面简单介绍一下日志传输的设置步骤：

1. 主服务器设置

(1) 启用Log Shipping Configuration

右键单击需要配置日志传输的数据库—>Tasks—> Ship Transaction Logs...—>Enable this as a primary database in a log shipping configuration打钩

(2) 点击Backup Setting

建立backup的文件夹,Network path和local path
删除多长时间之前的日志文件
警告,多长时间没有日志备份发出警告
Backup Job Schedule,设置详细的备份时间和周日
压缩选择,一般选择Compress Backup,可以减少网络的IO

2. 辅助服务器设置

(1) 在Secondary databases, 点击Add

(2) 连接到辅助服务器

有三个选项卡:

Initialize Secondary Database，用主数据库的full backup初始化辅助服务器。
Copy Files，在主服务器日志文件备份的位置。
Restore Transaction Log，恢复事务日志选项。

注：可以添加多个辅助服务器。

(3) 警告服务器设置(可选)

以上只是简单的介绍日志传输的设置。

五：总结

使用日志传输模式，一份数据拷贝可以被还原到多个不用的辅助数据库上。一旦主数据库发生故障，可通过还原事务日志到任意辅助数据库联机,或者恢复事务日志到指定的时间点(不支持自动故障转移)。

>>>SQL Server 2008高可用性(High Availability)系列入口地址

本文链接

SQL Server 2008高可用性(High Availability)简介(2)—Database Snapshots

2010-09-08T04:35:00Z

一：简介

数据库快照是数据库（源数据库）的只读、静态视图。多个快照可以位于一个源数据库中，并且可以作为数据库始终驻留在同一服务器实例上。创建快照时，每个数据库快照在事务上与源数据库一致。在被数据库所有者显式删除之前，快照始终存在。

快照可用于报表。另外，如果源数据库出现用户错误，还可将源数据库恢复到创建快照时的状态。丢失的数据仅限于创建快照后数据库更新的数据。

运行原理: 数据库快照在数据页级运行。在第一次修改源数据库页之前，先将原始页从源数据库复制到快照。此过程称为“写入时复制操作”。快照将存储原始页，保留它们在创建快照时的数据记录。对已修改页中的记录进行后续更新不会影响快照的内容。对要进行第一次修改的每一页重复此过程。这样，快照将保留自创建快照后经修改的所有数据记录的原始页。

注：只有 SQL Server 2005 Enterprise Edition 和更高版本才提供数据库快照功能，所有恢复模式都支持数据库快照。

二：数据库快照的典型用法及工作方式

1. 数据库快照的典型用法:

维护历史数据以生成报表。
使用为了实现可用性目标而维护的镜像数据库来减轻报表负载。
使数据免受管理失误所带来的影响。
在进行重大更新（例如，大容量更新或架构更改）之前，可创建数据库快照以保护数据。一旦进行了错误操作，可以使用快照将数据库恢复到生成快照时的状态。
使数据免受用户失误所带来的影响。
管理测试数据库

提示:数据库快照与源数据库相关。因此，使用数据库快照还原数据库不能代替备份和还原策略。严格按计划执行备份仍然至关重要。如果必须将源数据库还原到创建数据库快照的时间点，请实施允许您执行该操作的备份策略。

2. 数据库快照的工作方式

了解快照中的稀疏文件：为了存储复制的原始页，快照使用一个或多个“稀疏文件”。最初，稀疏文件实质上是空文件，不包含用户数据并且未被分配存储用户数据的磁盘空间。随着源数据库中更新的页越来越多，文件的大小也不断增长。创建快照时，稀疏文件占用的磁盘空间很少。然而，由于数据库随着时间的推移不断更新，稀疏文件会增长为一个很大的文件。

快照的工作方式：

(1) 写操作

第一次写入时会把原始页页复制到快照。

(2) 读操作

无更新页之前的读过程

有更新页之后的读过程，可以看到快照读取的是创建快照时的那一页。

(3) 较多的读写之后

随着源数据库中更新的页越来越多，拷贝到快照中的页页越来越多，文件的大小也不断增长。

快照保存的是数据更新之前的那份拷贝，所以通过快照读取的数据是数据更新之前的那一份，数据丢失就可以恢复到创建快照的这个时间点。

三：应用实例

1. 快照的命名

创建数据库快照之前，考虑如何命名它们是非常重要的。每个数据库快照都需要一个唯一的数据库名称。为了便于管理，数据库快照的名称可以包含标识数据库的信息，例如：

源数据库的名称。
该新名称用于快照的指示信息。
快照的创建日期和时间、序列号或一些其他的信息（例如一天中的某个时间）以区分给定的数据库上的连续快照。

如：

以6个小时为间隔(06：00-18：00之间)创建快照：

AdventureWorks2008_snapshot_0600
AdventureWorks2008_snapshot_1200
AdventureWorks2008_snapshot_1800

或者不太精确的命名：

AdventureWorks2008_snapshot_morning
AdventureWorks2008_snapshot_noon
AdventureWorks2008_snapshot_evening

2. 创建数据库快照

语法示例：

CREATE DATABASE AdventureWorks2008_dbss1800 ON ( NAME = AdventureWorks2008_Data, FILENAME = ‘D:\DATA\AdventureWorks2008_data_1800.ss' )

AS SNAPSHOT OF AdventureWorks2008;

.Snapshot Name: AdventureWorks2008_dbss1800

.NAME: source database data file name

.FILENAME: snapshot sparse file name

3. 删掉数据库快照

DROP DATABASE AdventureWorks2008_dbss1800

四：数据库快照的限制

1. 对源数据库的限制

不能对数据库进行删除、分离或还原。
源数据库的性能受到影响。由于每次更新页时都会对快照执行“写入时复制”操作，导致源数据库上的 I/O 增加。
不能从源数据库或任何快照中删除文件。
源数据库必须处于联机状态，除非该数据库在数据库镜像会话中是镜像数据库。
不能将源数据库配置为可缩放共享数据库。
若要在镜像数据库中创建数据库快照，数据库必须处于同步镜像状态。

2. 数据库快照的限制

数据库快照必须与源数据库在相同的服务器实例上创建和保留。
始终对整个数据库拍摄数据库快照。
数据库快照与源数据库相关。因此，使用数据库快照还原数据库不能代替备份和还原策略。严格按计划执行备份仍然至关重要。如果必须将源数据库还原到创建数据库快照的时间点，请实施允许您执行该操作的备份策略。
当将源数据库中更新的页强制压入快照时，如果快照用尽磁盘空间或者遇到其他错误，则该快照将成为可疑快照并且必须将其删除。
快照为只读。
禁止对 model 数据库、master 数据库和 tempdb 数据库创建快照。
不能从数据库快照中删除文件。
不能备份或还原数据库快照。
不能附加或分离数据库快照。

注：更多的限制请参照MSDN。

四:总结

数据库快照只是提供数据恢复的一种方式，在遇到灾难发生时，数据可以恢复到创建快照的那个时间点。恢复操作可以恢复最近出现的严重用户错误，如删除表等。不能代替完整的备份还原策略。

>>>SQL Server 2008高可用性(High Availability)系列入口地址

本文链接

SQL Server 2008高可用性(High Availability)简介(1)—概述

2010-09-07T02:35:00Z

一：高可用性简介

今天越来越多的公司都希望一部分或者所有的关键数据是高可用性的。比如在线交易支付系统，在线订单销售系统，物流运输管理系统等等需要有"24x7"在线支持服务，否则就有可能会有销售额的减少或者利润的损失。

在理想情况下，关键数据应该一直可用，这样业务系统才会一直处于可用状态，并且不能威胁到可用性。但是在实际情况下，会有很多的异常情况导致数据不可用（如DB异常挂掉，数据操作误删，Server软硬件故障等）。因此就要寻求一种可用性的解决方案，来解决由异常带来的数据临时不可用的问题。

和灾难恢复（Disaster Recovery）不同。灾难恢复是在DB发生故障之后（宕机导致数据丢失，数据误删等），通过数据恢复, 使丢失的数据重新可用；高可用性是在数据发生故障之前，为避免对数据的可用性造成影响而使数据处于可用状态的一种解决方案。

二: DOWNTIME和Data Loss的原因

1. 计划内的停工期，不会导致数据丢失

(1) DB维护

数据备份
创建或者重建索引
数据收缩
停机维护(在非工作时间)

(2) 批处理操作

一次查询大量的数据
Table被锁或死锁

(3) DB升级

硬件升级(CPU,RAM,HDD,NetWork…)
软件升级(OS, Microsoft upgrade, SQL Server版本升级)

2. 计划外的停工期，会导致数据丢失

(1) 数据中心故障

会导致整个的系统无法使用

(2) Server故障

软件故障(OS, SQL Server服务启动失效)
硬件故障(CPU, RAM,HDD,NetWork)

(3) IO子系统故障

硬盘故障
RAID控制器故障
IO阻塞

(4) 人为失误

数据误操作

三：高可用性的解决方案

目前我所熟悉的SQL Server 2008提供的高可用性解决方案大致有以下几个，对架构和使用方式做一个总结, 提出一点浅见:

1. Database Snapshots(数据库快照)

2. Log Shipping(日志传送)

3. Database Replication(数据库复制)

4. Database Mirroring(数据库镜像)

5. Failover Clustering(群集故障转移)

--------

SQL Server 2008高可用性(High Availability)简介(1)—概述

SQL Server 2008高可用性(High Availability)简介(2)—Database Snapshots

SQL Server 2008高可用性(High Availability)简介(3)—Log Shipping

SQL Server 2008高可用性(High Availability)简介(4)—Database Replication(计划中...)

SQL Server 2008高可用性(High Availability)简介(5)—Database Mirroring(计划中...)

SQL Server 2008高可用性(High Availability)简介(6)—Failover Clustering(计划中...)

…

本文链接

SQL Server性能调教系列(6)—Index Structure and Tuning

2010-09-06T07:46:00Z

一：前言

Index对数据库性能有着举足轻重的作用。Index设计的优劣直接影响到DB执行的效率。所以在做DB Tuning时，一部分会从Index着手处理，SQL Server也提供了很好的工具Database Engine Tuning Advisor，会给出一些建Index和优化方面的建议。

二：Index概述

这方面在各个博客论坛上面已经讲的比较多了，在此大致总结一下：

1. 数据表的基本结构

当建立一个新表时，系统将在磁盘中分配一段以8K为单位的连续空间；当第一个8K用完的时候，SQL Server指针会自动分配8K的空间。每个8K空间成为一个数据页（Page），又称页面或者数据页面，并分配0-7的页号，每个文件的第0页记录引导信息，叫文件头（File Header）；每8个数据页（64K）的组合形成扩展区（Extent），成为扩展。全部的数据页的组合形成堆（Heap）。

2. 索引的基本概念

建立索引的目的就是提高数据检索效率，改善数据库工作性能，提高数据访问速度。系统表sysindexes存储Index的重要信息。以B-Tree为存储结构。

3. 数据表扫描与索引的使用

没有索引时，访问表的数据时按照Table Scan，平均效率比较低。

建立索引时，访问表的数据时按照Index Scan/Seek，平均效率很高。

4. 聚集索引和非聚集索引(Clustered Index and Non Clustered Index)

相同点：

以B-Tree为存储结构存放的一组数据页
不同阶的节点包含指向另一个阶的数据页
子节点包含所有的键值
在sysindexes中可以找到索引的大小和内容分布
都会提高数据查询的效率

不同点：

叶子节点存放什么：聚集索引存放实际的数据页；非聚集索引存放指针

注意：子叶层级存放的内容不一样。

5. 覆盖索引(Covering Index)

索引覆盖是指建索引的字段正好是覆盖查询条件中所涉及的字段,这里需要注意的是,必须是从第一个开始覆盖。

6. 死锁(DackLock)

请参照

http://www.cnblogs.com/changbluesky/archive/2010/06/10/1753021.html

三：性能简述(Performance)

1. Index碎片

1.1 查询碎片

sys.dm_db_index_physical_stats可以用来检测特定索引、表或索引视图的所有索引、数据库中所有索引或所有数据库中所有索引中的碎片。

重要栏位:

avg_fragmentation_in_percent	逻辑碎片（索引中的无序页）的百分比
fragment_count	索引中的碎片（物理上连续的叶页）数量
avg_fragment_size_in_pages	索引中一个碎片的平均页数

1.2. 重建索引与重组索引(rebuild and reorganize)

无论何时对基础数据执行插入、更新或删除操作，SQL Server 数据库引擎都会自动维护索引。随着时间的推移，这些修改可能会导致索引中的信息分散在数据库中（含有碎片）。当索引包含的页中的逻辑排序（基于键值）与数据文件中的物理排序不匹配时，就存在碎片。碎片非常多的索引可能会降低查询性能，导致应用程序响应缓慢。通过重新组织索引或重新生成索引来修复索引碎片，提高性能。

ALTER INDEX IX_IndexName ON dbo.TableName REBUILD WITH (ONLINE=ON)
ALTER INDEX IX_IndexName ON dbo.TableName REORGANIZE

两种方法的区别：

重新组织索引是通过对叶页进行物理重新排序，使其与叶节点的逻辑顺序（从左到右）相匹配，从而对表或视图的聚集索引和非聚集索引的叶级别进行碎片整理。
重新生成索引将删除该索引并创建一个新索引。此过程中将删除碎片，通过使用指定的或现有的填充因子设置压缩页来回收磁盘空间，并在连续页中对索引行重新排序（根据需要分配新页）。这样可以减少获取所请求数据所需的页读取数，从而提高磁盘性能。

建议根据碎片程度，使用修复碎片的最佳方法：

2. 选择正确而的Index

2.1 主要的考量

以范围查询

常常需要排序的数据

2.2 次要考量

栏位长度要短

会影响所有的非聚集索引
非聚集索引的子也曾都包含所有聚集索引的键值

数据的类型

3.建立索引的方针

所有SQL语法的优先性

优先建立多个查询语法可以共通使用的索引

建立符合索引时，最佳的栏位顺序

四：总结

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

设计良好的索引可以减少磁盘 I/O 操作，并且消耗的系统资源也较少，查询优化器也能够很好的利用索引，提高查询性能。

>>>SQL Server性能调校系列入口地址

本文链接

SQL Server性能调教系列(5)--SQL Server配置

2010-08-16T02:36:00Z

一：前言

在新安装SQL Server 2005/2008之后，我们需要根据Server软硬件设施对SQL Server做一些配置，以至能够发挥较好的性能。但是在大多数情况下还是采取默认的配置。

二：配置

1. Server属性页配置的几个方面

(1).Security

Server登录权限认证：一般都是选择混合认证(SQL Server和Windows身份方式)

(2).Memory/Processors

Automatically set processor affinity mask for all processors:可以设置SQL Server自动分配使用的处理器个数,，如果Server负载很重，最好不要让SQL Server为所有的处理器分配任务，我是建议保留两颗CPU给OS使用。
Automatically set I/O affinity mask for all processors:自动IO均衡

(3).Database Setting

Default index fill factor：很重要的设置，设置页的填充百分比。如果设置80：表示在建立或者重建index时数据页会保留20%的空间供以后的插入或修改使用，这样会产生较少的页分裂，有助于提高性能。
Compress backup选项：在Server备份是会使用compress，减少IO，但会增加CPU的操作。

(4).Connection

Maximum number of concurrent connection:设置最大的连接数
Use query governor prevent long-running queries:用查询管理器阻止耗时的查询
Allow remote connections to this server:默认是勾选的

2：SQL Server Configuration Manage(SQL Server 2008企业版)

(1). SQL Server Services

开始，暂停，重启或停止服务
设置服务启动的方式(Automatic, Disable, Manual)
也可以设置启动的账户
配置启动参数

另：SQL Server服务中可以设置FILESTREAM属性

(2). SQL Server Network Configuration

Shared Memory：是可供使用的最简单协议，没有可配置的设置。由于Shared Memory 协议的客户端仅可以连接到同一台计算机上运行的 SQL Server 实例，因此它对于大多数数据库活动而言是没用的。
TCP/IP ：TCP/IP 是 Internet 上广泛使用的通用协议。它与互连网络中硬件结构和操作系统各异的计算机进行通信。TCP/IP 包括路由网络流量的标准，并能够提供高级安全功能。它是目前在商业中最常用的协议。
Named Pipes ：是为局域网而开发的协议。内存的一部分被某个进程用来向另一个进程传递信息，因此一个进程的输出就是另一个进程的输入。第二个进程可以是本地的（与第一个进程位于同一台计算机上），也可以是远程的（位于联网的计算机上）。
VIA：虚拟接口适配器 (VIA) 协议和 VIA 硬件一同使用。不推荐使用 VIA 协议。后续版本的 Microsoft SQL Server 将删除该功能。

建议：通常，TCP/IP 在慢速 LAN、WAN 或拨号网络中效果较好。而当网络速度不成问题时，Named Pipes 则是更好的选择，因为其功能更强、更易于使用并具有更多的配置选项。

(3). SQL Native Client 10.0 Configuration

Client Protocols
Aliases

协议同（2），可以指定更多的配置。

3. sp_configure/reconfigure

显示或更改当前服务器的全局配置设置，许多配置需要通过sp_configure来是设置。

语法：

sp_configure [ [ @configname = ] 'option_name'
[ , [ @configvalue = ] 'value' ] ]

reconfigure

如:

若要用 sp_configure 配置高级选项，必须首先在 "show advanced options" 选项设置为 1 的情况下运行 sp_configure，然后运行 RECONFIGURE：

sp_configure 'show advanced option', '1';
reconfigure

应用分布式查询:

sp_configure 'Ad Hoc Distributed Queries','1'
reconfigure

四：总结

SQL配置会涉及到好多的方面, 本人功力有限只能简单的说几个,以后发现多了,在分享出来.

>>>SQL Server性能调校系列入口地址

本文链接

SQL Server性能调教系列(4)--Profiler(下)

2010-08-04T00:16:00Z

接上篇:

SQL Server性能调教系列(4)--Profiler(上)

3.分析跟踪记录

在跟踪了一段时间之后，在文件中就会保存有跟踪的数据(包括IO，Duration，CPU，Reads，Writes，RowCounts等计数器)，接下来就是把跟踪的数据加载到表并分析这些数据。可以选择在Profile中打开并检查这些跟踪数据，会有些限制，如不能完成太多的操作，大量重复的SQL语句，没有汇总。

3.1 加载数据到表(使用函数fn_trace_gettable返回表格形式的数据，作为范例只选择分析T-SQL代码和Duration查询的运行时间)

select CAST(textdata as nvarchar(max)) as tsql_code,duration
into Workload
from sys.fn_trace_gettable('C:\test\performancetrace_20100802.trc',NULL) as TT

3.2 汇总相同的SQL项

select tsql_code,SUM(duration) as total_duration from workload group by tsql_code(由于我是在Production上面做的trace，考虑到系统的安全性，在此不便透露分析的SQL代码，实在很抱歉，各位朋友如有兴趣可在自己的测试环境中测试，讨论测试的结果)

问题：分组聚合后会看到逻辑上相同(参数不同)的查询会被分到不同的组，因为在筛选器中使用了不同的值。因为这些相同逻辑的SQL会使用相同的执行计划，应该聚合在一起才能准备的分析总的查询运行的时间。

3.3 问题处理方案一(大致分段截取)

通常情况下SQL语句都是Select+栏位，左边有很大一部分是相同的，根据SQL字符的长度，截取前一段来聚合。如取前50,100,150. 方法简单，容易操作,会聚合一部分数据，但是长度不太好取值，只能调整前缀的长度去测试。

select left(tsql_code,50) as t_sql,SUM(duration) as total_duration from workload group by left(tsql_code,50)

--or

select left(tsql_code,100) as t_sql,SUM(duration) as total_duration from workload group by left(tsql_code,100)

--or

select left(tsql_code,150) as t_sql,SUM(duration) as total_duration from workload group by left(tsql_code,150)

3.4 问题处理方案二(复杂，精确，逻辑上相同的SQL，参数用通配符替代)，这个方法是T-SQL查询技术内幕中介绍的方法，如果需要更加详细的说明，请阅读这本书，你会得到更多的启发。

(1) 模式化查询，它对于相同模式的查询是一样的。

T-SQL函数实现

建立函数：

CREATE FUNCTION [dbo].[fn_SQLSigTSQL]
(@p1 NTEXT, @parselength INT = 4000)
RETURNS NVARCHAR(4000)

-- This function will replace the parameters with '#'
-- This function is provided "AS IS" with no warranties,
-- and confers no rights.
-- Use of included script samples are subject to the terms specified at
-- http://www.microsoft.com/info/cpyright.htm
--
-- Strips query strings
AS
BEGIN
DECLARE @pos AS INT;
DECLARE @mode AS CHAR(10);
DECLARE @maxlength AS INT;
DECLARE @p2 AS NCHAR(4000);
DECLARE @currchar AS CHAR(1), @nextchar AS CHAR(1);
DECLARE @p2len AS INT;

SET @maxlength = LEN(RTRIM(SUBSTRING(@p1,1,4000)));
SET @maxlength = CASE WHEN @maxlength > @parselength
THEN @parselength ELSE @maxlength END;
SET @pos = 1;
SET @p2 = '';
SET @p2len = 0;
SET @currchar = '';
set @nextchar = '';
SET @mode = 'command';

WHILE (@pos <= @maxlength)
BEGIN
SET @currchar = SUBSTRING(@p1,@pos,1);
SET @nextchar = SUBSTRING(@p1,@pos+1,1);
IF @mode = 'command'
BEGIN
SET @p2 = LEFT(@p2,@p2len) + @currchar;
SET @p2len = @p2len + 1 ;
IF @currchar IN (',','(',' ','=','<','>','!')
AND @nextchar BETWEEN '0' AND '9'
BEGIN
SET @mode = 'number';
SET @p2 = LEFT(@p2,@p2len) + '#';
SET @p2len = @p2len + 1;
END
IF @currchar = ''''
BEGIN
SET @mode = 'literal';
SET @p2 = LEFT(@p2,@p2len) + '#''';
SET @p2len = @p2len + 2;
END
END
ELSE IF @mode = 'number' AND @nextchar IN (',',')',' ','=','<','>','!')
SET @mode= 'command';
ELSE IF @mode = 'literal' AND @currchar = ''''
SET @mode= 'command';

SET @pos = @pos + 1;
END
RETURN @p2;
END

该函数参数为一个查询字符串和要分析的代码的长度，但会输入查询的签名，并用井号（#）替换所有的参数。测试结果如下：

select dbo.fn_SQLSigTSQL('select * from Sales.SalesOrderHeader where SalesOrderID=''43659'' and Status=''5'' ',500)

CLR实现

CLR在处理迭代/过程逻辑和字符串处理时比T-SQL效率高，下面介绍用CLR实现模式化查询。

a. 建立C#版的Classs Libary，函数如下：

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using Microsoft.SqlServer.Server;
using System.Data.SqlTypes;
using System.Text.RegularExpressions;
public partial class SQLSignature
{
// fn_SQLSigCLR
[SqlFunction(IsDeterministic = true, DataAccess = DataAccessKind.None)]
public static SqlString fn_SQLSigCLR(SqlString querystring)
{
return (SqlString)Regex.Replace(
querystring.Value,
@"([\s,(=<>!](?![^\]]+[\]]))(?:(?:(?:(?# expression coming
)(?:([N])?(')(?:[^']|'')*('))(?# character
)|(?:0x[\da-fA-F]*)(?# binary
)|(?:[-+]?(?:(?:[\d]*\.[\d]*|[\d]+)(?# precise number
)(?:[eE]?[\d]*)))(?# imprecise number
)|(?:[~]?[-+]?(?:[\d]+))(?# integer
))(?:[\s]?[\+\-\*\/\%\&\|\^][\s]?)?)+(?# operators
))",
@"$1$2$3#$4");
}
// fn_RegexReplace - for generic use of RegEx-based replace
[SqlFunction(IsDeterministic = true, DataAccess = DataAccessKind.None)]
public static SqlString fn_RegexReplace(
SqlString input, SqlString pattern, SqlString replacement)
{
return (SqlString)Regex.Replace(
input.Value, pattern.Value, replacement.Value);
}
}

b. 加载.dll中间语言代码到DB

USE master;
CREATE ASSEMBLY SQLSignature
FROM 'C:\SQLSignature\SQLSignature\bin\Debug\SQLSignature.dll';

c. 注册函数fn_SQLSigCLR和fn_RegexReplace

CREATE FUNCTION dbo.fn_SQLSigCLR(@querystring AS NVARCHAR(MAX))
RETURNS NVARCHAR(MAX)
WITH RETURNS NULL ON NULL INPUT
EXTERNAL NAME SQLSignature.SQLSignature.fn_SQLSigCLR;
GO

CREATE FUNCTION dbo.fn_RegexReplace(
@input AS NVARCHAR(MAX),
@pattern AS NVARCHAR(MAX),
@replacement AS NVARCHAR(MAX))
RETURNS NVARCHAR(MAX)
WITH RETURNS NULL ON NULL INPUT
EXTERNAL NAME SQLSignature.SQLSignature.fn_RegexReplace;
GO

d. 注册完成之后，用下面代码测试：

SELECT
dbo.fn_SQLSigCLR(tsql_code) AS sig_sql,
duration
FROM dbo.Workload;

结果的SQL全被模式化，井号(#)替代所有的参数。

(2) 以用上面建立的函数，模式化追踪的T-SQL语句，并分类汇总。

a. 以用查询签名，为每个字符串生成整数的校验和（CheckSum）,方便以后的汇总计算，提高效率：

ALTER TABLE dbo.Workload ADD cs INT NOT NULL DEFAULT (0);
GO
UPDATE dbo.Workload
SET cs = CHECKSUM(dbo.fn_SQLSigCLR(tsql_code));

CREATE CLUSTERED INDEX idx_cl_cs ON dbo.Workload(cs);

b. 用每个签名的检验和计算运行时间填充临时表#AggQueries，包括运行时间的百分比，以及运行时间降序的行号。

IF OBJECT_ID('tempdb..#AggQueries') IS NOT NULL
DROP TABLE #AggQueries;
GO

SELECT cs, SUM(duration) AS total_duration,
100. * SUM(duration) / SUM(SUM(duration)) OVER() AS pct,
ROW_NUMBER() OVER(ORDER BY SUM(duration) DESC) AS rn
INTO #AggQueries
FROM dbo.Workload
GROUP BY cs;

CREATE CLUSTERED INDEX idx_cl_cs ON #AggQueries(cs);

查询聚合之后临时表的内容，数据量会大大的减少，包含签名，总的运行时间，运行时间占总运行时间的半分比，排序序号。

c.筛选并匹配，使用APPLY运算符得到查询模式和一个示例查询。

WITH RunningTotals AS
(
SELECT AQ1.cs,
CAST(AQ1.total_duration / 1000.
AS DECIMAL(12, 2)) AS total_s,
CAST(SUM(AQ2.total_duration) / 1000.
AS DECIMAL(12, 2)) AS running_total_s,
CAST(AQ1.pct AS DECIMAL(12, 2)) AS pct,
CAST(SUM(AQ2.pct) AS DECIMAL(12, 2)) AS run_pct,
AQ1.rn
FROM #AggQueries AS AQ1
JOIN #AggQueries AS AQ2
ON AQ2.rn <= AQ1.rn
GROUP BY AQ1.cs, AQ1.total_duration, AQ1.pct, AQ1.rn
HAVING SUM(AQ2.pct) - AQ1.pct <= 90 -- percentage threshold
)
SELECT RT.rn, RT.pct, S.sig, S.tsql_code AS sample_query
FROM RunningTotals AS RT
CROSS APPLY
(SELECT TOP(1) tsql_code, dbo.fn_SQLSigCLR(tsql_code) AS sig
FROM dbo.Workload AS W
WHERE W.cs = RT.cs) AS S
ORDER BY RT.rn;

4. 有了查询模式，示例查询，和占用时间的百分比例和排序。然后就可以着手优化。也可以通过类似的方式，找到造成大量结果集，大多数的I/O问题的查询模式。

四：总结

Perfiler是一个很好用的工具来追踪系统的性能和工作的负荷，从而准确的找到值得优化的SQL，提高效率，大大减少工作量。

附件下载:Server性能计数器.rar

PerformanceMonitor.rar

参考：Microsoft SQL Server 2005技术内幕：T-SQL查询

>>>SQL Server性能调校系列入口地址

本文链接

SQL Server性能调教系列(4)--Profiler(上)

2010-08-03T08:03:00Z

一：简介

在处理性能问题是，DBA倾向于关注系统技术层面，如资源队列，资源利用率，系统loading等。而用户只把性能问题认为是等待，他们从业务逻辑层面发出一个请求，等待返回结果，后台数据库就需要去响应这个请求。从用户角度来看，一般认为等待三秒才返回就属于性能问题（特殊的系统除外：比如需要大量的数据操作），他们并不关心系统的数据层，比如有多少个命令在等待处理，CPU利用率，RAM使用率等。在遇到这些问题之后，我们需要找到这个问题，请着手优化，找到合理的解决方案。

注：硬件方面的问题请参照系列（2）

SQL Server性能调教系列(2)--Server Performance Monitor(Perfmon)

二：理论

要做优化，首先要找出需要优化的部分（如找到效率低的SQL或SP等），引用SQL技术内幕中介绍的优化步骤：

1.分析实例级的等待

2.联系等待的队列

3.确定方案

4.细化到数据库/文件级

5.细化到进程级

6.优化索引/查询

三：方法

本章主要介绍Profiler工具来跟踪性能工作负荷。

1. Profiler简介

通过SQL Server—>Tools—>SQL Server Profiler启动

General页：跟踪的记录有两种保存方式:保存到文件和保存到表。通常选择保存到文件，因为保存到表会增加较多的额外系统开销。

Events Selection页：能够选择跟踪的事件。更多的跟踪事件请参考MSDN。

注：

不要使用GUI跟踪，应该使用T-SQL。因为使用GUI会有两个跟踪，一个把跟踪信息写入目标文件，一个把跟踪信息写入运行的GUI，会增加系统的额外开销。
不要把跟踪直接写入到表，这样会严重影响性能，把文件写到磁盘是最快的方案。
跟踪会产生大量和额外的IO操作。不要把跟踪文件放到包含数据库文件（如数据，日志和tempdb）的磁盘上。
选择事件类的数据列，只跟踪需要的信息。
使用跟踪筛选需要的事件。

2.启动跟踪

2.1 可以先在GUI中设置需要跟踪的事件类，然后在导出脚本(File—>Export-->Script Trace Definition)，通常筛选Duration数列大于某些值(比如3000毫秒)的事件来跟踪运行得比较慢的进程。

如:导出的脚本如下,这里把trace的脚本整理为一个存储过程,以方便执行.

CREATE PROC [dbo].[sp_perfworkload_trace_start]
@dbid AS INT,
@tracefile AS NVARCHAR(254),
@traceid AS INT OUTPUT
AS
-- Create a Queue
DECLARE @rc AS INT;
DECLARE @maxfilesize AS BIGINT;

SET @maxfilesize = 100;

EXEC @rc = sp_trace_create @traceid OUTPUT, 0, @tracefile, @maxfilesize, NULL
IF (@rc != 0) GOTO error;

-- Client side File and Table cannot be scripted

-- Set the events
DECLARE @on AS BIT;
SET @on = 1;
EXEC sp_trace_setevent @traceid, 10, 15, @on;
EXEC sp_trace_setevent @traceid, 10, 8, @on;
EXEC sp_trace_setevent @traceid, 10, 16, @on;
EXEC sp_trace_setevent @traceid, 10, 48, @on;
EXEC sp_trace_setevent @traceid, 10, 1, @on;
EXEC sp_trace_setevent @traceid, 10, 17, @on;
EXEC sp_trace_setevent @traceid, 10, 10, @on;
EXEC sp_trace_setevent @traceid, 10, 18, @on;
EXEC sp_trace_setevent @traceid, 10, 11, @on;
EXEC sp_trace_setevent @traceid, 10, 12, @on;
EXEC sp_trace_setevent @traceid, 10, 13, @on;
EXEC sp_trace_setevent @traceid, 10, 14, @on;
EXEC sp_trace_setevent @traceid, 45, 8, @on;
EXEC sp_trace_setevent @traceid, 45, 16, @on;
EXEC sp_trace_setevent @traceid, 45, 48, @on;
EXEC sp_trace_setevent @traceid, 45, 1, @on;
EXEC sp_trace_setevent @traceid, 45, 17, @on;
EXEC sp_trace_setevent @traceid, 45, 10, @on;
EXEC sp_trace_setevent @traceid, 45, 18, @on;
EXEC sp_trace_setevent @traceid, 45, 11, @on;
EXEC sp_trace_setevent @traceid, 45, 12, @on;
EXEC sp_trace_setevent @traceid, 45, 13, @on;
EXEC sp_trace_setevent @traceid, 45, 14, @on;
EXEC sp_trace_setevent @traceid, 45, 15, @on;
EXEC sp_trace_setevent @traceid, 41, 15, @on;
EXEC sp_trace_setevent @traceid, 41, 8, @on;
EXEC sp_trace_setevent @traceid, 41, 16, @on;
EXEC sp_trace_setevent @traceid, 41, 48, @on;
EXEC sp_trace_setevent @traceid, 41, 1, @on;
EXEC sp_trace_setevent @traceid, 41, 17, @on;
EXEC sp_trace_setevent @traceid, 41, 10, @on;
EXEC sp_trace_setevent @traceid, 41, 18, @on;
EXEC sp_trace_setevent @traceid, 41, 11, @on;
EXEC sp_trace_setevent @traceid, 41, 12, @on;
EXEC sp_trace_setevent @traceid, 41, 13, @on;
EXEC sp_trace_setevent @traceid, 41, 14, @on;

-- Set the Filters
DECLARE @intfilter AS INT;
DECLARE @bigintfilter AS BIGINT;
-- Application name filter
EXEC sp_trace_setfilter @traceid, 10, 0, 7, N'SQL Server Profiler%';
-- Database ID filter
EXEC sp_trace_setfilter @traceid, 3, 0, 0, @dbid;

-- Set the trace status to start
EXEC sp_trace_setstatus @traceid, 1;

-- Print trace id and file name for future references
PRINT 'Trce ID: ' + CAST(@traceid AS VARCHAR(10))
+ ', Trace File: ''' + @tracefile + '''';

GOTO finish;

error:
PRINT 'Error Code: ' + CAST(@rc AS VARCHAR(10));

finish:

2.2 用以下T-SQL代码启动跟踪：

declare @dbid int,@traceid int;
set @dbid=DB_ID()---可以为默认的DB，或者DB_ID('Your_dbname')
EXEC sp_perfworkload_trace_start @dbid,'C:\test\performancetrace_20100802.trc',@traceid output

执行之后会显示出traceid，请记住这个traceid，会用它来停止和关闭追踪。

Trce ID: 2, Trace File: 'C:\test\performancetrace_20100802.trc'

2.3 停止和关闭追踪(sp_trace_setstatus,如果traceid是2，则停止和关闭的代码如下)：

EXEC sp_trace_setstatus 2,0
EXEC sp_trace_setstatus 2,2

2.4

如果忘记traceid，可以在查询试图sys.traces找到。

接下篇:

SQL Server性能调教系列(4)--Profiler(下)

>>>SQL Server性能调校系列入口地址

本文链接