Skip to main content
Ongoing Syteca database management covers three operational concerns. Reclaiming space through Archive and Cleanup operations. Tidying the database when Clients are removed and their sessions remain behind. Keeping PostgreSQL databases performing well through automatic vacuuming. This page documents the parameters and procedures for each.
NOT AVAILABLE IN SAAS. Database management is on the on-premises Syteca database. In SaaS deployments, the Syteca vendor manages the database including all Archive and Cleanup operations, deleted-Client tidying, and PostgreSQL maintenance.

​
Archive and Cleanup parameters

Archive and Cleanup operations move older session data out of the primary Syteca database. The Cleanup operation removes it entirely; the Archive and Cleanup operation moves it to a separate archived database first, then removes it from the primary database. Both operations share a set of parameters configured on the Configuration page.

​
Where to configure

  1. Click the Configuration button at the top of the Management Tool interface.
  2. On the Configuration page, select the Database Management tab.
  3. Scroll to the Archive Parameters section.
Archive Parameters section of the Database Management tab

Archive Parameters section. Configures both Cleanup and Archive & Cleanup operations from a single place.

​
Parameters applied to Archive & Cleanup for both PostgreSQL and MS SQL Server

These parameters are needed when the Archive & Cleanup operation is used. They point Syteca at the archive destination.

​
Parameters applied only to Archive & Cleanup on MS SQL Server

​
Parameters applied to both Cleanup and Archive & Cleanup

If binary storage uses Amazon S3-like storage, see Configure Syteca to Store Binary Data in Amazon S3 for the specific bucket, access key ID, and secret access key configuration.

​
Clean up sessions of deleted Clients

When a Client is deleted from the Management Tool, most of its data leaves with it. In certain edge cases the Client’s sessions can remain in the database as orphaned records. Use the Server Tray application on the Application Server computer to clean up these leftovers.
1

Open Database Parameters from the Server Tray

On the Application Server computer, right-click the Syteca Server tray icon in the Notification area and select Database Parameters.The Database Parameters application (DbSetupToolUI) opens.
2

Open the Advanced tab

In the Database Parameters application, select the Advanced tab.
3

Start the cleanup

Click Clean up lost sessions. The cleanup runs against the Syteca database and removes orphaned session records from deleted Clients.
The cleanup can take a long time for large databases. Progress is visible in the Management Tool, on the Tasks List tab of the System Health page. Verify completion there before assuming the operation is done.

​
PostgreSQL autovacuuming

PostgreSQL requires periodic maintenance called vacuuming. Vacuuming reclaims storage used by rows that are no longer visible to any transaction, and updates statistics the query planner relies on. Without vacuuming, PostgreSQL databases slowly bloat and query performance degrades. The Autovacuum Daemon is a set of PostgreSQL processes that vacuum the database automatically based on activity thresholds. It is enabled in the default PostgreSQL configuration and, in most Syteca deployments, requires no intervention.

​
When to change autovacuum settings

Adjust autovacuum settings when the Application Server writes are heavy and default autovacuum tuning is not keeping up with the churn. Symptoms include:
  1. Growing database size that outpaces retention-based expectations.
  2. Slowing query performance as tables accumulate dead rows.
  3. Autovacuum log entries indicating the daemon is running frequently and taking a long time to complete.

​
How to change autovacuum settings

Autovacuum settings live in the PostgreSQL configuration file postgresql.conf. The location of postgresql.conf varies by operating system and PostgreSQL install method. Common locations:
1

Locate postgresql.conf on the database host

Find the postgresql.conf file on the database server. Use the platform-specific paths above as a starting point.
2

Edit the autovacuum settings

Open postgresql.conf in a text editor with administrator or root permissions. Search for the settings beginning with autovacuum_ and adjust them according to the PostgreSQL documentation on the autovacuum daemon.
3

Restart the PostgreSQL database

Restart the PostgreSQL database service for the changes to take effect. Configuration changes to postgresql.conf are read at PostgreSQL start.
Restarting the PostgreSQL database disconnects the Syteca Application Server briefly. Plan the restart during a maintenance window when active Client recording can be paused, or accept a brief interruption to Session data ingest while the database service restarts.

​
Recreate the ActivityDB database and attach it as an archived database

NOT AVAILABLE IN SAAS.
1

