Past two months I’ve received three calls from customers who’s vCenter suddenly stopped working because their SQL database had stopped because the logs had filled up. Turns out few people regularly check the status of their SQL database. VMware has written some very good KB articles on what to do when your SQL DB fills up and stops. So this blog post is only a wake-up call for you to check on your database.
Some good KB articles from VMware on this subject:
- Purging old data from the database used by vCenter Server
- Purging old data from the database used by VirtualCenter 2.x
- Defragmenting VirtualCenter performance data indexes on a Microsoft SQL database
- Investigating the health of a vCenter Server database
- Migrating an existing vCenter Server database to 4.1 using the Data Migration Tool
- Migrating to vCenter Server 5.0 using the Data Migration Tool
- Starting the VMware VirtualCenter Service service fails with the error: Windows could not start the VMware VirtualCenter Server on Local Computer
From Josh Atwell I got this tip: Size Matters, especially when your database is full.
Here’s a #PowerShell function written by Zach M @WIDBA:twitter that will help monitor your SQL DB size! He posted this up recently after he and I had a discussion on this very topic. Should be very helpful for keeping an eye out.
Thanks for this reminder, Gabe. If folks need a quick how-to on backing up and their SQL Server 2008 vCenter database, I blogged about it here: http://virtuallymikebrown.com/2011/10/14/sql-server-2008-backups-for-vmware-databases/. My tutorial ensures your SQL transaction logs are backed up and therefore, cleared for the next round of transactions. SQL Server can also be configured to keep only a certain number of days worth of backups and delete those older than the threshold, ensuring you don’t run out of disk space. You’ll need to size your .vmdks appropriately depending on the size of your environment and the granularity of the performance and historical data that’s backed up.
Wow – turns out my vcenter DB was hella fragged
first pass at defrag
12-> 30% Scan Density (ideally as close to 100% as possible)
98->32% Logical Scan Fragmentation (ideally as close to 0 as possible)
(then the transaction logs filled up)
re-running now
Hopefully the vCheck script takes less than 4 hours tomorrow to make this worth it
thanks