1、服务器ip地址和数据库版本
主机：192.168.1.1
备机：192.168.1.110
数据库：sql server 2005 sp4

2、主备实例互通
1）创建证书

--主机执行
USE MASTER
GO
CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'xifenfei';
GO
USE MASTER
GO
CREATE CERTIFICATE HOST_A_cert 
       WITH SUBJECT = 'A certificate for database mirroring',
       START_DATE = '11/25/2009',
       EXPIRY_DATE = '12/31/2199';
GO

--备机执行
USE MASTER
GO
CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'xifenfei';
GO
USE MASTER
GO
CREATE CERTIFICATE HOST_B_cert 
       WITH SUBJECT = 'A certificate for database mirroring',
       START_DATE = '11/25/2009',
       EXPIRY_DATE = '12/31/2199';
GO

2）创建连接的端点

--主机执行
create endpoint endpoint_mirroring
state=started
as
tcp (listener_port=5022,listener_ip=all)
for
database_mirroring
(authentication=certificate HOST_A_cert,encryption=supported,role=all);

--备机执行
create endpoint endpoint_mirroring
state=started
as
tcp (listener_port=5022,listener_ip=all)
for
database_mirroring
(authentication=certificate HOST_B_cert,encryption=supported,role=all);

3）备份证书以备建立互联

--主机执行
backup certificate HOST_A_cert to file='E:\database\key\HOST_A_cert.cer';
--备机执行
backup certificate HOST_B_cert to file='C:\database\mssql\key\HOST_B_cert.cer';

4）互换备份证书
拷贝证书文件到对象文件夹中

5）添加登录名、用户

--主机执行
create login HOST_B_login with password='20091125';
create user HOST_B_user for login HOST_B_login;
create certificate HOST_B_cert authorization HOST_B_user from file='C:\database\mssql\key\HOST_B_cert.cer';
grant connect on endpoint::endpoint_mirroring to [HOST_B_login];

--备机执行
create login HOST_A_login with password='20091125';
create user HOST_A_user for login HOST_A_login;
create certificate HOST_A_cert authorization HOST_A_user from file='E:\database\key\HOST_A_cert.cer';
grant connect on endpoint::endpoint_mirroring to [HOST_A_login];

3、建立镜像关系
1）备份还原数据库

/*尝试从刚刚使用的全备文件进行还原，在还原数据的时候需要使用”WITH NO RECOVERY“选项。*/
--主机执行
backup database test to disk='D:\sqlbackup\test091124full.bak'
backup log test to disk='D:\sqlbackup\test091124log.bak'

--备机执行
restore database acmr_10jqka from disk='D:\sqlbackup\test091124full.bak' with replace,norecovery
restore log acmr_10jqka from disk='D:\dbbackup\118_sql\acmr_10jqka091125log.bak' with norecovery

2）建立镜像

/*注意：先备机，后主机*/
--备机执行
alter database acmr_10jqka set partner='TCP://192.168.1.1:5022';
--主机执行
alter database test set partner='TCP://192.168.1.110:5022';

3）事务安全性设置

/*默认情况下，事务安全级别的设置为FULL，即“同步运行模式”，而且，SQL SERVER 2005标准版只支持同步模式。*/
/*如果关闭事务安全级别FULL模式，则可以切换到异步运行模式，该模式可使性能达到最佳。*/
--主机执行
use master
go
alter database test set partner safety full;   --事务安全，同步模式
alter database test set partner safety off;    --事务不安全，异步模式

4）切换

--主机执行下面命令后，即切换为备机角色
use master
go
alter database test set partner failover;
/*同理，也可以在备机（主体数据库）上执行上面命令，之后切换为备机（备数据库）*/

一、查询现有数据库恢复模式
1、直接查看
1).展开“数据库”，然后根据数据库的不同，选择用户数据库，或展开“系统数据库”，再选择系统数据库。
2).右键单击该数据库，再单击“属性”，这将打开“数据库属性”对话框。
3).在“选择页”窗格中，单击“选项”。
4).当前恢复模式显示在“恢复模式”列表框中。
5).也可以从列表中选择不同的模式来更改恢复模式。可以选择“完整”、“大容量日志”或“简单”。

