Pharos Transaction log in SQL has grown very large. The default size is 30MB to start but may grow and shrink as needed based on the Database configuration.

Overview

Use this article when the Pharos SQL transaction log file pharos_log.ldf) grows unexpectedly large or when transaction-heavy areas such as Administrator or My Print Center show timeout symptoms. In most environments, this is a SQL Server maintenance issue related to recovery model, transaction log backup cadence, or abnormal transaction volume, not a Pharos setting by itself.

Applies to

• Uniprint Suite

• Microsoft SQL Server hosting the Pharos database

• Principal Server environments where the pharos database transaction log is consuming excessive disk space or related transaction views are timing out

Symptoms

• pharos_log.ldf grows much larger than expected and consumes significant disk space.

• Transaction views such as Administrator or My Print Center may return timeout errors or load very slowly when database performance is affected.

• SQL Server may continue growing the transaction log if transaction log backups are not occurring as expected.

Cause

A large Pharos transaction log is usually caused by SQL Server transaction log maintenance rather than by the Pharos application itself. Common causes include:

1. Full recovery mode without regular transaction log backups.

2. SQL Server Agent or the backup process not running as expected.

3. High transaction activity or other database performance issues, where log growth is only one part of the overall problem.

Resolution

1. Confirm the SQL maintenance strategy with the customer or DBA.

   1. Check whether the Pharos database uses Simple or Full recovery mode.

   2. If Full recovery is in use, confirm that transaction log backups are scheduled and completing successfully.

   3. Verify that SQL Server Agent is set to Automatic and running if the environment depends on SQL Agent jobs for Pharos-related backups.

   4. Review current autogrowth settings and available disk capacity for the SQL volumes.

2. If the log file is already oversized and an outage window is approved, perform emergency remediation.

   1. Stop all Pharos services that connect to the database, starting with the Pharos License Server Service, and close any Pharos Reports sessions.

   2. Detach the pharos database.

   3. Locate the SQL data files and confirm pharos_data.mdf and pharos_log.ldf are present.

   4. Remove the oversized pharos_log.ldf file only as an emergency recovery step and only with DBA approval.

   5. Reattach the database by using pharos_data.mdf, then restart Pharos services, starting with License and Database Services.

3. Validate after the recovery step.

   1. Confirm the new log file is created and review its growth settings.

   2. Re-test the original workflow that showed the issue, such as transaction views in Administrator or My Print Center.

   3. If timeouts or slowness continue, continue database troubleshooting. Review transaction volume, fragmentation, workload patterns, and other database-side causes. Do not assume log reset alone has resolved the root issue.

Notes

• The log reset procedure can reduce file size quickly, but recent support history shows it does not always resolve transaction timeout issues by itself.

• If the customer requires point-in-time SQL recovery, coordinate with their DBA before changing recovery behavior or removing the transaction log file.

• If the environment continues to have performance issues after log cleanup, gather database and Pharos logs and investigate broader SQL performance or transaction load causes.