Best Practices for Running

Best Practices for Running TEMENOS T24 on

Microsoft SQL Server and Windows Server

Guidance for fine-tuning T24 implementations on Windows Server 2008 R2 and on the

SQL Server 2008 R2 database platform

V1.0 Published: October, 2010

Produced by the Temenos Database Technology Group and contributors from Microsoft:

Lonnye Bower, Konstantin Dotchkoff, Roger Toren - writing

Peter Carlin and Kun Cheng - reviewing

Abstract

TEMENOS T24 (T24) is a complete banking solution designed to meet the challenges faced by

financial institutions in todays competitive market. T24 provides a single, real-time view of

clients across the entire enterprise, making it possible for banks to maximize returns and keep

costs down.

Microsoft SQL Server provides the ideal database platform for T24. By choosing the Microsoft

platform, T24 customers experience faster funds transfers, higher security-trade volumes, and

quicker close-of-business processes; T24 customers can also benefit from open, state-of-the-art

technologies to accelerate innovation, greatly increasing the speed and effectiveness with which

new products and services are created. Using Windows Server 2008 R2 as the operating system

makes it possible for T24 to exceed performance standards in a scalable, reliable environment

that offers ease of management.

This white paper provides best practices for configuring and running TEMENOS T24 on Windows

Server and on the SQL Server database platform. Implementing these best practices can help

you avoid or minimize common problems and optimize the performance of your TEMENOS T24

implementation.

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

This document is provided as-is. Information and views expressed in this document, including URL and

other Internet Web site references, may change without notice. You bear the risk of using it.

This document does not provide you with any legal rights to any intellectual property in any Microsoft

product. You may copy and use this document for your internal, reference purposes.


Table of Contents

1 OVERVIEW ....................................................................................................................................... 5

2 BEST PRACTICES FOR THE DATABASE SERVER .................................................................................. 7

2.1 SERVER RECOMMENDATIONS ............................................................................................................... 7 2.1.1 Use the Latest Software Versions...................................................................................................... 7 2.1.2 Use a 64-Bit Server ............................................................................................................................ 7 2.1.3 Use a Dedicated Server ..................................................................................................................... 8

2.2 SIZING RECOMMENDATIONS ................................................................................................................ 8

2.3 STORAGE DESIGN RECOMMENDATIONS .................................................................................................. 9 2.3.1 Use SAN and RAID 10 ........................................................................................................................ 9 2.3.2 Set the Partition Offset ................................................................................................................... 10 2.3.3 Set the File Allocation Unit Size and Stripe Size............................................................................... 10 2.3.4 Dedicate a High Percentage of SAN Cache to Writes ...................................................................... 11 2.3.5 Configure Windows Drives .............................................................................................................. 11

2.4 HARDWARE AND NETWORK GUIDANCE ................................................................................................ 11 2.4.1 Use a Private Network Segment ..................................................................................................... 11 2.4.2 Enable Receive-Side Scaling ............................................................................................................ 12 2.4.3 Consider NIC Teaming ..................................................................................................................... 12 2.4.4 Use Multiple HBAs and Set the HBA Queue Depth .......................................................................... 12

2.5 DATA, LOG, TEMPDB, AND BACKUP FILE RECOMMENDATIONS .................................................................. 13 2.5.1 Configure Data Files ........................................................................................................................ 13 2.5.2 Configure the Log File ..................................................................................................................... 13 2.5.3 Configure tempdb Files ................................................................................................................... 13

2.6 RECOMMENDATIONS FOR MEMORY SETTINGS ....................................................................................... 14 2.6.1 SQL Server Memory Settings ........................................................................................................... 14 2.6.2 Lock Pages in Memory .................................................................................................................... 14

2.7 GUIDANCE FOR SQL SERVER CONFIGURATION SETTINGS ......................................................................... 15 2.7.1 Consider Lower Fill Factor ............................................................................................................... 15 2.7.2 Increase the SQL Server Recovery Interval ...................................................................................... 16 2.7.3 Use Trace Flag 834 .......................................................................................................................... 16 2.7.4 Keep Default Setting for Degree of Parallelism ............................................................................... 16 2.7.5 Keep Default Setting for Number of Worker Threads ..................................................................... 16 2.7.6 Encrypt Client Communication if Required ...................................................................................... 16