2、通过sql语句查看

--sql server 2000及其以前版本
SELECT name, (SELECT DATABASEPROPERTYEX(name, 'RECOVERY')) RecoveryModel FROM master.sys.databases ORDER BY name

--sql server 2005及其以后版本
SELECT name, recovery_model_desc FROM master.sys.databases ORDER BY name

二、三种恢复模式比较
1、简单恢复模式
特点：无日志备份。自动回收日志空间以减少空间需求，实际上不再需要管理事务日志空间。
工作丢失的风险 ：最新备份之后的更改不受保护。在发生灾难时，这些更改必须重做。
能否恢复到时点：只能恢复到备份的结尾
降低工作丢失风险：不影响备份管理的前提下时常备份，以免丢失大量数据。
适用范围(符合下列所有要求)：
1.不需要故障点恢复。如果数据库丢失或损坏，则会丢失自上一次备份到故障发生之间的所有更新，但您愿意接受这个损失。
2.您愿意承担丢失日志中某些数据的风险。
3.您不希望备份和还原事务日志，希望只依靠完整备份和差异备份。

2、完整恢复模式
特点：需要日志备份。数据文件丢失或损坏不会导致丢失工作。可以恢复到任意时点（例如应用程序或用户错误之前）。
工作丢失的风险:正常情况下没有。如果日志尾部损坏，则必须重做自最新日志备份之后所做的更改。
能否恢复到时点：果备份在接近特定的时点完成，则可以恢复到该时点。
时点恢复：出现故障后，可以尝试备份“日志尾部”（尚未备份的日志）。如果结尾日志备份成功，则可以通过将数据库还原到故障点来避免任何工作丢失。
缺点：使用日志备份的缺点是它们需要使用存储空间并会增加还原时间和复杂性。
一般的备份策略：
1.首先完整备份数据库以及日志备份.
2.在日志备份后的某个时间,数据库发生错误.接下来 先备份活动日志
3.然后还原完整数据库备份和日志备份,但是不恢复数据库；
4.还原并恢复结尾日志备份。这样就完成了恢复待故障点,恢复了所有数据.
降低工作丢失风险:建议经常执行日志备份，以将工作丢失的风险限定在业务要求所允许的范围内。
适用范围(符合下列任一要求)：
1.您必须能够恢复所有数据
2.数据库包含多个文件组，并且您希望逐段还原读/写辅助文件组（以及可选地还原只读文件组）。
3.您必须能够恢复到故障点
4.您希望可以还原单个页
5.您愿意承担事务日志备份的管理开销。

3、大容量日志会恢复
特点：需要日志备份。是完整恢复模式的附加模式，允许执行高性能的大容量复制操作。通过使用最小方式记录大多数大容量操作，减少日志空间使用量。
工作丢失的风险:如果在最新日志备份后发生日志损坏或执行大容量日志记录操作，则必须重做自该上次备份之后所做的更改,否则不丢失任何工作。
能否恢复到时点：可以恢复到任何备份的结尾。不支持时点恢复。
切换到该模式的必要性：对于某些大规模大容量操作（如大容量导入或索引创建）,暂时切换到大容量日志恢复模式可提高性能并减少日志空间使用量。仍需要日志备份。
何时使用大容量日志恢复模式：仅在运行大规模大容量操作期间以及在不需要数据库的时点恢复时使用该模式。

三、修改当前数据库恢复模式

--简单恢复模型:
USE master;
ALTER DATABASE dbname SET RECOVERY SIMPLE

--完整恢复模型:
USE master;
ALTER DATABASE dbname  SET RECOVERY FULL

--批量日志恢复模型:
USE master;
ALTER DATABASE dbname  SET RECOVERY BULK_LOGGED

CONVERT
将某种数据类型的表达式显式转换为另一种数据类型。由于某些需求经常用到取日期格式的不同.现以下可在SQL Server中　将日期格式化.

