Faster SQL Server Access with Solid State

Disks
A white paper by Robbie Stevens, Senior Marketing Writer

Web: RamSan.com | Facebook: facebook.com/texasmemorysystems

Twitter: @TexasMemory | LinkedIn: linkedin.com/company/texas-memory-systems

Scan this QR code with your smartphone for more information on using RamSan SSDs to accelerate SQL Server
databases.
Download a QR scanner here: http://2dscan.com
RamSan and “The World’s Fastest Storage” are registered trademarks of Texas Memory Systems, Inc.
© 2011 Texas Memory Systems, Inc..All rights reserved. Reproduction in any manner whatsoever without the
express written permission of Texas Memory Systems is strictly forbidden. Texas Memory Systems cannot be
responsible for errors in typography or photography.
Information in this document is subject to change without notice.
Table of Contents
Executive Summary ...................................................................................................... 4
Perspectives from Industry .......................................................................................... 5
The Problem of I/O Wait Time ..................................................................................... 6
Traditional Approaches to Improving SQL Server Performance .................................. 7
Introduction to Solid State Disks .................................................................................. 8
Flash Solid State Disks ............................................................................... 8
RAM Solid State Disks ............................................................................... 9
Identifying I/O Subsystem Problems .......................................................................... 10
SQL Server Components That Should Be Moved to Solid State Disk ......................... 13
Entire Database....................................................................................... 13
Transaction Logs ..................................................................................... 13
Temporary Database (tempdb) .............................................................. 14
Indexes .................................................................................................... 14
Frequently Accessed Tables .................................................................... 15
Identifying the Most Frequently Accessed SQL Server Files and Tables .................... 16
Conclusion .................................................................................................................. 18
Table of Figures
Figure 1: Maximum I/Os per Second ............................................................................ 6
Figure 2: An Inside Look at the RamSan-710 Flash Solid State Disk............................. 8
Figure 3: An Inside Look at the RamSan-440 RAM Solid State Disk ............................. 9
Figure 4: Processor Performance when Writing to Hard Disk ................................... 11
Figure 5: Processor Performance when Writing to Solid state disk ........................... 11
 Executive Summary
This whitepaper discusses methods for improving SQL Server database
performance.
It discusses methods for identifying I/O performance bottlenecks and points out
components that are the best candidates for migration to a solid state disk. The
paper also includes an in-depth explanation of solid state disk technology and
possible implementations.
For more in-depth information, visit www.ramsan.com or contact one of the
following:
 Existing customers contact support@ramsan.com.
 Potential customers contact sales@ramsan.com.

November 2011 4 Texas Memory Systems

 Perspectives from Industry
From Chapter 6 of Tuning and Sizing NT Server by Curt Aubley, reprinted on
Microsoft TechNet:

No matter how well you sized and tuned your NT Server disk subsystem, the
disk subsystem is still composed of physical devices that are slow when
compared to RAM. There may be times, regardless of how well you have
load balanced and tuned your disk subsystem, when "hot spots" still exist.
"Hot spots" are defined here as areas of the disk subsystem that
application(s) consistently request services from which greatly impact the
application's performance. Consider another technique to alleviate hot spot
situations; try implementing RAM disks.
From the Morgan Keegan System Area Network Conference, Solid State Caching,
page 85-86:

Since 1964 the capacity of disk drives has increased by over 6,000 times
while the average seek latency has only seen about a tenfold improvement.
The continued increase in capacity without corresponding improvement in
access times has caused a steady decline in the access density of disk media,
which is the ratio of I/Os per second divided by the capacity of the disk drive.
As a result, many storage administrators are finding that in spite of the fact
that they are adding storage capacity at an unprecedented pace, system
performance does not improve. In other words, their storage infrastructures
are I/O bound. One way to solve this dilemma is to spread the information
access workload across a large number of systems. In many situations,
however, a more efficient method of improving performance is the
implementation of a solid-state disk (SSD) caching solution. SSD offers the
fastest storage media available.

However, we believe SSD caching will see increasing adoption in the system
network as the optimal storage resource for certain data types requiring
high levels of availability. The return on investment of SSD increases
dramatically in a centralized storage configuration in which the cost may be
amortized across a larger infrastructure and SSD can be added incrementally
as needed…

November 2011 5 Texas Memory Systems

 The Problem of I/O Wait Time