3 BEST PRACTICES FOR THE APPLICATION SERVER ........................................................................... 17

3.1 SOFTWARE RECOMMENDATIONS ........................................................................................................ 17 3.1.1 Use the Latest Software Versions.................................................................................................... 17

3.2 T24 CONFIGURATION RECOMMENDATIONS .......................................................................................... 17 3.2.1 Configure the T24 Bulk Factor Parameter ....................................................................................... 17 3.2.2 Configure the T24 Handle Cache Parameter ................................................................................... 17 3.2.3 Consider Using Hyper-Threading .................................................................................................... 18

4 BEST PRACTICES FOR PROVIDING HIGH AVAILABILITY ................................................................... 19


4.1 HIGH AVAILABILITY RECOMMENDATIONS FOR THE DATABASE ................................................................... 19

4.2 HIGH AVAILABILITY RECOMMENDATIONS FOR THE STORAGE ..................................................................... 20

4.3 T24 RECOVERY................................................................................................................................ 20 4.3.1 Online Recovery .............................................................................................................................. 20 4.3.2 Close of Business (COB) ................................................................................................................... 20

5 BEST PRACTICES FOR DISASTER RECOVERY .................................................................................... 21

5.1 SAN MIRRORING ............................................................................................................................. 21

5.2 SYNCHRONOUS DATABASE MIRRORING ................................................................................................ 21

5.3 ASYNCHRONOUS REPLICATION METHODS ............................................................................................. 22

5.4 RECOMMENDATIONS FOR CONNECTION BANDWIDTH ............................................................................. 22

6 BEST PRACTICES FOR REPORTING .................................................................................................. 23

7 BEST PRACTICES FOR PERFORMANCE TUNING .............................................................................. 24

7.1 GUIDANCE FOR IMPROVING QUERY PERFORMANCE ................................................................................ 24 7.1.1 Optimize Standard T24 Queries ...................................................................................................... 24 7.1.2 Optimize Customer-Specific T24 Queries ........................................................................................ 25

7.2 RECOMMENDATIONS FOR MONITORING PERFORMANCE OF THE DATABASE TIER .......................................... 30

8 BEST PRACTICES FOR SYSTEM MAINTENANCE ............................................................................... 31

8.1 GUIDANCE FOR BACKING UP THE DATABASE ......................................................................................... 31 8.1.1 Use Backup Compression ................................................................................................................ 31 8.1.2 Implement a Backup Schedule ........................................................................................................ 31 8.1.3 Back Up System Databases ............................................................................................................. 32

8.2 RECOMMENDATIONS FOR UPDATING STATISTICS .................................................................................... 32

8.3 RECOMMENDATIONS FOR REORGANIZING OR REBUILDING INDEXES ........................................................... 32 8.3.1 Reorganize Indexes ......................................................................................................................... 33 8.3.2 Rebuild Indexes when Necessary .................................................................................................... 34

8.4 RECOMMENDATIONS FOR UPDATE MANAGEMENT ................................................................................. 34 8.4.1 Maintain Your Microsoft Software ................................................................................................. 34

9 SUMMARY ..................................................................................................................................... 35

10 APPENDIX 1: CREATE A MAINTENANCE PLAN TO BACK UP THE TEMENOS DATABASE ................... 37

11 APPENDIX 2: CREATE A MAINTENANCE PLAN TO BACK UP THE SYSTEM DATABASES .................... 43

12 APPENDIX 3: UPDATE STATISTICS .................................................................................................. 49

13 APPENDIX 4: REORGANIZE AND REBUILD INDEXES ........................................................................ 53

14 APPENDIX 5: INSTALLATION CHECK LIST ........................................................................................ 60


1 Overview

To help financial institutions face the challenges posed by todays 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 the most advanced and scalable architecture available today.

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 system and Microsoft SQL Server

data management software benefit from a wide range of products and tools that can be used to

further improve the performance and extend the capabilities of the T24 banking solution.

Figure 1 shows a logical model of the interaction of the various services and components that

make up a T24 banking implementation. In this white paper, we focus on best practice guidance

for the database layer (in green).

Figure 1. Logical architecture of T24.


This white paper, intended for database administrators (DBAs), describes optimizations that you

can make to the database tier and describes the database tiers 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 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 your TEMENOS

