When SP2 was released almost a year ago there was an update to the Database Statistics Job. What was updated was a rebuild of the database reindex. This was introduced as one of the main improvements in the SP2 and it is. But in some cases the job might not always be as good as it sounds for your environment.

The reason for that is that the rebuild of the index is quite aggressive in it’s nature and does not have any logic built in to it. It simply rebuilds the whole index daily.

If you look at the information from Microsoft at technet (http://technet.microsoft.com/en-us/library/cc678870.aspx) about the job it says:

If you have installed Office SharePoint Server 2007 with SP2:

• The job updates the query optimization statistics by sampling key tables every time that it runs, instead of performing a full scan.
• If you are running SQL Server 2005 or SQL Server 2008, the job rebuilds all indexes in the content databases every time that it runs.
• If you are running an Enterprise edition of SQL Server 2005 or SQL Server 2008, the job rebuilds most indexes online.
• If you are running a Standard edition of SQL Server 2005 or SQL Server 2008, the job rebuilds the indexes offline.
• If you are running SQL Server 2000, the job does not rebuild any indexes.

It actually also specifies that the job should only run weekly if you are running MOSS and daily if your using WSS. I assume that this is just a mistake in the documentation because in all environments I looked in it’s set to daily no matter if you are using Moss or WSS with SP2.

So what happens if you have a large environment where your have backups, or maybe a crawl running at the same time. Or maybe your SQL DBA’s have done their job and have their own reindex and update statistics job put directly in SQL? Well, you could run in to performance problems and extreme slow environments together with backups taking longer time then they should, error messages and maybe even corrupt databases. The later I have not seen but potentially it’s possible.

I’m not saying that bad things will happen to your environment with this job, but more of be aware and have a look at how this is configured in your environment. Maybe you should reschedule it if it’s in conflict with any other SQL job. And if you are not the SQL DBA talk to the DBAs and make sure that they don’t have any similar already in place. If they have, is it better with built in logic where they look at the fragmentation level? Then maybe you should disable the SharePoint Timer Job and only run the job put on the SQL server.

If you want to find out what settings you have you could first look in Central Administration. You have one Database Statistics job for each Web Application and you can see that under Operations and Timer Job Status. In the Timer Job Definition, found at the same place in Central administration, you can see if the job is run weekly or daily.
The best  way is however to use STSADM or SPDiag to get the information on when it’s scheduled. To reschedule jobs you need to use STSADM.

This is how you get the settings you have using STSADM:

stsadm -o getproperty -pn job-database-statistics -url http://YourSPSite

And to set a new value you do like this:

stsadm -o setproperty -pn job-database-statistics -pv “Weekly between Fri 22:00:00 and Sun 06:00:00″ -url http://YourSPSite

Here you have the STSADM reference for this particular task: http://technet.microsoft.com/en-us/library/cc424963.aspx