Often, additional processing power alone does little or nothing to improve SQL
Server performance. This is because the processor, no matter how fast, finds itself
constantly waiting on mechanical storage devices for its data. While every other
component in the “data chain” is solid state, hard drives are mechanical, relying on
physical movement around a magnetic platter to access information.
In the last twenty years, processor speeds have increased at a geometric rate. At the
same time, however, conventional storage access times have only improved
marginally. The result is a massive performance gap, felt most painfully by database
servers, which typically carry out far more I/O transactions than other systems.
Super fast processors and massive amounts of bandwidth are often wasted as
storage devices take several milliseconds just to access the requested data.
When servers wait on storage, users wait on servers. This is I/O wait time. Solid
state disks solve the problem of I/O wait time by offering faster access times and
more I/O transactions per second than monolithic RAID. Figure 1 shows the
performance of the RamSan-710 Flash SSD, RamSan-440 RAM SSD, RamSan-70 Flash
PCIe SSD, and RamSan-630 Flash SSD in sustained random I/Os per second versus
other storage options.

1,000,000

600,000 600,000

400,000

300 2,500 30,000

F IGURE 1: M AXIMUM I/O S PER S ECOND

November 2011 6 Texas Memory Systems

 Traditional Approaches to Improving SQL
Server Performance
Decreasing application performance under heavy user loads is not a new story for
most enterprises. As the number of concurrent users increase, the response time to
users worsens. The knee-jerk reaction to this problem is to look at two solutions for
database performance problems:
 Server and processor performance. When performance wanes, one of the first
things that most IT shops do is add processors to servers or add servers to
server farms.
Adding servers and processors has a minimal impact on database performance
and compounds the resources wasted as even more processing power waits on
the same slow storage.
 SQL statements. Enterprises invest hundreds of thousands of dollars squeezing
every bit of efficiency out of their SQL statements. The personnel required to
painstakingly evaluate and iterate the code are a major cost for many IT shops.
Tuning SQL may result in performance improvements, but even the best SQL
cannot make up for poor storage I/O. In many cases, applications cannot
support features that rely heavily on disk I/O, for example, developers often
remove features that result in large queries and return large data sets in order
to protect application performance.
When system administrators look to storage, they frequently try these different
approaches to resolving performance problems:
 Increase the number of disks. Adding disks to JBOD or RAID is one way to
improve storage performance. Increasing the number of disks spreads the I/O
from a database across more physical devices.
As with other approaches, this has a trivial impact on decreasing the problem.
 Move the most frequently accessed files to their own disk. This approach
delivers the best I/O available from a single disk drive.
However, the best I/O capability of a single hard disk drive is very limited.
The best solution to the performance gap is to implement solid state disks for the
most frequently accessed database components.

November 2011 7 Texas Memory Systems

 Introduction to Solid State Disks
Strictly speaking, a solid state disk (or SSD) is any storage device that does not rely
on mechanical parts to input and output data. Typically, however, the term refers to
storage devices that use memory (RAM or Flash) as the primary storage media. Data
is stored and accessed directly on memory chips. This generally results in storage
speeds far greater than is even theoretically possible with conventional, magnetic
storage devices. To fully make use of this speed, SSDs typically connect to servers or
networks through multiple high-speed channels.

Flash Solid State Disks

Flash solid state disks offer higher capacity at a lower price than either DDR RAM or
cached flash SSDs. This is because the Flash solid state disk is inherently non-volatile
and does not require additional batteries to allow flushing of the DDR cache during
power outages; Flash SSDs also do not include large amounts of expensive DDR
memory. Instead, a small amount of DDR is used to buffer the flash for writes and to
act as a metadata repository during operation. Batteries are used to provide
electricity during loss-of-power situations to allow the flush of the small cache and

RamSan-710 Architecture
metadata areas to Flash. With a Flash solution like the RamSan-710, 5 terabytes of
storage can fit into a 1U form factor.

2 Dual-ported FC or IB
Interfaces
1-5TB of SLC Management
Flash Boards Control
Processor

Redundant
Power
Supplies

Redundant
1U Chassis
Fans

F IGURE 2: A N I NSIDE L OOK AT THE R AM S AN -710 F LASH S OLID S TATE D ISK

November 2011 8 Texas Memory Systems

 RAM Solid State Disks