T24 implementation and can also help you avoid or minimize common problems.


2 Best Practices for the Database Server

Following are some best practices you should use to configure your database server.

2.1 Server Recommendations

2.1.1 Use the Latest Software Versions

For best performance, you should use the latest software versions. Currently, you should use:

T24 Version R10 SP5.

T24 version R10 SP5 contains key performance and scalability improvements for running T24 on

Windows Server and SQL Server.

Microsoft SQL Server 2008 R2.

SQL Server 2008 R2 contains performance and scalability improvements for running on

computes with many cores, such as those commonly used in banking implementations.

Windows Server 2008 R2 operating system.

Windows Server 2008 R2 provides many benefits, including:

A more 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 Best Practices for Disaster Recovery.

Receive-side scaling (RSS), which makes it possible for network packet processing to be

distributed across more CPUs. For more information, 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 Windows Server 2008 R2.

Note: On a database server running Windows Server 2008 R2, you should apply Windows

hotfix KB976700 to avoid excessive kernel time when an application performs many large I/O

operations. The excessive kernel time occurs if the total I/O bandwidth of the computer is not

large enough, decreasing application performance. For more information, see Microsoft Support

Article 976700.

2.1.2 Use a 64-Bit Server

64-bit servers provide efficient access to the memory and the number of cores required by T24.


2.1.3 Use a Dedicated Server

If you are mixing workloads on one physical computer, you should use virtual machines or

Windows/SQL Server mechanisms to control and monitor resource usage. Diagnosing

performance problems requires more effort and precision on a system with mixed workloads.

2.2 Sizing Recommendations You can use Table 1 for guidance on hardware resources and time required to complete the

daily close-of-business (COB) workload of a T24 Retail Model Bank system.

The table contains resource utilization results for several installation sizes based on the number

of customer accounts, i.e., 1 million (1M), 5 million (5M), 10 million (10M), and 25 million (25M)

accounts.

Size 1M 5M 10M 25M

Workload

Transactions Accruals Accruals Accruals Accruals &

Capitalizations

COB Total Time 0hr 52min 2hr 17min 1hr 56min 3hr 17min

IC.COB Time 0hr 13min 0hr 59min 0hr 54min 1hr 20min

Application

Tier

#TAFC Agents 64 120 128 320

#Cores 32 Xeon

5435 48 Xeon 5435

32 Xeon 5435

+

32 AMD 2384

188 (X6550,

E5540, E5650,

X7560)

CPU utilization 28% 42% 50% 73%

Cores used if

CPU at 100% 9 17 32 137

Database

Tier

#Cores 24 Xeon

7460 24 Xeon 7460 32 Xeon 7560 64 Xeon 7560

CPU utilization 19% 29% 34% 70%

Cores used if

CPU at 100% 5 7 11 45

Memory 64GB 64GB 128GB 1TB

Memory used 48GB 60GB 80GB 600GB

Network NIC bandwidth 1Gbps 1Gbps 10Gbps 10Gbps

#NICs in DB 1 1 1 1


I/O

System

IOPS avg 660 970 2,000 7,000

IOPS peak 3,000 2,800 53,000 62,000

Data IOPS avg 260 510 1,500 6,000

Log IOPS avg 400 440 610 1,000

Data IOPS peak 1,340 2,100 52,000 60,000

Log IOPS peak 2,680 2,800 4,930 1,500

Table 1. T24 COB resource utilization.

These results are based on lab testing with a standardized workload; every application has

different functionality and different close-of-business processes. You should 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.

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

2.3.1 Use SAN and RAID 10

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 (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.


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 2. Choosing drives from multiple buses to create a LUN.

You should refer to the article 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 well-

tuned I/O subsystem are:

< 5 milliseconds (ms) for log (ideally 1 ms on arrays with cache)

< 20 ms for data on OLTP systems (ideally 10 ms or less)

2.3.2 Set the Partition Offset

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 of 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 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.)

2.3.3 Set the File Allocation Unit Size and Stripe Size

When formatting the partition that will be used for SQL Server data files, you should use a 64-

kilobyte (KB) allocation unit size for data, logs, and the 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

For details on managing disk partition sector alignment, see Disk Partition Alignment Best

Practices for SQL Server.


2.3.4 Dedicate a High Percentage of SAN Cache to Writes

