sqlreplication

SQL Server复制

基础指南

SQL Server复制基础指南

微软SQL Server的复制功能是一项非常强大的技术，它可以实时地将数据从一个服务器移动到另一个，无论单向还是双向都可以。DBA在进行SQL Server扩展时，也需要频繁地用到复制技术。在本次的技术手册中，我们将对SQL Server的复制技术进行一个详尽的介绍，包括复制的工作原理、相关配置以及不同类型的复制等。

SQL Server复制技术原理

无论最终你是否希望成为一名DBA，理解SQL Server的复制技术还是非常重要的。本部分将对SQL Server的复制原理进行一个简单介绍，通过阅读本文，相信你可以做出更加明智的决策。

SQL Server复制：工作原理

SQL Server复制：何时说不

SQL Server 数据库复制教程（上）

SQL Server 数据库复制教程（中）

SQL Server 数据库复制教程（下）

合理利用SQL Server复制

在了解了SQL Server复制技术的基本原理之后，我们来看一下SQL Server复制在进行配置以及合理利用方面都有哪些注意事项，在本部分中，我们还讨论了利用Service Broker来代替SQL Server复制的方法。

如何设置SQL Server复制选项（上）

如何设置SQL Server复制选项（下）

利用Service Broker来代替复制

SQL Server升级后监控数据库镜像和复制

对比不同版本的复制选项

随着SQL Server不同版本的更新，SQL Server复制选项也有着不同程度的变化，尽管从SQL Server 2000升级到SQL Server 2005，数据复制功能的变化是根本性的，但从SQL Server 2005升级到2008的变化却是十分细微的。因此我们有必要了解一下不同版本复制功能的区别。

SQL Server 2008数据复制新特性及其带来的价值（上）

SQL Server 2008数据复制新特性及其带来的价值（下）

SQL Server 2005的复制存储过程选项

如何在升级到SQL Server 2005时复制数据库？

SQL Server复制：工作原理

无论最终你是否希望成为一名DBA，理解SQL Server复制还是非常重要的。本文将对SQL Server复制进行一个简单的介绍，通过阅读本文，相信你可以做出更加明智的决策。我曾经见过无数个复制项目进展得极为不顺利，因此为避免错误，最好的方法就是预先做

出正确的决策。

什么是SQL Server复制？

简单地说，复制就是SQL Server将你的数据拷贝同时从多个地方获取过来的方式。

复制的形式有所不同，以下是几种基本的复制形式：

快照复制。它就是一个简单的数据库拷贝。其实也并不简单，原始数据库需要被锁定，也就意味着快照生成过程中，这个数据库暂时不可用。这也确保了结果拷贝是独一无二的。

一个快照通常不会使用自身，也就是说它们可以作为其它形式复制的开始点。你为启

动另外一个拷贝而进行了快照，然后可以使用其他形式的复制来对拷贝进行即时更新。

事务性复制。这是一种单向的复制，也就是说数据从一个主发布端流向一个或多个订

阅端。在订阅端做出的任何修改都不会影响到发布端，因为数据流是单向的。行数据将不

会被复制，取而代之，发布端事务日志中的事务将发送到每个订阅端，不断地重复这些事务，可以将数据拷贝进行即时更新。

更新订阅端的事务性复制。这是事务性复制的另一种形式，它允许订阅段将事务发送

给发布端。数据之间也不会产生任何冲突，当订阅端数据库只更新数据子集的时候，这样

的方式最佳。

合并复制。这是一种更加复杂的复制，它允许每一个参与的数据库拷贝都能成为发布

端或订阅端，也就是说每一个数据库拷贝都是完全读写的。在应对数据冲突上，它需要特

别的决议模块,不同地点的数据也是同时进行着更改。

(作者：Don Jones 译者：孙瑞来源：TT中国)

原文标题：SQL Server复制：工作原理

链接：https://www.wendangku.net/doc/4516155974.html,/showcontent_29764.htm

SQL Server复制：何时说不

试想一下，当你的事务性复制发布端有五个更新中的订阅端。订阅端A对一些数据进行了更改，并将事务发送给发布端。发布端运行事务并将更改应用到数据库拷贝中，结果这样的更改还要发送给另外四个订阅端。与此同时，订阅端B、C、D、E也进行同样的动作，这会导致什么样的结果?

在一个繁忙的数据库应用中，上面所描述的动作会迅速生成大量的流量，即使网络

连接全部用来进行这一任务，你同样会给SQL Server主机增加几何倍数的负载。每个服

