none
SCSM SQL Data Grows Fast RRS feed

  • Question

  • I have an issue with our SCSM SQL Database growth and don't know where to start looking. This seems to have started after I updated SCSM to UR5. So what happens is I'll add 100 Gigs to my SQL Server where the SCSM DB resides and within a couple weeks I'm out of disk space. Anyone know what is causing this.
    Wednesday, September 2, 2015 4:18 PM

Answers

  • The top 3 biggest tables to check are dbo.JobStatus, dbo.BlobStorage, and dbo.EntityChangeLog.

    If the Job Status table has grown to excessive proportions, than you can use this link to change up how long the job status histories are kept: http://blogs.technet.com/b/servicemanager/archive/2010/12/07/more-aggressively-grooming-the-jobstatus-and-windowsworkflowtaskjobstatus-tables.aspx

    The Blob Storage table is all your file attachments and those can managed through training or altering your data retention settings.

    Wednesday, September 2, 2015 4:28 PM
  • I have an issue with our SCSM SQL Database growth and don't know where to start looking. This seems to have started after I updated SCSM to UR5. So what happens is I'll add 100 Gigs to my SQL Server where the SCSM DB resides and within a couple weeks I'm out of disk space. Anyone know what is causing this.

    Hi,

    There are all good answers on this thread. I have seen an issue similar to this several times. It turned out to be the SQL logs that were eating up drive space. I would first check your drive with something like WinDirStat to see if it is the DB data files or the log files that are using up all the space. Here is a link to the free WinDirStat utility: https://windirstat.info/

    If you find out it is the SQL logs for the SCSM DB check the recovery model. To check this do the following:

    From within SQL Management Studio right click on the SCSM DB>>Properties>>Options>>Recovery model

    You will want the recovery model to be set to simple. When it is set to full I have seen the SQL logs eat up drive space. After changing the recovery mode to simple restart the server with your SQL instance should shrink the log size giving you space back. This also should keep it from growing out of control after that.


    My Blog | www.buchatech.com | www.systemcenterportal.com
    If you found this post helpful, please give it a "Helpful" vote. If it answered your question, remember to mark it as an "Answer". This posting is provided "AS IS" with no warranties and confers no rights! Always test ANY suggestion in a test environment before implementing!

    Monday, September 21, 2015 4:22 AM
    Moderator
  • Hi,

    take a look at this article, it gives a good overview of the possible causes and approaches on solving this:

    Case of the fast growing SCOM datawarehouse db and logs
    http://www.bictt.com/blogs/bictt.php/2014/10/10/case-of-the-fast-growing

    Hope this helps.

    Regards,


    Stoyan (Please take a moment to "Vote as Helpful" and/or "Mark as Answer" where applicable. This helps the community, keeps the forums tidy, and recognizes useful contributions. Thanks!)

    Thursday, September 3, 2015 11:11 AM

All replies

  • The top 3 biggest tables to check are dbo.JobStatus, dbo.BlobStorage, and dbo.EntityChangeLog.

    If the Job Status table has grown to excessive proportions, than you can use this link to change up how long the job status histories are kept: http://blogs.technet.com/b/servicemanager/archive/2010/12/07/more-aggressively-grooming-the-jobstatus-and-windowsworkflowtaskjobstatus-tables.aspx

    The Blob Storage table is all your file attachments and those can managed through training or altering your data retention settings.

    Wednesday, September 2, 2015 4:28 PM
  • Hi,

    Moreover, You could shrink your data and logs via SQL Server Management Studio to reclaim the space.


    Please remember to mark the replies as answers if they help and unmark them if they provide no help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Thursday, September 3, 2015 10:58 AM
    Moderator
  • Hi,

    take a look at this article, it gives a good overview of the possible causes and approaches on solving this:

    Case of the fast growing SCOM datawarehouse db and logs
    http://www.bictt.com/blogs/bictt.php/2014/10/10/case-of-the-fast-growing

    Hope this helps.

    Regards,


    Stoyan (Please take a moment to "Vote as Helpful" and/or "Mark as Answer" where applicable. This helps the community, keeps the forums tidy, and recognizes useful contributions. Thanks!)

    Thursday, September 3, 2015 11:11 AM
  • I have an issue with our SCSM SQL Database growth and don't know where to start looking. This seems to have started after I updated SCSM to UR5. So what happens is I'll add 100 Gigs to my SQL Server where the SCSM DB resides and within a couple weeks I'm out of disk space. Anyone know what is causing this.

    Hi,

    There are all good answers on this thread. I have seen an issue similar to this several times. It turned out to be the SQL logs that were eating up drive space. I would first check your drive with something like WinDirStat to see if it is the DB data files or the log files that are using up all the space. Here is a link to the free WinDirStat utility: https://windirstat.info/

    If you find out it is the SQL logs for the SCSM DB check the recovery model. To check this do the following:

    From within SQL Management Studio right click on the SCSM DB>>Properties>>Options>>Recovery model

    You will want the recovery model to be set to simple. When it is set to full I have seen the SQL logs eat up drive space. After changing the recovery mode to simple restart the server with your SQL instance should shrink the log size giving you space back. This also should keep it from growing out of control after that.


    My Blog | www.buchatech.com | www.systemcenterportal.com
    If you found this post helpful, please give it a "Helpful" vote. If it answered your question, remember to mark it as an "Answer". This posting is provided "AS IS" with no warranties and confers no rights! Always test ANY suggestion in a test environment before implementing!

    Monday, September 21, 2015 4:22 AM
    Moderator