You are on page 1of 36

Enterprise Best Practices for Running the Kronos Workforce Central Suite on SQL Server

Maximize value and operational efficiency throughout your workforce management software
Microsoft Corporation Published: June 2010

Abstract
The Kronos Workforce Central suite provides the end-to-end solution to help your company executives, supervisors, and employees excel in all areas of workforce management. Workforce Central automates your labor-intensive administrative processes, freeing your workforce to focus on productivity and quality. Microsoft SQL Server database software provides an ideal database platform for Workforce Central. With SQL Server as a foundation, Kronos Workforce Central software can further decrease the time and costs related to managing worker information. This white paper provides best practices for configuring and running Workforce Central on the SQL Server database platform. This paper complements the detailed support documentation provided on the Kronos support Web site. Note: The intended audience for this paper is the enterprise customer with greater than 7,500 employees. However, smaller customers may find information in this document useful also. Implementing these best practices can help you avoid or minimize common problems and optimize the performance of Workforce Central on SQL Server. In turn, this allows you to effectively manage your workers, reduce operating expenses, increase productivity, and improve employee satisfaction.

Copyright Information
The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication. This white paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED, OR STATUTORY, AS TO THE INFORMATION IN THIS DOCUMENT. Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in, or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation. Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property. 2010 Microsoft Corporation. All rights reserved. Microsoft, SQL Server, Hyper-V, MSDN, Windows Server, and Windows are trademarks of the Microsoft group of companies. All other trademarks are property of their respective owners. 2010, Kronos Incorporated. Kronos, the Kronos logo, Workforce Central and Workforce Accruals are registered trademarks, and Workforce Analytics, Workforce Attendance, Workforce HR, Workforce Forecast Manager, Workforce Leave, Workforce Payroll, Workforce Scheduler, Workforce Central Portal, and Workforce Timekeeper are trademarks of Kronos Incorporated or a related company. All other product and company names are used for identification purposes only and may be the trademarks of their respective owners. All specifications are subject to change. All rights reserved.

Table of Contents
OVERVIEW ............................................................................................................................................... 5 KRONOS WORKFORCE CENTRAL: THE SOLUTION FOR WORKFORCE MANAGEMENT...................................................... 6 SQL SERVER: AN ENTERPRISE-READY DATABASE PLATFORM FOR WORKFORCE CENTRAL .............................................. 6 BETTER TOGETHER: WORKFORCE CENTRAL ON THE SQL SERVER DATABASE PLATFORM ............................................... 7 THE WORKFORCE CENTRAL ARCHITECTURE ............................................................................................. 8 CLIENT SOFTWARE TIER .................................................................................................................................... 8 WORKFORCE CENTRAL PLATFORM AND APPLICATIONS ........................................................................................... 8 DATABASE TIER .............................................................................................................................................. 9 BEST PRACTICES FOR RUNNING WORKFORCE CENTRAL ON SQL SERVER ............................................... 10 SELECT, SIZE, AND CONFIGURE SQL SERVER FOR OPTIMAL PERFORMANCE .............................................................. 10 You should be sure to select, size, and configure SQL Server carefully to optimize performance........ 10 Select the Appropriate Hardware ........................................................................................................ 10 Select the Appropriate SQL Server Edition ........................................................................................... 11 Separate the Database and the Application ........................................................................................ 11 Add Dedicated Report Servers for Large Environments ....................................................................... 11 Configure Your I/O Subsystem ............................................................................................................. 12 Set the HBA Queue Depth .................................................................................................................... 12 Use the Appropriate Amount of RAM .................................................................................................. 12 Configure the tempdb Database .......................................................................................................... 13 Configure Transaction Logs ................................................................................................................. 15 Distribute Files Across Disks ................................................................................................................. 15 Pre-Allocate Space for Existing Filegroups ........................................................................................... 16 Create Filegroups ................................................................................................................................. 16 VALIDATE YOUR CONFIGURATION BEFORE DEPLOYMENT ...................................................................................... 16 Validate the SQL Server Installation .................................................................................................... 16 Run an I/O Stress Tool .......................................................................................................................... 17 Check the Network ............................................................................................................................... 18 ADJUST SQL SERVER AND DATABASE SETTINGS .................................................................................................. 19 Set the Maximum Degree of Parallelism ............................................................................................. 19 Set the Index Fill Factor ........................................................................................................................ 20 Disable the Auto Update Statistics Setting .......................................................................................... 21 Disable the Auto Shrink Setting ........................................................................................................... 22 PERFORM REGULAR MAINTENANCE TASKS......................................................................................................... 22 Update Statistics .................................................................................................................................. 23 Reorganize or Rebuild Indexes as Necessary ....................................................................................... 23 MONITOR PERFORMANCE............................................................................................................................... 25 Establish a Performance Baseline ........................................................................................................ 25 Run Kronos Reconcile Reports.............................................................................................................. 26

Review Maintenance Jobs .................................................................................................................... 27 Use Task Manager ............................................................................................................................... 27 Use Windows Performance Monitor .................................................................................................... 27 Use Dynamic Management Views ....................................................................................................... 28 Monitor Disk I/O Subsystem ................................................................................................................ 29 PERIODICALLY CHECK DATABASE INTEGRITY........................................................................................................ 29 PERFORM REGULAR DATABASE BACKUPS........................................................................................................... 30 ADDITIONAL FEATURES WITH SQL SERVER 2008 ENTERPRISE EDITION.................................................................... 32 Backup Compression ............................................................................................................................ 32 Transparent Data Encryption ............................................................................................................... 32 TUNE KRONOS WORKFORCE CENTRAL .............................................................................................................. 33 Adjust Max Database Connections Setting if Necessary ...................................................................... 33 SUMMARY ............................................................................................................................................. 34 LINKS FOR FURTHER INFORMATION ...................................................................................................... 35

