Best Practices for Running TEMENOS T24 on Microsoft SQL Server and Windows Server

Guidance for fine-tuning T24 implementations on Windows Server 2008 R2 and on the SQL Server 2008 R2 and SQL Server 2012 database platform

V1.1 Published: July 2012 Produced by Temenos and Igor Pagliai, Microsoft Based on previous work done by: Lonnye Bower, Kun Cheng, Konstantin Dotchkoff, Roger Toren - writing Peter Carlin, Nicholas Dritsas - reviewing

Abstract
TEMENOS T24 (T24) is a complete banking solution designed to meet the challenges faced by financial institutions in today’s competitive market. T24 provides a single, real-time view of clients across the entire enterprise, making it possible for banks to maximize returns and keep costs down. Microsoft® SQL Server® provides the ideal database platform for T24. By choosing the Microsoft platform, T24 customers experience faster funds transfers, higher security-trade volumes, and quicker close-of-business processes; T24 customers can also benefit from open, state-of-the-art technologies to accelerate innovation, greatly increasing the speed and effectiveness with which new products and services are created. Using Windows Server® 2008 R2 as the operating system makes it possible for T24 to exceed performance standards in a scalable, reliable environment that offers ease of management. This white paper provides best practices for configuring and running TEMENOS T24 on Windows Server and on the SQL Server database platform. Implementing these best practices can help you avoid or minimize common problems and optimize the performance of your TEMENOS T24 implementation.

This document is provided “as-is.” Information and views expressed in this document, including URL and other Internet Web site references, may change without notice. You bear the risk of using it.

This document does not provide you with any legal rights to any intellectual property in any Microsoft product. You may copy and use this document for your internal, reference purposes.

Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server

2

Table of Contents
OVERVIEW ............................................................................................................................................... 5 1 BEST PRACTICES FOR THE DATABASE SERVER .................................................................................. 7 1.1 SERVER RECOMMENDATIONS ............................................................................................................... 7 1.1.1 Use the Latest Software Versions...................................................................................................... 7 1.1.2 Use a 64-Bit Server ............................................................................................................................ 8 1.1.3 Use a Dedicated Server ..................................................................................................................... 8 1.2 SIZING RECOMMENDATIONS ................................................................................................................ 8 1.3 STORAGE DESIGN RECOMMENDATIONS .................................................................................................. 8 1.3.1 Use SAN and RAID 10 ........................................................................................................................ 8 1.3.2 Set the Partition Offset ..................................................................................................................... 9 1.3.3 Set the File Allocation Unit Size and Stripe Size................................................................................. 9 1.3.4 Dedicate a High Percentage of SAN Cache to Writes ...................................................................... 10 1.3.5 Configure Windows Drives .............................................................................................................. 10 1.4 HARDWARE AND NETWORK GUIDANCE ................................................................................................ 10 1.4.1 Windows Server Power Plan ........................................................................................................... 10 1.4.2 Use a Private Network Segment ..................................................................................................... 11 1.4.3 Enable Receive-Side Scaling ............................................................................................................ 11 1.4.4 Consider NIC Teaming ..................................................................................................................... 12 1.4.5 Use Multiple HBAs and Set the HBA Queue Depth .......................................................................... 12 1.5 DATA, LOG, TEMPDB, AND BACKUP FILE RECOMMENDATIONS .................................................................. 12 1.5.1 Configure Data Files ........................................................................................................................ 12 1.5.2 Configure the Log File ..................................................................................................................... 13 1.5.3 Configure tempdb Files ................................................................................................................... 14 1.6 RECOMMENDATIONS FOR MEMORY SETTINGS ....................................................................................... 15 1.6.1 SQL Server Memory Settings ........................................................................................................... 15 1.6.2 Lock Pages in Memory .................................................................................................................... 16 1.6.3 Instant File Initialization (IFI) .......................................................................................................... 17 1.7 GUIDANCE FOR SQL SERVER CONFIGURATION SETTINGS ......................................................................... 17 1.7.1 Consider Lower Fill Factor ............................................................................................................... 18 1.7.2 Increase the SQL Server Recovery Interval ...................................................................................... 19 1.7.3 Use Trace Flag 834 .......................................................................................................................... 19 1.7.4 Keep Default Setting for Degree of Parallelism ............................................................................... 20 1.7.5 Keep Default Setting for Number of Worker Threads ..................................................................... 20 1.7.6 Encrypt Client Communication if Required...................................................................................... 20 1.7.7 T24 Database Configuration settings.............................................................................................. 20 2 BEST PRACTICES FOR THE APPLICATION SERVER ........................................................................... 22 2.1 SOFTWARE RECOMMENDATIONS ........................................................................................................ 22 2.1.1 Use the Latest Software Versions.................................................................................................... 22 2.2 T24 CONFIGURATION RECOMMENDATIONS .......................................................................................... 22 2.2.1 Configure the T24 Bulk Factor Parameter ....................................................................................... 22
Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server 3

..................................................... 29 BEST PRACTICES FOR PERFORMANCE TUNING ........1.............3.............................................................. 38 7.....................1 Reorganize Indexes ..........................................................................................................2 Close of Business (COB) ..................................................... 40 7............................. 25 3.............. 37 7......................... 30 6............................................ 57 APPENDIX 4: REORGANIZE AND REBUILD INDEXES ........................... 28 5 6 BEST PRACTICES FOR REPORTING .....................4........................................................................3...................................................................................... 38 7................3 T24 RECOVERY.......................................................3 4.......................................................................................................................................... 36 7 BEST PRACTICES FOR SYSTEM MAINTENANCE ..............................................................2................... 30 6................. 39 7...................................2 Run Anti-Virus Checks During Non-Peak Hours ............................................... 37 7...... 68 4 Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server ..........3 Configure the T24 Handle Cache Parameter ..................................................................................... 37 7..............................2..........3................. 51 APPENDIX 3: UPDATE STATISTICS ..... 24 3...............................1 4....................................................................................................................... 41 8 9 10 11 12 13 SUMMARY .................................1 SQL Server 2012 Setup Product Update ....1 GUIDANCE FOR BACKING UP THE DATABASE ................................. 61 APPENDIX 5: INSTALLATION CHECK LIST .............................................................................................. 40 7.................. 40 7.......1.... 27 RECOMMENDATIONS FOR CONNECTION BANDWIDTH ....................... 31 6............ 25 4 BEST PRACTICES FOR DISASTER RECOVERY ............................ 37 7.......................................................................................................2 2. 26 SAN MIRRORING .............................................................................................................................. 38 7.......................................................................................................1 Optimize Standard T24 Queries ................................................................ 27 SYNCHRONOUS DATABASE MIRRORING ................4................1...2 HIGH AVAILABILITY RECOMMENDATIONS FOR THE STORAGE.........4 RECOMMENDATIONS FOR UPDATE MANAGEMENT .............. 41 7................................................... 30 6.....................1 Use Backup Compression .......3 Back Up System Databases ..................2.................... 45 APPENDIX 2: CREATE A MAINTENANCE PLAN TO BACK UP THE SYSTEM DATABASES ......................................3 RECOMMENDATIONS FOR REORGANIZING OR REBUILDING INDEXES ........................................1 HIGH AVAILABILITY RECOMMENDATIONS FOR THE DATABASE ...5 SQL SERVER 2012 HIGH-AVAILABILITY AND DISASTER RECOVERY (HADR) ENHANCEMENTS............................................................3 Consider Running Windows Updates on a Test Server before Production ........ 23 3 BEST PRACTICES FOR PROVIDING HIGH AVAILABILITY ....................................................................................................................................................2 Implement a Backup Schedule .....................................1............................................................2 Rebuild Indexes when Necessary .............................................................................................................................. 43 APPENDIX 1: CREATE A MAINTENANCE PLAN TO BACK UP THE TEMENOS DATABASE .......................... 22 Consider Using Hyper-Threading ....................................... 26 4...................................................... 27 ASYNCHRONOUS REPLICATION METHODS .......................................................................................................................................................................4............................................... 25 3................ 25 3..2 Optimize Customer-Specific T24 Queries .................2 4....1 Online Recovery ......................... 24 3.......................4 4..................................................................................................................................1................................................................1 GUIDANCE FOR IMPROVING QUERY PERFORMANCE ......3.............2 RECOMMENDATIONS FOR MONITORING PERFORMANCE OF THE DATABASE TIER ...................................2 RECOMMENDATIONS FOR UPDATING STATISTICS ..........

and it uses established standards such as HTTP. we focus on best practice guidance for the database layer (in green). XML. T24 is built on an open architecture. Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server 5 . and Java 2 Platform. Temenos Group AG. In this white paper. the leading provider of integrated core banking systems. Customers running T24 on a Windows Server® operating system and Microsoft® SQL Server® data management software benefit from a wide range of products and tools that can be used to further improve the performance and extend the capabilities of the T24 banking solution. Figure 1 shows a logical model of the interaction of the various services and components that make up a T24 banking implementation. T24 pairs comprehensive and powerfully flexible business functionality with advanced and scalable architecture. The capabilities of T24 can be enhanced by the choice of an enterprise-ready database platform. global marketplace. The design of T24 supports multiple application servers and provides horizontal scalability with true non-stop resilience. Figure 1. Enterprise Edition (J2EE). offers TEMENOS T24 (T24). Logical architecture of T24.Overview To help financial institutions face the challenges posed by today’s around-the-clock.

The paper then looks at the options for disaster recovery. intended for database administrators (DBAs). Implementing these best practices can help you optimize the performance of a T24 implementation and can help avoid or minimize common problems. The paper also provides appendices with step-by-step guidance and extensive links for further information.This white paper. The paper first discusses best practices for configuring the database server and the application servers and provides guidance for building scalability and high availability into the T24 banking solution. Best practices for reporting are presented. and best practices for monitoring the performance of the database tier and for system maintenance are discussed. Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server 6 . describes optimizations that you can make to the database tier and describes the database tier’s interaction with the application tier to help ensure a successful deployment of T24 on SQL Server.