务器不仅需要跟上自己的变化，而且还要跟上其它服务器的变化。发布端还要负责合并所有的变更。

这么复杂的工作可行吗？当然，再某些情况下可以。但它并不是魔法，当超出网络与服务器负载能力时，它将停止工作。而修复复制更加痛苦，通常需要删除之前的复制，从第一步快照重新开始。

根据我的经验，复制对于分布在世界各地、处理着繁忙事务的数据库来说并不合适，它们都是由相对较慢的WAN来连接的。在大多数复制失败的情况下，我认为都是进行复制的人对其工作原理不甚了解。另外，如果你需要一个繁忙的数据库可以全球访问，云计算平台也是一个不错的选择，比如Windows Azure。

(作者：Don Jones 译者：孙瑞来源：TT中国)

原文标题：SQL Server复制：何时说不

链接：https://www.wendangku.net/doc/4516155974.html,/showcontent_29765.htm

SQL Server 数据库复制教程（上）

SQL Server 复制是一个包含在Microsoft SQL Server的软件包，它用于以实例间一种迁移一致状态进行服务器间的数据移动。

SQL Server复制可以：

1、是单向的或者双向的；

2、是调度或实时传输的；

3、是将数据传输到一个实例或者多个实例。

复制拓扑

复制拓扑由三台服务器组成——订阅端、发行端和分发端。订阅端是接受数据的服务器。发行端是保持有可供订阅端使用的原始数据集的服务器。分发端是包含大量设置的服务器。同时，它还保持有从发行端传输给订阅端的数据。

目前有三种不同的复制技术可以使用。它们是快照复制、合并复制和事务复制。

快照复制是一个单向性数据传输。当更新数据从发行端向订阅端传输时，所有数据都是一次发送的。

合并复制是一个双向复制，它可以实时或通过调度来传输数据。合并复制是唯一可用的双向复制。

事务复制是从发行端向订阅端单向的。数据可以调度或实时发送。当数据向订阅端传输时，所有数据变化都以发行端设计的顺序进行处理。

当配置复制时，我们可以选择复制的对象。每个复制的数据对象都称为物件。物件可以是表格、视图、存储过程、函数、规则、数据类型等等。在选择数据库对象时，虽然并没有明确要求，但建议选择所有依赖的对象。同时，虽然也不要求选择子表，但必须确保可以复制表所使用的任意用户自定义数据类型以及规则。虽然数据类型可以手动传输到订阅端，但是它们必须存在于删除服务器，否则表格建立将无法实现。

当配置物件时，我们可以在物件配置过滤器。这些过滤器都是有效的WHERE子句，它

们告诉SQL Server复制只传输表中的数据子集。我们可以任意使用表中的字段作为垂直

过滤器的一部分。我们也可以使用水平过滤器。水平过滤器是一种打比方的说法，其实指

的是：WHERE子句应用于正在进行数据复制的物件，并且其中只有与WHERE子句相匹配的

数据才会被传输到订阅端。

(作者：Denny Cherry 译者：曾少宁来源：TT中国)

原文标题：SQL Server 数据库复制教程（上）

链接：https://www.wendangku.net/doc/4516155974.html,/showcontent_24521.htm

SQL Server 数据库复制教程（中）

如何拓扑

在此，我们最主要的是要确定选择使用哪种复制拓扑。选择错误的拓扑将带来非常令

人不满意的结果。

当需要一个临时的数据下发时，我们可以使用快照复制。因为每次快照下发时，所有

的数据都是一次性移动的，但是它需要花费大量的带宽。只有在需要复制的数据变化远远

超过了初始数据集的规模才在缓慢的WAN上使用快照复制。换言之，如果大部分的数据都

在不断地更新，那么选择使用快照技术是非常正确的。如果并非如此，那么就不能选择它。

当需要在发行端和订阅端之间进行传输时，就应该选择合并复制。当有多个订阅端时，数据变化会及时地在网络上从发行端复制到所有的订阅端。

事务技术可能是复制最常见的形式。它是用来在几乎实时地（或按照调度）将数据变

化传输到一个或多个订阅端。事务复制最常用于服务器之间的实时传输。

不管我们使用哪种SQL Server复制拓扑，订阅端之间都是完全独立的。订阅端可以

因为多种原因而落后，包括网络拥挤、磁盘I/O拥挤以及用户进程锁定和阻塞。由于订阅

端彼此都是独立的，因此，一个订阅端的速度下降并不影响其他的订阅端。

复制代理