Most SANs have a large cache that can be split between a read cache and a write cache. SQL

Server provides read-ahead and read caching, 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.

2.3.5 Configure Windows Drives

Once you have configured LUNs on your SAN, you 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.

Physical Drive LUN Drive Usage

112 1 E data

1324 2 F data

2536 3 G tempdb

3748 4 H log

Table 3. 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 Top 10 Best Practices.

2.4 Hardware and Network Guidance The following are some important best practices for the hardware and networking of your T24

database implementation.

2.4.1 Use a Private Network Segment

The traffic between T24 application servers and SQL Server and the traffic between SQL Server

and the storage system is quite high. You should use a private network segment for T24SQL

Server communication. This should be at least a 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.


2.4.2 Enable Receive-Side Scaling

You should enable Receive-Side Scaling (RSS) on the SQL Server network interface card (NIC)

that is serving the application servers. This setting is found on the Advanced Property tab of the

network card. Also, be sure that offloading options are enabled. See the Microsoft Developer

Network (MSDN) articles Introduction to Receive-Side Scaling and Receive-Side Scaling

Enhancements in Windows Server 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 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.

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.

2.4.3 Consider NIC Teaming

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

performance to be sure that any benefit of NIC teaming is not offset by the disabling of any of

the RSS and offloading options.

2.4.4 Use Multiple HBAs and Set the HBA Queue Depth

You should use at least two host bus adapters (HBAs) to provide redundancy and to increase

bandwidth between the SAN and SQL Server. The HBA cards should be set as load balanced and

configured to provide high availability among them. Connections between the SAN and server

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. Note that this is a new recommendation; 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.


2.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 type of use.

You should avoid using very large LUNs (several hundred GB or more) so that chkdsk does not

run for an excessive length of time if it is invoked by the operating system on startup.

2.5.1 Configure Data Files

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 Server optimizes

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

2.5.2 Configure the Log File

The transaction log file, generally a sequentially written file, must be written as quickly as

possibleeven before the data is written 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 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.

2.5.3 Configure tempdb Files

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

versioning. For more information, 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 autogrow (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).

For more information about this SQL Server trace flag, see the article Concurrency

Enhancements for the tempdb Database.

For information on how to set startup settings for SQL Server, see the article Configure Server

Startup Options (SQL Server Configuration Manager.

For further information, see the MSDN article Optimizing tempdb Performance.

2.6 Recommendations for Memory Settings Following are recommendations for the memory settings for SQL Server.

2.6.1 SQL Server Memory Settings

See section Sizing Recommendations (and Table 1) for appropriate memory sizing for the

database system.

You should then configure the SQL Server max server memory (MB) setting by taking the

amount of memory allocated to the database system and subtracting one GB for every four

cores (round up). 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]).

2.6.2 Lock Pages in Memory

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 How to reduce paging of buffer pool memory in the 64-bit version

of SQL Server on the Microsoft Support site.


2.7 Guidance for SQL Server Configuration Settings Following is guidance for SQL Server configuration settings.

2.7.1 Consider Lower Fill Factor

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 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 sys.dm_os_wait_stats

WHERE wait_type LIKE 'PAGELATCH%'

To identify which tables and which pages experience latch contention, you can use the following

queries:

SELECT *

FROM sys.dm_db_index_operational_stats (DB_ID('T24'), NULL,

NULL, NULL)

ORDER BY [page_latch_wait_in_ms] DESC,

tree_page_latch_wait_in_ms DESC

and

SELECT * FROM sys.dm_os_waiting_tasks

WHERE wait_type LIKE 'PAGELATCH%'

Table 4 shows tables that have been identified as likely candidates for a lower fill factor setting

during lab testing:

Table 4. Table candidates for lower fill factor.

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


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 Fill Factor.

2.7.2 Increase the SQL Server Recovery Interval

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 510 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.

For more information about the recovery interval option, see the article Recovery Interval

Option.

2.7.3 Use Trace Flag 834

On computer systems with 64 or more CPU cores, use startup trace flag 834. When this trace

flag is set, SQL Server uses Windows large-page memory allocations for the buffer pool.

Allocating buffer pages is expensive, and turning on trace flag 834 boosts performance.

For more information about this SQL Server trace flag, see Microsoft Support Article 920093

