MSSQL编程：SQL SERVER 2005数据库镜像（3）

因此我们看到，这些信息足够让我们对单个操作实现“逆操作”。　　由于ServerA没法瞥见见证服务器ServerW大概本来的镜像同伴ServerB，因而必需进进disconnected形态并使数据库不成用。
　　ServerB和ServerW能够构成quorum。ServerB没法瞥见ServerA，因而ServerB试图成为主服务器并使其数据库联机。由于ServerW也看不到ServerA，因而批准了ServerB。ServerB如今有了quorum，承当起会话的主服务器脚色，然后复原其数据库。
　　假如恢复通讯连路，ServerA可以看到ServerB现在成为主服务器，并检测到见证服务器ServerW也承认ServerB为主服务器。ServerA将其脚色转换为镜像服务器，然后实验与新主服务器同步。同步以后的设置了局如5所示。

登录/注册后可看大图

　　5：该场景通讯连路恢复后的版本，数据库镜像按反偏向举行
　　总结：见证服务器位于镜像服务器的远程站点上，假如站点间的通讯链路中止，主动的妨碍转移发生。
　　场景HACL5：两个站点，见证服务器位于主服务器站点
　　在这个高可用处景中，假定将见证服务器安排在主服务器地点的统一站点上，如6所示，然后两个站点间的通讯中止了。

登录/注册后可看大图

　　6：主服务器/见证服务器和镜像服务器之间的通讯中止
　　在这类情形下，卖力镜像数据库的ServerB被主服务器和见证服务器伶仃。
　　ServerA和ServerW持续构成quorum，因而ServerA坚持其数据库为主数据库。
　　可是，ServerA同时将数据库设置成disconnected形态，由于它没法看到ServerB也不成能举行数据传输。ServerB也没法看到ServerA，因而也进进disconnected形态。设置了局如7所示。

登录/注册后可看大图

　　7：该场景中通讯失利招致两个同伴为disconnected形态
　　ServerA持续承受事件但没法截断事件日记纪录。假如敏捷恢复了链路，镜像会话还能够从头同步并前往到初始操纵形态。
　　总结：见证服务器和主服务器位于统一站点，镜像服务器位于远程站点，站点之间的通讯中止不会发生主动的妨碍转移。
　　总结：高可用处景中通讯连路中止
　　在利用三台自力服务器的高可用设置中，有三条自力的通讯连路。
　　◆主服务器/镜像服务器呈现通讯失利，没有主动的妨碍转移会产生。
　　◆主服务器/见证服务器起首呈现通讯失利，随后主服务器/镜像服务器通讯中止，主动的妨碍转移将产生。恢复链路将持续反偏向的数据库镜像。
　　◆镜像服务器/见证服务器通讯失利，没有主动的妨碍转移会产生。
　　在只要一条通讯连路的高可用设置形式中，见证服务器驻留在主服务器大概镜像服务器地点站点上。
　　◆见证服务器驻留在镜像服务器的远程站点上，假如站点之间的通讯链路中止，那末主动的妨碍转移将产生。
　　◆见证服务器和主服务器位于统一站点上，镜像服务器在远程站点，站点之间的通讯中止不会招致主动的妨碍转移产生。
　　高回护计划
　　高回护形式共同safetyFULL一同事情，但没有见证服务器。由于镜像设置中只包含主数据库服务器和镜像数据库服务器，因而只要一条通讯连路。这使场景数目年夜年夜下降。
　　场景1：高回护操纵形式只包含两个SERVER实例，主服务器和镜像服务器。因为没有见证服务器，主动的妨碍转移师不成能的。服务器之间唯一一条通讯连路会中止，招致设置了局如8所示。

登录/注册后可看大图

　　9：高回护场景中假如镜像服务器不成用，那末主数据库不受影响
　　场景3：高回护场景中假如主数据库不成用，那末镜像数据库必需持续担当镜像，但进进disconnected形态，如0所示。

登录/注册后可看大图