Overview
Workforce management requires employers to address a multitude of challenges, including: Implementing cost reduction measures. Improving hiring practices. Reducing employee absenteeism and turnover. Aligning labor resources with current demand. Forecasting future demand. Businesses often find it difficult to provide the IT resources needed to address these challenges and manage the workforce effectively. And without effective employee management, overhead costs increase and efficiency decreases. This can force a company to miss opportunities and lose productivity. Kronos Workforce Central is one of the most widely deployed solutions used for workforce management in nearly every industry. Using Microsoft SQL Server database software to power Workforce Central lets you take full advantage of the capabilities of Workforce Central. By combining the reliable and scalable database infrastructure of SQL Server with Kronos workforce management technology, you get the functionality and the high-quality information you need to manage your employees. You can control labor costs, minimize compliance risk, improve workforce productivity, and lower the total cost of ownershipall without straining valuable IT resources. The performance of Workforce Central, and therefore of the SQL Server database platform, is critical to employers. The value of business information is time sensitive, so if the workforce management software is running inefficiently, it negatively affects operations and the enterprises bottom line. This white paper, intended for database administrators (DBAs), presents the best practices Kronos recommends for configuring and running Workforce Central on the SQL Server database platform. The information in this paper can help DBAs optimize the performance of Workforce Central and proactively prevent or minimize potential problems. This paper is targeted at enterprise customers with 7,500 or more employees, though smaller companies may also find this guidance useful. Note that Workforce Central supports both Microsoft SQL Server 2005 and SQL Server 2008 database software; unless there is a specific difference, this document uses SQL Server to refer to all versions.

Kronos Workforce Central: The Solution for Workforce Management


The Kronos Workforce Central suite provides an end-to-end, integrated solution that gives company executives, supervisors, and employees the ability to see and control all aspects of workforce management. Workforce Central can automate and simplify essential business and administrative processes, eliminating error-prone, labor-intensive manual processes. This improves workforce productivity and quality and makes it possible for you to make better decisions that save time and money. Workforce Central consists of best-in-class software applications that are fully configurable and easy to implement, scale, and maintain. These applications include: Workforce Timekeeper. Provides basic timekeeping and scheduling capabilities to support attendance monitoring, tracking, and pay distribution. Workforce Scheduler. Optimizes staff deployment, automates numerous tasks, and provides advanced features to align labor resources with demand. Workforce Forecast Manager. Generates accurate, cost-effective schedules. It accounts for fluctuations in workforce demand by using historical data and current business drivers to predict future demand. Additional applications such as Workforce Attendance, Workforce Accruals, and Workforce Leave provide real-time visibility into all aspects of the labor tracking and reporting process. Workforce Central Portal and Workforce Analytics let you focus, aggregate, and analyze your relevant labor data. Workforce HR delivers automated processes to reduce the frustration and time associated with managing your employee information. Together, the Workforce Central applications provide a complete solution for workforce management.

SQL Server: An Enterprise-Ready Database Platform for Workforce Central


Microsoft SQL Server provides an ideal database platform for Workforce Central. SQL Server is a high-performance, integrated database and business intelligence solution for data management and analysis. This easy-to-implement, easy-to-support foundation provides: A multifunctional solution for large-scale online transaction processing (OLTP), data warehousing, and e-commerce applications. A comprehensive solution for data integration, analysis, and reporting. SQL Server can help companies manage large volumes of mission-critical data and run software applicationssuch as Kronos Workforce Centralto optimize their business performance. SQL Server can extract and transform data from a variety of sources, including XML data files, flat files, and relational data sources, and then load the data into one or more destinations. In 6

addition to rapid data mining, analysis, processing, and reporting capabilities, SQL Server has built-in features that give you a secure, reliable, and productive data management environment. With its scalable infrastructure, SQL Server has the capability to grow with your business and keep up with your toughest data challenges.

Better Together: Workforce Central on the SQL Server Database Platform


Running Kronos Workforce Central on SQL Server delivers measureable value by channeling workforce data into manageable, automated processes. This decreases administrative time, improves productivity, reduces costs, and generates greater employee satisfaction. Benchmarking tests confirm that SQL Server scales to meet the performance needs of even the largest enterprise customers, while providing lower initial costs and licensing fees.1 In 2010, Kronos plans enhancements to Workforce Central that will further optimize the performance of Workforce Central on SQL Server, including 64-bit support for the application layer and support for Microsoft SQL Server 2008 R2 and Microsoft Hyper-V Server 2008 R2, letting customers virtualize their Workforce Central deployments.

Workforce Central and SQL Server Reach New Heights in Scalability and TCO, http://www.kronos.com/ms/benchmark2

The Workforce Central Architecture


Best practices for Workforce Central on the SQL Server database platform start with configuration of the system. It is helpful to review and to have a thorough understanding of the Workforce Central architecture. The Workforce Central suite is a Java 2 Enterprise Edition (J2EE)-compatible set of applications that uses a three-tier structure: the client software tier, the Workforce Central platform and applications, and the database tier. (See Figure 1.)

Figure 1. Kronos architecture.

Client Software Tier


The client layer contains browsers, operating systems, a Java Runtime Environment (JRE), and other supporting technologies (such as Adobe Acrobat Reader). Client computers access a Workforce Central application through a Web Uniform Resource Locator (URL) using a browser. The application functions are then implemented as HTML pages or Java applets. The applets are downloaded via .jar files and use a sticky cache, which means that applets are only downloaded the first time that the client accesses them. Several Workforce Central applications, such as Process Designer, Interface Designer, and Workforce Worksheet, are installed on the client and operate at the client level.

Workforce Central Platform and Applications


This tier provides the business logic and connections to the back-end database; it contains the common infrastructure, applications, application server, and Web server: Base platform. Consists of data, code, business logic, graphical user interfaces (GUIs), and application programming interfaces (APIs).

Modular set of applications and components. Use various extensibility mechanisms. The applications and components are installed separately as needed and are licensed separately. Loosely coupled integration technologies. Connect the pieces of the applications and components with each other and with thirdparty applications.

Database Tier
The database tierthe focus of the best practices presented in this documentstores all of the application data. Note that the two main applications used by most Kronos customers, Workforce HR, Workforce Payroll, and Workforce Timekeeper, can share a database; the schemas can exist side by side in the database. Because Workforce HR and Workforce Payroll only support SQL Server, you must use SQL Server, and not an alternative database, for combined installations.

Best Practices for Running Workforce Central on SQL Server