While RAM SSDs are not inherently non-volatile like Flash SSDs, RAM-based RamSan
SSDs include internal batteries that, in the event of power loss or shutdown, keep
the unit powered long enough for data to be written onto backup disks. Because of
this, RAM SSDs offer the raw speed of system memory without the disadvantage of
losing data when powered down. And since all RamSan SSDs lack mechanical
devices in the main data chain, they typically have lower maintenance costs and
higher reliability (including a higher MTBF) than conventional storage.

F IGURE 3: A N I NSIDE L OOK AT THE R AM S AN -440 RAM S OLID S TATE D ISK

November 2011 9 Texas Memory Systems

 Identifying I/O Subsystem Problems
While a solid state disk can speed up almost any SQL Server database, it is most
needed in installations where servers are experiencing I/O wait time. A number of
elements are involved in server I/O. The PCI (or other) bus, host bus adapter,
interface, storage network switch, RAID controller, and hard disk drives are all
involved in every I/O between server and storage. Theoretically, any one of these
points can cause an I/O bottleneck. In practice, however, the hard disk drives are
the most likely culprit. Simply put, every component in the I/O process is solid state
except for the hard disk drives. Therefore, when you identify I/O wait time, hard
disk drives are the most likely cause. Adding a solid state disk can significantly
reduce I/O wait time.
The best way to identify I/O wait time is to look at operating system performance.
The tools to evaluate operating system performance vary by operating system.
For Microsoft Windows operating systems, the best tool for system performance
analysis is the Performance Monitor (Perfmon). Unfortunately, the Performance
Monitor does not provide the actual I/O Wait Time statistic, but it does include
actual processor performance levels. The “Processor: % Processor Time” statistic
shows the actual work being done by the processor. If transactions are hitting your
system hard and yet your “% Processor Time” is well under 100%, it is possible to
infer an I/O wait problem. Systems that implement solid state disk show high “%
Processor Time” numbers.
For example, Figure 4 and Figure 5 show screen shots from Windows Performance
Monitor. Figure 4 shows the “Processor: % Processor Time” for a Windows system
running Intel’s Iometer performing 100% random writes to a hard disk drive. In this
exhibit, the processor utilization is less than 1%. Running additional applications on
this system would only increase the processor utilization marginally, because the
processor is waiting on I/O from the hard disk drive. In this example, Iometer shows
that on average there were 150 writes per second (150 IOPS) to the disk drive.

November 2011 10 Texas Memory Systems

 F IGURE 4: P ROCESSOR P ERFORMANCE WHEN W RITING TO H ARD D ISK

Figure 5 shows the same system with the same access specifications in Iometer
running against a Texas Memory Systems RamSan solid state disk. In this example,
the processor averages 68% utilization. The Iometer shows that 138,000 writes per
second are going to the RamSan (138,000 IOPS). As it turns out, this IOPS number is
a limitation of the host bus adapter. Nonetheless, this example clearly illustrates
how a solid state disk can improve processor utilization for a Windows based
system.

F IGURE 5: P ROCESSOR P ERFORMANCE WHEN W RITING TO S OLID STATE DISK

November 2011 11 Texas Memory Systems

 In addition to processor indicators, Microsoft recommends looking at the “Physical
Disk: Average Queue Length” and “Physical Disk: Disk Bytes Per Second” to detect
bottlenecks in the disk subsystem. See Diagnosing Windows I/O Bottlenecks Using
Performance Monitor for more details on setting up Perfmon testing.
If the “Physical Disk: Average Disk Queue Length” is consistently high, consider
moving files that are located on that disk to the solid state disk. A “Disk Queue
Length” greater than 3 (per disk in the RAID set) indicates a problem.
The “Physical Disk: Disk Bytes Per Second” indicator helps you visibly determine the
level of performance you are getting when your disk array levels off. The point at
which disk bytes per second level off and physical disk queue lengths increase is the
point when your system is demonstrating an I/O bottleneck. In addition, if you
simultaneously graph Processor Utilization, you will notice that processor time tends
to decrease when your system experiences an I/O bottleneck. One you have
narrowed down the time range causing I/O problems, further refine your search for
the problem by using Perfmon’s ability to narrow details by reads/writes and by
drive arrays. In this way, you can quickly determine which array is causing I/O
problems.
For statistics to confirm the I/O Wait witnessed by the application, you can also load
the SQL Server: Wait Statistics objects into Windows Perfmon. These counters give
an application’s perception real-time queries’ Wait categories. The most prominent
waits are typically the Page IO Latch waits along with Log buffer and Log Write
waits.
These tools allow you to observe the I/O wait time for a Windows based system.

