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.
This document is provided as-is. Information and views expressed in this document, including URL and
other Internet Web site references, may change without notice. You bear the risk of using it.
This document does not provide you with any legal rights to any intellectual property in any Microsoft
product. You may copy and use this document for your internal, reference purposes.
Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
Table of Contents
OVERVIEW ............................................................................................................................................... 5
1
Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
2.2.2
2.2.3
SUMMARY ..................................................................................................................................... 43
10
11
12
13
Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
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 advanced and scalable architecture.
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).
Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
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 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
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.
Optimized partition offsets when disks are formatted, reducing complexity in I/O
system configuration.
Its also recommended to install all the proposed operating system updates related to security
available via Windows Update released from Microsoft immediately after the operating system
installation and before installing SQL Server and T24.
Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
LUN 1
LUN 2
LUN 4
Bus 1
10
13
46
Bus 2
11
14
47
Bus 3
12
15
48
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 welltuned I/O subsystem are:
< 5 milliseconds (ms) for log (ideally 1 ms on arrays with cache)
< 20 ms for data on OLTP systems (ideally 10 ms or less)
1.3.3 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 64kilobyte (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.
Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
data
1324
data
2536
tempdb
3748
log
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.
10
Performance 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
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
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.5 Use Multiple HBAs and Set the HBA Queue Depth
You should use at least two host bus adapters (HBAs) to provide redundancy and to increase
bandwidth between the SAN and SQL Server. 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, 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.
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 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.
Never use increments in percentage, always use fixed size autogrowth size;
Reasonable increment sizes for transaction log are 1GB, 2GB, 4GB, 8GB, 16GB and final
choice should be based on the relative size of the planned initial size of the transaction
log and reflects how big the environment will be in terms of number of accounts;
SQL Server 2008 R2 and later provide tools (SQL Trace and Dashboard reports) of how
much time the autogrowth operations on transaction log will take, if the observed
duration will be consistently higher than 1 second, its recommended to:
o
Raise the initial size of the transaction log to reduce occurrences of autogrowth
expansions;
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)
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, its recommended to avoid 4GB (or multiples) increment.
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.
For more information about T1118 trace flag, see the article Concurrency Enhancements for the
tempdb 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
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.
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 version in the provided link above.
For further information, see the MSDN article Optimizing tempdb Performance.
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
> 4 CPU = 256 + ((#CPU - 4) *8)
64bit CPU
<= 4 CPU = 512
> 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 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
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
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
New SQLOS features in SQL Server 2012
http://blogs.msdn.com/b/sqlosteam/archive/2011/11/10/new-sqlos-features-in-sqlserver-2012.aspx
Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
16
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 making 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 (SE_MANAGE_VOLUME_NAME)
user right at the OS level on the server and all cluster 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
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
Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
17
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
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 Fill Factor.
Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
19
Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
20
For modification of default value (0) for parameter Target Recovery Time (Seconds),
see section 2.7.2 Increase the SQL Server Recovery Interval.
Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
21
Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
22
5000
12000
>= 64 GB
15000
Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
23
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.)
In a cluster configuration with jDLS installed on the database server, you can configure 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 High Availability
Always On Technologies and High Availability with SQL Server 2008 R2.
25
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
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
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.
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 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.
Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
28
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.
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 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 the subscription from the primary
backup. Another possible alternative, both for SQL Server 2008 R2 and SQL Server 2012, is
Transactional Replication but its not recommended since:
Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
29
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 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
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.*,
Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
31
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:
Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
32
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.
Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
33
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.
Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
34
4. Verify optimizations.
Verify that the changes are successful and measure the impact of the optimizations.
Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
35
Predicts
Additional processors.
Paging in Pages/sec
36
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 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.
38
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
fragment_count
avg_fragment_size_in_pages
page_count
You can then use Table 7 as a guide to determine the best method to correct the fragmentation.
avg_fragmentation_in_percent
Corrective statement
> 80 percent
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.
7.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.
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, it does not
block running queries or updates.
Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
40
41
implement their own update services, defining a specific strategy and installing the updates on a
test server to verify their impact before installing them in production. For more information, see
Windows Server Update Services.
Security patching is an important subset of updates. You can find information about security
patching in Ten Principals of Microsoft Patch Management. Also see the Microsoft Support
article Guidelines for choosing antivirus software to run on the computers that are running SQL
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 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 Intel Xeon processor-based servers set a new
world record in the latest high-water benchmarking tests
Following is a list of technical articles that can help you learn more about specific Windows and
SQL Server topics:
Windows Configuration:
Storage Configuration:
Receive-Side Scaling
Introduction to Receive-Side Scaling
Receive-Side Scaling Enhancements in Windows Server 2008
Desktop Heap Overview
Desktop Heap, part 2
Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
43
Database Maintenance
See the SQL Server Best Practices portal for technical white papers, the SQL Server Best
Practices Toolbox, Top 10 Lists, and other resources.
Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
44
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.
3. Click Separate schedules for each task, because you will later select both full and
transaction log backups. Click Next.
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 Log), and Maintenance Cleanup Task.
Click Next twice.
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.
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.
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.
d. On the Define Back Up Database (Full) Task dialog box, specify information
about the full backup. Click Next.
48
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.
49
g. On the Define Maintenance Cleanup Task dialog box, configure the cleanup
tasks. Click Next.
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
3. On the Select Plan Properties dialog box, click Single schedule for the entire plan or no
schedule, and click Change to select the frequency and duration of transaction log
backups. Click Next.
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.
5. On the Select Maintenance Task Order dialog box, make sure that the tasks appear in
the order shown in Figure 15. Click Next.
Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
52
6. 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 Back Up Database (Full) Task dialog box, select System
databases. Click OK.
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.
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.
d. Define the history cleanup task by selecting from the various options. Click Next.
Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
55
Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
56
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 and duration of statistics updates.
Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
57
4. Based on your organizations needs, select the frequency and duration of the statistics
updates on the Job Schedule Properties Update Temenos Statistics (FullScan) dialog
box. Click OK, and then click Next.
5. On the Select Maintenance Tasks dialog box, select only Update Statistics. Click Next.
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.
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.
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.
9. On the Select Report Options dialog box, select report options based on your
organizations needs. Click Next.
Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
60
61
62
DECLARE
DECLARE
DECLARE
DECLARE
DECLARE
DECLARE
DECLARE
@schemaname nvarchar(130);
@objectname nvarchar(130);
@indexname nvarchar(130);
@partitionnum bigint;
@partitions bigint;
@frag float;
@command nvarchar(4000);
Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
63
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.
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.
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.
Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
66
6. On the Job Properties Temenos Index Reorg/Rebuild dialog box, configure the
notifications for the job based on your organizations needs. (Note that database email
must be configured correctly for the notifications to work.) Click OK.
Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
67
Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
68