　　0：高回护场景中假如主数据库不成用，那末镜像数据库进进disconnected形态
　　由于高回护操纵形式利用safetyFULL，因而任何损坏都招致主数据库比可用，而镜像数据库持续保持recovering形态：没无数据库是联机的。其了局是：该形式关于高可用性需求而言不是一个好的办理计划，因而更合适作为一种一时计划，如必需将见证服务器移除一小段工夫。
　　高功能计划
　　高功能操纵形式共同safetyOFF一同事情。没有见证服务器脚色。由于镜像设置中只包含主数据库服务器和镜像数据库服务器，因而只要一条通讯连路。只管相似于高回护形式，但因为safety设置为OFF，因而其举动与高回护形式其实不不异。
　　场景1：在高功能操纵形式中利用两个SQLSERVER实例。一个卖力主数据库另外一个卖力镜像数据库。因而服务器之间只要一条通讯连路而且大概中止，招致如1所示的设置了局。

登录/注册后可看大图

　　1：高功能场景中通讯失利，两个同伴均进进disconnected形态，可是主数据库仍然可用
　　因为safety设置为OFF，ServerA不必要quorum就能够使数据库坚持为可用形态。因而只管已进进disconnected形态，主服务器还能够持续承受用户举动。假如通讯恢复，那末镜像数据库将实验追逐主数据库但没法做到，大概呈现redo毛病，假如它不克不及找回一切丧失的事件。
　　场景2：在高功能场景中，假如镜像数据库不成用，那末主数据库了局显现在2中。

登录/注册后可看大图

　　2：假如在高功能形式下镜像服务器不成用，主数据库不受影响
　　因为safety设置为OFF，因而主数据库仍然可用。
　　场景3：假如在高回护形式下主数据库不成用，那末镜像数据库仍然作为镜像，但将被断开，如3所示。

登录/注册后可看大图

