"SQL server is not available" on version 7

[elb]

Hi,

I've been facing an error on some jobs with Veeam Backup and Replication v7.0.0.871 (patch 4), on a Windows 2012 Server.
I've got 4 virtual machines running on this host and a backup job for each one.

During about 2 years, everything was going right, but for some time now (I would say about 2 months), one of these jobs fails with error message:

"Error: Microsoft SQL server hosting the configuration database is currently unavailable. Possible reasons are heavy load, networking issue, server reboot, or hot backup.
Please wait, and try again later.
Error information:
SQL server is not available"

Last night I had this error on 2 jobs, while 2 jobs succeed.
I did reinstall Veeam (with reboot af the host), and created a new fresh SQL database. Made a new configuration with backup repositories and backup jobs, but still got this error.

Searching on this forum, I found a similar topic here --> vmware-vsphere-f24/error-information-sq ... 26809.html
BUT the solution which has been found is to set a SQL authentification connection, and this doesn not seem to be applicable on version 7 (--> http://helpcenter.veeam.com/backup/80/v ... entication)

Did someone faced a similar issue on version 7? Do we know a solution for that?

I can't have any offical support because of the expiration of the support contract.
Thank you

[Shestakov]

Hi,
Is that a constant error or accidental? As the error stated heavy load may cause it.
It`s hard to say without closer investigation, but one of the possible reasons is insufficient system memory to run a query.
The similar issue has been solved by changing the server configurations.

[elb]

Thank you Shestakov for answering.

In fact that wasn't my first thought because of the large amount of memory available on this server.
But I admit that this morning, during a backup job that didn't succeed at first try for the resaon said before, it was quite impossible to login to the server because of RAM overload. That did not happened until today but it may have already happened during backups.

As I read on the topic linked in your answer, It may be a good practice to set a maximum memory usage for SQL server, otherwise it may cause instability somewhere.

I just set a maximum size using SQL Management Studio, will let you know if things going better for the next jobs (which are scheduled during this week-end)

[Shestakov]

Yeah, I`d also give it a try.
Do you have Veeam ONE to check if your VMs are Under- and Over-sized and make a memory reclamation between them?

[elb]

No, did not used Veeam One until now.
What do you mean by "Under- and Over-sized and make a memory reclamation between them"?

[Shestakov]

There is a Hyper-V Optimization Report Pack made to help you achieve the most optimal resource usage, including Oversized VMs report helps you to detect VMs that have more allocated vRAM or vCPU resources than they require and Undersized VMs one, to show which VMs need more resources.

[elb]

OK, I see, sounds interesting!
I think I should give it a try, I must say I did not really look at this tool until now...

[Shestakov]

There is a trial version with full functionality available.
It`s v9, but should work fine with Veeam Backup & Replication 7.0 update(patch) 4.

[elb]

Hi,
Sorry for this late come back

Wanted to let you know results of actions I made after reading your advices:

First I set a maximum memory usage value on SQL Server ---> result has been really positive because as soon as I made it, all backup jobs in destination of the NAS have succeed, no more SQL unvailable issue
BUT, there are other jobs with USB HDD in destination. For these jobs, which had always succeed until now, I had the same error message as initial problem.
I set a minimum memory usage value this time for SQL server, and after that jobs have succeed. But I cannot say if this is this action that helped...

I did not install Veeam One, but I am aware it could be useful. I think that the next step I'll do.

Thank you for your help Sheskatov!!

[Gostev]

Better late than never thanks!