Best system performance is defined as the most efficient use of computing resources to produce the best user experience. Because many factors can contribute to poor system performance, you should aim to implement best practices in planning and operating your workforce management system. The Workforce Central suite application database also needs periodic maintenance and tuning; without such maintenance, database operations can become considerably slower over time. Implementing best practices help ensure that your SQL Server database is: Installed and configured so that it is accessible over the network. Available when users need it. Tuned for optimal performance, which makes it possible for users to receive the data that they request in a reasonable period of time. Accurate with no database corruption or system errors. Returned to normal as quickly as possible after a failure. Best practices for Workforce Central on a SQL Server database platform are relevant to hardware and software. Practices apply to sizing, setting up, and validating SQL Server; maintaining the database; monitoring performance; and backing up the database. The guidance provided below can get you started. For more detailed information, see the Links for Further Information section of this white paper; both Microsoft and Kronos provide a great deal of valuable guidance for keeping your workforce management system running smoothly. Note that trouble-free performance is impossible to guarantee. If you find that you do need to make a service call, ensure that you have first run through the recommended monitoring guidance in the sections that follow; this guidance provides you with valuable information that can be used to get your system back up and running quickly.

Select, Size, and Configure SQL Server for Optimal Performance


Are you using the appropriate SQL Server edition? Have you configured and sized your system for future growth? You should be sure to select, size, and configure SQL Server carefully to optimize performance.

Select the Appropriate Hardware


Kronos recommends that you carefully plan and configure your hardware to provide adequate resources for optimal performance and to allow for growth. Prior to deployment, a Kronos solutions architect will supply you with a Hardware Requirements Report to ensure adequate hardware is available. 10

Select the Appropriate SQL Server Edition


Workforce Central can run on either the Standard or Enterprise editions of SQL Server 2005 or SQL Server 2008. Ensure that you apply the latest service pack, which you can download from the SQL Server Developer Center. It is important to select the edition that is right for your workload. In general, the Enterprise editions are suited for large, mission-critical deployments that require high availability and uptime, while the Standard editions are suited for smaller, departmental deployments. For the highest levels of scalability, SQL Server 2008 R2 introduces the Datacenter edition. For more information, see SQL Server 2008 R2 Editions, SQL Server 2008 Editions, or SQL Server 2005 Feature Comparison. For advice on deciding among available editions, see SQL Server Books Online in Editions and Components of SQL Server 2008 and Editions and Components of SQL Server 2005.

Separate the Database and the Application


Kronos recommends that you install the SQL Server database on a separate physical server from the Workforce Central application server for best performance. Kronos provides installation guidance through the customer support portal: see Installing Workforce Timekeeper and Installing Workforce HR/Payroll. For instructions for installing SQL Server, see Installing SQL Server 2005 and How to Install SQL Server 2008 (Setup).

Add Dedicated Report Servers for Large Environments


Kronos recommends that you use dedicated report servers in large environments. The reporting functionality of Workforce Central is based on the report definition language (RDL), which is an XML schema from Microsoft for representing reports. Workforce Central supports two types of RDL reports: Standard reporting. Uses RDL report templates and the Reports Definition Language Client (RDLC) engine. Advanced reporting. Uses RDL-compliant report templates and the Microsoft SQL Server Reporting Services (SSRS) engine. It also requires an Internet Information Services (IIS) Web server. In large environments (greater than 20,000 employees), or if you use the advanced reporting functionality of Workforce Central, you can set up dedicated SSRS servers that provide the reporting engine for all application servers in your environment. Dedicated report servers use two report engines per system processor (a general purpose application server uses one report engine per system processor). Dedicated report servers can provide faster report execution without degrading the performance of transaction execution. For optimal performance, you should limit the number of employees per report to 1,000 and schedule reports during non-peak hours whenever possible.

11

Note: Use the Kronos sizing tool to determine the actual number of dedicated report servers that you need. The sizing tool should be available from your Kronos technical consultant.

Configure Your I/O Subsystem


Kronos recommends that you use an adequate number of disks to support your I/O requirements with an acceptable latency and use filegroups for administration requirements such as backup/restore. When configuring your I/O subsystem, you may opt to use redundant array of inexpensive disks (RAID), a technology which combines two or more physical hard disk drives into a single logical unit. Although many RAID implementations are available, Kronos recommends using hardwarelevel RAID storage or storage area network (SAN) disk storage with production-quality hard disk drives. Use one or more hardware RAID controllers with seven or more hard disk drives for database storage. Use a logical drive created as a RAID partition with the available drives for all filegroups. For SQL Server data and logs, Microsoft recommends using RAID 10; it offers better availability than RAID 5 and better support for write-heavy environments such as Workforce Central. This makes RAID 10 a good choice for tempdb too. Note that log files should be located on logical unit numbers (LUNs) that are separate from the data LUNs. The underlying SAN configuration matters; shared and combined SAN may not be optimal.

Set the HBA Queue Depth


A host bus adapter (HBA) connects your server to the SAN. The HBA queue depth setting throttles the maximum number of I/O operations that can simultaneously flow to the SAN from the HBA port. Since Workforce Central is I/O intensive, the default values for queue depth on HBAs are usually not high enough to support optimal performance. When queue depth is set too low, a common symptom is increasing latency and less-than-expected throughput given the bandwidth between host/storage and the number of disks in a particular configuration. The default value for the major HBA vendors is generally in the range of 8 to 32. Kronos recommends that you increase the HBA queue depth to 64 to increase I/O performance.

Use the Appropriate Amount of RAM


SQL Server memory usage is dynamic in nature, and it is typical for SQL Server to use most of the available physical memory of the server since a larger memory space for SQL Server generally reduces I/O. The default memory management behavior of SQL Server is to acquire as much memory as it needs without creating a memory shortage on the system. A SQL Server instance continues to acquire physical memory until it reaches its max server memory setting or until the Windows operating system indicates that there is no longer an excess of free memory. The 12

