名站网址导航为大家提供关于数据库教程相关的教程网站知识。
误区 #1：在 站点服务器故障转移后，正在运行的事务继续执行浅谈SQL Server中的三种物理连接操作办法(性能比较)
图2.循环嵌套连接的第二步,通过嵌套循环连接也可以看出，随着数据量的增长这种相关方式对性能的消耗将呈现出指数级别的增长，所以数据量到一定程度时，查询分析器往往就会采用这种相关方式。,下面咱们通过例子来看一下循环嵌套连接,利用微软的AdventureWorks网站数据库:,图3中ProductID是有索引的，并且在循环的外部表中（Product表）符合ProductID=870的行有4688条，因此，对应的SalesOrderDetail表需要查找4688次。让咱们在上,由图4中可以看出，由于多选择了一个UnitPrice列，导致了连接的索引无法覆盖所求查询，必须通过书签查找来进行，这也是为什么咱们要养成只Select需要的列的好习惯，为了解决上面的问题，咱们既可以用,可以看出，查询分析器此时选择了表扫描来进行连接，这种相关方式效率要低下很多，因此好的覆盖索引和Select *都是需要注意的地方。另外，上面情况即使涉及到表扫描，依然是比较理想的情况，更糟糕的情况是使用多,由图6中，咱们可以看出，估计的行数和实际的行数存在巨大的偏差，从而应该使用表扫描但查询分析器选择了书签查找，这种情况对性能的影响将会比表扫描更加巨大。具体大到什么程度呢？咱们可以通过强制表扫描和查询分,合并连接(Merge Join),谈到合并连接，我突然想起在西雅图参加SQL Pass峰会晚上酒吧排队点酒，由于我和另外一哥们站错了位置，貌似咱们两个在插队一样，我赶紧说:I'm sorry,i thought here is end,由上面的小故事不难看出，Merge Join其实上就是将两个有序队列进行连接，需要两端都已经有序，所以不必像Loop Join那样不断的查找循环内部的表。其次，Merge Join需要表连接条件中至少,Merge Join的过程咱们可以简单用下面图进行描述:,Merge Join首先从两个输入集合中各取第一行，假如如果匹配，则返回匹配行。加入两行不匹配，则有较小值的输入集合 1，如图9所示。,用C#具体相关代码表示Merge Join的话如具体相关代码1所示。,复制具体相关代码 具体相关代码如下:
这当然是错误的!
每次故障转移都伴随着某种形式的恢复。但是假如如果当正在执行的事务没有Commit时，由于站点服务器或实例崩溃导致连接断开，SQL Server可没有办法在故障转移后的站点服务器重新建立事务的上下文并继续执行事务-无论您使用的故障转移相关方式是集群，镜像，日志传送或是SAN复制。
对于故障转移集群来说，当故障转移发生后，一个SQL Server实例在另一个故障转移集群的节点启动。所有实例上的网站数据库都要经历Recovery阶段-也就是所有没有Commit的事务都要被回滚。
对于网站数据库镜像来说，来自主体站点服务器的日志不断传送到镜像站点服务器进行Redo操作办法。当镜像站点服务器被切换作为主体站点服务器时，原镜像站点服务器的事务日志将会变为Recovery模式，这使得好像原镜像站点服务器经历了一次崩溃那样，在这之后所有的连接都会导向原镜像站点服务器。
对于事务日志传送来说，事务日志被定期备份并传送到辅助站点服务器.当主站点服务器崩溃时,DBA按照恢复顺序将辅助站点服务器恢复后上线.但最终步骤都是要执行recovery步骤，也就是将没有提交的事务进行回滚。
对于SAN复制来说，本地SAN的I/O被复制到远程SAN上进行重放，当故障转移发生后,系统将会连接到远端SAN但网站数据库仍然需要执行recovery步骤，这和故障转移集群极其类似。
“唯一”使得正在执行的事务在故障转移发生后仍然得以继续执行的技术使用带有实时迁移功能的虚拟化技术，因为这时连接本身并不知道其连接的对象已经变为另一台物理站点服务器。
但是无论使用那种技术，假如如果”连接”失效，正在执行的事务将会丢失，所以处理这类问题的这部分工作就需要在程序中用具体相关代码实现某种“重新执行”的功能。 关于数据库教程相关的教程网站知识今天我们就说到这里了，希望可以帮到大家。