数据是由复制代理传输的，其中每个发布都有几个复制代理需要创建。快照代理可以

用在三种复制拓扑上。当复制创建后，就会得到物件快照并被上传到每个订阅端。当使用

合并复制或事务复制时，将会有一个日志读取器代理在分发端上运行并捕捉事务日志的变化。然后这些变化会被记录到发行数据库上。

当使用事务复制时，数据变化将从发行数据库上读取并通过发行代理应用到订阅端上。当使用合并复制时，数据变化通过合并代理从发行数据库上读取。合并代理又将从订阅端

上获取数据变化并上传到发行端以便分配到其他订阅端上。

当创建订阅时，我们有两个选项用于创建每个订阅端。我们可以使用发送订阅或请求

订阅。当分配代理运行在发行数据库的服务器上工作时就是发送订阅。而当请求代理运行

在订阅数据库的服务器上时就是请求订阅。

发送订阅的优点是分配代理集中在分发端上。这就能够限制管理开销同时保持订阅端

的分配（或合并）代理低负载。请求订阅的优点是分配代理的工作量分散到所有订阅端上。当分配数据库位于同一台服务器或实例上作为发行端时，建议使用请求订阅。

(作者：Denny Cherry 译者：曾少宁来源：TT中国)

原文标题：SQL Server 数据库复制教程（中）

链接：https://www.wendangku.net/doc/4516155974.html,/showcontent_24522.htm

SQL Server 数据库复制教程（下）

复制获取

当建立分发端时，系统会提示选择一个文件夹来存储快照。当使用的都是发送订阅时，这可能是一个本地驱动器路径。当使用请求订阅或同时使用发送和请求订阅时，则必须指

定一个网络共享路径。此网络共享不可以是一个管理共享，并且每个运行SQL Server代

理的订阅端的域名帐号必须能读写网络共享。

如果运行的都是发送订阅而且有超过30个左右的订阅，那么在尝试启动订阅时将出

现超时错误。最快速的补救方法就是编辑分发或合并代理的任务。编辑第二步并将任务类

型修改为操作系统命令。接着将完整路径和可执行复制命令名称设置在现有参数的前面。SQL Server2008的默认路径是C:\Program Files\Microsoft SQL Server\100\COM（在SQL 2000中用80取代100，而在SQL 2005则是90取代）。当运行分发代理时，可以使

用distrib.exe，而当运行合并代理时，则使用replmerg.exe。

修复SQL Server复制故障可能会非常棘手。默认情况下，代理并不提供大量错误数据。我们可以通过修改任务属性中的-OutputVerboseLevel开关来调整所接收到的错误数

据总数。通过增加默认的数目，更多的错误数据将记录到任务步骤中。我们也可以终止运

行代理的SQL代理任务，然后在DOS命令提示符中运行命令来轻松地看到更多错误数据。

当SQL Server复制有大量数据需要传输时，为了保持更新，需要一定数量的网络带宽。如果带宽无法满足，那么复制将越来越缓慢。如果在一个低带宽、低延迟的网络中，

那么通过添加SubscriptionStreams开关（或者在已经存在开关的情况下，增加开关数目）将有助于增加线路数目。如果在一个高延迟网络，那么由于事务整合性是在流之间维护的，因此增加这些设置可能不会提高性能。

(作者：Denny Cherry 译者：曾少宁来源：TT中国)

原文标题：SQL Server 数据库复制教程（下）

链接：https://www.wendangku.net/doc/4516155974.html,/showcontent_24523.htm

如何设置SQL Server复制选项（上）

微软SQL Server的复制功能是一项非常强大的技术，它可以实时地将数据从一个服

务器移动到另一个，无论单向还是双向都可以。

为确保SQL Server复制功能运行的高效性，你在配置工具时需要做出几个重要决策。

推还是拉？

这个策略决定了在哪里运行Distribution Agent（或者Merge Agent）。

默认情况下，SQL Server的工作是由SQL Agent服务配置并运行的。这称作push设置，因为SQL Agent会将设置变化从Distributor那里推送给Subscriber。如果Agent在Subscriber上面运行，它就称作pull方式订阅，因为数据将从Distributor那里拉过来。

当选择Distribution Agent或Merge Agent的存放位置时，你需要考虑以下几个方面。

如果你有多个Subscriber和唯一一个Distributor，那你就应该使用push订阅。这

将会减轻CPU和内存运行Distribution Agent或Merge Agent时的负载压力，把节省出

来资源用在处理配置变更和用户请求上。

另外，如果你的Publisher和Distributor存放在物理服务器的同一位置，那么你就

