Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase

Check Database Integrity taking a long time Expand / Collapse
Author
Message
Posted Thursday, June 13, 2013 2:14 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Wednesday, November 19, 2014 4:58 AM
Points: 8, Visits: 131
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
Post #1462931
Posted Sunday, June 16, 2013 10:10 AM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Thursday, November 27, 2014 1:25 AM
Points: 52, Visits: 487
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.
Post #1463968
Posted Monday, June 17, 2013 10:20 AM
Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Tuesday, October 28, 2014 10:45 AM
Points: 1,058, Visits: 2,696
Is your backup and application using this DB is working fine?



Regards
Durai Nagarajan
Post #1464262
Posted Monday, June 17, 2013 3:27 PM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Wednesday, November 19, 2014 4:58 AM
Points: 8, Visits: 131
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.
Post #1464411
Posted Tuesday, June 18, 2013 3:07 AM


Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Friday, March 21, 2014 9:46 AM
Points: 387, Visits: 1,078
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.
Post #1464522
Posted Tuesday, June 18, 2013 3:35 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Monday, December 8, 2014 11:49 AM
Points: 22, Visits: 129
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
Post #1464534
« Prev Topic | Next Topic »

Add to briefcase

Permissions Expand / Collapse