Oracle Timesten In-Memory Database 7.0 Features Overview
Total Page:16
File Type:pdf, Size:1020Kb
Oracle TimesTen In-Memory Database 7.0 Features Overview Updated September 2007 to include new features in 7.0.3 Oracle TimesTen In-Memory Database New Features in Release 7.0.3 September 2007 1 What‘s New in Oracle TimesTen 7.0.3 This section provides an overview of the new functionality added to the Oracle TimesTen In- Memory Database release 7.0.3. Enhancements for this release include: • Support for IPv6 on Linux and Solaris • Support for Oracle Database 11g release on Linux x86 platform • Enhancements for Replication host name specification and resolution • Improvements on client/server connection handling • New SQL features and 15 new SQL functions • Cache group parallel loading from Oracle database • Mechanisms to monitor read-only cache group status and operations • Support for NFS on Linux clients • Support for new platforms Sections 2-13 below describe the supported platforms, features and functionality in more details. 2 Supported Platforms The matrix below describes the supported platforms for the Oracle TimesTen In-Memory Database release 7.0.3. New platforms are highlighted in bold. Oracle TimesTen In-Memory Database, Replication, Cache Connect - Supported Platforms Operating System JVM Processor Type AIX 5L 5.2, 5.3 (32/64 bit) JDK 1.4.2, 5.0 (IBM) IBM Power HP-UX 11i v2 & 11i v3 (32/64 bit) JDK 1.4.2, 5.0 (HP) HP PA-RISC , IA64 - Asianux 2.0 (32/64 bits) JDK 1.4, 5.0 (Sun, Intel IA-32, EM64T, - MontaVista Linux CGE 4.0 (32/64 bit) BEA JRockit); JVM Itanium-2, AMD - Oracle Enterprise Linux 4.0, 5.0 (32/64 bits) 5.0 required for Opteron - Red Hat Enterprise Linux 3.0, 4.0, 5.0 (32/64 Opteron and EM64T bits) - SUSE Linux Enterprise Server 9, 10 (32/64 bit) Oracle TimesTen 7.0.3 Features Overview Page 2 of 24 September 2007 Solaris 8, 9, 10 (32/64 bit) JDK 1.4, 5.0 (Sun) UltraSparc Solaris 10 (32 bit and 64 bit) JDK 1.4, 5.0 (Sun) AMD Opteron Tru64 Unix 5.1B-2 (64 bit) JDK 1.4 (HP) AlphaChip EV68 Windows Server 2000, 2003, XP (32/64 bit) JDK 1.4, 5.0 (Sun, Intel IA-32, EM64T, BEA JRockit) AMD Opteron 3 IPv6 Support Support for IPv6 is available on the following platforms: • Linux x86 32-bit and 64-bit (including RHEL, OEL, SuSE, MontaVista Linux, Asianux) • Solaris Sparc 32-bit and 64-bit • Solaris x86 32-bit and 64-bit Refer to the Operations Guide for details on how to enable IPv6 support on your systems. 4 Replication Host Name Specification and Resolution This release simplifies the Replication scheme definition and specification of multiple host names. The enhancements include: • A more user-friendly way to specify multiple network host names and IP addresses • Ability to assign priority for each of the IP addresses for host name resolution • Ability to specify host name‘s IP address in IPv6 format The new syntax for CREATE REPLICATION is shown below where the new enhancement is shown in bold font: CREATE REPLICATION ... [ROUTE MASTER FullStoreName SUBSCRIBER FullStoreName [ MASTERIP MasterHost PRIORITY priority ] [SUBSCRIBERIP SubscriberHost PRIORITY priority ] […]][…] This new syntax helps reduce user errors when specifying the replication schemes, and the new syntax clearly defines the priority of each of the host names that should be used by Replication for host name resolution. Example 1: CREATE REPLICATION r ELEMENT e DATASTORE MASTER node1 SUBSCRIBER node2 return receipt ROUTE MASTER node1 SUBSCRIBER node2 MASTERID "11.121.131.1" PRIORITY 1 SUBSCRIBERIP "11.121.131.2“ Oracle TimesTen 7.0.3 Features Overview Page 3 of 24 September 2007 PRIORITY 1; xample 2: CREATE ACTIVE STANDBY PAIR node1 , node2 ROUTE MASTER node1 SUBSCRIBER node2 MASTERID "11.121.131.1" PRIORITY 1 SUBSCRIBERIP "11.121.131.2“ PRIORITY 1; Example 3: The Replication route can be modified using the ALTER REPLICATION command: ALTER ACTIVE STANDBY PAIR ADD ROUTE MASTER node1 SUBSCRIBER node2 MASTERID "11.121.131.1" PRIORITY 1 SUBSCRIBERIP "11.121.131.2“ PRIORITY 1 MASTERIP "11.121.141.3" PRIORITY 2 SUBSCRIBERIP "11.121.141.4" PRIORITY 2; Refer to the SQL Reference Guide for more details. 2 Client/Server Connections Improvement Prior to this release, every client/server connection consumed one Server process. In this release, a number of enhancements have been made to provide better control on process resource consumptions for application connections. The enhancements include: • Ability to specify multiple connections per Server process • Ability to specify number of Server processes for load balancing the connections • Ability to specify the connection thread stack size For applications that require a large number of client/server connections, configuring multiple connections per server process will help reduce the resources required on the server machine. To enable these new functionalities, use the following Server connection attributes in the Server DSN or the daemon options in the ttendaemon.options file: Max ConnsPerServer NumberOfClientConnections maxConnsPerServer configures the maximum number of threads per Server process, one thread per connection. ServersPerDSN NumberOfChildServerProcesses serversPerDSN configures the number of Server processes spawned for the particular database. The client connection requests will be distributed to the available server processes in round-robin fashion. If the system requires more server processes, additional servers will be created. ServerStackSize ThreadStackSize ThreadStackSize specifies the stack space allocated per thread in the Server process. The default is set at 128KB for 32-bit system and 256KB for 64-bit system. Oracle TimesTen 7.0.3 Features Overview Page 4 of 24 September 2007 In general, the default stack size is adequate for most applications. If your application requires more stack space due to large SQL operations, you should configure a higher value for the thread stack size. If the configured stack size is not enough to accommodate your application, the Server process may encounter segmentation faults. On the other hand, if the system is short on virtual memory and your application uses simple SQL operations, you may choose to reduce the thread stack size. 0xample : The following example shows how the connection requests are load balanced across the configured Servers. Suppose we configure axConnsPerServer = 10, and serversPerDSN = 5 The first 50 client/server connection requests will be handled as shown below: • Server #1 will handle connections 1, 6, 11, 16, 21, 26, 31, 36, 41, 46 • Server #2 will handle connections 2, 7, 12, 17, 22, 27, 32, 37, 42, 47 • Server #3 will handle connections 3, 8, 13, 18, 23, 28, 33, 38, 43, 48 • Server #4 will handle connections 4, 9, 14, 19, 24, 29, 34, 39, 44, 49 • Server #5 will handle connections 5, 10, 15, 20, 25, 30, 35, 40, 45, 50 Now suppose the 51 st connection request is received, and since all 5 configured Servers already have 10 connections each, an additional server process will be created. This 6 th server process will handle the next 10 connections; if we need more connections, additional server processes will be created accordingly. If any of the connections disconnects, the available thread will be used for the next incoming connection request. Refer to the Operations Guide for more details on the new daemon options. 6 Parallel Loading Cache Group Tables In this release, cache group data loading from the Oracle database can be performed with multiple threads loading concurrently to reduce the overall loading time. This is particularly useful when there are multiple CPUs available on the TimesTen server to perform the loading operation concurrently. The LOAD CACHE GROUP statement now accepts a new PARALLEL clause as follows: LOAD CACHE GROUP [Owner.]GroupName .. [ PARALLEL NumThreads ] For a system with N cores/processors, it‘s a good idea to set NumThreads to N as a start. Depending on the available processor and network bandwidth, a value higher than N may help, but the improvement will be less once N goes beyond the number of available processor cores. Refer to the SQL Reference Guide for more details. 7 Monitoring Read-Only Cache Group To monitor the progress of Autorefresh operations, the following mechanism is available in this release: Oracle TimesTen 7.0.3 Features Overview Page 5 of 24 September 2007 • ttCacheAutorefreshStatsGet œ a new built-in procedure to retrieve the information for the last ten Autorefresh transactions. You can use the information returned to adjust the Autorefresh interval time, to monitor whether there is a bottleneck in fetching the data from the Oracle database, or if there is a bottleneck in updating the TimesTen database; the statistics can also be used to compute the average throughput of the autorefresh operations. See description in Section 8.2 below. • More details on the Autorefresh transactions are written to the message log. • A new SQL script is available to gather information from the change log tables that exist on the Oracle database for Autorefresh cache groups. This script can be used to monitor the number of Oracle records pending to be refreshed to the TimesTen database. If the pending number of records keeps increasing, you can use the ttCacheAutorefreshStatsGet to help determine where the bottleneck may be. The SQL script is located in the TimesTen installation directory install_dir/bin/autorefreshChangeLogInfo.sql. The SQL script should be run against the Oracle database. Refer to the Trouble Shooting Guide for more details. 8 New Builtin Procedures The following new built-in procedures have been added to the release. 8.1 ttMonitorHighWaterReset The ttMonitorHighWaterReset function allows the user to: • Reset the PERM_IN_USE_HIGH_WATER column in the MONITOR table to the current value of PERM_IN_USE_SIZE attribute • Reset the TEMP_IN_USE_HIGH_WATER column in the MONITOR table to the current value of TEMP_IN_USE_SIZE attribute This function enables the user to reset the peak in-use values without unloading and reloading the database.