会在Subscriber上运行Distribution Agent或Merge Agent。这将减轻Publisher的负

载压力，实际上，Publisher是SQL Server复制技术的关键服务器。

虽然所有服务器运行在同一个高速局域网情况下，以上的建议还是有效的，但是在广

域网情况下进行复制数据，你可能还需要做一些改变。特别是在你有一个比较大的快照需

要发送给Subscriber时。

SQL Server复制功能允许你控制每次运行的线程数目，这样你就可以一次申请多个事务到你的Subscriber中。然而在使用SQL Server 2005及以下版本时，你会遭遇一个内

置的性能瓶颈并会严重阻碍你的工作。

在2005和以前的版本中，Distribution Agent同分布式数据库只有一个连接。因此，无论你在推送数据到Subscriber时运行多少个线程，数据传输也只能跟运行一个线程的

速度一样。而SQL Server 2008则避免了此种情况的发生。

因此，如果在广域网，特别是低速广域网或者有高延迟的广域网中运行SQL Server

复制功能时，Distribution Agent从分布式数据库下载数据的速度将极为有限。

注意：当使用网络时，速度和延迟完全是两回事。

相反地，Distribution Agent应该运行在Distributor上。这将允许单线程从Distributor那里将数据拉过来，同时多线程在Subscriber上交付那些事务。

(作者：Denny Cherry 译者：孙瑞来源：TT中国)

原文标题：如何设置SQL Server复制选项（上）

链接：https://www.wendangku.net/doc/4516155974.html,/showcontent_22850.htm

如何设置SQL Server复制选项（下）

快照

当在广域网中使用快照时，你可以遵循几个技巧来极大程度地缩减处理时间。

一般来说，你可能想要推翻技术。如果你要在广域网中使用快照功能，你会遭遇速度

骤降。而且，在高延迟广域网和高负载环境中，你处理快照的时间可能比数据更改还要慢。

解决这一问题的最佳方法是设置推送订阅。当运行快照时，这个方法可以提供最快的

数据处理速度。

当配置发布选项时，选择一个本地路径存储快照。然后启动Distribution Agent来

创建快照。

当快照被创建，Distribution Agent开始处理它后，停止Distribution Agent。当SQL Server Agent任务停止时，浏览快照存储的文件夹。默认情况下是C:\Program

Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\repldata\unc，配置不同存

放的位置可能也会有所不同。

选择一种你习惯的压缩技术对文件和文件夹进行压缩。将压缩文件拷贝到Subscriber 并在和Distributor一样的路径下解压缩数据。然后修改SQL Server Agent任务并拷贝

所有参数带SQL Server Agent任务中。

在Subscriber上，打开命令提示符找到COM文件夹，输入distrib.exe。C:\Program Files\Microsoft SQL Server\100\COM是SQL Server 2008的默认存放位置。相应地，在2005版本和2000版本中，你把路径中的100改为80或90就可以。

将从SQL Server Agent中拷贝的switch粘贴到命令框内并按回车。Distribution Agent将临时运行在Subscriber上，它将处理拷贝到Subscriber上的快照。

处理完快照之后，agent将正常处理Distributor中的数据，你可以关闭窗口并在Distributor上启动Distribution Agent。

注意你不可以在两台服务器上同时运行Distribution Agent。在一个启动时，运行另一个就会报错并关闭。

SQL Server复制功能可以成为一个非常强大的工具，但是在没有认真计划并充分准备的前提下，你很可能就无法完成相应的工作。

(作者：Denny Cherry 译者：孙瑞来源：TT中国)

原文标题：如何设置SQL Server复制选项（下）

链接：https://www.wendangku.net/doc/4516155974.html,/showcontent_22852.htm

利用Service Broker来代替复制

为什么使用服务代理

在开始探讨代码之前，我要讲一下为什么我选择使用SQL 服务代理替代SQL复制的一点幕后原因。这样可能对阐述有好处。

(选择使用SQL服务代理代替SQL复制的)主要原因是我们想在数据从生产环境OLTP

数据库迁移到报表数据库时，能对数据做ETL(数据提取转换加载)。我们还需要很容易地

就能从一个报表数据库扩展为多个数据库的能力，以满足报表服务器在不同地点的情况。

表

下面你会发现一些SQL代码，我们将用这些代码创建一些示例表。在我们的OLTP数

据库中，我们创建了两个表，它们是表“LoanApplication”和表“Customer”，而在我