instance frees memory when it has more than the min server memory setting, and the Windows operating system indicates that there is a shortage of free memory. You can adjust the max server memory and min server memory settings using the GUI or with sp_configure. For large systems (greater than 32 gigabytes [GB]), Kronos recommends that you cap the amount of memory available to SQL Server at 90 percent to ensure that there is plenty of memory available for the operating system and applications. SQL Server requires a minimum of 512 megabytes (MB) of RAM in the server; ideally, use at least 1.5 GB of RAM in the server, with 1 GB of RAM for SQL Server and 512 MB of RAM for the Windows operating system. If SQL Server uses all of the memory in the server and Windows does not have enough memory to function, SQL Server runs as if it is short on memory. This condition causes increases in query response time, CPU usage, and disk I/O as Windows begins paging more and more RAM to the hard disk drive. (Note that you should also select the correct version of the Windows operating system for your computer memory requirements.) In 64-bit platforms, all memory is available to the applications if they are compiled as 64-bit applications. In 32-bit platforms, you can configure SQL Server to use more than 2 GB of RAM by enabling the Address Windowing Extensions (AWE) memory setting, either on the same memory screen or via the sp_configure procedure by adjusting the AWE enabled setting. Both of these are advanced settings that you cannot see without enabling the show advanced options setting. Note that you must grant the Lock Pages in Memory privilege to the SQL Server account through the Windows Group Policy editor before enabling AWE; as an administrator, you can grant this privilege. 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. For more information, see Dynamic Memory Management or Managing Memory for Large Databases.

Configure the tempdb Database


The SQL Server tempdb database is used for storage of temporary data structures. Tempdb is responsible for managing temporary objects, row versioning, and online index rebuilds. Some of this processing was moved from the transaction log in Microsoft SQL Server 2000 to tempdb in SQL Server 2005 and SQL Server 2008, so configuring this database can have major performance implications. (See Figure 2.)

13

Figure 2. Configure tempdb.

It is good practice to create all tempdb files so that they are equal in size and pre-size each file. Do not rely on autogrow; instead, you should manage the growth of the files manually. (You may leave autogrow as an insurance policy, but you should proactively manage the growth of the data files.) For the best I/O performance, Kronos suggests that you create one tempdb data file per CPU core, up to approximately 10 to 16 files. (Note that creating too many files increases the cost of file switching, requires more index allocation map [IAM] pages, and increases the manageability overhead.) Also, it is best to move tempdb to a separate RAID with the fastest hard disk drives available, letting I/O transactions be split from the remainder of volumes on the SQL Server. If tempdb is located on the same hard disk drive as the operating system, the drive can run out of space. This is especially true especially if you use autogrow. Note: It may be possible to place tempdb on the same RAID group as the database files, if necessary. If you do this, you must monitor tempdb regularly.) Table 1 provides the minimum size recommendations for tempdb. Note that you may need to scale tempdb to a much larger configuration to meet your needs. For more information, see the article Optimizing tempdb Performance on Microsoft Developer Network (MSDN). Also see Capacity Planning for tempdb.

14

Table 1. Guidance for size of tempdb

ID Environment Size 1 2 3 Small Medium Large

Database Size (MB) 1,024 5,120 10,024

Transaction Log Size (MB) 256 1,024 2,048

Configure Transaction Logs


Kronos recommends that you provide adequate disk space for transaction logs and that you maintain and manage the transaction logs routinely. The transaction log file should not reside on the same disk as the data files. This allows disk I/O to be spread out over separate disks. Keep the following information in mind as you determine how much disk space to provide for transaction logs: Importing records, adding punches, calculating trial payroll, and database maintenance plan activity can all increase the size of the transaction log. Generally speaking, the more often the database changes and the less often you perform backups, the larger the transaction log needs to be. If there is not enough room for the transaction log, you receive error 1105, Can't allocate space for object '<syslog>' in database '<db name>' because the '<log segment>' segment is full. Since log space is allocated dynamically by default, the only time you normally receive this error is if you have run out of disk space. To avoid the situation of having insufficient disk space to write your transaction log, do one or both of the following actions: Perform backups more often. Increase the size of the transaction log.

Distribute Files Across Disks


Spreading data across physical disks lets you take advantage of the concurrent performance of those disks to optimize query performance. Kronos recommends that you use multiple filegroups to stripe the database across your specific I/O configuration (physical disks, LUNs) to achieve optimal I/O performance on a wide range of hardware configurations. To do this, create multiple filegroups and distribute them across separate hard disk drives or stripe sets, adding separate disks or stripe sets for logging and tempdb. (More information about log files and tempdb appears in sections Configure Transaction Logs and Configure the Tempdb Database.)

15

Use up to nine hard disk drives, as necessary, to achieve the disk I/O performance you need. Performance Monitor, a SQL Server tool for monitoring performance, indicates if there is a disk I/O bottleneck on a particular RAID array. Be ready to add hard disk drives and redistribute data across RAID arrays and/or small computer system interface (SCSI) channels, as necessary, to balance disk I/O and maximize performance.

Pre-Allocate Space for Existing Filegroups


Kronos recommends that you allow room for future data growth. To understand disk space requirements, carefully review the Hardware Requirements Report, which you can obtain from your Kronos solutions architect. Then, estimate the amount of space you will need for filegroups in the future (for example, in one year), and allocate that space during installation. This approach is better for performance than creating small files that need to autogrow in small units over time. Pre-allocating space also helps prevent disk fragmentation. (Note that existing filegroups can be expanded to accommodate future growth.)

Create Filegroups
Kronos recommends that you create the files in a contiguous space and that you size the initial file group data files to accommodate for future data growth. Be sure to defragment the hard disk you are using before you create the files. To defragment the hard disk(s), use a disk utility or the Disk Defragmenter included in the Windows Server operating system.

Validate Your Configuration Before Deployment


Have you validated your configuration and tested its capacity? Kronos recommends that you validate your system and your configuration before deploying Workforce Central. To do this, use the available tools, such as SQL Server Configuration Manager and the I/O stress tools. Note: SQL Server Configuration Manager opens from the SQL Server Management Studio and is a Microsoft Management Console (MMC) snap-in that is available from the Start menu.

Validate the SQL Server Installation


First, you should validate the successful installation of SQL Server and ensure that the services for the components you chose for your system are running. (Table 2 lists the server components).

16

Table 2. SQL Server services

Name SQL Server Database Engine (MSSQLSERVER) Analysis Services (MSSQLSERVER)

Service SQL Server Database Engine includes the core service for storing, processing, and securing data; replication; full-text search; and tools for managing relational and XML data. Analysis Services includes the tools for creating and managing online analytical processing (OLAP) and data mining applications. Note that Workforce Central uses Analysis Services for analytics only. Reporting Services includes server and client components for creating, managing, and deploying tabular, matrix, graphical, and free-form reports. Reporting Services is also an extensible platform that you can use to develop report applications. Note that Workforce Central uses Reporting Services only with advanced reporting.

Reporting Services

