Database performance tuning is more art than science, but a few well-placed monitors will come in handy as growth begins to stress your systems. Monitoring servers and applications is difficult in the abstract, hypothetical case because the stress points are not yet know. I’ve seen many standardized monitoring set ups that failed to alert anyone to an impending problem…then a sudden crisis where tons of data was available–but it was all “crisis data”–i.e. no one knew if the numbers were evidence or consequence of a problem.

Setting up a ping monitor of your database server is like asking your doctor to call you if your heart stops beating. You can add in a few other monitors like CPU utilization, memory, number of processes running, etc. but these monitors will not give you much insight into problems beyond the obvious. Every IT manager spend half a day reviewing these tips from SQL Server Performance.com (or see the mysql performance blog) and then start collecting data now so you will have some benchmarking data when scalability and capacity issues come up.

You could follow the advice in the article and run perfmon, but it’s unlikely you will want to run that indefinitely, so you will want to find a way to include this data collection in your general monitoring solution.