Download NA-0500-0025 - Automation Solutions

Knowledge Base Article
Database Server Performance Best Practices Guide
Article ID:
Publish Date:
Article Status:
Article Type:
Required Action:
NA-0500-0025
14 Dec 2016
Approved
General Product Technical Information
Information Only
Recent Article Revision History:
Revision/Publish
Description of Revision
Reviewed and determined applicable for v13.3 and v13.3.1
14 Dec 2016
(See end of article for a complete revision history listing.)
Affected Products:
Product Line
DeltaV
Category
Workstation Software
Device
VE210x DeltaV Workstation
Version
v7.x, v8.x,
v9.3.x,
v10.3.x,
v11.3.x,
v12.3.x,
v13.3.x
I.
General Database Server Performance Information
II.
ProfessionalPLUS Database Server Setup Recommendations
III.
Network Setup Recommendations
IV.
Database Server Maintenance Recommendations
V.
Configuration Best Practices
VI.
Engineering Tool Configuration Guidelines
I.
General Database Server Performance Information
This Knowledge Base Article, NA-0500-0025, discusses how the database server processes requests and also offers
general guidelines for improving overall database server performance in a concurrent engineering environment.
The database server resides on the ProfessionalPLUS workstation and services all updates to the Objectivity database.
The database server process (DVDBServer.exe) also performs a number of tasks in addition to processing client requests
to save configuration data. These tasks include updating node and download status; performing daily exports of the
configuration data; updating DeltaV Explorer client sessions to reflect configuration changes; providing object browsers
with parameter path information; and supplying DeltaV Diagnostics with system data.
It is important to understand some fundamental aspects of how the database server works in order to better improve
overall server performance. The term exclusive access in this document pertains to the requirement that the database
server must lock the database files in order to perform a specific task. When exclusive access is required by the database
server, no other write activities can be done while the request is being processed. The following activities require
exclusive access by the database server:
1. Downloads
A single download requires exclusive access to the database during two phases: in the first one, it is required to generate
the Download script, which ensures that the configuration data does not change between the time the download is
initiated by the user and the time when the script is completely generated for the target node. The second lock is
required once the script has been communicated to the target node and the server must update the Download Status
for the system. The combination of these two requirements makes a download expensive from a database server
performance perspective.
2. Save Operations
When configuration changes are applied or saved to the database, exclusive access is needed to ensure that appropriate
updates can be made to the system. The amount of time that a save operation requires is dependent upon the overall
size and complexity of the object. Additionally, the number of objects that reference the update also play a significant
role in determining how much activity the database server must perform under the hood .
The number of references that an object has can be checked via DeltaV Explorer or Control Studio. The Direction column
will contain the text “Is used by” to indicate that other database objects reference the particular object. Linked
composites are a good example of database objects that typically have a large number of references. Making a simple
change to a linked composite could require updating hundreds of objects in order to properly propagate the
configuration change.
Knowing how long a particular configuration change will take can aid engineers in coordinating their work on the
system.
3. Update Download Status
As mentioned in the Downloads topic, updating Download Status requires exclusive access to the database. This activity
can be performed independent of a download. The time required to perform this activity is directly proportional to the
number of nodes on the DeltaV network.
Recognizing that these actions require exclusive database access require engineers working concurrently on the DeltaV
system to coordinate their activities. A number of the Configuration Best Practices discussed in Section V are derived
from these fundamentals. In addition to the concept of exclusive access, there are a number of activities which require a
large amount of work by the database server. The exclusive access requirement does not cause performance issues, but
what does cause them is the amount of overhead generated for the database server when they are performed . The
Configuration Best Practices and Engineering Tool Configuration Guidelines sections of this article discuss these items in
detail.
II.
ProfessionalPLUS Database Server Setup Recommendations
Perform the setup recommendations in the following list on the ProfessionalPLUS workstation to maximize database
server performance:

Install the fastest CPUs available in the server.

Maximize the physical RAM on the server up to 4 GB. MS Server 2003 supports a maximum of 4 GB of physical
RAM.

Configure Windows Advanced System Settings for best performance (System Properties – Advanced Tab –
Settings button under performance – Visual Effects Tab – Adjust for best performance).

