Selecting an Empower 2 Database Server

Size: px

Start display at page:

Download "Selecting an Empower 2 Database Server"

Avice Simmons
6 years ago
Views:

1 TECN Rev. 01 Page 1 of 7 The Empower 2 application uses memory on the server to store information read from and inserted into the database. This document describes important information regarding selecting a database server, platform limitations, monitoring and diagnostic information, issues observed when exceeding those limits, and potential corrective actions. Selecting a Database Server Three database server platforms are supported for Empower 2 Build 2154 software: x86 Intel servers using 32-bit Microsoft Windows 2000 Server/Advanced Server or Windows Server 2003 operating system x86 Intel servers using 64-bit Windows Server 2003 operating system (supported starting with Empower 2 Feature Release 5) Sun Microsystems SPARC (or UltraSPARC) servers with Sun Solaris 10 operating environment (supported started with Empower 2 Feature Release 1) All platforms support a wide range of Empower 2 Enterprise configurations with multiple users and analytical systems. You should select the platform appropriate to your current and future numbers of clients and systems. In all of these configurations, the clients and LAC/E 32 s run a 32-bit version of Windows desktop operating system. These include Windows 2000 Professional, Windows XP, and Windows Vista (supported starting with Feature Release 5). Determining which configuration best suits your environment depends on the number of concurrent application connections that you will have. The total number of application connections is a combination of client, LAC/E 32 modules, and chromatographic systems communicating with the Empower 2 database server. Depending on how a user logs in to the application, the number of connections into the server will vary. When a client connects, multiple connections are made to the Empower 2 server. When using the Pro Interface, the Empower 2 Login window and the Message Center start in addition to any additional applications that may be launched following login. When using the QuickStart interface, application login, QuickStart, and the Message Center start. QuickStart then handles user activity without the need for additional Empower 2 server connections. Table 1 shows the appropriate database server based on the number of anticipated connections. Due to the variable memory usage of each connection, the number of 400 is an approximate value.

2 TECN Rev. 01 Page 2 of 7 Table 1 Selecting a Database Server Based on the Number of Connections Database Server Configuration Number of Connections* 32-bit Windows 64-bit Windows 4 GB of RAM installed and /3GB switch set Minimum of 8 GB RAM and Enterprise Edition Windows Server < 400 connections > 400 connections 64-bit Solaris 10 Minimum of x GB RAM > 400 connections * Empower 2 Enterprise Server connections = active user applications + chromatographic systems Platform Limitations 32-bit operating systems such as Microsoft Windows 2000 or 2003 Server have a limitation that the maximum allowable addressable memory for a process is 3 GB. NOTE: The operating system architectural limit is either 2 or 3 GB depending on the version of the Microsoft Windows deployed on the Empower 2 Enterprise database server. See Microsoft web site knowledge base article KB for switch and version references. Waters has addressed this issue by expanding support of 64-bit operating systems. If you are implementing smaller networks, you may continue to choose 32-bit Windows, but if you have larger needs, you may choose either of the 64-bit solutions. In some cases, you may be able to reuse the Intel-based hardware when upgrading. 64-bit operating systems have a significantly higher maximum allowable memory. The precise value is in the Terabyte range but may be limited to a lower value by hardware design and by the operating system edition. In some cases, if you have already selected the 32-bit solution, you may be able to migrate to 64-bit Windows in order to retain your hardware investment. Monitoring Memory Usage and Estimated Number of Connections Your average memory consumption per connection may vary and should be measured. The following equation will aid in estimating the total memory used on the Empower 2 database server. Memory Used (MB) = (U * Avg_App * M) + (S * M) where: U = Number of Users concurrently connected Avg_App = Average number of user applications launched (typically 5 for the Pro interface and 2 for the QuickStart interface) M = Average amount of memory used per connection as measured in your environment S = Number of the chromatography systems connected

