Nimble Storage SQL Server
Nimble Storage SQL Server
Summary
Microsoft SQL Server databases provide the data storage back end for mission-critical applications.
Therefore, its critical to protect these applications to ensure data integrity and availability for
transaction processing. Nimble Storage arrays provide I/O optimization and protection features that
greatly benefit SQL Server implementations.
It is important to first understand some of the internal I/O processes that SQL Server uses to store data
on disk. Then you can use this fundamental understanding to implement best practices for provisioning
a database storage design that will optimize performance and eliminate database backup windows.
Using these best practices can also dramatically reduce recovery time objectives for full databases as
well as individual database objects and data after user error and system failures.
Customers Table
CustomerID First Name
Last Name
89437392
John
Smith
27485839
Diane
Jones
75839544
Ellen
Davis
33258837
John
Smith
61382475
Roger
Williams
hundreds of tables that store specific types of information such as Customers, Products, Orders, etc.
Over time our database will grow as we add more data to the tables. It is important to plan and monitor
our database to provide the quickest response time to the end-users and to ensure that we properly
protect the data assets from loss.
Write-Ahead Logging (WAL)
To reduce the risk of data loss, Microsoft SQL Server writes data to disk using the Write-Ahead Logging
(WAL) algorithm which is common to all major database platforms. The algorithm is designed as a failsafe process that ensures that interrelated database changes are written completely as a single logical
unit of work that can be undone if any of the individual changes fails for any reason. WAL adds a
transaction log file to the write process to act as a witness to the database changes that will take place
and add a layer of protection ensuring that two files have to agree before the data can be trusted.
Management of a volume collection allows you to quickly change protection schedules for all related
volumes. For example, suppose that you have created a SQL Server database protection schedule for
several databases on a SQL Server supporting an eCommerce application. It is common for databases
to be partitioned into different data files with differing performance characteristics. The initial business
requirements called for a configuration based on hourly snapshots for backup and replication off-site
every six hours for disaster recovery. As business has increased, management has decided that the
database has become more critical and thus needs more frequent backup and more frequent
replication to reduce potential data loss. You can change the protection schedule for all of the
associated files for the database at the same time by changing the Volume Collection properties, thus
saving time and eliminating configuration errors that might inhibit recoverability.
Prefer Hardware Snapshots versus Software and SQL Server Snapshots
Snapshots are the basis for creating point-in-time versions of storage volumes and backups that can
be mounted and accessed just like any other iSCSI volume. You can create snapshots at different
layers of virtualization architectures, including within the Guest Software, within the Host Software and
within the Storage Hardware. Connecting data volumes directly to the guest allows NPM to trigger
snapshots that use the Nimble Storage hardware provider rather than inefficient software-based
snapshots.
Nimble Storage arrays provide highly efficient hardware snapshot functionality that is optimized by
Nimbles inline compression and block incremental efficiencies. This differs from operating system
native software snapshots such as Microsoft VSS, which are not efficiently stored within their
volumes. Software snapshots dont take advantage of Nimble Storage array optimized snapshot
backup functionality. The following diagram shows the differing locations in which snapshots are
stored. It is preferable to use hardware-based snapshots in the Nimble Storage array that take
advantage of performance, in-line compression, and cloning capabilities rather than performing
software snapshots with far less flexibility.
Beginning with SQL Server 2005 Enterprise, SQL Server also contains snapshot features that require
SQL scripting skills. These types of SQL Server application-native snapshots are stored within the
database files and use copy-on-write methodology that is very inefficient when compared with Nimble
Storage array snapshot backups. Using Nimble Storage arrays, Database Administrators can perform
database snapshots much more frequently and with more granular recovery points. These maintain the
same recovery methods available as SQL-native snapshots. Using Nimble array snapshots for
restoration, reporting, and other use cases is covered in the Better SQL Server Recovery section.
Better SQL Server Backups
SQL Server databases use the Write Ahead Logging algorithm to protect against system failure, and
Nimble Storage arrays are hardware redundant to protect against storage failure. However, databases
should be backed up from time to time to protect against logical failures such as accidental deletion of
data. SQL Server provides several native features for backup and you can take advantage of Nimble
Storage arrays for enhanced snapshot backup to avoid interruption of service.
The following timelines and graphs show the relative impacts of the different SQL Server backup and
restoration methodologies after a database failure. These demonstrate the recovery point and recovery
time associated with restoring a database back to full service. These timelines make certain
assumptions that the hardware, operating system, and application software are unaffected by the
outage and that the database failed because of a logical failure; an erroneous deletion of tables or
files, for example. The system load metric is a composite of total production system involvement in the
backup process, which includes the CPU, Memory, System Bus, Network, and Storage sub-system.
Production database processing must compete with the system load imposed by the backup process,
and reduces the transaction processing performance.
SQL Server Backup to Disk or Tape
The Traditional Backup to Disk/Tape timeline shows a typical daily backup schedule which performs a
full daily database backup followed by hourly transaction log backups. We can see that the system load
is high during the full backup when entire database and transaction log are copied to a backup disk or
tape device. Later we see spikes hourly when the transaction log backup copies are made. Finally, the
transaction logs are truncated on the successful completion of either the full or transaction log backup.
Recovery of a database begins with restoration of the most recent successful full backup, followed by
restoration of each transaction log backup. The restoration time is considerable because all database
objects (Tables, Indexes, Security, etc.) must be copied from the backup media to the server. Thus, if it
takes 5 hours to back up, then it will take at least 5 hours to restore. Transaction logs are cumulative,
so they can be restored as soon as the previous log completes restoration.
Nimble Storage arrays are optimized to perform full database snapshot backups that minimize the
impact on the production system. The Nimble array integrates with Microsoft VSS using Nimble
Protection Manager (NPM) to periodically request the database to flush pending database writes to
disk. Then the array creates an optimized snapshot. Recovery of a database using Nimble Storage
snapshots is a very quick process in which an administrator creates a clone of the snapshot and
mounts it directly for data restoration.
SQL Server Database Recovery Models
SQL Server database recovery models were created to simplify the administration of databases. Its
important to understand recovery models, because they affect your backup process. There are three
recovery models available, Full, Bulk-Logged, and Simple. The primary differences between the
recovery models are whether or not transactions are logged and if they truncate the transaction log
when a checkpoint occurs. A checkpoint is marked in the transaction log after all database changes
have been written to disk.
Nimble Snapshot Backups for Simple Recovery Model Databases
For most SQL Server protection scenarios, the simple recovery
model provides the best combination of management simplicity
between Nimble snapshot backups then you must use the SQL Server Full Recovery Model.
Database applications. To minimize the impact of an error during a bulk-logged operation, you should
always perform a backup using the methods appropriate for the recovery model that your database
uses if it is not always in the Bulk-Logged Recovery model.
10
Data Restoration
This works similarly to Database Object Restoration but uses a SQL query that restores certain data
points that were lost due to user error, for example, the recovery of an accidental Order deletion in an
ERP or CRM database from a recent snapshot backup.
update ProductionDB.dbo.Customer
set LastName = (
select LastName
from RecoveryDB.dbo.LastName
where CustomerID = 8309485)
where CustomerID = 8309485
11
12