This article describes the limitations you should consider when working with ApexSQL Audit.
The maximum number of audited distributed instances
There is no specific limit on the number of auditing instances (remote SQL Servers) that may be audited. The maximum number depends on your environment, the number of transactions executed against audited servers/databases and network bandwidth. The more distributed instances, the more likely it may be for you to encounter performance problems, as a large number of packages transferred through your network can cause bottlenecks.
There is no general recommendation and the solution to performance problems caused by too many audited instances audited depends on your specific environment. You should consider an additional ApexSQL Audit central instance that can take off some of the network load to other segments of your network.
The maximum size of the Central Database Repository (CDR)
The size of the ApexSQLCrd database used as a central data repository, is limited only by the available space on your hard disk. The ApexSQLCrd database files are created in the default database locations specified for the SQL Server instance where the ApexSQL Audit central instance is installed.
If there’s no more available space on your default drive, you can manually move the database files to a different one.
The maximum size of the ApexSQLCrd online transaction log
The ApexSQLCrd database is in the Full recovery model by default. If left unattended, the online transaction log can increase in size rapidly and consume all available space on its drive. This may also affect ApexSQL Audit performance.
To avoid this, either schedule the creation of transaction log backups, or switch to the Simple recovery model.