3 TECN Rev. 01 Page 3 of 7 Based on Waters testing, the amount of memory used by each connection on a 32-bit Windows database server may vary between 3 and 15 MB. For the purposes of selecting a database server, Waters used an average value of 5 MB, which results in 400 connections consuming 2 GB of RAM. This leaves room for operating system functions. These values are not absolutes. You should consider monitoring your systems to ensure that you have adequate resources. When the memory used on the 32-bit database server exceeds 2.5 GB, users will begin to see the effects. Memory may be monitored using the Windows Performance Monitor tool. Oracle indicates that the memory usage reported by the Windows Task Manager may not be accurate. The Virtual Bytes, Virtual Bytes Peak, and Threads parameters for the Oracle Process were monitored. Refer to Technical Note TECN Monitoring Oracle Memory Usage, for more information. Diagnostics Oracle logs information into ASCII files residing on the database server. These include a log called listener.log that documents connections to the database. It is located in oracle\network\log on the drive where Oracle is installed. The name of the log file is the name of the listener with.log appended to it. For Empower listener, it is typically LISTENER, but this may vary in larger installations. Listener Log The typical event recorded in the listener.log file related to exceeding the capacity of the server is ORA-12500, but ORA-12514, ORA-12505, and others may also be reported. An example of a normal entry and a failure are illustrated below: Entry indicating normal activity: 15-JUN :37:25 * (CONNECT_DATA=(SERVICE_NAME=<service_name>)(CID=(PROGRAM=C:\Empower\Bin\ PROCSRVR.EXE)(HOST=LEN_102806)(USER=SYSTEM))) * (ADDRESS=(PROTOCOL=tcp)(HOST=<ip address/name>)(port=1437)) * establish * <service_name> * 0 Entry indicating a failure: 18-JUN :49:22 * (CONNECT_DATA=(SERVICE_NAME=<service_name>)(CID=(PROGRAM=C:\Empower\Bin\ PROCSRVR.EXE)(HOST=LEN_102806)(USER=SYSTEM))) * (ADDRESS=(PROTOCOL=tcp)(HOST=<ip address/name>)(port=2942)) * establish * <service_name> * Values in Italic indicate variable information such as the exact Service name, the Empower program attempting contact, and the IP address and Port information. The numeric value at the end of each line indicates 0 for a successful connection or a value greater than 0 for failures. The number is generally the same as ORA-XXXXX or TNS-XXXXX. The value can be followed by additional information such as TNS:listener failed to start a dedicated server process.

4 TECN Rev. 01 Page 4 of 7 Each time the Empower 2 client is able to reach the database server over the network; there will be an entry in the listener.log file. The absence of a message indicating success or failure indicates that the client was unable to physically connect to the database server. Such failures are beyond the scope of this document. If the client is able to reach the database server but is unable to connect to the database, the next diagnostic log to review is the database alert log. Alert Log Oracle logs information about the operation of the database server in a file called the Alert log. This is typically called alert_sid.log where sid is the database sid (usually WAT6 or WAT7). The file is stored in the directory \oracle\oracle10g\admin\bdump on the drive where Oracle is installed. The database logs all activities in the Alert log, including normal activities such as startup as well as error messages. Entry indicating normal activity: System parameters with non-default values: processes = 150* sga_target = control_files = F:\EMPOWERDATABASE\ORADATA\WATC\CONTROL01.CTL, G:\EMPOWERMIRRORDB\ORADATA\WATC\CONTROL02.CTL, G:\EMPOWERMIRRORDB\ORADATA\WATC\CONTROL03.CTL db_block_size = 8192 compatible = log_archive_dest_1 = LOCATION=G:\EmpowerArchive1DB\\ log_archive_dest_2 = LOCATION=E:\EmpowerArchive2DB\\ log_archive_format = ARC%S_%R.%T db_file_multiblock_read_count= 16 db_recovery_file_dest = E:\Empower\Oracle\flash_recovery_area db_recovery_file_dest_size= undo_management = AUTO undo_tablespace = UNDOTBS1 remote_login_passwordfile= EXCLUSIVE db_domain = <name of the database domain> job_queue_processes = 10 background_dump_dest = E:\EMPOWER\ORACLE\ADMIN\WATC\BDUMP user_dump_dest = E:\EMPOWER\ORACLE\ADMIN\WATC\UDUMP core_dump_dest = E:\EMPOWER\ORACLE\ADMIN\WATC\CDUMP sort_area_size = db_name = WATC open_cursors = 300 pga_aggregate_target = * 150 was the default for the Empower 2 base release. 500 is the default for Empower 2 starting with Feature Release 5. This value is typically adjusted for the maximum number of concurrent connections expected allowing for some unexpected growth.

