SQL @ TechEd 2010

2010微软技术大会将于2010年12月1日至3日在国家会议中心举办。除了Simon Leung 和Enwei Xie的主题演讲之外,大会将开设6个动手实验营、10个分会技术课程共16个技术分类的近200场精彩课程演讲。 按照时间顺序,SQL中国研发团队将贡献如下课程: SQL Server 2008 R2 数据压缩的最佳实践技巧和新增功能 方峻12/2, 9:45-10:45 分会场八 DAT-300-3SQL Server 2008 推出数据压缩后非常受用户欢迎,得到了广泛的采用。本讲座将简单回顾一下数据压缩的功能,然后重点讨论一些常见的客户问题,实践技巧,应用场景和性能影响,并通过这些来帮助您选择什么时候采用哪种压缩技术。之后讲座将介绍 SQL Server 2008 R2 上数据压缩的新功能,对 Unicode 字符数据的压缩。 如果构建企业级的ETL 孙巍12/2, 9:45-10:45 分会场九 BIC-300-3数据整合及清洗是企业实现BI的必要步骤,生成及输出的数据是BI系统的数据基石。微软的SQL Server Integration Service(SSIS)提供了一套完整的ETL解决方案,不但从功能上满足了整合及清理的要求,还提供了强大的流程控制及扩展功能。企业级ETL解决方案不但要考虑转换功能实现,更多的是要考虑流程、性能、可管理性、可扩展性。本讲座将从企业对于ETL解决方案的需求开始完整的阐述如何使用SSIS实现企业级ETL。 SQL Server Cluster 多子网支持和新的故障检测机制 何民12/2, 11:00-12:00 分会场二 DAT-300-4课程由两部分组成:(一)SQL Server 多子网故障转移集群(multi-subnet failover clustering)可用于部署高可用系统之上的灾难恢复系统。本讲座将介绍多子网集群概念,和V-LAN解决方案的比较及部署的最佳实践。(二)即将发布的SQL Server 下一版本中,故障转移集群使用了 全新的故障检测机制。这一部分讲座包含对新的系统存储过程sp_server_diagnostics的介绍, 新的故障检测机制与SQL Server 2008 R2 之前版本的故障检测机制的对比,如何定制故障条件级别,以及演示。 SQL Server 2008 R2/PowerPivot探秘 卓伟雄12/2, 14:30-15:30 分会场九…


SQL Server Utility

在即将发布的SQL Server 2008 R2中,SQL Server Management Studio提供了一个新的管理组件:SQL Server Utility。该组件能够帮助数据库管理员以统一和集中的方式去管理多个数据库实例:Instance以及数据层应用程序:Data-tier Application。(如果你对数据层应用程序没有太多的了解,请参考这里) 本文将对该组件所针对的应用场景和相关概念做些解释,然后会对该组件的主要功能接界面做进一步的介绍。 先来看一下SQL Server Utility所要解决的用户需求吧: 随着数据库技术的越来越广泛的使用,很多企业里面都部署了一台以上的数据库服务器,并且在每个数据库服务器上都有着一个或若干个的数据库实例以及更多的数据层应用程序;想象一下,如果一个企业有着10个以上的数据库实例及更多的数据库层应用程序,对这些数据库实例与应用程序的监控与管理将是一个十分耗时而又费力的工作。而SQL Server Utility便是针对这一用户需求而开发的,在SQL Server Utility中,用户可以同时监控多个数据库实例及相关应用程序的使用状态,包括CPU、内存、硬盘等关键资源的使用情况。而且这些数据也会被保留一定时间,企业可以基于这些数据做进一步的分析,从而能够做更好的资源规划。 那么SQL Server Utility是如何做到这一点的呢?我们先来解释一下SQL Server Utility的物理架构和相关概念,然后会进一步解释具体的步骤。下图便是SQL Server Utility的物理架构:  在这一架构中,一个或者多个需要被监控的数据库实例将注册到一个统一的控制点上(UCP),而数据库管理员则可以通过其他与此控制点相连的管理终端上对那些需要被监控的数据库实例进行监控和管理。 为此,数据库管理员完成以下几步: 创建一个UCP。 将需要被监控的数据库实例或者相关的数据库应用程序注册到该UCP中。 在完成上述步骤后,数据库管理员只需要通过SQL Server Management Studio连接到创建好的UCP,便可以在dashboard上看到相关数据库实例的资源使用状态了。例图如下: 接下来我们进一步介绍如何创建一个UCP,以及如何注册一个数据库实例,并会对Utility的管理做一个简要的介绍。 创建一个UCP 1. 在创建一个UCP之前,需要注意以下若干项: a. 当前的登录帐号必须有数据库管理员权限;b. 用来创建UCP的数据库实例从来没有被创建过UCP,并且也没有注册到任何其他的UCP中;c. SQL Server Agent服务必须被设置为自动启动,缺省安装的情况下,SQL Server Agent 服务的启动方式是手动;d. SQL Server Agent的启动帐号不能是缺省的build-in的域帐号,譬如:Network Service; 2. 打开SQL Server Management Studio, 在View菜单中选择Utility Explorer; 3. 在Utility Explorer上点击:来启动创建UCP向导;  4. 点击下一步来指定在哪个数据库实例上来创建UCP,你可以在本地数据库实例上创建,也可以创建在一个远程的数据库实例上,但是数据库实例的版本号必须高于10.50。…