2.7.4 Keep Default Setting for Degree of Parallelism

Leave the default setting of max degree of parallelism option unchanged.

2.7.5 Keep Default Setting for Number of Worker Threads

Leave the default setting of max worker threads option unchanged.

2.7.6 Encrypt Client Communication if Required

If required, you can enable encrypting client connection communication to SQL Server. SQL

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 to support encryption. Clients can also

request encryption when connecting to SQL Server.

For more Information, see Encrypting Connections to SQL Server and How to: Enable Encrypted

Connections to the Database Engine (SQL Server Configuration Manager).


3 Best Practices for the Application Server

Following are some best practices you should use for configuring your T24 application server.

3.1 Software Recommendations

3.1.1 Use the Latest Software Versions

For best performance, you should use the latest software versions. Currently, you should use:

Use TAFC Version R10 SP5.

TAFC version R10 SP5 contains key performance and scalability improvements for running T24

on Windows Server and SQL Server.

3.2 T24 Configuration Recommendations Following are recommendations for some T24 parameters.

3.2.1 Configure the T24 Bulk Factor Parameter

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 parameter value: increasing the bulk factor value

improves throughput by processing more statements within each transaction but also increases

the possibility of longer transactions and blocking.

You should 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.

3.2.2 Configure the T24 Handle Cache Parameter

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_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.

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 5. Handle cache parameter scale based on application server memory.

3.2.3 Consider Using Hyper-Threading

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., Intel Nehalem-EX+); you

should consider turning hyper-threading on when using the newer chipsets and observe the

influence on performance.


4 Best Practices for Providing High

Availability

Failover clusteringa high-availability (HA) solutioncan 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.

4.1 High Availability Recommendations for the Database In a T24 implementation, SQL Server is 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 5,

providing redundancy for the LUNs used by SQL Server. The SAN is connected to the servers 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 transactional load and on the

configuration, such as the number of drives or other resources in the resource group.)

The cluster can also be used for planned maintenance. With SQL Server 2008, 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.) For more information on

applying service packs to a failover cluster instance, see SQL Server 2008 Failover Cluster Rolling

Patch and Service Pack Process.

T24 uses a lock arbiter called jDLS to maintain locks in a multi-application server setup. When

an application lock needs to be taken, a request is sent to the jDLS socket server. jDLS can be

installed:

In a resilient mode on two application servers.

On the database server if enough resources are available. (Note that approximately 20%

more CPU utilization on the database server is expected in this case.)

On a separate application server.

In a cluster configuration with jDLS installed on the database server, you can configure jDLS in

resilient mode and place jDLS on both database server nodes, with the primary jDLS being on

the active cluster node.

For general overview on the high-availability features of SQL Server, see High Availability

Always On Technologies and High Availability with SQL Server 2008 R2.


4.2 High Availability Recommendations for the Storage As described in section Storage Design 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 of its components are redundant.

You should be sure to consider the disaster recovery options described in the section Best

Practices for Disaster Recovery to mitigate the effect of a total SAN failure.

4.3 T24 Recovery When an error or connection failure occurs (e.g., a database failover event) during the

processing of transactions either online or as a COB agent, the controlling T24 process

terminates. Because the exact transaction state cannot be ascertained between connection

failures and reconnects, the current transaction is completely rolled back and restarted on

another process.

4.3.1 Online Recovery

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 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 secondary database node that is

active after the failover, and the transaction is then processed as normal.

4.3.2 Close of Business (COB)

Under normal operation, the T24 COB processes (agents or tSAs) are started 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 restart

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 restarted, which then

restarts the tSAs letting the COB processes continue from where they left off. You cannot

automatically restart the tSM by design, because an assessment of the failure is required to

ensure that its a real disconnection rather than a temporary network interruption.


5 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 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 site. This means that all writes to

the storage systems must complete at both sites before the transaction is committed, which can

increase the time to perform the transaction significantly, depending on the line speed.

The two primary methods of synchronous replication are SAN mirroring 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.

5.1 SAN Mirroring SAN mirroring synchronizes the contents of one SAN with another and requires very high

bandwidth between the two SANsusually dark fiber is recommended. A benefit of SAN

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 is not possible to determine

if the mirror is synchronized after a disaster, and you cannot easily discover any differences.