们的报表数据库中我们只有一个表“LoanApplication”。当数据插入或者更新到表“LoanApplication ”和表“Customer”时，数据会打包成XML文档并发送到报表数据库。在我这里的示例代码中，所有东西都在一台服务器上，但是数据库要挪到分离的服务器上

也是非常容易的。

SQL:

1.IF EXISTS(SELECT * FROM sys.DATABASES WHERE name =

‘Sample_OLTP’)

2.DROP DATABASE Sample_OLTP

3.GO

4.IF EXISTS(SELECT * FROM sys.DATABASES WHERE name =

‘Sample_Reporting’)

5.DROP DATABASE Sample_Reporting

6.GO

7.

8.CREATE DATABASE Sample_OLTP

9.CREATE DATABASE Sample_Reporting

10.GO

11.

12.ALTER DATABASE Sample_OLTP SET NEW_BROKER

13.ALTER DATABASE Sample_Reporting SET NEW_BROKER

14.GO

15.ALTER DATABASE Sample_OLTP SET TRUSTWORTHY ON

16.ALTER DATABASE Sample_Reporting SET TRUSTWORTHY ON

17.GO

18.

https://www.wendangku.net/doc/4516155974.html,E Sample_OLTP

20.GO

21.CREATE TABLE LoanApplication

22.(ApplicationId INT IDENTITY(1,1),

23.CreateTimestamp DATETIME,

24.LoanAmount MONEY,

25.SubmittedOn DATETIME,

26.ApprovedOn DATETIME,

27.LoanStatusId INT,

28.PrimaryCustomerId INT,

29.CoSignerCustomerId INT)

30.GO

31.CREATE TABLE Customer

32.(CustomerId INT IDENTITY(1,1).

33.FirstName VARCHAR(50),

https://www.wendangku.net/doc/4516155974.html,stName VARCHAR(50),

35.EmailAddress VARCHAR(255))

36.GO

https://www.wendangku.net/doc/4516155974.html,E Sample_Reporting

38.GO

39.CREATE TABLE LoanReporting

40.(ApplicationId INT,

41.CreateTimestamp DATETIME,

42.LoanAmount MONEY,

43.SubmittedOn DATETIME,

44.ApprovedOn DATETIME,

45.LoanStatusId INT,

46.PrimaryCustomerId INT,

47.PrimaryFirstName VARCHAR(50),

48.PrimaryLastName VARCHAR(50),

49.PrimaryEmailAddress VARCHAR(255),

50.CoSignerCustomerId INT,

51.CoSignerFirstName VARCHAR(50),

52.CoSignerLastName VARCHAR(50),

53.CoSignerEmailAddress VARCHAR(255))

54.GO

服务代理对象

在这个系统中，我只利用一对服务代理队列来处理所有数据传输。这样可以在数据流入时维持相互一致性。这些SQL服务代理对象应该被在示例OLTP数据库和示例报表数据库中创建。

SQL:

1.CREATE MESSAGE TYPE ReplData_MT

2.GO

3.CREATE CONTRACT ReplData_Ct

4.(ReplData_MT SENT BY ANY)

5.GO

6.CREATE QUEUE ReplData_Source_Queue

7.GO

8.CREATE QUEUE ReplData_Destination_Queue

9.GO

10.CREATE SERVICE ReplData_Source_Service

11.ON QUEUE ReplData_Source_Queue

12.(ReplData_Ct)

13.GO

14.CREATE SERVICE ReplData_Destination_Service

15.ON QUEUE ReplData_Destination_Queue

16.(ReplData_Ct)

17.GO

路由(route)

在该OLTP数据库中，你创建了这样一个route(根据你的实际服务器修改

BROKER_INSTANCE)。

SQL:

1.CREATE ROUTE ReplData_Route

2.WITH SERVICE_NAME=‘ReplData_Destination_Service’,

3.BROKER_INSTANCE=‘566C7F7A-9373-460A-8BCC-5C1FD4BF49C9′,

4.ADDRESS=‘LOCAL’

在该报表数据库中，你创建了这样一个route(根据你的实际服务器修改

BROKER_INSTANCE)。

SQL:

1.CREATE ROUTE ReplData_Route

2.WITH SERVICE_NAME=‘ReplData_Source_Service’,

3.BROKER_INSTANCE=‘A4EC5E44-60AF-4CD3-AAAD-C3D467AC682E’,

4.ADDRESS=‘LOCAL’

OLTP数据库中的存储过程

在该OLTP数据库中我们只需要一个存储过程。这个存储过程将处理信息的发送，这样我们就不必在每个表中写相同的代码。

