Optimizing SQL Server For Temenos T24
March 9, 2023 | Author: Anonymous | Category: N/A
Short Description
Download Optimizing SQL Server For Temenos T24...
Description
Best Practices for Running TEMENOS T24 on Microsoft SQL Server Ser ver 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 t he 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, t ransfers, higher security-trade volumes, and quicker close-of-business processes; T24 customers can also benefit from open, state-of-the-art st ate-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 co nfiguring 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“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 use this document for your internal, reference purposes. 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 1.1.1
Use the Latest Software Versions....................... 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..................... 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
2
SERVER RECOMMENDATIONS ............. ........................... ............................ ............................ ............................ ............................ ............................. ............................ ............. 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 D efault Setting for Number of Worker Threads ........................ ............................................ ....................................... ......................... ...... 20
1.7.6
Encrypt Client Communication if Required ...... ......................... ...................................... ...................................... ....................................... ....................... ... 20
1.7.7
T24 Database Configuration settings.......................... settings.............................................. ........................................ ....................................... ............................ ......... 20
BEST PRACTICES FOR F OR THE APPLICATION SERVER .......... ..................... ...................... ...................... ...................... ...................... ..................... .......... 22 2.1 2.1.1
2.2 2.2.1
SOFTWARE RECOMMENDATIONS ............. ........................... ............................ ............................ ............................. ............................. ............................ .................... ...... 22 Use the Latest Software Versions....................... Versions.......................................... ...................................... ....................................... ....................................... ...................22
T24 CONFIGURATION RECOMMENDATIONS ............. ........................... ............................ ............................ ............................. ............................. .................... ...... 22 Configure the T24 Bulk Factor Parameter ....... .......................... ...................................... ....................................... ....................................... ...................... ... 22
Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
3
3
2.2.2
Configure the T24 Handle Cache Parameter ............ ............................... ....................................... ....................................... ................................ ............. 22
2.2.3
Consider Using Hyper-Threading ................... ....................................... ....................................... ....................................... ....................................... ...................... ... 23
BEST PRACTICES FOR PROVIDING HIGH AVAILABILITY ........... ...................... ....................... ....................... ...................... ...................... ........... 24 3.1
HIGH AVAILABILITY RECOMMENDATIONS FOR THE DATABASE ............. ........................... ............................. ............................. ......................... ........... 24
3.2
HIGH AVAILABILITY RECOMMENDATIONS FOR THE STORAGE ............. ........................... ............................. ............................. ........................... ............. 25
3.3
T24 RECOVERY.............. ............................ ........................... ........................... ............................. ............................. ............................ ............................ ............................ ................ .. 25
3.3.1 3.3.2
4
Online Recovery ................. .................................... ...................................... ....................................... ....................................... ...................................... ................................ .............25 Close of Business (COB) ......................... ............................................ ...................................... ....................................... ....................................... ................................ ............. 25
BEST PRACTICES FOR DISASTER RECOVERY .......... ..................... ...................... ...................... ...................... ...................... ...................... ................... ........ 26 4.1
SQL SERVER 2012 HIGH-AVAILABILITY AND DISASTER RECOVERY (HADR) ENHANCEMENTS............. .......................... ............. 26
4.2
SAN MIRRORING ............. ........................... ............................ ............................ ............................ ............................ ............................. ............................. ........................... ............. 27
4.3
SYNCHRONOUS DATABASE MIRRORING .............. ............................ ............................ ............................ ............................. ............................. ......................... ........... 27
4.4
ASYNCHRONOUS REPLICATION METHODS ............. ........................... ............................. ............................. ............................ ............................ ....................... ......... 27
4.5
RECOMMENDATIONS FOR CONNECTION BANDWIDTH ............................ .......................................... ............................ ............................. ..................... ...... 28
5
BEST PRACTICES FOR REPORTING .................... ............................... ...................... ...................... ....................... ....................... ...................... ...................... ........... 29
6
BEST PRACTICES FOR PERFORMANCE TUNING ........... ...................... ...................... ...................... ...................... ....................... ....................... ........... 30 6.1 6.1.1
Optimize Standard T24 Queries .................. ...................................... ....................................... ....................................... ....................................... ......................... ...... 30
6.1.2
Optimize Customer-Specific T24 Queries ................. ..................................... ....................................... ...................................... ................................ ............. 31
6.2
7
GUIDANCE FOR IMPROVING Q UERY .......................... ............................ ............................ ............................. .......................... ........... 30 UERY PERFORMANCE ............
RECOMMENDATIONS FOR MONITORING PERFORMANCE OF THE DATABASE TIER .................................... ......................................... ...... 36
BEST PRACTICES FOR SYSTEM MAINTENANCE ......................... .................................... ...................... ...................... ...................... ..................... .......... 37 7.1
GUIDANCE FOR BACKING UP THE DATABASE .............. ............................ ............................ ............................ ............................. ............................. .................. .... 37
7.1.1
Use Backup Compression ................... ...................................... ...................................... ...................................... ....................................... .................................... ................ 37
7.1.2
Implement a Backup Schedule ................. ..................................... ....................................... ....................................... ....................................... ............................ ......... 37
7.1.3
Back Up System Databases ................................ ................................................... ...................................... ...................................... ....................................... .................... 38
7.2
RECOMMENDATIONS FOR UPDATING STATISTICS .............. ............................ ............................ ............................ ............................. ............................ ............. 38
7.3
RECOMMENDATIONS FOR REORGANIZING OR REBUILDING INDEXES ............ .......................... ............................. ............................. .................. .... 38
7.3.1
Reorganize Indexes .................. ...................................... ....................................... ...................................... ...................................... ....................................... .......................... ......39
7.3.2
Rebuild Indexes when Necessary ................... ....................................... ....................................... ....................................... ....................................... ...................... ... 40
7.4
RECOMMENDATIONS FOR UPDATE MANAGEMENT ............. ........................... ............................ ............................ ............................. .......................... ........... 40
7.4.1
SQL Server 2012 Setup Product Update ....................... .......................................... ...................................... ....................................... ............................. ......... 40
7.4.2
Run Anti-Virus Checks During Non-Peak Hours .................. ..................................... ...................................... ....................................... ....................... ... 41
7.4.3
Consider Running Windows Updates on a Test Server before Production ...................................... ......................................41
8
SUMMARY ..................................................................................................................................... 43
9
APPENDIX 1: CREATE A MAINTENANCE PLAN TO BACK UP THE TEMENOS DATABASE ........... ................... ........ 45
10
APPENDIX 2: CREATE A MAINTENANCE PLAN TO BACK U UP P THE SYSTEM DATABASES .................... .................... 51
11
APPENDIX 3: UPDATE STATISTICS ........... ...................... ...................... ...................... ...................... ...................... ...................... ...................... ..................... .......... 57
12
APPENDIX 4: REORGANIZE AND REBUILD INDEXES ......... .................... ...................... ...................... ...................... ...................... ................... ........ 61
13
APPENDIX 5: INSTALLATION CHECK LIST ................... .............................. ...................... ...................... ...................... ....................... ....................... ............. .. 68
Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
4
Overview To help financial institutions face the challenges posed by today’s around-the-clock, global marketplace, Temenos Group AG, the leading provider of integrated core banking systems, offers TEMENOS T24 (T24). T24 pairs comprehensive and powerfully flexible business functionality with advanced and scalable architecture. ar chitecture. T24 is built on an open architecture, and it uses established standards such as HTTP, XML, and Java 2 Platform, Enterprise Edition (J2EE). The design of T24 supports multiple application servers and provides horizontal scalability with true non-stop resilience. The capabilities of T24 can be enhanced by the choice of an enterprise-ready database platform. Customers running T24 on a Windows Server® operating o perating 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 exte nd the capabilities of the T24 banking solution. Figure 1 shows a logical model of the interaction of the various services a and nd components that make up a T24 banking implementation. In this white paper, we focus on best practice guidance for the database layer (in green). gree n).
Figure 1. Logical architecture of T24.
Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
5
This white paper, intended for database administrators (DBAs), 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. 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. The paper then looks at the options for disaster recovery. Best practices for reporting are presented, and best practices practice s for monitoring the performance of the database tier and for system maintenance are discussed. The paper also provides appendices with step-by-step guidance and extensive links for further information. Implementing these best practices can help you optimize the performance of a T24 implementation and can help avoid or minimize common problems.
Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
6
1 Best Practices for the Database Server Following are some best practices you should use to configure your database server.
1.1 Server Recommen Recommendations dations 1.1.1 Us e the Late Latess t S oft oftwa ware re Ver Verss ions
For best performance, you should use the t he latest software versions. Currently, you should use:
T24 Version R12. T24 version R12 contains key performance and scalability sc alability improvements for running T24 on Windows Server and SQL Server.
Microsoft® SQL Server® 2012 . SQL Server 2012 contains performance and scalability improvements for running on computes with many cores (up to 640) and memory me mory (up to 4TB), such as those commonly used in banking implementations, in addition to various new features like Availability Group for High Availability and Disaster Recovery. To learn more about SQL Server 2012 ne new w capabilities, visit the link: http://www.microsoft.com/sqlserver/en/us/product-info/overview-capabilities.aspx http://www.microsoft.com/sqlserver/en/us/product-info/overview-capabilities.aspx
Windows Server® 2008 R2 Operating System. Windows Server 2008 R2 provides many benefits, including:
A more efficient efficient TCP/IP stack than in previous versions of Windows Server. In addition
to reducing latency of transaction processing, this benefits the disaster recovery (DR) options described in detail in section section Best Practices for Disaster Recovery. Recovery.
Receive-side scaling (RSS), which makes it possible for network packet processing to be
Scaling.. distributed across more CPUs. For more information, see see Receive-Side Scaling
Support for up to 256 logical processors (cores) . On previous versions of Windows
Server, only up to 64 cores were supported.
Optimizations for 64-bit processors.
Improved failover clustering capabilities .
Optimized partition offsets when disks are formatted , reducing complexity in I/O
system configuration. For more detailed information, see see Windows Server 2008 R2 R2..
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 t he Cluster component mentioned in the article: Recommended hotfixes and updates for Windows Server 2008 R2 SP1 Failover http://support.microsoft.com/kb/2545685)) Clusters (http://support.microsoft.com/kb/2545685 Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
7
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 o perating system installation and before installing SQL Server and T24.
1.1.2 1.1. 2 Us e a 6464-B B it S erver 64-bit servers provide efficient access to the memory and the number of core coress required by T24.
1.1.3 Us e a Dedicate Dedicated d S erver 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. Diagnosing performance problems requires more effort and precision on a system with mixed workloads.
1.2 Sizing Recommendations Every bank has different functionality and different close-of-business processes. Therefore it is recommended to work with the Temenos Performance and Sizing Team to properly size your system based on the expected workload. Temenos also provides a Universal Performance Measurement (UPM) tool that can be used to verify a hardware configuration before T24 is installed. In some cases, tests that model your business processes as closely as possible may be necessary to confirm the server sizes required to support your business scenario.
1.3 Storage Design Recommendations Processing large volumes of banking transactions and providing high availability and disaster recovery (HADR), as well as reporting and extracting to data warehouse (DW) systems, requires substantial I/O system resources. Following are best practices you should use when designing storage for your T24 implementation.
1.3.1 1.3 .1 Use S A N and R A ID 1 10 0 You should use RAID 10 if possible for all logical unit numbers (LUNs). RAID 10 offers better performance and availability than RAID 5 and offers better support for write-heavy environments. For optimum and predictable performance, the LUNs must be made up of physical drives that are not used by other applications. It is generally better to have a larger number of small drives than a smaller number of large drives. If your storage area network net work (SAN) has multiple buses (sometimes called shelves), create each LUN using drives from each bus to improve the internal bandwidth. 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
LUN 1
LUN 2…
…LUN 4
Bus 1
1
4
7
10
13
…
46
Bus 2
2
5
8
11
14
…
47
Bus 3
3
6
9
12
15
…
48
Table 1. Choosing drives from multiple buses to create a LUN.
You should refer to the article art icle Predeployment I/O Best Practices for procedures to test your I/O subsystem 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 arr ays with cache)
< 20 ms for data on OLTP systems (ideally 10 ms or less)
1.3.2 S et the P artition Offs et If you are using the Windows Server® 2003 operating system, you should use the Diskpart.exe tool to create the disk partition. Use Diskpart.exe to specify a starting offset o off 1 megabyte (MB) to avoid split writes and reads, as these can seriously degrade performance. If the offset is not optimal, a single logical I/O becomes multiple physical I/Os. Some storage manufacturers claim to handle this within their architecture, but there usually is some degradation that can be easily avoided by setting the appropriate offset. For more information about DiskPart.exe, see the article article DiskPart. DiskPart. In Windows Server® 2008 and Windows Server 2008 R2, the partition offset is set appropriately by default for new storage. (Note that the offset of existing storage is not changed when upgrading from Windows Server 2003.)
1.3.3 S et the Fi le A llocat llocation ion Unit S ize a and nd S tripe S ize When formatting the partition that will be used for SQL Server data files, you should use a 64kilobyte (KB) allocation unit size for data, logs, and the t he tempdb database. The stripe size is also important to reach an optimal configuration. This is set in the SAN management software, not through Windows Server. The following two equations can be used to determine if you have an optimal configuration. Each should result in an integer value: Partition_Offset ÷ Stripe_Unit_Size Stripe_Unit_Size ÷ File_Allocation_Unit_Size F ile_Allocation_Unit_Size For details on managing disk partition sector alignment, see see Disk Partition Alignment Best Practices for SQL Server. Server. Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
9
1.3.4 1.3. 4 Dedicat Dedicate e a Hig h Percent Percenta ag e of S A N Ca C ache to Write Writess Most SANs have a large cache that can be split between a read cache and a write cache. SQL Server provides read-ahead and read caching, cac hing, and SQL Server does not benefit much from a SAN read cache. If you have the option (within the constraints of SAN usage by applications), you should dedicate 90% of the SAN cache to writes to improve write performance (a cache ratio of 10/90 read/write). Note that virtually all SANs sold today have battery-backed cache. If this is not the case with your SAN, you must disable write caching or risk losing committed data in the event of a power outage.
1.3.5 1.3 .5 C onf onfig ig ure Windows Windows Drives Once you have configured LUNs on your SAN, you yo u need to assign the LUNs to drives in Windows, using disk management to create the drives. Table 3 shows a sample Windows Server storage configuration for use by SQL Server.
Drive LUN Physical Drive LUN Drive Drive Usage Usage 12 1 – 12
1
E
data
13 – 24 24
2
F
data
25 – 36 36
3
G
tempdb
37 – 48 48
4
H
log
Table 2. Sample storage configuration for SQL Server.
You can also present storage to SQL Server through mount points, disk volumes that are mounted as folders on other physical disks, without incurring a performance penalty. For further information about storage design for SQL Server, see Storage see Storage Top 10 Best Practices. Practices.
1.4 Hardware and Network Guidance The following are some important best practices for the hardware and networking of your T24 database implementation.
1.4.1 1.4. 1 Windows Server P ow ower er P lan In some cases we observed o bserved degraded overall performance (even around 30-40%) on a Windows W indows Server 2008 R2 machine mac hine when running with the default (Balanced) power plan. The issue may occur irrespective of SQL Server Ser ver version and may be exhibited on both native and virtual environments. The degraded performance may increase the average response time for some tasks and cause performance issues with CPU-intensive applications. In order to avoid this situation, 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
Perf ormance” ormance” and test the performance difference with a significant workload: if no difference will be found, Power Plan scheme can be reverted to the default value. For more information on this potential issue and instructions for changing the Power Plan options, see the links below:
Degraded overall performance on Windows Server 2008 R2 http://support.microsoft.com/kb/2207548/en-us http://support.microsoft.com/kb/2207548/en-us
Hyperthreading, Turbo Boost, SQL Server and You (MSDN) http://msdnrss.thecoderblogs.com/2012/07/hyperthreading-turbo-boost-sql-serverand-you For general tuning information on Windows Server 2008 R2, see the white paper below:
Performance Tuning Guidelines for Windows Server 2008 R2 http://www.microsoft.com/whdc/system/sysperf/Perf_tun_srv-R2.mspx http://www.microsoft.com/whdc/system/sysperf/Perf_tun_srv-R2.mspx
1.4.2 Us e a P rivat ri vate e Netwo Network rk S eg egme ment nt The traffic between T24 application servers and SQL Server and the traffic between SQL Server and the storage system is quite high. You should use a private network segment for T24 –SQL Server communication. This should be at least a 1-Gigabit 1 -Gigabit Ethernet network, and a 10-Gigabit Ethernet network for installations with more than 5 million accounts. This can be in addition to a standard 100-Mb Ethernet connection to SQL Server for administration purposes.
1.4.3 1.4. 3 E na nabl ble e R eceive eceive-S -S ide S cal caling ing You should enable Receive-Side Scaling (RSS) on the SQL Server network interface card (NIC) that is serving the application servers. This setting is found on the Advanced Property tab of the network card. Also, be sure that offloading o ffloading options are enabled. See the Microsoft® Developer Scaling and and Receive-Side Scaling Network (MSDN®) articles articles Introduction to Receive-Side Scaling Enhancements in Windows Server 2008 2008 for more information. If your NIC does not support these options, consider replacing it with one that does. You should configure the maximum number of RSS processors by setting sett ing the MaxNumRssCpus registry key value to 8 on a computer system with 32 or more CPU cores. For computer systems with less than 32 cores, use the default setting. The RSS base CPU number (RssBaseCpu) is the CPU number of the first CPU that RSS can use. RSS cannot use the CPUs that are numbered below the base CPU number. You should set RssBaseCpu carefully so it does not overlap with the starting CPU. Lab testing has shown good results with setting both registry key values to 8 (on a computer system with more than 32 cores); this means that 8 RSS processors are used starting with core number 8 to process network traffic. Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
11
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.4.4 1.4. 4 C onsi de derr NIC Tea Teaming ming If you have three or more application servers, 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. Check with your vendor to select a NIC teaming option that can support RSS or provide equivalent features. You should be sure to test this configuration against your original or iginal performance to be sure that any benefit of NIC teaming is not offset by the disabling of any of the RSS and offloading options.
IMPORTANT: NIC teaming and RSS are not supported at the same time on Itanium architecture.
1.4.5 Us e Mul Multipl tiple e HB A s and S et the HB A Queue Dept Depth h You should use at least two host bus adapters (HBAs) to provide redundancy and to increase bandwidth between the SAN and SQL Server. Se rver. The HBA cards should be set as load balanced and configured to provide high availability among them. Connections between the SAN and server se rver are ideally 8 gigabyte (GB)/sec (but not less than 2 GB/sec). The HBA queue depth may need to be increased if you have a small number of LUNs. A queue depth value between 128 (if there are few LUNs) and 32 (if there are many LUNs) should be considered, queues now default to “per LUN” rather than “per target.” When the queue depth is set too low, 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.
1.5 Data, Log, tempdb, and Backup File Recommendations The location of SQL Server files affects performance. You should use multiple files for each filegroup supporting your databases, and use distinct LUNs for each of the data, tempdb, log, and backup files. Using separate LUNs also helps you monitor the disks based on the t he type of use. 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 oper ating system on startup.
1.5.1 1.5. 1 C onfig ure Data Data Fi les The filegroup used for the T24 data should be composed of multiple files. Best practice is to use one file for every two CPU cores on computer systems with 32 or more cores. On computer systems with less than 32 cores, use the same number of files as the number of CPU cores (the ratio should be 1:1). The data files should be equal in size. Note that the out-of-the-box configuration uses only one file in the primary filegroup, so you need to add additional files for optimal configuration. You should pre-allocate enough space in the data files based on the initial size of the computer system. 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. SQL Serve Serverr optimizes Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server 12
writes by spreading its write operations across the files based on the ratio of free space among the files, so extending all files at once maintains this optimization. You can leave the autogrowth setting sett ing on as an “insurance policy” so that SQL Server does not stop when it runs out of space; however, do not rely on autogrowth to extend the database files as a standard way of operating. While you should not allocate space for the data files in small units, if you allocate in very large units during autogrowth, the application must wait (possibly several minutes) while the space is allocated. Since you cannot control when autogrowth engages, allocate only by the space needed for a few days of operations.
1.5.2 1.5. 2 C onfig ure th the e Log Fi le The transaction log file, generally a sequentially se quentially written file, must be written as quickly as possible—even before the data is written w ritten to the data files (the data portion can be rebuilt from the log if necessary). While there is no performance benefit from using more than one file, multiple files can be beneficial for maintenance purposes (for example, if you are running out of space on the log drive). Adding physical devices to support the t he LUN can benefit performance. To avoid autogrowth operations on the transaction log file, monitor its size on a regular basis and adjust it as necessary. As a starting point, you can use the 80-GB transaction log size for T24 installations with 10 million accounts. Since expanding the transaction log is a relative slow operation, it’s recommended to balance the size of the growth and the number of transaction
log expansions based on the t he following recommendations:
Never use increments in percentage, always use fixed size autogrowth size;
Increment size should be always higher than 1GB;
Reasonable increment sizes for transaction log are 1GB, 2GB, 4GB, 8GB, 16GB and final
choice should be based on the relative re lative size of the planned initial size of the tr transaction ansaction log and reflects how big the environment will be in terms of number of accounts; acco unts;
SQL Server 2008 R2 and later provide tools (SQL Trace and Dashboard reports) of how much time the autogrowth operations on transaction tr ansaction log will take, if the observed duration will be consistently higher than 1 second, it’s recommended re commended to:
o Raise the initial size of the transaction log to reduce occurrences of autogrowth expansions;
o Reduce the autogrowth size; IMPORTANT: In SQL Server 2008 and SQL Server 2008 R2, 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.microsoft.com/kb/2633151) http://support.microsoft.com/kb/2633151) Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
13
SQL Server 2012 is not affected, for SQL Server 2008 R2 “Service Pack 1” and “Cumulative Update 4 for SP1” must be installed to solve the problem, for SQL Server 2008 there is no fix; if not possible to apply the hotfix, it’s recommended to avoid 4GB 4G B (or multiples) increment.
1.5.3 C onfig ure te temp mpdb db Fi les les SQL Server tempdb files are used for the storage of temporary data structures. The tempdb files are responsible for managing temporary objects, row versioning, and online index rebuilds. T24 uses a read-committed snapshot isolation level as its default isolation level, which uses row Engine.. versioning. For more information, see see Isolation Levels in the Database Engine To ensure efficient tempdb operation:
Create one tempdb file per physical CPU core.
This reduces page free space (PFS) contention.
Pre-size the tempdb files, and make the files equal in size .
As a starting point, you can use a 64-GB total size for T24 installations with 10 million accounts.
Do not rely on autogrowth (see previous section).
Use startup trace flag 1118.
When this trace flag is set, SQL Server allocates full extents for tempdb objects (instead of using mixed extent allocations).
Use startup trace flag 1117.
If used, SQL Server 2008 R2 (or later) will ex expand pand all TEMPDB data files at the same time to maintain optimal allocation balance, then overall TEMPDB performance: be sure to take into account the fact that all files will growth when establishing data file growth size. For more information about T1118 trace flag, see the article article Concurrency Enhancements for the tempdb Database. Database. For more information about T1117 trace flag, see the articles below: http://blogs.technet.com/technet_blog_images/b/sql_server_sizing_ha_and_performa nce_hints/archive/2012/02/09/sql-server-2008-trace-flag-t-1117.aspx http://blogs.msdn.com/b/axperf/archive/2011/09/12/consider-enabling-trace-flag1117-on-dynamics-ax-sql-server.aspx 1117-on-dynamics-ax-sql-server.aspx For information on how to set startup settings for SQL Server 2008, 2008 R2 and 2012, see the article Configure Server Startup Options (SQL Server Configuration Manager. article Manager.
Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
14
NOTE: In SQL Server 2012 the location for changing the startup parameters is changed, be sure to check the right r ight version in the provided link above. For further information, see the MSDN article article Optimizing tempdb Performance Performance..
1.6 Recommendations for Memory Settings Following are recommendations for the memory settings for SQL Server.
1.6.1 1.6. 1 S QL S erver Me Memo mory ry S et ettting s Recommendations (and Table 1) for appropriate memory sizing for the See section section Sizing Recommendations database system.
For SQL Server 2008 and SQL Server 2008 R2 you should then configure the SQL Serv Se rver “max server memory (MB)” setting by taking the amount of memory m emory allocated to the database system
and subtracting one GB for every eve ry four cores (round up). This leaves the operating system with enough memory to work efficiently without having to “grab” memory back from SQL Server. For
example, if the server has 64 GB of RAM and 24 cores, set the maximum memory to 58 GB (64 GB minus 6 [24 cores divided by 4]).
For SQL Server 2012 , 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. The bigger component not yet capped here is the memory required by worker thread stacks, then it’s recommended to
reserve enough memory based on the maximum number of worker threads. The maximum number of worker threads, if not directly modified in the instance configuration parameters, 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.microsoft.com/en-us/library/ms190219.aspx http://msdn.microsoft.com/en-us/library/ms190219.aspx For each single worker thread, the following amount of memory is required for specific CPU architecture: -
(x86): 512KB;
-
(x64): 2048 KB;
-
(IA64): 4096 KB;
If you need to do calculation over the 32 logical processors, the general formula below can be used:
Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
15
32bit CPU 4 CPU = 256 + ((#CPU - 4) *8)
64bit CPU 4 CPU = 512 + ((#CPU - 4) * 16) For example, on a x64 bit machine with 32 logical CPUs, 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, the total amount of memory that t hat should be reserved is (960*2) = 1920 MB. NOTE: In SQL Server 2012, 32bit AWE memory feature is deprecated:
The "awe enabled" SQL Server feature is deprecated http://support.microsoft.com/kb/2644592 http://support.microsoft.com/kb/2644592 For more information on how the memory management has been changed in SQL Server 2012, see the KB article and links below:
Memory configuration and sizing considerations in SQL Server 2012 2 012 http://support.microsoft.com/kb/2663912 http://support.microsoft.com/kb/2663912 SQL Server Memory Manager Changes in Denali http://blogs.msdn.com/b/sqlosteam/archive/2011/01/04/sql-server-memory-managerchanges-in-denali.aspx changes-in-denali.aspx New SQLOS features in SQL Server 2012 http://blogs.msdn.com/b/sqlosteam/archive/2011/11/10/new-sqlos-features-in-sqlserver-2012.aspx server-2012.aspx
1.6.2 1.6. 2 Lock Pages in Me Memo mory ry To reduce SQL Server paging, you can grant the SQL Server service account “Lock Pages in Memory” privilege through the Windows Group Policy editor. Enable this privilege for both 32-
bit and 64-bit servers. For detailed instructions, see see How to reduce paging of buffer pool memory in the 64-bit version of SQL Server on the Microsoft® Support site .
Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
16
1.6.3 Ins tant tant Fi le Initia Ini tializa lization tion (IF I) When it's necessary to create a SQL Server data file, the operating system has to go through the file and ‘Zero out’ the entire e ntire file after it is allocated for o one ne of the following operations:
Create a database.
Add files, log or data, to an existing database.
Increase the size of an existing file (including autogrowth operations). Restore a database or filegroup.
This can take a quite a bit of time for a very large file which can become critical in disaster recovery and restore operations; to solve this problem, 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 m making aking the process almost instantaneous. The operating system just allocates the disk space, but the content of the file is actually what is originally on the disk. Instant File Initialization (IFI) is only available if the SQL Server database engine service account has been granted the “Perform Volume Maintenance Tasks” Tasks” (SE_MANAGE_VOLUME_NAME) (SE_MANAGE_VOLUME_NAME) user right at the OS level on the server and all ccluster luster nodes if a clustered configuration is used. 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. To grant this right, use the following steps: On a pure performance perspective, using this feature is recommended, but there are some securities implications that should be considered and reviewed in the article below (also apply to SQL Server 2012): http://msdn.microsoft.com/en-us/library/ms175935(v=sql.105).aspx http://msdn.microsoft.com/en-us/library/ms175935(v=sql.105).aspx If the final customer is comfortable in being able to address this type of risk based on his inhouse security protection mechanisms, configurations and operations, then we recommend to proceed. NOTE: This feature is only available for data files, not transaction log files. For more information on this feature you can visit the link below: http://sqlskills.com/BLOGS/KIMBERLY/post/Instant-Initialization-What-Why-and-How.aspx http://sqlskills.com/BLOGS/KIMBERLY/post/Instant-Initialization-What-Why-and-How.aspx
1.7 Guidance for SQL Server Configuration Settings Following is guidance for SQL Server configuration settings.
Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
17
1.7.1 1.7. 1 C onsi de derr Lowe Lowerr Fill Fact Factor or In high-volume deployments (installations with 10 million accounts and more), you should consider a lower fill factor with PAD_INDEX on for indexes on hot tables with high latch contention. Consider a lower fill factor only if there is need to improve the performance and if excessive latch contention has been observed. Lab testing t esting has shown good results using a fill factor of 10% for small tables (less than 1 GB) and 50% for bigger tables. 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.dm_os_wait_stats using this query:
SELECT * FROM SELECT FROM sys. sys.dm_os_wait_stats dm_os_wait_stats WHERE wait_type LIKE 'PAGELATCH%' WHERE wait_type LIKE To identify which tables and which pages experience latch contention, you can use the following queries:
SELECT * SELECT FROM sys. sys.dm_db_index_operational_stats dm_db_index_operational_stats (DB_ID DB_ID( ('T24' 'T24'), ), NULL, NULL, FROM NULL, NULL, NULL) NULL) ORDER BY [page_latch_wait_in_ms] [page_latch_wait_in_ms] DESC, , ORDER BY tree_page_latch_wait_in_ms DESC DESC and
SELECT * FROM FROM sys. sys.dm_os_waiting_tasks dm_os_waiting_tasks SELECT WHERE wait_type LIKE 'PAGELATCH%' WHERE wait_type LIKE Table 4 shows tables that have been identified as likely candidates for a lower fill factor setting during lab testing:
Table
Fill factor
Pad_index
FBNK_PL_C002
10%
On
F_LOCKING
10%
On
FBNK_EB_C004
50%
On
FBNK_ACCT_ACTIVITY
50%
On
FBNK_ACCOUNT
50%
On
Table 3. Table candidates for lower fill f actor. Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
18
Note: This testing has been done with a standardized workload. Every application has different functionality, and if high latch contention is observed, you must identify these candidates for the application-specific workload profile. For more information on the fill-factor option for indexes, see the article article Fill Factor Factor..
1.7.2 1.7. 2 Incr Increa eass e th the e S QL S erver R ecove ecovery ry Int Interva ervall Increasing the recovery interval server configuration option causes the checkpoint process to occur less often. This can reduce the I/O load driven by checkpoints and improve the overall performance. During lab testing, a recovery interval of 5 –10 minutes has been determined to be the best setting for T24. Before changing the recovery interval, you should consider its implication on the mean time to recovery and recovery point objectives. Note that when using failover clustering, a longer recovery interval also influences the failover time of the database instance. There is a new database level option o ption in SQL Server 2012 called “Target Recovery Time (seconds)”, 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”. When it is set to 0 (zero) the database uses automatic checkpoint for the current c urrent database that uses “recovery interval” from server level (sp_configure); once
TARGET_RECOVERY_TIME changes to a value bigger than 0, the database starts to use it instead of automatic checkpoint and it is called indirect checkpoint. c heckpoint. 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. In SQL Server 2012, if it’s desired to change the checkpoint process behavior, it’s generally recommended to use database level
option for T24 database. For more information on this specific feature fe ature use this link link Database Checkpoints . For more information about the recovery interval option, see the article Checkpoints article Recovery Interval Option. Option.
1.7.3 Us e Trace Fla Flagg 834 On computer systems with 64 or more CPU cores, use startup trace flag 834. When this trace flag is set, SQL Server Serve r uses Windows large-page memory allocations for the buffer pool. Allocating buffer pages is expensive, and turning on trace flag 834 boosts performance.
IMPORTANT: Enabling this trace flag will affect time t ime required by SQL Server process to start up and then greatly augment failover time in Cluster configuration, then it’s highly recommended
to test it on production environment machines directly, before going live. 920093. For more information about this SQL Server trace flag, see see Microsoft Support Article 920093.
Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
19
1.7.4 K eep Defaul Defaultt S et etting ting for Deg ree of Paral Paralle lelis lis m Leave the default setting of max m ax degree of parallelism option unchanged.
1.7.5 K eep Defaul Defaultt S et etting ting for Numb Number er of Work er Threa Threads ds Leave the default setting of max worker threads option unchanged.
1.7.6 E ncr ncrypt ypt C lient C omm ommunic unica ation if R equired If required, you can enable encrypting e ncrypting client connection communication to SQL Server. SQL S QL Server supports Secure Sockets Layer (SSL) to encrypt the data transmitted between a client and the database server. SQL Server can be configured to require encrypted connections, in which case it rejects connections from clients who are not able tto o support encryption. Clients can also request encryption when connecting to SQL Server. For more Information, see see Encrypting Connections to SQL Server Server and and How to: Enable Encrypted Connections to the Database Engine (SQL Server Configuration Manager). Manager).
1.7.7 T24 Dat Datab aba as e C onfig urat uration ion s et etting ting s The following recommended settings apply for the T24 database:
Leave value for parameter “Auto Close” to “FALSE” (default configuration); Leave value for parameter “Auto Create Statistics” to “TRUE” (default configuration);
Leave value for parameter “Auto Shrink” to “FALSE” (default configuration);
Leave value for parameter “Auto Update Statistics” to “TRUE” (default configuration);
Change the value for parameter “Async “ Async Update Statistics” to “TRUE” (change required);
Leave value for parameter “Auto Shrink” to “FALSE” (default configuration); Ve rify” to “CHECKSUM” (default configuration); Leave value for parameter “Page Verify”
Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
20
Rec overy Time (Seconds)”, For modification of default value (0) for parameter “Target Recovery
see section “2.7.2 “2.7.2 Increase the SQL Server Recovery Interval ”. ”.
Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
21
2 Best Practices for the Application Server Following are some best practices you should s hould use for configuring your T24 application server.
2.1 Software Recommendations 2.1.1 Us e tthe he Lates Latestt S oftware Ver Verss ions io ns For best performance, you should use the latest software versions.
Use TAFC Version R12 . Currently, you should use TAFC version R12, which contains key performance and scalability improvements for running T24 on Windows Server and SQL Server.
2.2 T24 Configuration Recommendations Following are recommendations for some T24 parameters.
2.2.1 C onfi onfigg ure ur e tthe he T24 B ulk FFactor actor P Paramet arameter er The T24 Bulk Factor parameter (in PGM.FILE, Record IC.COB, Attribute 14) defines how many Data Manipulation Language (DML) statements are included within each database transaction. There is a trade-off for increasing this t his parameter value: increasing the bulk factor value improves throughput by processing more statements within each transaction but also increases the possibility of longer transactions tr ansactions and blocking. You should leave the default value for the bulk factor parameter (currently 5), unless you have a large installation with 10 million accounts or more. For such high-volume installations, increasing the bulk factor may improve performance. 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.
2.2.2 C onfi g ure ur e tthe he T24 Handle C ache P Paramet arameter er T24 provides a caching mechanism for OLEDB statement handles. This improves performance by caching and reusing the handles of frequently used statements, instead of releasing and preparing them each time. Each T24 table can have a maximum of 5 different handles (i.e., for the following T24 operations: READ, INSERT, UPDATE, DELETE, and SELECT). Each handle consumes a fixed amount of memory (64 KB) and consumes additional memory needed for data cache. The T24 Handle Cache parameter (JEDI_XMLDRIVER_HANDLE_ ( JEDI_XMLDRIVER_HANDLE_LIMIT) LIMIT) specifies the maximum number of statement handles that can be cached. The default value (currently 500) should be adjusted based on the available application server memory as shown in Table 4.
Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
22
App Server Memory
Handle Cache Parameter
< 8 GB
500 (default)
>= 8 GB and < 32 GB
5000
>= 32 GB and < 64 GB
12000
>= 64 GB
15000
Table 4. Handle cache parameter scale based on application server memory.
2.2.3 C ons i der Us i ng Hy Hyper-T per-Thr hreading eading Hyper-Threading should be off by default for T24 application servers. Lab testing has shown performance gain on application servers with the latest chipsets (e.g., (e.g., Intel Nehalem-EX+); you should consider turning hyper-threading on when using the newer chipsets and observe the influence on performance.
Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
23
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. Failover clustering is therefore recommended to provide database-tier HA for SQL Server in a T24 deployment.
3.1 High Availability Recommendations for the Database In a T24 implementation, 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. This protects the system from the failure of server components such as the network adapters, the processors, or the SAN connectivity. Typically, the data resides on a SAN with disks configured as RAID 10 (recommended) or RAID RA ID 5, providing redundancy for the LUNs used by SQL Server. The SAN is connected to the servers serve rs via two or more HBAs. The time to detect a fault and switch to the alternate node is typically less than one minute. (Note that the time is dependent on the current tr transactional ansactional load and on the configuration, such as the number of drives or other o ther resources in the resource group.) The cluster can also be used for planned maintenance. With SQL Server 2008 and later versions, you can apply service packs to inactive nodes, and then you can fail the active SQL Server group over to the patched nodes. (Note that this results in a brief usage outage outage.) .) For more information on applying service packs to a failover cluster instance, see see SQL Server 2008 Failover Cluster Rolling Patch and Service Pack Process Process (still valid on SQL Server 2012). T24 uses database locking from R11 onwards by default and can be turned off if require to use jDLS (T24 lock arbiter). jDLS can be installed:
In a resilient mode on two application servers.
r esources are available. (Note that approximately 20% On the database server if enough resources
more CPU utilization on the database server se rver is expected in this ccase.) ase.)
On a separate application server.
In a cluster configuration with jDLS installed on the database server, you can cconfigure onfigure jDLS in resilient mode on both database server nodes and have the jDLS in the same failover group as SQL Server. If the jDLS or SQL Server fails, then the connections are dropped (as well as the locks), and the processes reconnect to the secondary node and take locks via the jDLS of that node.
Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
24
For general overview on the high-availability features of SQL Server, see see High Availability— Always On Technologies Technologies and and High Availability with SQL Server 2008 R2. R2 .
3.2 High Availability Recommendations Recommendations for the Storage As described in section section Storage Design Recommendations Recommendations,, your storage solution should be a fault-tolerant SAN solution made up of a redundant disk configuration such as RAID 10. The SAN is still a single point of failure, but the majority m ajority of its components are redundant. re dundant. You should be sure to consider the disaster recovery r ecovery options described in the section section Best Practices for Disaster Recovery to Recovery to mitigate the effect of a total SAN failure.
3.3 T24 Recovery When an error or connection c onnection failure occurs (e.g., a database failover event) during the processing of transactions either online or as a COB agent, the controlling T24 process proce ss terminates. Because the exact transaction state cannot be ascertained between connection failures and reconnects, the current curre nt transaction is completely rolled back and restarted on another process.
3.3.1 On Online line R ecov ery For the T24 online processes (Web services, Browser, and MQ batch), an agent listener process is started on each application server. The listener process spawns and monitors child processes, which process pr ocess the transaction requests. Should a child agent fail, the aborted transaction is resubmitted by the application and is started on a new agent process. This in turn connects to the t he secondary database node that is active after the failover, and the transaction is then processed as normal.
3.3.2 C los e of B us i nes s (C OB ) Under normal operation, the T24 COB processes (agents or tSAs) are starte started d and monitored by a manager process (tSM) on each application server. If an agent (tSA) fails or aborts because of an error or failover, then the tSM initiates a new agent to replace the failed agent. The new agent resubmits the request, and this causes a connection to be established to the secondary database node which lets the COB jobs rest restart art and continue. If the error or failover occurs while the tSM is accessing tables in the database (e.g., JOB.LIST) and is “connected” to the database server, the tSM also terminates, leaving no monitoring process to automatically restart the tSAs. The tSM needs to be manually rest restarted, arted, which then restarts the tSAs letting the COB processes continue from where they left off. You cannot automatically restart the tSM by design, because bec ause an assessment of the failure is required to ensure that it’s a “real” disconnection rather than a temporary network interruption. Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
25
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. For protection from natural disasters such as earthquakes, the DR site is frequently located far from the primary site. SQL Server provides various technologies for transferring data changes from the primary database to a disaster recovery site. One of the main decisions that you need nee d to make is whether or not you are willing to tolerate potential data loss in the event of complete destruction of the primary site. Loss-less DR methods require the use of synchronous replication to the DR D R site. This means that all writes to the storage systems must complete at both sites before the tr transaction ansaction is committed, which can increase the time to perform pe rform the transaction significantly, depending on the line speed. The two primary methods of synchronous replication are SAN mirroring m irroring and database mirroring in “high-safety” mode. SAN mirroring requires additional features provided by the SAN vendor.
Database mirroring is a feature included with SQL Server.
4.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. Prior to SQL Server 2012, many customers used FCIs to provide local high availability within a data center and database mirroring for disaster recovery to a remote data center. With SQL Server 2012, this design pattern can be replaced with an architecture that uses F FCIs CIs for high availability and availability groups for disaster recovery business requirements. Availability groups leverage Windows Server Failover Clustering (WSFC) functionality, enable multiple features not available in database mirroring, with or without shared replicated SAN S AN storage between sites providing a cost effective solution able to guarantee zero data loss. Based on these new SQL Server 2012 HADR functionalities, 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; the result of this work can be viewed in the white paper below:
A deployment reference reference architecture and and guidance for implementing an HADR HADR solution for TEMENOS T24 running running on the Micr Microsoft osoft Application Platform Platform http://blogs.technet.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.aspx Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
26
For more information on SQL Server 2012 AlwaysOn technologies and Availability Group, you can visit the links below:
Microsoft SQL Server AlwaysOn Solutions Guide for High Availability and Disaster Recovery http://msdn.microsoft.com/library/hh781257.aspx http://msdn.microsoft.com/library/hh781257.aspx SQL Server 2012 AlwaysOn High Availability and Disaster Recovery Design Patterns http://sqlcat.com/sqlcat/b/msdnmirror/archive/2011/12/22/sql-server-2012-alwaysonhigh-availability-and-disaster-recovery-design-patterns.aspx high-availability-and-disaster-recovery-design-patterns.aspx
4.2 SAN Mirroring SAN mirroring synchronizes the contents of one SAN S AN with another and requires very high bandwidth between the two SANs―usually dark fiber is recommended. A benefit of SAN S AN mirroring is that it mirrors all of the storage, not just the database. SAN mirroring is provided by the storage vendor (it is not part of the Windows Server operating system).
Note: Asynchronous SAN mirroring is not recommended because it i t is not possible to determine if the mirror is synchronized after a disaster, and you cannot easily discover any differences.
4.3 Synchronous Database Mirroring Also known as high-safety mode, synchronous database mirroring guarantees that the mirror m irror and the primary databases are synchronized on all committed transactions. tr ansactions. It is important to note that only the one database being mirrored mir rored is synchronized―no other databases or files are synchronized in the same operation. Database mirroring can use any form of TCP connectivity between the two server servers, s, but as with SAN mirroring, a large bandwidth is important in providing responsive, 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: t he primary site (under 100 kilometers [km]) and uses One site is geographically close to the
mirroring to maintain an exact mirror of o f 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, less-expensive bandwidth. For more information, see see Synchronous Database Mirroring (High-Safety Mode). Mode).
4.4 Asynchronous Replication Methods If a small potential for loss of recently rece ntly committed transactions is acceptable, synchronization performance can be improved by using asynchronous protocols between primary and secondary database servers. Using asynchronous protocols means that there is no dependency between the database servers when committing a transaction. tran saction. A transaction may be committed on one server, but not on the other ot her until much later. Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
27
The primary methods of asynchronous replication are asynchronous database mirroring, log shipping, or transactional replication (server-to-server transactional replication or peer-to-peer replication). With these methods, there is a window of o f a few seconds to a few minutes where the transactions committed on the primary site are not yet committed on the DR site. Note that when using asynchronous database mirroring or log shipping, 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. Transactions that were not shipped to the DR site before switching to the secondary database server are lost. Overview,, Database Mirroring Overview Overview,, and For more information, see see Log Shipping Overview Transactional Replication Overview. Overview.
4.5 Recommendations for Connection Bandwidth An important consideration is the connection bandwidth between the primary and DR sites. Lab testing with 10 million accounts showed peak log usage of 34 MBytes/sec during COB, with values above approximately 15 MBytes/sec for more than an hour during IC processing. COB is the most intensive workload, and can generate large numbers of log records. With an estimated e stimated log compression ratio of 1:4, you should plan at least a 40-Mbit/sec (or 5 MBytes/sec) link to the DR site for configurations with 10 million accounts.
Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
28
5 Best Practices for Reporting In the default implementation of T24, reports re ports 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. For external reporting repor ting purposes only, including feeding data warehouses, outside the context of T24 reporting r eporting features, a secondary copy of the production database can be created. There are various options that can be considered, including snapshots, log shipping, database mirroring (SQL Server 2008 R2) R 2) and Availability Group (SQL Server 2012):
Snapshots give only point-in-time data (typically once per day). When you update the
snapshot, all connections to the previous snapshot are broken, providing a poor user experience. Snapshots can be generated by the SAN or you can use database snapshots.
Log shipping or database mirroring keeps the target database in “recovery” mode, and it
cannot be accessed for reading except through a database snapshot. This again means that it is only point-in-time data, and when updating, all previous connections are broken. othe r server. You cannot mirror a database Database mirroring can only mirror to one other
to both the DR site and to a reporting site.
SQL Server 2012 Availability Group supersedes SQL Server Mirroring functionalities
removing the constraint of a single copy, in addition to powerful features not available in any other available technology such as readable secondary Replica Re plica that can be used for external reporting purposes.
The reporting database may be configured for simple database recovery because it is not updated by client transactions; this lets you skip the backup process, but it means that if the database becomes corrupted, you need to re-initialize r e-initialize the subscription from the primary backup. Another possible alternative, both for SQL Server 2008 R2 and SQL Server 2012, is Transactional Replication but it’s not recommended since:
(t riggers, views, tables, stored It requires modifications to the database schema (triggers,
procedures);
There are several strict requirements on the structure of the published tables; The overhead on the primary production T24 database may affect heavily database
throughput;
Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
29
6 Best Practices for Performance Tuning Following is guidance for performance tuning for a T24/SQL Server implementation.
6.1 Guidance for Improving Query Performance Performance A typical T24 application consists of T24 core functionality, a number of o f T24 modules for specific banking industry areas, and a custom application code that reflects the particular business requirements. The following sections describe the various performance considerations for the standard T24 core components and for customer-specific queries.
6.1.1 Optimize S tanda tandard rd T24 Queri Queries es Temenos provides a post-installation script for creating indexes on the fields that the standard T24 application code uses most often. You should run this script after installation on all your T24 environments to ensure proper performance of the standard T24 queries. As every application has different functionality, close-of-business processes, and a specific transaction mix profile, you should monitor the usage of the standard st andard indexes and consider dropping indexes that are rarely used. You can use the following query to identify indexes that have not been used since the last time SQL Server was started:
SELECT SELECT object_name( (i.object_id object_id) ) AS AS object_name object_name, , object_name i.name AS index_name AS index_name FROM sys.indexes indexes i i JOIN JOIN sys sys. .objects objects o o ON i ON i. .object_id object_id = FROM sys. o.object_id WHERE o WHERE o. .type type = 'U' AND i AND i. .index_id NOT NOT IN IN SELECT s s. .index_id (SELECT FROM sys sys. .dm_db_index_usage_stats dm_db_index_usage_stats s s FROM WHERE WHERE s s. . = i. .index_id AND AND s s. .index_id object_id object_id i = i i. .object_id object_id AND s s. .database_id = db_id db_id()) ()) AND ORDER ORDER BY BY object_name( object_name(i.object_id object_id) ) ASC The sys.dm_db_index_usage_stats dynamic management view provides statistics about the index usage from the last time SQL Server was started.
Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
30
You can use the following query to monitor the index usage on a re regular gular basis:
SELECT SELECT object_name object_name( (i.object_id object_id) ) AS AS object_name object_name, , AS index_name, , s s. .index_id index_id, , i.name AS index_name user_seeks + user_scans + user_lookups AS user_reads AS user_reads, , system_seeks + system_scans + system_lookups AS AS , , system_reads system_reads, user_updates, user_updates system_updates FROM sys.dm_db_index_usage_stats dm_db_index_usage_stats s s JOIN JOIN sys sys. .indexes indexes i i FROM sys. ON s s. .index_id = i i. .index_id AND AND s s. .object_id object_id = i i. .object_id object_id ON WHERE WHERE s s. .database_id = db_id db_id() () AND i .type type 0 0 AND i. ORDER BY user_reads BY user_reads DESC ORDER
6.1.2 6.1. 2 Opt Optimize imize C us to tome mer-S r-S pe pecifi cificc T2 T24 4 Queries For queries used by customer-specific code, you should go through the following steps in order to identify performance issues, consider optimizations, and verify the benefit of the optimizations.
1. Identify slow-running queries. To improve query performance, start by identifying slow-running queries.
COB queries:
The close-of-business (COB) calculations are generally the most processing-intensive tasks in T24. The optimization of COB queries is critical for reducing the total duration of the COB. To identify slow-running queries (or just queries which can be optimized to help shorten the COB time), you can use the sys.dm_exec_query_stats dynamic management view. The following query selects the top 50 SQL Server statements ordered by the total CPU time (i.e., total amount of CPU time, in microseconds, for all executions of each statement):
SELECT TOP 50 50 SELECT TOP SUM( (query_stats query_stats. .total_worker_time total_worker_time) ) AS AS "total "total CPU time", time", SUM SUM( SUM (query_stats query_stats. .total_worker_time total_worker_time)/ )/SUM SUM( (query_stats query_stats. .executio n_count) n_count ) AS AS "avg "avg CPU Time", Time", SUM( SUM (query_stats query_stats. .execution_count execution_count) ) AS AS "executes" "executes", , SUM( SUM (query_stats query_stats. .total_logical_reads total_logical_reads) ) AS AS "total "total logical , reads", reads" SUM( SUM (query_stats query_stats. .total_logical_reads total_logical_reads)/ )/SUM SUM( (query_stats query_stats. .execut ion_count) ion_count ) AS "avg AS "avg logical reads", reads", SUM( SUM (query_Stats query_Stats. .total_logical_writes total_logical_writes) ) AS "total AS "total logical writes", writes" , SUM( SUM (query_Stats query_Stats. .total_logical_writes total_logical_writes)/ )/SUM SUM( (query_stats query_stats. .execu ) AS AS "avg logical writes" writes", , tion_count) tion_count MIN( MIN (query_stats query_stats. .statement_text statement_text) ) AS "statement AS "statement text" FROM FROM (SELECT SELECT QS QS.*, .*, Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
31
SUBSTRING(ST SUBSTRING( ST. .text text, , (QS QS. .statement_start_offset statement_start_offset/ /2) + 1 1, , ((CASE (( CASE statement_end_offset statement_end_offset WHEN -1 THEN THEN DATALENGTH DATALENGTH( (ST ST. .text text) ) WHEN ELSE QS ELSE QS. .statement_end_offset END END QS. .statement_start_offset statement_start_offset)/ )/2 2) + 1 1) ) AS AS - QS statement_text FROM FROM sys. sys.dm_exec_query_stats dm_exec_query_stats AS AS QS QS CROSS APPLY sys. sys.dm_exec_sql_text dm_exec_sql_text( (QS QS. .sql_handle sql_handle) ) as ST as ST) ) AS AS CROSS APPLY query_stats GROUP BY query_stats GROUP BY query_stats. .query_hash ORDER BY 1 BY 1 DESC ORDER After completion of the COB, you should look at F_JOB_TIMES for long COB job times. When you have identified the long-running jobs, search the content co ntent of the T24 log file &COMO& to match the jQL queries corresponding to the t he long-running jobs. Compare these jQL queries to the previously identified SQL Server statements to select queries that are good candidates for optimization.
Online Processing:
For online processing, identify slow-running operations in the user interface (UI) ( UI) based on user feedback and try to reproduce them (on a test database system). Use the SQL Server Profiler to capture the corresponding SQL Server queries. After identifying the SQL statements, you should test them and measure the CPU time and I/Os. This can be done using the sys.dm_exec_query_stats dynamic management view and the query described in the previous section. If you identify multiple long-running queries involved in the online operations, sort the queries based on the average CPU time, and consider the number of executions of each query. Optimizing a query which is executed very often is more important than optimizing queries executed only few times.
2. Consider optimizations. After identifying slow-running queries that are good candidates for optimization, consider the following: RE_CONSOLSPEC_ENTRY If there are queries on tables STMT_ENTRY, CATEG_ENTRY, or RE_CONSOLSPEC_ENTRY
using a “where” clause that is different from RECID = , then these are most likely jQL SELECT queries in a custom-developed code. There should generally be no queries on these tables with a search condition using any fields (other than the RECID). These are the biggest T24 tables, containing huge number of records, and there is usually heavy activity on these tables. The application logic and the jQL SELECT queries on o n these tables should be reconsidered and, if possible, rewritten. For example, instead of using STMT_ENTRY, you can use the table ACCT_ENT_TODAY in many cases. ACCT_ENT_TODAY is much smaller in size; the Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
32
key is the account number, and the t he rows in the table contain the key k ey of the entries that have been made into that account during the current business day.
If a query has a search condition on a single-value field, then consider scalar promotion
(see step 3). An example of this type of query is:
SELECT t t. .RECID RECID, ,t.XMLRECORD FROM FROM F_HOLD_CONTROL F_HOLD_CONTROL t SELECT WHERE WHERE XMLRECORD. .exist exist( (N'/row/c2[.="NEW.LOAN.REPORT"]' N'/row/c2[.="NEW.LOAN.REPORT"]') ) = 1 t.XMLRECORD
If a query has a search condition on a specific multi-valued field (specific local reference
field), then consider scalar promotion (see step 3). For example, the following query uses specifically spec ifically the eighth value of a multi-value field in the search condition:
SELECT t.RECID,t.XMLRECORD t.RECID,t.XMLRECORD FROM FROM FBNK_CARD_ISSUE t t WHERE t.XMLRECORD.exist( t.XMLRECORD.exist(N'/row/c14[@m="8"][.=12345]' N'/row/c14[@m="8"][.=12345]') ) = 1
Consider the number of promoted columns and indexes per table. Indexes improve the
performance of select queries, but also increase the time that is required to perform modifications (i.e., inserts, updates, deletes) to the underlying table. Too many indexes may degrade the overall performance. As a general rule, you should avoid creating more than seven indexes on a table. transaction ansaction Do not create XML indexes on T24 XMLRECORD fields. The impact on tr
latency is too high, and the benefit be nefit in query performance is usually not significant.
3. Use scalar promotion. A single-value field (or even a specific value of o f a multi-valued field) that is part of the XMLRECORD can be “promoted” as computed column of the table t able and be used in relational search conditions. Further, a relational index can be created on the computed column to improve the query performance. The minimum required T24 version for scalar promotion is R10 SP5. The detailed steps to promote a single-value XML field are as follows:
1.) Create a persisted computed column for the specific field. Create a user-defined function that evaluates the value of the field. The return value of the function should be a single scalar value. Using this function, the computed column should be added to the table and persisted. per sisted.
Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
33
Following are two examples of scalar promotion:
-- example 1 -- scalar promotion of single valued field field CREATE CREATE FUNCTION FUNCTION udf_HOLD_CONTROL_C2 udf_HOLD_CONTROL_C2( (@xmlrecord XML) XML) RETURNS nvarchar( (35 35) ) RETURNS nvarchar WITH SCHEMABINDING SCHEMABINDING WITH BEGIN RETURN @xmlrecord RETURN @xmlrecord. .value value( ('(/row/c2/text())[1]' '(/row/c2/text())[1]', , 'nvarchar(35)') 'nvarchar(35)') END ALTER TABLE F_HOLD_CONTROL ALTER TABLE F_HOLD_CONTROL ADD C2 AS dbo. .udf_HOLD_CONTROL_C2 udf_HOLD_CONTROL_C2( (XMLRECORD XMLRECORD) ) PERSISTED ADD C2 AS dbo -- example 2 -- scalar promotion of specific multi-valued field CREATE CREATE FUNCTION FUNCTION udf_CARD_ISSUE_CUSTOMER udf_CARD_ISSUE_CUSTOMER( (@xmlrecord XML) XML) RETURNS integer integer RETURNS WITH WITH SCHEMABINDING SCHEMABINDING BEGIN RETURN RETURN .value value( ('(/row/c14[@m="8"]/text())[1]' '(/row/c14[@m="8"]/text())[1]', , @xmlrecord @xmlrecord. 'integer' 'integer') ) END ALTER ALTER TABLE TABLE FBNK_CARD_ISSUE ADD C14_8 AS dbo. .udf_CARD_ISSUE_CUSTOMER udf_CARD_ISSUE_CUSTOMER( (XMLRECORD XMLRECORD) ) ADD C14_8 AS dbo PERSISTED 2.) Create non-clustered index on the computed column.
After creating the persisted per sisted computed column, create an index for this co column: lumn:
-- example 1 1 CREATE CREATE INDEX INDEX ix_HOLD_CONTROL_C2 ix_HOLD_CONTROL_C2 ON F_HOLD_CONTROL ON F_HOLD_CONTROL( (C2 C2) ) -- example 2 CREATE CREATE INDEX INDEX ix_CARD_ISSUE_CUSTOMER ix_CARD_ISSUE_CUSTOMER ON ON FBNK_CARD_ISSUE( FBNK_CARD_ISSUE (C14_8 C14_8) ) Once there is a promoted column for a specific field in the table, t able, T24 automatically translates the queries to use that column relational in the “where” clause if there is a search condition on that field.
Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
34
4. Verify optimizations. Verify that the changes are successful succ essful and measure the impact of the optimizations.
For scalar promotion (promoted and indexed fields):
Verify the query translation. Without scalar promotion, T24 uses a query syntax such as:
SELECT t.RECID,t.XMLRECORD t.RECID,t.XMLRECORD FROM FBNK_CARD_ISSUE t t WHERE t.XMLRECORD.exist( t.XMLRECORD.exist(N'/row/c14[@m="8"][.=12345]' N'/row/c14[@m="8"][.=12345]') ) = 1 The execution of this query usually uses a table scan to retrieve the results. After promoting the field “c2”, T24 should translate the query as:
SELECT t. SELECT t .RECID RECID, ,t.XMLRECORD FROM FBNK_CARD_ISSUE FBNK_CARD_ISSUE t FROM WHERE WHERE c14_8 c14_8 = 12345 In this case, index lookup on ix_CARD_ISSUE_CUSTOMER is used.
Prove that the index is used by reproducing the query and verifying the actual execution plan. You can run the query in SQL Server Management Studio and activate the icon “Include Actual Execution Plan” on the SQL Editor toolbar. Alternatively, you can use the SET STATISTICS PROFILE ON statement to display execution plan information.
Verify the performance of the query has improved.
After using the application for a period of time (e.g., couple of hours or days) or after running COB, use the sys.dm_db_index_usage_stats dynamic management view to verify the index usage. usage . Consider the ratio between index rreads eads and index writes, keeping in mind that an index usually improves the performance for read operations but slows down modifications (i.e., inserts, updates, deletes) at the same time. You can use the queries described in section section Standard T24 Queries Queries for this purpose. You should monitor the index usage statistics on a regular re gular basis.
For jQL queries changed in the application:
Execute the jQL query on the jsh> interface, and verify the performance. Additionally, you should measure the CPU time and I/O operations on the SQL Server. You can use the query described in the Close-of-Business section Close-of-Business section of the document for this purpose.
Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
35
5. Use T24 logical optimization. If you are not able to achieve sufficient performance improvement to specific queries or COB jobs by applying steps 1 –4 above, then consider using concat files, tables used for application-specific purposes in the application layer. In some cases, concat files can also be used as a “logical index” in T24.
6.2 Recommendations Recommendations for Monitoring Performance of the Database Tier You should perform system monitoring during development of your system and periodically during production. Before “going live,” look for bottlenecks and gauge your ability to scale to
your expected long-term workload. Once in production, you should create a performance per formance 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. You should not worry about seeing short spikes in utilization or high consumption during processes that are operating at an acceptable performance level. Note that SQL Server 2008 R2 and SQL Server 2012 introduce new application and multi-server management features, which can help you manage m anage the T24 database environment more efficiently at scale, with visibility into resource utilization for consolidation and improved efficiencies across the application lifecycle. For more information, see see SQL Server 2008 R2 Application and Multi-Server Management Management and and Automated Administration Across an Enterprise. Enterprise. Table 5 shows metrics that your monitoring plan should include.
Metric
Predicts
Database File Sizes (including tempdb)
Need for expansion of files or storage.
Log File Sizes
Need to backup transaction log more often.
Processor/% Processor Time: All Instances
Additional processors.
Average Disk Queue Length
Storage configuration too slow.
Average Disk sec/transfer
May indicate a large amount of disk fragmentation, slow disks, or disk failures. (Should be 10 ms or less.)
Disk Bytes/sec for each LUN
Need to spread data across more LUNs.
Paging in Pages/sec
Need for additional memory.
Network Interface Bytes Received/sec and Network Interface Bytes Sent/sec
Need for increased network capacity or segmentation.
Table 5. Monitoring plan Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
36
7 Best Practices for System Maintenance You should perform regular maintenance tasks to keep SQL S QL Server running optimally. Your maintenance schedule should include implementing a backup strategy, updating database statistics, rebuilding and reorganizing indexes, and identifying and correcting excessive fragmentation. For more information about creating maintenance plans, see see Appendix 1: Create a Maintenance Plan to Back Up the Temenos Application Database Database and and Appendix 2: Create a Maintenance Plan to Back Up the System Databases. Databases.
7.1 Guidance for Backing Up the Database You should back up the T24 database regularly to protect your data. You should also back up the transaction log frequently to protect your data and to keep the transaction tr ansaction log file from growing too large.
7.1.1 7.1. 1 Us e B ackup ck up C ompress ompress ion Backing up a large database can require a significant amount of time and a large amount of disk space for the backup file(s). With SQL Server S erver 2008 (and later ver versions) sions) backup compression, the backup file is compressed as it is written; writte n; this requires less storage, less disk I/O, and less time but incurs more CPU cycles as overhead. The compression is achieved by specifying the WITH COMPRESSION clause in the t he BACKUP command or by selecting compression the Options page in the Back Up Database dialog box. There is also a global setting to compress all backups taken on a server instance by default. (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.) 1 .) The RESTORE command automatically detects that a backup is compressed and decompresses the backup during the restore operation. For more information, see the article article Tuning the Performance of Backup Compression in SQL Server 2008 on SQLCAT.com.
7.1.2 Implem Implement ent a B ack ackup up S chedule A suggested schedule is a weekly full backup, a daily differential backup, and a log backup every hour. 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. Frequent full backups can improve the speed of recovery since it is not necessary to restore as many log files. Your organization may have specific requirements for recovery times, and you should discuss these with a qualified database administrator to determine a backup profile that meets these requirements.
Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
37
It is recommended to schedule the full backup to run after the COB processing pro cessing and after any index maintenance tasks (e.g., index reorganize or index rebuild). If you implement peer-to-peer replication, you must also implement a backup schedule for the target database(s). The distributor database operates in simple recovery mode, so it does not need to be backed up.
7.1.3 B ack Up S ys te tem m Datab Databa as es SQL Server maintains a set of o f system-level databases (called system databases) that are essential for the operation of a server instance. Several of the system databases must be backed up after every significant update: msdb, master, and model. If any database uses replication on the server instance, there is a distribution system database that must also backed up. Backups of these system databases let you restore and recover the SQL Server system in the event of system failure, such as the loss of a hard disk. For more information, see the article artic le Considerations for Backing Up and Restoring System Databases.. Databases
7.2 Recommendations Updating SQL Server collects statistics stat istics aboutfor individual columnsStatistics (single-colu (single-column mn statistics) or sets of columns (multi-column statistics). Statistics are used by the query optimizer to estimate the selectivity of expressions and thus the size of intermediate and final query results. Reliable statistics let the optimizer accurately assess the cost of different query plans and then choose a high-quality plan. For a typical T24 installation, it is recommended to keep the AUTO_CREATE_STATISTICS and AUTO_UPDATE_STATISTICS database options on (which is the default setting). For more information, see the article article Statistics Used by the Query Optimizer in Microsoft SQL Server 2008. 2008. For step-by-step guidance for manually updating statistics using a maintenance job, see Appendix 3: Update Statistics see Statistics..
7.3 Recommenda Recommendations tions for Reorganizi Reorganizing ng or Rebuilding Indexes The SQL Server Database Engine automatically maintains indexes whenever insert, update, or delete operations are applied to the underlying data. Over time, these modifications can cause the information in the index to become scattered or fragmented in the database. Fragmentation exists when indexes have pages in which w hich the logical ordering, based on the key value, does not match the physical ordering inside the data file. Heavily fragmented fragmente d indexes can degrade query performance and cause your application to respond slowly. You can defragment indexes by either reorganizing or rebuilding. For partitioned indexes built on a partition scheme, you can rebuild re build or reorganize a complete index or a single partition of an index. Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
38
To decide which defragmentation method to use, analyze the index to determine the degree of fragmentation. By using the DMF DMF sys.dm_db_index_physical_stats , you can detect fragmentation in a specific index, all indexes on a table or indexed view, all indexes in a database, or all indexes in all databases. Using this function, you have access ac cess to the fragmentation levels available in defined columns at any given time. Table 6 shows some of the information returned ret urned by the sys.dm_db_index_physical_stats function.
Column avg_fragmentation_in_percent
fragment_count
Description The percent of logical fragmentation (out-of-order pages in the index). The number of fragments (physically consecutive leaf pages) in the index.
avg_fragment_size_in_pages
Average number of pages in one fragment in an index.
page_count
The total number of index or data pages.
Table 5. Columns returned from sys.dm_db_index_physical_stats.
You can then use Table 7 as a guide to determine the best method to correct the fragmentation.
avg_fragmentation_in_percent
Corrective statement
> 10 percent and < = 80 percent
ALTER INDEX REORGANIZE
> 80 percent
ALTER INDEX REBUILD
Table 6. Corrective defragmentation method to use.
Note that very low levels of fragmentation fragme ntation (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 reo rganizing or rebuilding the index. The white Practices can provide additional paper Microsoft SQL Server 2000 Index Defragmentation Best Practices paper guidance.
7.3.1 R eo eorg rg anize Inde Indexes xes Reorganize an index when the index is not heavily fragmented. Use the ALTER INDEX statement with the REORGANIZE clause (replaces the DBCC DBC C INDEXDEFRAG statement in Microsoft® SQL Server® 2000). To reorganize a single partition of a partitioned index, use the PARTITION clause of ALTER INDEX.
Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
39
The reorganize process uses minimal system resources. Also, reorganizing is automatically performed online. The process does not hold long-term blocking locks; therefore, t herefore, it does not block running queries or updates.
7.3.2 7.3. 2 R eb ebuild uild Inde Indexes xes whe when n Necess ary Rebuilding an index drops the index and creates a new one. In doing this, fragmentation is removed, disk space is reclaimed by compacting the pages using the specified or existing fillfactor setting, and the index rows are reordered in contiguous pages (allocating new pages as needed). This can improve disk performance by reducing the number of page reads required to obtain the requested data. The following methods can be used to rebuild clustered and non-clustered indexes:
ALTER INDEX with the REBUILD clause. This statement replaces the DBCC DBREINDEX
statement.
CREATE INDEX with the DROP_EXISTING clause.
Each method performs the same function, but there are advantages and disadvantages to consider. See Reorganizing See Reorganizing and Rebuilding Indexes Indexes for more information. Note, that the clustered index cannot be rebuilt online if the underlying table contains XML data type. Appendix 4: Reorganize and Rebuild Indexes Indexes provides step-by-step guidance on creating maintenance plans for these operations.
7.4 Recommendations for Update Management A general recommendation is to keep your Microsoft software up to date with the most recent software updates. Software Updates (e.g., hotfixes, Cumulative Updates, service packs, etc.) can help prevent or fix problems, enhance the security of your computers, and improve how tthe he computers work. Consider testing and applying software updates on a regular r egular basis. For more information on applying updates, see see Update Management TechCenter TechCenter and and SQL Server 2008 failover cluster rolling patch and service pack process process (also apply to SQL Server 2012).
7.4.1 S QL S erver 2012 S et etup up P roduct Upda Update te Product Update is a new feature in SQL Server 2012 Setup. 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. t ime. Product Update can search Microsoft Update, Windows Server Update Services (WSUS), a local folder, or a network share for applicable updates. After Setup finds the latest versions of the applicable updates, it downloads and integrates them with the current c urrent SQL Server setup process. Product Update can pull in a cumulative update, service pack, or service pack plus cumulative update.
Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
40
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.microsoft.com/en-us/library/hh231670(v=SQL.110).aspx http://msdn.microsoft.com/en-us/library/hh231670(v=SQL.110).aspx Product Updates in SQL Server 2012 Installation http://msdn.microsoft.com/en-us/library/hh231670.aspx
7.4.2 7.4 .2 R un A nti-Virus nti-Virus C he hecks cks Duri ng Non Non-Pea -Peakk Hours Hours While every environment and infrastructure will have its own unique considerations, you should consider avoiding running real-time anti-virus checks; instead, run scheduled virus checks during non-peak hours.
7.4.3 7.4. 3 C onsi de derr R unning W Window indowss Upda Update tess on a Test Server be before fore Production As with anti-virus checks, you should carefully consider the unique characteristics character istics of your infrastructure when deciding on a plan for patch management. Your update strategy will depend on your organization’s policies, as well as those of Temenos. As a general rule, enterprises should manage the update process in a different way than desktop users; enterprises should Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
41
implement their own update services, defining a specific strategy and installing the updates on a test server to verify their the ir impact before installing them in production. For more information, see see Windows Server Update Services. Services. Security patching is an important subset of updates. You can find information about security patching in in Ten Principals of Microsoft Patch Management. Management. Also see the Microsoft Support article Guidelines for choosing antivirus software to run on the computers that are running SQL article Server.. Server
Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
42
8 Summary TEMENOS T24, coupled with Microsoft SQL Server database software, provides financial institutions with a complete banking solution. Using the best practices described in this white paper can help optimize the performance of o f the database tier. The links in the section that follows provide even more information. For the latest benchmarking results on SQL Server 2012, see the link below: TEMENOS T24 and SQL Server 2012 running on IIntel ntel Xeon processor-based servers set a new world record in the latest high-water benchmarking tests 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, 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 A lwaysOn High Availability and Disaster Recovery Design Patterns SQL Server 2012 AlwaysOn Introducing SQL Server 2012 AlwaysOn
Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
43
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 Conside rations
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 - 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 the SQL Server Best Practices Practices portal for technical white papers, the SQL Server Best Practices Toolbox, Top 10 Lists, and other resources. r esources.
Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
44
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. The following step-by-step instructions guide you through the process. 1. Open SQL Server Management Studio, expand the Management node, and then expand the Management Plans node. 2. Right-click Maintenance Plans, click Maintenance Plan Wizard, and then type an appropriate name for this Temenos application database backup plan.
Figure 2. Click Maintenance Plan Wizard.
3. Click Separate schedules for each task, because you will later select both full and transaction log backups. Click Next.
Figure 3. Select the plan properties.
Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
45
4. On the Select Maintenance Tasks dialog box, select Clean Up History, Back Up
Database (Full), Back Up Database (Transaction (T ransaction Log), and Maintenance Cleanup Task. Click Next twice.
Figure 4. Select maintenance tasks.
5. As you complete the Maintenance Plan Wizard, W izard, you should select options based on the needs of your organization. The following figures show examples of options you may want to select. a. On the Define History Cleanup Task dialog box, select the historical data you want to delete and the schedule. Click Next.
Figure 5. Options to define the history his tory cleanup task.
Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
46
b. On the Define Back Up Database (Full) Task dialog box, click on These
databases, and select the T24 user database in the Database(s) box. Click OK.
Figure 6. Options to configure the backup database task.
Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
47
c. On the Job Schedule Properties dialog box, select the frequency and duration of full backups. It is recommended to schedule the full backup to be executed, after the COB processing. Click OK.
Figure 7. Options to select for the job schedule properties.
d. On the Define Back Up Database (Full) Task dialog box, specify information about the full backup. Click Next.
Figure 8. Options to set the backup parameters. Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
48
e. On the Job Schedule Properties dialog box, select the frequency and duration of transaction log backups. Click OK.
fre quency and duration of transaction log backups. Figure 9. Options to set the frequency
f. On the Define Back Up Database (Transaction Log) Task dialog box, configure the transaction log backup. Click Next.
Figure 10. Options to configure the transaction log backups. Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
49
g. On the Define Maintenance Cleanup Task dialog box, configure the cleanup tasks. Click Next.
Figure 11. Options to define the maintenance cleanup tasks.
h. On the Select Report Options dialog box, select whether to write the report to text file or send the report through email. Click Next. 6. Review your selections, and then click Finish.
Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
50
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. The following step-bystep instructions guide you through the process. 1. Open SQL Server Management Studio, expand the Management node, and then expand the Management Plans node. 2. Right-click Maintenance Plans, click Maintenance Plan Wizard, and then type an appropriate name for this Temenos system database backup plan.
Figure 12. Click Maintenance Plan Wizard.
3. On the Select Plan Properties dialog box, click Single schedule for the entire plan or no t he frequency and duration of transaction log schedule, and click Change to select the backups. Click Next.
Figure 13. Select the plan properties.
Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
51
4. On the Select Maintenance Tasks dialog box, select Clean Up History, Back Up
Database (Full), and Maintenance Cleanup Task. Click Next.
Figure 14. Select the maintenance tasks.
5. On the Select Maintenance Task Order dialog box, make sure that the tasks appear in the order shown in Figure 15. Click Next.
Figure 15. Verify the order of the maintenance tasks.
Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
52
6. As you complete the Maintenance Plan Wizard, W izard, you should select options based on the needs of your organization. The following figures show examples of options you may want to select. a. On the Define Back Up Database (Full) Task dialog box, select System
databases. Click OK.
Figure 16. Select the system databases.
Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
53
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
11 Appendix 3: Update Statistics You should create a maintenance plan to update statistics. stat istics. The following step-by-step instructions guide you through the process. 1. Open SQL Server Management Studio, expand the Management node, and then expand the Management Plans node. 2. Right-click Maintenance Plans, and click Maintenance Plan Wizard.
Figure 21. Click Maintenance Plan Wizard.
3. On the Select Plan Properties dialog box, type an appropriate name for this statistics update plan, and click Single schedule for the entire plan or no schedule. Click Change to select the frequency fre quency and duration of statistics updates.
Figure 22. Select the plan properties.
Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
57
4. Based on your organization’s needs, select the frequency and duration of the statistics updates on the Job Schedule Properties – Update Update Temenos Statistics (FullScan) dialog box. Click OK, and then click Next.
Figure 23. Select the frequency and duration of updates.
5. On the Select Maintenance Tasks dialog box, select only Update Statistics. Click Next.
Figure 24. Select the update statistics task.
Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
58
6. On the Select Maintenance Task Order dialog box, make no changes. Click Next.
Figure 25. Make no changes on the task order dialog box.
7. On the Define Update Statistics Task dialog box, click on These databases, and select the T24 user database in the Database(s) box. Click OK.
Figure 26. Select the Temenos user database.
Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
59
8. On the Define Update Statistics Task dialog box, select Tables and views in the Object box. Under Scan type, click Full scan. Click Next.
Figure 27. Define parameters for the update statistics task.
9. On the Select Report Options dialog box, select report r eport options based on your organization’s needs. Click Next.
Figure 28. Select report options.
10. Review your selections, and then click Finish.
Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
60
12 Appendix 4: Reorganize and Rebuild Indexes The following script samples automatically reorganize or rebuild all partitions in a database. The first one reorganizes all indexes that have an average fragmentation between 10% and 80%. The second script rebuilds all indexes with an average fragmentation greater g reater than 80 perce percent. nt. Executing these scripts requires the VIEW DATABASE STATE permission. These examples use DB_ID() instead of specifying particular database name. Note that an error is generated if the current database has a compatibility level of 80 or less. To resolve the error, replace re place DB_ID() with a valid database name. For more information about database compatibility levels, see see sp_dbcmptlevel (Transact-SQL). (Transact-SQL). For more information, see the article artic le sys.dm_db_index_physical_stats sys.dm_db_index_physical_stats (Transact-SQL).
-- Reorganize indexes -- Ensure that a USE statement has been executed first. SET SET NOCOUNT NOCOUNT ON ON; ; DECLARE @objectid DECLARE @objectid int; int; DECLARE @indexid DECLARE @indexid int int; ; DECLARE @partitioncount DECLARE @partitioncount bigint bigint; ; DECLARE @schemaname DECLARE @schemaname nvarchar( nvarchar(130 130); ); DECLARE @objectname nvarchar(130 130); ); DECLARE @objectname nvarchar( DECLARE @indexname nvarchar( (130 130); ); DECLARE @indexname nvarchar DECLARE @partitionnum @partitionnum bigint; bigint; DECLARE DECLARE @partitions DECLARE @partitions bigint; bigint; DECLARE @frag DECLARE @frag float; float; DECLARE @command DECLARE @command nvarchar nvarchar( (4000 4000); ); -- Conditionally select tables and indexes from the sys.dm_db_index_physical_stats function sys.dm_db_index_physical_stats -- and convert object and index IDs to names. SELECT object_id object_id AS objectid AS objectid, , index_id AS indexid AS indexid, , partition_number AS partitionnum AS partitionnum, , avg_fragmentation_in_percent AS frag AS frag INTO #work_to_do #work_to_do INTO FROM sys. FROM sys.dm_db_index_physical_stats dm_db_index_physical_stats (DB_ID DB_ID(), (), NULL, NULL, NULL NULL , NULL, NULL, 'LIMITED') ) 'LIMITED' WHERE WHERE avg_fragmentation_in_percent avg_fragmentation_in_percent > 10.0 AND avg_fragmentation_in_percent avg_fragmentation_in_percent 1 Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
63
SET @command = @command + N' PARTITION=' SET @command PARTITION=' + CAST( (@partitionnum AS AS nvarchar nvarchar( (10 10)); )); CAST EXEC (@command @command); ); PRINT PRINT N'Executed: ' ' + @command @command; ; END; END ; -- Close and deallocate the cursor. CLOSE partitions CLOSE partitions; ; DEALLOCATE DEALLOCATE partitions partitions; ; -- Drop the temporary table. DROP DROP TABLE #work_to_do TABLE #work_to_do; ; 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 o n the 2 sample script). Ideally, the index maintenance tasks (reorganization or rebuild) should be performed after COB processing and before a full backup is executed. To create a nightly or weekly job to perform the reorganizing or rebuilding, perform the following steps: 1. Right-click Jobs, and click New Job.
Figure 29. Click New Job.
Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
64
2. Name the job so it can be easily identified as the reorganization or rebuilding index.
Figure 30. Name the maintenance job.
3. Click Steps, and then click New. Enter the step name (e.g., Reorg or Rebuild), select the type Transact-SQL script (T-SQL), specify the T24 database name, and copy the script sample into the Command field. To make sure that there are no errors in the T-SQL script, click Parse. Click OK.
Figure 31. Copy the script sample, and parse it.
Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
65
4. Select the Advanced page, change the On Success action to Quit the job reporting
success, and click OK.
Figure 32. Configure job step advanced options.
5. On the New Job Schedule dialog box, schedule the job to run nightly or weekly, depending on the needs of your organization. Click OK.
Figure 33. Options for scheduling jobs.
Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
66
6. On the Job Properties – Temenos Temenos Index Reorg/Rebuild dialog box, configure the notifications for the job based on your organization’s needs. (Note that database email must be configured correctly for the notifications to work.) Click OK.
Figure 34. Configure job notifications.
Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
67
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), or Microsoft® SQL Server® 2008 R2 Enterprise, 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, 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 grante d (see security section) Antivirus exclusions configured for SQL Server files Windows Server Power Plan checked
SQL Server configuration:
Trace flag 1118, and eventually Trace flag 1117, 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
View more...
Comments
