博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
移至64位SQL Server数据库(转)
阅读量:2501 次
发布时间:2019-05-11

本文共 2296 字,大约阅读时间需要 7 分钟。

移至64位SQL Server数据库(转)[@more@]相当长一段时间以来,在64位平台上运行SQL Server一直是提高数据库性能和扩展性的一种选择,不过配置方面的选项有限,而且不是没有问题。举例说,SQL Server 2000只能在昂贵的安腾系列处理器上面运行;而且SQL Server的客户端工具与64位平台不兼容。另一方面,SQL Server 2005却提供了新的选项可以充分利用64位架构的强大功能;而且完全没有在过去导致人们不太需要64位的问题。
使用SQL Server的公司为什么应当改用64位架构?
要解答这个问题,最重要的答案就是,64位平台与32位系统相比,大大提高了内存访问能力。32位系统最多只能本地访问4GB的内存。32位的SQL Server系统使用地址窗口扩展(AWE)及相关技术后,最多可以访问64GB的内存,不过地址虚拟技术带来了开销:AWE需要创建虚拟“窗口”来访问更高内存。访问高端内存的每个请求都必须通过这个窗口进行,开销要比请求访问本地内存大得多。因而,在高使用率情况下,访问更大内存的功能实际上妨碍了而不是有助于性能。此外,AWE内存只是被SQL Server用于缓冲器缓存,而不是用于过程缓存,而且不会有助于对利用许多即席查询(ad-hoc query)的服务器进行优化。AWE内存也不会被用于帮助内存中的排序、散列连接(hash join)或者其他数据密集型操作。
如今的64位系统最多可本地访问512GB的内存。这意味着,性能不会受到地址窗口的影响,额外内存可以供任何SQL Server缓存而不仅仅是缓冲器缓存使用。这种增加内存的功能在许多情况下直接提高了性能。由于更多的数据保存在缓存里面,势必会减少磁盘的I/O操作。你还会注意到使用中间排序、散列连接或者指针的查询在性能上得到提高。所有这些在内存里面进行求值要比换到磁盘上进行求值来得快。
为什么64位采用迟缓?
有人不由得会想:既然好处这么显著,为什么到目前为止64位SQL Serve的采用似乎很迟缓?SQL Server 2000的64位选项很有限,因为SQL Server 2000惟一支持的64位配置就是安腾服务器运行在Windows Server 2003上面。也没有哪个SQL Server 2000客户端工具可在64位服务器上面运行,包括企业管理器、查询分析器和SQL Profiler。连数据转换服务(DTS)软件包也无法在64位服务器上运行,这意味着DTS无法充分利用64位的更强功能。
SQL Server 2005 64位架构有什么优点?
SQL Server 2005为企业带来了64位架构的优点,而与以往相比价位较低、功能较多。最重要的是,SQL Server 2005支持可以安装在安腾和价格低得多的x64服务器两种平台上。所以,除了节省费用外,数据库管理员现在就可以使用英特尔处理器或者AMD处理器。
SQL Server 2005客户端工具与64位服务器完全兼容,所有SQL Server支持服务都可以在64位配置环境下与SQL Server 2005一起使用,这包括:分析服务、SQL Server集成服务、报表服务和通知服务。所有这些服务都能够利用访问更多内存的功能,有助于提高安装的SQL Server的性能、满足业务集成需求。
哪种安装环境应当升级至64位?
升级主要有两个市场:需要向上扩展的32位单服务器安装环境;以及需要合并的32位多服务器安装环境。每种场景都有明显的优点。
表明单服务器安装配置可能属于向上扩展类别的最明显迹象就是,深度查询磁盘活动、较低的缓冲器缓存命中率以及较短的页面生命周期。所有这些问题都可以使用性能计数器来评估,可通过能够访问更多内存的64位系统来加以解决。
另一方面,确定多服务器安装环境是不是非常适合合并来得困难一点。应当进行认真测试,评估所有数据库总共需要多少内存、处理器能不能处理所有数据库的并发查询、磁盘系统能不能处理同时读写带来的更大压力。做出这个决策比升级单一服务器困难得多,不过就整体的管理简易性而言,会获得巨大回报。
改用64位会在SQL Server的性能和扩展性方面带来重大影响。SQL Server 2005提供的选项使得从32位进行升级合理得多。如果你投资新硬件用于新的数据库管理系统(DBMS),就应当调查分析64位选项,尤其是基于价格较低的x64位处理器的那些选项。
我要不要使用新的XML数据类型把所有XML数据保存在SQL Server 2005里面?
XML酷似CLR用户定义类型(UDT),它现在是SQL Server 2005中新的第一类数据类型。开发人员现在可能会忍不住使用这种数据类型,以免编写代码把XML数据“分割”到表里面(即不是使用OPENXML往表里面批量载入数据)。
遗憾的是,像这样使用XML数据类型存在与使用用户定义类型表示数据同样的许多问题。开发人员应当把性能记在心头,因为对XML列的一个节点进行查询需要引擎对表中每一行的不同XML查询进行求值。与使用CLR UDT一样,还存在规范化问题。在过多使用XML数据类型的数据库里面,要确保数据完整性极其困难。

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/10617731/viewspace-950167/,如需转载,请注明出处,否则将追究法律责任。

转载于:http://blog.itpub.net/10617731/viewspace-950167/

你可能感兴趣的文章
高频交易的几种策略
查看>>
量化策略回测TRIXKDJ
查看>>
量化策略回测唐安奇通道
查看>>
CTA策略如何过滤部分震荡行情?
查看>>
量化策略回测DualThrust
查看>>
量化策略回测BoolC
查看>>
量化策略回测DCCV2
查看>>
mongodb查询优化
查看>>
五步git操作搞定Github中fork的项目与原作者同步
查看>>
git 删除远程分支
查看>>
删远端分支报错remote refs do not exist或git: refusing to delete the current branch解决方法
查看>>
python multiprocessing遇到Can’t pickle instancemethod问题
查看>>
APP真机测试及发布
查看>>
通知机制 (Notifications)
查看>>
10 Things You Need To Know About Cocoa Auto Layout
查看>>
一个异步网络请求的坑:关于NSURLConnection和NSRunLoopCommonModes
查看>>
iOS 如何放大按钮点击热区
查看>>
ios设备唯一标识获取策略
查看>>
获取推送通知的DeviceToken
查看>>
Could not find a storyboard named 'Main' in bundle NSBundle
查看>>