I. General Database Server Performance Information. Knowledge Base Article. Database Server Performance Best Practices Guide

Transcription

1 Knowledge Base Article Database Server Performance Best Practices Guide Article ID: NA Publish Date: 23 Mar 2015 Article Status: Article Type: Required Action: Approved General Product Technical Information Information Only Recent Article Revision History: Revision/Publish Description of Revision 23 Mar 2015 Added additional information on database clean and minor formatting changes (See end of article for a complete revision history listing.) Affected Products: Product Line Category Device Version DeltaV Workstation Software VE210x DeltaV Workstation v10.x DeltaV Workstation Software VE210x DeltaV Workstation v11.x DeltaV Workstation Software VE210x DeltaV Workstation v12.x DeltaV Workstation Software VE210x DeltaV Workstation v7.x DeltaV Workstation Software VE210x DeltaV Workstation v8.x DeltaV Workstation Software VE210x DeltaV Workstation v9.x I. General Database Server Performance Information II. III. IV. ProfessionalPLUS Database Server Setup Recommendations Network Setup Recommendations Database Server Maintenance Recommendations V. Configuration Best Practices VI. Engineering Tool Configuration Guidelines I. General Database Server Performance Information This Knowledge Base Article, NA , 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.

2 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:

3 III. 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 MB, max 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 3 rd 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. 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).

4 IV. 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 : Slow Connection of Process History View to a Remote Pi Server Node in Windows 2003/XP for details. Reference KBA NA : Tips for Network Design of a DeltaV Area Control Network for additional network recommendations. 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 DeltaV 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. 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

5 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 necessary. The analyze routine should be performed daily to make sure excessive file fragmentation does not exist. V. 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. 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).

6 VI. 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

7 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 23 Mar 2015 Added additional information on database clean and minor formatting changes 20 Jul 2010 Removed the note that the DeltaV Service should be stopped when performing disk defragmentation. 14 May 2010 Added a note that the DeltaV Service should be stopped when performing disk defragmentation. 30 Mar 2009 Clarified the duplex setting under 'Network Setup Recommendations' section 15 Jan 2009 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. 29 Jun 2005 Original release of article Emerson Process Management All rights reserved. For Emerson Process Management 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