vCenter Server service failed to start - logs full - customary log settings/sizes?

T

Thuleman

Supreme [H]ardness
Joined
Apr 13, 2004
Messages
5,833
All of a sudden my Veeam backup that has been running flawlessly for weeks failed all scheduled backup runs last night. At first I thought it was a Veeam problem but this morning, more awake, I realized that my VMware VirtualCenter Server service wasn't actually running.

Curious, since the service isn't in the habit of suddenly quitting like that for no reason. The Windows Application log showed that "The transaction log for database 'VIM_VCDB' is full. To find out why space in the log cannot be reused, see the log_reuse_wait_desc column in sys.databases".

As so often, The Google's first result provided a way to fix this issue (increase file size for log file to be able to start vCenter again How to Fix “Transaction log for database ‘VIM_VCDB’ is full” errors).

Then there's a way to cut down the growth of the DB by changing the logging level and the retention policy of the logs by connecting to vCenter using the vSphere Client and then going to Administration -> vCenter Server Settings -> Logging Options and Database Retention Policy.

My questions are what are your settings for:

MSSQL VIM_VCDB Properties Options Recovery Model?
I see a lot of folks online who seem to set this to Simple.

Logging Options and Database Retention?
 
From reading that I gather a couple of things. One, you're not using SQL express :)
You don't need anything more than simple recovery if you're not doing anything with the logging (log shipping, mirroring, etc). I don't know what you're doing for backups, but I doubt it would be affected negatively by that change.

The statistics levels usually produce very little data overall _IF_ the jobs are running that roll up the intervals. I usually crank the logging up as it can be very helpful having the more frequent interval data kept for a longer period of time when troubleshooting. Once you rollup past 5 minutes the data (I believe) can start to be fairly worthless. The live data is collected every 20 seconds which creates a lot of data if the rollup jobs aren't working. The vCenter service status (if vCenter was working) could let you know if those jobs are running properly, otherwise you'll have to check your logs to see if they're erroring or what. I know from my own experience after a VC DB migration that we originally had neglected to create the jobs on the new DB server :)... that can cause you pain as well.

Either way, it looks like its the log data and not the actual mdf that got out of whack this time. You have to make sure that if you're using the full recovery model that regular transaction log backups are occuring. If not the transactions marked inactive in the log aren't truncated and the space can't be reused.
 
I do actually use the SQL Express 2005 that came with vCenter 4.1.
The Recovery Model was set to Bulk-Recovery which I think is the default since I don't have any notes on ever changing it (or maybe that just means I changed it and didn't make a note of it (unlikely)).

My vCenter logging is set to Information (Normal logging) and the retention policy is 365 days, which is probably excessive for no good reason.
 
OK, SQL express is a different animal. Without the SQL agent the vCenter service handles the roll up jobs, but I think it has been established that the actual size of the database isn't the issue, but the log file grew tremendously. Why not just use the simple recovery model, and also -- how are you backing that database up, or actually, do you even care?? I've seen small shops just say they will rebuild VC, which I find nuts personally. I guess without a lot of users/roles, etc, it probably wouldn't be THAT bad.
 
So funny|!!! I happened to be troubleshooting this same issue with one of our two Veeam / vSphere environments here at work. I clicked on this link during a search and voila it brought me to this thread! I happened to be logged into the [H] Forum (as usual) anyway and was also posting another thread. Small world and just again proof of the wealth of knowledge on these forums!

Thank you guys, this has fixed my issue!
 
You must log in or register to reply here.
Back
Top