Configure Performance Memory Usage setting to System Cache (System Properties – Advanced Tab – Settings
button under performance – Advanced Tab).

Create a page file equal to 1.5 times the amount of physical memory.

When configuring the page file, set the minimum and maximum values to the same number ( e.g., min. 1500 MB,
max. 1500 MB).

Configure Performance Processor Scheduling setting to Background Services (System Properties – Advanced Tab
– Settings button under performance – Advanced Tab).

Ensure at least 500 MB of free disk space on all drive partitions.

Configure virus protection software to exclude database folder if ‘File System Real-time Protection’ is
implemented.

Verify proper binding order of NICs on the ProfessionalPLUS workstation.

Implement Hardware RAID5 or RAID10 for best disk I/O performance. The operating system views a RAID5 or
RAID10 setup as one disk and the controller handles caching and distributing data among individual disks within
the RAID array.

If you are not implementing RAID, create the page file on a dedicated partition and physi cal disk if possible.

If possible, choose another workstation for Alarms and Events collection.

If possible, use another workstation for Remote Terminal Server sessions and Historical Data collection. We do
not recommend using Remote Terminal Server on a ProfessionalPlus configured as the Domain Controller.

Do not install unsupported 3rd party applications or unnecessary software on the ProfessionalPLUS workstation.

Ensure that the latest workstation software updates are installed on the workstation. Refer to the Software
Updates KBA relevant to the DeltaV version being used.
III.
Network Setup Recommendations
Check the items on the following list to verify that the network is set up properly. Network issues can contribute to slow
database server performance if clients continuously have to retry communications. Database corruption and loss of
configuration changes can also occur if clients are prematurely disconnected from the database server due to network
problems.

Use Diagnostics to confirm good Primary and Secondary communications on all DeltaV nodes.

Verify the grounding of all network equipment.

Verify Emerson-supported configuration of network switches.

Verifying the proper shielding of network cables.

Ensure that Ethernet switch ports are configured to Auto-negotiate (or half duplex, when applicable) for
connections to MD controllers. Auto-negotiate is the standard setting for the switch ports when they are
shipped by Emerson. Half duplex setting is only applicable on special cases, such as when there is a media
converter in between a switch and a half duplex Controller (i.e. DeltaV controllers on v7.x and earlier).

Ensure that the Primary DNS Server setting on all nodes is set to ProfessionalPLUS.

Ensure that all DeltaV nodes are set up with redundant communications. Avoid having only one network
connection present on nodes configured as redundant in the database.

Ensure proper binding order of the NICs on all DeltaV workstations.

Review the Event Journal for ACN Switchover messages.

Monitor DeltaV controller communication parameters Errors Received (ER), CRC Errors (CrcER), and Carrier Lost
Errors (CaLET).

Configure reverse lookup zones in the DNS servers. Reference KBA AP-0400-0013: Slow Connection of Process
History View to a Remote Pi Server Node in Windows 2003/XP for details.

Reference KBA NA-0500-0028: Tips for Network Design of a DeltaV Area Control Network for additional network
recommendations.
IV.
Database Server Maintenance Recommendations
Implement the following recommendations to maintain optimal performance of the database server. Database server
performance can suffer drastically if the database files or the hard drive containing the files becomes heavily
fragmented..

Perform database cleans as necessary. The frequency depends on the amount and type of configuration work
being done. When heavy concurrent engineering is being performed, the database should be cleaned at a
minimum of two times per day. Scheduling a clean in the morning and at lunch time is one way to accommodate
this requirement. If your schedule can not accommodate two daily database cleans, we recommend performing
the clean daily in the mornings, assuming that a majority of the configuration work is being done during the day.
If database performance degradation is still being observed even with two daily cleans, additional database
cleans should be performed. By scheduling multiple cleans per day, the amount of time required to complete
each clean will be minimized because there is less work to be done at each interval. Another performance factor
to consider is that objects which are modified multiple times will become more fragmented than objects that
have yet to be modified. Furthermore, an object that has been saved several times may exhibit additional
performance degradation. If multiple configuration changes need to be made to the same object, using Control
Studio to make these changes and saving only once will reduce the total amount of fragmentation instead of
opening the object several times and making a single configuration change each time.
There are two types of database clean operations supported in Del taV – Standard and Extended Clean.
o
The Standard Clean operation runs both the ooclean and ootidy routines. The ooclean command cleans
up leftover transactions (journal files) that are no longer valid on the database , while the ootidy
command performs the equivalent of a disk defragment on the database files.
o
The Extended Clean performs the same activities as a Standard Clean except an additional ‘garbage
collection’ routine is run to delete objects that are no longer referenced in the database . We always
recommend the Extended Clean during heavy concurrent engineering.
In addition to the Objectivity database cleaning operations, when a database clean has finished the DeltaV
database server process (DvDbServer.exe) is restarted, which releases and re-acquires operating system
resources, helping to improve overall performance of the ProPlus.