　　3：假如主服务器不成用，那末ServerB不会遭到影响，可是进进disconnected形态
　　高功能操纵形式和高回护形式一样，没有主动的妨碍转移。因为safety设置为OFF，当镜像服务器不成用时，主服务器将坚持其数据库为可用。一样因为safety设置为OFF，不包管事件必定抵达镜像数据库。假如强迫妨碍转移到镜像服务器，那末有些事件大概会因而丧失。
　　完成数据库镜像
　　能够在SQLSERVER2005BooksOnline，数据库镜像主题的“HowTo”中找到完成数据库镜像的基础信息。在白皮书的这一部分，我们来研讨完成数据库镜像的一个特别示例和最好理论。
　　监督数据库镜像
　　经由过程在SQLSERVER2005ManagementStudio的ObjectExplorer中反省主数据库和镜像数据库，能够查明每一个数据库镜像同伴的形态。假如主数据库和镜像数据库是同步的，那末ObjectExplorer就在主数据库称号的前面附加一个（Principal，Synchronized）动静，在镜像服务器称号的中间附加一个（Mirror，Synchronized）。能够在主服务器上弹出的数据库Properties对话框中察看Mirroring页面下方的形态框，从而反省数据库镜像会话的形态。（数据库Properties对话框不会在镜像服务器上翻开）。
　　还能够查询数据库镜像目次视图sys.database_mirroring和sys.database_mirroring_witnesses（更多关于利用目次视图反省镜像会话中数据库形态的信息，请参阅该白皮书后面数据库静态部分的“DatabaseMirroringCatalogViewMetadata”。SQLSERVERBooksOnline中也包括了目次视图的完全文档。）
　　数据库镜像功能计数器
　　可使用功能计数器监督数据库镜像会话中镜像同伴之间的收集流量。SQLServerDatabaseMirroring工具包括了大批有效的功能计数器来监督主服务器和见证服务器。（参阅SQLServerBooksOnline中的"MonitoringDatabaseMirroring"）
　　能够在每一个数据库上设置DatabaseMirroring工具。假如必要在一台服务器上监督不止一个数据库，那末既能够独自监督某个数据库的举动，也能够监督一切数据库的全体举动。
　　关于主服务器，LogBytesSent/sec计数器唆使主服务器发送日记数据到镜像服务器的速度，而LogSendQueue唆使在某个给准时间点事件日记缓冲区中有几字节要发送到镜像服务器。跟着事件日记纪录从主服务器发送到镜像服务器，主服务器的发送行列将渐渐减少，但也会跟着新的日记纪录进进日记缓冲区而增加。主服务器上的TransactionDelay计数器唆使主服务器因为守候镜像服务器关于日记吸收切实其实认动静招致的提早。主服务器上的Sent/sec计数器与主服务器给镜像服务器发送的数据页面有关。
　　在镜像服务器上，LogBytesReceived/sec唆使镜像服务器和主服务器之间相差几。（见下面LogBytesSent/sec计数器）。RedoQueue计数器唆使redo行列的巨细。镜像服务器在redo阶段利用redo行列从头实行来自立服务器的事件。RedoBytes/sec唆使镜像服务器实行redo行列中事件的速度。
　　关于每一个同伴服务器，Sends/sec和Receives/sec计数器唆使有几个发送和吸收举措BytesSent/sec和BytesReceived/sec计数器唆使在每一个同伴服务器上那些发送和吸收举措包括的字节数。
　　估量Redo和Catch-up工夫
　　假如呈现妨碍转移，可使用RedoQueue和RedoBytes/sec来预算镜像数据库完成redo并成为可用形态必要消费的工夫。利用上面的复杂公式举行盘算：
　　估量的redo工夫（秒）=
　　(RedoQueue)/(RedoBytes/sec)
　　相似的，假如主服务器上的举动抢先于镜像服务器，可使用LogSendQueue和LogBytesReceived/sec计数器预算镜像服务器追逐上主服务器必要消费的工夫。上面给出了盘算公式：
　　估量的catchup工夫（秒）=
　　(LogSendQueue)/(LogBytesReceived/sec)
　　Profiler事务
　　SQLServer2005Profiler包括了一个数据库镜像事务类。Database:DatabaseMirroringStateChange事务将纪录被监督服务器是不是产生了形态改动。（拜见SQLServerBooksOnline主题“DatabaseMirroringStateChangeEventClass”）。当利用这个事务类时包括DatabaseName和State来会对您年夜有匡助。可使用该事务关照您数据库镜像会话中的任何形态改动。
　　数据库镜像排错
　　数据库镜像最简单堕落的中央就是设置历程和运转历程。
　　扫除设置毛病
　　假如已设置了数据库镜像可是没法启动，那末从头入手下手一切设置步骤。
　　1.确认镜像服务器尽量靠近主数据库。假如实验启动数据库镜像时收到了以下的毛病动静：
　　远程“AdventureWorks”数据库没有前滚到当地数据库日记正本中包括的一个工夫点。（MicrosoftSQLSERVER，毛病：1412）
　　申明镜像数据库滞后于主数据库。必要将主数据库的事件日记备份使用到镜像数据库（利用NORECOVERY），从而使镜像数据库恢复到某个工夫点，并能够今后工夫点入手下手吸收来自立数据库的日记纪录。
　　2.确认每一个服务器的SQLSERVERWindows服务帐户相互互相信托。假如服务器地点的域没有创建信托干系，那末确包管书是准确的。
　　3.经由过程查询sys.database_mirroring_endpoints目次视图，确认不但界说并且启动了endpoint：
SELECT*FROMsys.database_mirroring_endpoints;</p>　　确认利用了准确的完整限制盘算机称号和准确的端标语。假如在一台物理服务器的多个实例之间设置镜像，那末端标语就必需是独一的。SQLSERVER服务上岸帐号必要CONNECT到endpoint的会见权限。
　　最初，确以为服务器界说了准确的endpoint脚色。
　　4.确认在ALTERDATABASE命令中指定了准确的镜像同伴称号。能够在主服务器和镜像服务器的sys.database_mirroring目次视图中（和高可用形式下的sys.database_mirroring_witnesseswitnesses）反省镜像同伴称号。
　　扫除运转时毛病
　　假如数据库镜像设置准确，然后在运转过程当中呈现了毛病，请反省会话确当前形态。假如因为毛病而使镜像处于SUSPENDED形态，便可能在镜像服务器上发生redo毛病。反省并确认镜像服务器上有充足的磁盘空间用于redo（数据文件地点分区的残剩空间）和日记hardening（日记文件地点分区的残剩空间）。当您筹办从头启动会话时，利用ALTERDATABASE来从头入手下手会话。
　　假如没法毗连到主数据库，最大概的缘故原由就是safety设置为FULL而且主服务器没法构成quorum。这类情形可以产生，比方，假如体系在高回护形式下运转（safety为FULL但没有见证服务器），镜像服务器又断开了和旧的主服务器的接洽。能够在镜像服务器上利用上面的命令强迫镜像服务器举行恢复：
ALTERDATABASE[AdventureWorks]SETPARTNERFORCE_SERVICE_ALLOW_DATA_LOSS</p>　　成绩就在于一旦恢复了镜像数据库，镜像服务器将成为主服务器但却没法构成quorum，因而没法服务于数据库。假如那样的话，只需把safety设置为OFF就能够同意它服务于数据库了。
　　平安性与功能
　　数据库镜像的功能是关于举动范例和事件平安性的一个函数。
　　传输日记到镜像服务器会影响主服务器功能。数据库镜像给主服务器带来的开支是关于举动范例的一个函数。数据库镜像在多用户和大批长事件的体系上操纵功能最好，由于数据库服务器一般的事件举动会掩饰传输日记纪录到镜像服务器的引发的开支。假如单个用户按次实行大批短事件，那末数据库镜像给每一个事件酿成的开支将非常明显。
　　主服务器功能一样受Safety设置的影响。当safety设置为FULL时，主服务器必需守候镜像服务器暗示已收到日记纪录切实其实认信息，才能够将事件提交动静前往给客户端。假如有大批的用户和大批的长事件，那末这类守候招致的开支其实不分明。单线程体系和包括很多大事务的体系在safetyOFF时能够运转的更好。
　　由于镜像服务器接二连三地从头实行从主服务器吸收的数据更新事件，镜像服务器的数据缓存将变得hot。换句话说，就是利用那些和主服务器范例不异的数据更新操纵所触及的数据页面和索引页面来加工缓存。为了使镜像服务器的缓存更靠近于主服务器缓存，数据库镜像将一个SELECT提醒也传送给镜像服务器，从而能够在镜像服务重视重生成用于数据查询的缓存内容。如许能够匡助镜像服务器更靠近于主服务器，同时削减妨碍转移时残剩的redo工夫。很分明，镜像服务器上任何其他举动，包含对数据库快照的查询也会影响缓存的形态，并因而增添妨碍转移时完成日记redo的工夫。
　　测试数据库镜像
　　当设置本人的体系来测试数据库镜像时，有很多选项可用。一切数据库镜像都请求在数据库镜像会话中的服务器必需是分歧的SQLSERVER实例。因而能够在一台物理服务器上设置和测试数据库镜像，假如您安装了多个SQLSERVER2005干系数据库引擎。也能够在一台假造服务器上测试多个实例，可是在物理服务器长进行测试加倍可托。
　　举行数据库镜像的负载和压力测试时必要分歧的物理服务器。一台服务器上的两个大概三个实例大概会损耗不实在际的服务器资本。别的服务器之间的收集毗连质量也一样主要。主服务器和镜像服务器之间的收集越好，日记纪录和动静传送的速率就越快。
　　最传神的测试就是在一台真实的方针服务器大概实验台长进行，而且和终极体系的物理属性完整不异。当您在一台服务器上测试多个实例时，只能经由过程中断实例大概关机的体例来摹拟数据库镜像中服务器失利的效果。利用多台物理服务器时，就能够经由过程断开网线的体例来测试收集毗连失利的效果。
　　上面的理论可以匡助您创立测试情况：
　　◆要测试服务器失利，封闭SQLSERVER实例，经由过程SQLConfigurationManager大概利用SHUTDOWNWITHNOWAIT。
　　◆要测试通讯失利，拔失落服务器上的网线。
　　◆要测试数据库失利，中断SQLSERVER服务，从头定名。mdf文件，然后再重启SQLSERVER。
　　◆要招致镜像数据库的redo毛病，为主数据库增加一个新文件，将文件寄存在主服务器存在但镜像服务器中不存在的分区中。
　　◆另外一种招致镜像服务器redo毛病的办法就是强迫镜像服务器的数据库文件空间不敷。
　　◆要迫使主服务器的数据库复工，强迫主数据库数据文件空间不敷。
　　◆要招致主数据库或镜像数据库日记缓冲区hardening失利，强迫日记文件空间不敷。
　　为妨碍转移筹办镜像服务器
　　数据库镜像实在就是数据库到数据库的接洽。只要数据库中的数据会经由过程日记纪录从主数据库发送到镜像数据库。就像日记传送和复制一样，必需筹办备用服务器和镜像数据库，以便呈现妨碍时能够完整接受主数据库的事情。当您筹办镜像服务器时，应当从以下几个层面举行思索。
　　在物理服务器层面，确保备用服务器和主服务器具有不异的大概尽量靠近的物理CPU和内存设置，不然备用服务器在妨碍转移后将没法胜任事情。别的大概另有一些撑持使用程序、监督器、和撑持程序运转的可实行文件等等，都必要在镜像服务器长进行设置。
　　在SQLSERVER层面，确保备用服务器和主服务器具有不异的SQLSERVER设置（比方，AWE、最年夜并行化水平）。但最主要的就是上岸帐户和账户权限。主服务器上一切激活的SQLSERVER上岸帐户都必需同时存在镜像服务器上，不然一旦呈现妨碍转移，那末使用程序将没法利用这些上岸帐户毗连到新的主服务器上。可使用SQLSERVER集成服务的TransferLogins义务将上岸帐户和暗码从一台服务器拷贝到另外一台服务器，但您还必需为这些上岸帐户设置数据库权限。假如将上岸帐户传输到另外一个分歧的域，那末大概呈现不婚配色的SID，必要您往婚配它们。
　　SQLSERVER主服务器上大概还存在大批的撑持工具必要被转移到备用服务器上：SQLAgent功课和警报、SQLSERVER集成服务包、撑持数据库、毗连服务器的界说、备份设备、保护企图、SQLMail大概数据库设置、大概另有散布式事件和谐器（MSDTC）设置，等等。
　　当SQLAgent功课被传输到备用服务器后，年夜部分将自愿设置为禁用。一旦呈现妨碍转移，必要您启用这些功课。
　　妨碍转移后，假如使用程序利用SQLSERVER考证，还必要将SQLSERVER新的主服务器上的上岸帐户剖析成新的主服务器上的数据库用户。完成该义务最好的工具就是存储历程sp_change_users_login。
　　多半据库的成绩
　　很多使用程序利用一台服务器上的多个数据库。多个数据库能够被一个使用程序援用，也大概被多个使用程序援用。可是数据库镜像每次只能在一个数据库上事情。当您计划数据库镜像时必要思索这一点。
　　假如您但愿高可用形式，那末最合适的就是一个使用程序共同一个数据库。当主动的妨碍转移产生时使用程序不再必要主服务器上的任何数据库。思索假如多个数据库在一台服务器上而且操纵在高可用形式下，那末大概呈现甚么情形呢？假如一台物理服务器失落电了，大概一个SQLSERVER实例失利了，大概收集通讯失利了，那末一切数据库将主动妨碍转移到备用服务器，而他们的镜像将成为新的主数据库。假如见证服务器可用，使用程序能够毗连到新的主数据库。可是假如某个数据库因为磁盘失利而发生了分页，因而只要这个数据库被妨碍转移，那末会产生甚么呢？假如那样的话，使用程序就有大概没法毗连到一切准确的数据库。
　　因而依附多半据库的使用程序不合适利用数据库镜像的高可用形式。您能够将safety设置成OFF，实践上就是不利用主动妨碍转移，但您必须利用某种高效的体例坚持和别的数据库服务器的同步。
　　数据库镜像和高可用性手艺
　　SQLSERVER2005如今最少撑持四种高可用性手艺，只管分歧手艺互相之间有些功效堆叠，但每种手艺都有各自的优弱点。这些手艺是：
　　◆数据库镜像&ndash;为了便于会商，我们将思索高可用操纵形式和FULLsafety和见证服务器。
　　◆妨碍转移聚集&ndash;最典范的设置就是2节点的Windows妨碍转移聚集设置一个SQLSERVER实例。
　　◆日记传送&ndash;接纳SQLSERVER内置的日记传送和一个自力的监督服务器。
　　◆事件复制&ndash;一台分发服务器和一台定阅服务器，假如刊行服务器失利，定阅服务器作为备用服务器。
　　在这一部分我们将对照这四种手艺的基础功效，然后深切切磋如何对数据库镜像举行增补大概供应一个更好的办理计划。
　　下表显现了四种手艺的几个高可用性功效。
　　表14：对照SQLSERVER2005高可用性手艺
　　种别
　　可用性功效
　　数据库镜像(HA形式)
　　妨碍转移聚集
　　日记传送
　　事件复制
　　妨碍转移特征
　　备用服务器范例
　　Hot
　　Hot
　　Warm
　　Hot
　　主动脚色转换
　　是
　　是
　　必要本人编写代码
　　必要本人编写代码
　　妨碍转移保存已提交的事情
　　是
　　是
　　否
　　否
　　妨碍转移范例
　　主动和手动
　　主动和手动
　　妨碍转移历程数据库复工工夫
　　少于10秒
　　30秒+数据库复原
　　可变的
　　可变的
　　物理设置
　　冗余的存储地位
　　是
　　否（共享磁盘）
　　是
　　是
　　硬件需求
　　尺度服务器
　　聚集考证的服务器和存储
　　尺度服务器
　　尺度服务器
　　物理间隔限定
　　没有
　　100米
　　没有
　　没有
　　别的服务器脚色
　　见证服务器
　　没有
　　监督服务器
　　分发服务器
　　办理
　　庞大性品级
　　低
　　高
　　低
　　中等
　　备用服务器的可会见性
　　经由过程数据库快照，功能大概遭到影响
　　不成会见
　　R/O可是与数据库复原不兼容
　　同意只读事情
　　多备用服务器
　　无
　　无
　　是
　　是
　　备用服务器加载提早
　　没有
　　没有
　　有提早
　　没有
　　可用性局限
　　数据库
　　服务器实例
　　数据库
　　数据库
　　客户会见
　　客户重定向
　　由ADO。NET和SQLNativeClient供应撑持
　　不必要，利用假造IP
　　必要本人编写代码
　　必要本人编写代码
</p>　　上表总结了一切四种高可用手艺的特征。下一部分将举行更具体的对照。
　　数据库镜像和聚集
　　数据库镜像和妨碍转移聚集最次要的差别就是供应了分歧级其余冗余。数据库镜像供应的回护是数据库级其余，而聚集供应的回护是服务器实例级其余。另外一个次要不同就是在数据库镜像中，主服务器和镜像服务器是自力的SQLSERVER实例，两个实例有分歧的称号；而聚集中的SQLSERVER实例则利用不异的假造服务器称号和IP地点，并且不管哪一个节点掌管聚集实例，假造服务器称号和IP地点一直坚持稳定。
　　假如您必要在服务器一级的数据库回护（比方，您的使用程序必要同时会见一致服务器上的多个数据库），妨碍转移聚集将是更合适的选择。可是，假如每次只须为一个数据库供应可用性，那末数据库镜像具有更多上风。
　　数据库镜像不像聚集那样必要专门的硬件，也没有共享存储介质失利的潜伏伤害。数据库镜像能够在最短工夫内让备用数据库入手下手供应服务，其速率快于任何别的的高可用手艺。别的，数据库镜像可以与ADO。NET和SQLNativeAccessClient很好的共同在一同，从而完成客户真个妨碍转移。
　　不克不及在聚集中利用数据库镜像，可是能够思索利用数据库镜像作为一种手腕来创立聚集数据库实例的一个热备用份。如许做必要出格当心，由于聚集的妨碍转移工夫善于数据库镜像的超时价，高可用形式下的镜像会话将对聚集的妨碍转移做出反响，以为这是主服务器失利了，然后会将聚集节点设置为镜像形态。
　　数据库镜像和事件复制
　　数据库镜像和事件复制都创建在读取原始服务器事件日记的基本上，但今后接纳的手艺就一模一样了。（更多关于事件复制的细节，请参阅SQLSERVERBooksOnline中的相干主题）。事件复制多用于设置高可用性，由于它能够将刊行数据库中的用户事件在几秒钟内递送到定阅数据库中。数据库镜像的长处是速率关于乃至快于复制，但必要递送一切的数据库事件，而不但单是与用户表相干的事件。
　　事件复制手艺合适于将数据扩大到多个定阅者。事件复制的定阅数据库一般是只读的，假如必要近乎及时的数据会见，那末事件复制是幻想的候选者。
　　数据库镜像与事件复制兼容，假如必要保持刊行数据库的一个热备份，数据库镜像就长短常有效的一种体例。别的用于回护复制刊行商的体例，比方日记传送没法在刊行商本人的定阅者之前保持刊行商的备用服务器。换句话说，事件复制将事件日记递送给定阅者的速率要快于事件日记备份。恰是由于数据库镜像速率很快，因而出格合适用于保持刊行数据库的热备份。
　　可是假如刊行服务器失利，就必需手动利用复原好的备用数据库从头创建刊行商，然后从头毗连到分发服务器，，利用日记传输保护刊行商服务器的备用服务器所必需做的事情与此不异。
　　数据库镜像和日记传输
　　数据库镜像和日记传输都依附SQLSERVER数据库供应的恢复和复原功效。在数据库镜像中，镜像数据库一直坚持recovering形态，接二连三地复原来自立数据库的事件日记。而日记传输中的备用数据库则周期性地使用事件日记备份中的事件。由于bulk-logged数据被附加到事件日记备份中，因而日记传送能够事情在bulk-logged恢复模子下。数据库镜像则分歧，它间接将日记纪录从主数据库传送到镜像数据库中并且不克不及递送bulk-logged数据。
　　良多情形下数据库镜像能够供应与日记传送不异的数据冗余和更高的可用性和主动妨碍转移。可是，假如使用程序依附一台服务器上的多个数据库，那末日记传送是无效的体例（参阅前一部分先容的“Multi-DatabaseConsiderations”）。
　　别的，某些数据库镜像场景中还能够经由过程日记传送作为增补。比方：您能够某处设置一个高可用数据库镜像，然后将主数据库日记传送到远程站点以供应劫难恢复。4显现了怎样举行这类设置。