SQL Server 2008 R2已经RTM了!

大家期待已久的SQL Server 2008 R2 已经 Released to Manufacturing(RTM)了! SQL Server 2008 R2增强的特性为用户继续支持关键应用(mission-critical workloads)提供了一个可靠的、可扩展的平台。SQL Server 2008 R2 提高了开发者和 IT专业人员的工作效率,而且也提供了自助式商业智能报表和分析的功能。SQL Server 2008 R2一直都在创造性能以及性能/价格比的记录。 SQL Server 2008 R2,作为 Microsoft 的完整信息的平台,使收集、管理和使用业务信息更容易,也为企业提供了更经济高效的解决方案。SQL Server 2008 R2的新特性包括:PowerPivot、Master Data Services、Application and Multi-Server Management、Report Builder 3.0和StreamInsight。以下的资源让你了解更多SQL Server 2008 R2的信息: SQL Server 2008 R2 Digital Tour SQL Server 2008 R2 Homepage SQL Server 2008 R2…


大家都动手,一起用PowerPivot做自助式分析

在许多企业里,当商业用户需要分析数据时,他们往往会与IT部门的同事合作,从而创建一套商业智能解决方案。有时候,商业用户急需分析数据,并从中得到有用的信息,但是因为IT部门的项目比较多,或者商业用户要分析的资料不在IT部门的数据库里,IT 部门的同事可能需要比较长的时间来提供解决方案。因此,商业用户必须能通过自助的方式来为自己创建商业智能解决方案。 PowerPivot是什么?PowerPivot是Excel 2010的插件。PowerPivot让商业用户在熟悉的Excel环境中做强大的自助式分析。   图一:Excel 2010的插件——PowerPivot   图二: PowerPivot的环境 PowerPivot应用强大的列压缩技术,在内存中对海量的数据进行压缩。PowerPivot的引擎能对压缩后的数据进行聚合和计算,很快的让用户做互动性的分析。用户只要几下点击,便可以生成和发布出直观和互动的自助式商业智能解决方案。此外,用户可以把自己创建的PowerPivots发布到SharePoint Server 2010,与同事共享和协作。PowerPivot也让IT部门变得更强大。IT部门的同事可以同过SharePoint Server 2010中的Operation Dashboard管理PowerPivots。 今天,大家都动手,一起来做自助式分析!以下的学习资料供你参考: 通过如何应用PowerPivot来做自助式分析视频教程,大家可以学习 PowerPivot的基本功。 在2008 年十一月微软在北京和上海的技术大会,商务智能专家Donald Farmer和微软SQL中国研发部门经理赵晓燕与大家分享了商务智能的未来和Project Gemini如何让商业用户做自助式分析。参见体会Microsoft的更快、更高与更强——侧记TechEd 2008上海技术大会博文。 在2009年十一月微软的北京技术大会,Donald Farmer与我演示了PowerPivot(先前名称——Project Gemini)的各种强大功能。每一次的分享都让大家加深了对自助式商务智能的了解,和对PowerPivot的期待。参见精彩的微软技术大会(TechEd)- 你去了吗?博文。 各位IT朋友们可以到http://powerpivot.com/获取更多PowerPivot的资料。 微软商业智能(BI)团队


