>

SharePoint磁盘体量规划88bifa必发唯一官网,磁盘请

- 编辑:www.bifa688.com -

SharePoint磁盘体量规划88bifa必发唯一官网,磁盘请

 

 摘要:本文深入探讨了 SQL Server 体系结构的工作原理。其中介绍了数据库引擎的增强功能及其使用技巧,并提供了相关信息的链接。深入了解 SQL Server 的引擎有助于数据库管理员(数据库系统工程师)在设计、构建或改进数据库系统时充分利用 SQL Server 的优势。虽然本文主要面向数据库专业人士,但也可用于教学或营销目的。 

本文介绍如何在 Microsoft SharePoint Server 2010 环境中规划和配置存储和 Microsoft SQL Server 数据库层。

本文出处: 

  一. 简介

本文档中的容量规划信息为您提供规划应用准则。该准则建立在 Microsoft 对实时属性执行的测试的基础上。但是,您的结果可能因使用的设备和针对网站所实施的功能而有所不同。

 

  本文描述 Microsoft? SQL Server? 2000 中新增的存储引擎功能,并提供相关的使用技巧,同时探讨存储引擎的工作原理。初步掌握存储引擎的工作原理可使您最大限度地发挥 SQL Server 的性能。

由于 SharePoint Server 通常在由单独的 SQL Server 数据库管理员管理数据库所在的环境中运行,因此本文档专为 SharePoint Server 服务器场实施者和 SQL Server 数据库管理员联合使用而设计。假定深入了解 SharePoint Server 和 SQL Server。

最近遇到一个SQL Server服务器响应极度缓慢,并且出现客户端请求报错的情况,在数据库中的errorlog中出现磁盘请求超过15s才完成的error消息。
对于此类问题,到底是存储系统或者磁盘的故障,还是SQL Server 自己的问题,亦或是应用程序引发的呢?又要如何解决?
本文将对引起此问题的某一方面的因素进行简单的分析,但是无法涵盖所有潜在的可能性,因此遇到类似问题还要做具体的分析。

  当今,人们的注意力集中在应用程序的高可扩展性方面。数据库的设计和实施周期不断缩短,而且由于开发需求的不断变更以及产品使用的增长,又使得数据库在不断地演变发展。为满足可扩展性、可用性和易于使用等方面的要求,需要有一种具有应变能力和灵活性的数据存储引擎。

本文假定您熟悉关于性能和容量规划 (Office SharePoint Server)中提出的概念。

 

  SQL Server 2000 的不同版本可支持不同规模的系统,其范围从用于 Pocket PC 的小型移动系统到运行在群集 Windows? 2000 Datacenter Server 上容量达数 TB 的高可用性事务处理或决策支持系统。所有这些系统都满足使命关键的业务系统所要求的灵活性、安全性和可靠性要求。

SharePoint 2010 产品存储和数据库层的设计和配置过程

建议您将存储和数据库层设计过程分为以下几个步骤。每节提供有关每个设计步骤的详细信息,包括存储要求和最佳实践:

  • 收集存储和 SQL Server 空间以及 I/O 要求

  • 选择 SQL Server 版本

  • 根据容量和 I/O 要求设计存储体系结构

  • 估计内存要求

  • 了解网络拓扑要求

  • 配置 SQL Server

  • 验证和监视存储和 SQL Server 性能

SQL Server中的磁盘请求超时

  由于存储引擎操作的智能化和自动化,因而可以在各种用途和规模的项目中部署 SQL Server 2000 应用程序。高度完善的体系结构改善了性能、可用性和可伸缩性。

收集存储和 SQL Server 空间以及 I/O 要求

多个 SharePoint Server 2010 体系结构因素影响存储设计。内容数量、所用的功能和服务应用程序、服务器场数量和可用性需求是主要因素。

开始规划存储之前,应了解 SharePoint Server 2010 可使用的数据库。

本节内容:

  • SharePoint 2010 产品所用的数据库

  • 了解 SQL Server 和 IOPS

  • 估计核心存储和 IOPS 需求

  • 估计服务应用程序存储需求和 IOPS

  • 确定可用性需求

  该错误的英文版的错误信息如下:
  SQL Server has encountered %d occurrence(s) of I/O requests taking longer than %d seconds to complete on file [%ls] in database id %d. The OS file handle is 0x%p. 0
  The offset of the latest long I/O is: %#016I64x
  中文版的错误信息如下
  SQL Server 已遇到 %1! 次对数据库 ID %4! 中的文件 [%3!] 进行的 I/O 请求超过 %2! 秒才完成。操作系统文件句柄为 0x%5!。最新的长时间 I/O 的偏移量为: %6!

  可用性

SharePoint 2010 产品所用的数据库

