LOG SHPPING

Question : IS it possible to log ship database between SQL 2000 & SQL 2005?
Answer: No, thats impossible, In SQL 2005 transaction log architecture is changed compared to SQL
2000 and hence you wont be able to restore log backups from SQL 2000 to SQL 2005 or vice versa.

Question: How to failover in SQL 2005 Log Shipping?
Answer: I can better ask to check out the link Failover in SQL 2005 Log Shipping, Deepak written this
article clearly.

Question:Im getting the below error message in restoration job on secondary server, WHY?
[Microsoft SQL-DMO (ODBC SQLState: 42000)]
Error 4305: [Microsoft][ODBC SQL Server Driver][SQL Server]The log in this backup set
begins at LSN 7000000026200001, which is too late to apply to the database. An earlier
log backup that includes LSN 6000000015100001 can be restored.
[Microsoft][ODBC SQL Server Driver][SQL Server]RESTORE LOG is terminating abnormally.

Answer:Was your sql server or agent restarted Yday in either source or destination ? because the error
states there is a mismatch in LSN. A particular tran log was not applied in the destination server hence
the subsequent tran logs cannot be applied as a result !
You can check log shipping monitor \ log shipping tables to check the which transaction log is last applied
to secondary db, if the next consecutive transaction logs are available in the secondary server share
folder you manually RESTORE the logs with NORECOVERY option, Once you restored all the logs
automatically from the next cycle the job will work fine.
Incase if you are not able to find the next transaction log in secondary server shared folder, you need to
reconfigure log shipping. Try the below tasks to re-establish log shipping again.
Disable all the log shipping jobs in source and destination servers
Take a full backup in source and restore it in secondary server using the With Standby option
Enable all the jobs you disabled previously in step1

Question: Is it possible load balance in log shipping?
Answer:Yes ofcourse its possible in log shipping, while configuring log shipping you have the option to
choose standby or no recovery mode, there you select STANDBY option to make the secondary database
readonly. For SQL 2005 log shipping configuration check out the link 10 Steps to configure Log Shipping


Question: Can I take full backup of the log shipped database in primary server??
Answer: In SQL Server 2000 you wont be able to take full backup of log shipped database, because this
will break the LSN chain and it directly affects the log shipping.
In SQL Server 2005, yes its possible. You can take full backup of log shipped database and this wont
affect the log shipping.

Question : Can I shrink log shipped database log file??
Answer: Yes ofcourse you can shrink the log file, but you shouldnt use WITH TRUNCATE option. If you
use this option obviously log shipping will be disturbed.

Question : Can I take full backup of the log shipped database in secondary server??
Answer: No chance , you wont be able to execute BACKUP command against a log shipped database in
secondary server.

Question: Ive configured Log shipping successfully on standby mode, but in the restoration
job Im getting the below error. What I do to avoid this in future??
Message
2006-07-31 09:40:54.33 *** Error: Could not apply log backup file C:\Program Files\Microsoft SQL
Server\MSSQL.1\MSSQL\Backup\LogShip\TEST_20060731131501.trn to secondary database
TEST.(Microsoft.SqlServer.Management.LogShipping) ***
2006-07-31 09:40:54.33 *** Error: Exclusive access could not be obtained because the database is in
use.
RESTORE LOG is terminating abnormally.(.Net SqlClient Data Provider) ***

Answer: To restore transaction logs to the secondary db, SQL Server needs exclussive access on the
database. When you configure it in standby mode, users will be able to access the database and runs
query against the secondary db. Hence If the scheduled restore jobs runs at that time, the db will have a
lock and it wont allow SQL Server to restore the tlogs. To avoid this you need to check Disconnect users
in the database when restoring backups options in log shipping configuration wizard. Check the link 10
Steps to configure Log Shipping.

Question : Can you tell me the pre-requisites for configuring log shipping??
Answer : Check out the link Pre-requisites for Log Shipping.


Question : Suddenly Im getting the error below, How can I rectify this???
[Microsoft SQL-DMO (ODBC SQLState: 42000)] Error 4323: [Microsoft][ODBC SQL Server Driver][SQL
Server]The database is marked suspect. Transaction logs cannot be restored. Use RESTORE DATABASE
to recover the database.
[Microsoft][ODBC SQL Server Driver][SQL Server]RESTORE LOG is terminating abnormally
Answer : We had the same issue some time ago, this was related to a new file being created in a
filegroup on the source. Dont know if this applies to your case, but restoring a backup of this new file on
the secondary server solved the problem.