November 2011 12 Texas Memory Systems

 SQL Server Components That Should Be
Moved to Solid State Disk
Once you determine that your system is experiencing I/O subsystem problems, the
next step is to determine which components of your SQL Server database are
experiencing the highest I/O and in turn causing I/O wait time. Examine the
following database components:

Entire Database
There are some databases that should have all of their files moved to solid state
disk. These databases tend to have at least one of the following characteristics:
 High concurrent access. You should consider moving all data to solid state disk
for databases that are hit by a large number of concurrent users. This ensures
that storage is not a bottleneck for the application and maximizes the utilization
of servers and networks. I/O wait time will be minimized and servers and
bandwidth will be fully utilized.
 Frequent random accesses to all tables. For some databases, it is impossible to
identify a subset of files that are frequently accessed. Many times these
databases are effectively large indices.
 Small to medium size databases. Given the fixed costs associated with buying
RAID systems, it is often economical to buy a solid state disk to store small to
medium sized databases. A RamSan-710, for example, can provide 5 TB of
database storage for the price of some enterprise RAID systems.
 Large read-intensive databases. Given the fixed costs associated with
architecting a RAID system for performance (buying a large cache, buying a lot
of spindles for striping), it is economical and much faster to buy a RamSan-630
Flash solution to accelerate large read-intensive databases. A single RamSan-
630 can scale to 10 TB of capacity.
 Database performance is key to company profitability. There is a subset of
databases that help companies make more money, lose less money, or improve
customer satisfaction if they process faster. Solid state disks can help make
these companies more profitable.

Transaction Logs
Transaction logs are one of the most important factors in the write performance for
SQL Server databases. Whenever a database write occurs, SQL Server creates a
transaction log entry. Each SQL Server database has at least one transaction log
(*.ldf). SQL Server considers operations committed once the write to the transaction
logs is complete.

November 2011 13 Texas Memory Systems

 Because the transaction logs are a source of constant I/O during database
operation, the transaction logs should be stored on the fastest disk possible. Writing
a transaction log to a solid state disk is a natural way to improve overall database
performance.
The Microsoft MSDN site has the following to say about optimizing performance of
transaction logs:

Create the transaction log on a physically separate disk or RAID (redundant

array of independent disks) device.
Texas Memory Systems recommends that the separate disk be a RamSan solid state
disk.

Temporary Database (tempdb)

SQL Server uses tempdb to support temporary data during certain operations. The
tables support complex queries, joins, and index creations. Because tempdb
supports many kinds of operations, it is essential that they be located on the fastest
possible storage.
When complex operations occur, they complete more quickly if the tempdb is
moved to solid state disk. Because the I/O to the tempdb can be frequent, disk
drives cannot handle them easily.
The Microsoft MSDN site says the following about optimizing performance of
tempdb:

Place the tempdb database on a fast I/O subsystem to ensure good

performance. Stripe the tempdb database across multiple disks for better
performance. Place the tempdb database on disks different from those used
by user databases.

Indexes
An index is a data structure that speeds up access to database records. An index is
usually created for each table in a database. SQL Server updates these indexes when
adding records and modifying records’ identifying data. When a read occurs, SQL
Server consults an index to access the correct record quickly. Furthermore, many
concurrent users may read any index simultaneously. This activity to the disk drive
creates frequent, small, and random transactions, which makes the disk drives
unable to keep up with demand and I/O wait time results.
Storing indexes on a solid state disk can increase the entire application’s
performance. For online transaction processing (OLTP) systems with a high number
of concurrent users, this results in faster database access. Historically, indexes have

November 2011 14 Texas Memory Systems

 been a common SQL Server component to be moved to solid state disk because
they can be recreated from the existing data.
The Microsoft MSDN site says the following about allocating indexes to their own
filegroup:

By default, indexes are created on the same filegroup as the base table on
which the index is created. However, it is possible to create nonclustered
indexes on a filegroup other than the filegroup of the base table. By creating
the index on a different filegroup, you can realize performance gains if the
filegroups make use of different physical drives with their own controllers.
In this case, Texas Memory Systems recommends moving the filegroups that contain
the indexes to solid state disk.

Frequently Accessed Tables

