1.数据库镜像
通过新数据库镜像方法，将记录档案传送性能进行延伸。您将可以使用数据库镜像，通过将自动失效转移建立到一个待用服务器上，增强您SQL服务器系统的可用性。
2.在线恢复
使用SQL2005版服务器，数据库管理人员将可以在SQL服务器运行的情况下，执行恢复操作。在线恢复改进了SQL服务器的可用性，因为只有正在被恢复的数据是无法使用的，而数据库的其他部分依然在线、可供使用。
3.在线检索操作
在线检索选项可以在指数数据定义语言（DDL）执行期间，允许对基底表格、或集簇索引数据和任何有关的检索，进行同步修正。例如，当一个集簇索引正在重建的时候，您可以对基底数据继续进行更新、并且对数据进行查询。
4.快速恢复
新的、速度更快的恢复选项可以改进SQL服务器数据库的可用性。管理人员将能够在事务日志向前滚动之后，重新连接到正在恢复的数据库。
5.安全性能的提高
SQL Server 2005包括了一些在安全性能上的改进，例如数据库加密、设置安全默认值、增强密码政策、缜密的许可控制、以及一个增强型的安全模式。
6.新的SQL Server Management Studio
SQL Server 2005引入了SQL Server Management Studio，这是一个新型的统一的管理工具组。这个工具组将包括一些新的功能，以开发、配置SQL Server数据库，发现并修理其中的故障，同时这个工具组还对从前的功能进行了一些改进。
7.专门的管理员连接
SQL Server 2005将引进一个专门的管理员连接，即使在一个服务器被锁住，或者因为其他原因不能使用的时候，管理员可以通过这个连接，接通这个正在运行的服务器。这一功能将能让管理员，通过操作诊断功能、或Transact—SQL指令，找到并解决发现的问题。
8.快照隔离
我们将在数据库层面上提供一个新的快照隔离（SI）标准。通过快照隔离，使用者将能够使用与传统一致的视野观看数据库，存取最后执行的一行数据。这一功能将为服务器提供更大的可升级性。
9.数据分割
数据分割 将加强本地表检索分割，这使得大型表和索引可以得到高效的管理。
10.增强复制功能
对于分布式数据库而言，SQL Server 2005提供了全面的方案修改（DDL）复制、下一代监控性能、从甲骨文（Oracle）到SQL Server的内置复制功能、对多个超文本传输协议（http）进行合并复制，以及就合并复制的可升级性和运行，进行了重大的改良。另外，新的对等交易式复制性能，通过使用复制，改进了其对数据向外扩展的支持。
SQL Server 2005有关开发的10个最重要的特点
特点 描述
.NET 框架主机
使用SQL Server 2005，开发人员通过使用相似的语言，例如微软的Visual C# .NET和微软的Visual Basic，将能够创立数据库对象。开发人员还将能够建立两个新的对象——用户定义的类和集合。
XML 技术
在使用本地网络和互联网的情况下，在不同应用软件之间散步数据的时候，可扩展标记语言（XML）是一个重要的标准。SQL Server 2005将会自身支持存储和查询可扩展标记语言文件。
ADO.NET 2.0 版本
从对SQL类的新的支持，到多活动结果集（MARS），SQL Server 2005中的ADO.NET将推动数据集的存取和操纵，实现更大的可升级性和灵活性。
增强的安全性
SQL Server 2005中的新安全模式将用户和对象分开，提供fine-grain access存取、并允许对数据存取进行更大的控制。另外，所有系统表格将作为视图得到实施，对数据库系统对象进行了更大程度的控制。
Transact-SQL 的增强性能
SQL Server 2005为开发可升级的数据库应用软件，提供了新的语言功能。这些增强的性能包括处理错误、递归查询功能、关系运算符PIVOT, APPLY, ROW_NUMBER和其他数据列排行功能，等等。
SQL 服务中介
SQL服务中介将为大型、营业范围内的应用软件，提供一个分布式的、异步应用框架。
通告服务
通告服务使得业务可以建立丰富的通知应用软件，向任何设备，提供个人化的和及时的信息，例如股市警报、新闻订阅、包裹递送警报、航空公司票价等。在SQL Server 2005中，通告服务和其他技术更加紧密地融合在了一起，这些技术包括分析服务、SQL Server Management Studio。
Web服务
使用SQL Server 2005，开发人员将能够在数据库层开发Web服务，将SQL Server当作一个超文本传输协议（HTTP）侦听器，并且为网络服务中心应用软件提供一个新型的数据存取功能。
报表服务
利用SQL Server 2005, 报表服务可以提供报表控制，可以通过Visual Studio 2005发行。
全文搜索功能的增强
SQL SERVER 2005将支持丰富的全文应用软件。服务器的编目功能将得到增强，对编目的对象提供更大的灵活性。查询性能和可升级性将大幅得到改进，同时新的管理工具将为有关全文功能的运行，提供更深入的了解。
SQL SERVER 2005有关商业智能特征的10个最重要的特点
特点 描述
分析服务
SQL SERVER 2005的分析服务迈入了实时分析的领域。从对可升级性性能的增强、到与微软Office软件的深度融合，SQL SERVER 2005将帮助您，将商业智能扩展到您业务的每一个层次。
数据传输服务(DTS)
DTS数据传输服务是一套绘图工具和可编程的对象，您可以用这些工具和对象，对从截然不同来源而来的数据进行摘录、传输和加载（ETL），同时将其转送到单独或多个目的地。SQL SERVER 2005将引进一个完整的、数据传输服务的、重新设计方案，这一方案为用户提供了一个全面的摘录、传输和加载平台。
数据挖掘
我们将引进四个新的数据挖掘运算法，改进的工具和精灵，它们会使数据挖掘，对于任何规模的企业来说，都变得简单起来。
报表服务
在SQL SERVER 2005中，报表服务将为在线分析处理（OLAP）环境提供自我服务、创建最终用户特别报告、增强查询方面的开发水平，并为丰富和便于维护企业汇报环境，就允许升级方面，提供增进的性能。
集群支持
通过支持容错技术移转丛集、增强对多重执行个体的支持、以及支持备份和恢复分析服务对象和数据，分析服务改进了其可用性。
主要运行指标
主要运行指标(KPIs)为企业提供了新的功能，使其可以定义图表化的、和可定制化的商业衡量标准，以帮助公司制定和跟踪主要的业务基准。
可伸缩性和性能
并行分割处理，创建远程关系在线分析处理(ROLAP)或混合在线分析处理(HOLAP)分割，分布式分割单元，持续计算，和预制缓存等特性，极大地提升了SQL Server 2005中分析服务的可伸缩性和性能。
单击单元
当在一个数据仓库中创建一个单元时，单元向导将包括一个可以单击单元检测和建议的操作。
预制缓存
预制缓存将MOLAP等级查询运行与实时数据分析合并到一起，排除了维护在线分析处理存储的需要。显而易见，预制缓存将数据的一个更新备份进行同步操作，并对其进行维护，而这些数据是专门为高速查询而组织的、它们将最终用户从超载的相关数据库分离了出来。
与Microsoft Office System集成
在报表服务中，由报表服务器提供的报表能够在Microsoft SharePoint门户服务器和Microsoft Office System应用软件的环境中运行，Office System应用软件其中包括Microsoft Word和Microsoft Excel。您可以使用SharePoint功能，订阅报表、建立新版本的报表，以及分发报表。您还能够在Word或Excel软件中打开报表，观看超文本连接标示语言（HTML）版本的报表。
SQLServer2005怎样评估和管理索引？
SQLServer2005怎样评估和管理索引？
--王成辉翻译整理，转贴请注明出处
问题：SQLServer2005怎样评估和管理索引？
（1）怎样知道索引是否有用？它们是怎样使用的？
（2）哪些表和索引是没用或者很少用的？
（3）索引维护的成本与它的性能比多少合适？
（4）存在索引争夺吗？
（5）更多的索引好还是更少的索引好？
回答：
SQLServer2005动态管理视图(DMVs)返回会话、事务、请求的服务器状态信息。它可用于诊断、内存和过程调优、监控（SQLServer2000不支持）。SQLServer引擎跟踪详细的资源使用情况，用select语句从DMVs中可查到，但是这些信息不会长期驻留在磁盘上。
由于索引提供了代替表扫描的一个选择，且DMVs返回索引使用计数，所以可以比较索引的成本和其性能。这个比较包括保持索引最新的成本，与使用索引而不是表扫描读数据的性能之比。谨记一个更新或删除操作先要读数据从而定位数据，然后对定位的数据进行写操作。一个插入操作在所有的索引上只是写操作。因此，一个大量的插入将使写操作次数超过读操作次数。一个大量的更改操作（包括更新和删除），读和写的次数通常很接近（假定没有‘记录找不到’的情况发生）。一个大量的读操作，读的次数将超过写。引用约束如外键还要求额外的读操作（对于插入、更新、删除而言）去确保引用完整性得到维护。
（1）怎样知道索引是否有用？它们是怎样使用的？
首先来看看索引是否是有用的。DDL是用来创建对象（如索引）且更新目录的。创建索引不是使用索引，所以在索引相关的DMVs不会有记录，除非索引真正被使用。当一个索引被Select、 Insert、 Update或者 Delete引用时，会被sys.dm_db_index_usage_stats捕获。如果运行一个典型的SQLServer使用周期后，所有的有用的索引都会记录在sys.dm_db_index_usage_stats中。这样，任何一个在sys.dm_db_index_usage_stats中找不到的索引就是没用的索引（在最近的一个SQLServer使用周期里）。未使用的索引可通过下面的方式找到：
（2）哪些表和索引是没用或者很少用的？
------ 未使用的表和索引。表都有一个索引ID，如果是0则为堆表，1则为聚集索引
Declare @dbid int
Select @dbid = db_id('Northwind')
Select objectname=object_name(i.object_id)
, indexname=i.name, i.index_id
from sys.indexes i, sys.objects o
where objectproperty(o.object_id,'IsUserTable') = 1
and i.index_id NOT IN (select s.index_id
from sys.dm_db_index_usage_stats s
where s.object_id=i.object_id and
i.index_id=s.index_id and
database_id = @dbid )
and o.object_id = i.object_id
order by objectname,i.index_id,indexname asc
使用很少的索引和频繁使用的索引一样，都会记录在sys.dm_db_index_usage_stats中。为了找出这些索引，需要查看诸如user_seeks、
user_scans、 user_lookups和user_updates的列。
--- 使用很少的索引排在最先
declare @dbid int
select @dbid = db_id()
select objectname=object_name(s.object_id), s.object_id, indexname=i.name, i.index_id
, user_seeks, user_scans, user_lookups, user_updates
from sys.dm_db_index_usage_stats s,
sys.indexes i
where database_id = @dbid and objectproperty(s.object_id,'IsUserTable') = 1
and i.object_id = s.object_id
and i.index_id = s.index_id
order by (user_seeks + user_scans + user_lookups + user_updates) asc
（3）索引维护的成本与它的性能比多少合适？
如果一个表是频繁更改的而又有很少用到的索引，那么维护索引的成本将超过索引带来的好处。为了比较成本和其好处，可以如下使用表值函
数sys.dm_db_index_operational_stats：
--- sys.dm_db_index_operational_stats
declare @dbid int
select @dbid = db_id()
select objectname=object_name(s.object_id), indexname=i.name, i.index_id
, reads=range_scan_count + singleton_lookup_count
, 'leaf_writes'=leaf_insert_count+leaf_update_count+ leaf_delete_count
, 'leaf_page_splits' = leaf_allocation_count
, 'nonleaf_writes'=nonleaf_insert_count + nonleaf_update_count + nonleaf_delete_count
, 'nonleaf_page_splits' = nonleaf_allocation_count
from sys.dm_db_index_operational_stats (@dbid,NULL,NULL,NULL) s,
sys.indexes i
where objectproperty(s.object_id,'IsUserTable') = 1
and i.object_id = s.object_id
and i.index_id = s.index_id
order by reads desc, leaf_writes, nonleaf_writes
--- sys.dm_db_index_usage_stats
select objectname=object_name(s.object_id), indexname=i.name, i.index_id
,reads=user_seeks + user_scans + user_lookups
,writes = user_updates
from sys.dm_db_index_usage_stats s,
sys.indexes i
where objectproperty(s.object_id,'IsUserTable') = 1
and s.object_id = i.object_id
and i.index_id = s.index_id
and s.database_id = @dbid
order by reads desc
go
sys.dm_db_index_usage_stats和sys.dm_db_index_operational_stats不同之处在于：前者是每次访问加1，而后者依赖于操作、页、或行来计数。
（4）存在索引争夺吗？
可以在sys.dm_db_index_operational_stats中查看索引争夺（如等待锁）。列row_lock_count, row_lock_wait_count,
row_lock_wait_in_ms, page_lock_count, page_lock_wait_count, page_lock_wait_in_ms, page_latch_wait_count,
page_latch_wait_in_ms, pageio_latch_wait_count, pageio_latch_wait_in_ms详细描述了锁和在等待期间的锁争夺。可以通过比较锁和阻塞等待的计数来得到均值，如下：
declare @dbid int
select @dbid = db_id()
Select dbid=database_id, objectname=object_name(s.object_id)
, indexname=i.name, i.index_id --, partition_number
, row_lock_count, row_lock_wait_count
, [block %]=cast (100.0 * row_lock_wait_count / (1 + row_lock_count) as numeric(15,2))
, row_lock_wait_in_ms
, [avg row lock waits in ms]=cast (1.0 * row_lock_wait_in_ms / (1 + row_lock_wait_count) as numeric(15,2))
from sys.dm_db_index_operational_stats (@dbid, NULL, NULL, NULL) s, sys.indexes i
where objectproperty(s.object_id,'IsUserTable') = 1
and i.object_id = s.object_id
and i.index_id = s.index_id
order by row_lock_wait_count desc
下面的报告显示在表[Order Details]的锁，OrdersOrder_Details表上的索引。虽然锁出现的时间小于2％，但当它发生时，平均的锁时间是
15. 7秒。
使用事件探查器跟踪下面的阻塞进程报告是很重要的。你可以使用sp_configure ‘Blocked Process Threshold’,15设置锁进程报表的阈值为
15 。然后，超过15秒后运行跟踪去捕获锁。
事件探查器能跟踪锁和阻塞。跟踪结果可以保存到跟踪文件里以便进行分析。你可以找到锁产生的原因。本例中锁是由存储过程NewCustOrder引起的，阻塞是由存储过程UpdCustOrderShippedDate引起的。
本例中事件探查器的锁进程跟踪报告显示是由存储过程引起的，你不能查看存储过程里引起锁的实际语句。然而你可以用stmtstart和stmtend找到过程NewCustOrder里引起阻塞的语句。使用上面的报告，你能够通过提供sqlhandle、stmtstart和stmtend得到存储过程NewCustOrder的阻塞语句，如下：
declare @sql_handle varbinary(64),
@stmtstart int,
@stmtend int
Select @sql_handle = 0x3000050005d9f67ea8425301059700000100000000000000
Select @stmtstart = 920, @stmtend = 1064
select
substring(qt.text,s.statement_start_offset/2,
(case when s.statement_end_offset = -1
then len(convert(nvarchar(max), qt.text)) * 2
else s.statement_end_offset end -s.statement_start_offset)/2)
as "blocked statement"
,s.statement_start_offset
,s.statement_end_offset
,batch=qt.text
,qt.dbid
,qt.objectid
,s.execution_count
,s.total_worker_time
,s.total_elapsed_time
,s.total_logical_reads
,s.total_physical_reads
,s.total_logical_writes
from sys.dm_exec_query_stats s
cross apply sys.dm_exec_sql_text(s.sql_handle) as qt
where s.sql_handle = @sql_handle
and s.statement_start_offset = @stmtstart
and s.statement_end_offset = @stmtend
你能使用下面的存储过程实时的捕获在存储过程里实际引起锁的语句：
create proc sp_block_info
as
select t1.resource_type as [lock type]
,db_name(resource_database_id) as [database]
,t1.resource_associated_entity_id as [blk object]
,t1.request_mode as [lock req] --- lock requested
,t1.request_session_id as [waiter sid] --- spid of waiter
,t2.wait_duration_ms as [wait time]
,(select text from sys.dm_exec_requests as r --- get sql for waiter
cross apply sys.dm_exec_sql_text(r.sql_handle)
where r.session_id = t1.request_session_id) as waiter_batch
,(select substring(qt.text,r.statement_start_offset/2,
(case when r.statement_end_offset = -1
then len(convert(nvarchar(max), qt.text)) * 2
else r.statement_end_offset end - r.statement_start_offset)/2)
from sys.dm_exec_requests as r
cross apply sys.dm_exec_sql_text(r.sql_handle) as qt
where r.session_id = t1.request_session_id) as waiter_stmt --- statement blocked
,t2.blocking_session_id as [blocker sid] -- spid of blocker
,(select text from sys.sysprocesses as p --- get sql for blocker
cross apply sys.dm_exec_sql_text(p.sql_handle)
where p.spid = t2.blocking_session_id) as blocker_stmt
from
sys.dm_tran_locks as t1,
sys.dm_os_waiting_tasks as t2
where
t1.lock_owner_address = t2.resource_address
go
exec sp_block_info
（5）更多的索引好还是更少的索引好？
记住索引既有维护的成本又可提高读的性能，所有索引的成本和性能可以通过比较读和写而得到。读索引可以避免表扫描，然而索引的维护以
保持最新需要成本。可以很容易的找到索引是否使用还是很少使用。在最后的这个分析中，索引的成本性能是比较主观的问题。原因在于大量
的读与写较高的依赖于工作量和频率。另外，超过大量读写的定性因素是要考虑的第二个因素：包括重要程度很高的每月一次的管理报告或每
季的VP报告。
insert会执行所有索引的写操作，但是没有无关联的读（除非有引用约束）。除了select外，update和delete都会执行读操作，限定行的写操作也会执行。OLTP存在大量的小事务，还有频繁的查询、插入、更新、删除操作。数据仓库典型地包括高度集中的批量写和在线的读。
SQL语句 读操作 写操作
select Yes No
insert No Yes（所有的索引）
update Yes Yes（特定行）
delete Yes Yes（特定行）
一般说来，在一个高事务的OLTP环境下，保持索引的功能最小化，因为高事务伴随索引维护的成本和潜在的阻塞。相反，对于数据仓库而言，在更新时执行的批处理仅维护一次索引，这样对于在线用户来说有更多的索引比较好。
总而言之，SQLServer2005的一个重要的新特点包括动态管理视图（DMVs）。DMVs可用于诊断、内存和过程调优、监控（SQLServer2000不支持）。DMVs在回答诸如索引使用、索引的成本性能、索引争夺等实际问题时是有帮助的。最后使用select语句可以查询DMVs，但是这些信息不会长期驻留在磁盘上。这样它们反映了最后一个SQLServer周期服务器状态信息的变化。
还有它提供了一些新的特性，比如文件流支持、T-SQL改进（TOP子句等）、数据库镜像、透明客户端重定向、新的居于架框安全模式、内建HTTP服务器等。 拒绝代溝！ 2008-07-03 10:48 检举
来源：https://www.cnblogs.com/miaoyuanyan/archive/2008/07/29/1255449.html