Check Database Integrity taking a long time

Question

Check Database Integrity taking a long time

jayjj

Mr or Mrs. 500

Points: 576
More actions
June 13, 2013 at 2:14 am

#275031

Hi Guys,
I have just noticed that in the past few days a Maintenance Plan job that we have on SQL 2012 database seems to be taking a long time to complete. The last job was completed in over 12hrs, however so far i have not been able to pin point exactly what is causing this issue and this job use to complete in 30-60 minutes before. This is not a very large database either as its just 37GB.
From the logs i have worked out that its the CHECK Database Integrity Task which is taking 12hrs, this would start at 01:00AM and Complete at 13:00PM, other task are completed in normal times.
This is the OperationsManager Database within System Center 2012.
Wondering if anyone has an idea of what could be causing this issue.
Thanks

Viewing 6 posts - 1 through 5 (of 5 total)

You must be logged in to reply to this topic. Login to reply

Low Rider SSCommitted Points: 1502 More actions · Answer 1

Years ago i had faced a similar issue where the check db took a lot of time to complete.The issue was later found to be with the disk system and we had to move the database to another server.

However this was also accompanied by a reduction in performance of the database.Is your applcation running slowly too?You could get the disk system checked out.

durai nagarajan SSCoach Points: 15775 More actions · Answer 2

Is your backup and application using this DB is working fine?

Regards
Durai Nagarajan

jayjj Mr or Mrs. 500 Points: 576 More actions · Answer 3

thanks for the reply guys. I have a strong feeling it might be down to a few crashes and restore of the database we had in between this issue, we have made a few changes to assign more memory resource to the database so we are monitoring this and also we think next step is to place the temp database on its own drive.

The crashes we were having were due to the server crashing and corrupting the database as Applications are constantly writing to it, we would then have to restore via a TSM backup because the database would restart in a emergency mode.

SQL Show SSCertifiable Points: 6143 More actions · Answer 4

Let us find the root case of delayed checkdb. Since its 37GB, I would suggest to run checkdb in another test machine with your restored 37gb.

ronang SSC Veteran Points: 238 More actions · Answer 5

Hi

Check the fragmentation on you db files. Usually after several restores etc. and the fact that it seems to be a heavy write load on this db. Fragmentation can occur quite easily.

Regards,

Ronan