Skip to main content

Availability group database is in a restoring state. SQL error 1408

Hi There!

Today's post is about fixing databases that are in a restoring state.

Scenario A
I have added a couple of databases to an availability group on my primary server.

When I go to the replica server, the databases show that they are in a restoring state.

Here's how to fix this issue:

I.
On the secondary server in SSMS, expand 'AlwaysOn High Availability' > 'Availability Groups' > ServerName (secondary) > 'Availability Databases' > right click your database name > 'Join to Availability Group...' >hit OK.

sql error 1408II.


When I hit OK above, I received a new error; SQL error 1408.

The error reads: 
The remote copy of the database is not recovered far enough to enable database mirroring or to join it to the availability group. You need to apply missing log records to the remote database by restoring the current log backups from the principal/primary database.

Now I have to go back to the primary server and take a fresh transaction log backup of the database again. Then copy the backup (.bak) file to the secondary server.
Note: Step 1 would have been fine if I tried to join the database to the availability group immediately after the database was backed up. However, since the backup was days ago, the transaction log chain is too far apart/broken.


In SSMS, right click your database > task > restore > database > device > on the General page, find the backup you copied to your server > on the Files page, check the option to relocate all files to folder > On the Options page, check the option to Overwrite the existing database (WITH REPLACE) and the recovery state is RESTORE WITH NORECOVERY > hit OK.

III.
Go back and repeat step 1.

Success! Your database is now in sync on the secondary server.

Scenario B
I have added a couple of databases to an availability group on my primary server.

When I go to the replica server, the databases do not exist.

I.
On the primary server, take a full backup of the database (.bak). Then take a transaction log backup of the database (.trn). Copy both files to the secondary server.

II.
On the secondary server, restore the full backup first:

In SSMS, right click your database > task > restore > database > device > on the General page, find the backup you copied to your server > on the Files page, check the option to relocate all files to folder > On the Options page, do not check the option to Overwrite the existing database (WITH REPLACE) but make sure the recovery state is RESTORE WITH NORECOVERY > hit OK.

Then restore the transaction log:

In SSMS, right click your database > task > restore > database > device > on the General page, find the backup you copied to your server > on the Files page, check the option to relocate all files to folder > On the Options page, check the option to Overwrite the existing database (WITH REPLACE) and the recovery state is RESTORE WITH NORECOVERY > hit OK.

III.
(This is the same as Step 1 from scenario A)

On the secondary server in SSMS, expand 'AlwaysOn High Availability' > 'Availability Groups' > ServerName (secondary) > 'Availability Databases' > right click your database name > 'Join to Availability Group...' >hit OK.

Success! Your database is now in sync on the secondary server.


 If you have any further questions, please post below.


Thank you and Happy reading,

-marshé hutchinson
#learnSQLwithme





Labels:

Comments

Post a Comment

Popular posts from this blog

event id 101 task start failed - task scheduler event id 101 launch failure

Hello again. This post is related to automating SQL server tasks with Task Scheduler. In this example I was tasked with exporting SQL server agent jobs twice a month. To achieve this, I setup a task scheduler task that ran a PowerShell script that: establishes a local connection to the SQL server. cleans the file before writing to the .sql file to avoid adding on (appending) results on subsequent runs of the task scheduler task. when a connection is established, export the SQL agent jobs on the server to a .sql file on a remote server. sends a confirmation email via the SQL server database mail profile that the SQL agent jobs were exported to the specified remote server path. That was a mouthful. Now that you know my task scheduler task is calling a PowerShell script, let's get back to why it is failing.  The good news is this error is not related to the script. The error launch failure means the task could not even run. This is most likely due to a permissi...
Post a Comment
Read more

Msg 14234, Level 16, State 1, Procedure sp_verify_job, Line 199 The specified '@owner_login_name' is invalid (valid values are returned by sp_helplogins [excluding Windows NT groups]).

Hi guys! Here's another quick and easy post. Scenario I was trying to copy a SQL agent job from one server to another by just copying the script of that SQL job. You can copy any script by right clicking a job > Script job as > create to > new query window. I pasted the job on a different server and tried to execute it and received this error: Msg 14234, Level 16, State 1, Procedure sp_verify_job, Line 199 The specified '@owner_login_name' is invalid (valid values are returned by sp_helplogins [excluding Windows NT groups]). This error message is simply saying for the variable '@owner_login_name', the user account associated with the variable is incorrect because it does not exist. Fix Simply update the variable for '@owner_login_name' to a valid user account for the current SQL instance. Now when you execute the script again to create the SQL agent job your results will be: Command(s) completed successfully. If you have any furt...
2 comments
Read more

Database "" database is not in full recovery mode on each of the server instances. The full recovery model is required for a database to participate in database mirroring or in an availability group. [SQLSTATE 42000] (Error 1465).

Hi there. This post will be a quick and easy fix. If you are not already aware, availability groups are the replacement for mirroring in SSMS (SQL Server Management Studio). We like to utilize availability groups so that there is minimal data loss. Also, in the event of some natural disaster or disk failure on a server that is participating in an availability group, the data will fail-over to a backup server (replica). I was adding a database to an availability group when I received the error: Database "database_name" database is not in full recovery mode on each of the server instances. The full recovery model is required for a database to participate in database mirroring or in an availability group. [SQLSTATE 42000] (Error 1465). The error is exactly as it sounds; The database is not in the full recovery model. To fix this: I. In SSMS, right click the database to see the properties. On the Options page, change the database recovery model to Full. II....
1 comment
Read more