SQL Server 支持使用科威特算法的阿拉伯样式中的数据格式。

在表中，左侧的两列表示将 datetime 或 smalldatetime 转换为字符数据的 style 值。
给 style 值加 100，可获得包括世纪数位的四位年份 (yyyy)。

*     默认值（style 0 或 100、9 或 109、13 或 113、20 或 120、21 或 121）始终返回世纪数位 (yyyy)。
** 当转换为 datetime 时输入；当转换为字符数据时输出。
*** 专门用于 XML。对于从 datetime 或 smalldatetime 到 character 数据的转换，输出格式如表中所示。对于从 float、money 或 smallmoney 到 character 数据的转换，输出等同于 style 2。对于从 real 到 character 数据的转换，输出等同于 style 1。

重要 默认情况下，SQL Server 根据截止年份 2049 解释两位数字的年份。即，两位数字的年份 49 被解释为 2049，而两位数字的年份 50 被解释为 1950。许多客户端应用程序（例如那些基于 OLE 自动化对象的客户端应用程序）都使用 2030 作为截止年份。SQL Server 提供一个配置选项（”两位数字的截止年份”），借以更改 SQL Server 所使用的截止年份并对日期进行一致性处理。然而最安全的办法是指定四位数字年份。

当从 smalldatetime 转换为字符数据时，包含秒或毫秒的样式将在这些位置上显示零。当从 datetime 或 smalldatetime 值进行转换时，可以通过使用适当的 char 或 varchar 数据类型长度来截断不需要的日期部分。

下表显示了从 float 或 real 转换为字符数据时的 style 值。

在下表中，左列表示从 money 或 smallmoney 转换为字符数据时的 style 值。

使用 CONVERT：

CONVERT (data_type[(length)], expression [, style])
select CONVERT(varchar, getdate(), 120 )
2004-09-12 11:06:08

select replace(replace(replace(CONVERT(varchar, getdate(), 120 ),\’-\’,\’\’),\’ \’,\’\’),\’:\’,\’\’)
20040912110608

select CONVERT(varchar(12) , getdate(), 111 )
2004/09/12

select CONVERT(varchar(12) , getdate(), 112 )
20040912

select CONVERT(varchar(12) , getdate(), 102 )
2004.09.12

select CONVERT(varchar(12) , getdate(), 101 )
09/12/2004

select CONVERT(varchar(12) , getdate(), 103 )
12/09/2004

select CONVERT(varchar(12) , getdate(), 104 )
12.09.2004

select CONVERT(varchar(12) , getdate(), 105 )
12-09-2004

select CONVERT(varchar(12) , getdate(), 106 )
12 09 2004

select CONVERT(varchar(12) , getdate(), 107 )
09 12, 2004

select CONVERT(varchar(12) , getdate(), 108 )
11:06:08

select CONVERT(varchar(12) , getdate(), 109 )
09 12 2004 1

select CONVERT(varchar(12) , getdate(), 110 )
09-12-2004

select CONVERT(varchar(12) , getdate(), 113 )
12 09 2004 1

select CONVERT(varchar(12) , getdate(), 114 )
11:06:08.177

一、理论知识
1、复制数据库模型概念

