> ## Documentation Index
> Fetch the complete documentation index at: https://syteca.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# Database Management
> Manage the Syteca database over its lifetime. Configure Archive and Cleanup operations, clean up sessions left behind by deleted Clients, and tune PostgreSQL autovacuuming to keep the database healthy under sustained write load.
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.
### 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.
| Parameter | Purpose |
| ----------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Instance** | The path to the PostgreSQL or MS SQL Server instance that will host the archived database. |
| **Archived database name** | The name of the destination database. For MS SQL Server, if the database does not exist, it is created automatically when the Archive & Cleanup operation first runs. For PostgreSQL, the database must exist beforehand. |
| **User** and **Password** | Credentials of a user with permissions on the PostgreSQL Server or MS SQL Server instance sufficient to create tables, insert data, and (for MS SQL Server) create the archived database. |
| **Binary data location** | The path to the location where binary session data (screen captures) will be archived. Only shown when binary storage is used. When using Amazon S3-like storage, this field is replaced by **Bucket name**, **Access key ID**, and **Secret access key**. |
| **Use separate credentials to access binary storage** | Select this checkbox and provide a **User** and **Password** when the binary storage location requires separate credentials, for example a Network-Attached Storage location. Not available with Amazon S3-like storage, which uses its own key/secret. |
### Parameters applied only to Archive & Cleanup on MS SQL Server
| Parameter | Purpose |
| ------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Shrink database transaction log after cleanup** | Runs a transaction log shrink at the end of each Archive & Cleanup operation. Recommended for MS SQL Server deployments where the transaction log grows aggressively during the operation itself. |
### Parameters applied to both Cleanup and Archive & Cleanup
| Parameter | Purpose |
| ------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Archive and clean up the database without archiving and deleting the binary data** | When selected and a binary storage location is configured, screen captures are kept in binary storage even after the database side of the session is cleaned up or archived. Useful when binary storage retention policies differ from database retention policies. |
| **Delete offline Clients without sessions** | Offline Clients that have no recorded sessions are removed from the database during the cleanup process. Prevents orphaned Client records from accumulating when Clients are decommissioned before ever recording a session. |
If binary storage uses Amazon S3-like storage, see [Configure Syteca to Store Binary Data in Amazon S3](/docs/administration/database/binary-storage-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.
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.
In the Database Parameters application, select the **Advanced** tab.
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:
| Platform | Typical location |
| -------------------- | ------------------------------------------------------------ |
| **Windows** | `C:\Program Files\PostgreSQL\\data\postgresql.conf` |
| **Ubuntu / Debian** | `/etc/postgresql//main/postgresql.conf` |
| **Red Hat / CentOS** | `/var/lib/pgsql//data/postgresql.conf` |
Find the `postgresql.conf` file on the database server. Use the platform-specific paths above as a starting point.
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](https://www.postgresql.org/docs/current/routine-vacuuming.html#AUTOVACUUM).
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.**
Log in to the machine where Syteca Application Server is installed.
Stop the **EkranServer** service.
Restart your database service to close all existing connections to it.
In SQL Server Management Studio, expand **Databases**, right-click `EkranActivityDB`, select **Rename**, and enter a new name.
In pgAdmin4, check for existing connections to `EkranActivityDB`:
```sql theme={"system"}
SELECT * FROM pg_stat_activity;
```
Close any existing connections:
```sql theme={"system"}
SELECT pg_terminate_backend();
```
Replace `` with the value shown for `EkranActivityDB`. Then rename the database:
```sql theme={"system"}
ALTER DATABASE "EkranActivityDB" RENAME TO "newDBname";
```
Restart the database service now that the rename is complete.
Start the **EkranServer** service. Since the original `EkranActivityDB` was renamed, Syteca creates a new, empty `EkranActivityDB` under the original name.
Log in to the Management Tool, open **Configuration > Database Management**, and connect the renamed database as an archived investigated database. See [Archived Sessions](/docs/session-monitoring/archived-sessions) for how archived databases are viewed afterward.
## Vacuum the PostgreSQL database manually
**NOT AVAILABLE IN SAAS.**
Open pgAdmin and connect to the PostgreSQL server.
Stop the **EkranServer** service in Windows Services.
Right-click `EkranActivityDB`, select **Maintenance > Vacuum > Full**, and click **OK**.
Once the vacuum completes, restart the **EkranServer** service.
For recurring maintenance instead of a one-time manual vacuum, see [PostgreSQL autovacuuming](/docs/administration/deployment/database-management#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.
In SSMS, click **Connect > Database Engine**, and enter the credentials for the source MS SQL Server.
In **Object Explorer**, right-click the required database (for example `SERVER.EkranManagementDatabase`), select **Tasks > Back Up**.
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.
Connect to the destination MS SQL Server the same way as in step 1.
Right-click **Databases**, select **New Database**, and enter the exact same database name as the one backed up.
Right-click the new database, select **Tasks > Restore > Database**. Under **Source**, select **Device**, click the **...** button, **Add**, and select the backup file.
On the **Files** page of the restore dialog, select **Relocate all files to folder**.
On the **Options** page, select **Overwrite the existing database (WITH REPLACE)**.
Click **OK**. A confirmation message appears once the restore succeeds.
## Shrink the MS SQL database transaction log
**NOT AVAILABLE IN SAAS.**
Log in to the Management Tool as a user with the [administrative Database Management permission](/docs/administration/users/administrative-permissions), click **Configuration**, then select the **Database Management** tab.
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](#validate-monitoring-data-integrity) above — a lighter-weight alternative to certificate signing.
Right-click the **Syteca Server** tray icon and select **Stop**, or stop the **EkranServer** service via Task Manager.
Open `EkranServer.Settings.config` (by default in `C:\Program Files\Ekran System\Ekran System\Server`) and add:
```xml theme={"system"}
```
Start the **EkranServer** service again.
Right-click the **Syteca Server** tray icon and select **Stop**, or stop the **EkranServer** service via Task Manager.
Open Windows Registry Editor, select `HKEY_LOCAL_MACHINE\SOFTWARE\EkranSystem`, and add a new **DWORD (32-bit)** value named `SignMonitoredData` with data `1`.
Start the **EkranServer** service again.
After updating to version 6.53.1 or later, this setting moves from the registry to `EkranServer.Settings.config` automatically, and further changes must be made in that file.
## 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](#validate-monitoring-data-integrity) above. Do the following on the Application Server computer.
### 1. Import a trusted certificate
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**.
Select **Computer account**, click **Next**, select **Local computer: (the computer this console is running on)**, and click **Finish**, then **OK**.
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.
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
Right-click the **Syteca Server** tray icon and select **Stop**, or stop the **EkranServer** service via Task Manager.
Open `EkranServer.Settings.config` (by default in `C:\Program Files\Ekran System\Ekran System\Server`) and add:
```xml theme={"system"}
```
Start the **EkranServer** service again.
Right-click the **Syteca Server** tray icon and select **Stop**, or stop the **EkranServer** service via Task Manager.
Open Windows Registry Editor, select `HKEY_LOCAL_MACHINE\SOFTWARE\EkranSystem`, and add a new **String Value** named `SignMonitoredDataCert` with the copied Thumbprint value (no spaces) as its data.
Start the **EkranServer** service again.
After updating to version 6.53.1 or later, this setting moves from the registry to `EkranServer.Settings.config` automatically, and further changes must be made in that file.
## 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.
Restart the PostgreSQL server before deleting the database.
Start **pgAdmin** and connect to the server.
In the **Browser** pane, select the database to delete. By default, Syteca uses two databases:
* `ekranactivitydb`
* `ekranmanagementdatabase`
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](/docs/administration/users/administrative-permissions) — for example, members of the Administrators user group.
Click **System Health**, then the drop-down next to the **System State** tab.
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.
Click **System Health**, then the drop-down next to the **System State** tab.
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.
## Related
Diagnose Application Server issues, including database connection loss and Management Tool availability errors.
Watch the database write queue and storage usage in real time from the System State page.
Database sizing, supported PostgreSQL and MS SQL versions, and network port requirements.
Move screen captures out of the database to shared storage, reducing database growth substantially.