1 引言

　　随着 SQL Server使用越来越多，SQL Server 数据库的安全越来越受到更多的关注。一般情况下，SQL Server 数据库的安全通过对数据库的定时备份可在一定程度上得到保证，但是，它却存在明显缺陷。定时时间太长，在最后一次成功备份与发生故障之间丢失的数据就可能越多；定时备份时间太短，备份所需的时间代价太大，特别是数据库的规模较大时更是如此。如采用增量备份，虽能减少备份时间，但对备份数据的维护和数据恢复增加了困难，而且增量备份只能是阶段性的。无论数据库备份时间长短，只要在最后一次成功备份后对数据库数据进行了增删改，这些数据均无法恢复。另外，从原数据库损坏到数据库恢复前，一切对数据库的操作都无从谈起。SQL Server 的复制功能也不能解决这个问题。这在有些应用情况下是不可接受的。

　　本文探讨对 SQL Server 2000 数据库实时备份，备份数据库时时刻刻与原数据库保持一致，就可以很好地解决这个问题。要实现数据库实时备份，必须保证对原数据库的每个操作同时操作备份数据库。解决这个问题，可以从客户端和服务器端来考虑。

2 客户端数据库实时备份

　　客户端应用程序操作服务器端数据库一般有两种方法：一种采用 SQL 命令，另一种采用控件绑定。它们都需要同时建立两个数据源。采用SQL 命令操作数据库，在操作原数据库同时操作备份数据库，而且这些操作命令需放在同一个事务中。如果采用异常控制，则如果操作原数据库不成功，则终止本次操作。如果操作原数据库成功，则再操作备份数据库，如果操作备份数据库不成功，则需要先恢复原数据库后，方可终止本次操作。采用控件绑定操作数据库情况比较复杂，但也可以分为两种情况：一次操作一条记录和一次操作多条记录。一次操作一条记录相对容易，因为对数据库操作一般多会在一个对象的事件中，这时可以在事件中用SQL 命令模仿绑定操作备份数据库。当然，绑定操作原数据库和用SQL 命令模仿绑定操作备份数据库需要满足事务特性。采用控件绑定操作数据库一次操作多条记录，如果可以检测当前记录移动，则可以在对原数据库一次操作多条记录变成多次操作备份数据库一条记录。如果不能检测当前记录移动，则可以在对原数据库一次操作多条记录后，再一次操作备份数据库多条记录。但关键要记录变动（插入、删除和修改）的主关键字。通过这些变动记录主关键字定位备份数据库记录，用原数据库中这些记录数据更新备份数据库相应记录。客户端应用程序实现数据库实时备份，所有备份操作都由应用程序完成，并且要保证原操作和备份操作要么同时成功，要么一个都不做。这种方法贯穿操作数据库每一处，导致应用程序不但复杂，操作数据库的效率降低50%以上，并且在有些情况下无法实现。通过服务器端可以很好地解决这个问题。

3 服务器端数据库实时备份

　　理想的服务器端备份操作是客户端应用程序操作数据库编程与备份操作无关，即备份操作对客户端应用程序透明。同时，操作原数据库后不要太多地等待操作备份数据库附加操作，从而提高操作效率。

3.1 备份操作透明化

　　为了实现备份操作对应用程序透明，首先要寻找客户端应用程序操作数据库感应器，感应当前对数据库的每一个操作。不管应用程序是用 SQL 命令操作数据库，还是通过控件绑定操作数据库，能够感应这些操作的只有触发器。但需要注意：不要用TRUNCATE TABLE 实现DELETE，因为它不会触发DELETE 触发器。同样，WRITETEXT 也不会触发INSERT或UPDATE 触发器。SQL Server2000 数据库表的触发器不能使用默认的AFTER 类型，而要使用SQL Server2000 新加入的INSTEADOF 触发类型，因为它取代了触发该触发器执行的代码。在INSTEADOF 类型触发器中，可以使用SQL Server2000数据库的特殊临时inserted 表和deleted 表作为中介，它实际上是事务日志的视图，与创建触发器的表具有相同结构。应用程序不管当前采用何种方式操作数据库表，对应inserted 表和deleted 表就会生成相应的记录。其中，插入影响inserted 表，删除影响deleted 表，修改影响inserted 和deleted 表。在INSTEADOF类型INSERT、DELETE 和UPDATE 触发器中，以deleted表中所有记录的主关键字为依据删除备份数据库的相应的记录，以inserted 表的所有记录为依据加入到备份数据库中。触发器中的所有操作是一个完整的事务，从而保证操作原数据库和操作备份数据库的一致性。

3.2 备份操作的并发性

　　上述备份操作方法实现了对应用程序透明化，但操作原数据库和操作备份数据库是顺序串行进行的，操作数据库的效率降低的问题并没有解决，一个命令先后操作 2 数据库带来的问题也没有明显变化。因为应用程序对原数据库进行操作时，系统先执行其对应表INSTEADOF 类型触发器，触发器在操作备份数据库成功后对原数据库操作也才能被确认。两个操作结束当前操作才会完成，当然比仅操作原数据库需要更多时间。另外，操作效率还与如何备份有关。如果备份数据库与原数据库同在一个主机的不同硬盘上，操作效率降低并不太多，如图1 所示。