1）发布服务器
发布服务器是一种数据库实例，它通过复制向其他位置提供数据。发布服务器可以有一个或多个发布，每个发布定义一组要复制的具有逻辑关系的对象和数据。
2）分发服务器
分发服务器也是一种数据库实例，它起着存储区的作用，用于复制与一个或多个发布服务器相关联的特定数据。每个发布服务器都与分发服务器中的单个数据库（称作分发数据库）相关联。分发数据库存储复制状态数据和有关发布的元数据，并且在某些情况下为从发布服务器向订阅服务器移动的数据起着排队的作用。在很多情况下，一个数据库服务器实例充当发布服务器和分发服务器两个角色。这称为“本地分发服务器”。当发布服务器和分发服务器按各自的数据库服务器实例配置时，把分发服务器称为“远程分发服务器”。
3）订阅服务器
订阅服务器是接收复制数据的数据库实例。订阅服务器可以接收来自多个发布服务器和发布的数据。根据所选的复制类型，订阅服务器还可以将数据更改传递回发布服务器或者将数据重新发布到其他订阅服务器。
4）项目
项目用于标识发布中包含的数据库对象。一次发布可以包含不同类型的项目，包括表、视图、存储过程和其他对象。当把表作为项目发布时，可以用筛选器限制发送到订阅服务器的数据的列和行。
5）发布
发布是一个数据库中的一个或多个项目的集合。将多个项目分组成一个发布，使得更便于指定一组作为一个单元复制的、具有逻辑关系的数据库对象和数据。
6）订阅
订阅是把发布副本传递到订阅服务器的请求。订阅定义将接收的发布和接收的时间、地点。有两种类型的订阅：推送订阅和请求订阅。

2、复制代理概述
1）快照代理
快照代理通常与各种类型的复制一起使用。快照代理准备已发布表的架构和初始数据文件以及其他对象、存储快照文件并记录分发数据库中的同步信息。快照代理在分发服务器上运行
2）日志读取器代理
日志读取器代理与事务性复制一起使用。它将发布服务器上的事务日志中标记为复制的事务移至分发数据库中。使用事务性复制发布的每个数据库都有自己的日志读取器代理，该代理运行于分发服务器上并与发布服务器连接（分发服务器与发布服务器可以是同一台计算机）。
3）分发代理
分发代理与快照复制和事务性复制一起使用。它将初始快照应用于订阅服务器，并将分发数据库中保存的事务移至订阅服务器。分发代理既可以运行于分发服务器（对于推送订阅），也可运行于订阅服务器（对于请求订阅）。
4）合并代理
合并代理与合并复制一起使用。它将初始快照应用于订阅服务器，并移动和协调所发生的增量数据更改。每个合并订阅都有自己的合并代理，该代理同时连接到发布服务器和订阅服务器并对它们进行更新。合并代理既可以运行于分发服务器（对于推送订阅），也可以运行于订阅服务器（对于请求订阅）。默认情况下，合并代理将订阅服务器上的更改上载到发布服务器，然后将发布服务器上的更改下载到订阅服务器。
5）队列读取器代理
队列读取器代理与包含排队更新选项的事务性复制一起使用。该代理运行于分发服务器，并将订阅服务器上所做更改移回至发布服务器。与分发代理和合并代理不同，只有一个队列读取器代理的实例为给定分发数据库的所有发布服务器和发布提供服务。
6）复制维护作业
复制包含许多执行计划维护和按需维护的维护作业