Use SQL Server Configuration Manager to: View and manage the services associated with your SQL Server installation. Configure the network protocols used by SQL Server. Manage the network connectivity configuration from SQL Server client computers. If a service is not running, you can start it by right-clicking the service, and then clicking Start. If the service fails to start, look at the service properties for the path to the .exe, and make sure the .exe exists in the specified path.

Run an I/O Stress Tool


Kronos recommends that you run an I/O stress tool before installing Workforce Central to help identify hardware or I/O configuration related issues. The performance of the I/O system, as described in the previous sections, affects the performance of SQL Server. An I/O stress tool can: Validate performance. Ensure that the system is tuned optimally for SQL Server. Help determine bandwidth, so that there are no bottlenecks between the server and the storage area network (SAN). Table 3 lists tools that can be used validate your configuration.

17

Table 3. Tools for testing I/O subsystems

Tool

Used to determine Performance capacity

I/O Patterns

Description
A fairly rudimentary tool that can be used to issue a particular type of I/O against one or many test files to measure I/Os per second (IOPs), throughput (MB/s), and latency. Makes it possible for you to define combinations of I/O patterns, which can be issued concurrently against one or more test files. Validate the basic functionality of an I/O subsystem under stress and attempt to simulate actual SQL Server I/O patterns and check results for correctness.

SQLIO.exe

User defined Single I/O type at a time User defined Allows combinations of I/O types Simulates SQL Server I/O patterns

IOMeter

Performance capacity

SQLIOSim

Functional correctness

Remember that the purpose of running performance capacity tests is to find any major issues and test the maximum throughput achievable by the I/O subsystem. In most cases, the tests are enough information to get a basic understanding of the systems current I/O performance. If you need more detailed information, use Windows Performance Monitor and/or SAN-specific monitoring tools. When running an I/O stress tool, use the following standard guidelines: Test a variety of I/O types and sizes. Determine the saturation point of an I/O subsystem by gradually increasing the load. Use test files that are similar to your configuration. Understand your particular hardware configuration. Validate results against the expected outcome. Ensure that test runs are long enough to be valid. Consider the potential impact of the array cache on test results. Review performance with storage administrators and hardware vendors. For more detailed information about using I/O stress tools and best practice guidance for configuring the I/O subsystem, see the SQL Server Best Practices Article. To download SQLIO, go to SQLIO Disk Subsystem Benchmark Tool on the Microsoft Download Center.

Check the Network


Kronos recommends that you check your networking carefully as you prepare your SQL Server database. Your choice of network and connecting hardware can affect the performance of your Workforce Central system. 18

Workforce Central communicates with SQL Server over a local area network (LAN). Each client computer you use must support TCP/IP as a transport protocol. Before you install Workforce Central, Kronos suggests that you carefully check the following: 1. Confirm the physical connection of each application server and client workstation to the network. 2. Verify that each application server and client workstation supports TCP/IP. To do this, create a remote login session to your host server with Telnet or use the ping command in the Run window to locate the host server by its IP address. 3. Connect to your database server using your relational database management system (RDBMS) SQL Query tools. Do this to verify that each application server and client workstation can connect to the host server, using the RDBMS client software if required. Note that for very large installations, you should separate the network user traffic from the network data traffic.

Adjust SQL Server and Database Settings


Are your database and server settings optimally set to improve performance? Kronos recommends that you edit SQL Server database settings as explained in this section. You change settings using through Microsoft SQL Server Management Studio (or Enterprise Manager in SQL Server 2000) and through SQL Server statements.

Set the Maximum Degree of Parallelism


Kronos recommends that the max degree of parallelism be set to 1 to minimize locks and reduce blocking and deadlocks. (The default value of 0 uses all available processors.) Since Workforce Central generally consists of many short, simple transactions, multiple CPUs are helpful because they can service many simultaneous threads from multiple users. You can use the max degree of parallelism option to limit the number of processors to use in parallel plan execution. The setting takes effect immediately without restarting the MSSQLSERVER service. (See Figure 3.)

19

Figure 3. Change the max degree of parallelism to 1.

If the computer has only one processor, the max degree of parallelism value is ignored.

Set the Index Fill Factor


Kronos recommends setting the default index fill factor to 75 percent to allow for space on index pages and to allow for future growth of indexes. (The server-wide default is 0, which means that the leaf-level pages are filled to capacity.) Relational databases like SQL Server use indexes to find data quickly when a query is processed. Creating and removing indexes from a database schema rarely result in changes to an applications code; indexes operate behind the scenes in support of the database engine. However, creating the proper index can drastically increase the performance of an application. When an index is created or rebuilt, each page is filled with data according to the index fill factor setting. It is important to set this value correctly or you will get database fragmentation more frequently. With a high fill factor, changes in write-once read-only data require the entire index to be rewrittena time-consuming task. A low fill factor may reduce the frequency of splitting index pages but also increase storage requirements and decrease read performance. (See Figure 4.)

20

Figure 4. Set the index fill factor to 75 percent.

Disable the Auto Update Statistics Setting


Kronos recommends disabling the auto update statistics setting for the Workforce Central database (it is set to True by default). Letting SQL Server perform auto updates could negatively affect Workforce Central performance. Kronos recommends manually updating statistics instead. (See Figure 5.)

Figure 5. Disable auto update statistics.

21

Disabling the auto update statistics saves your temporary database (tempdb) some work. Usually objects created in the tempdb are fairly small and, as such, the statistics do not reach the threshold that causes the statistics to update automatically. By disabling the auto update statistics setting, you stop SQL Server from having to check to see if it needs to update the statistics.

Disable the Auto Shrink Setting


Kronos recommends disabling the auto shrink setting (it is set to False by default, in most cases). If you enable the setting, the system attempts to shrink database files when the file contains unused space. This activity may use system resources unnecessarily. (See Figure 6.)

Figure 6. Disable auto shrink.

Perform Regular Maintenance Tasks


Is your database maintenance plan up to date? Kronos strongly recommends that you perform regular maintenance to keep SQL Server running optimally. Your maintenance schedule should include: Updating database statistics. Recompiling stored procedures. Rebuilding and re-clustering tables and indexes. Identifying and correcting excessive fragmentation. Other important maintenance tasks include: Monitoring disk space usage. Monitoring application performance. 22

