Remote deployment

During installation, you can deploy your databases locally or remotely. You can specify a remote path for the state and configuration databases when prompted to provide a SQL Server instance name or keep the populated value, which assumes a local deployment.

By default, the state database resides on the same SQL Server instance as AVEVA Production Management, where it:

• Persists state information, such as sample stream data and Metrics Calculations Queue (MCQ) for delayed processing.

• Stores Plant2Business integration diagnostics.

• Stores conflict information for Master Data Management.

If you have a large project with a lot of stream data, we recommend to have a local state and configuration databases. Remote deployments have a reduced maximum data stream processing rate. Understanding the estimated incoming data stream rates is essential before choosing a deployment strategy.

Choose between remote versus local SQL Server deployment

The following are some things to consider when choosing a SQL Server deployment:

• If you have a local SQL Server deployment, the SQL service has a dependency on AVEVA Production Management, so if the connection to SQL Server is lost, AVEVA Production Management will also stop immediately.

  However, if you choose remote deployment, you must keep an eye on other SQL servers in case one goes down, so you can manually shutdown AVEVA Production Management. For more information on how you can manage remote database outages, refer to Guidance on managing remote database outages.

• If you have a remote SQL Server deployment:

  • You don't need SQL Server running on the AVEVA Production Management server. You can utilize other shared SQL servers or host all your databases on a single SQL Server instance and manage them centrally. This reduces the total cost of ownership since fewer SQL Server licenses are required.

  • It is recommended that the database server and the AVEVA Production Management server be physically co-located to reduce latency.

  • The network latency between the servers must be as close to zero as possible. Latency has significant impact on some operations, including:

    • Stream processing rates

    • Project upgrades and imports

    • Project saves where a large number of items have been modified

    • New project creation

  • You can no longer use the backup and restore options in Studio. You need to manually perform these tasks through SQL Server Management Studio. If you're moving the AVEVA Production Management service to a different computer and you plan to restore the configuration database backup on that same computer, you also have to copy the AuthStore.xml file from the existing project setup.

  • You have to set up web diagnostic integration logging for remote state database if you are using plant-to-business (P2B) integration logs to ensure that you don't lose logs inserted into the database between the time the state database goes offline and when it returns online.

    For detailed steps to set up diagnostics logging, refer to Enable diagnostics logging to a file in the Administrator (Studio) online help.