Databases and schema upgrade

YTCC keeps its data in several PostgreSQL databases. When you install a new YTCC version, the databases have to be brought up to the version of the programs. YTCC never does this when a program connects to a database; the setup program and the home page do it, each with a backup first.

The databases

Database	Name in the line v15	Holds
Registry	scada_v15_registry	The list of projects and their databases
Project database	scada_v15_proj_<project>	Drivers, devices, signals, alarms, areas and zones of one project
History database	scada_v15_hist_<project>	Archived values and alarm records of one project

Each version line has its own prefix, for example scada_v16_ for the line 1.6. Names longer than 63 characters are shortened with a short code at the end. An early installation from before version lines uses the names without a prefix, for example scada_registry and scada_proj_<project>.

Before you begin

• Back up the projects on the home page; see Backup and restore. A schema upgrade cannot be undone.

Steps

1. Upgrade with the setup program

The setup program of a later version upgrades the registry and every project when it upgrades YTCC, while YTCC is stopped. Each project is backed up first, to data\backups\yukseltme-<time>\ in the installation folder, and its database is upgraded only if the backup was taken. See Upgrade with the setup program.

2. Upgrade a project on the home page

A project that the setup program did not upgrade, or a project imported from an older backup, shows Upgrade needed in the project list of the home page. Stop it if it runs, right-click it, choose Upgrade… and confirm with Back up and upgrade. YTCC takes a full backup first and upgrades the database only if the backup was taken; the result names the old and the new schema and the backup. See Upgrade a project from the home page.

Result

The registry and the project databases have the schema of the installed programs, and the project list shows no Upgrade needed.

History databases

The upgrade does not change history databases. The history writer upgrades a history database itself when the change is compatible. If the history database belongs to a different major version, the history writer stops and is not restarted; use the YTCC version that wrote that history.

When a database does not match the programs

A program that connects to a database with a different schema version refuses to work with it:

• If the database is older, upgrade it with Upgrade… on the home page.
• If the database is newer than the program, a newer YTCC version has already upgraded it. Update YTCC to that version or a newer one.

The project list shows Upgrade needed for an older project database and Newer version for a newer one. In the configuration editor this appears as Project database is incompatible with this version. When you start a project with an old database on the home page, its drivers do not start and the Upgrade …? window opens directly; for a newer database the home page shows a notice that asks you to install the YTCC version that saved the project, or a newer one.

Connections to PostgreSQL

Every YTCC process keeps one small pool of connections per database and opens connections only when it needs them. A driver uses at most 2 connections per pool and closes them after 5 seconds without use; services such as the process manager, the live data server, the project bridge and the alarm service use at most 6 and close them after 60 seconds. A process that waits more than 10 seconds for a connection reports the real reason in its log, for example that PostgreSQL has no free connection.

The PostgreSQL connections card on the Processes tab shows the connections in use against the limit of the server and the applications that hold the most; YTCC processes appear as ytcc:<program>, drivers also with the driver key, for example ytcc:driver-iec101:iec101_01. See Logs and diagnostics.

When a project starts, the process manager estimates how many connections its processes may use at most and compares it with the free connections of the server. If the limit could be reached, it logs a warning; the project still starts. The connection limit is max_connections in postgresql.conf of the PostgreSQL server, 100 by default. Raise it there, or lower the pool size of the YTCC processes; both are settings for the support of the installation (see scada-manager commands).

Good to know

• On the command line, scada-manager migrate --registry and scada-manager migrate <project> upgrade the same databases; see scada-manager commands. Use them only when support asks you to.