Restoring Log Shipping to Destination Server

flyfish15

Dear Forum,

We have just installed Redgate Backup Version 4.6.0.815

The problem is restoring the log files, destination database is set to Full Recovery - Read only (RESTORE WITH STANDBY)

The error is I am getting is

Summary
The job failed. The Job was invoked by User LANGROUP\admin-inv. The last step to run was step 1 (Step 1).
Step 1
Executed as user: LANGROUP\admin-sql. SQL Backup job failed with exitcode: 150 SQL error code: 4326 [SQLSTATE 42000] (Error 50000). The step failed.


both admin-sql and admin-inv have set up in both source and destination database and have permissions to the database i am trying to restore.

Can anyone advise

Thanks in advance
Flyfish - first time user of Red-gate.


In setting up red through the walk throughs, the documentation etc.

Jason Cook

Hi flyfish,
You appear to have two issues with your log shipping configuration.

The first is the SQL Server Error (4326), which relates to log backups being out of sequence.

If you look in your SQL Backup logging directory (by default, this is at c:\documents and settings\all users\application data\red gate\sql backup\log\<instance name>), you should find a timestamped log that corresponds to the restore in question.

This log should give you information on what was wrong with the restore, and you can find which files in your "backups" directory you need to copy to the network share (or need to move from the network share to the "processed" directory). The log shipping should then start functioning correctly.


The second issue you appear to have is the SQL Backup Warning 150, which is because you haven't configured a SMTP mail server in the SQL Backup 4.6 User Interface.

If you open the "Options" dialog, and select the SQL Server instance(s) you are working with, you can enter a SMTP mail server, and this particular warning should then go away.

Ideally you should be entering an SMTP server name on both the SQL Server instances used for log shipping.



If you need any more information or detailed help with your question, feel free to follow-up on the forum or drop me an email.

Hope that helps,
Jason

NewDBAGirl

Looks like I am having the same problem. For starters, I don't have an application data folder under the all users folder. Where else can I find this data?

I'm really confused here because I don't understand why some of the restores will work and some won't. All of my log shipping is configured the same way.

By the way, I'm using SQL Back up v5. I did a search on the area and this post appeared.

Jason Cook

Hi NewDBAGirl,
You may need to click "Tools" at the top of the explorer window, and select "Folder Options". On the "View" tab, make sure the "Show Hidden Files and Folders" option is selected.

You should then see the "Application Data" folder appear.

If you need any more help finding the log files, let me know.

Jason

NewDBAGirl

Thank you very much. I was able to view the Application Data folder with the instructions that you provided.

I'm not sure if I should be applying the same steps that you recommended for the previous person. Here is my exact problem. Three of the databases are receiving this same error when trying to do a restore from log shipping. Each of the actual log names are different for each of the databases.

It is says SQL Error 4326: The log in this backup set terminates at '' which is too early to apply to the database. A more recent log backup that includes '' can be restored.

Do you know what should be done to eliminate this problem?

petey

The error indicates that the contents of the transaction log backup file that you are trying to restore, has already been applied to the database. By applied, I mean either you have restored this transaction log backup previously, or you have restored a full database /+ differential backup that was made after this transaction log backup.

See http://www.yohz.com/logship.html for some help on how log shipping is implemented in SQL Backup.

FistyBiscits

Go to the network share that you are using for your logshipping directory. You should find that the log you cannot apply is also the oldest log in that directory. Delete or backup/copy the log to another location. Next iteration of the log apply should work.

For some reason, the apply procedure stops when it encounters a log that is too old. Once this blocking log is moved the apply should function as expected.

HTH.

Cheers,

jimm1909

FistyBiscits wrote:

Go to the network share that you are using for your logshipping directory. You should find that the log you cannot apply is also the oldest log in that directory. Delete or backup/copy the log to another location. Next iteration of the log apply should work.
Vegas Attractions

For some reason, the apply procedure stops when it encounters a log that is too old. Once this blocking log is moved the apply should function as expected.

HTH.

Cheers,

Dave-

Thanks for the response that cleared up my issue.

-Jim