I recently did a VMWare/SAN assessment for a client.  The expressed reason, or the reason relayed to me (not always the same thing), was they wanted me to review their configuration for best practices and look for performance enhancement opportunities.  It was a multi-site SAN with close to a dozen ESXi hosts and had been in place for about one year.  When I first met with the client I learned that their real motivation for having me come out was they were experiencing problems:  virtual machines freezing, physical servers with hardware warning LEDs for DIMMs, error messages, etc.  But before I could even get started we ran into a new problem.  The vCenter Server was misbehaving.  I quickly found that the database, a SQL 2005 Express Edition, had hit the four GB ceiling.  So how do you shrink a vCenter database quickly so you can move on to the job you were hired to do?  It’s easy, VMWare has a maintenance script that cleans out old data based on a time frame that you specify.  It’s a very handy script that I expect to use again, often.  Here is the link to where you can download the script from VMWare’s site:  http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1025914

It took a while to run, but this particular vCenter Server was running on a virtual Windows XP, so that might have had something to do with it.  We also purged nearly a year’s worth of data leaving only 30 days worth, at the client’s request.  Purging less data naturally would have taken less time.  I might make some changes to it to write out the records to a second database before deleting them.  And if I do I’ll post the changes here.  But then again, how often do you need performance metrics dating back to the beginning of your install.  Baseline data is needed for sure for benchmarking and troubleshooting, but you don’t need every data sample the system ever captured.

Now for anyone thinking about the Database Retention Policy setting, know that it doesn’t apply to performance data, only vCenter Server tasks and events.  Also, I didn’t shrink the database after I was finished and you shouldn’t either given a similar scenario.  It’s just going to grow back again.  Better to leave the database at the appropriate size instead of forcing it to autogrow.  Another best practice.   All in all, it was an educational little obstacle and if you ever work with vSphere systems, here is one more post out on the web pointing you to VMWare’s handy dandy maintenance script.

Cheers.