5.2 Synchronous Database Mirroring Also known as high-safety mode, synchronous database mirroring guarantees that the mirror

and the primary databases are synchronized on all committed transactions. It is important to

note that only the one database being mirrored is synchronizedno other databases or files are

synchronized in the same operation.

Database mirroring can use any form of TCP connectivity between the two servers, 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:

One site is geographically close to the primary site (under 100 kilometers [km]) and uses

mirroring to maintain an exact mirror of the primary site.

A second site is geographically remote from the primary site and is synchronized using

one of the asynchronous methods that can use a lower, less-expensive bandwidth.


For more information, see Synchronous Database Mirroring (High-Safety Mode).

5.3 Asynchronous Replication Methods If a small potential for loss of recently 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. A transaction may be committed on one

server, but not on the other until much later.

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

For more information, see Log Shipping Overview, Database Mirroring Overview, and

Transactional Replication Overview.

5.4 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

log compression ratio of 1:4, you should plan at least a 40-Mbit/sec (or 5 MByte/sec) link to the

DR site for configurations with 10 million accounts.


6 Best Practices for Reporting

In the default implementation of T24, reports are generated from the same database as online

services. If you find that this has an unacceptable impact on online performance, you can shift

the reporting workload to another database server.

Transactional replication is recommended for maintaining a near real-time copy of the database

for reporting purposes. For reducing the data volume of the reporting database and network

utilization between the servers, it is also possible to replicate only a subset of the T24 tables that

are relevant for reporting. T24 system tables can be omitted from replication as they do not

contain business data. Temenos provides a list of system tables that do not need to be

replicated.

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 the subscription from the primary

backup.

There are alternatives that can be considered, including snapshots, log shipping, and database

mirroring, but these are generally not as effective as replication.

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.

Database mirroring can only mirror to one other server. You cannot mirror a database

to both the DR site and to a reporting site.


7 Best Practices for Performance Tuning

Following is guidance for performance tuning for a T24/SQL Server implementation.

7.1 Guidance for Improving Query Performance A typical T24 application consists of T24 core functionality, a number of 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.

7.1.1 Optimize Standard T24 Queries

Temenos provides a post-installation script for creating indexes on the fields that the standard

T24 application code uses most often. 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 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

object_name(i.object_id) AS object_name,

i.name AS index_name

FROM sys.indexes i JOIN sys.objects o ON i.object_id =

o.object_id

WHERE o.type = 'U'

AND i.index_id NOT IN

(SELECT s.index_id

FROM sys.dm_db_index_usage_stats s

WHERE s.index_id = i.index_id

AND s.object_id = i.object_id

AND s.database_id = db_id())

ORDER BY object_name(i.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.


You can use the following query to monitor the index usage on a regular basis:

SELECT

object_name(i.object_id) AS object_name,

i.name AS index_name, s.index_id,

user_seeks + user_scans + user_lookups AS user_reads,

system_seeks + system_scans + system_lookups AS

system_reads,

user_updates,

system_updates

FROM sys.dm_db_index_usage_stats s JOIN sys.indexes i

ON s.index_id = i.index_id AND s.object_id = i.object_id

WHERE s.database_id = db_id()

AND i.type 0

ORDER BY user_reads DESC

7.1.2 Optimize Customer-Specific T24 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

SUM(query_stats.total_worker_time) AS "total CPU time",

SUM(query_stats.total_worker_time)/SUM(query_stats.executio

n_count) AS "avg CPU Time",

SUM(query_stats.execution_count) AS "executes",

SUM(query_stats.total_logical_reads) AS "total logical

reads",

SUM(query_stats.total_logical_reads)/SUM(query_stats.execut

ion_count) AS "avg logical reads",

SUM(query_Stats.total_logical_writes) AS "total logical

writes",

SUM(query_Stats.total_logical_writes)/SUM(query_stats.execu

tion_count) AS "avg logical writes",

MIN(query_stats.statement_text) AS "statement text"

FROM

(SELECT QS.*,


SUBSTRING(ST.text, (QS.statement_start_offset/2) + 1,

((CASE statement_end_offset

WHEN -1 THEN DATALENGTH(ST.text)

ELSE QS.statement_end_offset END

- QS.statement_start_offset)/2) + 1) AS

statement_text

FROM sys.dm_exec_query_stats AS QS

CROSS APPLY sys.dm_exec_sql_text(QS.sql_handle) as ST) AS

query_stats

GROUP BY query_stats.query_hash

ORDER BY 1 DESC

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 of the T24 log file &COMO& to

match the jQL queries corresponding to the 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) 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:

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


