Documente Academic
Documente Profesional
Documente Cultură
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.
This document is provided as-is. Information and views expressed in this document, including UR L 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
1 2 OVERVIEW ....................................................................................................................................... 5 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
Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
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 5.2 5.3 5.4 6 7 SAN MIRRORING ............................................................................................................................. 21 SYNCHRONOUS DATABASE MIRRORING ................................................................................................ 21 ASYNCHRONOUS REPLICATION METHODS ............................................................................................. 22 RECOMMENDATIONS FOR CONNECTION BANDWIDTH ............................................................................. 22
BEST PRACTICES FOR REPORTING .................................................................................................. 23 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
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 10 11 12 13 14
SUMMARY ..................................................................................................................................... 35 APPENDIX 1: CREATE A MAINTENANCE PLAN TO BACK UP THE TEMENOS DATABASE ................... 37 APPENDIX 2: CREATE A MAINTENANCE PLAN TO BACK UP THE SYSTEM DATABASES .................... 43 APPENDIX 3: UPDATE STATISTICS .................................................................................................. 49 APPENDIX 4: REORGANIZE AND REBUILD INDEXES ........................................................................ 53 APPENDIX 5: INSTALLATION CHECK LIST ........................................................................................ 60
Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
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).
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 your TEMENOS T24 implementation and can also help you avoid or minimize common problems.
Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
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.
Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
IOPS avg IOPS peak I/O System Data IOPS avg Log IOPS avg Data IOPS peak Log IOPS peak
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.
Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
LUN 2 13 14 15
LUN 4 46 47 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)
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 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
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.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.
Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
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.
Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
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
Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
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 < 8 GB >= 8 GB and < 32 GB >= 32 GB and < 64 GB >= 64 GB Handle Cache Parameter 500 (default) 5000 12000 15000
Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows 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.
Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
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
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
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 = <value>, 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
Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
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.
Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
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):
Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
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
Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
application-specific purposes in the application layer. In some cases, concat files can also be used as a logical index in T24.
Predicts Need for expansion of files or storage. Need to backup transaction log more often. Additional processors. Storage configuration too slow. May indicate a large amount of disk fragmentation, slow disks, or disk failures. (Should be 10 ms or less.) Need to spread data across more LUNs. Need for additional memory. Need for increased network capacity or segmentation.
Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
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.
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 avg_fragmentation_in_percent fragment_count avg_fragment_size_in_pages page_count Description The percent of logical fragmentation (out-of-order pages in the index). The number of fragments (physically consecutive leaf pages) in the index. Average number of pages in one fragment in an index. The total number of index or data pages.
You can then use Table 7 as a guide to determine the best method to correct the fragmentation. avg_fragmentation_in_percent > 10 percent and < = 80 percent > 80 percent Corrective statement ALTER INDEX REORGANIZE ALTER INDEX REBUILD
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.
Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
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.
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.
Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
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
Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
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.
Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
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
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
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
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.
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.
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
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
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
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
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
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
Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
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
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
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
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
DECLARE partitions CURSOR FOR SELECT * FROM #work_to_do; -- Open the cursor. OPEN partitions; -- Loop through the partitions. WHILE (1=1) BEGIN; FETCH NEXT FROM partitions INTO @objectid, @indexid, @partitionnum, @frag; IF @@FETCH_STATUS < 0 BREAK; SELECT @objectname = QUOTENAME(o.name), @schemaname = QUOTENAME(s.name) FROM sys.objects AS o JOIN sys.schemas as s ON s.schema_id = o.schema_id WHERE o.object_id = @objectid; SELECT @indexname = QUOTENAME(name) FROM sys.indexes WHERE object_id = @objectid AND index_id = @indexid; SELECT @partitioncount = count (*) FROM sys.partitions WHERE object_id = @objectid AND index_id = @indexid; SET @command = N'ALTER INDEX ' + @indexname + N' ON ' + @schemaname + N'.' + @objectname + N' REORGANIZE'; IF @partitioncount > 1 SET @command = @command + N' PARTITION=' + CAST(@partitionnum AS nvarchar(10)); EXEC (@command); PRINT N'Executed: ' + @command; END; -- Close and deallocate the cursor. CLOSE partitions; DEALLOCATE partitions; -- Drop the temporary table. DROP TABLE #work_to_do; GO -- rebuild indexes -- Ensure that a USE <databasename> statement has been executed first. SET NOCOUNT ON; DECLARE @objectid int; DECLARE @indexid int; DECLARE @partitioncount bigint;
Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
@schemaname nvarchar(130); @objectname nvarchar(130); @indexname nvarchar(130); @partitionnum bigint; @partitions bigint; @frag float; @command nvarchar(4000);
-- Conditionally select tables and indexes from the sys.dm_db_index_physical_stats function -- and convert object and index IDs to names. SELECT object_id AS objectid, index_id AS indexid, partition_number AS partitionnum, avg_fragmentation_in_percent AS frag INTO #work_to_do FROM sys.dm_db_index_physical_stats (DB_ID(), NULL, NULL , NULL, 'LIMITED') WHERE avg_fragmentation_in_percent > 80.0 AND index_id > 0; -- Declare the cursor for the list of partitions to be processed. DECLARE partitions CURSOR FOR SELECT * FROM #work_to_do; -- Open the cursor. OPEN partitions; -- Loop through the partitions. WHILE (1=1) BEGIN; FETCH NEXT FROM partitions INTO @objectid, @indexid, @partitionnum, @frag; IF @@FETCH_STATUS < 0 BREAK; SELECT @objectname = QUOTENAME(o.name), @schemaname = QUOTENAME(s.name) FROM sys.objects AS o JOIN sys.schemas as s ON s.schema_id = o.schema_id WHERE o.object_id = @objectid; SELECT @indexname = QUOTENAME(name) FROM sys.indexes WHERE object_id = @objectid AND index_id = @indexid; SELECT @partitioncount = count (*) FROM sys.partitions WHERE object_id = @objectid AND index_id = @indexid; SET @command = N'ALTER INDEX ' + @indexname + N' ON ' + @schemaname + N'.' + @objectname + N' REBUILD'; IF @partitioncount > 1
Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
SET @command = @command + N' PARTITION=' + CAST(@partitionnum AS nvarchar(10)); EXEC (@command); PRINT N'Executed: ' + @command; END; -- Close and deallocate the cursor. CLOSE partitions; DEALLOCATE partitions; -- Drop the temporary table. DROP TABLE #work_to_do; GO You should generally create a nightly job for index reorganization (using the 1 sample script) and a weekly job for index rebuild (based on the 2 sample script). Ideally, the index maintenance tasks (reorganization or rebuild) should be performed after COB processing and before a full backup is executed. To create a nightly or weekly job to perform the reorganizing or rebuilding, perform the following steps: 1. Right-click Jobs, and click New Job.
Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
2. Name the job so it can be easily identified as the reorganization or rebuilding index.
3. Click Steps, and then click New. Enter the step name (e.g., Reorg or Rebuild), select the type Transact-SQL script (T-SQL), specify the T24 database name, and copy the script sample into the Command field. To make sure that there are no errors in the T-SQL script, click Parse. Click OK.
Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server
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
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
Best Practice Guidance for Running TEMENOS T24 on Microsoft SQL Server and Windows Server