Currently.1 Use the Latest Software Versions For best performance. see Windows Server 2008 R2. Optimizations for 64-bit processors.aspx Windows Server® 2008 R2 Operating System. Note: It is highly recommended to install “Service Pack 1” for Windows Server 2008 R2 along with the recommended non-security related hotfixes for the Cluster component mentioned in the article: Recommended hotfixes and updates for Windows Server 2008 R2 SP1 Failover Clusters (http://support. you should use: T24 Version R12. in addition to various new features like Availability Group for High Availability and Disaster Recovery. you should use the latest software versions. Improved failover clustering capabilities. For more information.      For more detailed information. Support for up to 256 logical processors (cores). Windows Server 2008 R2 provides many benefits.microsoft. SQL Server 2012 contains performance and scalability improvements for running on computes with many cores (up to 640) and memory (up to 4TB). this benefits the disaster recovery (DR) options described in detail in section Best Practices for Disaster Recovery.1 Server Recommendations 1.1. only up to 64 cores were supported.1 Best Practices for the Database Server Following are some best practices you should use to configure your database server. Receive-side scaling (RSS). Optimized partition offsets when disks are formatted. To learn more about SQL Server 2012 new capabilities. reducing complexity in I/O system configuration. In addition to reducing latency of transaction processing. such as those commonly used in banking implementations. 1.com/kb/2545685) Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server 7 .com/sqlserver/en/us/product-info/overview-capabilities. On previous versions of Windows Server.microsoft. visit the link: http://www. see Receive-Side Scaling. T24 version R12 contains key performance and scalability improvements for running T24 on Windows Server and SQL Server. including:  A more efficient TCP/IP stack than in previous versions of Windows Server. which makes it possible for network packet processing to be distributed across more CPUs. Microsoft® SQL Server® 2012.

3 Use a Dedicated Server If you are mixing workloads on one physical computer. you should use virtual machines or Windows/SQL Server mechanisms to control and monitor resource usage.2 Use a 64-Bit Server 64-bit servers provide efficient access to the memory and the number of cores required by T24. as well as reporting and extracting to data warehouse (DW) systems.It’s also recommended to install all the proposed operating system updates related to security available via Windows Update released from Microsoft immediately after the operating system installation and before installing SQL Server and T24. 1.1 Use SAN and RAID 10 You should use RAID 10 if possible for all logical unit numbers (LUNs).1. RAID 10 offers better performance and availability than RAID 5 and offers better support for write-heavy environments. tests that model your business processes as closely as possible may be necessary to confirm the server sizes required to support your business scenario.3. Following are best practices you should use when designing storage for your T24 implementation. Temenos also provides a Universal Performance Measurement (UPM) tool that can be used to verify a hardware configuration before T24 is installed.1. It is generally better to have a larger number of small drives than a smaller number of large drives. Therefore it is recommended to work with the Temenos Performance and Sizing Team to properly size your system based on the expected workload. the LUNs must be made up of physical drives that are not used by other applications. 1. For optimum and predictable performance. Table 2 shows how to choose drives from multiple buses to make up one LUN. Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server 8 . 1.2 Sizing Recommendations Every bank has different functionality and different close-of-business processes.3 Storage Design Recommendations Processing large volumes of banking transactions and providing high availability and disaster recovery (HADR). create each LUN using drives from each bus to improve the internal bandwidth. If your storage area network (SAN) has multiple buses (sometimes called shelves). In some cases. requires substantial I/O system resources. 1. 1. Diagnosing performance problems requires more effort and precision on a system with mixed workloads.

Some storage manufacturers claim to handle this within their architecture. Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server 9 . If the offset is not optimal. The stripe size is also important to reach an optimal configuration.exe tool to create the disk partition. logs. For more information about DiskPart. see the article DiskPart.2 Set the Partition Offset If you are using the Windows Server® 2003 operating system.LUN 1 Bus 1 Bus 2 Bus 3 1 2 3 4 5 6 7 8 9 10 11 12 LUN 2… 13 14 15 … … … …LUN 4 46 47 48 Table 1.exe to specify a starting offset of 1 megabyte (MB) to avoid split writes and reads. The following two equations can be used to determine if you have an optimal configuration. This is set in the SAN management software. as these can seriously degrade performance. Note: For an online transaction processing (OLTP) system the ideal latency values on a welltuned I/O subsystem are:  < 5 milliseconds (ms) for log (ideally 1 ms on arrays with cache)  < 20 ms for data on OLTP systems (ideally 10 ms or less) 1.3.3. but there usually is some degradation that can be easily avoided by setting the appropriate offset. Choosing drives from multiple buses to create a LUN.3 Set the File Allocation Unit Size and Stripe Size When formatting the partition that will be used for SQL Server data files.exe. In Windows Server® 2008 and Windows Server 2008 R2. not through Windows Server. and the tempdb database. you should use a 64kilobyte (KB) allocation unit size for data.) 1. Each should result in an integer value: Partition_Offset ÷ Stripe_Unit_Size Stripe_Unit_Size ÷ File_Allocation_Unit_Size For details on managing disk partition sector alignment. You should refer to the article Predeployment I/O Best Practices for procedures to test your I/O subsystem performance. you should use the Diskpart. Use Diskpart. a single logical I/O becomes multiple physical I/Os. (Note that the offset of existing storage is not changed when upgrading from Windows Server 2003. see Disk Partition Alignment Best Practices for SQL Server. the partition offset is set appropriately by default for new storage.

you need to assign the LUNs to drives in Windows.3. you must disable write caching or risk losing committed data in the event of a power outage. For further information about storage design for SQL Server. Table 3 shows a sample Windows Server storage configuration for use by SQL Server. SQL Server provides read-ahead and read caching. and SQL Server does not benefit much from a SAN read cache. disk volumes that are mounted as folders on other physical disks. The degraded performance may increase the average response time for some tasks and cause performance issues with CPU-intensive applications.3. see Storage Top 10 Best Practices. The issue may occur irrespective of SQL Server version and may be exhibited on both native and virtual environments. without incurring a performance penalty. using disk management to create the drives. You can also present storage to SQL Server through mount points.4. In order to avoid this situation. Note that virtually all SANs sold today have battery-backed cache.1.5 Configure Windows Drives Once you have configured LUNs on your SAN. it’s recommended to change the OS Power Plan from “Balanced” to “High Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server 10 .1 Windows Server Power Plan In some cases we observed degraded overall performance (even around 30-40%) on a Windows Server 2008 R2 machine when running with the default (Balanced) power plan.4 Hardware and Network Guidance The following are some important best practices for the hardware and networking of your T24 database implementation. Physical Drive LUN Drive Usage 1–12 13–24 25–36 37–48 1 2 3 4 E F G H data data tempdb log Table 2. 1. If you have the option (within the constraints of SAN usage by applications).4 Dedicate a High Percentage of SAN Cache to Writes Most SANs have a large cache that can be split between a read cache and a write cache. Sample storage configuration for SQL Server. 1. If this is not the case with your SAN. you should dedicate 90% of the SAN cache to writes to improve write performance (a cache ratio of 10/90 read/write). 1.

Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server 11 . You should set RssBaseCpu carefully so it does not overlap with the starting CPU. and a 10-Gigabit Ethernet network for installations with more than 5 million accounts. this means that 8 RSS processors are used starting with core number 8 to process network traffic. be sure that offloading options are enabled. Lab testing has shown good results with setting both registry key values to 8 (on a computer system with more than 32 cores).thecoderblogs.3 Enable Receive-Side Scaling You should enable Receive-Side Scaling (RSS) on the SQL Server network interface card (NIC) that is serving the application servers. see the links below: Degraded overall performance on Windows Server 2008 R2 http://support.microsoft.com/whdc/system/sysperf/Perf_tun_srv-R2. consider replacing it with one that does.com/2012/07/hyperthreading-turbo-boost-sql-serverand-you For general tuning information on Windows Server 2008 R2. Turbo Boost.Performance” and test the performance difference with a significant workload: if no difference will be found. You should configure the maximum number of RSS processors by setting the MaxNumRssCpus registry key value to 8 on a computer system with 32 or more CPU cores. This should be at least a 1-Gigabit Ethernet network. This setting is found on the Advanced Property tab of the network card.mspx 1. The RSS base CPU number (RssBaseCpu) is the CPU number of the first CPU that RSS can use. This can be in addition to a standard 100-Mb Ethernet connection to SQL Server for administration purposes.4. For computer systems with less than 32 cores.4.com/kb/2207548/en-us Hyperthreading. Also. SQL Server and You (MSDN) http://msdnrss.2 Use a Private Network Segment The traffic between T24 application servers and SQL Server and the traffic between SQL Server and the storage system is quite high. If your NIC does not support these options. Power Plan scheme can be reverted to the default value. see the white paper below: Performance Tuning Guidelines for Windows Server 2008 R2 http://www. RSS cannot use the CPUs that are numbered below the base CPU number. 1.microsoft. See the Microsoft® Developer Network (MSDN®) articles Introduction to Receive-Side Scaling and Receive-Side Scaling Enhancements in Windows Server 2008 for more information. use the default setting. You should use a private network segment for T24–SQL Server communication. For more information on this potential issue and instructions for changing the Power Plan options.

The HBA queue depth may need to be increased if you have a small number of LUNs. You should avoid using very large LUNs so that chkdsk does not run for an excessive length of time if it is invoked by the operating system on startup. 1. IMPORTANT: NIC teaming and RSS are not supported at the same time on Itanium architecture. log. The HBA cards should be set as load balanced and configured to provide high availability among them.4. The data files should be equal in size. queues now default to “per LUN” rather than “per target. tempdb. Note that the out-of-the-box configuration uses only one file in the primary filegroup. Connections between the SAN and server are ideally 8 gigabyte (GB)/sec (but not less than 2 GB/sec). use the same number of files as the number of CPU cores (the ratio should be 1:1). you may get increasing latency and less-than-expected throughput given the bandwidth between host/storage and the number of disks in a particular configuration.Note: You should use the Windows RSS registry keys to configure these values instead of NIC settings because NIC settings can be overridden by the Windows registry keys. 1. and backup files. Using separate LUNs also helps you monitor the disks based on the type of use. 1. Log. Best practice is to use one file for every two CPU cores on computer systems with 32 or more cores. A queue depth value between 128 (if there are few LUNs) and 32 (if there are many LUNs) should be considered. You should monitor the database free space and if necessary extend each file simultaneously so that all of the files have the same amount of free space. NIC teaming on the SQL Server side of the network segment may help. but often this type of NIC teaming disables RSS and other offloading options. and use distinct LUNs for each of the data.” When the queue depth is set too low. You should be sure to test this configuration against your original performance to be sure that any benefit of NIC teaming is not offset by the disabling of any of the RSS and offloading options.1 Configure Data Files The filegroup used for the T24 data should be composed of multiple files.5. so you need to add additional files for optimal configuration. On computer systems with less than 32 cores. 1.5 Use Multiple HBAs and Set the HBA Queue Depth You should use at least two host bus adapters (HBAs) to provide redundancy and to increase bandwidth between the SAN and SQL Server.4. SQL Server optimizes Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server 12 . You should use multiple files for each filegroup supporting your databases. tempdb. You should pre-allocate enough space in the data files based on the initial size of the computer system.5 Data. and Backup File Recommendations The location of SQL Server files affects performance. Check with your vendor to select a NIC teaming option that can support RSS or provide equivalent features.4 Consider NIC Teaming If you have three or more application servers.

you can use the 80-GB transaction log size for T24 installations with 10 million accounts. so extending all files at once maintains this optimization. Reasonable increment sizes for transaction log are 1GB. allocate only by the space needed for a few days of operations. 16GB and final choice should be based on the relative size of the planned initial size of the transaction log and reflects how big the environment will be in terms of number of accounts. SQL Server 2008 R2 and later provide tools (SQL Trace and Dashboard reports) of how much time the autogrowth operations on transaction log will take.2 Configure the Log File The transaction log file. multiple files can be beneficial for maintenance purposes (for example. do not rely on autogrowth to extend the database files as a standard way of operating. if the observed duration will be consistently higher than 1 second.  o IMPORTANT: In SQL Server 2008 and SQL Server 2008 R2. Increment size should be always higher than 1GB. Since you cannot control when autogrowth engages. if you are running out of space on the log drive). it’s recommended to: o Raise the initial size of the transaction log to reduce occurrences of autogrowth expansions.microsoft. Since expanding the transaction log is a relative slow operation. 8GB. if you allocate in very large units during autogrowth. always use fixed size autogrowth size. the application must wait (possibly several minutes) while the space is allocated. a bug exists affecting transaction log file growth of 4GB (or multiples of it) as explained in the article: The SQL Server database transaction log file does not grow by the configured file growth value (http://support. You can leave the autogrowth setting on as an “insurance policy” so that SQL Server does not stop when it runs out of space. however. 4GB. it’s recommended to balance the size of the growth and the number of transaction log expansions based on the following recommendations:    Never use increments in percentage. While there is no performance benefit from using more than one file. monitor its size on a regular basis and adjust it as necessary. Reduce the autogrowth size.writes by spreading its write operations across the files based on the ratio of free space among the files. 1.5. To avoid autogrowth operations on the transaction log file. 2GB. As a starting point. must be written as quickly as possible—even before the data is written to the data files (the data portion can be rebuilt from the log if necessary). generally a sequentially written file. While you should not allocate space for the data files in small units. Adding physical devices to support the LUN can benefit performance.com/kb/2633151) Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server 13 .

T24 uses a read-committed snapshot isolation level as its default isolation level.aspx http://blogs. When this trace flag is set. This reduces page free space (PFS) contention. then overall TEMPDB performance: be sure to take into account the fact that all files will growth when establishing data file growth size.aspx For information on how to set startup settings for SQL Server 2008. Pre-size the tempdb files. For more information. for SQL Server 2008 there is no fix.com/technet_blog_images/b/sql_server_sizing_ha_and_performa nce_hints/archive/2012/02/09/sql-server-2008-trace-flag-t-1117. Use startup trace flag 1118. For more information about T1118 trace flag. For more information about T1117 trace flag. and make the files equal in size.SQL Server 2012 is not affected. SQL Server 2008 R2 (or later) will expand all TEMPDB data files at the same time to maintain optimal allocation balance. The tempdb files are responsible for managing temporary objects. see the articles below: http://blogs. To ensure efficient tempdb operation:   Create one tempdb file per physical CPU core.com/b/axperf/archive/2011/09/12/consider-enabling-trace-flag1117-on-dynamics-ax-sql-server.technet.5.msdn. If used. and online index rebuilds. Use startup trace flag 1117. it’s recommended to avoid 4GB (or multiples) increment. if not possible to apply the hotfix.    Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server 14 .3 Configure tempdb Files SQL Server tempdb files are used for the storage of temporary data structures. you can use a 64-GB total size for T24 installations with 10 million accounts. As a starting point. Do not rely on autogrowth (see previous section). row versioning. SQL Server allocates full extents for tempdb objects (instead of using mixed extent allocations). for SQL Server 2008 R2 “Service Pack 1” and “Cumulative Update 4 for SP1” must be installed to solve the problem. 2008 R2 and 2012. which uses row versioning. see the article Configure Server Startup Options (SQL Server Configuration Manager. see the article Concurrency Enhancements for the tempdb Database. 1. see Isolation Levels in the Database Engine.

then it’s recommended to reserve enough memory based on the maximum number of worker threads. the memory management has been significantly changed and now the configuration parameter “max server memory (MB)” is a real cap for almost all memory used by SQL Server and not only the Buffer Pool as worked in previous versions. For SQL Server 2008 and SQL Server 2008 R2 you should then configure the SQL Server “max server memory (MB)” setting by taking the amount of memory allocated to the database system and subtracting one GB for every four cores (round up). be sure to check the right version in the provided link above. For SQL Server 2012.com/en-us/library/ms190219. if the server has 64 GB of RAM and 24 cores. 1. see the MSDN article Optimizing tempdb Performance.microsoft. the general formula below can be used: Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server 15 .1 SQL Server Memory Settings See section Sizing Recommendations (and Table 1) for appropriate memory sizing for the database system. The maximum number of worker threads.aspx For each single worker thread. If you need to do calculation over the 32 logical processors. For example. if not directly modified in the instance configuration parameters.6.6 Recommendations for Memory Settings Following are recommendations for the memory settings for SQL Server.NOTE: In SQL Server 2012 the location for changing the startup parameters is changed. the following amount of memory is required for specific CPU architecture: (x86): 512KB. is dynamically chosen by SQL Server based on the table contained in the following link: Configure the max worker threads Server Configuration Option http://msdn. The bigger component not yet capped here is the memory required by worker thread stacks. This leaves the operating system with enough memory to work efficiently without having to “grab” memory back from SQL Server. set the maximum memory to 58 GB (64 GB minus 6 [24 cores divided by 4]). 1. (x64): 2048 KB. (IA64): 4096 KB. For further information.

on a x64 bit machine with 32 logical CPUs. For detailed instructions. the total amount of memory that should be reserved is (960*2) = 1920 MB.aspx New SQLOS features in SQL Server 2012 http://blogs. 32bit AWE memory feature is deprecated: The "awe enabled" SQL Server feature is deprecated http://support.6.4) * 16) For example. the maximum number of thread is internally calculated by SQL Server as (512 + (28*16)) = 960 and since on x64 each thread stack is 2MB.2 Lock Pages in Memory To reduce SQL Server paging.msdn.com/b/sqlosteam/archive/2011/01/04/sql-server-memory-managerchanges-in-denali. Enable this privilege for both 32bit and 64-bit servers.msdn. Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server 16 .32bit CPU <= 4 CPU = 256 > 4 CPU = 256 + ((#CPU .com/kb/2644592 For more information on how the memory management has been changed in SQL Server 2012.com/kb/2663912 SQL Server Memory Manager Changes in Denali http://blogs. see the KB article and links below: Memory configuration and sizing considerations in SQL Server 2012 http://support. NOTE: In SQL Server 2012. you can grant the SQL Server service account “Lock Pages in Memory” privilege through the Windows Group Policy editor.4) *8) 64bit CPU <= 4 CPU = 512 > 4 CPU = 512 + ((#CPU .microsoft.microsoft.aspx 1. see How to reduce paging of buffer pool memory in the 64-bit version of SQL Server on the Microsoft® Support site.com/b/sqlosteam/archive/2011/11/10/new-sqlos-features-in-sqlserver-2012.

For more information on this feature you can visit the link below: http://sqlskills. NOTE: This feature is only available for data files. Instant File Initialization (IFI) is only available if the SQL Server database engine service account has been granted the “Perform Volume Maintenance Tasks” (SE_MANAGE_VOLUME_NAME) user right at the OS level on the server and all cluster nodes if a clustered configuration is used. configurations and operations. to solve this problem. log or data. Restore a database or filegroup. use the following steps: On a pure performance perspective. Increase the size of an existing file (including autogrowth operations). to an existing database.com/en-us/library/ms175935(v=sql. SQL Server 2005 (and later versions) can leverage Windows (Windows Server 2003 and later) OS Instant File Initialization (IFI) feature to remove the need to zero-out the file when it is allocated making the process almost instantaneous. but the content of the file is actually what is originally on the disk.3 Instant File Initialization (IFI) When it's necessary to create a SQL Server data file. This can take a quite a bit of time for a very large file which can become critical in disaster recovery and restore operations. Add files. The operating system just allocates the disk space.aspx If the final customer is comfortable in being able to address this type of risk based on his inhouse security protection mechanisms.6. then we recommend to proceed.aspx 1. the operating system has to go through the file and ‘Zero out’ the entire file after it is allocated for one of the following operations:     Create a database.1.microsoft. using this feature is recommended. To grant this right. Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server 17 .com/BLOGS/KIMBERLY/post/Instant-Initialization-What-Why-and-How. but there are some securities implications that should be considered and reviewed in the article below (also apply to SQL Server 2012): http://msdn.7 Guidance for SQL Server Configuration Settings Following is guidance for SQL Server configuration settings. not transaction log files. Members of the Windows Administrator group have this right and can grant it to other users by adding them to the Perform Volume Maintenance Tasks security policy.105).

you can use the following queries: SELECT * FROM sys. Lab testing has shown good results using a fill factor of 10% for small tables (less than 1 GB) and 50% for bigger tables. tree_page_latch_wait_in_ms DESC and SELECT * FROM sys. NULL.dm_os_wait_stats WHERE wait_type LIKE 'PAGELATCH%' To identify which tables and which pages experience latch contention.1 Consider Lower Fill Factor In high-volume deployments (installations with 10 million accounts and more). NULL) ORDER BY [page_latch_wait_in_ms] DESC. you should consider a lower fill factor with PAD_INDEX on for indexes on hot tables with high latch contention.dm_db_index_operational_stats (DB_ID('T24'). Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server 18 . Page latch contention can be identified by examining the “SQL Server: Wait Statistics – Page Latch waits” performance counter and querying the dynamic management view sys. Table candidates for lower fill factor. NULL.1.dm_os_waiting_tasks WHERE wait_type LIKE 'PAGELATCH%' Table 4 shows tables that have been identified as likely candidates for a lower fill factor setting during lab testing: Table FBNK_PL_C002 F_LOCKING FBNK_EB_C004 FBNK_ACCT_ACTIVITY FBNK_ACCOUNT Fill factor 10% 10% 50% 50% 50% Pad_index On On On On On Table 3. Consider a lower fill factor only if there is need to improve the performance and if excessive latch contention has been observed.dm_os_wait_stats using this query: SELECT * FROM sys.7.

Note that when using failover clustering. For more information about the recovery interval option. a longer recovery interval also influences the failover time of the database instance. For more information on this specific feature use this link Database Checkpoints . you must identify these candidates for the application-specific workload profile. once TARGET_RECOVERY_TIME changes to a value bigger than 0. 1. SQL Server uses Windows large-page memory allocations for the buffer pool. For more information about this SQL Server trace flag.7. During lab testing. see the article Recovery Interval Option.7. In SQL Server 2012. Allocating buffer pages is expensive. and turning on trace flag 834 boosts performance. When this trace flag is set.3 Use Trace Flag 834 On computer systems with 64 or more CPU cores. a recovery interval of 5–10 minutes has been determined to be the best setting for T24. Before changing the recovery interval. available in each database as a property that can be used to control checkpoint at database level instead using instance level (that is for all databases) parameter “Recovery Interval”.2 Increase the SQL Server Recovery Interval Increasing the recovery interval server configuration option causes the checkpoint process to occur less often. before going live. see the article Fill Factor. if it’s desired to change the checkpoint process behavior. see Microsoft Support Article 920093. IMPORTANT: Enabling this trace flag will affect time required by SQL Server process to start up and then greatly augment failover time in Cluster configuration. use startup trace flag 834. Every application has different functionality. This can reduce the I/O load driven by checkpoints and improve the overall performance. it’s generally recommended to use database level option for T24 database. There is a new database level option in SQL Server 2012 called “Target Recovery Time (seconds)”. Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server 19 . the database starts to use it instead of automatic checkpoint and it is called indirect checkpoint. and if high latch contention is observed. 1. For more information on the fill-factor option for indexes. For more information on this feature see the following link: The value can be specified in seconds (in the GUI interface) or minutes and will define the maximum time to recover the database after a crash. you should consider its implication on the mean time to recovery and recovery point objectives. When it is set to 0 (zero) the database uses automatic checkpoint for the current database that uses “recovery interval” from server level (sp_configure). then it’s highly recommended to test it on production environment machines directly.Note: This testing has been done with a standardized workload.

Leave value for parameter “Auto Shrink” to “FALSE” (default configuration).7.4 Keep Default Setting for Degree of Parallelism Leave the default setting of max degree of parallelism option unchanged.   Leave value for parameter “Auto Shrink” to “FALSE” (default configuration).1. Leave value for parameter “Auto Update Statistics” to “TRUE” (default configuration). in which case it rejects connections from clients who are not able to support encryption.6 Encrypt Client Communication if Required If required. Leave value for parameter “Auto Create Statistics” to “TRUE” (default configuration).5 Keep Default Setting for Number of Worker Threads Leave the default setting of max worker threads option unchanged. you can enable encrypting client connection communication to SQL Server.7. 1. 1. For more Information. Leave value for parameter “Page Verify” to “CHECKSUM” (default configuration). SQL Server supports Secure Sockets Layer (SSL) to encrypt the data transmitted between a client and the database server. Change the value for parameter “Async Update Statistics” to “TRUE” (change required). 1. Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server 20 .7. SQL Server can be configured to require encrypted connections. see Encrypting Connections to SQL Server and How to: Enable Encrypted Connections to the Database Engine (SQL Server Configuration Manager).7 T24 Database Configuration settings The following recommended settings apply for the T24 database:      Leave value for parameter “Auto Close” to “FALSE” (default configuration).7. Clients can also request encryption when connecting to SQL Server.

Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server 21 .7.2 Increase the SQL Server Recovery Interval”. For modification of default value (0) for parameter “Target Recovery Time (Seconds)”. see section “2.

2. Record IC.2 T24 Configuration Recommendations Following are recommendations for some T24 parameters. instead of releasing and preparing them each time. 2. unless you have a large installation with 10 million accounts or more. which contains key performance and scalability improvements for running T24 on Windows Server and SQL Server. You should leave the default value for the bulk factor parameter (currently 5).2. Each T24 table can have a maximum of 5 different handles (i.FILE. you should use the latest software versions. INSERT.1 Software Recommendations 2. 2. DELETE. For such high-volume installations. There is a trade-off for increasing this parameter value: increasing the bulk factor value improves throughput by processing more statements within each transaction but also increases the possibility of longer transactions and blocking. you should use TAFC version R12. Currently. Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server 22 .e.1 Use the Latest Software Versions For best performance. The default value (currently 500) should be adjusted based on the available application server memory as shown in Table 4.2 Configure the T24 Handle Cache Parameter T24 provides a caching mechanism for OLEDB statement handles. for the following T24 operations: READ. Attribute 14) defines how many Data Manipulation Language (DML) statements are included within each database transaction. Lab testing has demonstrated good results using a bulk factor of 20 for deployments with more than 10 million accounts deployment and a bulk factor of 40 for a deployment with 25 million accounts.. This improves performance by caching and reusing the handles of frequently used statements. The T24 Handle Cache parameter (JEDI_XMLDRIVER_HANDLE_LIMIT) specifies the maximum number of statement handles that can be cached. 2. Use TAFC Version R12. and SELECT).1. UPDATE.COB.2. increasing the bulk factor may improve performance.2 Best Practices for the Application Server Following are some best practices you should use for configuring your T24 application server. Each handle consumes a fixed amount of memory (64 KB) and consumes additional memory needed for data cache.1 Configure the T24 Bulk Factor Parameter The T24 Bulk Factor parameter (in PGM.

2. Lab testing has shown performance gain on application servers with the latest chipsets (e.2.3 Consider Using Hyper-Threading Hyper-Threading should be off by default for T24 application servers. Handle cache parameter scale based on application server memory. Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server 23 . you should consider turning hyper-threading on when using the newer chipsets and observe the influence on performance.g. Intel Nehalem-EX+).App Server Memory < 8 GB >= 8 GB and < 32 GB >= 32 GB and < 64 GB >= 64 GB Handle Cache Parameter 500 (default) 5000 12000 15000 Table 4..

) The cluster can also be used for planned maintenance. see SQL Server 2008 Failover Cluster Rolling Patch and Service Pack Process (still valid on SQL Server 2012). Failover clustering is therefore recommended to provide database-tier HA for SQL Server in a T24 deployment. the processors.) For more information on applying service packs to a failover cluster instance. 3. you can configure jDLS in resilient mode on both database server nodes and have the jDLS in the same failover group as SQL Server. (Note that this results in a brief usage outage. or the SAN connectivity. then the connections are dropped (as well as the locks).1 High Availability Recommendations for the Database In a T24 implementation. jDLS can be installed:    In a resilient mode on two application servers. Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server 24 . In a cluster configuration with jDLS installed on the database server.3 Best Practices for Providing High Availability Failover clustering―a high-availability (HA) solution―can keep applications running in the event of the failure of hardware components. (Note that the time is dependent on the current transactional load and on the configuration. This protects the system from the failure of server components such as the network adapters. and the processes reconnect to the secondary node and take locks via the jDLS of that node. The time to detect a fault and switch to the alternate node is typically less than one minute. and then you can fail the active SQL Server group over to the patched nodes. SQL Server 2008 and SQL Server 2008 R2 are typically installed in a two-node failover cluster to provide an alternate server for the database. (Note that approximately 20% more CPU utilization on the database server is expected in this case. If the jDLS or SQL Server fails. Typically.) On a separate application server. providing redundancy for the LUNs used by SQL Server. the data resides on a SAN with disks configured as RAID 10 (recommended) or RAID 5. The SAN is connected to the servers via two or more HBAs. With SQL Server 2008 and later versions. such as the number of drives or other resources in the resource group. you can apply service packs to inactive nodes. T24 uses database locking from R11 onwards by default and can be turned off if require to use jDLS (T24 lock arbiter). On the database server if enough resources are available.

2 Close of Business (COB) Under normal operation. Because the exact transaction state cannot be ascertained between connection failures and reconnects.3 T24 Recovery When an error or connection failure occurs (e. The listener process spawns and monitors child processes.2 High Availability Recommendations for the Storage As described in section Storage Design Recommendations. a database failover event) during the processing of transactions either online or as a COB agent. If an agent (tSA) fails or aborts because of an error or failover. the tSM also terminates. because an assessment of the failure is required to ensure that it’s a “real” disconnection rather than a temporary network interruption. the controlling T24 process terminates. The new agent resubmits the request.LIST) and is “connected” to the database server.1 Online Recovery For the T24 online processes (Web services.g.3. the T24 COB processes (agents or tSAs) are started and monitored by a manager process (tSM) on each application server. the aborted transaction is resubmitted by the application and is started on a new agent process. You should be sure to consider the disaster recovery options described in the section Best Practices for Disaster Recovery to mitigate the effect of a total SAN failure. and MQ batch). 3. If the error or failover occurs while the tSM is accessing tables in the database (e. but the majority of its components are redundant. and the transaction is then processed as normal.. 3. You cannot automatically restart the tSM by design. The SAN is still a single point of failure. 3. JOB. 3.g.3.. Should a child agent fail. the current transaction is completely rolled back and restarted on another process. and this causes a connection to be established to the secondary database node which lets the COB jobs restart and continue. then the tSM initiates a new agent to replace the failed agent.For general overview on the high-availability features of SQL Server. your storage solution should be a fault-tolerant SAN solution made up of a redundant disk configuration such as RAID 10. Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server 25 . Browser. which then restarts the tSAs letting the COB processes continue from where they left off. an agent listener process is started on each application server. The tSM needs to be manually restarted. leaving no monitoring process to automatically restart the tSAs. This in turn connects to the secondary database node that is active after the failover. which process the transaction requests. see High Availability— Always On Technologies and High Availability with SQL Server 2008 R2.

many customers used FCIs to provide local high availability within a data center and database mirroring for disaster recovery to a remote data center. the result of this work can be viewed in the white paper below: A deployment reference architecture and guidance for implementing an HADR solution for TEMENOS T24 running on the Microsoft Application Platform http://blogs. SAN mirroring requires additional features provided by the SAN vendor. Loss-less DR methods require the use of synchronous replication to the DR site. 4. Prior to SQL Server 2012.com/b/sql_server_isv/archive/2012/05/18/a-deploymentreference-architecture-and-guidance-for-implementing-an-hadr-solution-for-temenost24-running-on-the-microsoft-application-platform. This means that all writes to the storage systems must complete at both sites before the transaction is committed. For protection from natural disasters such as earthquakes.aspx Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server 26 .1 SQL Server 2012 High-Availability and Disaster Recovery (HADR) enhancements SQL Server 2012 AlwaysOn Failover Cluster Instances (FCI) and AlwaysOn Availability Groups (AG) provide a comprehensive high availability and disaster recovery solution. SQL Server provides various technologies for transferring data changes from the primary database to a disaster recovery site. Availability groups leverage Windows Server Failover Clustering (WSFC) functionality. enable multiple features not available in database mirroring. with or without shared replicated SAN storage between sites providing a cost effective solution able to guarantee zero data loss. this design pattern can be replaced with an architecture that uses FCIs for high availability and availability groups for disaster recovery business requirements. The two primary methods of synchronous replication are SAN mirroring and database mirroring in “high-safety” mode. With SQL Server 2012.technet. Microsoft and Temenos built a deployment reference architecture and guidance for implementing a high-availability and disaster-recovery solution for TEMENOS T24 running on the Microsoft Application Platform and leveraging SQL Server 2012 new features. Database mirroring is a feature included with SQL Server. the DR site is frequently located far from the primary site.4 Best Practices for Disaster Recovery Disaster recovery (DR) provides alternate services in the event of a catastrophic physical disruption of the infrastructure at the primary site. Based on these new SQL Server 2012 HADR functionalities. One of the main decisions that you need to make is whether or not you are willing to tolerate potential data loss in the event of complete destruction of the primary site. depending on the line speed. which can increase the time to perform the transaction significantly.

2 SAN Mirroring SAN mirroring synchronizes the contents of one SAN with another and requires very high bandwidth between the two SANs―usually dark fiber is recommended. Note: Asynchronous SAN mirroring is not recommended because it is not possible to determine if the mirror is synchronized after a disaster. see Synchronous Database Mirroring (High-Safety Mode). Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server 27 . a large bandwidth is important in providing responsive.com/sqlcat/b/msdnmirror/archive/2011/12/22/sql-server-2012-alwaysonhigh-availability-and-disaster-recovery-design-patterns. low-latency service. One option to mitigate the cost of the network between the primary site and the DR site is to use two levels of DR sites:   One site is geographically close to the primary site (under 100 kilometers [km]) and uses mirroring to maintain an exact mirror of the primary site. A second site is geographically remote from the primary site and is synchronized using one of the asynchronous methods that can use a lower. synchronous database mirroring guarantees that the mirror and the primary databases are synchronized on all committed transactions.microsoft.4 Asynchronous Replication Methods If a small potential for loss of recently committed transactions is acceptable. 4. For more information. not just the database. less-expensive bandwidth.com/library/hh781257. SAN mirroring is provided by the storage vendor (it is not part of the Windows Server operating system).3 Synchronous Database Mirroring Also known as high-safety mode. but not on the other until much later.aspx 4. 4. It is important to note that only the one database being mirrored is synchronized―no other databases or files are synchronized in the same operation. A benefit of SAN mirroring is that it mirrors all of the storage. synchronization performance can be improved by using asynchronous protocols between primary and secondary database servers. Database mirroring can use any form of TCP connectivity between the two servers. you can visit the links below: Microsoft SQL Server AlwaysOn Solutions Guide for High Availability and Disaster Recovery http://msdn. Using asynchronous protocols means that there is no dependency between the database servers when committing a transaction. A transaction may be committed on one server. but as with SAN mirroring.For more information on SQL Server 2012 AlwaysOn technologies and Availability Group.aspx SQL Server 2012 AlwaysOn High Availability and Disaster Recovery Design Patterns http://sqlcat. and you cannot easily discover any differences.

With these methods.The primary methods of asynchronous replication are asynchronous database mirroring. with values above approximately 15 MBytes/sec for more than an hour during IC processing. Database Mirroring Overview. Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server 28 . log shipping. For more information. the log from the primary site cannot be applied to the DR site once the DR site has been used to store new transactions in its new role as the primary database. and can generate large numbers of log records. With an estimated log compression ratio of 1:4. Transactions that were not shipped to the DR site before switching to the secondary database server are lost. Lab testing with 10 million accounts showed peak log usage of 34 MBytes/sec during COB. and Transactional Replication Overview.5 Recommendations for Connection Bandwidth An important consideration is the connection bandwidth between the primary and DR sites. 4. or transactional replication (server-to-server transactional replication or peer-to-peer replication). COB is the most intensive workload. you should plan at least a 40-Mbit/sec (or 5 MBytes/sec) link to the DR site for configurations with 10 million accounts. Note that when using asynchronous database mirroring or log shipping. see Log Shipping Overview. there is a window of a few seconds to a few minutes where the transactions committed on the primary site are not yet committed on the DR site.

   The reporting database may be configured for simple database recovery because it is not updated by client transactions. views. both for SQL Server 2008 R2 and SQL Server 2012. all previous connections are broken. reports are generated from the same database as online services and using any read-only copy of the production database is not supported for in-thebox T24 reporting capabilities. including snapshots. is Transactional Replication but it’s not recommended since:    It requires modifications to the database schema (triggers. database mirroring (SQL Server 2008 R2) and Availability Group (SQL Server 2012):  Snapshots give only point-in-time data (typically once per day). There are various options that can be considered. Database mirroring can only mirror to one other server.5 Best Practices for Reporting In the default implementation of T24. There are several strict requirements on the structure of the published tables. and it cannot be accessed for reading except through a database snapshot. providing a poor user experience. The overhead on the primary production T24 database may affect heavily database throughput. but it means that if the database becomes corrupted. Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server 29 . For external reporting purposes only. in addition to powerful features not available in any other available technology such as readable secondary Replica that can be used for external reporting purposes. This again means that it is only point-in-time data. When you update the snapshot. a secondary copy of the production database can be created. all connections to the previous snapshot are broken. this lets you skip the backup process. and when updating. outside the context of T24 reporting features. Log shipping or database mirroring keeps the target database in “recovery” mode. Another possible alternative. tables. SQL Server 2012 Availability Group supersedes SQL Server Mirroring functionalities removing the constraint of a single copy. log shipping. you need to re-initialize the subscription from the primary backup. Snapshots can be generated by the SAN or you can use database snapshots. stored procedures). including feeding data warehouses. You cannot mirror a database to both the DR site and to a reporting site.

and a specific transaction mix profile.1.index_id NOT IN (SELECT s.index_id FROM sys.database_id = db_id()) ORDER BY object_name(i.6 Best Practices for Performance Tuning Following is guidance for performance tuning for a T24/SQL Server implementation. 6.object_id = o. you should monitor the usage of the standard indexes and consider dropping indexes that are rarely used.index_id AND s.object_id = i.name AS index_name FROM sys.dm_db_index_usage_stats dynamic management view provides statistics about the index usage from the last time SQL Server was started. and a custom application code that reflects the particular business requirements. close-of-business processes.1 Guidance for Improving Query Performance A typical T24 application consists of T24 core functionality.object_id WHERE o.object_id) AS object_name. You should run this script after installation on all your T24 environments to ensure proper performance of the standard T24 queries. The following sections describe the various performance considerations for the standard T24 core components and for customer-specific queries.dm_db_index_usage_stats s WHERE s. a number of T24 modules for specific banking industry areas. 6. You can use the following query to identify indexes that have not been used since the last time SQL Server was started: SELECT object_name(i.object_id AND s.1 Optimize Standard T24 Queries Temenos provides a post-installation script for creating indexes on the fields that the standard T24 application code uses most often.type = 'U' AND i.objects o ON i.index_id = i. i.indexes i JOIN sys.object_id) ASC The sys. As every application has different functionality. Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server 30 .

Identify slow-running queries. s.object_id = i. SUM(query_Stats. total amount of CPU time. in microseconds. To improve query performance.execu tion_count) AS "avg logical writes".executio n_count) AS "avg CPU Time". SUM(query_stats.2 Optimize Customer-Specific T24 Queries For queries used by customer-specific code. you can use the sys. SUM(query_stats. SUM(query_Stats.index_id.dm_db_index_usage_stats s JOIN sys. 1.*. and verify the benefit of the optimizations. system_seeks + system_scans + system_lookups AS system_reads.index_id = i.. To identify slow-running queries (or just queries which can be optimized to help shorten the COB time).execut ion_count) AS "avg logical reads". SUM(query_stats. user_updates.e. The following query selects the top 50 SQL Server statements ordered by the total CPU time (i. The optimization of COB queries is critical for reducing the total duration of the COB.dm_exec_query_stats dynamic management view.index_id AND s.execution_count) AS "executes".object_id WHERE s.total_logical_reads) AS "total logical reads".total_worker_time)/SUM(query_stats.You can use the following query to monitor the index usage on a regular basis: SELECT object_name(i.database_id = db_id() AND i.name AS index_name.indexes i ON s. you should go through the following steps in order to identify performance issues. i.object_id) AS object_name.total_logical_writes) AS "total logical writes".statement_text) AS "statement text" FROM (SELECT QS. SUM(query_stats. system_updates FROM sys.type <> 0 ORDER BY user_reads DESC 6.  COB queries: The close-of-business (COB) calculations are generally the most processing-intensive tasks in T24.total_logical_writes)/SUM(query_stats. Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server 31 .total_worker_time) AS "total CPU time". MIN(query_stats. for all executions of each statement): SELECT TOP 50 SUM(query_stats. consider optimizations. user_seeks + user_scans + user_lookups AS user_reads. start by identifying slow-running queries.total_logical_reads)/SUM(query_stats.1.

If you identify multiple long-running queries involved in the online operations. After identifying slow-running queries that are good candidates for optimization. and consider the number of executions of each query. you should test them and measure the CPU time and I/Os. This can be done using the sys. identify slow-running operations in the user interface (UI) based on user feedback and try to reproduce them (on a test database system).query_hash ORDER BY 1 DESC After completion of the COB. These are the biggest T24 tables. After identifying the SQL statements.SUBSTRING(ST.text) ELSE QS. CATEG_ENTRY. containing huge number of records. consider the following:  If there are queries on tables STMT_ENTRY. The application logic and the jQL SELECT queries on these tables should be reconsidered and. if possible. ACCT_ENT_TODAY is much smaller in size.text. Compare these jQL queries to the previously identified SQL Server statements to select queries that are good candidates for optimization. (QS. then these are most likely jQL SELECT queries in a custom-developed code. or RE_CONSOLSPEC_ENTRY using a “where” clause that is different from RECID = <value>. Consider optimizations. Use the SQL Server Profiler to capture the corresponding SQL Server queries. Optimizing a query which is executed very often is more important than optimizing queries executed only few times. you should look at F_JOB_TIMES for long COB job times. the Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server 32 .statement_end_offset END . There should generally be no queries on these tables with a search condition using any fields (other than the RECID).  Online Processing: For online processing. ((CASE statement_end_offset WHEN -1 THEN DATALENGTH(ST. 2. search the content of the T24 log file &COMO& to match the jQL queries corresponding to the long-running jobs. sort the queries based on the average CPU time.statement_start_offset)/2) + 1) AS statement_text FROM sys. instead of using STMT_ENTRY. When you have identified the long-running jobs.dm_exec_sql_text(QS. you can use the table ACCT_ENT_TODAY in many cases.dm_exec_query_stats AS QS CROSS APPLY sys. For example.dm_exec_query_stats dynamic management view and the query described in the previous section. and there is usually heavy activity on these tables.QS. rewritten.statement_start_offset/2) + 1.sql_handle) as ST) AS query_stats GROUP BY query_stats.

e. Using this function.XMLRECORD FROM F_HOLD_CONTROL t WHERE t.exist(N'/row/c2[. Use scalar promotion.t.RECID.RECID. and the benefit in query performance is usually not significant.  If a query has a search condition on a single-value field. the following query uses specifically the eighth value of a multi-value field in the search condition: SELECT t. inserts. The detailed steps to promote a single-value XML field are as follows: 1. then consider scalar promotion (see step 3). The return value of the function should be a single scalar value. a relational index can be created on the computed column to improve the query performance. An example of this type of query is: SELECT t. and the rows in the table contain the key of the entries that have been made into that account during the current business day.) Create a persisted computed column for the specific field. Do not create XML indexes on T24 XMLRECORD fields. Too many indexes may degrade the overall performance. then consider scalar promotion (see step 3). A single-value field (or even a specific value of a multi-valued field) that is part of the XMLRECORD can be “promoted” as computed column of the table and be used in relational search conditions. Indexes improve the performance of select queries.XMLRECORD.. Further.XMLRECORD. The impact on transaction latency is too high. As a general rule. you should avoid creating more than seven indexes on a table. For example.=12345]') = 1  Consider the number of promoted columns and indexes per table. but also increase the time that is required to perform modifications (i. updates.="NEW. Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server 33 . the computed column should be added to the table and persisted.LOAN.XMLRECORD FROM FBNK_CARD_ISSUE t WHERE t. deletes) to the underlying table.t.exist(N'/row/c14[@m="8"][. The minimum required T24 version for scalar promotion is R10 SP5. Create a user-defined function that evaluates the value of the field.key is the account number.  3.REPORT"]') = 1  If a query has a search condition on a specific multi-valued field (specific local reference field).

example 1 CREATE INDEX ix_HOLD_CONTROL_C2 ON F_HOLD_CONTROL(C2) -. 'nvarchar(35)') END ALTER TABLE F_HOLD_CONTROL ADD C2 AS dbo. 'integer') END ALTER TABLE FBNK_CARD_ISSUE ADD C14_8 AS dbo.udf_CARD_ISSUE_CUSTOMER(XMLRECORD) PERSISTED 2. After creating the persisted computed column. Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server 34 .Following are two examples of scalar promotion: -.) Create non-clustered index on the computed column.value('(/row/c14[@m="8"]/text())[1]'. T24 automatically translates the queries to use that column relational in the “where” clause if there is a search condition on that field.example 2 CREATE INDEX ix_CARD_ISSUE_CUSTOMER ON FBNK_CARD_ISSUE(C14_8) Once there is a promoted column for a specific field in the table.value('(/row/c2/text())[1]'.scalar promotion of specific multi-valued field CREATE FUNCTION udf_CARD_ISSUE_CUSTOMER(@xmlrecord XML) RETURNS integer WITH SCHEMABINDING BEGIN RETURN @xmlrecord.scalar promotion of single valued field CREATE FUNCTION udf_HOLD_CONTROL_C2(@xmlrecord XML) RETURNS nvarchar(35) WITH SCHEMABINDING BEGIN RETURN @xmlrecord.example 2 -.udf_HOLD_CONTROL_C2(XMLRECORD) PERSISTED -.example 1 -. create an index for this column: -.

e. You can use the queries described in section Standard T24 Queries for this purpose..t.  For scalar promotion (promoted and indexed fields):  Verify the query translation.XMLRECORD FROM FBNK_CARD_ISSUE t WHERE c14_8 = 12345 In this case. Verify optimizations. After promoting the field “c2”. you can use the SET STATISTICS PROFILE ON statement to display execution plan information.  For jQL queries changed in the application:  Execute the jQL query on the jsh> interface. deletes) at the same time.4.XMLRECORD FROM FBNK_CARD_ISSUE t WHERE t.XMLRECORD. use the sys. Consider the ratio between index reads and index writes.dm_db_index_usage_stats dynamic management view to verify the index usage. You can use the query described in the Close-of-Business section of the document for this purpose.RECID.exist(N'/row/c14[@m="8"][. Verify that the changes are successful and measure the impact of the optimizations. Additionally. and verify the performance. T24 uses a query syntax such as: SELECT t. T24 should translate the query as: SELECT t.  Prove that the index is used by reproducing the query and verifying the actual execution plan. You should monitor the index usage statistics on a regular basis.t. index lookup on ix_CARD_ISSUE_CUSTOMER is used. updates.  After using the application for a period of time (e.g. Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server 35 . Without scalar promotion.  Verify the performance of the query has improved. You can run the query in SQL Server Management Studio and activate the icon “Include Actual Execution Plan” on the SQL Editor toolbar..=12345]') = 1 The execution of this query usually uses a table scan to retrieve the results. you should measure the CPU time and I/O operations on the SQL Server. couple of hours or days) or after running COB. inserts. keeping in mind that an index usually improves the performance for read operations but slows down modifications (i.RECID. Alternatively.

6. May indicate a large amount of disk fragmentation. Metric Database File Sizes (including tempdb) Log File Sizes Processor/% Processor Time: All Instances Average Disk Queue Length Average Disk sec/transfer Disk Bytes/sec for each LUN Paging in Pages/sec Network Interface Bytes Received/sec and Network Interface Bytes Sent/sec Table 5. you should create a performance baseline and monitor trends in resource consumption against the performance baseline so that you can predict future bottlenecks and determine when resource limitations might begin to impact performance as your customer base grows.5. In some cases.2 Recommendations for Monitoring Performance of the Database Tier You should perform system monitoring during development of your system and periodically during production. Need for increased network capacity or segmentation. Need for additional memory. tables used for application-specific purposes in the application layer. Monitoring plan Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server 36 Predicts Need for expansion of files or storage. Need to backup transaction log more often. Once in production. with visibility into resource utilization for consolidation and improved efficiencies across the application lifecycle. Before “going live. Note that SQL Server 2008 R2 and SQL Server 2012 introduce new application and multi-server management features. Additional processors. If you are not able to achieve sufficient performance improvement to specific queries or COB jobs by applying steps 1–4 above. Storage configuration too slow. then consider using concat files. concat files can also be used as a “logical index” in T24. slow disks.) Need to spread data across more LUNs. see SQL Server 2008 R2 Application and Multi-Server Management and Automated Administration Across an Enterprise. (Should be 10 ms or less. which can help you manage the T24 database environment more efficiently at scale. You should not worry about seeing short spikes in utilization or high consumption during processes that are operating at an acceptable performance level. Table 5 shows metrics that your monitoring plan should include. For more information. . Use T24 logical optimization.” look for bottlenecks and gauge your ability to scale to your expected long-term workload. or disk failures.

updating database statistics. For more information about creating maintenance plans. less disk I/O. and less time but incurs more CPU cycles as overhead. Your organization may have specific requirements for recovery times. Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server 37 .2 Implement a Backup Schedule A suggested schedule is a weekly full backup. see the article Tuning the Performance of Backup Compression in SQL Server 2008 on SQLCAT. and identifying and correcting excessive fragmentation. this requires less storage. There is also a global setting to compress all backups taken on a server instance by default. For more information.) The RESTORE command automatically detects that a backup is compressed and decompresses the backup during the restore operation. and a log backup every hour. and you should discuss these with a qualified database administrator to determine a backup profile that meets these requirements. the backup file is compressed as it is written. (This setting is accessed by using the Database Settings tab in the Server Properties dialog box or by running sp_configure with backup compression default set to 1. With SQL Server 2008 (and later versions) backup compression. Your maintenance schedule should include implementing a backup strategy.1 Guidance for Backing Up the Database You should back up the T24 database regularly to protect your data. a daily differential backup. 7. Frequent full backups can improve the speed of recovery since it is not necessary to restore as many log files. The compression is achieved by specifying the WITH COMPRESSION clause in the BACKUP command or by selecting compression the Options page in the Back Up Database dialog box. see Appendix 1: Create a Maintenance Plan to Back Up the Temenos Application Database and Appendix 2: Create a Maintenance Plan to Back Up the System Databases. rebuilding and reorganizing indexes.1. 7.7 Best Practices for System Maintenance You should perform regular maintenance tasks to keep SQL Server running optimally. You should also back up the transaction log frequently to protect your data and to keep the transaction log file from growing too large. 7. Frequent log backups can keep the size of the log file smaller and can also minimize data loss when implementing log shipping for disaster recovery.com.1 Use Backup Compression Backing up a large database can require a significant amount of time and a large amount of disk space for the backup file(s).1.

Heavily fragmented indexes can degrade query performance and cause your application to respond slowly. For more information. based on the key value. Backups of these system databases let you restore and recover the SQL Server system in the event of system failure. these modifications can cause the information in the index to become scattered or fragmented in the database.3 Back Up System Databases SQL Server maintains a set of system-level databases (called system databases) that are essential for the operation of a server instance. 7.g. For partitioned indexes built on a partition scheme. Reliable statistics let the optimizer accurately assess the cost of different query plans and then choose a high-quality plan. If any database uses replication on the server instance. For more information. you must also implement a backup schedule for the target database(s). Fragmentation exists when indexes have pages in which the logical ordering. it is recommended to keep the AUTO_CREATE_STATISTICS and AUTO_UPDATE_STATISTICS database options on (which is the default setting). so it does not need to be backed up.It is recommended to schedule the full backup to run after the COB processing and after any index maintenance tasks (e.. Statistics are used by the query optimizer to estimate the selectivity of expressions and thus the size of intermediate and final query results.2 Recommendations for Updating Statistics SQL Server collects statistics about individual columns (single-column statistics) or sets of columns (multi-column statistics). Several of the system databases must be backed up after every significant update: msdb. 7.3 Recommendations for Reorganizing or Rebuilding Indexes The SQL Server Database Engine automatically maintains indexes whenever insert. you can rebuild or reorganize a complete index or a single partition of an index. such as the loss of a hard disk. If you implement peer-to-peer replication. see the article Statistics Used by the Query Optimizer in Microsoft SQL Server 2008. Over time. there is a distribution system database that must also backed up. For step-by-step guidance for manually updating statistics using a maintenance job. master. see Appendix 3: Update Statistics.1. The distributor database operates in simple recovery mode. 7. Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server 38 . does not match the physical ordering inside the data file. see the article Considerations for Backing Up and Restoring System Databases. You can defragment indexes by either reorganizing or rebuilding. update. index reorganize or index rebuild). and model. or delete operations are applied to the underlying data. For a typical T24 installation.

Use the ALTER INDEX statement with the REORGANIZE clause (replaces the DBCC INDEXDEFRAG statement in Microsoft® SQL Server® 2000).dm_db_index_physical_stats. analyze the index to determine the degree of fragmentation. Table 5. avg_fragmentation_in_percent > 10 percent and < = 80 percent > 80 percent Corrective statement ALTER INDEX REORGANIZE ALTER INDEX REBUILD Table 6.dm_db_index_physical_stats.3.1 Reorganize Indexes Reorganize an index when the index is not heavily fragmented. Note that very low levels of fragmentation (less than 10%) should not be addressed by either of these commands because the benefit from removing such a small amount of fragmentation is almost always vastly outweighed by the cost of reorganizing or rebuilding the index.dm_db_index_physical_stats function. use the PARTITION clause of ALTER INDEX. You can then use Table 7 as a guide to determine the best method to correct the fragmentation. Table 6 shows some of the information returned by the sys. or all indexes in all databases. 7. To reorganize a single partition of a partitioned index. you have access to the fragmentation levels available in defined columns at any given time. all indexes on a table or indexed view. Using this function. Average number of pages in one fragment in an index. Corrective defragmentation method to use. The total number of index or data pages. Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server 39 . all indexes in a database. The white paper Microsoft SQL Server 2000 Index Defragmentation Best Practices can provide additional guidance. Columns returned from sys. Column avg_fragmentation_in_percent fragment_count avg_fragment_size_in_pages page_count Description The percent of logical fragmentation (out-of-order pages in the index). you can detect fragmentation in a specific index. By using the DMF sys.To decide which defragmentation method to use. The number of fragments (physically consecutive leaf pages) in the index.

hotfixes.) can help prevent or fix problems.1 SQL Server 2012 Setup Product Update Product Update is a new feature in SQL Server 2012 Setup.  CREATE INDEX with the DROP_EXISTING clause. or a network share for applicable updates. etc. Cumulative Updates. Each method performs the same function. disk space is reclaimed by compacting the pages using the specified or existing fillfactor setting. but there are advantages and disadvantages to consider. and improve how the computers work. Product Update can search Microsoft Update. it downloads and integrates them with the current SQL Server setup process. Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server 40 .4 Recommendations for Update Management A general recommendation is to keep your Microsoft software up to date with the most recent software updates. fragmentation is removed. Consider testing and applying software updates on a regular basis. See Reorganizing and Rebuilding Indexes for more information. or service pack plus cumulative update. see Update Management TechCenter and SQL Server 2008 failover cluster rolling patch and service pack process (also apply to SQL Server 2012). Also.The reorganize process uses minimal system resources. a local folder. For more information on applying updates. it does not block running queries or updates. reorganizing is automatically performed online. Product Update can pull in a cumulative update. In doing this. that the clustered index cannot be rebuilt online if the underlying table contains XML data type.4. The process does not hold long-term blocking locks.3. service packs. This statement replaces the DBCC DBREINDEX statement. Note. The following methods can be used to rebuild clustered and non-clustered indexes:  ALTER INDEX with the REBUILD clause.g. Software Updates (e. It integrates automatically the latest SQL Server 2012 product updates with the main product installation so that the main product and its applicable updates are installed at the same time. and the index rows are reordered in contiguous pages (allocating new pages as needed). 7. Appendix 4: Reorganize and Rebuild Indexes provides step-by-step guidance on creating maintenance plans for these operations. This can improve disk performance by reducing the number of page reads required to obtain the requested data. service pack. After Setup finds the latest versions of the applicable updates.2 Rebuild Indexes when Necessary Rebuilding an index drops the index and creates a new one. enhance the security of your computers. 7.. therefore. 7. Windows Server Update Services (WSUS).

Your update strategy will depend on your organization’s policies.For more information on this feature see the links below: New features in SQL Server 2012 setup: Product Updates in SQL Server 2012 Installation http://msdn.4.4. enterprises should Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server 41 .aspx 7.2 Run Anti-Virus Checks During Non-Peak Hours While every environment and infrastructure will have its own unique considerations.aspx Product Updates in SQL Server 2012 Installation http://msdn.microsoft.com/en-us/library/hh231670.3 Consider Running Windows Updates on a Test Server before Production As with anti-virus checks. 7. run scheduled virus checks during non-peak hours. you should consider avoiding running real-time anti-virus checks. as well as those of Temenos. you should carefully consider the unique characteristics of your infrastructure when deciding on a plan for patch management.microsoft. As a general rule.com/en-us/library/hh231670(v=SQL.110). enterprises should manage the update process in a different way than desktop users. instead.

defining a specific strategy and installing the updates on a test server to verify their impact before installing them in production.implement their own update services. For more information. Also see the Microsoft Support article Guidelines for choosing antivirus software to run on the computers that are running SQL Server. see Windows Server Update Services. Security patching is an important subset of updates. Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server 42 . You can find information about security patching in Ten Principals of Microsoft Patch Management.

The links in the section that follows provide even more information. part 2 Storage Configuration:     Predeployment I/O Best Practices Storage Top 10 Best Practices DiskPart Disk Partition Alignment Best Practices for SQL Server  SQL Server Configuration:       Isolation Levels in the Database Engine Optimizing tempdb Performance Configure Server Startup Options Recovery Interval Option Fill Factor How to reduce paging of buffer pool memory in the 64-bit version of SQL Server  High Availability and Disaster Recovery:     A deployment reference architecture and guidance for implementing an HADR solution for TEMENOS T24 running on the Microsoft Application Platform Microsoft SQL Server AlwaysOn Solutions Guide for High Availability and Disaster Recovery SQL Server 2012 AlwaysOn High Availability and Disaster Recovery Design Patterns Introducing SQL Server 2012 AlwaysOn 43 Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server . see the link below: TEMENOS T24 and SQL Server 2012 running on Intel Xeon processor-based servers set a new world record in the latest high-water benchmarking tests Following is a list of technical articles that can help you learn more about specific Windows and SQL Server topics:  Windows Configuration:       Receive-Side Scaling Introduction to Receive-Side Scaling Receive-Side Scaling Enhancements in Windows Server 2008 Desktop Heap Overview Desktop Heap. Using the best practices described in this white paper can help optimize the performance of the database tier. provides financial institutions with a complete banking solution. coupled with Microsoft SQL Server database software. For the latest benchmarking results on SQL Server 2012.8 Summary TEMENOS T24.

Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server 44 .Application and Multi-Server Management SQL Server 2008 failover cluster rolling patch and service pack process Update Management TechCenter Troubleshooting Performance Problems in SQL Server 2008 See the SQL Server Best Practices portal for technical white papers. the SQL Server Best Practices Toolbox. Top 10 Lists. and other resources.             Overview of AlwaysOn Availability Groups High Availability with SQL Server 2008 Failover Clustering in Windows Server 2008 R2 SQL Server 2008 Failover Clustering Database Mirroring Overview Synchronous Database Mirroring (High-Safety Mode) Database Mirroring Best Practices and Performance Considerations Log Shipping Overview Transactional Replication Overview Best Practices for Replication Administration Replication Security Best Practices Peer-to-Peer Transactional Replication Database Maintenance          Considerations for Backing Up and Restoring System Databases Tuning the Performance of Backup Compression in SQL Server 2008 Best Practices for Recovering a Database to a Specific Recovery Point Statistics Used by the Query Optimizer in Microsoft SQL Server 2008 Reorganizing and Rebuilding Indexes SQL Server 2008 R2 .

Right-click Maintenance Plans. because you will later select both full and transaction log backups. Select the plan properties. Click Next. Open SQL Server Management Studio. and then type an appropriate name for this Temenos application database backup plan. Click Separate schedules for each task. 2. Figure 2. Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server 45 . and then expand the Management Plans node. expand the Management node. 3. Click Maintenance Plan Wizard. Figure 3. The following step-by-step instructions guide you through the process. 1.9 Appendix 1: Create a Maintenance Plan to Back Up the Temenos Database It is important to create a maintenance plan to back up the Temenos database. click Maintenance Plan Wizard.

5. Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server 46 . select the historical data you want to delete and the schedule. Click Next. select Clean Up History. Select maintenance tasks. The following figures show examples of options you may want to select. Back Up Database (Transaction Log). Click Next twice. Figure 4. Options to define the history cleanup task. a. As you complete the Maintenance Plan Wizard. Figure 5. On the Select Maintenance Tasks dialog box. and Maintenance Cleanup Task. On the Define History Cleanup Task dialog box. Back Up Database (Full).4. you should select options based on the needs of your organization.

b. On the Define Back Up Database (Full) Task dialog box. click on These databases. Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server 47 . Click OK. and select the T24 user database in the Database(s) box. Figure 6. Options to configure the backup database task.

Options to set the backup parameters. select the frequency and duration of full backups. d. after the COB processing. Figure 8.c. Figure 7. It is recommended to schedule the full backup to be executed. Click OK. Click Next. On the Define Back Up Database (Full) Task dialog box. specify information about the full backup. Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server 48 . Options to select for the job schedule properties. On the Job Schedule Properties dialog box.

On the Define Back Up Database (Transaction Log) Task dialog box. select the frequency and duration of transaction log backups. Options to set the frequency and duration of transaction log backups. Click OK. f. configure the transaction log backup. Options to configure the transaction log backups. Figure 9. Figure 10.e. On the Job Schedule Properties dialog box. Click Next. Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server 49 .

Review your selections. select whether to write the report to text file or send the report through email. On the Select Report Options dialog box. 6.g. Figure 11. Options to define the maintenance cleanup tasks. Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server 50 . Click Next. configure the cleanup tasks. On the Define Maintenance Cleanup Task dialog box. h. Click Next. and then click Finish.

Click Next. 2. Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server 51 . 3. The following step-bystep instructions guide you through the process. click Maintenance Plan Wizard. and then type an appropriate name for this Temenos system database backup plan. 1. and click Change to select the frequency and duration of transaction log backups. Right-click Maintenance Plans. and then expand the Management Plans node. click Single schedule for the entire plan or no schedule. expand the Management node. On the Select Plan Properties dialog box. Click Maintenance Plan Wizard. Figure 13.10 Appendix 2: Create a Maintenance Plan to Back Up the System Databases You should create a maintenance plan to back up the system databases. Open SQL Server Management Studio. Figure 12. Select the plan properties.

5. Figure 15.4. make sure that the tasks appear in the order shown in Figure 15. Select the maintenance tasks. Figure 14. Click Next. Back Up Database (Full). On the Select Maintenance Tasks dialog box. On the Select Maintenance Task Order dialog box. Click Next. Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server 52 . Verify the order of the maintenance tasks. and Maintenance Cleanup Task. select Clean Up History.

As you complete the Maintenance Plan Wizard. Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server 53 . The following figures show examples of options you may want to select. select System databases. Figure 16.6. you should select options based on the needs of your organization. a. Click OK. Select the system databases. On the Define Back Up Database (Full) Task dialog box.

b. Define the full backup task by selecting from the various options. Click Next.

Figure 17. Options to define the full backup.

Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server

54

c. Define the maintenance cleanup task by selecting from the various options. Click Next.

Figure 18. Options to define the maintenance cleanup tasks.

d. Define the history cleanup task by selecting from the various options. Click Next.

Figure 19. Options to define the history cleanup tasks.

Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server

55

e. Select the report options you want. Click Next.

Figure 20. Options for reporting.

7. Review your selections, and click Finish.

Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server

56

3. and click Single schedule for the entire plan or no schedule. and click Maintenance Plan Wizard. Click Change to select the frequency and duration of statistics updates. expand the Management node. 2. Select the plan properties. 1. Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server 57 . Open SQL Server Management Studio.11 Appendix 3: Update Statistics You should create a maintenance plan to update statistics. On the Select Plan Properties dialog box. Click Maintenance Plan Wizard. and then expand the Management Plans node. type an appropriate name for this statistics update plan. Right-click Maintenance Plans. The following step-by-step instructions guide you through the process. Figure 22. Figure 21.

Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server 58 . Select the update statistics task. and then click Next.4. On the Select Maintenance Tasks dialog box. Figure 24. Click OK. select the frequency and duration of the statistics updates on the Job Schedule Properties – Update Temenos Statistics (FullScan) dialog box. Select the frequency and duration of updates. Based on your organization’s needs. Figure 23. select only Update Statistics. Click Next. 5.

click on These databases. Figure 26. On the Select Maintenance Task Order dialog box. Click OK. Make no changes on the task order dialog box. Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server 59 . Click Next. On the Define Update Statistics Task dialog box.6. make no changes. 7. Figure 25. and select the T24 user database in the Database(s) box. Select the Temenos user database.

Under Scan type. Click Next. 10. select report options based on your organization’s needs. select Tables and views in the Object box. 9. Figure 27. On the Select Report Options dialog box. On the Define Update Statistics Task dialog box. Review your selections. and then click Finish. Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server 60 . Define parameters for the update statistics task. Click Next. Select report options. Figure 28.8. click Full scan.

dm_db_index_physical_stats function -.Declare the cursor for the list of partitions to be processed. DECLARE @indexname nvarchar(130).0 AND index_id > 0. see the article sys. For more information about database compatibility levels. DECLARE @partitioncount bigint. -. DECLARE @frag float. index_id AS indexid.Ensure that a USE <databasename> statement has been executed first. NULL. 'LIMITED') WHERE avg_fragmentation_in_percent > 10. NULL. -. NULL .dm_db_index_physical_stats (DB_ID(). For more information.and convert object and index IDs to names. To resolve the error. DECLARE @command nvarchar(4000). -. partition_number AS partitionnum. replace DB_ID() with a valid database name. DECLARE @partitions bigint. DECLARE @indexid int. DECLARE @objectname nvarchar(130). Note that an error is generated if the current database has a compatibility level of 80 or less.dm_db_index_physical_stats (Transact-SQL). avg_fragmentation_in_percent AS frag INTO #work_to_do FROM sys. The second script rebuilds all indexes with an average fragmentation greater than 80 percent.12 Appendix 4: Reorganize and Rebuild Indexes The following script samples automatically reorganize or rebuild all partitions in a database. SELECT object_id AS objectid. DECLARE @schemaname nvarchar(130). Executing these scripts requires the VIEW DATABASE STATE permission. DECLARE @partitionnum bigint. These examples use DB_ID() instead of specifying particular database name.Reorganize indexes -.Conditionally select tables and indexes from the sys. The first one reorganizes all indexes that have an average fragmentation between 10% and 80%. see sp_dbcmptlevel (Transact-SQL).0 AND avg_fragmentation_in_percent <= 80. SET NOCOUNT ON. Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server 61 . DECLARE @objectid int.

GO -.schema_id = o.Close and deallocate the cursor. Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server 62 .schema_id WHERE o.objects AS o JOIN sys. WHILE (1=1) BEGIN. FETCH NEXT FROM partitions INTO @objectid.Ensure that a USE <databasename> statement has been executed first.partitions WHERE object_id = @objectid AND index_id = @indexid. PRINT N'Executed: ' + @command. IF @partitioncount > 1 SET @command = @command + N' PARTITION=' + CAST(@partitionnum AS nvarchar(10)).' + @objectname + N' REORGANIZE'. @schemaname = QUOTENAME(s. OPEN partitions. DECLARE @partitioncount bigint. -. SET NOCOUNT ON. SET @command = N'ALTER INDEX ' + @indexname + N' ON ' + @schemaname + N'.schemas as s ON s. DROP TABLE #work_to_do. DECLARE @objectid int.rebuild indexes -.name) FROM sys. @partitionnum.name).Open the cursor. @indexid. -. -. END. SELECT @objectname = QUOTENAME(o. SELECT @partitioncount = count (*) FROM sys.DECLARE partitions CURSOR FOR SELECT * FROM #work_to_do. CLOSE partitions.object_id = @objectid. IF @@FETCH_STATUS < 0 BREAK.indexes WHERE object_id = @objectid AND index_id = @indexid. SELECT @indexname = QUOTENAME(name) FROM sys. -. EXEC (@command).Drop the temporary table.Loop through the partitions. @frag. DECLARE @indexid int. DEALLOCATE partitions.

dm_db_index_physical_stats (DB_ID().Declare the cursor for the list of partitions to be processed.and convert object and index IDs to names.schemas as s ON s. -. IF @@FETCH_STATUS < 0 BREAK. OPEN partitions. @command nvarchar(4000). WHILE (1=1) BEGIN.Open the cursor. @partitionnum bigint. @schemaname = QUOTENAME(s. @partitionnum. @objectname nvarchar(130).Conditionally select tables and indexes from the sys. -. index_id AS indexid. 'LIMITED') WHERE avg_fragmentation_in_percent > 80. SELECT @indexname = QUOTENAME(name) FROM sys. SET @command = N'ALTER INDEX ' + @indexname + N' ON ' + @schemaname + N'. @frag float. -.partitions WHERE object_id = @objectid AND index_id = @indexid.objects AS o JOIN sys. SELECT @partitioncount = count (*) FROM sys.DECLARE DECLARE DECLARE DECLARE DECLARE DECLARE DECLARE @schemaname nvarchar(130).schema_id WHERE o.Loop through the partitions.indexes WHERE object_id = @objectid AND index_id = @indexid. -. NULL.name) FROM sys. FETCH NEXT FROM partitions INTO @objectid. SELECT object_id AS objectid.schema_id = o. @frag.' + @objectname + N' REBUILD'.name). IF @partitioncount > 1 Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server 63 . NULL. avg_fragmentation_in_percent AS frag INTO #work_to_do FROM sys.dm_db_index_physical_stats function -. @indexname nvarchar(130). SELECT @objectname = QUOTENAME(o. @indexid. partition_number AS partitionnum. NULL . DECLARE partitions CURSOR FOR SELECT * FROM #work_to_do. @partitions bigint.0 AND index_id > 0.object_id = @objectid.

Right-click Jobs. PRINT N'Executed: ' + @command. -. perform the following steps: 1.SET @command = @command + N' PARTITION=' + CAST(@partitionnum AS nvarchar(10)). END. the index maintenance tasks (reorganization or rebuild) should be performed after COB processing and before a full backup is executed.Drop the temporary table. Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server 64 . CLOSE partitions.Close and deallocate the cursor. DROP TABLE #work_to_do. Ideally. Figure 29. DEALLOCATE partitions. and click New Job. Click New Job. GO You should generally create a nightly job for index reorganization (using the 1 sample script) and a weekly job for index rebuild (based on the 2 sample script). To create a nightly or weekly job to perform the reorganizing or rebuilding. -. EXEC (@command).

Figure 31.2. and copy the script sample into the Command field. Figure 30. and parse it. Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server 65 .g. 3. select the type Transact-SQL script (T-SQL). Click OK. Name the job so it can be easily identified as the reorganization or rebuilding index. Enter the step name (e.. Reorg or Rebuild). click Parse. Click Steps. Copy the script sample. specify the T24 database name. To make sure that there are no errors in the T-SQL script. Name the maintenance job. and then click New.

Figure 32. Configure job step advanced options. 5. depending on the needs of your organization. schedule the job to run nightly or weekly. Click OK. On the New Job Schedule dialog box. change the On Success action to Quit the job reporting success.4. and click OK. Figure 33. Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server 66 . Options for scheduling jobs. Select the Advanced page.

Configure job notifications. (Note that database email must be configured correctly for the notifications to work. On the Job Properties – Temenos Index Reorg/Rebuild dialog box.) Click OK. configure the notifications for the job based on your organization’s needs. Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server 67 .6. Figure 34.

all SQL Server security hotfixes approved by TEMENOS installed  Recommended non-security hotfixes installed for Cluster component  Lock pages in memory privilege granted to SQL service account  Perform volume maintenance task user right granted (see security section)  Antivirus exclusions configured for SQL Server files  Windows Server Power Plan checked  SQL Server configuration:  Trace flag 1118. or Microsoft® SQL Server® 2008 R2 Enterprise. added to SQL Server startup parameters  SQL Server configuration parameter “Max Server Memory” set to proper value  Database log and data files are properly sized for T24 and TEMPDB databases  AUTO_CREATE_STATISTICS and AUTO_UPDATE_STATISTICS options for T24 database are turned on (default setting)  SQL Server maintenance jobs created and active  T24 indexes on standard fields created (post-installation script) Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server 68 .13 Appendix 5: Installation Check List Use the following checklist to assure a successful T24 installation:  Windows Server version: 64-bit edition of Windows Server® 2008 R2 Enterprise  SQL Server 64bit version: Microsoft® SQL Server® 2008 Enterprise Service Pack 2 (SP2). and eventually Trace flag 1117. or Microsoft® SQL Server® 2008 R2 Datacenter. or SQL Server 2012 Enterprise Edition  T24 / TAFC Version: R12 or higher  Configuration settings:  Service Pack 1 for Windows Server® 2008 R2 Enterprise installed  All security hotfixes installed for the Operating System.