性能监控列表
输入你的结果到上表
每一个数据库都需要监控
作为性能监控的一部分，你需要检查你服务器上的每一个数据库和一些基本的数据库设置。和这套监控列表的其他监控相比，你会发现该监控是最容易的。为了方便，你可以将你要监控的每个数据库做一个上表的副本。
作为数据库设置监控的一部分，我们来看看数据库选项和数据库配置设置之间的不同。在以前的性能监控列表中，我们仅仅着眼于那些直接和 性能相关的数据库设置，而忽略了其余部分。
数据库选项和数据库配置设置都能使用企业管理器查看和修改（我偏好它，因为简单），或者用ALTER DATABASE命令修改。另外，仅对于数据 库选项而言，还可以使用sp_dboption系统存储过程去查看和修改它们，但微软正试图逐步淘汰这个命令，到SQLServer2000为止，以后可能不 再支持。
数据库设置性能监控列表的第一部分是数据库选项，第二部分着眼于数据库配置设置。
查看数据库选项
在这一部分，我们将仅仅察看以某种方式影响性能的众多数据库选项中的6个。察看目前设置的最好方法是用企业管理器，步骤如下（假定用的 是sqlserver2000）：
Auto_Close
这个数据库选项是为SQLServer7.0和2000的桌面版本设计的，而不是为服务版本。因此，它将不会被打开（缺省也不是打开的）。该选项所要 做的就是在最后一个数据库用户从数据库断开连接时关闭数据库。当一个连接在数据库关闭后要求访问它时，数据库不得不重新打开，这会花 费时间。
这样有个问题就是：如果数据库被频繁的访问（这是经常的情况），那么数据库会不断的关闭重新打开，这样应用程序或用户在连接时会很大 的影响SQLServer的性能。
作为监控的一部分，如果你发现这个选项被打开，而你又使用的不是桌面版，那么你需要找出原因。如果你找不到原因，或者原因很少，那么 关闭该选项。
Auto_Create_Statistics
当auto_create_statistics打开时（缺省也是打开的），查询的Where子句用到的所有列上会自动创建统计。这发生在查询被查询优化器第一次优化时，假定这列还没有创建统计。所有的列统计能极大的帮助查询优化器，以便它能为查询创建一个优化的执行计划。
如果该选项关闭，那么丢失的列统计不会自动创建，这就意味着当查询优化器不能为查询产生优化的执行计划时，查询的性能将受到影响。如果你原意，你仍然可以手工创建列统计，即使该选项被关闭。
使用该选项真正没有负面的影响。恰好第一次列统计被创建，这将在查询第一次运行前花很短的时间，从而引起查询潜在的花费更长一点的时间运行。但一旦列统计已经创建，每次运行同样的查询时，都将比第一次不存在统计时更有效率。
作为监控的一部分，如果你发现这个选项被关闭，你需要找出原因。如果你不能找到原因，或者原因很少，那么打开这个选项。
Auto_Update_Statistics
为了使查询优化器做出更快的查询优化决策，列和索引统计需要更新。确保它的最好方法是打开数据库选项auto_update_statistics（缺省也是打开的）。这能帮助确保优化器统计是有效的，帮助确保查询运行时是被完全优化的。
但这个选项不是万能的。当SQLServer数据库在繁重的负载之下，有时auto_update_statistics可能在不恰当的时候更新一个大表的统计，如一天最忙的时候。
如果你发现auto_update_statistics在不恰当的时候运行了，你也许要关闭它，然后在数据库不繁忙的时候手工更新统计（使用UPDATE STATISTICS）。
但是还要考虑的一点是如果关闭auto_update_statistics选项将发生的事情。关闭该选项也许会在一天中不恰当的时候不运行统计更新来减少你服务器的压力，它也能引起你的一些查询得不到正确的优化，从而在繁忙的时候引起服务器的另一些压力。
象其他优化问题一样，你可能要通过试验来看开关这个选项是否对你的环境更有效。但是首要的原则是，如果你的服务器不是最繁忙的，那么打开该选项也许是最好的选择。
Auto_Shrink
一些数据库需要周期性的收缩以便删除数据库旧的数据来释放磁盘空间。但不要企图用auto_shrink数据库选项，这可能浪费不必要的数据库资源。
auto_shrink选项缺省是关闭的，这意味着只有一个方法去释放数据库里的空的空间，那就是手动去做。如果打开该选项，SQLServer将每隔30分钟检查看看是否需要收缩数据库。这样不仅使使用的资源上升（这些资源本来可以在别处得到更好的利用），也可能当auto_shrink进程在最繁忙的时间启动并工作时引起不可预料的瓶颈。
如果你需要周期性的收缩数据库，使用DBCC SHRINKDATABASE或者DBCC SHRINKFILE命令手工执行这一步或者使用SQLServer代理或创建一个数据库维护计划在不忙的时候进行周期性的调度。
作为监控的一部分，如果你发现该选项是打开的，你需要找出原因。如果找不到或者原因很少，那么关闭该选项。
Read_Only
如果一个数据库仅为了只读目的，如为了报表，那么考虑设置read_only选项（缺省是关闭的）。这将除去那些资源利用多的锁，潜在的轮流提升它上面运行的查询的性能。如果你很少更改数据库，那么关闭该选项，当要更改的时候再打开。
Torn_Page_Detection
由于SQLServer的数据页面（8K）和NT Server或者Windows Server（512字节）是不同的尺寸，可能在电源故障或者磁盘驱动、物理磁盘问题时数据库会变得不完整。
下面是原因。每当操作系统写一个SQLServer的8K数据页到磁盘时，都必须把数据分成多个512字节的页面。在第一个512字节的数据写完后，SQLServer假定整个8K的页面已被成功写入磁盘。所以如果在8K的SQLServer页面分成的所有512字节的页面写入磁盘之前出现了电源故障，那么SQLServer不知道发生了什么事情。这被称为残缺页。
正如你所想象的那样，这损坏了数据页面，也损坏了整个数据库。没有办法将数据库损坏的原因归结到残缺页，除非通过一个已知完好的备份备份恢复。防止这个问题的最好的方法之一就是确保服务器有一个备用电池。但这不能防止所有的问题，因为一个有缺陷的磁盘驱动也能引起类似问题（我曾经见过）。
如果你担心SQLServer数据库出现残缺页问题，你能让SQLServer告诉你他们是否发生（尽管这不能防止问题发生，也不能事后修正它们）。有一个数据库选项叫做"torn page detection"能在数据库级打开或者关闭。如果该选项打开，且如果发现了残缺页，那么数据库会被标记为不完整，且你基本上没有什么选择余地只能用你最近的备份恢复你的数据库。
在SQLServer7.0里，这个选项缺省是关闭的，且你必须为你要在上面用这个选项的每一个数据库上打开。在SQLServer2000里，这个选项默认是为所有数据库打开的。
那么最大的问题是：为什么不只打开它而变得安全呢？这个问题的原因在于打开该选项会影响SQLServer的性能。 你记住的不要太多，仅仅记住一点，如果你的SQLServer有很高性能问题，那么关闭该选项可能有一个明显的区别。作为一个DBA，你必须在是否使用该选项上做出决定，为你的特别的环境做出决定。
查看数据库配置设置
这一节我们将只查看三个数据库配置设置，检查它们是怎样影响性能的。查看它们最好的方法是用企业管理器，参考下面的步骤（这些步骤适合于SQLServer2000）：
Compatibility Level
SQLServer7.0和2000有一个数据库兼容模式，允许为以前版本的SQLServer写的应用程序在7.0或者2000下允许。在你想要最大化你数据库的性能里，你不要在兼容模式下运行你的数据库（不是所有新的性能相关的特征都被支持）。
相反，你的数据库应该运行在本来的SQLServer7.0或者2000模式下（依赖于你目前运行的版本）。当然，这会要求你修改你的应用程序使其适应SQLServer7.0或2000，但大多数情况下，这些额外的又是必须的升级应用程序的工作将对提升性能有更多的回报。
SQLServer7.0的兼容级别是70，2000的兼容级别是80。
Database and Transaction Log Auto Grow
我们将一起讨论数据库自动增长和事务日志自动增长，因为它们关联得很近。
如果你设置SQLServer7.0或2000的数据库和事务日志自动增长（缺省也是），记住每当这个选项起作用时，它将花费一些额外的CPU和I/O。理论上，我们应尽量减少自动增长发生的频率以便减少不必要的性能负担。
一个有用的方法时尽可能精确的度量数据库最终的大小。当然，事实上要得到正确的目的几乎是不可能的。但如果估计得越精确（有时得到这个好的估计要花费一些时间），sqlserver不得不自动增长数据库和事务日志就会越少，有助于提升你应用程序的性能。
下面一些对事务日志的独特建议是重要的。这是因为很多时候SQLServer不得不增长事务日志的大小，SQLServer不得不创建和维护更多的事务日志文件，当需要恢复事务日志时会增加恢复时间。一个被SQLServer使用的事务文件本质上被分成多个物理事务日志文件管理。
缺省的自动增长比例为数据库和事务日志的10％。这个自动增长数字对你的数据库和事务日志也许有好有坏。如果你发现数据库和日志经常自动增长（比如一天一次或者一周几次），那么改变这个增长百分比到一个较大的数字，如20％或30％。每次数据库或日志增长时，SQLServer都将有一个小的性能下降。通过增加每次数据库增长的数量，让增长不是很频繁的发生。
如果你的数据库很大，10G或者更大，你也许要用一个固定的增长量来代替百分比增长量。这是因为百分比增长量在一个大数据库上会变得很大。例如在一个10G的数据库上一个10％增长率意味着当数据库增长时，要增长1G。这也许是或不是你所要的。如果这超过了你的需求，那么选择每次增长一个固定增长量如100M，也许更合适。
作为监控的一部分，你需要小心估计你的数据库看上面的建议是否适合它们，然后做出正确的选择。
| 数据库配置选项 | 缺省值 | 当前值 |
| auto_close | off | |
| auto_create_statistics | on | |
| auto_update_statistics | on | |
| auto_shrink | off | |
| read_only | off | |
| torn_page_detection | on in 2000 off in 7.0 | |
| compatibility level | 80 for 2000 70 for 7.0 | |
| database auto grow | on | |
| transaction log auto grow | on |
输入你的结果到上表
每一个数据库都需要监控
作为性能监控的一部分，你需要检查你服务器上的每一个数据库和一些基本的数据库设置。和这套监控列表的其他监控相比，你会发现该监控是最容易的。为了方便，你可以将你要监控的每个数据库做一个上表的副本。
作为数据库设置监控的一部分，我们来看看数据库选项和数据库配置设置之间的不同。在以前的性能监控列表中，我们仅仅着眼于那些直接和 性能相关的数据库设置，而忽略了其余部分。
数据库选项和数据库配置设置都能使用企业管理器查看和修改（我偏好它，因为简单），或者用ALTER DATABASE命令修改。另外，仅对于数据 库选项而言，还可以使用sp_dboption系统存储过程去查看和修改它们，但微软正试图逐步淘汰这个命令，到SQLServer2000为止，以后可能不 再支持。
数据库设置性能监控列表的第一部分是数据库选项，第二部分着眼于数据库配置设置。
查看数据库选项
在这一部分，我们将仅仅察看以某种方式影响性能的众多数据库选项中的6个。察看目前设置的最好方法是用企业管理器，步骤如下（假定用的 是sqlserver2000）：
- 在企业管理器里，展开所有的数据库。
- 右击你要察看的数据库，选择属性。
- 在属性对话框里选择选项标签。
Auto_Close
这个数据库选项是为SQLServer7.0和2000的桌面版本设计的，而不是为服务版本。因此，它将不会被打开（缺省也不是打开的）。该选项所要 做的就是在最后一个数据库用户从数据库断开连接时关闭数据库。当一个连接在数据库关闭后要求访问它时，数据库不得不重新打开，这会花 费时间。
这样有个问题就是：如果数据库被频繁的访问（这是经常的情况），那么数据库会不断的关闭重新打开，这样应用程序或用户在连接时会很大 的影响SQLServer的性能。
作为监控的一部分，如果你发现这个选项被打开，而你又使用的不是桌面版，那么你需要找出原因。如果你找不到原因，或者原因很少，那么 关闭该选项。
Auto_Create_Statistics
当auto_create_statistics打开时（缺省也是打开的），查询的Where子句用到的所有列上会自动创建统计。这发生在查询被查询优化器第一次优化时，假定这列还没有创建统计。所有的列统计能极大的帮助查询优化器，以便它能为查询创建一个优化的执行计划。
如果该选项关闭，那么丢失的列统计不会自动创建，这就意味着当查询优化器不能为查询产生优化的执行计划时，查询的性能将受到影响。如果你原意，你仍然可以手工创建列统计，即使该选项被关闭。
使用该选项真正没有负面的影响。恰好第一次列统计被创建，这将在查询第一次运行前花很短的时间，从而引起查询潜在的花费更长一点的时间运行。但一旦列统计已经创建，每次运行同样的查询时，都将比第一次不存在统计时更有效率。
作为监控的一部分，如果你发现这个选项被关闭，你需要找出原因。如果你不能找到原因，或者原因很少，那么打开这个选项。
Auto_Update_Statistics
为了使查询优化器做出更快的查询优化决策，列和索引统计需要更新。确保它的最好方法是打开数据库选项auto_update_statistics（缺省也是打开的）。这能帮助确保优化器统计是有效的，帮助确保查询运行时是被完全优化的。
但这个选项不是万能的。当SQLServer数据库在繁重的负载之下，有时auto_update_statistics可能在不恰当的时候更新一个大表的统计，如一天最忙的时候。
如果你发现auto_update_statistics在不恰当的时候运行了，你也许要关闭它，然后在数据库不繁忙的时候手工更新统计（使用UPDATE STATISTICS）。
但是还要考虑的一点是如果关闭auto_update_statistics选项将发生的事情。关闭该选项也许会在一天中不恰当的时候不运行统计更新来减少你服务器的压力，它也能引起你的一些查询得不到正确的优化，从而在繁忙的时候引起服务器的另一些压力。
象其他优化问题一样，你可能要通过试验来看开关这个选项是否对你的环境更有效。但是首要的原则是，如果你的服务器不是最繁忙的，那么打开该选项也许是最好的选择。
Auto_Shrink
一些数据库需要周期性的收缩以便删除数据库旧的数据来释放磁盘空间。但不要企图用auto_shrink数据库选项，这可能浪费不必要的数据库资源。
auto_shrink选项缺省是关闭的，这意味着只有一个方法去释放数据库里的空的空间，那就是手动去做。如果打开该选项，SQLServer将每隔30分钟检查看看是否需要收缩数据库。这样不仅使使用的资源上升（这些资源本来可以在别处得到更好的利用），也可能当auto_shrink进程在最繁忙的时间启动并工作时引起不可预料的瓶颈。
如果你需要周期性的收缩数据库，使用DBCC SHRINKDATABASE或者DBCC SHRINKFILE命令手工执行这一步或者使用SQLServer代理或创建一个数据库维护计划在不忙的时候进行周期性的调度。
作为监控的一部分，如果你发现该选项是打开的，你需要找出原因。如果找不到或者原因很少，那么关闭该选项。
Read_Only
如果一个数据库仅为了只读目的，如为了报表，那么考虑设置read_only选项（缺省是关闭的）。这将除去那些资源利用多的锁，潜在的轮流提升它上面运行的查询的性能。如果你很少更改数据库，那么关闭该选项，当要更改的时候再打开。
Torn_Page_Detection
由于SQLServer的数据页面（8K）和NT Server或者Windows Server（512字节）是不同的尺寸，可能在电源故障或者磁盘驱动、物理磁盘问题时数据库会变得不完整。
下面是原因。每当操作系统写一个SQLServer的8K数据页到磁盘时，都必须把数据分成多个512字节的页面。在第一个512字节的数据写完后，SQLServer假定整个8K的页面已被成功写入磁盘。所以如果在8K的SQLServer页面分成的所有512字节的页面写入磁盘之前出现了电源故障，那么SQLServer不知道发生了什么事情。这被称为残缺页。
正如你所想象的那样，这损坏了数据页面，也损坏了整个数据库。没有办法将数据库损坏的原因归结到残缺页，除非通过一个已知完好的备份备份恢复。防止这个问题的最好的方法之一就是确保服务器有一个备用电池。但这不能防止所有的问题，因为一个有缺陷的磁盘驱动也能引起类似问题（我曾经见过）。
如果你担心SQLServer数据库出现残缺页问题，你能让SQLServer告诉你他们是否发生（尽管这不能防止问题发生，也不能事后修正它们）。有一个数据库选项叫做"torn page detection"能在数据库级打开或者关闭。如果该选项打开，且如果发现了残缺页，那么数据库会被标记为不完整，且你基本上没有什么选择余地只能用你最近的备份恢复你的数据库。
在SQLServer7.0里，这个选项缺省是关闭的，且你必须为你要在上面用这个选项的每一个数据库上打开。在SQLServer2000里，这个选项默认是为所有数据库打开的。
那么最大的问题是：为什么不只打开它而变得安全呢？这个问题的原因在于打开该选项会影响SQLServer的性能。 你记住的不要太多，仅仅记住一点，如果你的SQLServer有很高性能问题，那么关闭该选项可能有一个明显的区别。作为一个DBA，你必须在是否使用该选项上做出决定，为你的特别的环境做出决定。
查看数据库配置设置
这一节我们将只查看三个数据库配置设置，检查它们是怎样影响性能的。查看它们最好的方法是用企业管理器，参考下面的步骤（这些步骤适合于SQLServer2000）：
- 在企业管理器里，显示你的服务器里所有的数据库
- 右击你要查看的数据库，选择属性
- 从属性对话框里，选择选项标签查看兼容级别，选择数据文件标签查看数据库自动增长设置，选择事务日志标签查看事务日志自动增长设置。
Compatibility Level
SQLServer7.0和2000有一个数据库兼容模式，允许为以前版本的SQLServer写的应用程序在7.0或者2000下允许。在你想要最大化你数据库的性能里，你不要在兼容模式下运行你的数据库（不是所有新的性能相关的特征都被支持）。
相反，你的数据库应该运行在本来的SQLServer7.0或者2000模式下（依赖于你目前运行的版本）。当然，这会要求你修改你的应用程序使其适应SQLServer7.0或2000，但大多数情况下，这些额外的又是必须的升级应用程序的工作将对提升性能有更多的回报。
SQLServer7.0的兼容级别是70，2000的兼容级别是80。
Database and Transaction Log Auto Grow
我们将一起讨论数据库自动增长和事务日志自动增长，因为它们关联得很近。
如果你设置SQLServer7.0或2000的数据库和事务日志自动增长（缺省也是），记住每当这个选项起作用时，它将花费一些额外的CPU和I/O。理论上，我们应尽量减少自动增长发生的频率以便减少不必要的性能负担。
一个有用的方法时尽可能精确的度量数据库最终的大小。当然，事实上要得到正确的目的几乎是不可能的。但如果估计得越精确（有时得到这个好的估计要花费一些时间），sqlserver不得不自动增长数据库和事务日志就会越少，有助于提升你应用程序的性能。
下面一些对事务日志的独特建议是重要的。这是因为很多时候SQLServer不得不增长事务日志的大小，SQLServer不得不创建和维护更多的事务日志文件，当需要恢复事务日志时会增加恢复时间。一个被SQLServer使用的事务文件本质上被分成多个物理事务日志文件管理。
缺省的自动增长比例为数据库和事务日志的10％。这个自动增长数字对你的数据库和事务日志也许有好有坏。如果你发现数据库和日志经常自动增长（比如一天一次或者一周几次），那么改变这个增长百分比到一个较大的数字，如20％或30％。每次数据库或日志增长时，SQLServer都将有一个小的性能下降。通过增加每次数据库增长的数量，让增长不是很频繁的发生。
如果你的数据库很大，10G或者更大，你也许要用一个固定的增长量来代替百分比增长量。这是因为百分比增长量在一个大数据库上会变得很大。例如在一个10G的数据库上一个10％增长率意味着当数据库增长时，要增长1G。这也许是或不是你所要的。如果这超过了你的需求，那么选择每次增长一个固定增长量如100M，也许更合适。
作为监控的一部分，你需要小心估计你的数据库看上面的建议是否适合它们，然后做出正确的选择。
扫一扫
108
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
