仓酷云

 找回密码
 立即注册
搜索
热搜: 活动 交友 discuz
查看: 969|回复: 7
打印 上一主题 下一主题

[学习教程] MSSQL网页编程之迁徙至64位SQL Server 2005

[复制链接]
老尸 该用户已被删除
跳转到指定楼层
楼主
发表于 2015-1-16 22:17:12 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式

马上注册,结交更多好友,享用更多功能,让你轻松玩转社区。

您需要 登录 才可以下载或查看,没有帐号?立即注册

x
MySQL的海豚标志的名字叫“sakila”,它是由MySQLAB的创始人从用户在“海豚命名”的竞赛中建议的大量的名字表中选出的。获胜的名字是由来自非洲斯威士兰的开源软件开发者AmbroseTwebaze提供。  相称长一段工夫以来,在64位平台上运转SQLServer一向是进步数据库功能和扩大性的一种选择,不外设置方面的选项无限,并且不是没有成绩。举例说,SQLServer2000只能在高贵的安腾系列处置器下面运转;并且SQLServer的客户端工具与64位平台不兼容。另外一方面,SQLServer2005却供应了新的选项能够充实使用64位架构的壮大功效;并且完整没有在已往招致人们不太必要64位的成绩。
  利用SQLServer的公司为何应该改用64位架构?
  要解答这个成绩,最主要的谜底就是,64位平台与32位体系比拟,年夜年夜进步了内存会见才能。32位体系最多只能当地会见4GB的内存。32位的SQLServer体系利用地点窗口扩大(AWE)及相干手艺后,最多能够会见64GB的内存,不外地点假造手艺带来了开支:AWE必要创立假造“窗口”来会见更高内存。会见高端内存的每一个哀求都必需经由过程这个窗口举行,开支要比哀求会见当地内存年夜很多。因此,在高利用率情形下,会见更年夜内存的功效实践上妨害了而不是有助于功能。别的,AWE内存只是被SQLServer用于缓冲器缓存,而不是用于历程缓存,并且不会有助于对使用很多即席查询(ad-hocquery)的服务器举行优化。AWE内存也不会被用于匡助内存中的排序、散列毗连(hashjoin)大概其他数据麋集型操纵。
  现在的64位体系最多可当地会见512GB的内存。这意味着,功能不会遭到地点窗口的影响,分外内存能够供任何SQLServer缓存而不单单是缓冲器缓存利用。这类增添内存的功效在很多情形下间接进步了功能。因为更多的数据保留在缓存内里,必将会削减磁盘的I/O操纵。你还会注重到利用两头排序、散列毗连大概指针的查询在功能上失掉进步。一切这些在内存内里举行求值要比换到磁盘长进行求值来得快。
  为何64位接纳缓慢?
  有人忍不住会想:既然优点这么明显,为何到今朝为止64位SQLServe的接纳仿佛很缓慢?SQLServer2000的64位选项很无限,由于SQLServer2000唯一撑持的64位设置就是安腾服务器运转在WindowsServer2003下面。也没有哪一个SQLServer2000客户端工具可在64位服务器下面运转,包含企业办理器、查询剖析器和SQLProfiler。连数据转换服务(DTS)软件包也没法在64位服务器上运转,这意味着DTS没法充实使用64位的更强功效。
  SQLServer200564位架构有甚么长处?
  SQLServer2005为企业带来了64位架构的长处,而与以往比拟价位较低、功效较多。最主要的是,SQLServer2005撑持能够安装在安腾和代价低很多的x64服务器两种平台上。以是,除节俭用度外,数据库办理员如今就能够利用英特尔处置器大概AMD处置器。
  SQLServer2005客户端工具与64位服务器完整兼容,一切SQLServer撑持服务都能够在64位设置情况下与SQLServer2005一同利用,这包含:剖析服务、SQLServer集成服务、报表服务和关照服务。一切这些服务都可以使用会见更多内存的功效,有助于进步安装的SQLServer的功能、满意营业集成需求。
  哪一种安装情况应该晋级至64位?
  晋级次要有两个市场:必要向上扩大的32位单服务器安装情况;和必要兼并的32位多服务器安装情况。每种场景都有分明的长处。
  标明单服务器安拆卸置大概属于向上扩大种别的最分明迹象就是,深度查询磁盘举动、较低的缓冲器缓存射中率和较短的页面熟命周期。一切这些成绩都可使用功能计数器来评价,可经由过程可以会见更多内存的64位体系来加以办理。
  另外一方面,断定多服务器安装情况是否是十分合适兼并来得坚苦一点。应该举行仔细测试,评价一切数据库统共必要几内存、处置器能不克不及处置一切数据库的并发查询、磁盘体系能不克不及处置同时读写带来的更年夜压力。做出这个决议比晋级单一服务器坚苦很多,不外就全体的办理浅易性而言,会取得伟大报答。
  改用64位会在SQLServer的功能和扩大性方面带来严重影响。SQLServer2005供应的选项使得从32位举行晋级公道很多。假如你投资新硬件用于新的数据库办理体系(DBMS),就应该查询拜访剖析64位选项,特别是基于代价较低的x64位处置器的那些选项。
  我要不要利用新的XML数据范例把一切XML数据保留在SQLServer2005内里?
  XML酷似CLR用户界说范例(UDT),它如今是SQLServer2005中新的第一类数据范例。开辟职员如今大概会不由得利用这类数据范例,以避免编写代码把XML数据“支解”到内外面(即不是利用OPENXML往内外面批量载进数据)。
  遗憾的是,像如许利用XML数据范例存在与利用用户界说范例暗示数据一样的很多成绩。开辟职员应该把功能记在心头,由于对XML列的一个节点举行查询必要引擎对表中每行的分歧XML查询举行求值。与利用CLRUDT一样,还存在标准化成绩。在过量利用XML数据范例的数据库内里,要确保数据完全性极为坚苦。