SSIS工程师为您揭秘数据流

我上个月有幸参加了在西雅图召开的PASS(Professional Association for SQL Server)峰会。我的同事Matt Masson做了个关于SQL Server 数据集成服务(Integration Services,SSIS)的讲座(下载),现场非常火爆,讲完后他被听众围住了个把小时。他的题目是Maximize Your SSIS Investment with Tuning Tricks and Tips,主要关于提升数据集成包(package)的性能。 他讲了四部分,其中第二部分深入浅出地介绍了SSIS数据流(Data flow)。我估计我国的用户会特别感兴趣这一块,因此在这里分享给你 🙂 数据流一瞥 SSIS的引擎(engine)是内存式(in-memory)的:从源(source)读数据,在内存中执行package,再把结果写到端(destination)。尽量不碰外存是其高性能的原因之一。很多以前使用ETL(Extract-Transform-Load)工具的人需要对此调整观念:那些工具先把数据加载到数据库里再做SQL转换,其实是ELT(Extract-Load-Transform)。Matt讲了个很有趣的案例:有位客户的package以前运行只要几分钟,自从服务器升级到新机器后竟然更慢了,要花一个小时。那个package很简单,只是源到端拷贝,中间没有转换(transform),因此客户很生气。Matt他们急忙去会诊,才发现这个package的源和端以前就在它所运行的那台机器上,在美国; 后来升级了的机器在中国,源和端都跑到了中国来,而package还是在美国那台机器上运行。结果这个package所做的就是从中国读出若干GB的数据到美国的内存,再拷回中国……Matt说,类似的客户问题其实并不少见。希望你读本文以后能避免这种设计了 🙂 SSIS在设计时(design time)阶段就确定了数据流的元数据(metadata)。它在运行之前就精确知道了运行时的列将有多宽,转换需要多少内存,等等。 数据流水线(pipeline) 当数据流启动时,源就开始把一行行数据填到一个类似桶的缓存(buffer)中。源根本不知道下游是什么。一旦缓存满了,桶就随着流水线流到下游组件(component)上,同时引擎抓一个新的空缓存过来给源。源根本不知道这一切,它只是不断地填桶。有时源填了太多的桶,转换和端都来不及应付了;此时引擎会启动反压(backpressure)机制,让源睡眠。等到流水线又有空间之后,源被唤醒继续填桶。其实在实现上,源甚至都不知道自己被催眠过(好可怜)……直到所有源数据行都发光了,源才在最后一个缓存上贴个“行集末(End Of Rowset)”的标签,把它发出去,告诉下游组件再没有新数据了。 转换与缓存拷贝 SSIS的高性能有部分归功于它在内存使用上比较聪明。在缓存之间拷贝数据是耗时的,因此引擎会尽量减少缓存拷贝。按照缓存使用的不同,可将众多转换组件分为三类。 第一类是同步(synchronous)转换,它们一般逐行对数据做就地修改,从不拷贝缓存。它们有可能增加新行,比如数据转换(Data Convert)和派生列(Derived Column)转换,而仍然是同步的:引擎事先确定了新列将加在哪里,提前就在缓存里加了空列,只是上游组件看不到这些空列罢了。异步(asynchronous)转换会动态创建新缓存,包括两小类: 部分阻塞(Partially Blocking)转换,一伺新缓存满了就把它输出,比如联合全体(Union All)组件接受多个输入流,一旦从各输入得到了足够多的行就把它输入到一个新缓存里。由于要拷贝数据,这种转换比同步转换慢;但和全阻塞(Blocking)转换相比就好多了。排序(Sort)、聚集(Aggregate)这些全阻塞转换在接收完所有输入行之前,是不会输出一行的。这是由运算本身的特点决定的:不到看到所有数据,是无法确定哪个是最小值的。 因此,在使用全阻塞转换时要格外审慎,尤其是数据量很大时。一旦内存用完,缓存被置换到硬盘上,性能就完了。要想提高数据流性能,最好设法从package中去除全阻塞转换。 线程机制 要理解数据流,还需要了解其线程机制。流水线在运行时被分成若干执行树(Execution Trees)。每个创建新缓存的组件就是一棵新执行树的起点;因此起点要么是个数据源,要么是个异步转换。下图的数据流中有5棵执行树,如蓝箭头所示。引擎限定了每棵树中最多工作的缓存数(目前定为五个),一旦更多缓存进来,就启动反压。注意到多播(Multicast)和条件分割(Conditional Split)转换都是同步的,它们在分割数据流时并不创建新缓存;引擎只是创建了一些能映射到同一块内存的虚拟缓存。所以即使你多播20次也不会看到内存消耗增多。   此图修改自Matt的幻灯片 值得一提的是,数据流线程调度在SQL 2008版本中被改进了:在2005版中,每棵树只分到一个线程执行,其问题是对于图中右边那种较长的树,虽然树里都是一序列同步转换,但每次只能在树中移动一个缓存,执行完它之后才能开始执行下一个缓存。很多人为了打碎较长的执行树,就在中间插入一个单输入的联合全体(Union All)组件,由于它是异步的,就能间接引入另一个线程。而现在,我们在2008版中改为让每个缓存上都有一个线程在执行,这样一棵树中就可以有多个线程在执行。可能第一个线程先把一个缓存进行了三个转换, 然后第二个线程捡起这个缓存继续向下游转换,同时第一个线程开始捡起下一个缓存。这样就再也不需要上述间接的方法了。 看完以上揭秘,你有收获吗? 杨珂,SSIS软件开发工程师