Monitoring physical and logical disk space. Maintaining indexes and data files. Reviewing backup and recovery operations. Reviewing security. Performing consistency checks. Reviewing SQL Server Logs and/or Windows logs. Verifying the status of all jobs. Monitoring I/O performance regularly during peak processing times. Applying service packs for your database software.

Note that maintaining large or heavily used tables can drastically slow your system. To reduce the impact on day-to-day operations, consider these options: Schedule index maintenance for periods of reduced load. Perform index maintenance as part of a scheduled shutdown.

Update Statistics
Kronos often recommends updating statistics manually using the fullscan (100-percent sample size) option. Use the Stats utility (kron_updatestats) in Workforce Central to run the SQL Server command for updating the statistical information. In particular, update statistics after any large database operation such as an import or archive. Note, however, that you should avoid running Stats during peak usage periods. SQL Server continually collects statistical information about indexes and column data stored in the database. These statistics provide the database with information it needs to efficiently access data. For example, the statistics are used by the SQL Server query optimizer to choose the most efficient plan for retrieving or updating data. Outdated statistics can therefore cause inefficient query plans, which can result in poor performance. If you regularly update those statistics while the database is running, your database performs better.

Reorganize or Rebuild Indexes as Necessary


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 in a table or indexed view, all indexes in a database, or all indexes in all databases. With this command, you do not have to create a temporary table to store results. Instead you have the latest fragmentation levels available in defined columns at any given time. Table 4 shows the result set returned by the sys.dm_db_index_physical_stats. 23

Table 4. Results from sys.dm_db_index_physical_stats.

Column avg_fragmentation_in_percent fragment_count avg_fragment_size_in_pages

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 SQL Server Database Engine automatically maintains indexes whenever insert, update, or delete operations are made to the underlying data. Over time, these modifications can cause the information in the index to become scattered in the database (fragmented). 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 use Table 5 as a guide to determine the best method to correct the fragmentation.
Table 5. Corrective defragmentation method to use.

avg_fragmentation_in_percent value > 5% and < = 30% > 30%

Corrective statement ALTER INDEX REORGANIZE ALTER INDEX REBUILD WITH (ONLINE = ON)*

These commands do not need to address very low levels of fragmentation (less than 5 percent). The benefit of 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.

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

24

Rebuild Indexes when Necessary


Rebuilding an index improves disk performance by reducing the number of page reads required to obtain the requested data. It does this by: Dropping the index and creates a new one. Removing fragmentation. Reclaiming disk space by compacting the pages using the specified or existing fill factor setting. Reordering the index rows into contiguous pages (allocating new pages as needed). 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 guidance.

Monitor Performance
How can you proactively monitor your database server to prevent problems? Kronos recommends that you review all maintenance jobs regularly. Monitoring capacity and performance can provide valuable information for troubleshooting, if necessary. Monitoring includes searching for bottlenecks in your system. If you find your performance is suboptimal, look first at memory, then disk, and finally CPU. You can use Task Manager, System Monitor, SQL Profiler, and DMVs to locate system bottlenecks and determine if these bottlenecks can be resolved by a hardware upgrade. In most cases, a solution involves tuning or rewriting queries, or re-architecting your solution. In many cases, adding hardware does not provide the performance gains of simple index placement.

Establish a Performance Baseline


Kronos recommends starting with a performance baseline. A baseline is an accurate and complete record of the performance of SQL Server during a representative load over a representative time period. The baseline includes all the performance monitor counters during a cycle. This cycle could be a day, a week, or even a month, and the cycle would capture both the peak times and the off-peak times. The baseline lets you: Analyze bottlenecks. Compare and contrast the impact of changes that have been made to the system.

25

Running a baseline can help you determine periods of low activity that can be used for a maintenance window.

Run Kronos Reconcile Reports


The Kronos Reconcile report verifies that all Kronos objects exist and have appropriate permissions. The report contains a: List of any objects that do not exist or that have insufficient permissions. List of all non-Kronos objects within the Workforce Central database. (See Figure 7.)

Figure 7. Kronos reconcile report.

The schema reconciliation report portion verifies information about integrity constraints, indexes, and columns. The report verifies that sequence counters are valid but does validate actual data. (See Figure 8.)

Figure 8. Kronos schema reconciliation report.

26

Review Maintenance Jobs


You can review all of your maintenance jobs in Microsoft SQL Server Management Studio (or Enterprise Manager) to determine success or failure. (See Figure 9.)

Figure 9. Review maintenance tasks.

SQL Server Management Studio is an integrated environment for accessing, configuring, managing, administering, and developing all components of SQL Server. It can be very useful in managing and monitoring your SQL Server environment. SQL Server Management Studio combines the features of Enterprise Manager, Query Analyzer, and Analysis Manager, included in previous releases of SQL Server, into a single environment. In addition, SQL Server Management Studio works with all components of SQL Server such as Reporting Services and Integration Services.

Use Task Manager


Task Manager is useful for getting an instantaneous two-minute window view of CPU utilization, the amount of paging and memory usage, and other counters that update each second. The Process tab lets you to see how many resources each process is consuming. To view Task Manager, press CTRL-ALT-DEL and then select the Performance tab. Use the select columns option to display more counters for each process. Remember that if you are using AWE, the SQL Server process Mem Usage counter will not be accurate

Use Windows Performance Monitor


Use the add button to add the counters you wish to collect. Expand Performance Logs and Alerts, and select New Log Settings. Add the counters you want to log. Table 6 shows the counters you should monitor. For more information, see Performance Monitor Counters. Also see SQL Server Best Practices Article for a list of I/O-related performance counters and their meanings. 27

Since Workforce Central is characterized by many quick, small reads, latency can be an issue. System Monitor (also known as Performance Monitor or Perfmon) lets you collect and display information about a wide variety of operating system and SQL Server counters. Table 6. Recommended Performance Monitor Baseline Counters Counter Process: % Processor Time Description The percentage of the processor time that is used to process user or system transactions as opposed to the CPU sitting idly. The number of threads that are waiting for the CPUs. Pages read and written from memory. The number of read and write requests that are queued for the physical disk subsystem. The number of users on the system. Significance The higher the processor usage the more the CPUs are being used to process user or system transactions. The higher the queue rate the more the threads are waiting on the CPUs to process the instructions on the CPU. The higher the memory usage the more processes are thrashing in memory. The higher the average disk queue length the more resources are waiting for earlier requests to finish prior to fulfilling their request. Because each user connection consumes some memory, configuring overly high numbers of user connections could affect throughput. Determine if excessive network traffic is occurring on a network card or if the system has issues isolated on the SQL Server with no network traffic. Determine if excessive locking is limiting resources for users to access the system. The higher the context switching the more the server is stressed.

