Microsoft SQL Server Acceleration Flash Buyer's Guide
←
→
Page content transcription
If your browser does not render page correctly, please read the page content below
Microsoft SQL Server Acceleration Flash Buyer’s Guide Allon Cohen, PhD Scott Harlin OCZ Storage Solutions, Inc. – A Toshiba Group Company
Contents
1 Introduction...................................................................................................................................2
2 Microsoft SQL Server Overview.....................................................................................................3
2.1 What are common Microsoft SQL Server DBMS data types?.................................................3
2.2 What are the common Microsoft SQL Server databases?.......................................................4
2.3 What are the common Microsoft SQL Server applications?.....................................................5
3 When should I use flash to accelerate my SQL Server application?................................................6
4 Which flash form factors are best for my SQL Server application?..................................................7
5 Which performance metrics should I use to best compare flash solutions?....................................8
5.1 Testing flash performance specific to SQL Server workloads................................................10
6 What is the difference between flash volumes and flash caching, and when to use each?...........10
7 What kinds of SQL Server data should I place on flash?..............................................................11
8 What capabilities verify data will be available on flash for SQL Server?.........................................12
9 What parameters should I consider if my SQL Server instances are virtualized?...........................13
10 What native flash functionality does SQL Server 2014 provide?.................................................14
11 How can flash improve SQL Server ETL processes?.................................................................15
12 How can implementation wizards affect the success of my SQL Server acceleration project?....16
13 Flash Buyer’s Checklist..............................................................................................................17
14 Introducing OCZ’s ZD-XL SQL Accelerator.................................................................................18
1 Introduction
Flash memory technology provides a perfect match to the performance requirements of enterprise
and cloud database applications. In comparison to traditional hard disk drive (HDD) storage,
flash-based storage uses significantly less electricity, has no moving mechanical heads or spinning
disks, and reads and writes data significantly faster handling random data access effortlessly while
completely outperforming the slower electromagnetic media.
The purpose of this Flash Buyer’s Guide developed by OCZ Storage Solutions – a Toshiba Group
Company is to provide database administrators (DBAs) and IT managers responsible for the success
of their enterprise database applications with key guidelines on when and why to deploy flash in a
Microsoft SQL Server environment and how to accelerate this application effectively using solid-state
storage.
The guide details typical and common questions asked by DBAs and IT managers when considering
flash usage in their environments and provide answers to those questions with solutions and
capabilities that accelerate Microsoft SQL Server applications.
Buyer’s Guide | SQL Server Acceleration Flash Buyer’s Guide | V1.0 | © 2014 OCZ Storage Solutions 2Included in the Flash Buyer’s Guide is a checklist that can be used when comparing the variety of
offerings available from various flash storage vendors, as well as a short introduction to how OCZ
accelerates SQL Server applications through its award-winning ZD-XL SQL Accelerator PCIe card.
2 Microsoft SQL Server Overview
SQL Server is a database management system (DBMS) developed by Microsoft designed for
enterprise environments. It is a software product whose primary function is to store and retrieve
data as requested by other applications (either on the same computer or on another computer
across a network). There are different editions of Microsoft SQL Server aimed at various audiences
with workloads that include OnLine Transaction Processing (OLTP), data warehousing, data mining,
OnLine Analytical Processing (OLAP), to name a few.
As the most pervasive DBMS solution in the market, Microsoft SQL Server provides enterprises of
all sizes with a wide range of transactional and analytical capabilities to solve critical business needs.
Being data access intensive, one of the major factors affecting its performance is the strength of the
underlying storage resources. The speed of the storage implementation is determined by the time
it takes to scan and analyze large portions of data as well as the amount of concurrent commands
that the storage device can process ultimately determines whether users receive the business insight
they need, when they need it.
To enable a large number of users to be serviced without contention, and to maximize each user’s
application experience, the underlying storage metrics particular to SQL Server workloads must
deliver optimal performance. Providing immediate access to data becomes especially critical during
peak usage so that productivity is not adversely affected. Transactional access rates and database
read bandwidth can significantly impact the time it takes to complete queries in enterprise and cloud
environments.
New technologies introduced in Microsoft SQL Server 2014, such as in-memory columnar
processing and buffer pool extensions further enhance SQL Server performance, far bypassing the
capabilities of traditional HDD storage. With the parallel growth in server CPU power and memory, a
matching storage paradigm is required to achieve the full benefits and new capabilities presented by
SQL Server 2014.
2.1 What are common Microsoft SQL Server DBMS data types?
Microsoft SQL Server is a DBMS that lets users create and access data in a database and manages
these user requests freeing them and other application programs from having to know where
data is located on storage media. As a DBMS, it ensures that data continues to be accessible, is
consistently organized as intended, and is secured so only those with access privileges can access
the data.
Buyer’s Guide | SQL Server Acceleration Flash Buyer’s Guide | V1.0 | © 2014 OCZ Storage Solutions 3The most common DBMS is a relational database management system (RDBMS), as the standard
user and program interface is the Structured Query Language (SQL). A DBMS can be thought of as
a file manager that manages data in databases rather than files in file systems. Microsoft SQL Server
is a DBMS that serves database requests from multiple users and includes three distinct data types:
1. Data records and indexes (referred to as database data)
2. Transaction logs (referred to as the write log files) log user transactions and are also used for
recovery and data replication
3. TempDB files use a temporary database to store transient, non-persistent data
2.2 What are the common Microsoft SQL Server databases?
Microsoft SQL Server databases typically fall into two primary categories, either transactional or
analytical, with records presented as either row or columnar based.
Transactional Databases
These databases facilitate and manage all online transactions capturing information surrounding
a business transaction (e.g. a sale) while enabling the data to be segmented, grouped, stored
or retrieved for a specific use-case. This type of data commonly includes data items such as
products ordered, sales prices, shipping and routing information, method of payment, applied
warranties/rebates /discounts, sales location and any number of other variables available
through the recording of transactions.
Analytical Databases
These databases selectively extract data for analysis and provide varying points of view of the
data captured. As an example, this type of data enables users to analyze products sold in a
geographic area, during a specific month, compared to revenue during another month, or a
comparison of other product sold during the same time period, etc. To facilitate this kind of
analysis, the data in some cases is stored in a multi-dimensional database (versus a relational
database) that considers each data attribute (such as product, geographic sales region, and
time period) as a separate dimension for analysis.
Row-Oriented Databases
A DBMS that stores data in rows, sometimes referred to as a record, and includes a set of
database fields within a table relevant to a specific entry. For example, in a table called customer
contact information, a row may contain the following fields:
ID LastName FirstName Bonus
132 Doe John 8000
133 Smith Will 4000
134 Jones Mike 2000
Buyer’s Guide | SQL Server Acceleration Flash Buyer’s Guide | V1.0 | © 2014 OCZ Storage Solutions 4In a row-oriented DBMS, each record would be stored as a unit. In the above example, three
units would be stored and include {132, Doe, John, 8000}, {133, Smith, Will, 4000} and {134,
Jones, Mike, 2000}.
Column-Oriented Databases
A DBMS that stores data in columns (instead of rows) so that data can be highly compressed
enabling operations to be performed very quickly as the number of data elements that typically
must be read by the database engine while it is processing queries is greatly reduced. Also,
since columnar databases are self-indexing, they require less storage space.
Using the example from the Row-Oriented records, in a column-oriented DBMS, each record
would be stored as a unit as follows: {132, 133, 134}, {Doe, Smith, Jones}, {John, Will, Mike}
and {8000, 4000, 2000}.
2.3 What are the common Microsoft SQL Server applications?
Microsoft SQL Server applications typically fall into three primary categories including OnLine
Transaction Processing (OLTP), OnLine Analytical Processing (OLAP) and data mining. A brief
description of each now follows:
OLTP
A database application that facilitates, manages, and processes transactions. A primary
example includes data entry and sales order retrieval in support of a number of industries. The
key to supporting OLTP applications in the enterprise is to enable a large number of users to
be serviced without contention and to deliver optimal storage latency and transactional IOPS.
SSD flash memory provides a perfect fit for the data access requirements of OLTP applications
through its support of ultra-low latencies and the ability to efficiently handle randomized data
access requests.
OLAP
A database application used to selectively extract data for analysis and to provide varying points
of view of the data captured and helps enable companies and organization to make better
business decisions. As it relates to marketing applications, OLAP is commonly used to verify or
prove the effectiveness of existing marketing campaigns.
In many cases, the data to be used for OLAP is collected into a central repository commonly
called a data warehouse. Data from various OLTP applications and other sources are selectively
extracted and organized onto the data warehouse database for use by analytical applications
and user queries. A Microsoft SQL Server data warehouse can include hundreds of thousands
of products and a few million records (typical in today’s enterprise) so the accuracy of the
information and the ability to deliver data in real-time to customers can be the difference in
securing customer orders and providing a heightened experience.
Buyer’s Guide | SQL Server Acceleration Flash Buyer’s Guide | V1.0 | © 2014 OCZ Storage Solutions 5Data Mining
In data mining applications, miners sort through huge data sets using sophisticated software
to identify undiscovered patterns and establish hidden relationships, whereas data analytics
focuses on the process of deriving a conclusion based solely on what is already known. Typical
data mining parameters include:
• Association: searches for patterns that connect one event to another
• Sequence (Path) Analysis: searches for patterns where one event leads to another later event
• Classification: classifies new facts into previously discovered patterns
• Clustering: finds and visually groups facts into distinct classes
• Forecasting: discovers patterns in data that can lead to reasonable future predictions known
as predictive analysis
3 When should I use flash to accelerate my SQL Server
application?
A DBA or IT manager will definitely know when they have a performance issue to address when
either end users complain about performance or when the CFO complains about SAN and server
expenditures. Microsoft SQL Server performance can be affected by multiple external factors
such as the underlying networking, slow CPUs, and limited memory allocation, but the collective
experience of many DBAs has shown that in a majority of cases, the culprit is slow storage. The
following highlights key signs that indicate the enterprise environment can benefit from using flash to
accelerate SQL Server applications.
Low CPU Utilization during Peak Usage Times
During high workload events when memory fills up, SQL Server often requires frequent access
to data pages from underlying storage. Low CPU utilization coupled with high memory usage is
an indicator that the processing cores are wasting idle cycles waiting for data to arrive. In these
cases, deploying flash services quickens data access and dramatically improves CPU utilization.
SAN Controller I/O at Maximum Performance
If SQL Server is saturating the underlying SAN, all other applications attempting to access the
SAN will also be affected. The performance bottleneck will spread from SQL Server to other
applications. On-host flash resources, such as PCIe cards, enable the data hungry SQL Server
CPUs to get the data they need locally, alleviating pressure on the SAN while enabling it to
handle other applications.
Excessive TempDB Usage
TempDB files may contain interim results (such as transient calculation tables) that the server
writes during the query and must read before being able to complete the query, therefore,
write and read performance are critical for the timely execution of such queries. In multi-core
systems, tempDB files may be written to and read from simultaneously creating random access
patterns that are detrimental to HDD performance as its mechanical head moves from location
Buyer’s Guide | SQL Server Acceleration Flash Buyer’s Guide | V1.0 | © 2014 OCZ Storage Solutions 6to location. Each movement takes time so the read/write IOPS performance and latency slows
down considerably until data is found and accessed. In contrast, tempDB usage patterns are.
Low memory creates further loads on tempDB files as SQL Server uses it to store interim results
when main memory runs out. Utilizing flash storage, tempDB performance can be dramatically
improved and an excellent fit for SSDs as it seamlessly handles random read and write loads.
Frequent Storage and Server Upgrades
If an IT department is constantly upgrading the SAN due to growing usage, or if more servers
are being purchased to improve performance while CPU utilization for each server remains low,
introducing flash into the environment will efficiently extend CPU utilization on existing servers
and gain the required performance benefits while reducing licensing, OPEX and CAPEX costs in
the enterprise.
4 Which flash form factors are best for my SQL Server
application?
The main flash-based SSD formats fall into three categories:
PCIe Flash Cards – a high-speed expansion card format that connects enterprise servers to
peripherals in a serial interface format. Every device connected to a motherboard using PCIe
can use multiple point-to-point connections called ‘lanes.’ As a result, PCIe-connected devices
can aggregate bandwidth, which in turn, enables more scalable performance, lower latency and
higher data transfer rates making these devices ideal for SQL Server applications.
As a server-side flash solution, PCIe cards are typically compact, power-efficient and fit directly
into the server’s PCIe bus to increase server application performance while delivering fast and
reliable access to data without burdening host CPU and memory resources. The interface
supports different size formats of PCIe cards such as Full Height/Full Length (FH/FL), Full-Height/
Half-Length (FH/HL) and Half-Height/Half-Length (HH/HL).
SAS or SATA SSDs – These flash-based drives are packaged in the same form factor as
traditional HDDs so they can be ubiquitously deployed and utilized in practically any server
or storage slot initially designed to hold HDDs. SAS (Serial Attached SCSI) and SATA (Serial
Advanced Technology Attachment) are both industry standard connections used to connect
HDDs, and now flash-based SSDs, into a computer system based on serial signaling
technology.
One drawback of both SAS and SATA is that these form factors were originally designed for
HDDs, so that the power that can be drawn and used by SSDs is limited affecting each SSD’s
peak performance. Storage capacity is also capped by the amount of flash that can actually
fit into these smaller HDD enclosures. Finally, bandwidth is also limited by SAS and SATA
Buyer’s Guide | SQL Server Acceleration Flash Buyer’s Guide | V1.0 | © 2014 OCZ Storage Solutions 7interfaces to the maximal rates originally designed for mechanical HDDs in mind. To a certain
extent, this limitation can be overcome by aggregating the bandwidth from multiple SSDs in an
enclosure.
External Flash Arrays – External flash arrays offer a simple way to deploy large amounts of flash
centrally to multiple servers. They connect to servers using traditional SAN and NAS interfaces
and present flash to the array through networking protocols. Flash arrays enable relatively
simple deployment because they do not require physical access to the host running SQL Server
to deploy the flash. These external arrays therefore offer an excellent solution when the flash
placed locally on the server is limited, as is the case in blade arrays.
Flash arrays may be susceptible to networking and storage controller bottlenecks as they do not
sit directly on the host PCIe bus. Latency will also be increased due to the extra network hops.
5 Which performance metrics should I use to best compare
flash solutions?
Flash storage vendors present performance data that covers various users and use cases so one
must use caution when interpreting this data when it pertains to Microsoft SQL Server environments
as this application has very particular data access patterns. As a result, some of the general
performance data published by flash vendors may be irrelevant to the eventual performance one will
actually obtain in a SQL Server environment.
Typical parameters used to evaluate the total effectiveness of a storage system include input/output
operations per second (IOPS), bandwidth and latency.
Latency
The time it takes to complete an operation. Typically the farther away the flash storage device is
from the CPU accessing it, the more latency exists and the slower it is to complete an operation.
As an example, a PCIe flash card that resides on the server’s PCIe bus, in close proximity to the
CPU, has significantly less latency than a SAS-based or SATA-based SSD residing on a shared
storage network. HDDs have significantly higher latency than SSDs given the time it takes to
move the read head to new locations.
It is important to note that while latency measures the total time it takes to complete an I/O
command, not all commands are identical. Commands are differentiated by their command size
which reflects the amount of data that needs to be passed to or from an SSD. Small command
sizes require the processing of small amounts of data and hence the latency to process them
will typically be lower. Larger command sizes require the processing of larger amounts of data
and hence take more time to process. For this reason low latency numbers published by flash
storage vendors usually reflect very small command sizes.
Buyer’s Guide | SQL Server Acceleration Flash Buyer’s Guide | V1.0 | © 2014 OCZ Storage Solutions 8For most transactional operations, SQL Server uses large command sizes typically ranging
from 4KB to as high as 64KB, and therefore the lowest latency number published usually are
not relevant to SQL Server performance. As most SQL Server applications run on multicore
systems and issue multiple storage commands in parallel, the latency of a single I/O command
will rarely be the determinant of overall performance. In most systems the ability to handle
multiple concurrent commands is much more critical as indicated by IOPS performance.
IOPS (Input/Output Operations Per Second)
A measurement representing the total number of I/O operations that an SSD can perform in
one second in context with the type of storage operation performed (read, write, hybrid) and the
size of commands for the data being exchanged. While lowering latency does enable a higher
number of IOPS (as more commands can be completed each second), latency is not the only
factor determining IOPS.
The second factor affecting IOPS performance is parallelism, which increases IOPS by enabling
multiple commands to be processed in parallel. A PCIe flash card that employs parallelism will
be able to process more commands per second and more effectively handle the concurrent
requests of many CPU cores processing data in parallel for SQL Server queries. For this reason,
a PCIe card with multiple controllers (or a controller with multiple cores) will usually fair better
in SQL Server environment than a PCIe card with a single controller, even if it is capable of
producing very low latencies of individual commands.
While IOPS is usually a better metric to look at than latency for measuring SQL Server
performance, remember that even when comparing IOPS it is important to consider command
sizes relevant to SQL Server loads as they range from 4K to 64K. IOPS are particularly
important as a performance indicator for transactional workloads (OLTP applications) which
involve large, multiple, concurrent transactions. However, the performance of analytics and
reporting workloads are sometimes governed by the ability to quickly read very large amounts of
data for processing which is measured by the bandwidth indicator.
Bandwidth
Synonym for the data transfer rate and represents the amount of data that can be transferred in
a given time period. SSD bandwidth is usually measured and expressed in megabits per second
or gigabits per second (Mbps or Gbps).
When SQL Server needs to access large amounts of data (such as entire tables) for analytical
or report generation, it will attempt to read the largest sequential commands possible. In this
scenario, the storage device will receive a series of very large sequential commands that can
reach up to 256K per command. At this stage, the time it will take to complete such queries is
no longer governed by a maximal IOPS count (as each command is in itself very large) but rather
by the maximal bandwidth the SSD can produce. This will vary between manufacturers and
between models as the maximum bandwidth can be limited by the interface (SAS/SATA/PCIe),
by the power available to the SSD, by the controller(s) and by the internal handling of large data
sets by the SSD (such as striping large commands between NAND chips).
Buyer’s Guide | SQL Server Acceleration Flash Buyer’s Guide | V1.0 | © 2014 OCZ Storage Solutions 95.1 Testing flash performance specific to SQL Server workloads
While IOPS can help determine performance for transactional loads and bandwidth can help
determine flash performance for analytical loads, in day to day activities the performance boost
received through the use of flash is also dependent on other environment variables such as the
CPU, amount of memory, and the design of the actual queries being performed by SQL Server.
Therefore, the best measure for evaluating flash performance is to test with the specific SQL
Server data sets and queries of your environment.
If testing production data is not possible, standard benchmarks are available and can be
helpful in indicating flash performance under typical database loads. Commonly used standard
benchmark tests include TPC-C which simulates transactional loads and TPC-H which simulates
analytical loads. Many manufacturers can provide you with the results of their testing based
on these benchmarks and other tests. Using tools such as Hammer DB can help you generate
emulated benchmark loads against SQL Server instances.
6 What is the difference between flash volumes and flash
caching, and when to use each?
A flash volume is a portion of a PCIe flash card or SSD that is exposed as a volume to the operating
system so that data is written and read directly to flash. Flash volumes offer the highest possible
speed for both read and write operations as they use flash directly for every command. As a result,
flash volumes are particularly useful when both high write speeds and high read speeds are required
by the application. A typical example is the tempDB file.
When SQL Server does not have enough DRAM available, queries will automatically be written into a
tempDB file. As the memory clears up, data in the tempDB file will immediately be read. This write
operation followed shortly thereafter by a read operation of the tempDB file makes its performance
highly susceptible to both read and write speeds. If the tempDB file resides on a remote SAN, these
write and read operations can cause a considerable drop in SQL Server performance. Placing
tempDB files on local flash volumes provide an immediate boost in application performance.
A flash cache is a repository of flash memory storage that holds copies of certain portions of a
database stored on another media such as HDDs. The cache enables requests for data to be
fulfilled at greater speed and used in tandem with slower hard disk drives (HDDs) to improve data
access times. Cache can be located in a server, storage device or network, and requires time for it
to warm-up and populate. As more data enters the cache, more requests can be accelerated.
A good example for flash caching occurs with large databases that will not fit into flash volumes. As
database capacities grow beyond a certain point, it becomes are impractical or not cost-effective to
place the entire database on SSD flash. Even though database files can reach terabytes in size, only
the data within certain ‘hot zones’ needs to be frequently accessed. Storing only data from these
hot zones on flash cache allows for a major performance increase at a considerable cost savings.
Buyer’s Guide | SQL Server Acceleration Flash Buyer’s Guide | V1.0 | © 2014 OCZ Storage Solutions 10There are two major use cases that require a SQL Server environment to use flash caching:
When user databases are larger than the available flash resources
In this use case, flash caching offers an excellent avenue to accelerate performance with lower
amounts of flash when a caching algorithm is used that can select the right data to place on
flash from the larger databases on the HDD volumes. Caching selection algorithms that are
tailored to provide the highest benefit to a particular data access pattern are called optimized
caching policies. It is useful to differentiate between transactional and analytical loads when
caching data as their access patterns are very different, requiring each to have its own optimized
caching policy.
When enterprise environments use legacy SAN backup and High Availability functions
In this use case, it is important to use write-through caching as it ensures that the data on the
SAN always contains the latest data and is safe for backup and High Availability (HA) purposes.
When an enterprise environment depends on its legacy SAN for backup and HA, caching will
provide a way to benefit from flash while retaining all current procedures.
While all-flash volumes provide the fastest performance, flash caching lowers CAPEX and OPEX
by combining smaller amounts of flash with less costly HDDs. Selecting a flash solution that
can easily shift between flash volumes and flash caching, or uses both modes concurrently for
different databases, will future-proof the SQL Server environment for data growth.
7 What kinds of SQL Server data should I place on flash?
SQL Server stores its databases in files, of which, the two most common are the main database file
and the log file. TempDB files represent a third type of database file and discussed in Section V.
Log Files
These files are write-intensive with heavy reading occurring only when transactions need to be
reconstructed due to an external event such as a power failure. For this reason, write-through
caching (which accelerates reads but not writes) is not effective for use with log files. To
accelerate log files, place them on a flash volume but make sure to maintain High Availability
(HA) on this volume (e.g. with mirroring) to assure that the log file will not be lost if a flash failure
occurs.
Main Database Files
The main database files are usually more balanced in terms of reads and write with actual
read and write ratios dependent on the workload. When SQL Server requires a page from
the database, it can load it into memory much faster if that page is on flash rather than on an
HDD. As a performance guideline, the higher the probability that a page will be in flash when it
is needed by SQL Server, the better SQL Server performance will be. This is typically measured
by a metric called the hit ratio, or the percentage of time a request from SQL Server can be
Buyer’s Guide | SQL Server Acceleration Flash Buyer’s Guide | V1.0 | © 2014 OCZ Storage Solutions 11answered by data in flash rather than SQL Server having to fetch the data from HDD storage.
To improve hit ratios, the caching software needs to statistically process the data in real-time and
intelligently select whether specific data elements are worth caching. However, the more analysis
that the software performs in real-time, the higher the interference incurred on the data path,
resulting in the classic data path design dilemma:
• If too much time is spent on deciding whether to cache a data element as it flows through the
data path, data access to SSD flash can be slowed down.
• If too little time is spent on deciding whether to cache a data element as it flows through the data
path, it’s possible that the data cached will be useless to the application, or even worse, critical
data can be flushed out of the cache.
Caching performance can be improved when a system uses out-of-band processing to select what
data to cache.
8 What capabilities verify data will be available on flash for
SQL Server?
Enterprise applications such as SQL Server are extremely vulnerable to cache policy optimization as
they dynamically handle large amounts of data of constantly shifting importance. Data that is critical
to cache at one point in time may be useless at another, and the selection of the best data to cache
at each point in time is highly dependent on current access statistics.
To assure high hit ratios, there are four basic methods to select data to be cached on flash.
Hot Zone Detection
A mechanism that pinpoints frequently accessed data locations in SSD flash volumes to help
determine what data to cache and its relevance. The key to accelerating SQL Server is figuring
out what data is important and worth caching so that the data on SSD flash is quickly accessible
and relevant to the needs of the application. This method relies on optimized caching policies to
determine the data to cache based on how ‘hot’ the data is. A smart caching mechanism can
detect where indexes are located within a file by monitoring the number of accesses to a zone.
The located hot zones can then be used to determine what data is worth storing on the flash.
Sequentiality Detection
This data cache selection mechanism differentiates between relevant and irrelevant data access
patterns and can filter out background processing tasks (such as error checking) to prevent
irrelevant data from entering the cache. On the other hand, important sequential patterns (such
as index creation) may be marked for special handling in the cache.
Buyer’s Guide | SQL Server Acceleration Flash Buyer’s Guide | V1.0 | © 2014 OCZ Storage Solutions 12Command-size Inspection
Commands are differentiated by their command size and reflect the amount of data that needs
to be passed to or from an SSD. Inspecting the command sizes being generated by SQL Server
enables differentiation between different types of data usages.
Cache Analysis and Warm-up
While hot zone detection is effective for transactional processing throughout the day, analytical
processing requires a different method for selecting data to cache. Analytical processing often
involves a periodic batch process that requires accessing specific types of data. For example,
a SQL Server instance may be collecting sales data throughout the day, but at night, a report
generation process may be collecting data from different sources to help develop a complete
sales report comparing the day’s sales activities to previous periods.
In this scenario, hot zone detection will not be helpful for this type of analytics because the data
being accessed is not the same data that was hot during the day. To achieve high hit ratios for
analytics requires data access analysis and a pre-warming cache mechanism. Data access
analysis monitors the data being accessed during a certain period of the day (in the example
above it would monitor what data is accessed for report generation). After an analysis of the
required data is performed, a pre-warming cache mechanism fetches this data just before
generating the report verifying that the data is on flash at the precise time SQL Server needs it.
9 What parameters should I consider if my SQL Server
instances are virtualized?
Whether or not your SQL Server implementation is virtualized today, at some point in the future,
some or all of the SQL Server instances may need to move to a virtualized environment. Selecting
a flash acceleration solution that supports both virtualized and non-virtualized environments enables
the flexibility to deploy SQL Server in either of these modes.
Accelerating a virtualized SQL Server instance is similar in many respects to accelerating a physical
SQL Server instance however there are a few additional considerations that must be taken into
account when deploying flash into a virtualized environment.
Flash Resource Sharing
If the virtual environment includes multiple instances of SQL Server virtual machines (VMs)
running concurrently, as well other application VMs that can benefit from flash resources as well,
look for a solution that enables intelligent and efficient distribution of flash resources between all
connected VMs. Additionally, when the solution allows you to virtualize flash as a highly available
network-exposed resource, the flash can be shared amongst any VM in the cluster regardless
of location making sure that no VM inefficiently occupies flash when it can be better used
elsewhere in the environment.
Buyer’s Guide | SQL Server Acceleration Flash Buyer’s Guide | V1.0 | © 2014 OCZ Storage Solutions 13High Availability Support
One of the main reasons for deploying virtualization is the ability to provide High Availability (HA)
should a server running the SQL Server virtual machine (VM) go offline for any reason. Therefore,
users should look for flash acceleration solutions that either support SQL Server’s native High
Availability Always On Technology when deployed virtually or supports a virtualization platform’s
HA functionality such as VMware High Availability.
Virtual Machine Migration
While virtual machines (VMs) can migrate between physical servers in a cluster, flash is a
physical resource that resides in a particular location in the enterprise. If the chosen solution
does not allow exposing flash over the network, once a VM is migrated to a new server, it will
lose connectivity to its flash cache, and that source application will experience a sharp drop
in performance until data is reloaded over time to the new cache. Therefore, look for a flash
solution that enables the dynamic migration of a VM from one storage system to another, with
no VM downtime, service disruption or loss of cache to end-users.
Remote Flash Access
In some cases, SQL Server will run on remote servers while the flash resources are located
remotely on either a different commodity server or storage appliance. Therefore, look for a
flash solution that provides a connection from SQL Server to its flash resources remotely and
can relocate SQL Server files to remote flash volumes, remote flash caching or a combination
of both enabling SQL Server virtual machines (VMs) to continue enjoying the benefits of flash
acceleration even when migrated between servers.
10 What native flash functionality does SQL Server 2014
provide?
Recognizing the importance of flash for performance acceleration of SQL Server environments,
Microsoft has added flash buffer pool extension (BPE) support to the SQL Server 2014 version
release. Buffer Pool Extensions allow SQL Server users to define a file residing on flash so that the
SQL Server instance can extend its memory buffer to flash. SQL Server uses the flash file to store
clean buffer pages that it has no room for in memory. Assuming these pages will be needed by SQL
Server again, they can be fetched faster by loading them directly from the flash buffer pool extension
rather than from the database files.
While it is important to make sure that the flash acceleration solution supports SQL Server 2014
Buffer Pool Extensions, it is also important to select a solution that extends and enhances the
capabilities provided by BPE. For example, native BPE support can be activated at the SQL Server
Instance level but cannot differentiate between different databases running in the environment.
Therefore, to make sure that the flash is used to accelerate a key database critical for performance
(without the flash being hogged by a less important but larger database), look for a solution that can
selectively differentiate between databases and accelerate at a per database level.
Buyer’s Guide | SQL Server Acceleration Flash Buyer’s Guide | V1.0 | © 2014 OCZ Storage Solutions 14Analytical loads are another key area in which the Microsoft BPE functionality can be extended by
acceleration software. In this scenario, the BPE mechanism relies on data being accessed before
loading it into the flash buffer extension. Therefore, if the data is only accessed one time each night
(e.g. for nightly report generation), it will most likely not be in the flash when SQL Server requires
it. If analytics are used with such recurring processes, look for a solution that provides analysis
and warm-up scheduling to assure the data is loaded into the flash just before it is needed by the
application.
11 How can flash improve SQL Server ETL processes?
As it relates to managing databases, Extract/Transform/Load (ETL) refers to three separate functions
that are combined into a single programming tool and can be used to acquire a temporary subset of
data for reports or other purposes or a more permanent data set for the population of a data mart
or data warehouse, the conversion from one database type to another, or the migration of data from
one database or platform to another. Each process has a very distinct function as follows:
Extract
This function reads data from a specified source database and extracts a desired subset of data
Transform
This function works with the acquired data, using rules or lookup tables, to convert it to the
desired state
Load
This function writes the resulting data (either all of the subset or just the changes) to a target
database, which may or may not previously exist
Depending on the size of data and database files, the ETL process can be long and time consuming.
Look for a flash solution that has the ability to partition its flash for use as a flash volume, flash cache
or a hybrid of both. The ability to partition flash volumes provide an optimized solution where the
write log and tempDB data files benefit from high flash performance while hot areas of the database
are flash cached for immediate use by SQL Server. The result enables all SQL Server data types to
be optimized and accelerated.
A flash solution that enables write-through caching functionality will allow you to load that data into
flash as it is being loaded into an underlying database. When used as a mirrored volume for the ETL
process, the most current data will already be cached on flash in the secondary replica significantly
reducing ETL run times.
Buyer’s Guide | SQL Server Acceleration Flash Buyer’s Guide | V1.0 | © 2014 OCZ Storage Solutions 1512 How can implementation wizards affect the success of my
SQL Server acceleration project?
Many DBAs are expert in database administration but are not as experienced in deploying flash into
their enterprise environments, so simplifying the DBAs life through best practice guidelines for flash
implementation is a benefit. Based on a simple to use and intuitive graphical user interface (GUI),
implementation wizards are very helpful in guiding DBAs through a flash-based storage deployment.
Adding best practice models of the flash-based resources can also provide efficient acceleration and
quick plug-and-play set-up into existing SQL Server deployments.
Look for flash solutions with intuitive GUI management wizards that can:
• Divide the flash resource into a volume section and a cache section
• Advise on what data and workloads to place on the flash volume or on flash cache
• Provide a list of the database volumes so that optimized policies can be used whether the
workload is transactional or analytical
• Provide instructions on how to pre-warm the cache in advance of demanding and critical jobs
Buyer’s Guide | SQL Server Acceleration Flash Buyer’s Guide | V1.0 | © 2014 OCZ Storage Solutions 1613 Flash Buyer’s Checklist
Category Functionality Solution A Solution B
In-Server Installation (PCIe, SAS/
SATA )
Supported Form Factors
External Appliance Support
Random Read IOPS at 8K
Random Write IOPS at 8K
Max Read Bandwidth
Performance
Max Write Bandwidth
Benchmark Performance (TPC-C,
TPC-H, etc.)
Performance under my test load
Flash Volume Support
Usage Mode Flash Cache Support
Flexible concurrent usage
Caching Policies for OLTP and
analytics
Data Accesses Analysis
Caching Functionality
Cache Warm-up Scheduling
Database Level Acceleration
Flash Resource Sharing
Virtualization Support High Availability Support
VM Migration and Remote Caching
Support BPE
SQL Server 2014 Flash BPE Enhancements
Implementation Wizards
SQL Server Management
Integration
Deployment and Management
Central Management for multiple
servers
Buyer’s Guide | SQL Server Acceleration Flash Buyer’s Guide | V1.0 | © 2014 OCZ Storage Solutions 1714 Introducing OCZ’s ZD-XL SQL Accelerator
ZD-XL SQL Accelerator is a tightly integrated hardware/software, plug-and-play acceleration solution
optimized for Microsoft SQL Server applications. It leverages OCZ’s industry-proven PCIe SSD
hardware and application-tuned software to deliver low latency flash that resolves potential SQL
Server bottleneck issues enabling the flash to be deployed as a local flash volume, a flash cache
for HDD volumes, or as a combination of both. The solution includes a combination of fast flash
performance, a unique cache mechanism that makes advanced and statistically-optimized decisions
on what data to cache, and a dynamic cache warm-up scheduler that enables workloads to be
placed on flash cache in advance of demanding and critical jobs.
This advanced PCIe accelerator card utilizes implementation wizards and step-by-step instructions
to guide database administrators (DBAs) through the deployment process enabling best practice
models of its flash-based resources to be simply and quickly set-up for efficient SQL Server
acceleration. The intuitive GUI also divides the ZD-XL SQL Accelerator SSD resource into a volume
section and cache section, advising DBAs on what data and workloads to place on flash. It also
provides a list database volumes enabling DBAs to simply select the optimized policy to use on each
workload and instructs them on how to pre-warm the cache in advance.
Additionally, ZD-XL SQL Accelerator provides complete High Availability (HA) via Microsoft AlwaysOn
Technology so not only can SQL Server environments function at the speed of flash, but in the event
of planned or unplanned downtime, can continue operations from the stopping point retaining all
of its data as if no downtime had occurred. With this level of functionality and performance, OCZ’s
initial ZD-XL SQL Accelerator release earned prominent reviews as well as the 2013 Best of Interop®
award in the Data Center & Storage category.
In support of SQL Server 2014, ZD-XL SQL Accelerator enables its flash resources and associated
management capabilities to connect directly to the application providing the utmost in application
management integration. This tight integration of flash and application management enables ZD-XL
SQL Accelerator to accelerate the application at a per database level versus having to accelerate all
of the databases in the SQL Server instance.
SQL Server can run on blade servers or specific rack-mounted servers except that the PCIe form
factor does not fit making flash acceleration more difficult. OCZ enables flash acceleration for these
instances by running ZD-XL SQL Accelerator software next to the database application on blade
or rack-mounted servers while the SSD flash is located remotely on either a commodity server or
storage appliance. As a result, ZD-XL SQL Accelerator software provides a direct connection from
SQL Server to its flash resources remotely.
Many enterprises benefit from the capability of running SQL Server in a virtualized environment. For
these applications, ZD-XL SQL Accelerator supports both VMware ESXi and Microsoft Hyper-V
hypervisors enabling its flash resources to be deployed exactly to the needs of VMs while retaining
the application connection in the virtualized environment.
Buyer’s Guide | SQL Server Acceleration Flash Buyer’s Guide | V1.0 | © 2014 OCZ Storage Solutions 18Contact us for more information OCZ Storage Solutions 6373 San Ignacio Avenue San Jose, CA 95119 USA P 408.733.8400 E sales@oczenterprise.com W ocz.com/enterprise EMAIL SALES TEAM VISIT OCZ ENTERPRISE Disclaimer OCZ may make changes to specifications and product descriptions at any time, without notice. The information presented in this document is for informational purposes only and may contain technical inaccuracies, omissions and typographical errors. Any performance tests and ratings are measured using systems that reflect the approximate performance of OCZ products as measured by those tests. Any differences in software or hardware configuration may affect actual performance, and OCZ does not control the design or implementation of third party benchmarks or websites referenced in this document. The information contained herein is subject to change and may be rendered inaccurate for many reasons, including but not limited to any changes in product and/or roadmap, component and hardware revision changes, new model and/or product releases, software changes, firmware changes, or the like. OCZ assumes no obligation to update or otherwise correct or revise this information. OCZ MAKES NO REPRESENTATIONS OR WARRANTIES WITH RESPECT TO THE CONTENTS HEREOF AND ASSUMES NO RESPONSIBILITY FOR ANY INACCURACIES, ERRORS OR OMISSIONS THAT MAY APPEAR IN THIS INFORMATION. OCZ SPECIFICALLY DISCLAIMS ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR ANY PARTICULAR PURPOSE. IN NO EVENT WILL OCZ BE LIABLE TO ANY PERSON FOR ANY DIRECT, INDIRECT, SPECIAL OR OTHER CONSEQUENTIAL DAMAGES ARISING FROM THE USE OF ANY INFORMATION CONTAINED HEREIN, EVEN IF OCZ IS EXPRESSLY ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. ATTRIBUTION © 2014 OCZ Storage Solutions, Inc. – A Toshiba Group Company. All rights reserved. OCZ, the OCZ logo, OCZ XXXX, OCZ XXXXX, [Product name] and combinations thereof, are trademarks of OCZ Storage Solutions, Inc. – A Toshiba Group Company. All other products names and logos are for reference only and may be trademarks of their respective owners. Buyer’s Guide | SQL Server Acceleration Flash Buyer’s Guide | V1.0 | © 2014 OCZ Storage Solutions 19
You can also read
