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.

2
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

3
 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

4
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 ownership―all 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
enterprise’s 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.

5
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
applications—such as Kronos Workforce Central—to 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.

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

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

8
  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 third-
party applications.

Database Tier
The database tier—the focus of the best practices presented in this document—stores 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.

9
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 hardware-
level 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 Database Size Transaction Log Size

Size (MB) (MB)

1 Small 1,024 256

2 Medium 5,120 1,024
3 Large 10,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 Service

SQL Server SQL Server Database Engine includes the core service for storing,
Database Engine processing, and securing data; replication; full-text search; and tools
(MSSQLSERVER) for managing relational and XML data.
Analysis Services includes the tools for creating and managing online
Analysis Services analytical processing (OLAP) and data mining applications.
(MSSQLSERVER)
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
Reporting Services that you can use to develop report applications.

Note that Workforce Central uses Reporting Services only with

advanced reporting.

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 I/O Patterns Description

determine

SQLIO.exe Performance User defined— A fairly rudimentary tool that can be used to
capacity Single I/O type at issue a particular type of I/O against one or
a time many test files to measure I/Os per second
(IOPs), throughput (MB/s), and latency.
IOMeter Performance User defined— Makes it possible for you to define
capacity Allows combinations of I/O patterns, which can be
combinations of issued concurrently against one or more test
I/O types files.
SQLIOSim Functional Simulates SQL Validate the basic functionality of an I/O
correctness Server I/O subsystem under stress and attempt to
patterns simulate actual SQL Server I/O patterns and
check results for 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 system’s 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
application’s 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 rewritten—a 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 Description

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

in the index).
fragment_count The number of fragments (physically consecutive leaf
pages) in the index.
avg_fragment_size_in_pages Average number of pages in one fragment in an index.

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

> 5% and < = 30% ALTER INDEX REORGANIZE

> 30% 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 Description
Process: % The percentage of the processor
Processor Time time that is used to process user
or system transactions as opposed
to the CPU sitting idly.
System: Processor The number of threads that are
Queue Length waiting for the CPUs.
Memory: Pages/sec Pages read and written from
memory.
PhysicalDisk: Avg. The number of read and write
Disk Queue Length requests that are queued for the
physical disk subsystem.
SQL Server: General The number of users on the
Statistics -- User system.
Connections
Network Interface: The bytes sent and received over
Bytes Total/sec a single network card.
SQL Server: Locks -- The lock request waits per
Lock Waits/sec -- second.
_Total
System: Context The number of processes that are
Switches/sec changing threads per second.
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.

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
object’s 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 server’s 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 database’s 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 point-
in-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 Administrator’s 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