SQL:

1.CREATE PROCEDURE SendTriggerData

2.@XMLData XML

3.AS

4.BEGIN

5.DECLARE @handle UNIQUEIDENTIFIER

6.

7.BEGIN DIALOG CONVERSATION @handle

8.FROM SERVICE ReplData_Source_Service

9.TO SERVICE ‘ReplData_Destination_Queue’

10.ON CONTRACT ReplData_Ct

11.WITH ENCRYPTION=OFF;

12.

13.SEND ON CONVERSATION @handle

14.MESSAGE TYPE ReplData_MT

15.(@XMLData)

16.END

17.GO

OLTP数据库触发器

该OLTP数据库中每个表上的触发器被保持尽可能小，以便我们给该OLTP服务器增加尽可能少的负载负担。很明显我们会给该OLTP数据库带来额外负载，但是我们希望把它保持在最小。

SQL:

1.CREATE TRIGGER t_LoanApplication ON LoanApplication

2.FOR INSERT, UPDATE

3.AS

4.BEGIN

5.DECLARE @xml XML

6.

7.SET @xml = (SELECT *

8.FROM inserted AS LoanApplication

9.FOR XML AUTO, ROOT(‘root’))

10.

11.EXEC SendTriggerData @xml

12.END

13.GO

14.

15.CREATE TRIGGER t_Customer ON Customer

16.FOR INSERT, UPDATE

17.AS

18.BEGIN

19.DECLARE @xml XML

20.

21.SET @xml = (SELECT *

22.FROM inserted AS Customer

23.FOR XML AUTO, ROOT(‘root’))

24.

25.EXEC SendTriggerData @xml

26.END

27.GO

报表数据库中的存储过程

该报表数据库是实际工作执行的地方。在这里我们获取XML文档，识别数据从哪个表来，然后把XML文档传递给子存储过程，然后处理数据并更新表。

SQL:

1.CREATE PROCEDURE ProcessOLTPData_LoanApplication

2.@xml XML

3.AS

4.DECLARE @hDoc INT

5.EXEC sp_xml_preparedocument @hDoc OUTPUT, @xml

6.

7.UPDATE LoanReporting

8.SET ApplicationId=a.ApplicationId,

9.CreateTimestamp = a.CreateTimestamp,

10.LoanAmount=a.LoanAmount,

11.SubmittedOn=a.SubmittedOn,

12.ApprovedOn=a.ApprovedOn,

13.LoanStatusId=a.LoanStatusId

14.FROM OPENXML (@hDoc, ‘/root/LoanApplication’)

15.WITH(ApplicationId INT ‘@ApplicationId’,

16.CreateTimestamp DATETIME ‘@CreateTimestamp’,

17.LoanAmount MONEY ‘@LoanAmount’,

18.SubmittedOn DATETIME ‘@SubmittedOn’,

19.ApprovedOn DATETIME ‘@ApprovedOn’,

20.LoanStatusId INT ‘@LoanStatusId’,

21.PrimaryCustomerId INT ‘@PrimaryCustomerId’,

22.CoSignerCustomerId INT ‘@CoSignerCustomerId’) a

23.WHERE a.ApplicationId = LoanReporting.ApplicationId

24.

25.INSERT INTO LoanReporting

26.(ApplicationId, CreateTimestamp, LoanAmount, SubmittedOn,

ApprovedOn, LoanStatusId, PrimaryCustomerId, CoSignerCustomerId) 27.SELECT ApplicationId, CreateTimestamp, LoanAmount,

SubmittedOn, ApprovedOn, LoanStatusId, PrimaryCustomerId,

CoSignerCustomerId

28.FROM OPENXML (@hDoc, ‘/root/LoanApplication’)

29.WITH(ApplicationId INT ‘@ApplicationId’,

30.CreateTimestamp DATETIME ‘@CreateTimestamp’,

31.LoanAmount MONEY ‘@LoanAmount’,

32.SubmittedOn DATETIME ‘@SubmittedOn’,

33.ApprovedOn DATETIME ‘@ApprovedOn’,

34.LoanStatusId INT ‘@LoanStatusId’,

35.PrimaryCustomerId INT ‘@PrimaryCustomerId’,

36.CoSignerCustomerId INT ‘@CoSignerCustomerId’) a

37.WHERE NOT EXISTS(SELECT * FROM LoanReporting WHERE

a.ApplicationId = LoanReporting.ApplicationId)

38.

39.EXEC sp_xml_removedocument @hDoc