既能够作为一个单独的应用程序应用在客户端服务器网络环境中,也能够作为一个库而嵌入到其他的软件中。
山那边是海 该用户已被删除
沙发
发表于 2015-1-19 06:43:47 | 只看该作者
索引视图2k就有。但是2005对其效率作了一些改进但是schema.viewname的作用域真是太限制了它的应用面。还有一大堆的环境参数和种种限制都让人对它有点却步。
小魔女 该用户已被删除
板凳
发表于 2015-1-26 09:41:00 | 只看该作者
原来公司用过MYSQL自己也只是建个表写个SQL
飘灵儿 该用户已被删除
地板
发表于 2015-2-4 14:03:51 | 只看该作者
我是一个ERP初学者,对于前台运用基本熟悉,但对于后台SQLServer的运用一点也不懂,特想学习下相关资料。至少懂得一些基本的运用。希望各位能给于建议,小弟再谢过!
5#
发表于 2015-2-10 01:50:02 | 只看该作者
还不是性能有问题!否则面向对象的数据库早就实现了!建议使用CLR的地方一般是和应用的复杂程度或操作系统环境有很高的耦合度的场景。如你想构建复杂的算法,并且用到了大量的指针和高级数据模型。
冷月葬花魂 该用户已被删除
6#
发表于 2015-2-28 15:05:36 | 只看该作者
SP4包括用于以下SQLServer2000组件的程序包:Database组件(下载文件:SQL2000-KB884525-SP4-x86.EXE)更新SQLServer2000的32位Database组件,包括数据库引擎、复制、客户端连接组件及工具。有关其他信息,请参阅ReadmeSql2k32Sp4.htm。AnalysisServices组件(下载文件:SQL2000.AS-KB884525-SP4-x86.EXE)更新SQLServer2000的32位AnalysisServices。
小妖女 该用户已被删除
7#
发表于 2015-3-10 00:31:51 | 只看该作者
作了些试验,发现使用CLR的存储过程或函数在达到一定的阀值的时候,系统性能会呈指数级下滑!这是非常危险的!只使用几个可能没有问题,当一旦大规模使用会造成严重的系统性能问题!
小女巫 该用户已被删除
8#
发表于 2015-3-17 04:00:04 | 只看该作者
SP4是一个累积性的ServicePack,包含自以前的ServicePack发布以来所有的修补程序(包括MS03-031安全公告)。
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

QQ|Archiver|手机版|仓酷云 鄂ICP备14007578号-2

GMT+8, 2024-12-23 00:11

Powered by Discuz! X3.2

© 2001-2013 Comsenz Inc.

快速回复 返回顶部 返回列表