xiaoxinlucky
超级版主
帖子
604
精华
12
无忧币 2017
积分 1392
阅读权限 200
来自 (保密)
|
发表于:2008-1-7 11:43
标题：SQL Server2005：64位平台的优势
＜上一帖 |
下一帖＞
摘要：
和32位环境中运行的SQL Server相比，Microsoft SQL Server 2005(64-bit)在内存使用和并行处理的性能上有着显著的提高。本文描述了64位解决方案的效能，突出了和32位环境的差别，并且讨论了一些能够获益于64位环境中的SQL Server的运行的应用程序和应用场景。本文帮助读者区分哪种工作能够获益于Microsoft SQL Server 2005 (64-bit)，并对它的部署和运行做出适当的期望。
目录
执行摘要
简介
读者
概述：数据库性能和可伸缩性
SQL Server 2005 (64-bit)
SQL Server 2005 (64-bit)硬件需求
SQL Server 2005 (64位)组件
64位架构的优势
应用AWE 的SQL Server 2005 (32位)
AWE: 概述 5
AWE的局限性
AWE不增加虚拟地址空间
考虑选择SQL Server 2005 (64位)
关系数据库性能因素
考虑Analysis Services
考虑Integration Services
考虑Reporting Services
考虑服务器合并
考虑部署SQL Server 2005 (64-bit)
集成
Mission-critical safety net
兼容性问题
迁移
64位的驱动
结束语
执行摘要
第一版Microsoft® Windows® 64位 (Itanium)的操作系统在2001年8月发布。Microsoft SQL Server™ (64位)在2002年4月发布。从此以后，Windows平台上的64位计算领域发生了重大的改变。按照摩尔定律的方式，不但64位硬件的价格在下降，而且性能有了巨大的提升。Intel (EM64T)和AMD (AMD64)引入的x64平台，使价格进一步下降。它们使进入64位平台的价格降低了一个数量级，同时全部的64位平台获得了200%的增益。最近的SQL Server 64位的TPC-C基准结果（在写本篇文章时）达到了超过每分钟一百万个TPC-C处理，而其成本为每个tpmC消耗5.38美元 。
为了简化用户的使用，最新版的Microsoft Windows XP 和Windows Server™ 2003操作系统和SQL Server 2005在32-bit (x86), x64, and Itanium这三种平台上都是可用的。考虑部署SQL Server 2005的用户可以为他们的商业应用和全部IT基础结构选择最佳的硬件平台。有两个重要的因素会推动SQL Server 2005(64位)的快速采用和部署。
首先，应当注意到的是64位计算的长期前景的产业动力。许多产业专家和分析家预期，在2005年底左右，几乎所有的Intel和AMD的服务器的处理器都将允许64位计算，或者本身64位的或者是64位扩展的。这一点在2004年第4季度 Information Week做的一次关于64位平台的使用的民意调查中得到了进一步的证明。在这次投票中，几乎三分之一的回应者已准备首次运行64位服务器，同时36%的人会在两年内这样做。依照另一项由大型产业分析专家The Gartner Group 做出的研究，多核的64位处理器将会在2007年左右占领市场。甚至最新的叫做Montecito的Itanium芯片（在写本篇文章时），也具有双核和超线程的能力。显然，产业正在被引向64位平台，并且步伐越来越快，至少对于服务器和工作组级别的计算机是这样。尽管如此，64位的笔记本/便携式电脑在2005年初也已经可用。
其次，SQL Server 2005(64位)带给客户的实际好处是非常有说服力的。在可支持性，可管理性，可伸缩性，性能，互操作性和商业智能的范围内，SQL Server 2005较以前提供了更丰富的64位支持。所有这些SQL Server的特性和服务组件，比如SQL Server Integration Services (SSIS)，Analysis Services，Reporting Services，Microsoft Search and Notification Services，都能在x64或基于Itanium的平台上运行。另外，所有的SQL Server2005工具可以在这两个平台上运行并得到充分的支持。因此，应用程序的采用和承载能力将不再主要集中于内存殆尽的系统或拥有适合于Itanium架构的负载特性。例如，一些SQL Server的工作负荷载32位服务器上会耗尽虚拟内存极限，而现在可以在x64上运行。一些应用需要巨型计算机的马力（适合大内存和Itanium EPIC架构的工作负荷），可以在基于Itanium的系统上运行，并且或许可以在即将出炉的高性能处理器-可伸缩的x64多核解决方案上运行。
本文描述了SQL Server 2005 (64位)提供的性能、可操作性和可管理性方面的增强。通过32位和64位环境的客观的比较，本文提出了问题“什么时候以及为什么我将应用SQL Server 2005和64位计算？”。
这篇文章讨论了采用64位的价值驱动，包括：
1. 许可证费用的减少和更高的事务处理吞吐量，使得TCO全面减少。
2. 合并服务器，使得操作成本减少。
3. 在不改变应用的情况下，保证大型商业智能（BI）和在线事务处理（OLTP）的可伸缩性
简介
与在32位环境中运行的SQL Server相比，Microsoft SQL Server 2005标准版和企业版(64位)在内存使用和并行处理的性能上做出了显著的提高。这篇文章描述了64位解决方案的能力，强调了和32位环境的区别，并且讨论了一些能够获益于64位环境中的SQL Server的运行的应用程序和应用场景。这篇文章意图帮助读者区分哪种工作能够获益于Microsoft SQL Server 2005 (64-bit)，并对它的部署和运行做出适当的期望。
在将应用移植到64位版本的SQL Server上后，许多客户对他们所获得的成本收益感到十分欣喜和惊讶。比如，有一家处于主导地位的卫生保健和医疗供应公司，他们每年要接到超过一百七十万份重要的订单。当他们将32位移植到64位SQL Server上之后，他们得到了几乎2.5倍的事务处理能力。除此之外，新的64位服务器硬件设备的花销只比原有的32位服务器（15个月之前购置）的花销高了10% 。如果您想得到伸缩性更加良好的系统，您可以选择一个具有扩大到64路的IA64处理器能力并含1BT的RAM的服务器。如果您的公司策略，是建立一个具有多个64位服务器的服务器场，那么您可以选择一个基于x64的系统。如果您想在您的64位服务器上运行32位的应用程序，那么您同样可以选择一个具有双核的x64系统。
从长远来看，客户可能会发现SQL Server 2005 (64位)的TCO比SQL Server 2005 (32位)少。有人会问，“为什么会这样？”首先，在64位平台上运行的性能远远高于32位平台。另外，64位平台提供了很大的增长空间。这意味着，硬件的生命周期会比较长，特别是随着多核（现在是双核）的64位CPU的发布。64位平台同样非常方便的支持相同服务器下的多OLTP和分析工作，因此它减少了硬件、许可证、运转和基础设施的消耗。也就是说，相同的服务器在很长的时间里都能满足您的需求，并在您的数据中心占据较少的占地面积，使用较少的维护费用。
运行64位版本，能够降低您的许可证费用。例如，您可以选择一个4路的32位服务器，或者是一个2路的64位服务器。64位平台每年的许可证费用是32位平台的一半，因而性能上的收益非常倾向于64位。较低的许可证费用会不会超过增添硬件的花费？答案非常令人满意：“是的”。收益是巨大的，特别在Intel和AMD都提供的x64平台上。不久，两个公司将会大量的交付市场，双核处理器以及多核处理器会在保持相同的开销的情况下，进一步提高处理能力。
读者
这篇文章是给一些技术人员参考，这些人可能是信息服务(IS)专业人员、数据库管理员，和系统架构师，他们对Microsoft SQL Server 2005标准版和企业版(64位)的提供的性能和可伸缩性比较感兴趣。这篇文章假设您大体理解数据库并了解Microsoft SQL Server 的一些基本知识。
概述：数据库性能和可伸缩性
为了在动态的竞争环境中做出及时准确的商业决策，一个组织必须能够很容易和快速的存储和分析大量的商业数据。通常作为IT基础架构的主要部分，数据库处于IT的核心地位。
• 应用程序和数据在复杂性和规模上都在增长。今天，许多32位平台上的应用程序正在到达或已经到达了平台的极限，特别是有关处理器数量和可访问存储器的极限。
• 先进的DBMS能力，特别是在可伸缩的架构和高利用率的范围内，已经成为一个商业必需品，并且对于越来越多的组织来说，为了从众多的数据源中聚集和分析数据并为日益增长的商业用户提供数据，先进的DBMS能力已经越来越普遍。
• 众多组织正在合并他们的服务器，简化关键的数据中心操作。合并服务器可以减少管理的复杂度和开销，并减少数据中心的物理空间的需求。
预料到这些趋势，Microsoft已经在研究和开发商做出了大量的投资，并生产出了它的强大的SQL Server 2005数据库的64位版本，并在这些处理器上达到最佳：Intel Itanium 2, AMD Opteron， AMD Athlon 64， 支持EM64T 的Intel Xeon，以及支持EM64T的Intel Pentium IV。
受64位架构的强大的可伸缩性和增强的内存寻址能力的影响，SQL Server 2005 (64位)能够控制越来越大、越来越复杂的数据库和分析程序，并支持拥有很多处理器的大规模SMP系统上的服务器合并。对于多并行处理的工作量、并发用户连接、计划缓存、排序空间和锁存储，使用SQL Server 2005 (64位)的应用程序可以获益于大量的内存储器数据（缓存数据和大型的数据结构）。
通过消除32位平台和处理瓶颈，在支付的起的前提下，64位平台为商业应用提供了一个新级别的可伸缩性。
SQL Server 2005 (64-bit)
SQL Server 2005 (64位)在应用Intel Itanium 2，AMD Opteron，AMD Athlon 64，支持EM64T 的Intel Xeon，或支持EM64T 的Intel Pentium IV处理器的服务器，和Microsoft Windows Server 2003 Service Pack (SP) 1上达到最优化，并且提供了优越的性能和可伸缩性。32位和64位版本的SQL Server 2005都给予同一个通用架构，为现有应用程序提供了一个简单的移植路径。企业可以利用现有的工具和经验研发新的应用程序。
SQL Server 2005的64位和32位版本的主要差别，来源于从潜在的64位架构获得的优势。这些优势有：
• 64位架构提供了一个巨大的直接寻址内存空间。SQL Server 2005 (64位)不受32位系统的内存限制。因此，更多的可用内存使之能够完成复杂的查询并支持基本的数据库操作。
• 64位处理器提供了增强的并行性，并因此提供了更多的线性的可伸缩性并支持最多64个处理器，而且与32位系统相比，每个处理器会产生更多的收益。
• 在缓存和处理器之间传递数据时间的缩短，使改良的总线结构提高了性能。
• 更大的on-die cache允许用户请求更快的完成，并使处理器时间的利用更加有效。
利用这些架构上的优势，SQL Server 2005 (64位)能够处理大规模复杂的查询工作，巩固许多数据库应用程序，并且毫不费力的做出调整，以适合日益增长的处理和当今IT环境的性能需求。
SQL Server 2005 (64-bit)硬件需求
SQL Server 2005 (64位)没有一个单独的硬件兼容性列表(HCL)。用户可以为操作系统选择用其它方式验证并符合表1的最低硬件要求的硬件。
表1：硬件需求
SQL Server 2005 (64位)可以在下面的配置中部署
表2: SQL Server 2005 (64位)部署选项
SQL Server 2005 (64位)组件
区别这个版本的64位SQL Server与以前版本的关键在于，这个版本的SQL Server不只拥有了64位能力的核心组件，而是所有 的SQL Server 2005的特性在64位上皆可用，它或者通过本地执行（比如服务器引擎），或者通过Microsoft Windows on Windows 64位模式实现（比如SQL Server Management Studio中包含的一些工具）。WOW64是64位版本的Microsoft Windows的一个功能，它允许32位的应用程序在64位操作系统中以32位的模式运行。即使底层的操作系统运行在64位平台上，应用程序在32位模式下也运行的相当好。所有的64位组件和32位版本的SQL Server 2005具有兼容性代码，使得64位服务器和其它32位版本的SQL Server 2005数据库服务器的集成更加简单。
64位架构的优势
SQL Server 2005 (64位)的增强的可伸缩性和性能，很大程度上是由许多64位架构的架构特性所决定的。下面是每个关键架构特性的说明。
• 内存寻址能力
一个32位的系统只能直接寻址4GB的地址空间。在32位平台中，附加的内存是通过Address Windowing Extensions (AWE)间接访问到的，在下面的小节中会详细讨论。在Intel Itanium 64位架构上运行的Windows Server 2003 SP1支持最多1,024GB的物理可寻址内存。
• 大量处理器以及每个处理器更多的线性可伸缩性
在并行处理和总线架构方面的提高，使64位平台支持大量处理器（最多64个），使每附加一个处理器，几乎能获得线性的可伸缩性。使用大量处理器，使SQL Server可以在一个系统中支持更多的进程、应用程序和用户。
服务器平台可以使用多于32个CPU，这只可能在64位架构中实现。SQL Server在64位系统上已经达到了最高的TPC-C基准测试，因为这些系统依靠大量的内存和64位架构上的64位处理器的优良的伸缩性。
• 增强的总线架构
当前的64位芯片的总线结构比早期的芯片更快。更多的数据传向缓存和处理器，这有一点类似于从拨号连接到宽带连接的提高。
应用AWE 的SQL Server 2005 (32位)
Microsoft SQL Server 2005 企业版 (32位)在32位平台上应用Microsoft Windows 2003 Address Windowing Extensions (AWE) API来支持大于4GB的内存。自从SQL Server 2000开始就可以这样，但是一直没有被考虑。对于用AWE的一些应用程序，升级到64位平台可能是最好的选择。但对于其它的应用程序来说，这是最好的选择。
应用AWE 的SQL Server 2005 (32位)
Microsoft SQL Server 2005 企业版 (32位)在32位平台上应用Microsoft Windows 2003 Address Windowing Extensions (AWE) API来支持大于4GB的内存。自从SQL Server 2000开始就可以这样，但是一直没有被考虑。对于用AWE的一些应用程序，升级到64位平台可能是最好的选择。但对于其它的应用程序来说，这是最好的选择。
AWE的局限性
带AWE的SQL Server 2005 (32位)有很多重要的局限性。附加的内存寻址能力只在关系数据库工具的数据库页面缓冲器的管理中可用。它对于其它的消耗内存的数据库操作是不可用的，例如缓存查询计划，排序，索引，连接，或存储用户连接信息。同样，对于其它的引擎例如Analysis Services也是不可用的。相反的，SQL Server 2005 (64位)使内存对于所有的数据库处理和操作都是可用的。在IA64或x64硬件平台上应用64位版本，一个SQL Server实例能够寻址1TB的内存，这是现在Windwos Server 2003 SP1所支持的最大物理内存容量。（理论上可寻址的极限伟18EB）这些内存对于SQL Server的所有组件都是可用的，并且对于数据库引擎的所有操作都是可用的。
结果，SQL Server 2005 (64位)增强了很多存储密集型数据库应用程序的性能。
AWE不增加虚拟地址空间
32位系统限制虚拟地址空间（该地址空间由Windows管理内存分配）为2GB。因为AWE没有消除这种虚拟地址空间（VAS）的限制，所以很多用户通过在boot.ini中使用/3GB的开关，试图将这种32位的VAS的2GB的内存上限提高。这样可以将VAS提高到3GB，因此只有1GB留给操作系统。这样导致在Windows Server 2003企业版和数据中心版上的数据库实例的可寻址物理内存减少为16GB。当在Windows Server 2003企业版中不用/3GB开关时，最大的内存寻址是32GB，而对于数据中心版，是64GB。因为在一个实例中，Windows需要1GB多的VAS来管理大于16GB的总的物理内存。所以使用开关将会强加一个人工的上限，从而缩小了您的硬件和操作系统的能力。
实际上，32位环境中AWE的使用只是为了缓存数据。这是因为数据页用相对寻址（应用AWE的要求），而其它组件不用。结果，其它的以相对较小的VAS（2或3GB）运行的组件，在一个具有复杂工作负荷或有很多并发用户的较大的系统（甚至是拥有重组内存的高端服务器）上，可能会受到严重的阻碍。
例如，SQL Server 2005中的计划缓存（查询计划的缓存）存储在VAS中。万一VAS存储紧张，消耗为零（0）的查询计划和执行上下文将从计划缓存中被删除。在高事务处理环境中，这可能会导致性能下降，因为时间和CPU资源需要重新编译查询计划。相反的，在64位系统中，VAS实际上是不受限制的。因为不需要再花时间来重新生成查询计划，所以它执行的更快。这样CPU的荷载更少，因为CPU没有频繁的编译查询计划。同样的事情也会在拥有大量内存（比如8GB或更多）的服务器上发生，因为计划缓存（以及除了数据页的其它组件）不能利用AWE存储。
AWE局限性的另一个例子是SQL Server 2005对公共语言运行时（CLR）的支持。虽然CLR从缓冲池（单页分配器）中获得内存分配（在那里AWE非常有用），大多数SQL操作系统(SQLOS)在CLR一边的内存分配（多页分配器）是从VAS中得到的。对于一些想应用SQL Server 2005中的CLR的用户，选择64位的另一个原因可能是防止VAS存储紧张所带来的性能损失。
考虑选择SQL Server 2005 (64位)
虽然64版本的SQL Server为很多应用程序提供了强大的可伸缩性和性能，但并不是所有的应用程序都将从中获益。本小节将帮助您来决定是用现有的SQL Server实例还是在64位平台上部署新的系统。
在IA64平台上升级到SQL Server 2000 64位后，客户通常会要求在IA64上使用SQL Server工具。在SQL Server 2005种，大多数组件都支持在IA64本地运行。另外，在x64平台（支持EM64T的Intel Xeon、AMD Opteron和AMD Athlon 64）上支持本地运行和WOW64两种方式。这时就不需要在32位平台上运行SQL Server工具了。
当第一个64位版本的SQL Server 2000单独运行在IA64基础的服务器上时，它是纯64位的，SQL Server 2000(32位) SP4在x64服务器上提供了一个中间步骤可以升级到64位平台。值得注意的是，自从Service Pach 4发布以来，用户已经可以在x64平台的WOW64上运行SQL Server 2000（32位）的所有组件。但是在IA64上，一些组件，比如管理工具，还必须单独在32位计算机上运行，来访问IA64机器上的数据库引擎。当然这不会引起可用性和性能的问题，但是对用户来数这确实很不方便。
IA64和x64平台上的SQL Server 2005在基于Intel和AMD的64位服务器上得到增强。客户可以在64位模式下本地运行SQL Server 2005 (64位)和它所有的组件。或者，也可以在WOW64上运行SQL Server（32位），就不用再到其它的机器上运行工具了。这时一个很大的进步，因为很多客户要在它们的SQL Server计算机上运行第三方的防病毒监视器、网络代理和系统管理代理等。这些第三方的软件可能不支持64位，但能够和SQL Server 2005继续在同一个64位服务器中共存。
随着64位平台的增强，SQL Server 2005利用这些硬件的收益进一步提高内存和并行处理的能力。并在性能和可伸缩性方面，获得了巨大的收益。下面是一些能够获得收益的场景：
• 一些应用程序，例如SAP Advance Planning and Optimization (APO)，需要大量的直接寻址内存。对于这些应用程序来数，依照并发的用户和反应时间，可能会看到巨大的性能上的收益和可伸缩性的提高。
• 在32位系统中，Analysis Services被限制最大使用3GB的物理内存。64位平台能够帮助消除这种限制。它也能够帮助创建或加速拥有快速相应时间需求的大型的在线分析处理（OLAP）系统。
• 64位平台便于多个数据库和应用程序合并到少量的服务器上。在一个64位系统中控制多个数据库，您可以简化管理，提高存储利用率，并提高运行效率。由于32位系统中的内存使用方面的限制和先进的硬件分割能力的普遍缺乏，这样的合并工作在32位平台中只能发挥有限的功能。
• 64位平台允许您“扩大”当前的正经历巨大的增长的应用程序。对于一个多层应用程序来说，迁移现有的几乎达到平台极限的数据库服务器，不会对其它层造成影响。
• 64位服务器能够代替legacy UNIX或mainframe systems/application。对于高端数据库服务器，64位平台提供了一个强大且可靠的面向UNIX/mainframe系统的备选方案。
下面的小节列出了一些因素，是您在为64位平台评估特定的应用程序是需要考虑的。
关系数据库性能因素
存储密集型的SQL Server相关的工作最有希望使用SQL Server（64位）。在32位应用程序中，许多SQL Server的资源都受限于2GB或3GB的内存限制。这些资源包括：
• 排序空间
• 在联接和聚合时用到的哈希表
• 创建索引，包括全文索引
• 用户连接存储
• 为已编译的计划做缓存
虚拟存储不足的系统的性能会下降，因为需要等待资源，并因计划被挤出缓存而需要处理器重新编译所造成的延迟。这些系统也可能通过大量磁盘操作记录这些对象。比如，当哈希表不能找到可用的内存时，就被记录到磁盘上。
在32位平台上，如果庞大和复杂的查询不能装入相对较小的虚拟内存地址空间里，特别是关于数据仓库和大量数据的查询，会被磁盘应用所引起的资源等待所影响。在64位系统中，有大量的虚拟地址空间可用，因此这些查询可以完全在内存中快速的执行。
即使在使用AWE存储的32位的系统中，性能获益也非常显著，因为从虚拟地址空间中映射内存页（使用AWE的功能）需要时间和很多处理器周期。这种开销的减少或消除，特别对于那些拥有大量并发用户和系统，并对大量数据执行复杂查询的系统来说，最为显著。
其它能通过扩展内存而获得收益的操作包括：
• 创建索引的操作会从大容量可寻址内存中获益。这是因为整个排序过程可以在内存中完成。在将最终的实际索引写到磁盘之前，就没有必要在将中间结果集写到磁盘上。
• 全文索引在32位计算机中被限制到2GB或3GB的工作区内。（实际上，因为内存也要用作其它的处理，所以这个限制显然比2或3GB低。）这就为比较大的全文索引的创建和重建制造了一个潜在的瓶颈。早期部署大型全文搜索系统的客户，在这些系统中重建索引后，速度上显现出数量级规模的增长。
• 当有足够的直接寻址内存可用以后，一些使用排序、大型哈希联接或哈希聚合的查询性能都有了显著的提高。哈希联接非常有效，但是会耗费内存。如果系统中内存不足，那么哈希联接会从缓存中删除，这样有利于内存保护，但是会很慢。
• 拥有大量存储过程的系统会获益于计划缓存能力的增强。64位架构能够充分减少CPU总利用率，减少从缓存中清除存储过程所带来的延迟，并降低编译频率。
• 服务器端的游标，以往经常非常耗费内存，现在可以轻松的控制在内存中，并因此获得更好的性能。
• 聚合和排序等操作需要整个数据集的操作。这些操作也会从64位平台提供的增加的内存支持中获益。
对于许多I/O密集型的应用程序，在64位环境中，它们可以将更大的工作数据集装载到内存中，并因此获益匪浅。虽然需要AWE支持的比64GB更多内存的应用程序很少，但是这种应用程序或工作，确实会获益于由缓存增大并代替磁盘子系统所带来的提取数据库页的速度。
考虑Analysis Services
就像Analysis Services 2000(32位)，Analysis Services 2005(32位)不能利用AWE的扩展内存。因此最多只有3GB的可用物理内存。这就使64位版本的SQL Server更加适用于应用Analysis Services的大规模企业的商业职能解决方案。
64位平台上的附加的可用内存使Analysis Services具有了支持大维度或超大维度的快速访问和处理的能力。如果您的OLAP应用程序具有以下特点，请考虑使用64位环境：
• 大维度。SQL Server 2005 (64位)支持大维度。
• 大量内存用来处理缓冲
• 大立方体。通过使用大容量缓存，使用大立方体能够获得巨大的性能提高，并因此减少访问物理磁盘的次数。
• 快速的立方体处理。内存的可用性减少了向磁盘中写临时文件的需要。附加的内存也允许在聚集阶段有更多的并行化。
• 大量的并发用户。
Before adopting a 64-bit environment for data analysis, users need to ensure that the following requirements are met:
在采用64位环境做数据分析之前，用户需要确定是否满足以下需求：
• 为所有的数据源提供64位的OLE DB providers，并用来在64位环境中访问数据库。SQL Server 2005 (64位)包括了一个OLE DB provider，用来访问SQL Server。如果用其它数据库厂商在数据源，那么用户应当确认适当的OLE DB providers是否可用。
• Analysis Services的用户自定义函数(UDFs)或其它用Microsoft Visual Basic® 6.0写的组件，在64位环境中不受支持。用户需要确认，这些组件是否存在，如果需要重写，那么用Microsoft Visual Studio® 2005重写并用64位的编译器来编译。
考虑Integration Services
当SQL Server 2000 64位发布时，Data Transformation Services (DTS)在64位的Itanium计算机上还不受支持。但是，SQL Server 2005 Integration Services (SSIS)，一个全新结构的DTS，现在在32位和64位的平台上都可用了。另外，64位版本的SQL Server 2005 SSIS能够被安装在IA64和x64系统（Intel的EM64T和AMD的AMD64）中，为用户提供了更强的灵活性和更多的选择，他们可以选择其中任意一个适合他们的环境的平台。
有一个好消息是，在32位平台上，SSIS只能用虚拟存储空间(VAS)存储(2GB，或3GB-如果用/3GB开关)，使AWE存储与SSIS毫无关系。
在实际工作测试中，早期采用的客户运行大型数据库并进行复杂的提取、转换和装载(ETL)处理，都得到了非常好的结果。使用同样配置的32位和64位系统，对同样工作的测试表明，在64位系统中，运行SSIS包，包括读取大量的行，执行聚合，装载结果到多个表中，能够获得巨大的约为四倍的性能优势。这应部分归因于，在用户不进行干预的情况下，SQL Server 2005 (64位)会自动利用64位的增强的并行处理。
64位平台上的SSIS组件提供了下列优势：
• SSIS组件提供了row-by-row的处理（比如计算新列，转换数据，字符转换，和查找联接）来引用表，并受益于64位平台提供的增强的性能。
• SSIS任务可以实现聚合，排序，和模糊查找，需要和整个数据集一起工作，并受益于增加的内存容量。
• 在传统的数据仓库装载场景中，集成处理验证并装载数据，其中聚合，排序和其它操作都是由数据库服务器完成的。这些操作需要应付用户查询中对资源的争用。此外，这个架构对于大规模的数据和大量复杂的聚合并不能很好的做出调整。64位上的SSIS便于执行聚合和排序，还有验证和装载数据。这个架构调整的就很好，并能够将数据库释放给用户的查询。
考虑Reporting Services
就像SQL Server 2000 64位上的DTS一样，Reporting Services并不是被设计安装到64位系统中。它只能安装到一个32位的计算机中。然后再通过网络访问64位的SQL Server 2000数据库和Analysis Services。而现在，SQL Server 2005 (64位)就支持直接在64位服务器上安装Reporting Services。
Reporting Services 运行在64位环境中能够提高性能么？答案是：是的。Reporting Services是一个基于CLR的应用。它的所有的内存分配是通过SQL Server CLR 宿主层来管理，也就意味着Reporting Services不能利用AWE。在32位系统中，用户受限于2GB或3GB的内存。在64位系统中(64位CLR支持)，Reporting Services能够访问所有可访问的物理内存，这样就会使大型复杂报表产生巨大的性能提升。
考虑服务器合并
早期用一个流行的ERP应用程序做的测试 ，结果显示，相对于他们的32位系统来说，64位系统每个CPU能获得显著的可伸缩性的提高。也就是说，64位系统提供了更强的线性可伸缩性。这种增益很大一部分来源于总线结构的增强和更大的on-die cache。另外，在64位架构上，服务器平台提供了多于32个可用的CPU。在64位架构上，由于其大容量的内存和优良的伸缩性，SQL Server已经达到了最好的TPC-C基准结果。对于终端用户来说，最大的收益是，优化建立在SQL Server 2005中，而用户并不需要做任何额外的工作。
在64位环境中处理器和内存的可用的增长空间，使性能有了很大的增长空间，并为服务器的合并提供的更大的机会。大量的合并后的数据库能够适应在一个SQL实例中，因为它拥有足够的空间来支持多个共存的应用程序的数据结构（连接，索，哈希等）。同样的优势也适用于同一个物理服务器上多个实例的合并。
如果您的工作负荷是CPU密集型的，那么请认真考虑SQL Server 2005 (64位)，它使可伸缩性随着处理器数量的增加而增加。64位版本对于使用超过16颗处理器的SQL Server特别有帮助。此外，在SQL Server 2005中支持“hot-add memory”，用户可以动态添加他们SQL Server系统的处理容量，而不必影响正常工作。
就合并服务器来说，如果想将十台不同服务器上的十个数据库合并到一台服务器上，那么在一个32位服务器上，技术上的局限性会致使客户安装多个数据库实例，而不是将所有数据库安装在一个实例中。
其原因是虚拟地址空间(VAS)所导致的。要知道，这十个单独的实例每个都要用VAS来存储，从锁管理到计划缓存。通过测量每个SQL Server实例在每个服务器上的VAS内存使用量，您会发现所有服务器上的VAS量都超过2GB或3GB的界限。如果这个界限被忽略，那么很有可能会引发巨大的性能问题，并将影响到所有的数据库。这就是为什么在32位平台上，将多个数据库从多个服务器合并到一个数据库实例上是一件相当困难的事情的原因，并因此需要用多个实例。虽然对于这件事本身来说并不是什么坏事，但是在进行合并工作时，它确实限制了用户可以选择的范围。
这在64位平台上就不是问题了，因为64位平台上的VAS的理论界限为18EB，而不是2GB。用户可以基于他们的商业需求，来决定是否合并多个实例为一个实例。这时就不会被技术所限制。在考虑合并策略时，64位平台提供了更强大的灵活性。数据库的合并，会带来SQL Server许可证上的成本节省，减少服务器数量的运作上的节省，并降低管理上的复杂度。
考虑部署SQL Server 2005 (64-bit)
Microsoft为了SQL Server 2005 (64位)和SQL Server 2005 (32位) 的兼容性做出了巨大的努力。这包括数据和日志文件格式的兼容性。两个系统在产品应用级的相似性（尽管在较低的资源管理级上的区别），较大的简化了迁移的过程，并简化了相同基础架构下集成32位和64位平台的过程。
集成
一个企业的数据中心，可以由32位和64位系统和应用程序组成。企业可以继续应用和购买32位的服务器，同时连接到64位服务器的后端的数据库上，以获得64位平台的优势，或者也可以使用二者混合的服务器场。从32位和64位环境中请求数据，并不需要客户端的代码发生任何的改变。访问32位的应用程序不需要改变应用程序的代码，就可以连接并访问64位的系统，因为两个版本的T-SQL代码是完全兼容的。这给了用户极大的灵活性，用以决定企业中使用64位系统的比率。
Mission-critical safety net
这里还有一些关于SQL Server的附加功能，这些功能在64位平台上是可用的。
审计跟踪，灾难恢复，备份/还原支持
许多可与需要商业过程中的审计跟踪。谁修改了什么？什么时候？怎么修改的？安装SQL Server 2005种的SQL Server Profiler，就可以拥有审计跟踪的功能。另外，Microsoft和第三方的厂商如Lumigent和LogPI一起提供了基于事务日志的附加功能。所有32位版本中的备份和还原的功能，在SQL Server 2005 (64位)种都是可用的，并得到了增强。另外，灾难恢复功能（如日志传送和数据库镜像）以及故障转移群集在SQL Server 2005的64位版本中均可用。从用户的角度来看，除了在64位系统上附加的性能增益外，这些功能和在32位系统上完全一样。
64位上的第三方支持
虽然有一些厂商的应用程序不支持在64位系统上本地运行，但是新的AMD和Intel x64服务器的发布，可以运行这些32位的应用程序运行（基于WOW），并且SQL Server 2005可以在本地运行（x64）或在OS模拟模式（WOW64）下运行。支持64位的厂商也在不断的增长，一些主要的软件厂商，包括安全和防病毒软件的厂商，已经能够支持64位平台。
兼容性问题
SQL Server 2005 (64位)与SQL Server 2005 (32位)完全兼容，使现存基础架构中的集成更加简单，并提供了对扩展的64位硬件的支持。产品提供了与SQL Server 2000 (32位和64位)数据库以及事务日志文件的完全的兼容性。
和SQL Server 2000 (64位)不同，SQL Server 2005管理工具和客户端工具可以在64位本地或在WOW中使用。
64位版本的SQL Server和Windows Server 2003有一些功能的增强和组件的改变。一些原来是SQL Server中的组件，如Microsoft Data Access Components (MDAC), Distributed Transaction Coordinator (DTC), and Microsoft Management Console (MMC)，现在作为核心组件被放在Windows Server 2003的安装中。这样，使SQL Server 2005 (64位)能够更好的利用操作系统的资源。
迁移
从SQL Server 2000 (32位和64位)和SQL Server 2005 (32位)到SQL Server 2005 (64位)上的数据迁移是一项非常简单的工作，因为它们的数据和日志文件的格式是完全一致的。可以使用分离和附加，或备份和还原来实现。
• 分离/附加
可以使用系统提供的存储过程来从32版本中分离(sp_detach_db)数据库，并将数据库附加(sp_attach_db)到64位版本中。或者也可以使用SQL Server企业管理器中的GUI环境来实现。
• 备份/还原
一个标准的备份和还原的过程，就可实现从32位平台到64位平台的数据迁移。这可以通过T-SQL命令或通过GUI工具来实现。
当然，也可以将数据从SQL Server 2005数据库中再迁移会32位版本中。但是，不支持从SQL Server 2005 (64位)到SQL Server 7.0的数据迁移。
通过执行“in-place”安装升级现有的SQL Server 2000 64位数据库，以可以实现SQL Server 2005的数据迁移。因为SQL Server 2005工具可以在64位平台上安装，所以可以使用Copy Database Wizard (CDW)，从其它服务器中的SQL Server 2000数据库中自动附加数据库。CDW也可以把SQL Server 2000种的SQL 登录和密码用脚本输出，并自动在目标64位SQL Server上创建。
64位的驱动
Microsoft为SQL Server 2005提供了所有必须的驱动的64位的版本。但是，对于第三方的应用程序和硬件的驱动应当提早进行研究，以确保它们可以在本地使用，或者可以使用其它已经存在的驱动来代替。
版权所有
这是一份初版文件，可能会于本软件产品正式发行之前依实况进行必要的修订。
本文件中所包含的信息代表 Microsoft Corporation 于发行日前针对该问题的观点。由于 Microsoft 必须反应市场条件的变更，因此不应解释为 Microsoft 的承诺。在发行日之后，Microsoft 不保证文件中任何信息的正确性。
此白皮书仅供参考使用。MICROSOFT 对于本文件中各项信息，不作任何明示、暗示或法定的保证。
使用者必须遵守所有适用的版权法律规定。在不影响版权各项权利的情况下，若无 Microsoft Corporation 的明确书面许可，本文件中的任何部份均不得因任何目的，以各种可能的形式或方式 (电子、机械、影印、录制或其它方式) 进行复制、储存或导入至检索系统或传送。
本文件中可能述及 Microsoft 的专利、专利应用程序、商标、版权或其它智能财产权。除非取得 Microsoft 明确书面授权声明，否则本文件并未授予这些专利、商标、版权或其它智能财产的授权。
除非另有说明，本文档中用作示例的公司、组织、产品、域名、电子邮件地址、徽标、人员、地点和事件均是虚构的，并不是有意或者不应推断为与任何真实的公司、组织、产品、域名、电子邮件地址、徽标、人员、地点或事件有关联。
Ó 2005 Microsoft Corporation。保留所有权利。
Microsoft、Visual Basic、Visual Studio、Win32、Windows、和 Windows Server是 Microsoft Corporation 在美国和/或其它国家/地区的注册商标或商标。本文档中提到的真实公司和产品的名称均是各自所有者的商标。
|
最全面的资料《SQL Server数据管理》 |
|
| 诚征版主 | 版主堂 | 意见建议 | 大史记 | 论坛地图