3

精彩的微软技术大会(TechEd)- 你去了吗?

每个微软技术大会(TechEd)对我来说都具有特别的意义。因为在这个里,我能遇到许多对微软技术有浓厚兴趣和热情的朋友们。在这个里,我们一起互动,一起讨论微软的最新技术。今年IT朋友们都共聚在北京的国家会议中心参加微软技术大会。  在这三天里,SQL Server 团队的讲师们也与大家分享了许多对云端数据库 (SQL Azure)、商业智能 (Business Intelligence)、数据库管理、虚拟化和跟踪及排错的最新发展。今年商业智能的巨人Donald Farmer 也前来赴约。Donald与大家分享了数据挖掘的技术和自助式商务智能。从数据挖掘的讲座中,大家深入了解如何应用数据挖掘的技术在 SQL Server 动态数据库管理视图(DMV) 的数据中找出异常。从自助式商务智功能的讲座中,Donald 介绍了自助式商务智能的重要性和PowerPivot 如何让熟悉Excel 的用户分析海量的数据。在演示中,大家都对PowerPivot 如何快速的分析了一亿行数据叹为观止,不约而同的热烈拍掌! 微软技术大会(TechEd)结束了!但我深信参加大会的朋友们都增加了对微软技术的了解与热情。真棒! 项目经理卓伟雄


我们TechEd见

2009年微软技术大会(TechEd)中国下周就将在北京召开了,SQL Server中国研发团队将派出多位项目经理、软件设计开发工程师和软件测试开发工程师,与中国程序开发者和IT从业人员分享我们最新的产品开发。以下是我们负责的课程、动手实验室和专家交流区列表,希望能在大会现场与大家面对面交流。 针对程序开发者 时间 课程标题 主讲人 课程简介 11/7 15:50-17:00 BAP302   SQL Server 2008 R2的自助式商务智能(英文课程) Donald Farmer 卓伟雄 类别:商务智能及商业应用平台本讲座将为您详尽介绍R2中的BI新特性,以及Gemini中的个人商务智能 针对IT专业人士 时间 课程标题 主讲人 课程简介 11/6 8:00-9:10 DAT331   先睹为快 微软云计算数据库平台 — SQL Azure 吴中伟 李刚毅 类别:数据平台管理与开发 本讲座将为您介绍清晰而全面的SQL Azure信息包括SQL Azure的架构、基本概念、目前支持的各种功能等。 11/6 13:00-14:10 DAT201 SQL Server 2008 数据库引擎: 产品发布十五个月后 王枫 类别:数据平台管理与开发 本讲座将对SQL Server 2008针对数据库引擎的主要新功能作一个全面的介绍。 11/6 14:25-15:35 DAT221   SQL Server…