key is the account number, and the rows in the table contain the key 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.RECID,t.XMLRECORD FROM F_HOLD_CONTROL t

WHERE

t.XMLRECORD.exist(N'/row/c2[.="NEW.LOAN.REPORT"]') = 1

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 the eighth value of a multi-value field

in the search condition:

SELECT t.RECID,t.XMLRECORD FROM FBNK_CARD_ISSUE t

WHERE t.XMLRECORD.exist(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.

Do not create XML indexes on T24 XMLRECORD fields. The impact on transaction

latency is too high, and the benefit in query performance is usually not significant.

3. Use scalar promotion.

A single-value field (or even a specific value of a multi-valued field) that is part of the

XMLRECORD can be promoted as computed column of the table and be used in relational

search conditions. 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.


Following are two examples of scalar promotion:

-- example 1

-- scalar promotion of single valued field

CREATE FUNCTION udf_HOLD_CONTROL_C2(@xmlrecord XML)

RETURNS nvarchar(35)

WITH SCHEMABINDING

BEGIN

RETURN @xmlrecord.value('(/row/c2/text())[1]',

'nvarchar(35)')

END

ALTER TABLE F_HOLD_CONTROL

ADD C2 AS dbo.udf_HOLD_CONTROL_C2(XMLRECORD) PERSISTED

-- example 2

-- scalar promotion of specific multi-valued field

CREATE FUNCTION udf_CARD_ISSUE_CUSTOMER(@xmlrecord XML)

RETURNS integer

WITH SCHEMABINDING

BEGIN

RETURN

@xmlrecord.value('(/row/c14[@m="8"]/text())[1]',

'integer')

END

ALTER TABLE FBNK_CARD_ISSUE

ADD C14_8 AS dbo.udf_CARD_ISSUE_CUSTOMER(XMLRECORD)

PERSISTED

2.) Create non-clustered index on the computed column.

After creating the persisted computed column, create an index for this column:

-- example 1

CREATE INDEX ix_HOLD_CONTROL_C2 ON F_HOLD_CONTROL(C2)

-- example 2

CREATE INDEX ix_CARD_ISSUE_CUSTOMER ON

FBNK_CARD_ISSUE(C14_8)

Once there is a promoted column for a specific field in the table, T24 automatically

translates the queries to use that column relational in the where clause if there is

a search condition on that field.

4. Verify optimizations.

Verify that the changes are successful 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

FROM FBNK_CARD_ISSUE t

WHERE t.XMLRECORD.exist(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.RECID,t.XMLRECORD

FROM FBNK_CARD_ISSUE t

WHERE 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. Consider the ratio between index reads

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 Standard T24 Queries for this purpose.

You should monitor the index usage statistics on a regular 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 of the

document for this purpose.

5. Use T24 logical optimization.

If you are not able to achieve sufficient performance improvement to specific queries or

COB jobs by applying steps 14 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.

7.2 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 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 introduces application and multi-server management, which can

help you manage 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 SQL Server 2008 R2 - Application and Multi-Server Management.

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.


8 Best Practices for System Maintenance

You should perform regular maintenance tasks to keep SQL 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 Appendix 1: Create a Maintenance

Plan to Back Up the Temenos Application Database and Appendix 2: Create a Maintenance Plan

to Back Up the System Databases.

8.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 log file from growing

too large.

8.1.1 Use Backup Compression

Backing up a large database can require a significant amount of time and a large amount of disk

space for the backup file(s). With SQL Server 2008 backup compression, the backup file is

compressed as it is written; 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 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.) The RESTORE command

automatically detects that a backup is compressed and decompresses the backup during the

restore operation.

For more information, see the article Tuning the Performance of Backup Compression in SQL

Server 2008 on SQLCAT.com.

8.1.2 Implement a Backup Schedule

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.


It is recommended to schedule the full backup to run after the COB processing 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.

8.1.3 Back Up System Databases

SQL Server maintains a set of system-level databases (called system databases) that are