5 TECN Rev. 01 Page 5 of 7 In this case, the value highlighted indicates that 150 processes (500 for Empower 2 FR5) may connect to this database. When Oracle starts up, it reserves memory for this number of processes or connections. Even if sufficient memory exists, the database will be limited to this number. Activity in the alert log which indicates an issue can be illustrated by the following messages: Entry indicating a failure: Process q005 started up but failed with error = 4030 skgpspawn failed:category = 27143, depinfo = 9261, op = spdcr, loc = skgpspawn skgpspawn failed:category = 27143, depinfo = 9261, op = spdcr, loc = skgpspawn ORA-04030: out of process memory when trying to allocate 8156 bytes (callheap,kdbmal allocation) ORA-07445: exception encountered: core dump [ACCESS_VIOLATION] [0x60AB0F06] [] [] [] [] ORA-04030: out of process memory when trying to allocate 8204 bytes (PL/SQL Opt Poo,pdz7M04_Create) In this case, the key message is ORA-4030: out of process memory. This results when the available memory on the database server for the process is exhausted and no memory can be allocated to new connections. Issues Observed When Exceeding Memory or Process Limitations When the database server is not able to connect clients to the database, one or more of the following behaviors may occur: Acquisitions already in progress may stop collecting data and do not buffer (PCS #47788). Processing in progress may stop and/or skip injections (PCS #47813). Processing may hang with the ORA message described above but messages are logged in the Empower 2 Message Center. Project Backup failed The appropriate error is displayed on the screen and any incomplete projects are rolled back. The failure is recorded in the System Audit Trail. Project Cloning failed The appropriate error is displayed on the screen and any incomplete projects rolled back. The failure is recorded in the System Audit Trail. Project Restore failed The appropriate error is displayed on the screen and any incomplete projects rolled back. The failure is recorded in the System Audit Trail. Deletion failed The appropriate error is displayed on the screen; however, Empower 2 does not record the failure and a partial project may remain viewable and accessible (PCS #47789).

6 TECN Rev. 01 Page 6 of 7 Review Users already in Review may notice a performance degradation including a response time that is slower than usual. Some of these behaviors alert the user interactively and via the System Audit Trail and therefore Waters is not investigating any corrective action. Those with PCS numbers have been entered into the Waters Product Change System database to be considered for correction in a future release of Empower 2. The behaviors described above were discovered through specific testing. The testing performed was not exhaustive and therefore you may also observe other behaviors when the database server is not able to service additional connection requests. Potential Corrective Actions Potential corrective actions may include: Reduce the number of connections made to the database. Identify those client machines that are idle and ensure that they are logged completely out of Empower 2. This includes Citrix sessions that may have been disconnected due to a network issue. Be certain to close all Empower 2 applications including the Message Center. In a traditional client, this appears as an E icon in the system tray and may otherwise be overlooked. Consolidate systems onto the smallest number of acquisition servers as possible. Chromatographic systems in Empower 2 maintain a connection to the database that remains until the machine is rebooted. If you are using an acquisition client and all acquisition has ceased, reboot the machine. Increase the available memory. If the /3GB switch has not been used in 32-bit versions of Windows, you can add it. Adding this switch will increase from the amount of memory available to a process from 2 to 3 GB. Switch to a 64 bit operating system. 64 bit Windows 2003 Server is now supported by Empower 2 starting with Feature Release 5. Oracle has identified additional options that include: Switch to the shared server mode This enables Oracle to share memory across the various connections in a different fashion. While this appears to be a solution, it has not been tested by Waters. Anecdotal reports from a customer indicated similar issues as described. This option is not supported by Waters.

7 TECN Rev. 01 Page 7 of 7 Use a utility provided by Oracle to reduce the base amount of memory consumed on each connection. Each Oracle connection consumes at least 1 MB of memory. This tool reduces those values. According to Oracle documentation, this may lead to issues as well. This option is not supported by Waters. Oracle recommends switching to a 64-bit operating environment when facing issues in a 32-bit environment. While there are options to increase usage, the majority of those are simply postponing the inevitable. Summary The constraints of a 32-bit database server eventually limit the number of users and systems that may connect to an Empower 2 Enterprise environment. Memory usage by individual users will vary according to factors such as the number of custom fields, the values present in them, the number of samples processed, peaks found, and similar differences. An average of 5 MB per connected application is a suitable starting point, but the memory used should be monitored and the log files reviewed on a regular basis in order to maximize availability. Ultimately, you can now implement a 64-bit Windows solution as easily as a 32 bit Windows solution. Upgrading to a 64-bit Windows operating system is expected to address the limitations outlined in this document. NOTE: When making any changes to a system, you should consider the applicable Standard Operating Procedures (SOPs) and complete the appropriate documentation and validation. If you have questions or require additional information, contact your local Waters Data Specialist.

Managing an Oracle Instance

Managing an Oracle Instance Date: 07.10.2009 Instructor: SL. Dr. Ing. Ciprian Dobre 1 Objectives After completing this lesson, you should be able to do the following: Create and manage initialization parameter