　　而且不同硬盘同时破坏的可能性不大，所以这种备份也基本可行。但是，对于需要考虑服务器故障的情况或者在原数据库与备份数据库进行动态切换情况下就不能满足要求。但备份数据库与原数据库不在同一个主机上，这时除了原来就存在的客户端与原数据库所在网络性能对操作数据库影响外，还与原数据库所在的服务器与备份数据库所在的服务器之间网络性能有关。由于网络等原因使操作不成功的可能性没有明显降低，如图 2 所示。

　　为了使备份操作对原操作的影响尽可能少，可以建立一个分发数据库，分发数据库中包含的表与原数据库相同，但每个表还应有记录进行标志的位置，表中数据只保存尚未与备份数据库同步的原数据库已变动的记录。分发数据库与原数据库放在同一台服务器的不同硬盘上，原数据库表 INSTEADOF 类型触发器仅操作分发数据库，由于操作的分发数据库在同一台服务器上并且表记录少，所以操作所需的时间有限，这样操作原数据库的时间并没有太多增加。另外，分发数据库还要建立一个记录更新表，在加入分发数据库相应表记录的同时，需要在该更新表中记录原数据库已更新的表名。另外，在服务器端创建一个备份服务应用程序，该应用程序每隔一段时间就检测该更新表，如果更新表中有记录，就根据更新表中指定的表名，先将分发数据库该表包含的记录对应备份数据库表的记录删除，再检索分发数据库该表标志为插入的，将分发数据库这些记录加入到备份数据库表中。最后，删除分发数据库该表包含的所有记录，删除分发数据库更新表当前记录。每循环一次进行一个表的同步操作，直到分发数据库更新表中没有记录为止。由于客户端应用程序操作原数据库时，原数据库所在的服务器仅附带操纵本机分发数据库后返回，而其后真正的备份操作是在备份服务应用进程中完成的。客户端应用程序操作原数据库后的其它操作与备份服务应用进程的当前备份操作是同时进行的，如图3 所示。

3.3 备份操作的实时性和可靠性

　　采用分发数据库实现备份操作，备份是完备的，实时的。因为分发数据库是在操作原数据库时通过事务保证了它们与原数据库的操作一致性。原数据库中的变化会在分发数据库及时反映。但分发数据库与备份数据库同步是有时间间隔的，因为分发数据库中记录更新到备份数据库操作肯定在原操作后进行，时间间隔的大小一方面取决于备份服务应用程序设定的备份操作的定时时间，同时还与分发数据库服务器与备份数据库服务器之间的网络有关。如果在分发数据库与备份数据库同步时网络故障或备份数据库服务器暂时没有打开，分发数据库与备份数据库当前的同步操作就不能进行。但分发数据库与备份数据库同步的时间并不影响备份操作的实时性。因为，实际上操作原数据库时已经在分发数据库中进行了增量备份，而分发数据库与备份数据库同步仅仅是备份数据库原同步点的完全备份加上增量备份变成新同步点的完全备份。所以，即使分发数据库与备份数据库同步操作由于网络原因不能及时进行，分发数据库中的待更新记录就会增加，并没有影响对原数据库的操作，反而增加了方案实用性，这也是这种方案的出发点和可行的关键之一。即使在分发数据库与备份数据库新的一次同步前，原数据库被破坏，利用分发数据库和原备份数据库仍然能够同步到原数据库被破坏前的最新状态。在备份操作时，分发数据库出现故障，服务器编程时可以在对其操作时情况及时将报告用户，用户可以及时人工干预。在这以后，对原数据库的操作可以照常进行，仅仅备份操作暂时停止。故障恢复后，备份操作重新开启，但需要人工同步到新的同步点。备份数据库出现故障，如数据库破坏，也需要人工同步到新的同步点，清除分发数据库数据后备份操作再重新开启。

4 备份数据库动态切换

　　数据库备份是为了原数据库被破坏后进行恢复，因为这里数据库备份是实时的，而且备份数据库仅仅是存放的地点不一样，所以根本不需要恢复操作。当原数据库被破坏后，可以进行动态切换。客户端应用程序只需要改变数据库连接位置，这需要在开发该应用程序就考虑动态切换。从服务器端来说，主要是切换到备份数据库前，要保证分发数据库和备份数据库能够同步到最新位置。只要在切换前触发服务器端备份服务应用程序即可。不能进行动态切换的情况就是分发数据库和备份数据库不能同步到最新位置，可能的原因有：当前分发数据库服务器和备份数据库服务器之间网络故障从而无法同步；服务于原数据库的 SQL Server 2000 不能正常工作，尽管这种可能性很小；原数据库服务器故障。网络有故障暂时不能解决，可通过静态同步。原数据库服务器故障，并不一定硬盘故障。原数据库所在的硬盘故障，一般分发数据库所在硬盘不会同时故障。只要分发数据库数据存在，备份数据库静态同步到最新位置就没有问题。在一台服务器的不同硬盘上创建两个SQLServer 2000 实例，一个服务于原数据库，另一个服务于分发数据库，可以解决服务于原数据库的SQL Server 2000 不能正常工作影响同步的情况。

5 结论