essential for the operation of a server instance. 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 Considerations for Backing Up and Restoring System

Databases.

8.2 Recommendations for Updating Statistics SQL Server collects statistics about individual columns (single-column 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 Statistics Used by the Query Optimizer in Microsoft SQL

Server 2008. For step-by-step guidance for manually updating statistics using a maintenance job,

see Appendix 3: Update Statistics.

8.3 Recommendations for Reorganizing 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 the logical ordering, based on the key value, does not

match the physical ordering inside the data file. Heavily fragmented 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 or reorganize a complete index or a single partition of an

index.


To decide which defragmentation method to use, analyze the index to determine the degree of

fragmentation. By using the 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 to the

fragmentation levels available in defined columns at any given time.

Table 6 shows some of the information returned by the sys.dm_db_index_physical_stats

function.

Column Description

avg_fragmentation_in_percent The percent of logical fragmentation (out-of-order pages

in the index).

fragment_count 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 6. 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 7. Corrective defragmentation method to use.

Note that very low levels of fragmentation (less than 10%) should not be addressed by either of

these commands because the benefit from removing such a small amount of fragmentation is

almost always vastly outweighed by the cost of reorganizing or rebuilding the index. The white

paper Microsoft SQL Server 2000 Index Defragmentation Best Practices can provide additional

guidance.

8.3.1 Reorganize Indexes

Reorganize an index when the index is not heavily fragmented. Use the ALTER INDEX statement

with the REORGANIZE clause (replaces the DBCC INDEXDEFRAG statement in Microsoft SQL

Server 2000). To reorganize a single partition of a partitioned index, use the PARTITION clause

of ALTER INDEX.


The reorganize process uses minimal system resources. Also, reorganizing is automatically

performed online. The process does not hold long-term blocking locks; therefore, it does not

block running queries or updates.

8.3.2 Rebuild Indexes when Necessary

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 fill-

factor 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 and Rebuilding 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 provides step-by-step guidance on creating

maintenance plans for these operations.

8.4 Recommendations for Update Management Following is guidance for updating management.

8.4.1 Maintain Your Microsoft Software

It is recommended 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 the

computers work. Consider testing and applying software updates on a regular basis.

For more information on applying updates, see Update Management TechCenter and SQL

Server 2008 failover cluster rolling patch and service pack process.


9 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 the database tier. The links in the section that

follows provide even more information.

For benchmarking results from a SQL Server/TEMENOS T24 implementation at the North Shore

Credit Union in British Columbia, Canada, see:

TEMENOS T24 Core Banking Optimized on Microsoft SQL Server Database Platform.

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:

High Availability with SQL Server 2008

Failover Clustering in Windows Server 2008 R2

SQL Server 2008 Failover Clustering

Database Mirroring Overview

Synchronous Database Mirroring (High-Safety Mode)

Database Mirroring Best Practices and Performance Considerations


Log Shipping Overview

Transactional Replication Overview

Best Practices for Replication Administration

Replication Security Best Practices

Peer-to-Peer Transactional Replication

Database Maintenance

Considerations for Backing Up and Restoring System Databases

Tuning the Performance of Backup Compression in SQL Server 2008

Best Practices for Recovering a Database to a Specific Recovery Point

Statistics Used by the Query Optimizer in Microsoft SQL Server 2008

Reorganizing and Rebuilding Indexes

SQL Server 2008 R2 - Application and Multi-Server Management

SQL Server 2008 failover cluster rolling patch and service pack process

Update Management TechCenter

Troubleshooting Performance Problems in SQL Server 2008

See the SQL Server Best Practices portal for technical white papers, the SQL Server Best

Practices Toolbox, Top 10 Lists, and other resources.


10 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.


4. On the Select Maintenance Tasks dialog box, select Clean Up History, Back Up

Database (Full), Back Up Database (Transaction Log), and Maintenance Cleanup Task.

Click Next twice.

Figure 4. Select maintenance tasks.

5. As you complete the Maintenance Plan Wizard, 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 cleanup task.


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.


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.


e. On the Job Schedule Properties dialog box, select the frequency and duration of

transaction log backups. Click OK.

Figure 9. Options to set the frequency and duration of transaction log backups.

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.


g. On the Define Maintenance Cleanup Task dialog

Best Practices for Running

Documents

Transcript of Best Practices for Running