登录/注册后可看大图

　　4：将主数据库日记传送到远程服务器
　　这类体例的长处就是：一旦全部站点失利了，第二个站点上的数据还持续可用。可是，假如数据库镜像失利了，从ServerB到远程备用服务器的日记传送一般必需从头入手下手。
　　别的利用日记传送增补数据库镜像的场景就是作为主服务器的当地备用，主服务器的数据库镜像会话用于劫难恢复。此时，数据库镜像会话运转在高功能操纵形式下，远程站点的镜像服务器作为远程备用服务器。

登录/注册后可看大图

　　5：经由过程主数据库日记传送的体例来保存一切的事件
　　在高功能形式中存在的数据丧失，假如主服务器失利而且利用强迫恢复服务的体例恢复了镜像服务器。假如您正在对旧的主服务器举行日记传送，而且假如旧的主服务器事件日记文件没有破坏，那末能够对主数据库举行“开头日记”备份来取得事件日记中最初一组纪录。假如备用日记传输数据库已使用了一切别的的事件日记备份，您就能够将开头日记备份使用到备用服务器，如许不会丧失旧的主服务器上的任何数据。然后能够对日记传送备用服务器中的数据和远程数据库做个对照，在必要时将丧失的数据拷贝到远程服务器。
　　当您对照日记传输和数据库镜像功效时，必要明白的一点就是：对主数据库举行数据库和日记备份很主要。将这些日记备份使用到的日记传送服务器能够对数据库镜像设置起到增补感化。
　　结论
　　数据库镜像是SQLSERVER2005中的新手艺，能够完成高可用性和高功能的可数据库冗余办理计划。在数据库镜像中，当主数据库的事件日记缓冲区被写进磁盘时（软化的），事件日记纪录就从主数据库间接发送到镜像数据库。这类手艺可使镜像数据库几近和主数据库的数据坚持同步，同时不会丧失提交的数据。在导可用性操纵形式中，假如主服务器失利了，那末镜像服务器将主动成为新的主服务器并复原数据库。利用新的ADO．NET大概SQLNativeAccessClient驱动程序，使用程序还能够从本人的服务器长进行主动的妨碍转移。数据库镜像成为SQLSERVER2005供应的高可用手艺家属中的新成员。
你看出了作者的深度？深处半米！当初是冲那么多的大牛给他写序才买的，后来才发现无啥内容，作者也只是才用几年的新手，百花了几十两银子，再次感叹当今社会的虚伪与浮躁

多加的系统视图和实时系统信息这些东西对DBA挑优非常有帮助，但是感觉粒度还是不太细。

一个百万级别的基本信息表A，一个百万级别的详细记录表B，A中有个身份证id，B中也有身份id；先要找出A中在B的详细记录。

对递归类的树遍历很有帮助。个人感觉这个真是太棒了！阅读清晰，非常有时代感。

仓酷云

可能有的朋友会抱怨集成的orderby，其实如果使用ranking函数,Orderby是少不了的。如果担心Orderby会影响效率，可以为orderby的字段建立聚集索引，查询计划会忽略orderby操作（因为本来就是排序的嘛）。

原来的计算字段其实和虚拟字段很像。只是管理方面好了而已，性能方面提高不多。但是SQL2005提供了计算字段的持久化，这就提高了查询的性能，但是会加重insert和update的负担。OLTP慎用。OLAP可以大规模使用。

可以动态传入参数，省却了动态SQL的拼写。

从项目平台的选择上讲，我们关心的，应该是一款产品能不能满足任务需求，而不是网上怎么说。