Dynamic configuration

AVEVA Historian supports dynamic configuration. That means you can reconfiguration of tags and other objects in the Historian database while the system is running. The Historian automatically detects and applies the modifications to its internal run-time state without requiring the system to be restarted. In addition, clients do not experience interruptions due to configuration changes.

The dynamic configuration feature in the Historian caters for all possible database modifications that affect the run-time operation of the system. The Configuration subsystem is designed to ensure that no loss of data occurs for tags that are not affected by the modifications being applied. However, tags that require a change in data acquisition configuration will obviously lose data during the reconfiguration.

In most cases, the system continues to run uninterrupted. In the following cases, a restart of the system is required:

• When you change the main historization path in the system, a parameter that is rarely modified after installation.

• When you modify the DataImportPath system parameter.

For a description of the effect of various types of modifications made while the system is running, see Effects of configuration changes on the system.

Dynamic configuration is usually a two-step process:

1. Add, modify, or delete one or more objects in the database, using the Operations Control Management Console, Transact-SQL statements, or the database modification tool of your choice.

   As soon as you make a change, the Runtime database is updated to reflect the change. For example, when you add an analog tag using the wizard within the Configuration Editor, the database is updated as soon as you click Finish.

2. After making all of the modifications, you must commit the changes, which triggers the dynamic configuration process in the server. Modifications made to the system are done in a transactional fashion.

   The database modifications are not reflected in the running system until you commit the changes. You are committing changes to the system, not to the database.

You can commit changes to the configuration of the system as often as you want. You can also commit changes in batches or individually. There is no limit on the number of changes that may be committed to the system. Configuration changes typically take effect within 10 seconds under maximum data throughput conditions.

For information on cases in which a commit is prevented, see Cases in which configuration changes are not committed.