Log in to the Application Server computer

Log in to the machine where Syteca Application Server is installed.
2

Stop the Application Server

Stop the EkranServer service.
3

Restart the database service

Restart your database service to close all existing connections to it.
4

Rename the existing ActivityDB database

In SQL Server Management Studio, expand Databases, right-click EkranActivityDB, select Rename, and enter a new name.
5

Restart the database service again

Restart the database service now that the rename is complete.
6

Start the Application Server

Start the EkranServer service. Since the original EkranActivityDB was renamed, Syteca creates a new, empty EkranActivityDB under the original name.
7

Connect the renamed database as an archived database

Log in to the Management Tool, open Configuration > Database Management, and connect the renamed database as an archived investigated database. See Archived Sessions for how archived databases are viewed afterward.

​
Vacuum the PostgreSQL database manually

NOT AVAILABLE IN SAAS.
1

Log in to pgAdmin

Open pgAdmin and connect to the PostgreSQL server.
2

Stop the Application Server

Stop the EkranServer service in Windows Services.
3

Run a full vacuum

Right-click EkranActivityDB, select Maintenance > Vacuum > Full, and click OK.
4

Restart the Application Server

Once the vacuum completes, restart the EkranServer service.
For recurring maintenance instead of a one-time manual vacuum, see PostgreSQL autovacuuming.

​
How long do cleanup operations take?

Cleanup and Archive & Cleanup duration depends on how many sessions are in the database, their size, and where the archive instance is located. As a rough estimate: archiving a session whose screen captures are stored in the database takes 3 to 6 minutes; a session whose screen captures are stored in a shared folder takes under a minute.
IN SAAS ONLY: only the Cleanup operation is available — Archive & Cleanup isn’t offered in SaaS.

​
Upgrade from an older MS SQL Server version

NOT AVAILABLE IN SAAS.
To move a Syteca database from an older MS SQL Server version (for example 2008 R2) to a newer one, back it up on the old server and restore it on the new one using SQL Server Management Studio (SSMS). This procedure applies to any older-to-newer MS SQL Server version transfer.
1

Connect to the source server

In SSMS, click Connect > Database Engine, and enter the credentials for the source MS SQL Server.
2

Back up the database

In Object Explorer, right-click the required database (for example SERVER.EkranManagementDatabase), select Tasks > Back Up.
3

Set the backup location

Click Add, then the … button, choose a location and file name, and click OK.
Note the backup location — you’ll need it in a later step.
4

Connect to the destination server

Connect to the destination MS SQL Server the same way as in step 1.
5

Create a new database with the same name

Right-click Databases, select New Database, and enter the exact same database name as the one backed up.
6

Restore from the backup

Right-click the new database, select Tasks > Restore > Database. Under Source, select Device, click the … button, Add, and select the backup file.
7

Relocate the database files

On the Files page of the restore dialog, select Relocate all files to folder.
8

Allow overwriting

On the Options page, select Overwrite the existing database (WITH REPLACE).
9

Complete the restore

Click OK. A confirmation message appears once the restore succeeds.
SSMS restore dialog Files page with Relocate all files to folder selected

Relocating database files during restore in SQL Server Management Studio.

​
Shrink the MS SQL database transaction log

NOT AVAILABLE IN SAAS.
1

Open Database Management

Log in to the Management Tool as a user with the administrative Database Management permission, click Configuration, then select the Database Management tab.
2

Shrink the log

Click Shrink Transaction Log at the bottom of the page.
No progress indicator is shown, and there’s no notification when shrinking completes.
Not supported if the MS SQL database is part of an SQL availability group — the System Health page explains why in that case. Shrinking also can’t run while a database cleanup is already in progress.

​
Set up hash-code calculation for monitoring data validation

NOT AVAILABLE IN SAAS. Contact your Syteca vendor or the Syteca Support team to enable this in a SaaS environment.
This enables the hash-code option described in Validate monitoring data integrity above — a lighter-weight alternative to certificate signing.
1

Stop the Application Server

Right-click the Syteca Server tray icon and select Stop, or stop the EkranServer service via Task Manager.
2

Add the key to the config file

Open EkranServer.Settings.config (by default in C:\Program Files\Ekran System\Ekran System\Server) and add:
3

Start the Application Server

Start the EkranServer service again.

