MS SQL 事物日志传送能否跨数据库版本吗?

简介:

    SQL SERVER的事物日志传送(log shipping)功能,相信很多人都使用过或正在应用,这是MS SQL提供的一个非常强大的功能,一般需要一个主数据库服务器(primary/production database server)和辅助数据库服务器(standby server)来完成这个配置,默认情况下,主数据库和辅助数据库的版本应该是一致的,那么如果这两个数据库版本不一致,会不会有什么问题?还能做log shipping配置吗?

那么数据库版本不一致分两种情况:

    1: 类似于MS SQL 2005 64 bit SP4 与MS SQL 2005 SP3 32 bit这样的版本差别

    2: 完全不同的版本,例如MS SQL SERVER 2005 和 MS SQL SERVER 2008.

可能有人就要吐槽了,为啥要搞成不同的版本呢,这不是自己没事找事做吗?出现这种情况,真是一言难尽,历史的问题.....等等,你叫我怎么吐槽呢?好了,咱们就不纠结这些鸡毛蒜皮的事情了,现在回到上面的问题上来。

 

至于第一种情况,完全可以做log shipping,不存在什么问题,我做了两个这样的案例,都配置成功,而且工作的好好的。

 

案例1的环境:

数据库服务器

版本信息

主数据库服务器

Microsoft SQL Server 2005 - 9.00.5000.00 (Intel X86)   Dec 10 2010 10:56:29   Copyright (c) 1988-2005 Microsoft Corporation  Standard Edition on Windows NT 5.2 (Build 3790: Service Pack 2)

辅助数据库服务器

Microsoft SQL Server 2005 - 9.00.5000.00 (X64)   Dec 10 2010 10:38:40   Copyright (c) 1988-2005 Microsoft Corporation  Standard Edition (64-bit) on Windows NT 5.2 (Build 3790: Service Pack 2)

案例2的环境:

数据库服务器

版本信息

主数据库服务器

Microsoft SQL Server 2005 - 9.00.4000.00 (Intel X86)   Dec 10 2010 10:56:29   Copyright (c) 1988-2005 Microsoft Corporation  Standard Edition on Windows NT 5.2 (Build 3790: Service Pack 2)

辅助数据库服务器

Microsoft SQL Server 2005 - 9.00.5000.00 (X64)   Dec 10 2010 10:38:40   Copyright (c) 1988-2005 Microsoft Corporation  Standard Edition (64-bit) on Windows NT 5.2 (Build 3790: Service Pack 2)

第二种版本不同的情况,也要细分多种不同情况:

 

1: 主数据库服务器为SQL SERVER 2008, 辅助数据库服务器为SQL SERVER 2005, 对于这种情况,这是完全行不通的, 因为你在SQL SERVER 2008上的备份,不能在低版本SQL SERVER 2005上还原(当然更低的版本也是如此),以此类推,Primary Server is SQL 2012 Std and Secondary Server is SQL 2008 R2 Std 这种情况也是行不通的。

 

2:主数据库服务器为SQL SERVER 2005, 辅助数据库服务器为SQL SERVER 2008R2,对于这种情况,log shipping部署时,你选择Standby Mode时,就会报错:

clip_image002

相关出错信息:System.Data.SqlClient.SqlError: This backup cannot be restored using WITH STANDBY because a database upgrade is needed. Reissue the RESTORE without WITH STANDBY. (Microsoft.SqlServer.Smo)

所以你只能选择No Recovery mode选项,至于这个就有点鸡肋了。关于上面出错的原因,下面这段解释非常清晰,明了(出处请见下面参考资料):

Each version of SQL Server has a database version number; for SQL 2000 it is 8, SQL 2005: 9 and SQL 2008: 10. When a database backup that came from a lower SQL Server version is restored, SQL Server will run an upgrade process to bring that older database version up to the database version supported by the new instance. This process is run automatically as part of SQL Server’s recovery process.  The recovery process itself is certain operations that need to happen to ensure the database is in a consistent state for user access (roll-forwards and roll-backs etc).

Placing a database in “Standby/Read Only” mode instructs SQL Server to recover the database after each restore, but also create a special standby file that contains information which will allow this recovery to be undone when it is time to do additional transaction logs restores. 

However unfortunately, once a database has been upgraded it cannot be undone.  This is why if you try and use the “Standby/Read Only” option when restoring a database of an older version SQL Server fails with

Msg 3180, Level 16, State 1, Line 1
This backup cannot be restored using WITH STANDBY because a database upgrade is needed. Reissue the RESTORE without WITH STANDBY.
Msg 3013, Level 16, State 1, Line 1
RESTORE DATABASE is terminating abnormally.