与 SharePoint Server 2010 一起安装的数据库取决于环境中正使用的功能。所有 SharePoint 2010 产品都依赖 SQL Server 系统数据库。本节提供了与 SharePoint Server 2010 一起安装的数据库的摘要。有关详细信息,请参阅数据库类型和说明 (SharePoint Server 2010) 和数据库模型(该链接可能指向英文页面) (

  参考message信息中的833号错误消息

  由于在与物理文件进行交互时采用了新的算法,可靠性和并发能力得到了增强。这些算法减轻了日常维护工作,使您不必再运行数据库控制台命令 (DBCC)。然而,DBCC 仍旧可以使用,并且新增的 DBCC CHECK 命令的运行不会干扰联机处理工作。

 

产品版本 数据库

SharePoint Foundation 2010

配置

管理中心内容

内容(一个或多个)

Usage and Health Data Collection

Business Data Connectivity

Application Registry Service(如果从 Microsoft Office SharePoint Server 2007 业务数据目录升级)

Subscription Settings Service(如果已通过 Windows PowerShell 启用)

SharePoint Server 2010 Standard Edition 的其他数据库

Search Service 应用程序:

  • 搜索管理

  • 爬网(一个或多个)

  • 属性(一个或多个)

 

User Profile Service 应用程序:

  • 配置文件

  • 同步

  • 社会性标签

 

Web Analytics Service 应用程序

  • 暂存

  • 报告

 

安全存储

状态

托管元数据

Word Automation Services

SharePoint Server 2010 Enterprise Edition 的其他数据库

PerformancePoint

Project Server 2010 的其他数据库

草稿

已发布

存档

报告

FAST Search Server 的其他数据库

搜索管理

 

如果要与 SQL Server 更完全地集成,您的环境可能还包括其他数据库,如下面的方案中所述:

  • Microsoft SQL Server 2008 R2 PowerPivot for Microsoft SharePoint 2010 可以用于包括 SQL Server 2008 R2 Enterprise Edition 和 SQL Server Analysis Services 的 SharePoint Server 2010 环境中。如果已经在使用它,您还必须进行规划以支持 PowerPivot 应用程序数据库以及系统上的额外负载。有关详细信息,请参阅在 SharePoint 场中规划 PowerPivot 部署.aspx) (

  • Microsoft SQL Server 2008 Reporting Services (SSRS) 插件可以用于任何 SharePoint 2010 产品环境。如果要使用该插件,请规划支持两个 SQL Server 2008 Reporting Services 数据库和 SQL Server 2008 Reporting Services 所需的额外负载。

  88bifa必发唯一官网 1

  可扩展性

了解 SQL Server 和 IOPS

在托管 SQL Server 的任何服务器上,服务器从 I/O 子系统获得最快可能响应非常重要。

更多更快的磁盘或阵列可提供足够的每秒 I/O 操作数 (IOPS),同时在所有磁盘上保持低延迟和少队列。

I/O 子系统的较慢响应速度无法通过添加其他类型的资源(如 CPU 或内存)加以补偿;但是,它会对整个服务器场造成影响应导致出现问题。部署前规划最小延迟并监视您的现有系统。

部署新服务器场之前,建议通过使用 SQLIO 磁盘子系统基准工具检测 I/O 子系统。有关详细信息,请参阅 SQLIO 磁盘子系统基准工具(该链接可能指向英文页面) (

有关如何从 SQL Server 角度分析 IOPS 要求的详细信息,请参阅分析 I/O 特点并调整 SQL Server 数据库应用程序的存储系统大小(该链接可能指向英文页面) (

 

  存储子系统(由物理数据库文件及其在磁盘上的布局组成)既支持小型数据库,也支持超大型数据库。SQL Server 当前可支持最高达 64 GB 物理内存 (RAM) 和 32 颗处理器。

估计核心存储和 IOPS 需求

配置和内容存储以及 IOPS 是基础层,您必须在每个 SharePoint Server 2010 部署中规划。

 

  易于使用

配置存储和 IOPS

配置数据库和管理中心内容数据库的存储要求不是很高。建议您为配置数据库分配 2 GB,为管理中心内容数据库分配 1 GB。随着时间的推移,配置数据库会增长超过 1 GB,但是增长速度不是很快,大约每收集 50,000 个网站增长 40MB。

配置数据库的事务日志可能很大,建议您将数据库的恢复模式从完整更改为简单。

注意:

如果想要使用 SQL Server 数据库镜像为配置数据库提供可用性,您必须使用完全恢复模式。

 

配置数据库和管理中心内容数据库的 IOPS 要求最低。

具体的833 error 申请磁盘请求超时现象

  增强的管理功能可帮助数据库管理员 (DBA) 实现服务器的自动管理和集中管理。这也使得对远程服务器和应用程序的维护变得容易,DBA 无需访问每个站点。由复杂算法管理的服务器配置可动态对服务器使用方案的变化作出反应,从而使 DBA 可以将精力集中在数据库管理和优化等任务上。

内容存储和 IOPS

估计内容数据库所需的存储和 IOPS 不是一项精确活动。在测试和介绍以下信息过程中,我们要帮助您推导出用于确定部署初始大小的估计值。但是,如果您的环境正在运行,我们希望您根据来自实时环境的数据重新检查容量需求。

有关我们总体容量规划方法的详细信息,请参阅关于性能和容量规划 (Office SharePoint Server)。

  具体报错情况如下:
  SQL Server 已遇到 m 次对数据库 n 中的文件***进行的 I/O 请求超过 15 秒才完成。操作系统文件句柄为 ***。最新的长时间 I/O 的偏移量为: ***
  也就是说在数据库的文件自动增长的过程中遇到了错误。

  二. 存储引擎的增强功能

估计内容数据库存储

下面的过程介绍如何约估内容数据库的存储,无需考虑日志文件:

  1. 计算预期文档数。此值由公式中的 D 代表。

    如何计算文档数将由您使用的功能确定。例如对于“我的网站”或协作网站,建议您计算每个用户的预期文档数,然后乘以用户数。对于记录管理或内容发布网站,可以计算由某个进程管理和生成的文档数。

    如果要从目前系统迁移,可以很轻松地推断出目前增长率和使用率。如果要创建新系统,请查看您的现有文件共享或其他存储库,并根据该使用率进行估计。

  2. 估计将要存储的文档的平均大小。此值由公式中的 S 表示。为不同类型或组的网站估计平均值很有意义。“我的网站”、媒体存储库和不同部门门户的平均文件大小会显著不同。

  3. 估计环境中列表项目数。此值由公式中的 L 代表。

    列表项目相对于文档较难估计。我们通常使用文档数的 (D) 三倍作为估计值,但是根据预计使用网站的方式不同,估计值也将不同。

  4. 确定适当版本数。估计一个库中任意文档将存在的版本数平均值(此值通常会比允许的最大版本数小得多)。此值由公式中的 V 代表。

    V 的值必须大于零。

  5. 使用下面的公式估计内容数据库大小:

    数据库大小 = ((D × V) × S) (10 KB × (L (V × D)))

    公式中值 10 KB 是一个常数,粗略估计 SharePoint Server 2010 所需的元数据量。如果您的系统需要大量使用元数据,您可能需要减小此常数。

例如,如果您要使用公式估计具有以下特点的协作环境中内容数据库的数据文件所需的存储空间量,可能大约需要 105 GB。

create table #errorlog
(
    LogDate datetime,
    ProcessInfo varchar(50),
    TextInfo varchar(5000)
)
GO

insert into #errorlog
exec xp_readerrorlog
GO

select * from #errorlog where TextInfo like '%taking longer%'
order by LogDate DESC

  SQL Server 2000 的关系数据库服务器包括两个主要部分:关系引擎和存储引擎。两个引擎独立工作,它们通过本地数据访问组件(如 OLE DB)进行交互。关系引擎提供访问存储引擎的接口,而存储引擎由与基本数据库存储组件和功能进行交互的服务构成。

 

输入

文档数 (D)

200,000

通过假定 10,000 个用户乘以 20 个文档计算得出

文档平均大小 (S)

250 KB

列表项目 (L)

600,000

非当前版本数 (V)

2

假定允许的最大版本数为 10

数据库大小 = (((200,000 x 2)) × 250) ((10 KB × (600,000 (200,000 x 2))) = 110,000,000 KB 或 105 GB

  88bifa必发唯一官网 2

  存储引擎的主要任务包括: 
  提供改善管理存储组件易用性的功能 
  管理数据缓冲和对物理文件的所有 I/O 操作 
  控制并发、管理事务、锁定和日志记录 
  管理用于存储数据的文件和物理页 
  恢复系统故障 

影响内容数据库大小的功能

使用下面的 SharePoint Server 2010 功能会显著影响内容数据的大小:

  • 回收站 文档从第一阶段和第二阶段回收站完全删除之前,会一直占用内容数据库空间。每月计算删除的文档数以确定回收站对内容数据库大小的影响。有关详细信息,请参阅配置回收站设置 (SharePoint Server 2010)。

  • 审核 审核数据可以快速复合并使用内容数据库中的大量空间,尤其在是查看审核打开的情况下。不要允许审核数据无限制增长,建议仅在务必满足管理需求或内部控制时启用审核。使用以下准则估计针对审核数据需要保留的空间:

    • 估计网站的新审核条目数,并将此数字乘以 2 KB(条目通常限制为 4 KB,平均大小约为 1 KB)。

    • 根据想要分配的空间,确定想要保留的审核日志数。

  • Office Web Apps。如果正使用 Office Web Apps,Office Web Apps 缓存会显著影响内容数据库的大小。默认情况下,Office Web Apps 缓存配置为 100 GB。有关 Office Web Apps 缓存大小的详细信息,请参阅管理 Office Web Apps 缓存。

  比较有意思的是某DBA将此错误信息报告给负责存储(SAN存储,并非挂的磁盘)的工程师,认为是可能存储系统存在故障或者不稳定造成的,
  存储工程师认为存储没有问题,检查服务器后说服务器不正常,内存“几乎占满”,
  对于数据库服务器,内存“几乎占满”的情况可以说是完全正常的,鉴于负责存储的工程师并非专业DBA,对于SQL Server数据库服务器的内存使用可能不是太了解,提出此疑问也可以理解。
  因为数据库服务器使用的存储是高性能的SAN存储,存储是作为一个服务存在的,有N多服务器共同来使用的,
  其他服务器并没有出现磁盘请求,不太可能说某一台服务器会出现疑似“存储故障”就简单认定为是存储故障。
  那么究竟原因在什么地方呢?

  SQL Server 2000 中的存储引擎提供概念简单而实际操作比较灵活的新增功能,同时减少了详细规划容量和优化性能的工作。SQL Server 2000 可以对其环境作出反应,并准确而快速地适应数据库使用上的变化。这种技术上的突破已将数据库管理的重点转移到作为服务的数据简化上。SQL Server 2000 DBA 可以将注意力集中到设计一个可对数据流和数据使用作出响应的系统上,而不再需要将时间浪费在优化个别参数上。 

估计内容数据库 IOPS 需求

内容数据库的 IOPS 要求会因使用环境的方式、磁盘空间的大小以及拥有的服务器数的不同而显著不同。通常,建议您将环境中的预计工作负荷与已测试的解决方案之一进行比较。有关详细信息,请参阅性能和容量测试结果及建议 (SharePoint Server 2010)。

重要:

本节中内容的测试尚未完成。请稍后查看其他信息。

 

 

2003-6-7 19:21:00    
 查看评语???     

估计服务应用程序存储需求和 IOPS

估计内容存储和 IOPS 需求之后,接下来必须确定环境中正使用的服务应用程序所需的存储和 IOPS。

数据库引擎错误833的含义

 2003-6-7 19:23:01      SQL Server 2000 中的变化建立在体系结构的增强上。这种增强是在 SQL Server 7.0 中引入的,其目的是为后来的改进和创新提供基础。存储引擎小组的主要目的是减少花在定期优化服务器上的时间和精力。由于绝大多数的调优参数设置是基于数据库使用的,所以引擎使用自适应算法动态调整这些设置,使其适合数据库环境。调优参数现在可以按这种方式自动调整,而在早期版本中,它们需要不断调整和测试。您仍可以手动调整调优功能,但 SQL Server 2000 可以完成更多的工作。只有很少的 SQL Server 客户才需要对调优参数进行调整;这种调整工作需要进行仔细的测试,并且需要经验丰富的数据库管理员进行监督。

SharePoint Server 2010 Service 应用程序存储和 IOPS 要求

若要估计系统中服务应用程序的存储要求,必须首先了解服务应用程序以及使用服务应用程序将要采取的方式。SharePoint Server 2010 中提供的具有数据库的服务应用程序在下表中列出。

  首先来看这个833错误的具体含义是什么,就不自己装13解释一通了,那本经典的书上写的很清楚了。
  总之,意思就是,SQL Server在请求磁盘读写的时候,遇到磁盘繁忙或者其他一些因素,超过了15秒还没有完成
  比如数据的读写的时候需要向磁盘发起请求,而磁盘正忙或者其他问题,来不及或者相应的不够及时,这样无疑会严重影响SQL Server对外提供服务器的响应时间。
  上面简单分析了,因为该问题并非普片发生的,存储系统不太可能出现问题,那就很有可能定位到当前服务器自身的因素了。

  下表总结了 SQL Server 2000 存储引擎的主要增强功能。本文的后面将对这些内容进行详细阐述。

 

服务应用程序 大小估计建议

搜索

搜索需要三个数据库。您的环境可能包括多个属性和爬网数据库。

搜索管理数据库通常较小:分配 10 GB。

若要估计属性和爬网数据库所需的存储,请使用以下乘数:

  • 爬网:0.046 × (内容数据库的总和)

  • 属性:0.015 × (内容数据库的总和)

搜索的 IOPS 要求很高。

  • 对于爬网数据库,搜索需要 3,500 至 7,000 IOPS。

  • 对于属性数据库,搜索需要 2,000 IOPS。

有关如何估计搜索所需容量的详细信息,请参阅性能和容量测试结果及建议 (SharePoint Server 2010)

User Profile

User Profile Service 应用程序分配有三个数据库:配置文件、同步和社会性标签。

若要估计数据库所需的存储,请使用以下信息:

  • 配置文件。具有默认设置,在配置为使用 Active Directory 的环境中,配置文件数据库每个用户配置文件大约需要 1 MB。

  • 同步。具有默认设置,在每个用户拥有很少组的环境中,同步数据库每个用户配置文件大约需要 630 KB。90% 的空间将被数据文件使用。

  • 社会性标签。具有默认设置,社会性标签数据库每个标签、注释或评级大约需要 0.009 MB。若要估计用户将创建的标签和注释数,请考虑以下有关网站 del.icio.us 的信息:

    • 大约 10% 的用户被视为活动。

    • 活动用户每月创建 4.5 个标签和 1.8 个注释。

在具有 160,000 个用户配置文件,5 个组,79,000 个标签、注释和评级(2,500 个注释、76,000 个标签和 800 个评级)和默认设置的实时协作环境中,我们发现了以下大小的数据库:

 

数据库名称 数据库大小
配置文件155 GB
同步96 GB
社会性标签0.66 GB

托管元数据

Managed Metadata Service 应用程序有一个数据库。数据库的大小受系统中所用的内容类型和关键字的数量影响。许多环境将包括 Managed Metadata Service 应用程序的多个实例。

Web Analytics

Web Analytics 有两个数据库:临时和报告。许多因素影响数据库的大小。其中包括保持期、每日跟踪的数据量以及正在分析的 Web 应用程序中的网站集数、网站数和子网站数。有关如何估计数据库大小和 IOPS 要求的详细信息,请参阅性能和容量测试结果及建议 (SharePoint Server 2010)

安全存储

Secure Store Service 应用程序数据库的大小由存储中的凭据数和审核表中条目数决定。建议您为该数据库每 1,000 个凭据分配 5 MB。它具有最低要求的 IOPS。

状态

State Service 应用程序有一个数据库。建议为其分配 1 GB。它具有最低要求的 IOPS。

Word Automation Service

Word Automation Service 应用程序有一个数据库。建议为其分配 1 GB。它具有最低要求的 IOPS。

PerformancePoint

PerformancePoint Service 应用程序有一个数据库。建议为其分配 1 GB。它具有最低要求的 IOPS。

  88bifa必发唯一官网 3

功能 描述及益处 
应用程序锁定管理器 如果需要控制对应用程序定义的资源(如表单)的并发访问,新增的存储过程允许您使用 SQL Server 的应用程序锁定管理器锁定这些资源。 
数据库控制台命令 (DBCC) DBCC CHECK 命令可以在联机处理过程中运行,且不会中断更新。新增的功能允许校验物理页的一致性,以检测硬件引起的错误。在 SQL Server 2000 企业版中,DBCC 可以在多个处理器上以并行方式运行。 
数据库选项 所有的数据库选项都可使用 ALTER DATABASE 进行修改。此功能简化了管理工作。 
差异备份 在 SQL Server 2000 中,由于改进后的功能可以在更广的层次上跟踪数据库的更改,差异备份的速度更快。 
动态调优 通过使用动态自适应算法,服务器可以自动调整以前是静态不变的配置设置。管理控制仍可用于管理系统范围的资源,但以后您不必使用它们。手动设置参数可以在它们的约束边界内动态调整。 
行内文本 在包含较小且使用频繁的文本列的表中,较小的文本值可以与标准数据行存储在同一页中,而不必存储在文本值页中。如果表中包含这种被频繁访问的文本数据,此功能可减少大量磁盘 I/O 操作。 
并行建立索引 在企业版中,索引建立过程自动使用为并行处理配置的所有处理器,减少了建立索引所需的时间;例如,在一台八处理器的服务器中,时间缩短到原来的六分之一。索引建立过程还可利用内存和 tempdb 中的可用资源。 
预读索引 读取索引的功能得到增强,提高了扫描索引的性能。 
重组索引 对 DBCC SHOWCONTIG 进行的改进提供了有关索引碎片的详细信息。新增的 DBCC 命令 INDEXDEFRAG 可联机重组索引页,且不会中断数据库服务,也不会导致数据库一致性或故障恢复方面的问题。 
降序排列索引中的键列 索引中的各个键列可单独指定为升序或降序。 
KILL 命令 此命令现在报告完成的进度。如果此命令正在等待另一个进程(例如回滚),则可以查看命令执行的进度。改进后的命令可以用于停止 Microsoft 分布式事务协调器 (MS DTC) 事务,而这些事务并不与特定会话相关联。 
对高内存量的支持 Windows 2000 中的技术改进了使用大量内存的企业版系统的性能。通过使用 Windows 2000 的 AWE 扩展,SQL Server 2000 可至多支持 64 GB 物理内存 (RAM)。 
锁定 改进后的锁定管理器可探测到其它资源(如线程和内存)的死锁情况。并发能力的改善同时也降低了死锁的发生,从而进一步加强了 SQL Server 2000 的可扩展性。 
逻辑日志标记 Transact-SQL 命令可在日志中创建书签,使数据库可以恢复到书签所示的时点。此功能还可同步恢复用于同一应用程序的多个数据库。 
联机索引重组 对 DBCC SHOWCONTIG 进行的改进提供了有关索引碎片的详细信息。新增的 DBCC 命令 INDEXDEFRAG 可联机重组索引页,且不会中断数据库服务,也不会导致数据库一致性或故障恢复方面的问题。 
优化的预读 I/O 操作 对于扫描所涉及的每个文件,SQL Server 2000 都会同时发出多个连续的、预读读取操作。为提高性能,查询优化器在扫描表和索引时使用连续的预读 I/O 操作。 
密码保护备份 可使用密码保护备份媒体和单独的备份。这样可以防止未授权的用户恢复备份并访问数据库。 
故障恢复模式 通过使用故障恢复模式,可以选择数据库的日志记录级别。这样事务日志管理更加灵活。故障恢复模式可联机更改,以适应一天当中不断变化的数据库使用。 
共享表扫描 在企业版中,对某个表的多次扫描可以利用其他进行中的对该表的扫描,减少了对磁盘的实际 I/O 操作。 
收缩日志 收缩日志命令可在更多的情况下立即运行。即使不能立即收缩日志,SQL Server 也会提供建议性的反馈,说明在继续或完成收缩操作之前必需完成的操作。 
快照备份 对第三方供应商提供的快照备份的支持进一步得到加强。快照备份采用存储技术,可以在几秒内备份或恢复整个数据库。如今,可以将这些备份与常规事务日志及差异备份相结合,为 OLTP 数据库提供完整的保护。此功能对于中型或大型数据库是非常有益的,因为在这种环境中可用性是非常重要的。 
节省空间的空表和索引 SQL Server 2000 不为空表和索引分配磁盘页。SQL Server 7.0 会给空表和索引分配多达三个磁盘页。 
前 n项排序 此新功能可优化前 n 项值的检索(例如,SELECT TOP 5 * FROM tablename)。 
Xlock SQL Server 2000 提供这种新的 Transact-SQL 锁定提示。它可用于明确调用互斥的、事务级别的页或表锁。 

确定可用性需求

可用性是用户认为针对 SharePoint Server 2010 环境可供使用的程度。可用系统是一个弹性系统,即不经常发生影响服务的事件,并且在事件发生时及时采取有效措施。

可用性要求会显著增加存储需求。有关详细信息,请参阅规划可用性 (SharePoint Server 2010)。

 

  SQL Server 2000 中增加了许多功能,这些功能使数据交互更为有效,使管理更加灵活。以下部分将详细介绍这些增强功能,并提供相关的使用技巧。
三. 与数据进行交互

选择 SQL Server 版本

虽然 SharePoint 2010 产品可以在 Microsoft SQL Server 2008 R2、SQL Server 2008 或 SQL Server 2005 上运行,但强烈建议您考虑在 SQL Server 2008 或 SQL Server 2008 R2 的 Enterprise Edition 中运行您的环境,以利用它提供的额外性能、可用性、安全性和管理功能。有关使用 SQL Server 2008 R2 Enterprise Edition 的好处的详细信息,请参阅SQL Server 2008 R2 和 SharePoint 2010 产品:关联后功能更强大(白皮书)(SharePoint Server 2010)。

特别考虑对以下功能的需求:

  • 备份压缩 备份压缩可以加速任何 SharePoint 备份,在 SQL Server 2008 Enterprise Edition 或 SQL Server 2008 R2 Standard Edition 中提供。通过在备份脚本中设置压缩选项或在默认情况下通过配置运行 SQL Server 的服务器进行压缩,可以大大减小数据库备份和传送日志的大小。有关详细信息,请参阅备份压缩 (SQL Server) (

    注意:

    SharePoint 2010 产品 不支持 SQL Server 数据压缩,Search Service 应用程序数据库除外。

     

  • 透明数据加密 如果您的安全要求包括对透明数据加密的需求,则必须使用 SQL Server Enterprise Edition。

  • Web Analytics Service 应用程序 如果您规划使用 Web Analytics Service 应用程序进行大量分析,请考虑使用 SQL Server Enterprise Edition,以便系统可以利用表分区。

  • 内容部署 如果您规划使用内容部署功能,请考虑使用 SQL Server Enterprise Edition,以便系统可以利用 SQL Server 数据库快照。

  • 远程 BLOB 存储 如果想要利用与每个内容数据库关联的文件之外的数据库或位置的远程 BLOB 存储,必须使用 SQL Server 2008 或 SQL Server 2008 R2 Enterprise Edition。

  • 资源调控器 资源调控器是 SQL Server 2008 中引入的一项技术。利用该技术,可以通过指定因传入请求产生的资源消耗的限额,管理 SQL Server 工作负荷和资源。利用资源调控器,可以区分工作负荷并根据您指定的限额在工作负荷请求时分配 CPU 和内存。资源调控器仅在 SQL Server 2008 或 SQL Server 2008 R2 Enterprise Edition 中提供。有关使用资源调控器的详细信息,请参阅使用资源调控器管理 SQL Server 工作负荷。

    建议结合 SharePoint Server 2010 使用资源调控器执行下列操作:

    • 限制搜索爬网组件的目标 Web 服务器消耗的 SQL Server 资源量。建议的最佳实践是当系统在负载情况下,将爬网组件限制为 10% 的 CPU。

    • 监视系统中每个数据库消耗的资源量。例如,可以使用资源调控器帮助您确定运行 SQL Server 的几个计算机中数据库的最佳放置位置。

  • PowerPivot for SharePoint 2010 使用户可以共享 Excel 和浏览器中用户生成的数据模式和分析并在此方面进行协作,同时自动刷新这些分析。它属于 SQL Server 2008 R2 Enterprise Edition Analysis Services 的一部分。

 

  在 SQL Server 2000 中,存储引擎的功能得到增强,在与数据进行交互时可提供更好的可扩展性及性能。了解这些增强的功能有助于更有效地使用 SQL Server。

根据容量和 I/O 要求设计存储体系结构

您为环境选择的存储体系结构和磁盘类型会影响系统性能。

本节内容:

  • 选择存储体系结构

  • 选择磁盘类型

  • 选择 RAID 类型

原因分析

  无论是通过用户界面还是自动执行的任务,数据交换都从查询开始。数据请求先被传递到关系引擎,然后关系引擎与存储引擎进行交互以获取数据,并将其传递给用户。无论是从用户还是 DBA 的角度来看,存储和关系引擎的功能是无法区分的。

选择存储体系结构

SharePoint Server 2010 支持直接附加存储 (DAS)、存储区域网络 (SAN) 和网络附加存储 (NAS) 存储体系结构,但是仅在 NAS 与配置为使用远程 BLOB 存储的内容数据库结合使用时支持 NAS。您的选择取决于业务解决方案和您的现有体系结构中的因素。

任何存储体系结构都必须支持您的可用性需求以及必须在 IOPS 和延迟方面表现出色。若要获得支持,系统必须在 20 毫秒 (ms) 内持续返回数据的第一个字节。

  因为是专门的SQL Server服务器,没有其他应用程序的请求,很有可能跟向sqlserver数据库发起的请求有关。
  其实发生这个问题之前,早就有预兆了,平时还算稳定的服务器(CPU很少超过60%,内存的PLE也可以稳定在20分钟以上,磁盘IO延迟较低等等),只是偶尔会存在抽风一阵子的情况
  抽风的时候表现为CPU狂飙到80%左右,内存的PLE会严重下降,IO延迟严重增高。
  现在只能从SQL Server的Session入手,在观察SQL Server中的活动Session的时候,发现某一类的SQL语句的查询时间非常长,
  平时这类SQL在某一个时间段内执行的频率还算比较高。
  但是正常情况下,这类SQL的执行效率还是比较高的,为什么突然就变的非常之底?
  在检查活动Session的对应的执行计划的时候,发现这类活动Session的等待状态都是IO等待(PAGEIOLATCH_SH),同时SQL的执行完全是意料之外的执行方式。
  因为类似查询还是执行的比较频繁的,此类Session会从不同的客户端发起,一旦SQL的执行效率降下来,服务器上会积压大量的活动Session
  为什么平时执行的好好的SQL语句突然就变的很慢很慢,
  原因就在于在某一点,SQL Server自动触发了统计信息的更新,但是这是一个比较大的表,但是默认统计信息更新的取样比例是不够的,如果取样百分比不够,这个统计信息完全是不可用的。
  参考之前的文章:
  一旦自动收集统计信息完成之后,会根据当前收集到的统计信息,向之前的SQL语句发出一种它认为高效的方式(table scan而不是index seek),其实这种方式并非是合理的,
  由此引发对应的SQL利用一种并非合理的执行计划来实现查询,同时会引发Session的拥堵,客户端发过来大量的Session同时在利用一种低效的方式缓慢执行。
  所以CPU会飙升,IO延迟增加,内存的PLE严重下降。
  由此也不难理解,数十个查询的Session正在以一种不合理的方式疯狂地想磁盘发出请求,磁盘正在忙于活动Session的数据请求,
  出现无法响应因为数据或者索引文件的自动增长请求,造成一开始说的问题。

  更有效地读取数据

直接附加存储 (DAS)

DAS 是一个直接附加到服务器或工作站的数字存储系统,两者之间没有存储网络。DAS 物理磁盘类型包括串行附加 SCSI (SAS) 和串行附加 ATA (SATA)。

通常,建议您在共享存储平台无法保证 IOPS 在平均值和峰值的情况下具有 20 毫秒的响应时间和足够容量时,选择 DAS 体系结构。

  最后经过索引重建(促使统计信息更新,当然纯粹的统计信息更新也可以)解决,长期预防的话,需要安排job人为地定义统计信息更新的阈值以及取样百分比。

  数据通过一系列事务在服务器和用户之间传递。应用程序或用户启动任务后,数据库将其传递给查询处理器进行处理,然后返回最终结果。查询处理器通过接收、解释和执行 SQL 语句来完成任务。

存储区域网络 (SAN)

SAN 是一个将远程计算机存储设备(如磁盘阵列和磁带库)附加到服务器的体系结构,以这种方式,设备可以作为本地附加到操作系统的设备出现(例如块存储)。

通常,如果共享存储提供的好处对于您的组织具有重要意义,建议您选择 SAN。

共享存储的好处包括:

  • 更轻松地在服务器之间重新分配磁盘存储。

  • 可以为多个服务器提供服务。

  • 可以访问的磁盘数不受限制。

 

  例如,当用户会话发出 SELECT 语句时,将会执行以下步骤: 

网络附加存储 (NAS)

NAS 设备是一台连接到网络的独立计算机。它的唯一目的是为网络中的其他设备提供基于文件的数据存储服务。NAS 设备上的操作系统和其他软件提供数据存储、文件系统和文件访问功能以及对这些功能的管理(例如文件存储)。

注意:

NAS 仅支持用于配置为使用远程 BLOB 存储的内容数据库。任何网络存储体系结构必须在 1 毫秒内对 ping 作出响应,并必须在 20 毫秒内返回数据的第一个字节。此限制不适用于本地 SQL Server FILESTREAM 提供程序,因为它仅将数据本地存储在同一服务器上。

 

总结:

  关系引擎将语句进行编译和优化后,将其纳入执行计划(获取数据所需的一系列步骤)。然后,关系引擎运行执行计划。执行步骤包括通过存储引擎访问表和索引。 

选择磁盘类型

您在系统中使用的磁盘类型会影响可靠性和性能。其他同等情况下,较大驱动器会增加平均寻道时间。SharePoint Server 2010 支持以下类型的驱动器:

  • 小型计算机系统接口 (SCSI)

  • 串行高级技术附件 (SATA)

  • 串行附加 SCSI (SAS)

  • 光纤通道 (FC)

  • 集成设备电子学 (IDE)

  • 固态硬盘 (SSD) 或闪存盘

  数据库服务器上的问题,很多问题都是一个连锁反应的过程,对应观察到的一部分现象,很有可能并不是表面上的反应的那样(磁盘请求超时,问题出在存储上?)
  专业的位置上必须要有专业的素养,比如一开始DBA误以为是存储问题,存储工程师认为服务器内存用满了是不正常的等,其实都不是问题的根本原因所在。
  面对问题,要追本溯源,找出来最根本的原因,才是解决问题的关键。

  关系引擎解释执行计划,调用存储引擎以收集所需的信息。 

选择 RAID 类型

RAID(独立磁盘冗余阵列)通常用于改善各个磁盘的性能特征(通过将多个磁盘内的数据分段)并提供保护避免发生单个磁盘故障。

SharePoint Server 2010 支持所有 RAID 类型;但是,建议您使用 RAID 10 或具有等效性能的供应商特定 RAID 解决方案。

在配置 RAID 阵列时,确保将文件系统与供应商提供的偏移对齐。在缺少供应商指导的情况下,请参阅SQL Server 预部署 I/O 最佳实践(该链接可能指向英文页面) (

有关设置 RAID 和 SQL Server I/O 子系统的详细信息,请参阅 SQL Server 最佳实践文章(该链接可能指向英文页面) (

 

  关系引擎将存储引擎返回的所有数据组合到最终的结果集中,然后将结果集返回给用户。 

估计内存要求

SharePoint Server 2010 所需的内存与正运行 SQL Server 的服务器上托管的内容数据库的大小直接关联。

添加服务应用程序和功能时,要求可能会增加。下表提供了建议的内存量的准则。

注意:

小型和中型部署的定义在文章 关于性能和容量规划 (Office SharePoint Server)的“参考体系结构”一节中介绍。

 

 

  为提高此过程的性能,进行了两项改进。在 SQL Server 2000 中,关系引擎将核准查询谓词的工作交由存储引擎完成,这样在该过程中这些谓词能尽早得到处理,因而提高了存储和关系引擎之间数据交换的效率。此项改进使核准查询的效率显著提高。

 

内容数据库的总计大小 建议运行 SQL Server 的计算机使用 RAM

小型生产部署的最低要求

8 GB

中型生产部署的最低要求

16 GB

建议最高 2 TB

32 GB

建议在 2 TB 与最大 5 TB 之间的范围内

64 GB

 

注意:

这些值高于 SQL Server 的最小建议值,因为 SharePoint Server 2010 环境需要进行数据分布。有关 SQL Server 系统要求的详细信息,请参阅安装 SQL Server 2008 的硬件和软件要求 (http://go.microsoft.com/fwlink/?linkid=129377&clcid=0x804)。

 

影响所需内存的其他因素包括:

  • 使用 SQL Server 镜像。

  • 频繁使用大于 15 MB 的文件。

  增强的 Top n 功能

了解网络拓扑要求

在服务器场内部和彼此之间规划网络连接。建议使用延迟较低的网络。

下面的列表提供一些最佳实践和建议:

  • 服务器场中的所有服务器都应针对运行 SQL Server 的服务器具有 LAN 带宽和延迟。延迟不应大于 1 毫秒。

  • 建议不要使用广域网 (WAN) 拓扑,其中运行 SQL Server 的服务器通过具有大于 1 毫秒延迟的网络从服务器场的其他组件远程部署。此拓扑尚未测试。

  • 如果规划使用 SQL Server 镜像或日志传送来保持远程网站为最新状态,请规划可用的 WAN 网络。

  • 建议 Web 服务器和应用程序服务器具有两个网络适配器:一个适配器处理最终用户流量,另一个处理与运行 SQL Server 的服务器之间的通信。

  另一项改进是存储引擎处理从结果集中选择前 n 个记录的方式。在 SQL Server 2000 中,新的 Top n 引擎将分析类似以下语句的最佳操作路径:
SELECT top 5 * from orders order by date_ordered desc
在本例中,如果必须搜索整个表,则引擎会分析数据并只跟踪高速缓存中的前 n 项数值。这种方式将大幅提高上述 SELECT 语句的性能,因为只有前 n 项值需要排序,而非整个表。

配置 SQL Server

以下各节介绍如何规划为 SharePoint Server 2010 配置 SQL Server。

本节内容:

  • 估计需要多少个服务器

  • 配置存储和内存

  • 设置 SQL Server 选项

  • 配置数据库

  共享扫描

估计需要多少个服务器

通常,SharePoint Server 2010 旨在利用 SQL Server 向外扩展 — 即相比仅使用几个大型服务器,SharePoint Server 2010 使用大量运行 SQL Server 的中型服务器具有更好的性能表现。

始终将 SQL Server 置于未运行任何其他服务器场角色或托管任何其他应用程序的数据库的专用服务器上,除非您将系统部署在独立服务器上。

以下是何时部署将运行 SQL Server 的其他服务器的一般指南:

  • 存在四个以上 Web 服务器以全容量运行时,添加其他数据库服务器。

  • 在内容数据库超过 5 TB 时,添加其他数据库服务器。

注意:

Microsoft 支持不遵循此指南的服务器配置。

 

若要在运行 Secure Store Service 应用程序时提升安全凭据存储,建议将安全存储数据库托管在仅限一名管理员访问的单独数据库实例上。

  在 SQL Server 2000 企业版中,两个或多个查询可共享正在进行的表扫描,此项功能可改善大型 SQL Server 2000 数据库的性能。例如,当查询使用无序扫描查询一个很大的表时,高速缓存中的页面将被清空,以便为流入数据腾出空间。如果另一个查询已经开始,对同一表的第二次扫描就会使磁盘 I/O 再次检索这些页面。在频繁进行表扫描的环境中,当两个查询搜索相同的数据页时,这将导致磁盘颠簸。 

配置存储和内存

在运行 SQL Server 2008 的服务器上,建议每个 CPU 的 L2 缓存最低为 2MB,以提高内存。

图 1:共享扫描效果

遵循供应商存储配置建议操作

若要在配置物理存储阵列时获得最佳性能,请遵守存储供应商提供的硬件配置建议操作,而不要使用操作系统的默认值。

如果未从供应商处获得指南,建议您使用 DiskPart.exe 磁盘配置实用程序为 SQL Server 2008 配置存储。有关详细信息,请参阅预部署 I/O 最佳实践 (

  优化的进程可减少由此类数据访问模式造成的磁盘 I/O 操作。对表的第一个无序扫描将从磁盘中读取数据;后续的对同一表的无序扫描不必再读取硬盘,而只需使用已在内存中的信息。参见图 1。在对同一个表同时进行多个扫描操作时,此同步过程可将性能提高至多八倍。此项改进的效果在大型决策支持查询中更加明显,因为整个表的大小远远大于高速缓存的大小)。 

提供尽可能多的资源

确保磁盘的 SQL Server I/O 通道没有与其他应用程序共享,例如页面文件和 Internet Information Services (IIS) 日志。

提供尽可能多的总线带宽。较大的总线带宽可帮助提高可靠性和性能。考虑硬盘不是总线带宽的唯一用户,例如,您还必须考虑网络访问。

  当查询没有更有效的执行计划时,存储引擎将使用共享扫描功能协助查询。此功能的目的是提高频繁读取大型表的性能。当查询处理器确定最佳执行计划中包含表扫描时,将调用此功能。然而,尽管可以使用查询或索引优化强制进行共享扫描时,但强制进行表扫描并不会提高性能。此时使用状态良好的索引完成同样的工作效果不会差,而且可能会更好。

设置 SQL Server 选项

以下 SQL Server 设置和选项应在部署 SharePoint Server 之前配置。

  • 不要在支持 SharePoint Server 的 SQL Server 上启用自动创建统计信息。SharePoint Server会在进行设置和升级时配置必需的设置。自动创建统计信息会显著更改从 SQL Server 的一个实例到 SQL Server 的另一个实例的查询的执行规划。因此,为了向所有客户提供持续支持,SharePoint Server 根据需要为查询提供了编码提示,从而在所有方案中提供最佳性能。

  • 为确保获得最佳性能,强烈建议您将承载 SharePoint Server 2010 数据库的 SQL Server 实例的 max degree of parallelism (MAXDOP) 设置为 1。有关如何设置 max degree of parallelism 的详细信息,请参阅 max degree of parallelism 选项 (

  • 为提高维护的便捷性,请为服务器场中的每个数据库服务器配置 SQL Server 连接别名。连接别名是用于连接到 SQL Server 的实例的备用名称。有关详细信息,请参阅 如何:设置 SQL Server 别名 (SQL Server Management Studio) (

  并发

配置数据库

下面的指南介绍在环境中配置每个数据库时进行规划的最佳实践。

  为了在多个用户进行数据交互的同时维护事务的一致性,存储引擎会锁定资源以管理行、页、键、键范围、索引、表和数据库的依存性。通过在更改资源时将其锁定,引擎可防止多个用户同时更改同一数据。SQL Server 中的锁可在不同粒度级别上动态应用,以选择事务所需的限制最小的锁。

在各磁盘之间进行数据分隔并设置优先级

理想情况下,应在单独的物理硬盘上放置 tempdb 数据库、内容数据库、使用率数据库、搜索数据库和 SQL Server 2008 事务日志。

下面的列表为设置数据优先级提供一些最佳实践和建议:

  • 在速度较快的磁盘中设置数据优先级时,请使用以下分级:

    1. Tempdb 数据文件和事务日志

    2. 数据库事务日志文件

    3. 搜索数据库(搜索管理数据库除外)

    4. 数据库数据文件

在着重面向读取的门户网站中,将数据优先级设置为高于日志优先级。  
  • 测试和客户数据显示,tempdb 的磁盘 I/O 不足可能会显著抑制 SharePoint Server 2010 服务器场的性能。为避免此问题,请为 tempdb 分配专用磁盘。如果预计存在或监测到高工作负荷(即读取操作或写入操作需要的平均时间超过 20 毫秒),则可能必须通过分隔磁盘上的文件或将磁盘替换为更快的磁盘来消除瓶颈。

  • 为获得最佳性能,请将 tempdb 放在 RAID 10 阵列上。tempdb 数据库文件数应与 CPU 内核数相同,而且 tempdb 数据文件应设置为同等大小。为此,将双核处理器算作两个 CPU。将支持超线程的每个处理器算作一个 CPU。有关详细信息,请参阅优化 tempdb 性能 (

  • 可将数据库数据和事务日志文件分隔到不同的磁盘上。如果由于文件太小而不足以使用整个磁盘或带区,或者您拥有的磁盘空间不足而必须使文件共享磁盘,请将具有不同使用模式的文件放在同一磁盘上,以尽量减少同时访问请求数。

  • 有关如何配置所有日志和搜索数据库以对您的特定存储解决方案进行写入优化的信息,请咨询您的存储硬件提供商。

  在 SQL Server 2000 中,并发方面的改进进一步减少了死锁,避免了对资源不必要的锁定。例如,增强的锁定管理器可了解被竞用的其它资源(如线程和内存)。这种新的功能可帮助数据库管理员确定更广范围内的设计或硬件限制。 

对内容数据库使用多个数据文件

请遵循以下建议操作以便获得最佳性能:

  • 仅在数据库的主文件组中创建文件。

  • 将文件分布到不同的磁盘上。

  • 数据文件的数目应小于或等于 CPU 内核的数目。为此,将双核处理器算作两个 CPU。将支持超线程的每个处理器算作一个 CPU。

  • 创建大小相同的数据文件。

重要:

虽然可以使用 SharePoint Server 2010 的内置备份和恢复工具来备份和恢复多个数据文件,但如果您在同一位置进行覆盖,则这些工具无法将多个数据文件还原到不同的位置。因此,在对内容数据库使用多个数据文件时,我们强烈建议您使用 SQL Server 备份和恢复工具。有关如何备份和恢复 SharePoint Server 2010 的详细信息,请参阅规划备份和恢复 (SharePoint Server 2010)

 

有关如何创建和管理文件组的详细信息,请参阅物理数据库文件和文件组 (

 
 2003-6-7 19:30:13    锁定管理器中新增的 Transact-SQL 接口支持在编程代码中使用自定义的锁定逻辑。业务逻辑所需的锁可通过在 Transact-SQL 批处理中调用 sp_getapplock 命令来创建,这将允许您指定要锁定的应用程序定义的资源(例如锁定表单,而非数据行)、要使用的锁定模式、超时值以及锁的范围是事务还是会话。当使用新的应用程序锁管理器创建锁后,它们接受 SQL Server 的常规锁管理,如同它们是由存储引擎创建的一样,因此,不必担心当调用事务终止时,应用程序创建的锁仍处于打开状态。

限制内容数据库大小以提高可管理性

规划数据库大小以提高环境的可管理性和性能以及易于环境升级。

为帮助确保系统性能,我们强烈建议将内容数据库的大小限制为 200 GB。

网站集不应超过 100 GB,除非它是数据库中唯一的网站集。设置此限制,以便您可以在需要时使用 SharePoint Server 2010 粒度备份工具以便将网站集移至另一个数据库。

重要:

只有其中的数据保持合理静态的大型单个网站存储库和存档支持最大可达 1 TB 的内容数据库,例如参考文档管理系统和记录中心网站。因为这些方案的 I/O 模式和典型数据结构格式是针对较大规模数据库专门设计并经过测试的,所以它们支持较大的数据库。

 

如果设计需要的数据库大小超过建议的标准,请遵循以下指南操作:

  • 对于包含大量以二进制大型对象 (BLOB) 存储的大型文件的数据库,请考虑使用远程 BLOB 存储 (RBS)。RBS 适用于以下情况:

    1. 运行包含不经常访问的大量文件的网站时,例如知识存储库。

    2. 具有数以兆 (TB) 计的数据时。

    3. 适用于视频或媒体文件。

有关详细信息,请参阅[规划 RBS (SharePoint
Server 2010)](http://technet.microsoft.com/zh-cn/library/ff628583.aspx)。  
  • 请遵循最佳实践查看大型数据库的数据。有详细信息,请参阅SharePoint Server 2010 容量管理:软件边界和限制。

有关大型文档库的详细信息,请参阅性能和容量测试结果及建议 (SharePoint Server 2010) 中包含的“估计大型文档库性能和容量要求”。

  在 SQL Server 2000 中,用于获取锁的进程将考虑页中的数据是否都已提交。例如,若要对某个表运行 SELECT 语句,而该表中的数据在最近未发生变化(如 pubs 数据库中的表),则该进程不会产生锁,因为最近没有活动事务对表进行过更新。存储引擎是通过将数据页上的日志序列号与当前活动事务相比较来实现上述功能的。如果数据库中的绝大多数数据都早于最早的活动事务,则对于这样的数据库,这一功能将显著减少锁定操作,从而使性能大幅提高。 

主动管理数据和日志文件增长

建议您考虑使用以下建议,主动管理数据和日志文件增长:

  • 尽可能将所有数据和日志文件预先增长至其预期的最终大小。

  • 鉴于安全原因,建议您启用自动增长。不要依赖默认自动增长设置。配置自动增长时,考虑使用以下准则:

    • 在规划超过建议大小 (200 GB) 的内容数据库时,请将数据库自动增长值设置为固定兆字节 (MB) 数,而不是设置为百分比。这样做是为了减少 SQL Server 增加文件大小的频率。增加文件大小是一项涉及用空白页填充新空间的阻止操作。

    • 将 Search Service 应用程序属性存储数据库的自动增长值设置为 10%。

    • 如果计算预期内容数据库的大小在下一年内不会达到建议的 200 GB(最大大小),通过使用 ALTER DATABASE MAXSIZE 属性,将其设置为预期数据库在一年内可达到的最大大小(含 20% 的附加误差限度)。定期查看此设置以确保其始终是基于过去增长率的适当值。

  • 将磁盘中的可用空间保持在 25% 这一级别,以便适应增长和高峰使用模式。如果通过将磁盘添加到 RAID 阵列或分配更多存储空间来管理增长,请密切监视磁盘大小以避免空间不足。

  在使用锁保护事务中数据的同时,另一个进程 latching 控制对物理页的访问。闩锁是一种非常轻型的、短期同步对象,它保护事务生存期内不需要锁定的操作。当存储引擎扫描某页时,它先锁住该页,读取行,将行返回给关系引擎,然后再解除对页面的锁定,以使其它进程可以访问同一数据。存储引擎使用称为 lazy latching 的进程优化对数据页的访问,即只在另一个活动进程请求某页时,才释放对该页的锁存。如果没有活动进程请求同一数据页,则在对该页的整个操作过程中,单个闩锁将始终有效。

验证和监视存储和 SQL Server 性能

对硬件的性能和备份解决方案进行测试,使您可以满足服务水平协议 (SLA)。尤其对运行 SQL Server 的计算机的 I/O 子系统进行测试以确保性能令人满意。

对用来确保可在可用的维护时段内备份系统的备份解决方案进行测试。如果备份解决方案不能满足您的业务所需的 SLA,请考虑使用增量备份解决方案,如 System Center Data Protection Manager (DPM) 2010。

跟踪运行 SQL Server 的服务器的以下资源组件至关重要:CPU、内存、缓存/点击率和 I/O 子系统。一个或多个组件变慢或超载时,根据当前和预定工作负荷分析适当策略。有关详细信息,请参阅 SQL Server 2008 性能问题疑难解答(该链接可能指向英文页面) (

下节列出性能计数器,建议您用其监视在 SharePoint Server 2010 环境中运行的 SQL Server 数据库的性能。此外还列出每个计数器的运行状况近似值。

有关如何监视性能和使用性能计数器的详细信息,请参阅监视性能 (

  为改进系统的并发性能,应将精力集中在数据库系统的设计以及与其相关的代码对象上。SQL Server 2000 支持 TB 级的数据存储,其扩展能力可线性增长,且不受限制。数据库管理员的任务是管理数据库生命周期,即所有数据库组件(从代码到磁盘上的数据存储)的设计和优化周期,以确保设计始终满足服务级协议的要求。

要监视的 SQL Server 计数器

监视以下 SQL Server 计数器,确保服务器的运行状况良好:

  • 常规统计信息 此对象提供计数器用以监视常规服务器端活动,如当前连接数以及每秒与运行 SQL Server 实例的计算机连接或断开连接的用户数。考虑监视以下计数器:

    • 用户连接 此计数器显示运行 SQL Server 的计算机上的用户连接数。如果看到这一数字自基线上升了 500%,您会发现性能下降。
  • 数据库 此对象提供计数器用以监视大容量复制操作、备份和还原吞吐量以及事务日志活动。监视事务和事务日志以便确定数据库中发生的用户活动量以及事务日志达到的填满程度。用户活动量决定数据库的性能并影响日志大小、锁定和复制。监视低级日志活动用以衡量用户活动和资源使用率,可帮助您找到性能瓶颈所在。考虑监视以下计数器:

    • 事务数/秒 此计数器显示每秒指定数据库或整个服务器上的事务数。此数字更重要的是为您提供基线,帮助您解决问题。
  • 锁数 此对象提供有关各资源类型上 SQL Server 锁数的信息。考虑监视以下计数器:

    • Average Wait Time (ms) 此计数器显示每个导致等待的锁请求的平均等待时间量。

    • Lock Wait Time (ms) 此计数器显示锁在最后一秒内的等待时间。

    • Lock waits/sec 此计数器显示每秒不能立即达到满意且必须等待资源的锁数。

    • Number of deadlocks/sec 此计数器显示每秒运行 SQL Server 的计算机上的死锁数。此值不能超过 0。

  • 闩锁 此对象提供计数器以监视称为闩锁的内部 SQL Server 资源锁。监视闩锁确定用户活动和资源利用率,可以帮助您找到性能瓶颈所在。考虑监视以下计数器:

    • Average Latch Wait Time (ms) 此计数器显示必须等待的闩锁请求的平均闩锁等待时间。

    • Latch Waits/sec 此计数器显示未能立即授予的闩锁请求数。

  • SQL 统计信息 此对象提供计数器以监视送到 SQL Server 实例的编译和请求类型。监视查询编译和重新编译数以及由 SQL Server 的实例收到的批次数,可为您提供一个 SQL Server 以多快的速度处理用户查询以及查询优化器处理查询的效率的指示。考虑监视以下计数器:

    • SQL Compilations/sec 此计数器指示每秒编译代码路径被进入的次数。

    • SQL Re-Compilations/sec 此计数器指示每秒语句重新编译数。

  • 缓冲区管理器 此对象提供计数器以监视 SQL Server 使用内存存储数据页面、内部数据结构和过程缓存的方式,并提供计数器以监视 SQL Server 读取和写入数据库页面时的物理 I/O。考虑监视以下计数器:

    • Buffer Cache Hit Ratio

    • 此计数器显示在缓冲区缓存中找到而不需要从磁盘中读取的页面的百分比。该比率是缓存命中总数与最近几千次页面访问的缓存查找总数之比。由于从缓存读取比从磁盘读取成本要低得多,因此您需要将此比率设置为较高值。通常,您可以通过增加 SQL Server 可用的内存量提高缓冲区缓存命中率。

  • 计划缓存 此对象提供计数器以监视 SQL Server 使用内存存储对象(如存储过程)、临时和准备的 Transact-SQL 语句和触发器的方式。考虑监视以下计数器:

    • Cache Hit Ratio

    • 此计数器指示规划的缓存命中数与查找数的比率。

  四. 表和索引

要监视的物理服务器计数器

监视以下计数器以确保运行 SQL Server 的计算机的运行状况良好:

 

  • Processor: % Processor Time: _Total 此计数器显示处理器执行应用程序或操作系统进程(未空闲)所花的时间百分比。在运行 SQL Server 的计算机上,此计数器的值应保持在 50% 与 75% 之间。在不断超载的情况下,调查是否存在异常进程活动或服务器是否需要额外 CPU。

  • System: Processor Queue Length 此计数器显示处理器队列中的线程数。监视此计数器以确保线程数始终小于 CPU 内核数的两倍。

  • Memory: Available Mbytes 此计数器显示计算机上运行的处理器可用的物理内存量(以 MB 为单位)。监视此计数器以确保将总可用物理 RAM 保持在至少 20% 这一水平。

  • Memory: Pages/sec 此计数器显示为解决硬页面错误从磁盘读取页面或将页面写入磁盘的速度。

有关详细信息和内存疑难解答方法,请参阅 SQL Server 2005 监视内存使用量 (

  在物理数据结构方面也进行了改进,提高了设计和维护的灵活性。

要监视的磁盘计数器

监视以下计数器以确保磁盘运行状况良好。请注意,下列值代表随着时间的推移测量的值(不是突然波动出现的值,也不是基于一次测量的值)。

  • Physical Disk: % Disk Time: DataDrive 此计数器显示所选磁盘驱动器处理读取或写入请求的运行时间的百分比,通常指示磁盘的繁忙程度。如果“PhysicalDisk: % Disk Time”计数器的值很高(超过 90%),请检查“PhysicalDisk: Current Disk Queue Length”计数器以查看等待磁盘访问的系统请求数。等待 I/O 请求数应保持在不超过组成物理磁盘的轴数的 1.5 到 2 倍。

  • Logical Disk: Disk Transfers/sec 此计数器显示在磁盘上执行读取和写入操作的速率。使用此计数器可监视增长趋势并进行适当地预测。

  • Logical Disk: Disk Read Bytes/secLogical Disk: Disk Write Bytes/sec 这两个计数器显示在读取或写入操作过程中从磁盘传送字节的速率。

  • Logical Disk: Avg. Disk Bytes/Read 此计数器显示在读取操作过程中从磁盘传送的平均字节数。该值可反映磁盘延迟 — 较大的读取操作会导致更长的延迟时间。

  • Logical Disk: Avg. Disk Bytes/Write 此计数器显示在写入操作过程中传送到磁盘的平均字节数。该值可反映磁盘延迟 — 较大的写入操作会导致更长的延迟时间。

  • Logical Disk: Current Disk Queue Length 此计数器显示在收集性能数据时磁盘上未完成的请求数。对于此计数器,值越小越好。若每个磁盘未完成的请求数大于 2,则指示存在瓶颈,并应进行调查。这意味着,对于由 4 个磁盘组成的逻辑单元 (LUN),可以接受的最大值为 8。瓶颈会造成工作积压,这些工作积压会扩展到正在访问磁盘的当前服务器之外,从而导致用户长时间等待。可以通过以下方法来解决瓶颈:向 RAID 阵列添加更多的磁盘,用速率更快的磁盘替换现有磁盘或将一些数据移动到其他磁盘。

  • Logical Disk: Avg. Disk Queue Length 此计数器显示在采样间隔期间为选定磁盘排队的读写请求的平均数。此规则指明,每个心轴的未完成的读写请求不应超过 2 个,但由于存储虚拟化和各个配置间的 RAID 级别的差异,导致难以测量此请求数。请查找既大于平均磁盘队列长度又大于平均磁盘延迟的情况。此组合可指示存储阵列缓存使用过度或与其他应用程序共享心轴会影响性能。

  • Logical Disk: Avg. Disk sec/ReadLogical Disk: Avg. Disk sec/Write 这两个计数器显示对磁盘执行读取或写入操作所花费的平均时间(以秒为单位)。监视这两个计数器,确保二者的值保持在磁盘容量的 85% 以下。如果读取或写入操作大于磁盘容量的 85%,则磁盘访问时间将按指数方式增加。若要确定硬件的特定容量,请参考供应商文档,或使用 SQLIO 磁盘子系统基准工具计算容量。有关详细信息,请参阅 SQLIO 磁盘子系统基准工具(该链接可能指向英文页面) (

-   **Logical Disk: Avg. Disk sec/Read**
    此计数器显示对磁盘进行读取操作所花费的平均时间(以秒为单位)。在经良好调整的系统上,对于日志,理想值为
    1 到 5 毫秒(在缓存阵列上,最好为 1 毫秒);对于数据,理想值为 4
    到 20 毫秒(最好是小于 10
    毫秒)。在高峰期会出现更长的延迟,但如果定期出现较高的值,则应调查其原因。  

-   **Logical Disk: Avg. Disk sec/Write**
    此计数器显示对磁盘进行写入操作所花费的平均时间(以秒为单位)。在经良好调整的系统上,对于日志,理想值为
    1 到 5 毫秒(在缓存阵列上,最好为 1 毫秒);对于数据,理想值为 4
    到 20 毫秒(最好是小于 10
    毫秒)。在高峰期会出现更长的延迟,但如果定期出现较高的值,则应调查其原因。  


在将 RAID 配置与“Logical Disk: Avg. Disk Bytes/Read”或“Logical Disk:
Avg. Disk
Bytes/Write”计数器配合使用时,请使用下表中列出的公式以确定在磁盘上进行输入和输出操作的速率。  


###  

<table>
<colgroup>
<col style="width: 50%" />
<col style="width: 50%" />
</colgroup>
<thead>
<tr class="header">
<th>RAID 级别</th>
<th>公式</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td><p>RAID 0</p></td>
<td><p>I/Os per disk = (reads   writes) / number of disks</p></td>
</tr>
<tr class="even">
<td><p>RAID 1</p></td>
<td><p>I/Os per disk = [reads   (2 × writes)] / 2</p></td>
</tr>
<tr class="odd">
<td><p>RAID 5</p></td>
<td><p>I/Os per disk = [reads   (4 × writes)] / number of disks</p></td>
</tr>
<tr class="even">
<td><p>RAID 10</p></td>
<td><p>I/Os per disk = [reads   (2 × writes)] / number of disks</p></td>
</tr>
</tbody>
</table>

例如,如果有一个带两个物理磁盘的 RAID 1
系统,则各个计数器将具有下表中显示的值。  


###  

<table>
<colgroup>
<col style="width: 50%" />
<col style="width: 50%" />
</colgroup>
<thead>
<tr class="header">
<th>计数器</th>
<th>值</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td><p><strong>Avg. Disk sec/Read</strong></p></td>
<td><p>80</p></td>
</tr>
<tr class="even">
<td><p><strong>Logical Disk: Avg. Disk sec/Write</strong></p></td>
<td><p>70</p></td>
</tr>
<tr class="odd">
<td><p><strong>Avg. Disk Queue Length</strong></p></td>
<td><p>5</p></td>
</tr>
</tbody>
</table>

可使用以下公式计算每个磁盘的 I/O 值:(80   (2 × 70))/2 = 110  

可使用以下公式计算磁盘队列长度:5/2 = 2.5  

在此情况下,存在一个边框 I/O 瓶颈。

  随着表或索引的增长,SQL Server 以八个为一组分配新的数据页;这些数据页称为扩展。虽然 text、ntext 或 image 类型的列可存储在不同的页中,但一行数据不能超出一页,所以它只能拥有 8 KB 数据。拥有聚集索引的表按键的顺序存储在磁盘上。堆是不带聚集索引的表,它们是无序的。记录按插入的顺序存储。

其他监视工具

也可以使用 SQL Server 2008 中的 sys.dm_io_virtual_file_stats 动态管理视图来监视磁盘延迟并分析趋势。有关详细信息,请参阅 sys.dm_io_virtual_file_stats (Transact-SQL) (

  SQL Server 2000 支持索引视图,在其它数据库产品中常常称为实体视图。在某个视图上创建聚集索引时,该视图将从派生对象转为存储在数据库中的基本对象,并且其结构与带有聚集索引的表相同。索引视图可用于存储预先计算的值或复杂联接的结果,但前提是维护开销不能超过性能上的收益。在 SQL Server 2000 企业版中,只要索引视图可以优化查询计划,查询处理器就会自动使用它。对于很少更改但又经常作为复杂联接或计算查询组成部分的数据,索引视图可改善查询速度。

  行内文本

  行内文本可用于在主页面中存储小文本数据。例如,如果某个表中有一文本列,但文本值通常小到可与行中的其余内容放在同一普通页中,则可以在文本列中设置阈值。阈值用来确定可存储在主页面而非单独的文本页上的最大文本长度。如果大多数数据可放在主页面上,而只有小部分数据比较大,需要创建文本页,采取这种做法就可使性能获得提高。

  若要确定在何种情况下使用此新功能,则需要权衡存储密度(或每个数据页上存储的行数)以及 I/O 性能的改善。例如,某个表中的文本列用于存放注释。该列中有 20% 的文本值较长,而其它 80% 的文本值都小于 100 个字节。对于这种情形,似乎可以采用行内文本解决方案;但是,只有在这样的列中的数据被频繁访问时才应考虑使用行内文本。如果用户频繁访问此表,但只在进行特殊搜索时才查看此注释列,则使用行内文本未必是最好的做法。由于每页存储的行数少,所以存储密度会降低;并且由于表包含更多的页,所以表扫描响应时间也会增加。所以,实现行内文本的最好情况是,存在需要频繁访问的文本列,并且该列的许多值都小于 8 K,可以存储在行中。

  新增数据类型

  SQL Server 2000 引入了三种新的数据类型。bigint 是 8 字节整数类型。sql_variant 可以存储不同数据类型的数据值。第三种数据类型 table 可用于优化性能。Table 变量使 tempdb 的使用效率更高,并且比临时表更加快速。与其它变量一样,它们的作用范围是声明它们的批处理。table 变量的功能类似于临时表,但其性能要高于临时表或游标,并且可更加有效地利用服务器资源。通常,在创建与数据库交互的代码时,一定要考虑利用服务器上可用资源的最佳方法。 

  索引

  通过使用索引,可以优化对数据的访问。因为是否建立索引取决于使用情况,所以不正确的索引是造成数据库缓慢最主要的原因。标准的索引维护工作应该包括周期性校验当前索引方案以及通过适当增删索引使其适应当前的系统使用情况。

  SQL Server 2000 中的几个新增功能使索引维护更加有效,索引管理更加容易。这些增强功能减少了磁盘 I/O 操作,从而增加了索引扫描的性能。在范围扫描可以使用辅助索引时,这一功能尤其有用。 

 
 2003-6-7 19:31:33    建立索引

  建立索引时,存储引擎对行进行采样,并计算使用服务器资源建立索引的最佳方法。通过使用选项,可以控制建立索引的方式,因而可选择控制系统资源的分配方式。可以使用这些选项,并结合您在特定数据库系统方面的知识,平衡对于整体系统的性能是至关重要的进程中的资源,从而使建立索引的操作对事务处理的影响最小。

资源 命令 选项 说明 
内存 sp_configure(高级)
index create memory
指定建立索引操作可以使用的内存总量。 
TempDB create index
sort_in_tempdb
从 tempdb 中分配在索引建立期间用于排序的磁盘空间。如果 tempdb 在单独的磁盘上,此命令会产生更高的 I/O 带宽;并且如果数据库所在空间不是非常连续,该命令还可以使索引页的布局在物理上更加连续。 
CPU sp_configure(高级)
最大并行程度
限制在并行操作中(服务器范围)可使用的处理器(CPU) 的个数。 

  大型系统的另一个可扩展性功能是并行索引建立。SQL Server 2000 企业版具有此功能。在发出单个 CREATE INDEX 语句时,此过程将被自动调用。存储引擎计算数据的要求,然后创建单独的线程,每个线程建立一段索引。 

图 2:并行索引优化

  索引建立也可以使用共享表扫描,从而使这一过程进一步优化。

  整理索引碎片

  SQL Server 2000 支持联机索引重组,相比于以前的版本,这是一个非常大的进步。联机索引重组对事务的吞吐量影响非常小,并且可随时停止并重新启动,而不会影响其运行效果。索引重组操作按较小增量进行,并且可完全恢复。

  随着在表中插入、删除和更新信息,聚集和非聚集索引页最终将变得零碎,从而降低对数据的范围查询的效率。因此,定期整理索引碎片是非常有益的。可以使用 DBCC SHOWCONTIG(该命令在 SQL Server 2000 中已有所改进)分析并报告碎片。

  如果确定索引已变为碎片,就可以使用 DBCC INDEXDEFRAG 命令对其进行重组。该命令以逻辑键的顺序记录页,同时压缩可用空间,移动已建立的扩展中的行以满足填充因子设置。通过提高页面中内容的密度以减少数据扫描时读取的页数,从而提高读取性能。如果索引经常得到维护并且其分布不是完全散碎的,那么运行 DBCC INDEXDEFRAG 对联机性能的影响要远远小于重建索引。

  DBCC INDEXDEFRAG 是众多长期运行的管理操作中的一个,它们内部都使用短小的事务。这些短小的事务可最大限度提高服务器中的并发操作,允许操作停止而不影响工作,并且这些事务被全部记录以便在发生故障时进行恢复。
五. 日志记录和故障恢复 

  事务日志是一个记录流,它记录了从数据库创建到当前时点对数据库所做的更改。每个记录的操作都创建一个日志记录。日志记录由事务生成,并在事务提交时写入磁盘。相反,被事务修改的数据页不会立即写入磁盘,而是先保留在 SQL Server 的缓冲区高速缓存中,稍后再写入磁盘。推迟将数据写入磁盘可最大限度地提高对数据页进行多路访问的性能,并避免中断扫描。在提交时强制将日志写入磁盘是为了确保在服务器关机时不会丢失已完成的工作。

  故障恢复可确保在将数据库变为联机状态之前保持其在事务上的一致性。如果数据库在事务上是一致的,则所有提交的工作都已生效,而任何未提交的工作都变为无效。日志总是定义数据库的正确视图。简而言之,故障恢复就是将数据与事务日志在某一给定时点保持一致的过程。 

  当 SQL Server 启动时,当数据库被连接时,或在从备份恢复数据库的最后一步时,故障恢复将自动执行。在 SQL Server 启动时执行的故障恢复称为重新启动故障恢复或启动故障恢复。使用备份进行故障恢复通常是由于磁盘发生故障。此类故障恢复称为媒体故障恢复。

  重新启动故障恢复是自动进行的,通常可恢复到最近的时点。在使用备份进行故障恢复时,DBA 可以选择恢复到较早的时点。这种故障恢复需要满足一些限制条件。

  每当启动一个 SQL Server 实例时,启动故障恢复会自动运行,它将回滚上次关闭实例时尚未完成的所有事务。在使用备份进行故障恢复时,DBA 可以选择恢复到较早的时点。这种故障恢复需要满足一些限制条件。无论何种情况,故障恢复操作都基于此目标时点。 

 
 2003-6-7 19:32:58    故障恢复分为两个阶段: 

  恢复所有更改,直到达到事务日志中的目标时点。 

  撤消由在恢复停止点仍处于活动状态的事务所执行的所有操作。

  SQL Server 使用检查点加速重新启动故障恢复。检查点强制将当前缓冲区高速缓存中所有已修改的数据页保存到磁盘上。这将为故障恢复的恢复阶段创建一起点。由于检查点的开销非常大,所以 SQL Server 自动对检查点进行管理,以保证在尽量缩短重新启动所花时间的同时尽可能提高性能。

  在 SQL Server 2000 中,成功完成的写入必须可持久存储在磁盘中。如果使用写缓存磁盘存储,请与您的存储设备供应商联系,确认高速缓存是否容错。容错能力表示高速缓存可不受电源故障或操作员操作的影响。如果缓存没有容错能力,则应不使用。

  逻辑日志标记

  在 SQL Server 7.0 中,已经可以恢复到任何指定时点。如果出现硬件故障,则恢复过程是相当简单的。然而,对数据库的另一种威胁可能是输入了无效的数据,或者有效数据被用户操作所破坏。在这种情况下,需要确定问题发生的开始时间。在 SQL Server 7.0 中,解决这种问题的唯一方法是将日志恢复成数据库副本,直到问题重现,然后再对产品映像执行恢复操作,直到在所发现的问题出现时刻之前的时点。

  在 SQL Server 2000 中,可以在日志中标记事务。之后,如果需要恢复,就可以参考执行时使用的标记,而不必使用规定的时刻。为此,请使用 BEGIN TRANSACTION 的语句和 WITH MARK [说明] 子句。标记存储在 msdb 中。故障恢复可以包括包含标记的事务,也可以恰恰在包含标记的事务前停止。例如,如果某个进程以批处理方式运行并且更改了许多记录,那么可以使用此功能以确保,当进程运行在错误环境中时可以将数据回滚到执行命令的时点。

  标记名称不必唯一。若要指定所需的事务,请指定 datetime 值。该操作的语法为:
RESTORE LOG WITH [ STOPBEFOREMARK|STOPAFTERMARK ] = @TaggedTransaction AFTER @datetime
也可以对分布式事务使用标记(称为分布式标记),以支持将多个相关数据库恢复到事务上一致的状态。相关数据库可以位于 SQL Server 的同一或不同实例上。可以定期对一组数据库设置分布式标记(例如,每五分钟一次)。如果其中某个数据库的事务日志被损坏,则必须将这组数据库恢复到更早的时点。分布式标记可提供这一时点。使用分布式标记,就可以在对多个相关数据库进行备份时不用费心地确定备份的时刻。

  收缩事务日志

  SQL Server 7.0 中不能立即执行日志收缩操作。该操作被推迟到下一次备份或删节事务日志。这种方式使许多 SQL Server 7.0 客户非常烦恼。SQL Server 2000 可以立即收缩日志,并且可在日志备份后指出是否可以进行进一步收缩。这时,可以在日志备份完成后再次运行收缩命令。

  日志大小取决于当前故障恢复模式以及应用程序设计。如果发现需要定期收缩日志,请查明造成问题的原因。应该进一步调查日志添满的原因,而不要只是一味地使用收缩命令维护日志。

  故障恢复模式

  使用 SQL Server 2000 中增加的故障恢复模式可以方便到实施数据保护计划。这些模式都在性能、日志空间要求和媒体(磁盘)故障保护之间进行了取舍。共有三种模式,它们是:简单故障恢复、完全故障恢复和大容量记录。

  选择故障恢复模式时,应考虑数据库的使用情况和可用性要求,同时选择的模式应有助于确定适当的备份和恢复过程。这些故障恢复模式只适用于媒体故障恢复,即使用备份进行故障恢复。重新启动故障恢复所有提交的工作。

  故障恢复模式间的转换非常容易。例如,在大型数据库中,既可使用完全模式,也可以使用大容量记录模式,或同时使用这两种模式。可以在白天使用完全模式,而在夜晚或在包含大容量插入以及重建索引的数据装载过程中使用大容量记录模式。也可以在运行数据装载时切换到大容量记录模式,然后再切换回完全模式,运行事务日志备份,而且能够恢复到模式切换时点,而不必运行完全数据库备份。此功能可更有效地进行大容量处理操作;而所要做的只是将以前的事务日志进行备份。

  要更改故障恢复模式,请使用以下语法:
  ALTER DATABASE SET RECOVERY RecoveryModel

  简单故障恢复模式

  简单故障恢复模式通常需要很少的日志空间,但如果数据或日志文件被损坏,则它造成的潜在工作损失是最大的。因为在这种模式下只记录基本故障恢复所需的事件。使用简单故障恢复模式时,只能进行完全数据库备份和差异数据库备份。在出现故障时,必须重新完成自从上次备份后所有提交的工作。此模式对管理员是最简单的,但并不适用于关键性任务的应用程序,因为这种程序通常不允许丢失已提交的工作。

  此模式类似于 SQL Server 7.0 及以前版本中的 truncate log on checkpoint 选项。 

 
 2003-6-7 19:34:47    完全故障恢复模式

  在完全故障恢复模式中,所有一切都被记录。完全故障恢复模式提供了全面的保护,以防止损坏的数据文件对工作造成损失。如果事务日志被损坏,则从最近一次日志备份后提交的工作都将丢失,并且必须重新手动完成。

  即使使用完全故障恢复模式,也最好使用容错磁盘存储事务日志,以防止数据丢失。完全故障恢复模式还允许恢复到指定的时点。

  大容量记录故障恢复模式

  大容量记录故障恢复模式为大容量操作提供了最高的性能。而且,这些操作在该模式下占用的日志空间要小于在完全故障恢复模式下占用的空间。例如,新页的分配将被记录,而插入页中的数据则不被记录。在 SQL Server 2000 中,大容量操作由大容量装载(BCP 和 BULK INSERT,包括当他们在 DTS 包中运行时)、SELECT INTO、CREATE INDEX、WRITETEXT 和 UPDATETEXT 组成。

  与完全故障恢复模式相比,大容量记录故障恢复模式减少了对大容量操作的日志记录。请记住,在需要进行故障恢复时,如果日志被损坏或在最近一次日志备份后又进行了大容量操作,则在最后一次日志备份后对数据库进行的更改将会丢失。

  此模式不支持恢复到指定的时点,但它允许恢复到包含大容量更改的事务日志备份的末尾。使用大容量记录故障恢复模式进行的事务日志备份包含由大容量操作修改的扩展。此功能改善了对日志传送的支持,因为不用担心备份在大容量操作后会变为无效。SQL Server 维护映射以跟踪修改的数据扩展,这样做,可优化 SQL Server 用于标识更改的进程。

  改善的备份功能

  除引入故障恢复模式以简化常规数据保护外,SQL Server 2000 还改善了管理特性:快照技术、差异备份和安全性都已得到加强。 

  事务日志备份链永远不会断开。在 SQL Server 7.0 中,某些操作(如向数据库中添加文件)会中断日志链,并且要求以后进行完全数据库备份。 

  备份操作不会与应用程序或其他管理操作发生冲突。例如,备份可与大容量操作(如创建索引和批处理装载)同时进行。 

  日志和文件备份可以同时进行。 

  无论系统正在进行何种活动,SQL Server 2000 都对无人值守备份操作实现良好的支持。

  SQL Server 支持与独立硬件和软件供应商共同完成的快照备份和恢复技术。快照备份使得在进行备份时占用的系统资源最少,甚至可以不占用资源。这种技术对于中型或大型数据库尤其有益,因为在这种环境中可用性是非常重要的。这种技术的主要优势在于: 

  可在非常短的时间(通常可以秒计)内创建备份,基本上不会对服务器造成任何影响。 

  可以使用磁盘备份非常快地恢复数据库。 

  另一台主机可创建备份,且不会对生产系统造成影响。 

  可以立即创建生产数据库的副本,以用于报告或测试目的。 

  快照备份和恢复技术是与第三方硬件和/或软件供应商协作共同完成的,这些供应商使用了 SQL Server 2000 为实现该技术而提供的特定功能。备份技术通常使用拆分磁盘镜像集的方法,创建要备份的数据的即时副本。在恢复时,原有数据就可立即投入使用。基本磁盘的同步是在后台进行的,因此几乎可以实现即时恢复。

  差异数据库备份的运行时间与上次完全备份后数据更改的总量成正比。数据更改越少,备份越快。SQL Server 2000 使用映射跟踪自最近一次数据库或文件备份后发生更改的数据扩展,以确保可更有效地定位这些扩展。此外,SQL Server 2000 支持文件差异备份。

  备份仍会收集自最近一次完全备份后对数据库进行的更改,运作方式与故障恢复相同。然而,这种备份是非常快的,因为它们只记录少部分更改过的信息,尤其是当数据库非常大而更改的数据又非常少时。

  为确保安全,可以使用密码保护备份媒体和备份集。这样就可防止未授权的用户在备份中添加数据或恢复数据库。

  六. 增强的管理功能

  在 SQL Server 2000 中,存储引擎的若干管理功能得到了加强。

  数据库验证

  DBCC 提供了各种管理能力,包括验证数据库一致性的 CHECK 命令。

  使用 SQL Server 7.0 和 SQL Server 2000 的经验表明,数据库的不一致性是由硬件问题引起的,但是数据库引擎或应用程序在正常操作中不一定能检测到这种问题。这种情况更可能出现在不经常访问的数据上。为解决这种问题,SQL Server 2000 引入一种检查模式 Physical_Only,可以探测到绝大部分由硬件引发的问题。探测过程非常快,速度与磁盘扫描速度相当,并且其对资源的消耗也很小。

  由于 SQL Server 存储引擎在基础体系结构上的改进(从 SQL Server 7.0 开始),已不必在常规维护时进行数据库验证。然而,Microsoft 仍然将数据库验证工具作为管理任务关键数据的重要组成部分。Microsoft 建议: 

  根据对基本硬件(特别是磁盘子系统)的信心,不定期运行 Physical_Only 检查。 

 
 2003-6-7 19:36:16    在关键时刻,如在硬件或软件升级时,或怀疑出现任何问题时,进行完整数据库检查。 

  Microsoft 不推荐在进行常规维护时执行完整数据库检查。

  SQL Server 2000 还在数据库验证方面作出了如下重大改进: 

  默认情况下,检查可以在联机状态下完成。联机检查对事务工作负载的影响很小。这种影响的大小取决于系统负载、硬件配置和 tempdb 的速度。Microsoft 的实验结果表明,对于中等 OLTP 工作负载(50% 的 CPU 使用率),这种影响为 15% 到 20%。提供的 TABLOCK 选项会强制检查索取共享表锁,这可以使检查的运行速度更快,但会妨碍更新。 

  检查操作在对称的多处理器 (SMP) 计算机中是以并行方式完成的,它受限于在该 SQL Server 实例中设置的最大并行程度。 

  SQL Server 2000 检查命令继续支持 SQL Server 7.0 中引入的修复功能。在某些情形,脱机修复可以替代备份恢复。

  数据库状态控制

  SQL Server 2000 对 ALTER DATABASE 语句进行了改进,改进后的语句允许通过 Transact-SQL 对数据库状态实现更多的控制。现在,所有数据库选项都可通过 ALTER DATABASE 命令进行灵活修改;在以后的版本中,将不再更新 sp_dboption 和 databaseproperty()。Transact-SQL 命令 sp_88bifa必发唯一官网,helpdb 和 DatabasePropertyEx() 提供有关数据库状态的更多信息。

  下表列出了数据库状态选项。

选项类型 可用设置 
用户权限 SINGLE_USERRESTRICTED_USERMULTI_USER 
可用性 ONLINEOFFLINE 
更新能力 READ_ONLYREAD_WRITE 

  SQL Server 还根据数据库中的条件设置以下状态:复原 (restoring)、恢复 (recovering) 和待定 (suspect)。数据库选项可通过以下方式进行设置:ALTER DATABASE 语句的 SET 子句、sp_dboption 系统存储过程或 SQL Server Enterprise Manager(在某些情况下)。

  在数据库状态发生变化后,更改数据库状态的会话仍然保持连接,而与新状态不一致的会话可被终止,并且其事务将被回滚。会话终止选项如下: 

  立即终止 

  在指定时间后终止 

  允许活动进程正常完成 

  检查活动,如果发现活动用户会话,则忽略状态更改 

  如下为语法的两个示例:

  alter database accting set read_only with rollback immediate
  alter database accting set single_user with rollback after 60 seconds

  系统进程 ID 和工作单元

  管理方面的另一个改进是 KILL 命令,该命令在停止进程时使用。改进后的 KILL 命令具有状态反馈。所以,如果要了解 KILL 命令的状态,请运行以下命令:

  KILL SPID WITH STATUSONLY

  在试图停止已由其它 KILL 命令停止的系统进程 ID (SPID) 时,系统将返回相同的状态信息。

  在 SQL Server 2000 中,MS DTC 事务可以在没有相关连接或 SPID 的情况下 存在。因此,在等待事务或工作单元完成之前,连接可由其他进程使用。当 MS DTC 事务管理器发送消息声明任务已完成时,您可以提交事务,也可以回滚事务。这就叫做一个工作单元 (UOW),它是 MS DTC 用于事务的事务标识符。UOW 没有 SPID。 

 
 2003-6-7 19:37:22    动态调优

  在 SQL Server 2000 中,基于使用的性能优化是动态管理的,无需手动调整。静态参数已被去除,但仍然保留了对某些资源的管理控制(例如,设置 SQL Server 可以使用的最大内存数)。相对于根据平均值和估计值进行手工计算的系统,这种方法更加精确,反应更加快捷。这样,您可以将注意力集中在数据库管理的设计方面。传统的数据库系统需要大量的手工管理和调优工作。例如,为了根据使用情况来优化系统,DBA 必须监视系统,不断记录大量的统计数据,以便选择可提供最佳系统性能的静态设置。然后,DBA 要重新评估系统以确定新设置的效果,接着又从头开始调优过程。

  SQL Server 2000 在存储引擎中引入了动态算法,它可主动监视服务器的使用情况,并在内部调整设置。SQL Server 2000 中的动态反馈和分析可将设置保持在绝对优化值的 10% 以内(参见图 3),从而使系统的性能更优,适应性更强。
七. 数据存储组件

  SQL Server 2000 协同 Windows 2000 操作系统平衡所有可用 CPU 的工作量。如果正在运行一个特定的 SQL Server 实例,并且其他应用程序未占用相同的资源,请将处理器相关设置保持为默认值,以便使全部的处理器得到充分利用。SQL Server 可利用多个处理器上的并行处理能力执行查询、索引建立、DBCC 和其他操作。SQL Server 2000 标准版最多可支持四个处理器和 2 GB 物理内存 (RAM)。企业版提高到新的水平,支持多达 32 个处理器和 64 GB 物理内存 (RAM)。

  SQL Server 实例的主内存源称为它的内存池。在 SQL Server 实例中几乎所有使用内存的数据结构都是从内存池分配的。从内存池分配的对象示例包括缓冲区高速缓存(其中存储最近读取的数据)和过程高速缓存(其中存储最近的执行计划)。 

  内存池中的分配是高度动态的。为优化性能,SQL Server 不断调整分配给不同区域的内存池大小。例如,当存储的执行计划的数量很少时,会通过将更多可用内存分配给数据高速缓存来调整内存池,从而优化资源的使用。

  SQL Server 2000 尽可能使用内存以减少磁盘 I/O。为此,SQL Server 在物理内存 (RAM) 中使用缓冲区高速缓存装载最近引用的数据,这样,这些数据可被重复使用。减少磁盘 I/O 和提供数据库系统速度的潜在方法是增加 SQL Server 可用的物理内存 (RAM)。

  通常,内存设置不需要任何调整。然而,在某些情况下可以对它们进行控制。例如,当在同一服务器上运行 SQL Server 的多个实例时,特别是在使用故障转移群集时,需要特别关注内存。如果在运行 SQL Server 的服务器上运行其他应用程序,也需要监视内存的使用情况。 

 
 2003-6-7 19:38:17      SQL Server 2000 利用 Windows 2000 的新功能,可寻址超过 3GB 的物理内存 (RAM) 。参见图 4。SQL Server 2000 企业版可以使用 Windows 2000 Advanced Server 或 Windows 2000 Datacenter Server 所允许的内存量。

  文件、文件组和磁盘

  SQL Server 在磁盘文件中存储数据和日志。在基本安装中,默认情况下,创建的数据和日志文件保存在服务器配置中指定的默认位置。然而,为了获得最优的性能和管理能力,可以应用以下几条基本原则: 
尽可能将数据分布到多个磁盘、信道和控制器中。 

  通常,磁盘越多(无论其单个容量),访问磁盘(控制器和信道)的速度以及存储引擎读写数据的速度也就越快。系统使用量越大,数据文件与日志文件的分离程度(将它们存储在不同的物理驱动器上)也就越重要。此外,由于 tempdb 的使用已发生变化,所以应该将 tempdb 存储在大磁盘集上;例如,与数据文件存放在一起或一组磁盘上。 

  使用文件组,使企业数据库更易于管理。 

  每个数据库都以一个默认的文件组开始。由于 SQL Server 2000 可在不附加文件组的情况下高效工作,因此许多系统都无需添加用户定义的文件组。然而,随着系统的增长,使用附加的文件组可提供更高的管理能力,当然这要求由称职的 DBA 实施和维护。

  在 SQL Server 2000 中,如果将数据库上的特定文件组设置为只读,则该文件组中的数据不能更改,但仍可以管理诸如权限等目录信息。

  注意:在 SQL Server 2000 中,数据库引擎中的异步 I/O 操作数实现了动态管理,并且不受使用的文件或文件组个数的影响,这一点与 SQL Server 7.0 相同。

  实施或优化数据库设计时,数据库管理员(数据库系统工程师)需要考虑数据库存储组件的配置,尤其是物理和逻辑磁盘的布局、数据库文件在磁盘中的排列。

  八. 总结

  灵活性的增强和性能控制的提高,使数据库管理员可以在掌握数据库技术的使用技巧和丰富数据库的使用经验时,将精力集中在管理数据库代码、设计和存储组件等方面,并以此作为数据库系统管理的最佳途径。SQL Server 2000 数据库引擎为各种数据库实现提供了通用的可扩展性和灵活性。 

本文由88bifa必发唯一官网发布,转载请注明来源:SharePoint磁盘体量规划88bifa必发唯一官网,磁盘请