​
Set up certificate signing for monitoring data validation

NOT AVAILABLE IN SAAS. Contact your Syteca vendor or the Syteca Support team to enable this in a SaaS environment.
This completes the certificate-signing option described in Validate monitoring data integrity above. Do the following on the Application Server computer.

​
1. Import a trusted certificate

1

Open the Certificates snap-in

Press Windows+R, enter mmc, press Enter, and click Yes on the User Account Control prompt. Select File > Add/Remove Snap-in, choose Certificates, and click Add.
2

Target the local computer account

Select Computer account, click Next, select Local computer: (the computer this console is running on), and click Finish, then OK.
3

Import the certificate

Under Certificates (Local Computer), right-click Personal, select All Tasks > Import, and step through the Certificate Import Wizard: browse to the certificate file, enter its private key password if prompted, and finish the wizard.
4

Copy the certificate's thumbprint

Under Certificates (Local Computer) > Personal > Certificates, double-click the imported certificate, select Details > Thumbprint, and copy the value shown.

​
2. Enable signing with the certificate

1

Stop the Application Server

Right-click the Syteca Server tray icon and select Stop, or stop the EkranServer service via Task Manager.
2

Add the key to the config file

Open EkranServer.Settings.config (by default in C:\Program Files\Ekran System\Ekran System\Server) and add:
3

Start the Application Server

Start the EkranServer service again.

​
Delete the PostgreSQL database manually

NOT AVAILABLE IN SAAS.
If the PostgreSQL database wasn’t removed automatically when the Application Server was uninstalled, delete it manually. Only the database owner or a superuser can do this.
Deleting a database can’t be undone.
1

Restart the PostgreSQL server

Restart the PostgreSQL server before deleting the database.
2

Open pgAdmin

Start pgAdmin and connect to the server.
3

Select the databases to delete

In the Browser pane, select the database to delete. By default, Syteca uses two databases:
  • ekranactivitydb
  • ekranmanagementdatabase
4

Delete each database

Right-click each database and select Delete/Drop, then click OK to confirm.

​
Validate monitoring data integrity

NOT AVAILABLE IN SAAS. Contact your Syteca vendor or the Syteca Support team to enable this in a SaaS environment.
Monitoring data validation confirms that screen captures and metadata received from Windows Clients haven’t been altered in the database. It’s available for both PostgreSQL and MS SQL Server. Two validation types are available:
  • Calculate hash codes — a hash is calculated for each screen capture and metadata record received.
  • Sign with a certificate — each screen capture and metadata record is signed with a trusted certificate.
If both are enabled, only certificate signing is actually used.
Enabling validation, or changing the validation type, invalidates every previously recorded Windows Client session.
Once enabled, opening a Windows Client session in the Session Player checks the integrity of its data. If any screen captures or metadata records were deleted or modified, the Session Player displays “Session data is not valid!”
Enabling validation increases CPU usage while viewing sessions in the Session Player. Screen captures won’t display for existing sessions that hadn’t been viewed before validation was enabled.

​
Isolate the database from Clients

NOT AVAILABLE IN SAAS.
Isolation mode temporarily disconnects every Client from the database, useful when fixing database issues, running cleanup, or performing maintenance. While isolated, Clients keep monitoring and write data to their local cache until reconnected.
Only available to users of the built-in default tenant with the administrative Tenant Management and System Configuration permission — for example, members of the Administrators user group.
1

Open System Health

Click System Health, then the drop-down next to the System State tab.
2

Enable isolation

Select Isolate Database from Clients.
While enabled, every Client operates offline and writes to its local cache. Data flows to the Application Server automatically as soon as isolation is disabled.
1

Open System Health

Click System Health, then the drop-down next to the System State tab.
2

Disable isolation

Select Stop Isolating Database from Clients (or click the here link in the notification banner shown at the top of every page while isolation is active).
After a long isolation period, disabling it causes a network load spike as every Client sends its accumulated offline data at once.

Application Server troubleshooting

Diagnose Application Server issues, including database connection loss and Management Tool availability errors.

Application Server resource monitoring

Watch the database write queue and storage usage in real time from the System State page.

System requirements

Database sizing, supported PostgreSQL and MS SQL versions, and network port requirements.

Shared storage HA

Move screen captures out of the database to shared storage, reducing database growth substantially.