3、复制类型概述
1）事务复制概述
事务性复制通常从发布数据库对象和数据的快照开始。创建了初始快照后，接着在发布服务器上所做的数据更改和架构修改通常在修改发生时（几乎实时）便传递给订阅服务器。数据更改将按照其在发布服务器上发生的顺序和事务边界，应用于订阅服务器，因此，在发布内部可以保证事务的一致性。
事务性复制通常用于服务器到服务器环境中，在以下各种情况下适合采用事务性复制：
希望发生增量更改时将其传播到订阅服务器。
从发布服务器上发生更改，至更改到达订阅服务器，应用程序需要这两者之间的滞后时间较短。
应用程序需要访问中间数据状态。例如，如果某一行更改了五次，事务性复制将允许应用程序响应每次更改（例如，激发触发器），而不只是响应该行最终的数据更改。
发布服务器有大量的插入、更新和删除活动。
发布服务器或订阅服务器不是 SQL Server 数据库（例如，Oracle）。
默认情况下，事务性发布的订阅服务器应视为只读，因为更改将不会传播回发布服务器。但是，事务性复制确实提供了允许在订阅服务器上进行更新的选项。
2）合并复制概述
与事务性复制相同，合并复制通常也是从发布数据库对象和数据的快照开始，并且用触发器跟踪在发布服务器和订阅服务器上所做的后续数据更改和架构修改。订阅服务器在连接到网络时将与发布服务器进行同步，并交换自上次同步以来发布服务器和订阅服务器之间发生更改的所有行。
合并复制通常用于服务器到客户端的环境中。合并复制适用于下列各种情况：
多个订阅服务器可能会在不同时间更新同一数据，并将其更改传播到发布服务器和其他订阅服务器。
订阅服务器需要接收数据，脱机更改数据，并在以后与发布服务器和其他订阅服务器同步更改。
每个订阅服务器都需要不同的数据分区。
可能会发生冲突，并且在冲突发生时，您需要具有检测和解决冲突的能力。
应用程序需要最终的数据更改结果，而不是访问中间数据状态。例如，如果在订阅服务器与发布服务器进行同步之前，订阅服务器上的行更改了五次，则该行在发布服务器上仅更改一次来反映最终数据更改（也就是第五次更改的值）。
合并复制允许不同站点自主工作，并在以后将更新合并成一个统一的结果。由于更新是在多个节点上进行的，同一数据可能由发布服务器和多个订阅服务器进行了更新。因此，在合并更新时可能会产生冲突，合并复制提供了多种处理冲突的方法。
3）快照复制概述
快照复制将数据以特定时刻的瞬时状态分发，而不监视对数据的更新。发生同步时，将生成完整的快照并将其发送到订阅服务器。
快照复制可由其自身使用，但是快照处理（负责创建由发布所指定的所有对象和数据的副本）通常还用于为事务性发布与合并发布提供初始的数据和数据库对象集
当符合以下一个或多个条件时，使用快照复制本身是最合适的：
很少更改数据。
在一段时间内允许具有相对发布服务器已过时的数据副本。
复制少量数据。
在短期内出现大量更改。
在数据更改量很大，但很少发生时，快照复制是最合适的。例如，如果某销售组织维护一个产品价格列表且这些价格每年要在固定时间进行一两次完全更新，那么建议在数据更改后复制完整的数据快照。对于给定的某些类型的数据，更频繁的快照可能也比较适合。例如，如果一天中在发布服务器上更新相对小的表，但可以接受一定的滞后时间，则可以在夜间以快照形式传递更改。
发布服务器上快照复制的连续开销低于事务性复制的开销，因为不用跟踪增量更改。但是，如果要复制的数据集非常大，那么若要生成和应用快照，将需要使用大量资源。评估是否使用快照复制时，需要考虑整个数据集的大小以及数据的更改频率。

二、复制功能配置
1、建立一个 WINDOWS 用户，设置为管理员权限，并设置密码，作为发布快照文件的有效访问用户，赋予管理员权限。（发布和订阅服务器）
2、在SQL SERVER下实现发布服务器和订阅服务器的通信正常（即可以互访）。（发布和订阅互测）
3、新建文件夹并设置1中用户有权限访问（发布服务器，注其他网络设备也可以）
4、设置SQL代理(SQLSERVERAGENT)服务的登录为1设置的用户（发布和订阅服务器）
5、设置SQL server的协议，除了VIA协议之外的其他几项都启用，并且重启SQL serve（发布和订阅服务器）
6、设置SQL server的身份验证模式，即为sql server和windows都能访问模式（发布和订阅服务器）
7、相互注册对方的机器，操作：视图—-单击以注册服务器—-右键数据库引擎—-新建服务器注册—–填写要注册的远程服务器名称——身份验证选——SQL Server验证（发布和订阅服务器）
8、配置分发服务器：复制–右键新建分发服务器–选择快照文件夹3–根据提示之完成
9、配置发布服务器：右键本地发布——选择发布数据库——-选择发布类型——-选择订阅服务器类型——-选择要发布的对象——设置快照代理（使用SQL Server 代理帐户）——-填写发布名称
10、配置订阅服务器：右键本地订阅——–选择发布服务器（使用机器名）——-选择订阅方式（如果是在服务器方订阅的话选择推送订阅反之选择请求订阅）——-填加订阅服务器——–选择代理计划（一般选择连续运行）