V.
At a minimum, perform a weekly defragmentation of the hard drive or partition that contains the database. A
disk partition that is heavily fragmented can create additional performance degradation when the system needs
to read or write to the disk. Microsoft XP and Server 2003 have a built-in utility called Disk Defragmenter that
analyses and defragments disk partitions. In some cases, defragmenting the drive partition may be required
more often than the general weekly recommendation. By analyzing the partition with the database, the utility
will display fragmentation numbers and recommend a defragmentation if ne cessary. The analyze routine should
be performed daily to make sure excessive file fragmentation does not exist.
Configuration Best Practices
The following configuration best practices should improve overall database server performance .
Note These procedures are not mandatory, but they help identify which activities can create a large
amount of overhead for the database server process. It is difficult to employ all of these recommendations
in a concurrent engineering environment, however, knowing which activities require exclusive access or a
large amount of database server resources should help coordinate configuration work.
When a recommendation states to minimize an activity, the message should not be communicated to
configuration engineers that these activities can not be performed. The goal is to inform engineers of what
activities can be costly from a database server performance perspective.

Schedule downloads to the extent possible. The feasibility of this recommendation will vary drastically for each
environment, but should be carefully considered due to the ramifications discussed in Section I.
VI.

Close DeltaV Explorer sessions when they are no longer in use. If you plan to use DeltaV Explorer for an
extended period of time, close and reopen the application every hour or so to optimize the database server ’s
cache.

Since a Save operation requires exclusive database access, it is important to understand when to use DeltaV
Explorer or Control Studio to make a configuration change. The Engineering Tool Configuration Guidelines
section of this article focuses on this topic.

Schedule imports to the extent possible. Imports require exclusive access only to the object that is being
modified; however, the search for that object creates additional overhead for the database server.

Check-in VCAT items when finished with configuration.

Verify downloads only when it is necessary. The general rule should be, if the modules that are being
downloaded can affect running process or are being downloaded to a controller running a process, enable the
verify option on the download.

When using Remote Terminal sessions, close applications prior to logging off.

Use a Development System for extensive changes that can be made offline.

Minimize the use of explicit “Update Download Status” or use only when necessary. When a download
completes, the server will automatically update download status.

Minimize the use of the DeltaV Explorer Refresh feature.

Check out an item with VCAT only if changes will be made. Use the read-only view to minimize the number of
items checked out for VCAT if changes are not needed.

Minimize the use of DeltaV Explorer’s magnify glass (diagram) view.

Avoid copying large files to or from the ProfessionalPLUS during heavy concurrent engineering (e.g., backups).

Avoid compressing large files (e.g., daily backups) during heavy concurrent engineering.

Minimize the use of DeltaV Explorer’s ‘Find’ feature. If necessary, make sure you designate which objects to
search instead of leaving the default (all objects searched).

Minimize use of the References feature in DeltaV Explorer during heavy concurrent engineering.

Minimize the use of DeltaV Operate on the ProfessionalPLUS during heavy concurrent engineering.

Enable VCAT only when necessary. In some cases, code changes can be made in the early stages of a project that
do not require revision information.

When Device Audit Trail is used on a DeltaV system, install SQL Server on an Application station rather than the
ProfessionalPLUS. In the event that both Device Audit Trail and VCAT are being used, the improvements realized
by this step will be minimal considering the SQL Server requirement for VCAT on the ProfessionalPLUS
workstation.
Engineering Tool Configuration Guidelines
This section provides general tips for implementing configuration changes, which can help optimize the database server
performance in a concurrent engineering environment. DeltaV offers flexibility in how configuration changes are
implemented. Approaching a configuration change from the correct engineering tool can improve overall database
server performance.
ENGINEERING TOOLS