This error message essentially says you cannot bring an older database version online in “Standby/Read Only” mode.
But you can restore transaction logs and log shipping from an older database version to a newer database version when you keep the database offline.  This is because the recovery (and upgrade process) for the database is deferred until the point you do actually bring the database online.  This means you can log ship from an older version of SQL Server to a newer version until the point you bring that database online for user access.

翻译如下(水平有限,仅供参考):

每一个版本的SQL Server数据库都有相应版本号;例如SQL 2000是8,SQL 2005是9,SQL2008:10。当数据库恢复一个从较低的SQL Server版本的备份时,SQL Server将执行一个升级过程,把那个旧的数据库版本升级到新实例支持的版本。这个过程是SQL Server的恢复过程中自动运行的一部分。恢复过程本身就需要某些操作发生,以确保数据库处于一致的状态向前回滚,向后回滚等)。

把数据库置于“待机/只读”模式不仅会指示SQL Server的每次还原后恢复操作,还会创建一个特殊的备用文件,当它做其他事务日志恢复时,包含的恢复撤销时的信息。

然而不幸的是,一旦数据库已经升级,它不能被撤消。这就是为什么如果你尝试使用“待机/只读”选项时,旧版本的SQL Server数据库恢复失败的原因

Msg 3180, Level 16, State 1, Line 1

This backup cannot be restored using WITH STANDBY because a database upgrade is needed. Reissue the RESTORE without WITH STANDBY.
Msg 3013, Level 16, State 1, Line 1
RESTORE DATABASE is terminating abnormally.

这个错误消息本质上是说,你不能把一个旧的数据库版本设置为联机在“待机/只读”模式下。
但 是你可以从一个旧的数据库版本还原事务日志和日志传送到一个新的数据库版本,当你保持数据库脱机。这是因为,为数据库的恢复(升级过程中)被推迟,直到点 你确实使数据库联机。这意味着您可以登录到一个新的版本,直到从旧版本的SQL Server用户访问您带来的联机数据库。

 

相关实践学习
日志服务之使用Nginx模式采集日志
本文介绍如何通过日志服务控制台创建Nginx模式的Logtail配置快速采集Nginx日志并进行多维度分析。
相关文章
|
3天前
|
SQL 关系型数据库 MySQL
【MySQL 数据库】7、SQL 优化
【MySQL 数据库】7、SQL 优化
23 0
|
5天前
|
SQL 关系型数据库 MySQL
数据库管理新星:Navicat、HeidiSQL和SQL Workbench的竞争格局
随着数据管理需求的不断增长,数据库管理工具的选择变得至关重要。在众多选择中,Navicat、HeidiSQL和SQL Workbench作为备受关注的数据库管理工具,各自展现出独特的特性和功能,竞争格局日益激烈。
17 0
|
15天前
|
SQL 存储 关系型数据库
sql数据库的相关概念与底层介绍
sql数据库的相关概念与底层介绍
32 0
|
4天前
|
SQL Oracle Java
怎样写出可在各种数据库间移植的SQL
国际标准没有对这些函数做规定,这种 SQL 语句就会和数据库相关而无法移植了,而这些函数在应用开发中还特别常见。 Hibernate 能将包括这些函数的标准 HQL 语句转换成不同数据库的 SQL,但 HQL 支持的函数太少,碰到不认识的函数还是要分别注册,这就丧失了可移植性;而且 HQL 能生成的 SQL 本身也比较简单,覆盖面太窄了。
|
5天前
|
SQL 数据采集 JSON
弱结构化日志 Flink SQL 怎么写?SLS SPL 来帮忙
弱结构化日志 Flink SQL 怎么写?SLS SPL 来帮忙
123331 2
|
25天前
|
关系型数据库 MySQL 数据库
MySQL员工打卡日志表——数据库练习
MySQL员工打卡日志表——数据库练习
84 0
|
28天前
|
监控 安全 数据库
Binlog vs. Redo Log:数据库日志的较劲【高级】
Binlog vs. Redo Log:数据库日志的较劲【高级】
71 0
|
28天前
|
存储 缓存 关系型数据库
Binlog vs. Redo Log:数据库日志的较劲【基础】
Binlog vs. Redo Log:数据库日志的较劲【基础】
53 0
|
28天前
|
SQL 监控 关系型数据库
数据库日志解析:深入了解MySQL中的各类日志
数据库日志解析:深入了解MySQL中的各类日志
53 0
|
1月前
|
SQL 人工智能 运维
数据库基础入门 — SQL排序与分页
数据库基础入门 — SQL排序与分页
17 0