Question : Is it possible to log ship database from SQL server 2005 to SQL server 2008 and
vice versa?
Answer : Yes you can log ship database from SQL server 2005 to SQL Server 2008 this will work.
However log shipping from SQL Server 2008 to SQL Server 2005 is not possible because you wont be
able to restore SQL server 2008 backup to SQL Server 2005 (downgrading version)

Question:What is Log Shipping
Essentially, log shipping is the process of automating the backup of database and
transaction log files on a production SQL server, and then restoring them onto a standby server. But
this is not all. The key feature of log shipping is that is will automatically backup transaction logs
throughout the day (for whatever interval you specify) and automatically restores them on the
standby server. This in effect keeps the two SQL Servers in "synch". Should the production server fail,
all you have to do is point the users to the new server, and you are all set. Well, its not really that
easy, but it comes close if you put enough effort into your log shipping setup.

Question : IS it possible to log ship database between SQL 2000 & SQL 2005?
Answer: No, thats impossible, In SQL 2005 transaction log architecture is changed compared to SQL
2000 and hence you won't be able to restore tlog backups from SQL 2000 to SQL 2005 or vice versa.
Question:I'm getting the below error message in restoration job on secondary server, WHY?
[Microsoft SQL-DMO (ODBC SQLState: 42000)]
Error 4305: [Microsoft][ODBC SQL Server Driver][SQL Server]The log in this backup set
begins at LSN 7000000026200001, which is too late to apply to the database. An earlier
log backup that includes LSN 6000000015100001 can be restored.
[Microsoft][ODBC SQL Server Driver][SQL Server]RESTORE LOG is terminating abnormally.
Answer:Was your sql server or agent restarted Y'day in either source or destination ? because the error
states there is a mismatch in LSN. A particular tran log was not applied in the destination server hence
the subsequent tran logs cannot be applied as a result !
You can check log shipping monitor \ log shipping tables to check the which transaction log is last
applied to secondary db, if the next consecutive transaction logs are available in the secondary server
share folder you manually RESTORE the logs with NORECOVERY option, Once you restored all the logs
automatically from the next cycle the job will work fine.
Incase if you are not able to find the next transaction log in secondary server shared folder, you need to
reconfigure log shipping. Try the below tasks to re-establish log shipping again.
o Disable all the log shipping jobs in source and destination servers
o Take a full backup in source and restore it in secondary server using the With Standby option
o Enable all the jobs you disabled previously in step1