System: Processor Queue Length Memory: Pages/sec PhysicalDisk: Avg. Disk Queue Length

SQL Server: General Statistics -- User Connections Network Interface: Bytes Total/sec

The bytes sent and received over a single network card.

SQL Server: Locks -Lock Waits/sec -_Total System: Context Switches/sec

The lock request waits per second. The number of processes that are changing threads per second.

Use Dynamic Management Views


SQL Server provides DMVs and DMFs that give you a window into the current state of internal metadata in SQL Server. DMVs let you drill down on particularly resource-intensive statements of stored procedures or batch operations. Note that because the data these views expose is linked with events such as memory pressure or server restarts, you must save the results of these views to tables to get meaningful results. If not, you may be misled by what may have been transitory events. DMVs are part of the sys schema in the master database. You can find the list of dynamic views in SQL Server Management Studio under Master/Views/System Views; the dynamic functions are located under Master/Functions/System Functions/Table-valued Functions. Each dynamic 28

objects name has a dm_ prefix. Some DMVs return database-specific information while others return instance-wide data. For example, you can use the DMVs for memory to see how SQL Server is internally allocating its memory. Run DBCC PROCCACHE to see how the total number of allocated buffers (num proc buffs) compares with the number used (num proc buffs used). A high-value percentage indicates poor use of procedure cache. You can run DBCC MEMORYSTATUS to observe the values for buffer distribution table. If the number of targeted pages decreases over time, it is likely that your SQL Server is experiencing external memory pressure. Compare the number of targeted pages against the stolen pages. If the number of stolen pages does not stabilize over time, the server may eventually get into internal physical memory pressure. You can then use a DMV query to determine which SQL Server components are consuming the most amount of memory, and observe how this changes over time. Since processes that are disk intensive typically do not have the appropriate indexes or have poor execution plans, you can also use a DMV query to list the top tables experiencing I/O waits.

Monitor Disk I/O Subsystem


Kronos recommends that you monitor your disk I/O subsystem performance. The physical disk subsystem must provide a database server with sufficient I/O processing power for the database server to run without disk queuing. One way to monitor your servers I/O subsystem is to use LogicalDisk: Avg Disk sec/Read and LogicalDisk: Avg Disk sec/Write. You can also use SQLIO or IOMeter.

Periodically Check Database Integrity


Do you routinely check your database for integrity errors? SQL Server includes Database Consistency Checker (DBCC) to help you detect and fix structural integrity problems, including consistency errors, allocation errors, or torn pages. You issue DBCC commands from Management Studio or a DOS.bat file. You can use the Database Maintenance Plan Wizard in SQL Server Management Studio to create a schedule to run DBCC commands. You should run DBCC commands on both your product and master databases. Kronos recommends that you schedule the DBCC CHECKDB statement to run as part of your maintenance plan to check your databases structural integrity. DBCC CHECKDB checks each table in a database for pointer and data page errors. Databases sometimes become corrupted, and corruption can be so severe that it prevents an otherwise successful backup from loading properly.

29

You should run DBCC CHECKDB regularly. Although you can use DBCC CHECKDB during normal operating hours, it can cause significant locking contention and performance degradation. (See Figure 10.)

Figure 10. Run DBCC CHECKDB to check database integrity.

Perform Regular Database Backups


Does your backup strategy meet your business requirements? Kronos recommends that you carefully plan, document, and test a backup and recovery strategy and that you store backup files to disk (local or network) or tape. A well-planned backup and recovery strategy helps protect your database against data loss caused by a variety of failures. SQL Server supports the following types of backups: Whole database. Partial database. Set of files or filegroups. For each of these, SQL Server supports full and differential backups: Full backup. Contains all the data in a specific database or set of filegroups or files, and also contains enough transaction log information to allow for recovering that data. 30

Differential backup. Includes database changes since the last full backup. Transaction log backup. Records any database changes. Database file or filegroup backups. Allow copies to be made of specific database files. This type of backup is not recommended for Workforce Central.

It is also important to select an appropriate recovery model. Full recovery model. This is the best model for preventing critical data loss and restoring data to a specific point in time. This recovery model is generally used by enterprise production systems. If the transaction log is available, it is possible to get up-to-the-minute recovery and pointin-time restore if the end of the transaction log is backed up and restored. The trade-off for the Full recovery model is that it can negatively affect other operations. Simple recovery model. This model is appropriate if the data backed up is not critical, data is static or does not change often, or if data loss is not a concern for the organization. With this recovery model, the organization loses all transactions since the last full or last differential backup. This model is typical for test environments or production databases that are not mission critical. Bulk-logged model. This model is an adjunct of the full recovery model that permits high-performance bulk copy operations. This model reduces log space usage by using minimal logging for most bulk operations. For more information about recovery models, see the article Recovery Model Overview. It is good practice to test your backup and recovery plan. If possible, simulate a disaster such as an air conditioning failure during a heat wave to make sure that your emergency procedures function as planned. At the very least, rebuild the database from scratch using your backups and make sure that your system can access the restored database. Keep the following in mind as you develop and implement a backup and recovery strategy: If you choose the SQL Server full recovery, the transaction log can grow very quickly and should be scheduled for backup at multiple times throughout the day. Performing multiple backups ensures that the log is truncated frequently and improves the recoverability of data. If you choose the simple recovery model, schedule full database backups for at least once per day. With this method, data recoverability is limited to the last full database backup. 31

Have at least one backup device for each database, and give that device a name that clearly describes the database with which it is associated. For example, you might name the backup device for timekeepingdb TIMEKEEPERDB_BACKUPS. Back up a database immediately after you make extensive changes or perform nonlogged operations. Back up the master database any time you perform an operation that alters the structure of any database. Otherwise, you lose information about those changes if the master database fails. Also, be sure to include regular backups of the master and msdb databases as part of your overall backup strategy. The master database contains information about the databases on your system and the msdb database stores information about scheduled jobs. Database backups should be stored off site when possible or appropriate.

Additional Features with SQL Server 2008 Enterprise Edition


