The ePO database size can grow significantly over time for several reasons, such as the following:

• Virus outbreaks
• False positives
• Update errors
• Upgrade

If the ePO database grows too large, ePO may become unusable or unstable until you take the appropriate actions to reduce it.

Eventually, the ePO database can grow to the maximum limit defined in SQL. Or, the database can fill the entire hard-drive, which results in the following error in the orion.log:

'PRIMARY' filegroup is full

If the ePO database runs on an SQL Express instance
SQL Express has a hard-coded maximum database size of 10 GB. If you reach this limit, the database can't grow any further, even if you have space available on the storage device that hosts it.

You can address this issue in one of the following ways:

• Create space in the database by deleting old events. For details, see KB68961 - How to find the top 10 threat events and purge events.
• Move the database to a full instance of SQL, which doesn't have the 10-GB limit, and allow the database to grow as needed. For details, see KB68427 - Recommended procedure to migrate or move an ePolicy Orchestrator database to a new SQL Server.

If the ePO database runs on a full instance of SQL
The following are the most common causes of database full errors:

• The hard disk or storage device hosting the database files is full.
  Either of the following approaches address the issue:
  • Make space available by deleting or moving other files on the same device.
  • Move the database files to another storage device that has space available.

• The database has reached its defined maximum size, as set in the properties for the database.
  Either of the following approaches address the issue:
  • Create space in the database by deleting old events. For details, see KB68961 - How to find the top 10 threat events and purge events.
  • Allow the database to grow by increasing the maximum size of the database files. 
     
• The transaction log has run out of space.
  Address the issue as follows:

1. Truncate the transaction log.
2. Use the Simple recovery model for your database. The Simple recovery model allows SQL to manage the transaction log for you, which avoids future transaction log growth.