Kaseya Community

SQL Express DB hit 10GB limit in 2 days

  • Hi guys

    Having a recent issue with my DB and I ran a script to show table sizes. These 2 tables are about 4GB each, which is huge and the DB filled up in 2 days.

    TableName indexName RowCounts TotalPages UsedPages DataPages TotalSpaceMB UsedSpaceMB DataSpaceMB
    ntEventLog20161004 NULL 1156511 524171 524107 524104 4095 4094 4094
    ntEventLog20161003 NULL 1092610 489002 488938 488936 3820 3819 3819

    Most of Kaseya's functionality has stopped working so I need to do a cleanup / squish before I can get back onto the system, however, I need to know what is causing this log to fill up so rapidly.

    Any idea's ?


  • What are your event log collection and retention settings?  You don't need to upload event logs to your VSA server to alert on them

  • Here is a link with more detail - community.kaseya.com/.../18333.aspx

  • Remember you dont need to collect event logs to be able to alert on them.

    So you can cut the retention to 0 and still have your monitor sets in place.

    I would do a count on agentguid on those tables and see which agents are producing the most records, and then narrow it down from there.

  • How many agents do you have? Consider buying a SQL Server license. Nothing good will come from running Kaseya on SQL Express. The limitations are profound.

  • Are you suggesting I shouldn't use an MS Access database?  :-)

  • Zippo - I can see  you holding up the "Sarcasm" sign from here! :D

  • Ha! Just having a little fun. No harm meant!  :-)

  • I think the only harm that could arise is if you hit someone with the sarcasm sign! (or used Access to back-end Kaseya!)

    I hold my sarcasm sign up often enough to recognize it when I see it. You have to have some fun or this stuff will make you nuts! :)

  • This raises an interesting point - while it's true you don't have to collect Event Logs in order to alert on them, you do have to collect them for two useful purposes - and from what I understand, if you collect anything, you have to collect everything you need for monitoring.

    The two useful purposes (which are, after all, related) are:

    1. Event Log reporting - if you want to use "Event Log" or "Event Log Frequency" reports, they will be empty unless you're actually collecting the logs to the KServer.

    2. Post-mortem analysis (this is the big one).  Say a server goes offline, dead, unbootable, time to pull the backups.  The first thing I want to know is "what was happening immediately before it died" and if I have been collecting Event Logs to the database, I at least have a shot at understanding and putting together what was going on.  Otherwise, I only have whatever's in my most recent backup - which is fine for business continuity purposes, but not so great for researching/figuring out what went wrong in the 15 minutes leading up to the crash.

  • Hi

    Everyone on here has made valid points. I would like to reiterate SMason's point, consider the amount of endpoints you are monitoring and collecting logs for. You may need to move to a full version of SQL. Also, here are the min reqs for Kaseya, one or split servers, help.kaseya.com/.../index.asp. If you expand the last point in the Contents menu you will get the min reqs by amount of machines. If you still need some help I would recommend submitting a ticket and having a performance tech evaluate your current server. They make any suggestions as to best practices in your situation.  

  • Hi all

    Apologies for the late reply on this post, but this has been resolved.

    The issue in this instance, was 2 machines with rapid error reporting in the event logs. The events were causing the DB to fill up in a matter of hours and then the system would fall over.

    https://localhost/inc/perftest.asp? was indicating that the NTEventLog table was growing extremely quickly.

    The events were being monitored as part of the original installation, but had not yet been configured to alert for particular issues. I cleaned up the tables and DB's as per instructions located in the forums which helped and tracked down the offending machines via the NTEventLog table entries.


    [edited by: Justin van Hal at 3:17 AM (GMT -8) on Nov 14, 2016]