Can MSSQL transaction log be transferred across databases?

I believe many people have used or are applying the logshipping function of SQLSERVER. This is a very powerful function provided by MSSQL and generally requires a primary database server (primaryproductiondatabaseserver) and the auxiliary database server (standbyserver) to complete this configuration. By default

The log shipping function of SQL server is used or is being applied by many people. This is a very powerful function provided by ms SQL, generally, you need a primary database server (primary/production database server) and a secondary database server (standby server) to complete this configuration. By default

SQL server's log shipping function, website space, I believe many people have used or are using it. This is a very powerful function provided by ms SQL, generally, a primary database server (primary/production database server) and a secondary database server (standby server) are required to complete this configuration. By default, the versions of the primary database and the secondary database should be the same. If the versions of the two databases are different, will there be any problems? Can I configure log shipping?

There are two different database versions:

1: versions similar to 64-bit SP4 in ms SQL 2005 and 32-bit in ms SQL 2005 SP3

2: completely different versions, such as ms SQL server 2005 and ms SQL SERVER 2008.

Some people may have to talk about it. Why do we need to build different versions? Isn't it okay to find something to do? In this case, it is really hard to say a word, a historical issue... and so on. How do you tell me to speak out? Well, we will not be entangled in these trivial things. Now we are back to the above questions.

As for the first case, we can do log shipping. There is no problem. I have done two such cases, both of which are successfully configured and work well.

Environment of Case 1:

Database Server

Version Information

Master Database Server

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)

Secondary Database Server

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)

Case 2 environment:

Database Server

Version Information

Master Database Server

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)

Secondary Database Server

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)

In the second version, different situations also need to be subdivided:

1: The primary database SERVER is SQL server 2008, and the secondary database SERVER is SQL server 2005. In this case, this is totally unfeasible because of your backup on SQL SERVER 2008, it cannot be restored on a lower version of SQL server 2005 (or a lower version), and so on. Primary Server is SQL 2012 Std and Secondary Server is SQL 2008 R2 Std does not work.

2: The primary database SERVER is SQL server 2005, and the secondary database SERVER is SQL SERVER 2008R2. In this case, when the log shipping is deployed, the SERVER space will report an error when you choose Standby Mode:

Error message: 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)

You can only select the No Recovery mode option. The reason for the above error is clearly and clearly explained in the following section (for the source, see references below ):

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

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.

The translation is as follows (the level is limited for your reference only ):