DeltaV Explorer is one of the main engineering tools in DeltaV. This database client acts as a direct window into
the database so that configuration changes are applied immediately without requiring an explicit save by the
user. In the background, a save operation and corresponding exclusive lock is still being performed by the
database for each change. This functionality can work against you from a performance perspective if multiple (3
or more) configuration changes need to be made to the same object; Control Studio should be used in this
scenario to reduce the total number of save operations. If only a couple of changes need to be performed on the
same object, DeltaV Explorer should be used to optimize database server performance. In some cases, a
configuration change can only be made with a specific engineering tool, however, for the items that can be
changed by multiple tools, these subtle practices can improve overall database server performance.
DeltaV Explorer also caches information being displayed to the user. A good example of populating this cache is
expanding a tree (e.g, Plant Area) to view objects. When the tree is expanded, all of the items in the list are
added to the database server’s cache. When this happens, other clients (or the same client) can benefit from
reading this data from cache versus repeatedly retrieving the data from the database files. In current DeltaV
revisions, collapsing the tree that has been viewed will not force the database server to release these items
from cache. By closing the DeltaV Explorer session, the database server will eventually (usually within 10
minutes) release the memory associated with this cache and free up these resources. To maximize this feature,
we recommend closing and reopening DeltaV Explorer every hour or so when heavy concurrent engineering is
taking place. When the DeltaV Explorer session is re-opened, a new identifier will be assigned to the client
session, thus allowing the server to ‘flush’ the cache associated with the previous DeltaV Explorer session.

Control Studio is the probably the second most common engineering tool used in DeltaV. Control Studio is
different in that the whole object (or module) is loaded into the database server’s cache upon opening the
session. DeltaV Explorer would require viewing the object before it is cached. It is important to note that when
new items (e.g., function blocks) are added to the module, the database server must still retrieve a copy of the
object from the database files. A cached copy of all configuration items is not loaded into the client’s process
space. This limitation explains why you may get database server busy messages when trying to add additional
configuration items as a result of another client requiring exclusive access to the database.
One advantage in Control Studio is that the user has control over when a change is made to the database. If
several modifications must be made to an existing object, using Control Studio to make these changes and then
performing a single save operation can improve overall database server performance. In most cases, the initial
creation of a module must be done with Control Studio.

Recipe Studio is generally used for creating batch recipes. A majority of the configuration work for a recipe must
be done with Recipe Studio. Some exceptions to this rule would be deferring recipe parameters and creating and
editing Formulas. Recipe Studio has the same advantage as Control Studio for making multiple configuration
changes to the same object.

The I/O Configuration tool behaves similarly to DeltaV Explorer. When changes are made via this application,
they are immediately applied to the database. There is no significant performance difference between making a
change using the I/O Configuration client and DeltaV Explorer.
Complete Article Revision History:
Revision/Publish
Description of Revision
Reviewed and determined applicable for v13.3 and v13.3.1
14 Dec 2016
Added additional information on database clean and minor formatting changes
23 Mar 2015
Removed the note that the DeltaV Service should be stopped when performing disk
20 Jul 2010
defragmentation.
Added a note that the DeltaV Service should be stopped when performing disk
14 May 2010
defragmentation.
30 Mar 2009
15 Jan 2009
29 Jun 2005
Clarified the duplex setting under 'Network Setup Recommendations' section
Changed page file settings to 1.5 x RAM; added RAID10; added recommendation that
Remote Terminal server should not be installed on Proplus Domain Controller; and
changed verbiage of some sentences.
Original release of article
©Emerson Automation Solutions 2009-2017. All rights reserved. For Emerson Automation Solutions trademarks and service marks, click this link to
see trademarks. All other marks are properties of their respective owners. The contents of this publication are presented for informational p urposes
only, and while every effort has been made to ensure their accuracy, they are not to be construed as warrantees or guarantees, express or implied,
regarding the products or services described herein or their use or applicability. All sales are governed by our terms and co nditions, which are
available on request. We reserve the right to modify or improve the design or specification of such products at any time without notice.
View Emerson Products and Services: Click This Link