Sometimes, just 5%-10% of tables account for a large percentage of all database
activity, and thus I/O to storage. When a large number of users hit a table, they are
likely going after different records and different attributes. As a result, the activity
on that table is random. Disk drives are notoriously bad at servicing random
requests for data. In fact, the peak performance of a disk drive drops as much as
95% when servicing random transactions. When a table experiences frequent
access, transaction queues develop where other transactions are literally waiting on
the disk to service the next request. These queues are another sign that the system
is experiencing I/O wait time.
Moving frequently accessed tables to a solid state disk makes sense. Unlike
traditional hard drives, random transactions do not affect solid state disk
performance. Additionally, solid state disks have faster access times than disk
drives. Therefore, moving frequently accessed tables to solid state disk can improve
application performance up to 10 times.
SQL Server supports moving specific tables to specific filegroups, which enables you
to move the most frequently accessed tables to solid state disk easily.

November 2011 15 Texas Memory Systems

 Identifying the Most Frequently Accessed SQL
Server Files and Tables
The SQL Server Profiler tool allows database administrators to monitor events in
SQL Server. The profiler monitors SQL Server activities by tracing selected events,
including database objects. Database objects include databases, tables, indexes,
views, and stored procedures. The SQL Server Profiler specifically supports
monitoring when a table is opened. Tables are opened during “Select,” “Insert,” and
“Delete” statements. By using the profiler, a database administrator can monitor
the number of times all tables are opened during the trace period. The results of the
trace can be sent to a table for further analysis to determine which tables were
most frequently opened during the trace period and thus which tables are the best
candidates for placement onto a solid state disk.
Microsoft cautions that “Object” related traces could impose a significant overhead
on database performance because of the frequency that objects are accessed. If you
have a test environment that models production activity and transaction mixes, this
may be the best place to use an SQL Server Profiler “Object” trace. Otherwise, make
sure you do not use the Profiler during peak transaction periods unless you are
willing to take the performance hit.
More information on SQL Server Profiler and database objects can be found at the
Microsoft MSDN site.
It is a best practice for Microsoft SQL users to physically isolate database objects,
such as tables and indexes, into unique Filegroups. With Filegroups, management
and monitoring become more granular than the database level and DBAs are able to
avoid the high overhead of SQL Server profiler to find hotspots. This monitoring is
done with Dynamic Management Views (DMVs).
The DMV dm_io_virtual_file_stats is a query of I/O counters and cumulative wait
times for each type of I/O. These counters represent the aggregate values since the
last boot of the SQL Server instance. Because these are running counters, a
difference in query results in needed to get a proper assessment of I/O wait. One
query result should be recorded before a busy period of the application and a 2nd
query result should be recorded after the busy period. Recording each query result
in a spreadsheet application, such as Microsoft Excel, is ideal for this analysis.

November 2011 16 Texas Memory Systems

select CURRENT_TIMESTAMP as SnapShotTime,
db.name as DatabaseName,
mf.physical_name as FilePath,
mf.name as LogicalName,
vfs.*
from sys.dm_io_virtual_file_stats(-1,-1) as vfs
join sys.master_files
as mf on vfs.database_id = mf.database_id and vfs.file_id= mf.file_id
join sys.databases
as db on vfs.database_id= db.database_id;

From the above query, we are able to extract the counters for every database with
their respective file statistics. The results can then be presented into a more visual
form using Microsoft Excel with a PivotChart to group files into filegroups. Below is
an example of showing the number of I/O Stalls logged against each file’s size in a
TPC benchmark database.

Database I/O Waits with Size on Disk

100,000,000,000

10,000,000,000

1,000,000,000

100,000,000

10,000,000

1,000,000

100,000

10,000

1,000

100

10

1
Parts
Orders

PartSupp

tpc
Supplier

tpc_log
Indexes

Nation

Region
Customer

LineItem

tpc

Total I/O Wait in milliseconds Size in Bytes

November 2011 17 Texas Memory Systems

 Conclusion
Increasing processor power often has very little impact on SQL Server performance.
Instead, the problem of I/O wait time demands a storage-based solution. The best
option is to put the most frequently accessed database components on fast solid
state disks. Using the SQL Server Profiler tool, you can easily determine the best
candidates to move, ranging from the entire database to transaction logs, temdb,
indexes, and frequently accessed tables.

November 2011 18 Texas Memory Systems