To further enhance Workforce Central performance, Kronos recommends taking advantage of the following features if you are using Microsoft SQL Server 2008 Enterprise edition or Microsoft SQL Server 2008 R2 Enterprise edition:

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 out, so it requires less storage, less disk I/O, and less time to complete. The compression is achieved by specifying the WITH COMPRESSION clause in the BACKUP command or by selecting it in 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 page of 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 it during the restore operation. For more information, see the article Tuning the Performance of Backup Compression in SQL Server 2008 on SQLCAT.com.

Transparent Data Encryption


Transparent data encryption (TDE) helps protect data that is residing on a backup tape or disk. TDE performs real-time I/O encryption and decryption of the data and log files by using a database encryption key (DEK). The DEK is a symmetric key secured by using a certificate stored in the master database of the server, or DEK is an asymmetric key protected by an Extensible Key Management (EKM) module. With TDE, you cannot view data stored in the .mdf, .ndf, and .ldf files using a hex editor or other means. However, data that is not at rest, such as the results of a SELECT statement in SQL Server 32

Management Studio, continues to be visible to users who have rights to view the table. Also, because TDE is implemented at the database level, the database can take advantage of indexes and keys for query optimization. Encrypting a database is a one-time process that you initiate using a Transact-SQL command or SQL Server Management Studio, and it is executed as a background thread. You can monitor the encryption or decryption status using the sys.dm_database_encryption_keys dynamic management view. Note the following information: If any database within the instance does have TDE applied, the tempdb system database is also encrypted. When backup compression is used to compress an encrypted database, the size of the compressed backup is larger than if the database were not encrypted because encrypted data does not compress well.

Tune Kronos Workforce Central


There are adjustments you can make to Workforce Central to enhance the performance of the application.

Adjust Max Database Connections Setting if Necessary


The default setting for site.database.max is 50. In general, you should not adjust this setting without guidance from Kronos. (Kronos customers may adjust this setting in Workforce Central 6.1 or later with guidance from the Best Practices for Optimal WFC Performance Guide, located on the Kronos support site.)

33

Summary
Kronos Workforce Central, coupled with Microsoft SQL Server database software, provides you with a complete, strategic solution that easily controls all aspects of workforce management. The Kronos Workforce Central suite provides the end-to-end solution to help your company executives, supervisors, and employees excel in all areas of workforce management. Workforce Central automates your labor-intensive administrative processes, freeing your workforce to focus on productivity and quality. Microsoft SQL Server provides an ideal database platform for Workforce Central. SQL Server is an enterprise-ready, comprehensive, integrated data management and analysis platform that makes it possible for organizations to reliably manage large mission-critical workloads and complex business applications. SQL Server provides rapid data integration and data mining and fast, intuitive analysis and reporting capabilities. The built-in features of SQL Server deliver reliability and security on a scalable foundation that includes a powerful database engine. Using the best practices discussed in the previous sections can help optimize performance of Workforce Central and can help you avoid and minimize problems. The links in the section that follows provide even more information.

34

Links for Further Information


For general information, visit the Kronos Workforce Management Home Page. Kronos provides valuable information for customers on the Kronos Customer Portal. See the documentation section for guides such as: Workforce Central Database Administrators Guide Guide to Planning a Workforce Central Installation

SQL Server information can be found in books online: SQL Server 2008 Books Online SQL Server 2005 Books Online SQL Server Books Online also includes best practice information in the following articles: Best Practices for Replication Administration Replication Security Best Practices

Best Practices for Recovering a Database to a Specific Recovery Point

See the SQL Server Best Practices portal for technical white papers, the SQL Server Best Practices Toolbox, Top 10 Lists, and other resources. For Kronos and Microsoft news, events, and further information, see the Kronos and Microsoft Alliance page. Following is a list of technical white papers that were tested and validated by the SQL Server development team. These can help you learn more about specific SQL Server topics.

Tuning the Performance of Change Data Capture in SQL Server 2008 The Data Loading Performance Guide SQL Server 2008 White Paper: Analysis Services Performance Guide Fast Track Data Warehouse 2.0 Architecture Running SQL Server 2008 in a Hyper-V Environment - Best Practices and Performance Considerations SQL Server Replication: Providing High Availability Using Database Mirroring Best Practices for Semantic Data Modeling for Performance and Scalability Analysis Services Distinct Count Optimization Database Snapshot Performance Considerations Under I/O-Intensive Workloads Best Practices for Migrating Non-Unicode Data Types to Unicode 35

Database Mirroring and Log Shipping Working Together Analysis Services Many-to-Many Dimensions: Query Performance Optimization Techniques The Impact of Changing Collations and of Changing Data Types from Non-Unicode to Unicode Precision Considerations for Analysis Services Users Scale-Out Querying with Analysis Services Using SAN Snapshots Identifying and Resolving MDX Query Performance Bottlenecks in SQL Server 2005 Analysis Services XML Best Practices for Microsoft SQL Server 2005 Performance Optimizations for the XML Data Type in SQL Server 2005 SQL Server 2005 Security Best Practices - Operational and Administrative Tasks SQL Server 2005 Full-Text Queries on Large Catalogs: Lessons Learned Scale-Out Querying with Analysis Services Analysis Services Processing Best Practices Predeployment I/O Best Practices Partial Database Availability Comparing Tables Organized with Clustered Indexes versus Heaps SQL Server 2005 Deployment Guidance for Web Hosting Environments Resolving Common Connectivity Issues in SQL Server 2005 Analysis Services Connectivity Scenarios Implementing Application Failover with Database Mirroring OLAP Design Best Practices for Analysis Services 2005 DBCC SHOWCONTIG Improvements and Comparison Between SQL Server 2000 and SQL Server 2005 TEMPDB Capacity Planning and Concurrency Considerations for Index Create and Rebuild Loading Bulk Data into a Partitioned Table Database Mirroring Best Practices and Performance Considerations SQL Server 2005 Waits and Queues Microsoft SQL Server 2005 Analysis Services Performance Guide SAP with Microsoft SQL Server 2005: Best Practices for High Availability, Maximum Performance, and Scalability Microsoft SQL Server 2005 Tuning Tips for PeopleSoft 8.x Troubleshooting Performance Problems in SQL Server 2005 Troubleshooting Performance Problems in SQL Server 2008

36

You might also like