Microsoft SQL Server 2008故障转移群集在Hyper-V虚拟机上的多种组建方式

Hyper-V虚拟机给我们带来了诸多便利,比如应用程序整合、节能、节约成本、提高资源利用率等等。随着Hyper-V虚拟机的推广,用户的使用越来越普及。很多用户在Hyper-V虚拟机中用到了MS SQL Server。但是单独(standalone)的SQL Server 不能提供高可用性和灾难恢复的功能。在对可用性有较高要求的Hyper-V用户面前,故障转移群集(Failover cluster)是必然用到的功能。当虚拟的生产服务器宕机时,热备份中的虚拟的服务器可以很快投入工作中。 然而在虚拟机上搭建故障转移群集比在物理机上搭会有更多种组合。 本文中介绍各种搭建方式的优点和缺点。您可以在虚拟机上搭建SQL Server 故障转移群集以供学习与自娱。需要提醒的是,搭建需要满足如下前提条件: Hyper-V要求的宿主机(host machine)必须是Windows 2008 x64 或 Windows2008 第二版 x64(差点忘了,用免费的securable软件可以检查你的宿主机CPU是否支持硬件虚拟化,2009年买的新机通常都是支持的)。虚拟机的操作系统可以是Windows 2003、Windows 2008、Windows 2008第二版(x64或x86)等不限。 熟悉Windows Cluster service的兄弟们都知道要搭建Cluster的机器必须拥有共享硬盘。Hyper-V还有个更严厉的要求:两个虚拟机搭cluster需要的共享硬盘必须是支持iSCSI的共享硬盘才行。可以是支持iSCSI的SAN或iSCSI的仿真软件(iSCSI Target和iSCSI Initiator)。 真实生产环境中的当然得买老贵的iSCSI SAN了。如果只是搭一个供自己欣赏或者搞个开发、测试环境的话当然是用仿真软件来仿真出几个共享硬盘省钱了,仿真软件可在网上搜索下载。有了仿真软件普通台式机就可以搭建,SCSI的物理设备可以统统不用。幸福吧?做过Cluster的老人们都还记得在Hyper-V出现之前,搭个故障转移群集有多麻烦,软件硬件都有特殊要求啊。 2节点的SQL Server故障转移群集是最常见的,更多节点的故障转移群集(最多16个)的搭建方式和2节点故障转移群集的搭建方式类似,所以在本博文中不讨论。 在Hyper-V虚拟环境中有很多种搭建故障转移群集的方式足有5、6种之多。哪种方式比较实用用户往往无所事从。本文中我们将分析虚拟环境中有很多种搭建故障转移群集的方式及其利弊,供各位IT兄弟们参考。为了描述清楚,各种搭建方式用A、B、C、D、E和F来编号。 方式A如下图  方式A 需要2台宿主机,两台宿主机的本地硬盘(例如E:)上各放着一个虚拟机的虚拟硬盘文件(.vhd),映射为虚拟机的操作系统C:。2个虚拟机在每个宿主机上分别启动,共同组建成一个SQL Server故障转移群集。可以看到2个虚拟机要用到iSCSI SAN了吧? 那个就是共享盘。SQL Server跑在虚拟机Child1中,当Child1宕机的时候就会发生failover,共享盘Q:, R:就自动被第二台虚拟机Child2上的SQL Server抢到,第二台虚拟机上的SQL Server就开始工作了,如下图所示:  方式A是最容易想到的一种搭建方式。而且提供了高可用性的支持。如果有带冗余的网络和SAN, 可以用在生产环境中。(我可没说iSCSI仿真软件可以用在生产环境中啊,仿真软件感觉有点慢,而且没有冗余) 方式B如下图  方式A看起来有点费钱了,要2台物理机,想省物理机吗?那么试试方式B,您只要1台够了。既然每台宿主机可以同时跑多台虚拟机,我把2台组建SQL Server cluster的虚拟机跑在同一台宿主机上不就可以了? 如上图所示。如果你青睐iSCSI仿真软件,iSCSI SAN的钱也可以省掉,彻底的虚拟化了。你可以在唯一的宿主机上跑2个虚拟机的同时,宿主机还装了iSCSI Target可以模拟虚拟机所需要的共享盘。爽! 方式B的好处是,你可以把SQL Server cluster整个放到自己的笔记本中去。要演示SQL Server cluster怎么工作只要带着1个笔记本就够了(俺的笔记本是支持Hyper-V的…


SQL Server 2008故障转移集群概述

故障转移集群(Failover Cluster)是实现SQL Server高可用性解决方案之一。一个集群通常由多台服务器组成,每台服务器称为一个节点。通过使用冗余节点来减少宕机时间,为客户关键业务的高可用性提供了有力的保障。与以前版本相比,SQL Server 2008故障转移集群做了很大改进,不但简化了安装和维护,而且提供了新功能减少系统维护时的宕机时间,比如循环升级、循环打补丁等。本文将简述一下SQL Server 2008故障转移集群的基本结构和原理。 SQL Server 2008支持本地集群,即所有节点都在同一个子网内,通常位于同一个物理地点;如果节点跨越不同区域,则必须把所有的节点都配置到同一个VLAN中,所以在上层的集群看起来还是同一个子网内。一个典型的故障转移集群的架构如图1所示。  首先要指出的是,SQL Server故障转移集群有两个核心层次,一个是Windows层,一个是SQL Server层。Windows故障转移集群是一个平台,提供了与应用无关的故障转移的基本功能,比如节点之间心跳检测、故障转移策略管理等。在其上可以构建很多故障转移集群的具体应用,而SQL Server故障转移集群正是其中之一(其他故障转移集群的应用还有很多,比如邮件服务器、文件服务器、打印服务器等)。因此,安装SQL Server故障转移集群前,必须要先把所用的节点加入到同一个Windows故障转移集群中。向现有的集群中增加新节点也是如此。SQL Server 2008故障转移集群推荐安装在Windows Server 2008上,因为该版操作系统大大简化了Windows故障转移集群的管理维护。 和独立的SQL Server一样,SQL Server的故障转移集群也支持多实例。每一个SQL Server故障转移集群的实例都有一个虚拟的网络名字,客户通过该名字访问集群数据库就和访问一台物理的数据库服务器一样。所以虽然集群内部有很多节点,但客户是感觉不到的。正常运行时,只有一个节点上的SQL Server实例进程在运行,此节点称为活动节点(Active Node),而所有其他节点则称为被动节点(Passive Node)。集群的虚拟网络名字总是映射到当前活动节点的IP上。 和独立的SQL Server不同的是,SQL Server故障转移集群的数据不能存储在本地磁盘上,而必须存储在共享的SAN(Storage Area Network)上。实际上SAN是在Windows故障转移集群中配置,然后分配给SQL Server故障转移集群的实例使用的(在安装时指定)。通常SAN总是被当前的活动节点独占使用的,从而避免了多节点同时访问可能造成的数据损坏。 故障转移有两种形式,一种是由管理员发起的,一般是在对当前活动节点进行系统维护之前先把整个集群转移到其他节点上;另一种是系统检测到故障时自动进行的故障转移。故障转移过程如图2所示。Windows故障转移集群会首先停止当前活动节点上的SQL Server实例进程,然后根据该实例的故障转移策略选择一个新的节点,最后在此新节点上启动SQL Server的实例进程,同时获得对SAN的独占访问权。这个节点就成为了新的活动节点,虚拟网络名字也随之映射到此新节点上,从而保证客户应用还能正常连接数据库。由于数据都是存储在共享的SAN上的,在故障转移过程中并不需要数据复制。宕机时间只发生在故障转移时短暂的瞬间,即旧的活动节点的实例进程被停止后,到新的活动节点的实例进程正常工作之前。当然,故障转移之前的客户连接都会被中断,所有未完成的事务都会被回滚,并且故障转移完成之后,客户端需要重新连接数据库。 那么在系统自动触发的故障转移中,系统是如何检测故障及采取措施呢?这就需要探讨一下故障的检测和转移策略。 故障的种类多种多样。如前所述,Windows故障转移集群为集群应用提供了底层服务,与之对应,一些底层的故障,比如网络故障、磁盘故障等,也是由它来检测的。而每个SQL Server集群实例自身的故障(比如拒绝客户端连接、无响应等)则是由一个为SQL Server定制的集群资源来检测的,称为“SQL Server资源”,其任务就是定期去查询数据库的状态。具体来说有两种查询:一个是“LooksAlive”,另一个是“IsAlive”。前者是一个轻量查询,缺省配置下每5秒钟检查一下SQL Server服务的状态,并不去连接数据库,所以对数据库的影响很小,查询次数也比较多;而后者是要连接到数据库中去执行一下SQL语句“SELECT @@SERVERNAME”判断是否能返回正确的结果,对数据库的影响较大,尤其是系统繁忙时,所以只在每60秒钟,或者“LooksAlive”查询失败时才会去执行一次。 故障发生时,默认的转移策略就已经能满足很多用户的需求了。当然,用户还可以随时根据自己的特殊需求,用Windows集群管理器(Failover Cluster Manager)对集群实例内的每个资源单独配置不同的策略。同时,同一集群实例内的资源之间会通过特定的依赖关系(如图3所示)而互相影响。如果出故障资源变成“失败”状态从而导致其上层资源的依赖关系不能成立,则该上层资源也会变成“失败”状态;如果要转移到新节点,则同实例内部的所有其他资源都会跟着转移。 集群内部的状态信息都会同时记载到集群日志和Windows事件浏览器中,所以一旦集群发生了异常,总可以通过研究这些信息了解系统状态变化的全过程。 您可以参考以下链接获得Windows和SQL Server故障转移集群更详细的信息: Windows Server 2008 Failover Clusteringhttp://www.microsoft.com/Windowsserver2008/en/us/failover-clustering-main.aspx SQL Server…


SQL HADR多个技术概览和比较

对于企业级用户和关键系统来说,最重要的要求之一就是系统的高度可用性和数据的安全性(High Availability and Disaster Recovery,HADR)。我们先来了解一下HADR的问题空间。HADR有两个目标和衡量方式: 保证系统可用目标恢复时间(Recovery Time Objective,RTO):出了故障后把系统恢复正常工作状态所需要的时间。 保证数据安全目标恢复点(Recovery Point Objective,RPO):系统数据能恢复到故障前的哪个时间点。换而言之,故障后你能容忍多少数据损失。 故障又主要有两大类别: 计划宕机时间 硬件升级 软件补丁(操作系统,应用程序),应用程序升级 维护操作 意外宕机时间 无法预料的故障 硬件故障,软件故障,电力中断,数据损坏 站点故障:火灾,地震,洪水 用户或应用程序错误 意外更改,不正确的数据操作 针对不同的可用性要求和故障类别,SQL Server提供多样的HADR技术来满足用户的需要。但怎样从中选择最合适的技术?下面是对SQL可用性技术和功能的一个概览: 意外宕机时间 SAN/RAID 备份和恢复(Back Up and Restore) 日志传送(Log Shipping) 数据库镜像(Database Mirroring) 故障转移群集(Clustering)复制(Replication) 计划宕机时间 轮流升级和打补丁(Upgrade and Patching) 在线操作(Online Operations) 资源管理器(Resource Governor) 数据库快照(Database Snapshot) SQL Server HADR 技术比较  这些技术都有自己的特点和要求,用户可根据自已需求,配置,和预算来选择,以满足HADR在目标恢复时间(RTO)和目标恢复点(RPO)的要求。 希望您能通过本文对SQL HADR技术有个大致了解,以后我们会再详细介绍其中的一些技术,谢谢。 SQL Engine部门经理吴家震

1