Question: Is it possible load balance in log shipping?
Answer:Yes ofcourse its possible in log shipping, while configuring log shipping you have the option to
choose standby or no recovery mode, there you select STANDBY option to make the secondary database
readonly.
Question: Can I take full backup of the log shipped database in primary server??
Answer: In SQL Server 2000 you won't be able to take full backup of log shipped database, because this
will break the LSN chain and it directly affects the log shipping.
In SQL Server 2005, yes its possible. You can take full backup of log shipped database and this won't
affect the log shipping.
Question : Can I shrink log shipped database log file??
Answer: Yes ofcourse you can shrink the log file, but you shouldn't use WITH TRUNCATE option. If you
use this option obviously log shipping will be disturbed.
Question : Can I take full backup of the log shipped database in secondary server??
Answer: No chance , you won't be able to execute BACKUP command against a log shipped database in
secondary server.
Question: I've configured Log shipping successfully on standby mode, but in the restoration job I'm
getting the below error. What I do to avoid this in future??
Message
2006-07-31 09:40:54.33 *** Error: Could not apply log backup file 'C:\Program Files\Microsoft SQL
Server\MSSQL.1\MSSQL\Backup\LogShip\TEST_20060731131501.trn' to secondary database
'TEST'.(Microsoft.SqlServer.Management.LogShipping) ***
2006-07-31 09:40:54.33 *** Error: Exclusive access could not be obtained because the database is in
use.
RESTORE LOG is terminating abnormally.(.Net SqlClient Data Provider) ***
Answer: To restore transaction logs to the secondary db, SQL Server needs exclussive access on the
database. When you configure it in standby mode, users will be able to access the database and runs
query against the secondary db. Hence If the scheduled restore jobs runs at that time, the db will have a
lock and it won't allow SQL Server to restore the tlogs. To avoid this you need to check "Disconnect
users in the database when restoring backups" options in log shipping configuration wizard.
Question : Suddenly I'm getting the error below, How can I rectify this???
[Microsoft SQL-DMO (ODBC SQLState: 42000)] Error 4323: [Microsoft][ODBC SQL Server Driver][SQL
Server]The database is marked suspect. Transaction logs cannot be restored. Use RESTORE DATABASE to
recover the database.
[Microsoft][ODBC SQL Server Driver][SQL Server]RESTORE LOG is terminating abnormally
Answer : We had the same issue some time ago, this was related to a new file being created in a
filegroup on the source. Don't know if this applies to your case, but restoring a backup of this new file on
the secondary server solved the problem.
Question : Is it possible to log ship database from SQL server 2005 to SQL server 2008 and vice versa?
Answer : Yes you can log ship database from SQL server 2005 to SQL Server 2008 this will work. However
log shipping from SQL Server 2008 to SQL Server 2005 is not possible because you wont be able to
restore SQL server 2008 backup to SQL Server 2005 (downgrading version).
Question:Benefits of Log Shipping
While I have already talked about some of the benefits of log shipping, let's take a more comprehensive
look:
Log shipping doesn't require expensive hardware or software. While it is great if your standby
server is similar in capacity to your production server, it is not a requirement. In addition, you
can use the standby server for other tasks, helping to justify the cost of the standby server. Just
keep in mind that if you do need to fail over, that this server will have to handle not one, but
two loads. I like to make my standby server a development server. This way, I keep my
developers off the production server, but don't put too much work load on the standby server.
Once log shipping has been implemented, it is relatively easy to maintain.
Assuming you have implemented log shipping correctly, it is very reliable.
The manual failover process is generally very short, typically 15 minutes or less.
Depending on how you have designed your log shipping process, very little, if any, data is lost
should you have to failover. The amount of data loss, if any, is also dependent on why your
production server failed.
Implementing log shipping is not technically difficult. Almost any DBA with several months or
more of SQL Server 7 experience can successfully implement it.
Question: Problems with Log Shipping
Let's face it, log shipping is a compromise. It is not the ideal solution, but it is often a practical solution
given real-world budget constraints. Some of the problems with log shipping include:
Log shipping failover is not automatic. The DBA must still manually failover the server,
which means the DBA must be present when the failover occurs.
The users will experience some downtime. How long depends on how well you
implemented log shipping, the nature of the production server failure, your network,
the standby server, and the application or applications to be failed over.
Some data can be lost, although not always. How much data is lost depends on how
often you schedule log shipping and whether or not the transaction log on the failed
production server is recoverable.
The database or databases that are being failed over to the standby server cannot be
used for anything else. But databases on the standby server not being used for failover
can still be used normally.
When it comes time for the actual failover, you must do one of two things to make your
applications work: either rename the standby server the same name as the failed
production server (and the IP address), or re-point your user's applications to the new
standby server. In some cases, neither of these options is practical.
Question:Log Shipping Overview
Before we get into the details of how to implement log shipping, let's take a look at the big picture.
Essentially, here's what you need to do in order to implement log shipping:
Ensure you have the necessary hardware and software properly prepared to implement
log shipping.
Synchronize the SQL Server login IDs between the production and standby servers.
Create two backup devices. One will be used for your database backups and the other
will be used for your transaction log backups.
On the production server, create a linked server to your standby server.
On the standby servers, create two stored procedures. One stored procedure will be
used to restore the database. The other stored procedure will be used to restore
transaction logs.
On the production server, create two SQL Server jobs that will be used to perform the
database and transaction log backups. Each job will include multiple steps with scripts
that will perform the backups, copy the files from the production server to the standby
server, and fire the remote stored procedures used to restore the database and log files.
Start and test the log shipping process.
Devise and test the failover process.
Monitor the log shipping process.
Problems with Log Shipping

Log shipping is a compromise but it is not the ideal solution, it is a practical solution given real-world
budget constraints. Some of the problems with log shipping include:

Log shipping failover is not automatic. The DBA must be present when the failover occurs.
The users will experience some downtime. How long depends on how well you implemented log
shipping, the nature of the production server failure, your network, the standby server, and the
application or applications to be failed over.
Some data can be lost, although not always. How much data is lost depends on how often you
schedule log shipping and whether or not the transaction log on the failed production server is
recoverable.
The database or databases that are being failed over to the standby server cannot be used for
anything else. But databases on the standby server not being used for failover can still be used
normally.
When it comes time for the actual failover, you must do one of two things to make your
applications work: either rename the standby server the same name as the failed production
server (and the IP address), or re-point your user's applications to the new standby server. In
some cases, neither of these options is practical.