SQL DB Toc Fromms01

Table of Contents
Overview
What's New - SQL Server 2017
What's New - SQL Server 2016
Release notes
Backward compatibility
Deprecated features in SQL Server 2017
Deprecated in SQL Server 2016
Discontinued functionality in SQL Server 2016
Breaking changes in SQL Server 2017
Breaking changes in SQL Server 2016
New and updated articles
Install
Configure
High availability
Availability groups
Database mirroring
Log shipping
SQL Server Database Engine
11/20/2017 • 1 min to read • Edit Online
THIS TOPIC APPLIES TO: SQL Server (starting with 2016) Azure SQL Database Azure SQL Data
Warehouse Parallel Data Warehouse
The Database Engine is the core service for storing, processing, and securing data. The Database Engine provides
controlled access and rapid transaction processing to meet the requirements of the most demanding data
consuming applications within your enterprise.
Use the Database Engine to create relational databases for online transaction processing or online analytical
processing data. This includes creating tables for storing data, and database objects such as indexes, views, and
stored procedures for viewing, managing, and securing data. You can use SQL Server Management Studio to
manage the database objects, and SQL Server Profiler to capture server events.
See Also
SQL Server Resource Center
What's new in Database Engine - SQL Server 2017
THIS TOPIC APPLIES TO: SQL Server (starting with 2017) Azure SQL Database Azure SQL Data Warehouse
Parallel Data Warehouse
This topic describes improvements made to the SQL Server Database Engine for SQL Server 2017. Click the links
for more information on each item.
NOTE
SQL Server 2017 also includes the features added in SQL Server 2016 service packs. For those items, see What's New in SQL
Server 2016 (Database Engine).
Enhancements
CLR uses Code Access Security (CAS) in the .NET Framework, which is no longer supported as a security
boundary. A CLR assembly created with PERMISSION_SET = SAFE may be able to access external system
resources, call unmanaged code, and acquire sysadmin privileges. Beginning with SQL Server 2017, an
sp_configure option called clr strict security is introduced to enhance the security of CLR assemblies.
clr strict security is enabled by default, and treats SAFE and EXTERNAL_ACCESS assemblies as if they were
marked UNSAFE . The clr strict security option can be disabled for backward compatibility, but this is not
recommended. Microsoft recommends that all assemblies be signed by a certificate or asymmetric key with a
corresponding login that has been granted UNSAFE ASSEMBLY permission in the master database. CLR assemblies
can be added to a whitelist, as a work-around for the clr strict security feature. sp_add_trusted_assembly,
sp_drop_trusted_assembly, and sys.trusted_asssemblies are added to support the white list of trusted
assemblies. For more information, see CLR strict security.
A new, DMF sys.dm_db_log_stats, is introduced to expose summary level attributes and information on
transaction log files; useful for monitoring the health of the transaction log.
Resumable online index rebuild. Resumable online index rebuild allows you to resume an online index rebuild
operation from where it stopped after a failure (such as a failover to a replica or insufficient disk space). You can
also pause and later resume an online index rebuild operation. For example, you might need to temporarily free
up systems resources in order to execute a high priority task or complete the index rebuild in another
maintenance window if the available maintenance windows is too short for a large table. Finally, resumable
online index rebuild does not require significant log space, which allows you to perform log truncation while the
resumable rebuild operation is running. See ALTER INDEX and Guidelines for online index operations.
IDENTITY_CACHE option for ALTER DATABASE SCOPED CONFIGURATION. A new option IDENTITY_CACHE
was added to ALTER DATABASE SCOPED CONFIGURATION T-SQL statement. When this option is set to OFF , it allows
the Database Engine to avoid gaps in the values of identity columns in case a server restarts unexpectedly or
fails over to a secondary server. See ALTER DATABASE SCOPED CONFIGURATION.
SQL Server now offers graph database capabilities to model more meaninginful relationship-oriented data. This
includes new CREATE TABLE syntax for creating node and edge tables, and the keyword MATCH for queries. For
more information, see Graph Processing with SQL Server 2017.
A new generation of query processing improvements that will adapt optimization strategies to your application
workload’s runtime conditions. For this first version of the adaptive query processing feature family, we have
three new improvements: batch mode adaptive joins, batch mode memory grant feedback, and
interleaved execution for multi-statement table valued functions. See Adaptive query processing in SQL
databases.
Automatic tuning is a database feature that provides insight into potential query performance problems,
recommend solutions, and automatically fix identified problems. Automatic tuning in SQL Server, notifies you
whenever a potential performance issue is detected, and lets you apply corrective actions, or lets the Database
Engine automatically fix performance problems. For more information, see Automatic tuning.
PERFORMANCE ENHANCEMENT FOR NON CLUSTERED INDEX BUILD ON MEMORY-OPTIMIZED TABLES.
Performance of bwtree (non-clustered) index rebuild for MEMORY_OPTIMIZED tables during database recovery
has been significantly optimized. This improvement substantially reduces the database recovery time when non-
clustered indexes are used.
sys.dm_os_sys_info has three new columns: socket_count, cores_per_socket, numa_node_count. This is useful
when you run your server in a VM, as exceding NUMA can lead overcommited hosts that in the end transforms
to performance issues.
A new column modified_extent_page_count, is introduced in sys.dm_db_file_space_usage to track differential
changes in each database file of the database. The new column modified_extent_page_count allows you to build
smart backup solution, which performs differential backup if percentage changed pages in the database is below
a threshold (say 70-80%) else perform full database backup.
SELECT INTO … ON FileGroup - SELECT INTO now supports loading a table into a filegroup other than a default
filegroup of the user using the ON keyword support added in SELECT INTO TSQL syntax.
Tempdb Setup Improvements - The setup allows specifying initial tempdb file size up to 256 GB (262,144 MB)
per file with a warning to customers if the file size is set to value greater than 1 GB and if IFI is not enabled. It is
important to understand the implication of not enabling instant file initialization (IFI) where setup time can
increase exponentially depending on the initial size of tempdb data file specified. IFI is not applicable to
transaction log size so specifying larger value of transaction log can invariably increase the setup time while
starting up tempdb during setup irrespective of the IFI setting for SQL Server service account.
A new dmv sys.dm_tran_version_store_space_usage is introduced to track version store usage per database.
This new dmv is useful in monitoring tempdb for version store usage for you to proactively plan tempdb sizing
based on the version store usage requirement per database without any performance toll or overheads of
running it on production servers.
A new DMF sys.dm_db_log_info is introduced to expose the VLF information similar to DBCC LOGINFO to
monitor, alert, and avert potential transaction log issues caused due to number of VLFs, VLF size or shrinkfile
issues experienced by customers.
Improved Backup performance for small databases on high end servers - While performing backup of databases
in SQL Server, the backup process requires multiple iterations of buffer pool to drain the on-going I/Os. As a
result, the backup time is not just the function of database size but also a function of active buffer pool size. In
SQL Server 2017, the backup is optimized to avoid multiple iterations of buffer pool resulting in dramatic gains
in backup performance for small to medium databases. The performance gain reduces as the database size
increases as the pages to backup and backup IO takes more time compared to iterating buffer pool.
Query Store now tracks wait stats summary information. Tracking wait stats categories per query in Query Store
enables the next level of performance troubleshooting experience, providing, even more, insight into the
workload performance and its bottlenecks while preserving the key Query Store advantages.
System-versioned temporal tables now support CASCADE DELETE and CASCADE UPDATE.
Indirect checkpoint performance improvements.
Cluster-less Availability Groups support added.
Minimum Replica Commit Availability Groups setting added.
Availability Groups can now work across Windows-Linux to enable cross-OS migrations and testing.
Temporal Tables Retention Policy support added,
New DMV SYS.DM_DB_STATS_HISTOGRAM
Online non-clustered columnstore index build and rebuild support added
sys.dm_db_stats_histogram (Transact-SQL) is added for examining statistics.
The Database Tuning Advisor (DTA) released with SQL Server Management Studio version 16.4, when analyzing
SQL Server 2016 and later, has additional options.
Improved performance. For more information, see Performance Improvements using Database Engine
Improved performance. For more information, see Performance Improvements using Database Engine
Tuning Advisor (DTA) recommendations.
The -fc option for allowing recommendations of columnstore indexes. For more information, see DTA
Utility and Columnstore index recommendations in Database Engine Tuning Advisor (DTA).
The -iq option for allowing the DTA to review a workload from the Query Store. For more information,
see Tuning Database Using Workload from Query Store.
For In-Memory functionality, additional enhancements to memory-optimized tables and natively compiled
functions are available. For code samples that illustrate these enhancements, see Optimize JSON processing
with in-memory OLTP.
Support for computed columns in memory-optimized tables, including indexes on computed columns.
Full support for JSON functions in natively compiled modules, and in check constraints.
CROSS APPLY operator in natively compiled modules.
New string functions CONCAT_WS, TRANSLATE, and TRIM are added.
The WITHIN GROUP clause is now supported for the STRING_AGG function.
Two new Japanese collation families (Japanese_Bushu_Kakusu_140 and Japanese_XJIS_140) were added, and
the collation option Variation-selector-sensitive (_VSS) was added for use in these new Japanese collations. Also,
all of the new collations automatically support supplementary characters without needing to specify the _SC
option. For more detail see Collation and Unicode Support
New bulk access options (BULK INSERT and OPENROWSET(BULK...)) enable access data directly from a file
specified as CSV format, and from files stored in Azure Blob storage through the new BLOB_STORAGE option of
EXTERNAL DATA SOURCE.
Database COMPATIBILITY_LEVEL 140 has been added. Customers running in this level will get the latest
language features and query optimizer behaviors. This includes changes in each pre-release version Microsoft
releases.
Improvements to the way incremental statistics update thresholds are computed (140 compatibility mode
required).
sys.dm_exec_query_statistics_xml is added.
We have made several performance and language enhancements to Memory-Optimized objects:
sp_spaceused is now supported for memory-optimized tables.
sp_rename is now supported for memory-optimized tables and natively compiled T-SQL modules.
CASE expressions are now supported for natively compiled T-SQL modules.
The limitation of 8 indexes on memory-optimized tables has been eliminated.
TOP (N) WITH TIES is now supported in natively compiled T-SQL modules.
ALTER TABLE against memory-optimized tables is now usually substantially faster.
Transaction log redo of memory-optimized tables is now done in parallel. This bolsters faster recovery
times and significantly increases the sustained throughput of AlwaysOn availability group configuration.
Memory-optimized filegroup files can now be stored on Azure Storage. Backup/Restore of memory-
optimized files on Azure Storage is also available now.
Clustered Columnstore Indexes now support LOB columns (nvarchar(max), varchar(max), varbinary(max)).
The STRING_AGG aggregate function has been added.
New Permissions: DATABASE SCOPED CREDENTIAL is now a class of securable, supporting CONTROL , ALTER ,
REFERENCES , TAKE OWNERSHIP , and VIEW DEFINITION permissions. ADMINISTER DATABASE BULK OPERATIONS , which is
restricted to SQL Database, is now visible in sys.fn_builtin_permissions .
The sys.dm_os_host_info DMV is added to provide operating system information for both Windows and Linux.
The database roles are created with R Services for managing permissions associated with packages. For more
information, see R Package management for SQL Server.
What's new in Database Engine - SQL Server 2016
This topic summarizes the enhancements introduced in the SQL Server 2017 release of the SQL Server Database
Engine. The new features and enhancements increase the power and productivity of architects, developers, and
administrators who design, develop, and maintain data storage systems.
To review what is new in the other SQL Server components, see What's New in SQL Server 2016.
NOTE
SQL Server 2016 is a 64-bit application. 32-bit installation is discontinued, though some elements run as 32-bit components.
Try it out
To download SQL Server 2016, go to Evaluation Center .
Have an Azure account? Then go Here to spin up a Virtual Machine with SQL Server 2017 already installed.
NOTE
For the current release notes, see SQL Server 2016 Release Notes.
SQL Server 2016 Service Pack 1 (SP1)

CREATE OR ALTER <object> syntax is now available for procedures, views, functions, and triggers.
Support for a more generic query hinting model has been added: OPTION (USE HINT('<hint1>', '<hint2>')) . For
more information, see Query Hints (Transact-SQL).
The sys.dm_exec_valid_use_hints DMV is added to list hints.
The sys.dm_exec_query_statistics_xml DMV is added to return showplan XML transient statistics.
The sys.dm_db_incremental_stats_properties DMV is added to incremental statistics for the specified table.
The instant_file_initialization_enabled column is added to sys.dm_server_services.
The of estimated_read_row_count column is added to sys.dm_exec_query_profiles.
The sql_memory_model and sql_memory_model_desc columns are added to sys.dm_os_sys_info to provide
information about the locking model for memory pages.
The editions that support a number of features has been expanded. This includes adding row-level security,
Always Encrypted, dynamic data masking, database auditing, in-memory OLTP and several other features to all
editions. For more information see Editions and Supported Features for SQL Server 2016.
sp_refresh_parameter_encryption allows Always On encryption to update metadata, when objects encrypted
using Always On are redefined.
SQL Server 2016 RTM

This section contains the following subsections:
Columnstore Indexes
Database Scoped Configurations
In-Memory OLTP
Query Optimizer
Live Query Statistics
Query Store
Temporal Tables
Striped Backups to Microsoft Azure Blob Storage
File-Snapshot Backups to Microsoft Azure Blob Storage
Managed Backup
TempDB Database
Built-in JSON Support
PolyBase
Stretch Database
Support for UTF-8
New Default Database Size and Autogrow Values
Transact-SQL Enhancements
System View Enhancements
Security Enhancements
High Availability Enhancements
Replication Enhancements
Tools Enhancements
Columnstore Indexes
This release offers improvements for columnstore indexes including updateable nonclustered columnstore indexes,
columnstore indexes on in-memory tables, and many more new features for operational analytics.
A read-only nonclustered columnstore index is updateable after upgrade. A rebuild of the index is not
required to make it updateable.
There are performance improvements for analytics queries on columnstore indexes, especially for
aggregates and string predicates.
DMVs and XEvents have supportability improvements.
For more details, see these topics in the Columnstore Indexes Guide section of Books Online:
Columnstore Indexes Versioned Feature Summary – includes what’s new.
Columnstore Indexes Data Loading
Columnstore Indexes Query Performance
Get started with Columnstore for real time operational analytics
Columnstore Indexes for Data Warehousing
Columnstore Indexes Defragmentation
Database Scoped Configurations
The new ALTER DATABASE SCOPED CONFIGURATION (Transact-SQL) statement gives you control of certain
configurations for your particular database. The configuration settings affect application behavior.
The new statement is available in both SQL Server 2016 and SQL Database.
In-Memory OLTP
St o r a g e fo r m a t c h a n g e
The storage format for memory-optimized tables is changed between SQL Server 2014 and 2016. For upgrade and
attach/restore from SQL Server 2014, the new storage format is serialized and the database is restarted once
during database recovery.
Upgrade to SQL Server 2016
A LT ER T A BLE i s l o g-o pt i m i z ed, an d r u n s i n par al l el
Now when you execute an ALTER TABLE statement on a memory-optimized table, only the metadata changes are
written to the log. This greatly reduces log IO. Also, most ALTER TABLE scenarios now run in parallel, which can
greatly shorten the duration of the statement.
For non-parallel exceptions, including LOBs, see Altering Memory-Optimized Tables.
St a t i st i c s
Statistics for memory-optimized tables are now updated automatically. In addition, sampling is now a supported
method to collect statistics, allowing you to avoid the more expensive fullscan method.
P a r a l l e l a n d h e a p sc a n fo r m e m o r y - o p t i m i z e d t a b l e s
Memory-optimized tables, and indexes on memory-optimized tables, now support parallel scan. This improves the
performance of analytical queries.
In addition, heap scan is supported, and can be performed in parallel. In the case of a memory-optimized table, a
heap scan refers to scanning all the rows in a table using the in-memory heap data structure used for storing the
rows. For a full table scan, heap scan is more efficient than using an index.
T r a n sa c t - SQ L I m p r o v e m e n t s fo r m e m o r y - o p t i m i z e d t a b l e s
There are several Transact-SQL elements that were not supported for memory-optimized tables in SQL Server
2014, which are now supported in SQL Server 2016:
UNIQUE constraints and indexes are supported.
FOREIGN KEY references between memory-optimized tables are supported.
These foreign keys can reference only a primary key, and cannot reference a unique key.
CHECK constraints are supported.
A non-unique index can allow NULL values in its key.
TRIGGERs are supported on memory-optimized tables.
Only AFTER triggers are supported. INSTEADOF triggers are not supported.
Any trigger on a memory-optimized table must use WITH NATIVE_COMPILATION.
Full support for all SQL Server code pages and collations with indexes and other artifacts in memory-
optimized tables and natively compiled T-SQL modules.
Support for Altering Memory-Optimized Tables:
ADD and DROP indexes. Change bucket_count of hash indexes.
Make schema changes: add/drop/alter columns; add/drop constraint.
A memory-optimized table can now have several columns whose combined lengths are longer than the
length of the 8060 byte page. An example is a table that has three columns of type nvarchar(4000) . In such
examples, some columns are now stored off-row. Your queries are blissfully unaware of whether a column is
on-row or off-row.
LOB (large object) types varbinary(max) , nvarchar(max) , and varchar(max) are now supported in memory-
optimized tables.
For overall information, see:
Transact-SQL Constructs Not Supported by In-Memory OLTP
Unsupported SQL Server Features for In-Memory OLTP
T r a n sa c t - SQ L I m p r o v e m e n t s fo r n a t i v e l y c o m p i l e d m o d u l e s
There are some Transact-SQL elements that were not supported for natively compiled modules in SQL Server
2014, which are now supported in SQL Server 2016:
Query constructs:
UNION and UNION ALL
SELECT DISTINCT
OUTER JOIN
Subqueries in SELECT
INSERT, UPDATE and DELETE statements can now include the OUTPUT clause.
LOBs can now be used in the following ways in a native proc:
Declaration of variables.
Input parameters received.
Parameters passed into string functions, such as into LTrim or Substring, in a native proc.
Inline (meaning single statement) table-valued functions (TVFs) can now be natively compiled.
Scalar user-defined functions (UDFs) can now be natively compiled.
Increased support for a native proc to call:
Built-in security functions.
Built-in math functions.
Built-in function @@SPID .
EXECUTE AS CALLER is now support, which means the EXECUTE AS clause is no longer required when
creating a natively compiled T-SQL module.
For overall information, see:
Supported Features for Natively Compiled T-SQL Modules
Altering Natively Compiled T-SQL Modules
P e r fo r m a n c e a n d sc a l i n g i m p r o v e m e n t s
There is no longer any limitation on data size. See Estimate Memory Requirements for Memory-Optimized
Tables.
There are now multiple concurrent threads responsible to persist to disk the changes to memory-optimized
tables.
Parallel plan support for Accessing Memory-Optimized Tables Using Interpreted Transact-SQL.
En h a n c e m e n t s i n SQ L Se r v e r M a n a g e m e n t St u d i o
The Determining if a Table or Stored Procedure Should Be Ported to In-Memory OLTP no longer requires the
configuration of data collectors or management data warehouse. The report can now run directly on a
production database.
PowerShell Cmdlet for Migration Evaluation for evaluating the migration fitness of multiple objects in a SQL
Server database.
Generate migration checklists by right-clicking on a database, and selecting Tasks > Generate In-Memory
OLTP migration checklists.
C r o ss- fe a t u r e su p p o r t
Support for using temporal system-versioning with In-Memory OLTP. For more information, see System-
Versioned Temporal Tables with Memory-Optimized Tables
Query store support for natively compiled code from In-Memory OLTP workloads. For more information,
see Using the Query Store with In-Memory OLTP.
Row-Level Security in Memory-Optimized Tables
Using Multiple Active Result Sets (MARS) connections can now access memory-optimized tables and
natively compiled stored procedures.
Transparent Data Encryption (TDE) support. If a database is configured for ENCRYPTION, files in theThe
Memory Optimized Filegroup are now also encrypted.
For more information, see In-Memory OLTP (In-Memory Optimization).
Query Optimizer
Co m pat i bi l i t y Level Gu ar an t ees
When you upgrade your database to SQL Server 2016, there will be no plan changes seen if you remain at the
older compatibility levels that you were using (for example, 120 or 110). New features and improvements related
to query optimizer, will be available only under latest compatibility level.
T rac e Flag 4 19 9
In general, you do not need to use trace flag 4199 in SQL Server 2016 since most of the query optimizer behaviors
controlled by this trace flag are enabled unconditionally under the latest compatibility level (130) in SQL Server
2016.
N e w R e fe r e n t i a l I n t e g r i t y O p e r a t o r
A table can reference a maximum of 253 other tables and columns as foreign keys (outgoing references). SQL
Server 2016 increases the limit for the number of other table and columns that can reference columns in a single
table (incoming references), from 253 to 10,000. For restrictions, see Create Foreign Key Relationships. A new
referential integrity operator is introduced (under compatibility level 130), which performs the referential integrity
checks in place. This improves overall performance for UPDATE and DELETE operations, on tables that have a large
number of incoming references, thereby making it feasible to have large number of incoming references. For more
information, see Query Optimizer Additions in SQL Server 2016
P a r a l l e l u p d a t e o f sa m p l e d st a t i st i c s
Data sampling to build statistics is now done in parallel (under compatibility level 130), to improve the
performance of statistics collection. For more information, see Update Statistics.
Sublinear threshold for update of statistics
Automatic update of statistics is now more aggressive on large tables (under compatibility level 130). The threshold
to trigger auto-update of statistics is 20%, starting SQL Server 2016, for larger tables, this threshold will start
decreasing (still a percentage) as the number of rows increase in the table. You will no longer need to set trace flag
2371 to reduce the threshold.
O t h er en h an c em en t s
The Insert in an Insert-select statement is multi-threaded or can have a parallel plan (under compatibility level 130).
To get a parallel plan, INSERT … SELECT statement must use the TABLOCK hint. For more information, see Parallel
Insert Select
Live Query Statistics
Management Studio provides the ability to view the live execution plan of an active query. This live query plan
provides real-time insights into the query execution process as the controls flow from one query plan operator to
another. For more information, see Live Query Statistics.
Query Store
Query store is a new feature that provides DBAs with insight on query plan choice and performance. It simplifies
performance troubleshooting by enabling you to quickly find performance differences caused by changes in query
plans. The feature automatically captures a history of queries, plans, and runtime statistics, and retains these for
your review. It separates data by time windows, allowing you to see database usage patterns and understand when
query plan changes happened on the server. The query store presents information by using a Management Studio
dialog box, and lets you force the query to one of the selected query plans. For more information, see Monitoring
Performance By Using the Query Store.
Temporal Tables
SQL Server 2016 now supports system-versioned temporal tables. A temporal table is a new type of table that
provides correct information about stored facts at any point in time. Each temporal table consists of two tables
actually, one for the current data and one for the historical data. The system ensures that when the data changes in
the table with the current data the previous values are stored in the historical table. Querying constructs are
provided to hide this complexity from users. For more information, see Temporal Tables.
Striped Backups to Microsoft Azure Blob Storage
In SQL Server 2016, SQL Server backup to URL using the Microsoft Azure Blob storage service now supports
striped backups sets using block blobs to support a maximum backup size of 12.8 TB. For examples, see Code
Examples.
File-Snapshot Backups to Microsoft Azure Blob Storage
In SQL Server 2016, SQL Server backup to URL now supports using Azure snapshots to backup databases in which
all database files are stored using the Microsoft Azure Blob storage service. For more information, see File-
Snapshot Backups for Database Files in Azure.
Managed Backup
In SQL Server 2016 SQL Server Managed Backup to Microsoft Azure uses the new block blob storage for backup
files. There are also several changes and enhancements to Managed Backup.
Support for both automated and custom scheduling of backups.
Support backups for system databases.
Support for databases that are using the Simple recovery model.
For more information, see SQL Server Managed Backup to Microsoft Azure
NOTE
For SQL Server 2016, these new managed backup features do not yet have corresponding UI support in SQL Server
Management Studio.
TempDB Database
There are several enhancements to TempDB:
Trace Flags 1117 and 1118 are not required for tempdb anymore. If there are multiple tempdb database files
all files will grow at the same time depending on growth settings. In addition, all allocations in tempdb will
use uniform extents.
By default, setup adds as many tempdb files as the CPU count or 8, whichever is lower.
During setup, you can configure the number of tempdb database files, initial size, autogrowth and directory
placement using the new UI input control on the Database Engine Configuration - TempDB section of SQL
Server Installation Wizard.
The default initial size is 8MB and the default autogrowth is 64MB.
You can specify multiple volumes for tempdb database files. If multiple directories are specified tempdb data
files will be spread across the directories in a round-robin fashion.
Built-in JSON Support
SQL Server 2016 adds built-in support for importing and exporting JSON and working with JSON strings. This
built-in support includes the following statements and functions.
Format query results as JSON, or export JSON, by adding the FOR JSON clause to a SELECT statement. Use
the FOR JSON clause, for example, to delegate the formatting of JSON output from your client applications
to SQL Server. For more info, see Format Query Results as JSON with FOR JSON (SQL Server).
Convert JSON data to rows and columns, or import JSON, by calling the OPENJSON rowset provider
function. Use OPENJSON to import JSON data into SQL Server, or convert JSON data to rows and columns
for an app or service that can't currently consume JSON directly. For more info, see Convert JSON Data to
Rows and Columns with OPENJSON (SQL Server).
The ISJSON function tests whether a string contains valid JSON. For more info, see ISJSON (Transact-SQL)
The JSON_VALUE function extracts a scalar value from a JSON string.For more info, see JSON_VALUE
(Transact-SQL).
The JSON_QUERY function extracts an object or an array from a JSON string. For more info, see
JSON_QUERY (Transact-SQL).
The JSON_MODIFY function updates the value of a property in a JSON string and return the updated JSON
string. For more info, see JSON_MODIFY (Transact-SQL).
PolyBase
PolyBase allows you to use T-SQL statements to access data stored in Hadoop or Azure Blob Storage and query it in
an adhoc fashion. It also lets you query semi-structured data and join the results with relational data sets stored in
SQL Server. PolyBase is optimized for data warehousing workloads and intended for analytical query scenarios.
For more information, see PolyBase Guide.
Stretch Database
Stretch Database is a new feature in SQL Server 2016 that migrates your historical data transparently and securely
to the Microsoft Azure cloud. You can access your SQL Server data seamlessly regardless of whether it’s on-
premises or stretched to the cloud. You set the policy that determines where data is stored, and SQL Server handles
the data movement in the background. The entire table is always online and queryable. And, Stretch Database
doesn't require any changes to existing queries or applications – the location of the data is completely transparent
to the application. For more info, see Stretch Database.
Support for UTF-8
bcp Utility, BULK INSERT, and OPENROWSET now support the UTF-8 code page. For more information, see those
topics and Create a Format File (SQL Server).
New Default Database Size and Autogrow Values
New values for the model database and default values for new databases (which are based on model). The initial
size of the data and log files is now 8 MB. The default auto-growth of data and log files is now 64MB.
Transact-SQL Enhancements
Numerous enhancements support the features described in the other sections of this topic. The following additional
enhancements are available.
The TRUNCATE TABLE statement now permits the truncation of specified partitions. For more information, see
TRUNCATE TABLE (Transact-SQL).
ALTER TABLE (Transact-SQL) now allows many alter column actions to be performed while the table remains
available.
The full-text index DMV sys.dm_fts_index_keywords_position_by_document (Transact-SQL) returns the location
of keywords in documents. This DMV has also been added in SQL Server 2012 SP2 and SQL Server 2014 SP1.
A new query hint NO_PERFORMANCE_SPOOL can prevent a spool operator from being added to query plans.
This can improve performance when many concurrent queries are running with spool operations. For more
information, see Query Hints (Transact-SQL).
The FORMATMESSAGE (Transact-SQL) statement is enhances to accept a msg_string argument.
The maximum index key size for NONCLUSTERED indexes has been increased to 1700 bytes.
New DROP IF syntax is added for drop statements related to AGGREGATE, ASSEMBLY, COLUMN, CONSTRAINT,
DATABASE, DEFAULT, FUNCTION, INDEX, PROCEDURE, ROLE, RULE, SCHEMA, SECURITY POLICY, SEQUENCE,
SYNONYM, TABLE, TRIGGER, TYPE, USER, and VIEW. See individual syntax topics for syntax.
A MAXDOP option has been added to DBCC CHECKTABLE (Transact-SQL), DBCC CHECKDB (Transact-SQL), and
DBCC CHECKFILEGROUP (Transact-SQL) to specify the degree of parallelism.
SESSION_CONTEXT can now be set. Includes the SESSION_CONTEXT (Transact-SQL) function,
CURRENT_TRANSACTION_ID (Transact-SQL) function, and the sp_set_session_context (Transact-SQL)
procedure.
Advanced Analytics Extensions allow users to execute scripts written in a supported language such as R.
Transact-SQL supports R by introducing the sp_execute_external_script (Transact-SQL) stored procedure, and
the external scripts enabled Server Configuration Option. For more information, see SQL Server R Services.
Also to support R, the ability to create an external resource pool. For more information, see CREATE EXTERNAL
RESOURCE POOL (Transact-SQL). New catalog views and DMVs
(sys.resource_governor_external_resource_pools (Transact-SQL) and
sys.dm_resource_governor_external_resource_pool_affinity (Transact-SQL)). Additional arguments are available
for sp_execute_external_script (Transact-SQL) and CREATE WORKLOAD GROUP (Transact-SQL). Additional
columns are added to some of the existing resource governor catalog views and DMVs.
The CREATE USER syntax is enhanced with the ALLOW_ENCRYPTED_VALUE_MODIFICATIONS option to support
the Always Encrypted feature. For more information see Migrate Sensitive Data Protected by Always Encrypted.
The COMPRESS (Transact-SQL) and DECOMPRESS (Transact-SQL) functions convert values into and out of the
GZIP algorithm.
The DATEDIFF_BIG (Transact-SQL) and AT TIME ZONE (Transact-SQL) functions and the sys.time_zone_info
(Transact-SQL) view are added to support date and time interactions.
A credential can now be created at the database level (in addition to the server level credential that was
previously available). For more information, see CREATE DATABASE SCOPED CREDENTIAL (Transact-SQL).
Eight new properties are added to SERVERPROPERTY (Transact-SQL): InstanceDefaultDataPath,
InstanceDefaultLogPath, ProductBuild, ProductBuildType, ProductMajorVersion, ProductMinorVersion,
ProductUpdateLevel, and ProductUpdateReference.
The input length limit of 8,000 bytes for the HASHBYTES (Transact-SQL) function is removed.
New string functions STRING_SPLIT (Transact-SQL) and STRING_ESCAPE (Transact-SQL) are added.
Autogrow options: Trace flag 1117 is replaced by the AUTOGROW_SINGLE_FILE and AUTOGROW_ALL_FILES
option of ALTER DATABASE, and trace flag 1117 has no affect. For more information, see ALTER DATABASE File
and Filegroup Options (Transact-SQL) and the new is_autogrow_all_files column of sys.filegroups (Transact-
SQL).
Allocation of mixed extents: For user databases, default allocation for the first 8 pages of an object will change
from using mixed page extents to using uniform extents. Trace flag 1118 is replaced with the SET
MIXED_PAGE_ALLOCATION option of ALTER DATABASE, and trace flag 1118 has no affect. For more
information, see ALTER DATABASE SET Options (Transact-SQL), and the new is_mixed_page_allocation_on
column of sys.databases (Transact-SQL).
System View Enhancements
Two new views support row level security. For more information, see sys.security_predicates (Transact-SQL) and
sys.security_policies (Transact-SQL).
Seven new views support the Query Store feature. For more information, see Query Store Catalog Views
(Transact-SQL).
24 new columns are added to sys.dm_exec_query_stats (Transact-SQL) provide information about memory
grants.
Two new query hints (MIN_GRANT_PERCENT and MAX_GRANT_PERCENT) are added to specify memory grants.
See Query Hints (Transact-SQL).
sys.dm_exec_session_wait_stats (Transact-SQL) provides a per session report similar to the server wide
sys.dm_os_wait_stats (Transact-SQL).
sys.dm_exec_function_stats (Transact-SQL) provides execution statistics regarding scalar valued functions.
Beginning with SQL Server 2016, entries in sys.dm_db_index_usage_stats (Transact-SQL) are retained as they
were prior to SQL Server 2008 R2.
Information about statements submitted to an instance of SQL Server can be returned by the new dynamic
management function sys.dm_exec_input_buffer (Transact-SQL).
Two new views support SQL Server R Services: sys.dm_external_script_requests and
sys.dm_external_script_execution_stats.
Security Enhancements
Row-Level Security
Row-level security introduces predicate based access control. It features a flexible, centralized, predicate-based
evaluation that can take into consideration metadata (such as labels) or any other criteria the administrator
determines as appropriate. The predicate is used as a criterion to determine whether or not the user has the
appropriate access to the data based on user attributes. Label based access control can be implemented by using
predicate based access control. For more information, see Row-Level Security.
Always Encrypted
With Always Encrypted, SQL Server can perform operations on encrypted data, and best of all the encryption key
resides with the application inside the customer’s trusted environment and not on the server. Always Encrypted
secures customer data so DBAs do not have access to plain text data. Encryption and decryption of data happens
transparently at the driver level minimizing changes that have to be made to existing applications. For more
information, see Always Encrypted (Database Engine).
Dynamic Data Masking
Dynamic data masking limits sensitive data exposure by masking it to non-privileged users. Dynamic data masking
helps prevent unauthorized access to sensitive data by enabling customers to designate how much of the sensitive
data to reveal with minimal impact on the application layer. It’s a policy-based security feature that hides the
sensitive data in the result set of a query over designated database fields, while the data in the database is not
changed. For more information, see Dynamic Data Masking.
New Permissions
The ALTER ANY SECURITY POLICY permission is available as part of the implementation of row level security.
The ALTER ANY MASK and UNMASK permissions are available as part of the implementation of dynamic data
masking.
The ALTER ANY COLUMN ENCRYPTION KEY, VIEW ANY COLUMN ENCRYPTION KEY, ALTER ANY
COLUMN MASTER KEY DEFINITION, and VIEW ANY COLUMN MASTER KEY DEFINITION permissions are
available as part of the implementation of the Always Encrypted feature.
The ALTER ANY EXTERNAL DATA SOURCE and ALTER ANY EXTERNAL FILE FORMAT permissions are
visible in SQL Server 2016 but only apply to the Analytics Platform System ( SQL Data Warehouse).
The EXECUTE ANY EXTERNAL SCRIPT permissions are available as part of the support for R scripts.
The ALTER ANY DATABASE SCOPED CONFIGURATION permissions is available to authorize the use of
the ALTER DATABASE SCOPED CONFIGURATION (Transact-SQL) statement.
Transparent Data Encryption
Transparent Data Encryption has been enhanced with support for Intel AES-NI hardware acceleration of
encryption. This will reduce the CPU overhead of turning on Transparent Data Encryption.
AES Encryption for Endpoints
The default encryption for endpoints is changed from RC4 to AES.
New Credential Type
A credential can now be created at the database level (in addition to the server level credential that was
previously available). For more information, see CREATE DATABASE SCOPED CREDENTIAL (Transact-SQL).
High Availability Enhancements
SQL Server 2016 Standard Edition now supports Always On Basic Availability Groups. Basic availability groups
provide support for a primary and secondary replica. This capability replaces the obsolete Database Mirroring
technology for high availability. For more information about the differences between basic and advanced
availability groups, see Basic Availability Groups (Always On Availability Groups).
Load-balancing of read-intent connection requests is now supported across a set of read-only replicas. The
previous behavior always directed connections to the first available read-only replica in the routing list. For more
information, see Configure load-balancing across read-only replicas.
The number of replicas that support automatic failover has been increased from two to three.
Group Managed Service Accounts are now supported for Always On Failover Clusters. For more information, see
Group Managed Service Accounts. For Windows Server 2012 R2, an update is required to avoid temporary
downtime after a password change. To obtain the update, see gMSA-based services can't log on after a password
change in a Windows Server 2012 R2 domain.
Always On availability groups supports distributed transactions and the DTC on Windows Server 2016. For more
information, see Support for distributed transactions.
You can now configure Always On availability groups to failover when a database goes offline. This change requires
the setting the DB_FAILOVER option to ON in the CREATE AVAILABILITY GROUP (Transact-SQL) or ALTER
AVAILABILITY GROUP (Transact-SQL) statements.
Always On now supports encrypted databases. The Availability Group wizards now prompt you for a password for
any databases that contain a database master key when you create a new Availability Group or when you add
databases or add replicas to an existing Availability Group.
Two availability groups in two separate Windows Server Failover Clusters (WSFC) can now be combined into a
Distributed Availability Group. For more information, see Distributed Availability Groups (Always On Availability
Groups).
Direct seeding allows a secondary replica to be automatically seeded over the network (rather than manual seeding
that requires a physical backup of the target database to be restored on the secondary). Direct seeding is specified
by setting SEEDING_MODE=AUTOMATIC in the CREATE AVAILABILITY GROUP (Transact-SQL) or ALTER
AVAILABILITY GROUP (Transact-SQL) statements. You must also specify GRANT CREATE ANY DATABASE with
ALTER AVAILABILITY GROUP (Transact-SQL) on each secondary replica that is used with direct seeding.
Performance improvements – The synchronization throughput of availability groups has been increased ~10x
through parallel and faster compression of log blocks on the primary replica, an optimized synchronization
protocol, and parallel decompression and redo of log records on the secondary replica. This increases the freshness
of readable secondaries and reduces database recovery time in case of failover. Note that redo for memory-
optimized tables is not yet parallel in SQL Server 2016.
Replication Enhancements
Replication of memory-optimized tables are now supported. For more information, see Replication to Memory-
Optimized Table Subscribers.
Replication is now supported to Azure SQL Database. For more information, see Replication to SQL Database.
Tools Enhancements
Management Studio
Download the latest SQL Server Management Studio (SSMS)
SQL Server Management Studio supports the Active Directory Authentication Library (ADAL) which is under
development for connecting to Microsoft Azure. This replaces the certificate-based authentication used in SQL
Server 2014 Management Studio.
SQL Server Management Studio installation requires installing .NET 4.6 as a pre-requisite. .NET 4.6 will be
automatically installed by setup when SQL Server Management Studio is installed.
A new query result grid option supports keeping Carriage Return/Line Feed (newline characters) when copying
or saving text from the results grid. Set this from the Tools/Options menu.
SQL Server Management Tools is no longer installed from the main feature tree; for details see Install SQL
Server Management Tools with SSMS.
SQL Server Management Studio installation requires installing .NET 4.6.1 as a pre-requisite. .NET 4.6.1 will be
automatically installed by setup when SQL Server Management Studio is installed.
Upgrade Advisor
SQL Server 2016 Upgrade Advisor Preview is a standalone tool that enables users of prior versions to run a set of
upgrade rules against their SQL Server database to pinpoint breaking and behavior changes and deprecated
features as well as providing help with the adoption of new features such as Stretch Database.
You can download Upgrade Advisor Preview here or you can install it by using the Web Platform Installer.
See Also
What's New in SQL Server 2016
SQL Server 2016 Release Notes
Install SQL Server Management Tools with SSMS
SQL Server Database Engine Backward Compatibility
Topics in the backward compatibility section describe changes in behavior between versions of SQL Server.
TOPIC DESCRIPTION
Deprecated Database Engine Features in SQL Server 2017 Deprecated Database Engine features in the 2017 release.
Deprecated Database Engine Features in SQL Server 2016 Deprecated Database Engine features in the 2016 release.
Discontinued Database Engine Functionality in SQL Server Discontinued Database Engine features in the 2016 release.
2016
Breaking Changes to Database Engine Features in SQL Server Database Engine feature changes that might require changes
2017 to applications.
Breaking Changes to Database Engine Features in SQL Server Database Engine feature changes that might require changes
2016 to applications.
Deprecated Database Engine Features in SQL Server
2017
This topic describes the deprecated SQL Server Database Engine features that are still available in SQL Server
2017. These features are scheduled to be removed in a future release of SQL Server. Deprecated features should
not be used in new applications.
You can monitor the use of deprecated features by using the SQL Server Deprecated Features Object performance
counter and trace events. For more information, see Use SQL Server Objects.
The value of these counters are also available by executing the following statement:
SELECT * FROM sys.dm_os_performance_counters

WHERE object_name = 'SQLServer:Deprecated Features';
NOTE
This list is identical to the SQL Server 2016 list. There are no new deprecated or discontinued Database Engine features
announced for SQL Server 2017.
Features Not Supported in the Next Version of SQL Server

The following SQL Server Database Engine features will not be supported in the next version of SQL Server. Do not
use these features in new development work, and modify applications that currently use these features as soon as
possible. The Feature name value appears in trace events as the ObjectName and in performance counters and
sys.dm_os_performance_counters as the instance name. The Feature ID value appears in trace events as the
ObjectId.
CATEGORY DEPRECATED FEATURE REPLACEMENT FEATURE NAME FEATURE ID
Backup and Restore RESTORE { DATABASE None. BACKUP DATABASE 104

| LOG } WITH or LOG WITH
[MEDIA]PASSWORD PASSWORD 103
continues to be
deprecated. BACKUP { BACKUP DATABASE
DATABASE | LOG } or LOG WITH
WITH PASSWORD MEDIAPASSWORD
and BACKUP {
DATABASE | LOG }
WITH
MEDIAPASSWORD
are discontinued.
Compatibility levels Upgrade from version Compatibility levels Database 108

110 ( SQL Server are only available for compatibility level
2008 and SQL Server the last two versions. 100
2008 R2). For more information
about compatibility
levels, see ALTER
DATABASE
Compatibility Level
(Transact-SQL).
Database objects Ability to return result None Returning results 12

sets from triggers from trigger
Encryption Encryption using RC4 Use another Deprecated 253

or RC4_128 is encryption algorithm encryption algorithm
deprecated and is such as AES.
scheduled to be
removed in the next
version. Decrypting
RC4 and RC4_128 is
not deprecated.
Remote servers sp_addremotelogin Replace remote sp_addremotelogin 70

servers by using
sp_addserver linked servers. sp_addserver 69
sp_addserver can only
sp_dropremotelogin be used with the local sp_dropremotelogin 71
option.
sp_helpremotelogin sp_helpremotelogin 72
sp_remoteoption sp_remoteoption 73
Remote servers @@remserver Replace remote None None

servers by using
linked servers.
Remote servers SET Replace remote SET 110

REMOTE_PROC_TRAN servers by using REMOTE_PROC_TRAN
SACTIONS linked servers. SACTIONS
Set options SET ROWCOUNT for TOP keyword SET ROWCOUNT 109
INSERT, UPDATE,
and DELETE
statements
Table hints HOLDLOCK table hint Use HOLDLOCK with HOLDLOCK table hint 167
without parenthesis. parenthesis. without parenthesis
Tools sqlmaint Utility Use the SQL Server None None

maintenance plan
feature
Features Not Supported in a Future Version of SQL Server

The following SQL Server Database Engine features are supported in the next version of SQL Server, but will be
removed in a later version. The specific version of SQL Server has not been determined.
Compatibility levels sp_dbcmptlevel ALTER DATABASE … sp_dbcmptlevel 80

SET
COMPATIBILITY_LEVE
L. For more
information, see
ALTER DATABASE
Compatibility Level
(Transact-SQL).
Compatibility levels Database Plan to upgrade the Database

compatibility level database and compatibility level
110 and 120. application for a 110
future release.
Database
compatibility level
120
XML Inline XDR Schema The XMLDATA XMLDATA 181

Generation directive to the FOR
XML option is
deprecated. Use XSD
generation in the case
of RAW and AUTO
modes. There is no
replacement for the
XMLDATA directive in
EXPLICT mode.
Backup and restore BACKUP { DATABASE BACKUP { DATABASE BACKUP DATABASE 235
| LOG } TO TAPE | LOG } TO DISK or LOG TO TAPE
BACKUP { DATABASE BACKUP { DATABASE

| LOG } TO | LOG } TO
device_that_is_a_tape device_that_is_a_disk
Backup and restore sp_addumpdevice sp_addumpdevice ADDING TAPE 236

'tape' 'disk' DEVICE
Backup and restore sp_helpdevice sys.backup_devices sp_helpdevice 100
Collations Korean_Wansung_Uni None. These collations Korean_Wansung_Uni 191

code exist in SQL Server code
2005, but are not 192
Lithuanian_Classic visible through Lithuanian_Classic
fn_helpcollations. 194
SQL_AltDiction_CP12 SQL_AltDiction_CP12
53_CS_AS 53_CS_AS
Collations Hindi These collations exist Hindi 190

in SQL Server 2005
Macedonian and higher, but are Macedonian 193
not visible through
fn_helpcollations. Use
Macedonian_FYROM_
90 and
Indic_General_90
instead.
Collations Azeri_Latin_90 Azeri_Latin_100 Azeri_Latin_90 232
Azeri_Cyrilllic_90 Azeri_Cyrilllic_100 Azeri_Cyrilllic_90 233
Configuration SET ANSI_NULLS OFF None. SET ANSI_NULLS OFF 111

and ANSI_NULLS OFF
database option ANSI_NULLS, SET ANSI_PADDING 113
ANSI_PADDING and OFF
SET ANSI_PADDING CONCAT_NULLS_YIEL 112
OFF and DS_NULL will always SET
ANSI_PADDING OFF be set to ON. SET CONCAT_NULL_YIEL 36
database option OFFSETS will be DS_NULL OFF
unavailable. 111
SET SET OFFSETS
CONCAT_NULL_YIEL 113
DS_NULL OFF and ALTER DATABASE SET
CONCAT_NULL_YIEL ANSI_NULLS OFF 112
DS_NULL OFF
database option ALTER DATABASE SET
ANSI_PADDING OFF
SET OFFSETS
ALTER DATABASE SET
CONCAT_NULL_YIEL
DS_NULL OFF
Data types sp_addtype CREATE TYPE sp_addtype 62
sp_droptype DROP TYPE sp_droptype 63
Data types timestamp syntax for rowversion data TIMESTAMP 158

rowversion data type syntax
type
Data types Ability to insert null Use a DEFAULT INSERT NULL into 179
values into instead. TIMESTAMP columns
timestamp columns.
Data types 'text in row' table Use varchar(max), Text in row table 9
option nvarchar(max), and option
varbinary(max) data
types. For more
information, see
sp_tableoption
(Transact-SQL).
Data types Data types: Use varchar(max), Data types: text, 4

nvarchar(max), and ntext or image
text varbinary(max) data
types.
ntext
image
Database sp_attach_db CREATE DATABASE sp_attach_db 81

management statement with the
sp_attach_single_file_d FOR ATTACH option. sp_attach_single_file_d 82
b To rebuild multiple b
log files, when one or
more have a new
location, use the FOR
ATTACH_REBUILD_LO
G option.
Database objects CREATE DEFAULT DEFAULT keyword in CREATE_DROP_DEFA 162

CREATE TABLE and ULT
DROP DEFAULT ALTER TABLE 64
sp_bindefault
sp_bindefault 65
sp_unbindefault
sp_unbindefault
Database objects CREATE RULE CHECK keyword in CREATE_DROP_RULE 161

CREATE TABLE and
DROP RULE ALTER TABLE sp_bindrule 66
sp_bindrule sp_unbindrule 67
sp_unbindrule
Database objects sp_change_users_logi Use ALTER USER. sp_change_users_logi 231

n n
Database objects sp_depends sys.dm_sql_referencin sp_depends 19

g_entities and
sys.dm_sql_referenced
_entities
Database objects sp_renamedb MODIFY NAME in sp_renamedb 79

ALTER DATABASE
Database objects sp_getbindtoken Use MARS or sp_getbindtoken 98

distributed
transactions.
Database options sp_bindsession Use MARS or sp_bindsession 97

distributed
transactions.
Database options sp_resetstatus ALTER DATABASE SET sp_resetstatus 83

{ ONLINE |
EMERGENCY }
Database options TORN_PAGE_DETECTI PAGE_VERIFY ALTER DATABASE 102

ON option of ALTER TORN_PAGE_DETECTI WITH
DATABASE ON option of ALTER TORN_PAGE_DETECTI
DATABASE ON
DBCC DBCC DBREINDEX REBUILD option of DBCC DBREINDEX 11

ALTER INDEX.
DBCC DBCC INDEXDEFRAG REORGANIZE option DBCC INDEXDEFRAG 18

of ALTER INDEX
DBCC DBCC SHOWCONTIG sys.dm_db_index_phy DBCC SHOWCONTIG 10

sical_stats
DBCC DBCC PINTABLE Has no effect. DBCC [UN]PINTABLE 189
DBCC UNPINTABLE
Extended properties Level0type = 'type' Use Level0type = EXTPROP_LEVEL0TYP 13

and Level0type = 'USER' only to add an E
'USER' to add extended property 14
extended properties directly to a user or EXTPROP_LEVEL0USE
to level-1 or level-2 role. R
type objects.
Use Level0type =
'SCHEMA' to add an
extended property to
level-1 types such as
TABLE or VIEW, or
COLUMN or
TRIGGER. For more
information, see
sp_addextendedprope
rty (Transact-SQL).
Extended stored srv_alloc Use CLR Integration XP_API 20

procedure instead.
programming srv_convert
srv_describe
srv_getbindtoken
srv_got_attention
srv_message_handler
srv_paramdata
srv_paraminfo
srv_paramlen
srv_parammaxlen
srv_paramname
srv_paramnumber
srv_paramset
srv_paramsetoutput
srv_paramstatus
srv_paramtype
srv_pfield
srv_pfieldex
srv_rpcdb
srv_rpcname
srv_rpcnumber
srv_rpcoptions
srv_rpcowner
srv_rpcparams
srv_senddone
srv_sendmsg
srv_sendrow
srv_setcoldata
srv_setcollen
srv_setutype
srv_willconvert
srv_wsendmsg
srv_wsendmsg
Extended stored sp_addextendedproc Use CLR Integration sp_addextendedproc 94
procedure instead.
programming sp_dropextendedproc sp_dropextendedproc 95
sp_helpextendedproc sp_helpextendedproc 96
Extended stored xp_grantlogin Use CREATE LOGIN xp_grantlogin 44

procedures
xp_revokelogin Use DROP LOGIN xp_revokelogin 45
IsIntegratedSecurityO
xp_loginConfig nly argument of xp_loginconfig 59
SERVERPROPERTY
Functions fn_get_sql sys.dm_exec_sql_text fn_get_sql 151
Hash algorithms The MD2, MD4, MD5, Use SHA2_256 or Deprecated hash
SHA, and SHA1 SHA2_512. algorithm
algorithms. These are
not available under
compatibility level
130.
High availability database mirroring Always On availability DATABASE_MIRRORI 267

groups NG
If your edition of SQL

Server does not
support Always On
availability groups,
use log shipping.
Index options sp_indexoption ALTER INDEX sp_indexoption 78
Index options CREATE TABLE, ALTER Rewrite the statement INDEX_OPTION 33

TABLE, or CREATE to use the current
INDEX syntax without syntax.
parentheses around
the options.
Instance options sp_configure option System tables are no sp_configure 'allow 173
'allow updates' longer updatable. updates'
Setting has no effect.
Instance options sp_configure options: Now automatically sp_configure 'locks' 174

configured. Setting
'locks' has no effect. sp_configure 'open 175
objects'
'open objects' 176
sp_configure 'set
'set working set size' working set size'
Instance options sp_configure option System tables are no sp_configure 'priority 199
'priority boost' longer updatable. boost'
Use the Windows
start /high …
program.exe option
instead.
Instance options sp_configure option System tables are no sp_configure 'remote 37

'remote proc trans' longer updatable. proc trans'
Linked servers Specifying the SQL Server Native SQLOLEDDB for 19

SQLOLEDB provider Client (SQLNCLI) linked servers
for linked servers.
Locking sp_lock sys.dm_tran_locks sp_lock 99
Metadata FILE_ID FILE_IDEX FILE_ID 15
INDEXKEY_PROPERTY sys.index_columns INDEXKEY_PROPERTY 17
Native XML Web The CREATE Use Windows CREATE/ALTER 21

Services ENDPOINT or ALTER Communications ENDPOINT
ENDPOINT statement Foundation (WCF) or 22
with the FOR SOAP ASP.NET instead. sys.endpoint_webmet
option. hods 23
sys.endpoint_webmet EXT_soap_endpoints
hods
sys.soap_endpoints
sys.soap_endpoints
Removable databases sp_certify_removable sp_detach_db sp_certify_removable 74
sp_create_removable sp_create_removable 75
Removable databases sp_dbremove DROP DATABASE sp_dbremove 76
Security The ALTER LOGIN Replaced by the new ALTER LOGIN WITH 230
WITH SET ALTER LOGIN ADD SET CREDENTIAL
CREDENTIAL syntax and DROP
CREDENTIAL syntax
Security sp_addapprole CREATE sp_addapprole 53

APPLICATION ROLE
sp_dropapprole sp_dropapprole 54
DROP APPLICATION
ROLE
Security sp_addlogin CREATE LOGIN sp_addlogin 39
sp_droplogin DROP LOGIN sp_droplogin 40
Security sp_adduser CREATE USER sp_adduser 49
sp_dropuser DROP USER sp_dropuser 50
Security sp_grantdbaccess CREATE USER sp_grantdbaccess 51
sp_revokedbaccess DROP USER sp_revokedbaccess 52

Security sp_addrole CREATE ROLE sp_addrole 56
sp_droprole DROP ROLE sp_droprole 57
Security sp_approlepassword ALTER APPLICATION sp_approlepassword 55

ROLE
sp_password sp_password 46
ALTER LOGIN
Security sp_changeobjectowne ALTER SCHEMA or sp_changeobjectowne 58

r ALTER r
AUTHORIZATION
Security sp_control_dbmasterk A master key must sp_control_dbmasterk 274

ey_password exist and password ey_password
must be correct.
Security sp_defaultdb ALTER LOGIN sp_defaultdb 47
sp_defaultlanguage sp_defaultlanguage 48
Security sp_denylogin ALTER LOGIN sp_denylogin 42

DISABLE
sp_grantlogin sp_grantlogin 41
CREATE LOGIN
sp_revokelogin sp_revokelogin 43
DROP LOGIN
Security USER_ID DATABASE_PRINCIPA USER_ID 16

L_ID
Security sp_srvrolepermission These stored sp_srvrolepermission 61

procedures return
sp_dbfixedrolepermiss information that was sp_dbfixedrolepermiss 60
ion correct in SQL Server ion
2000. The output
does not reflect
changes to the
permissions hierarchy
implemented in SQL
Server 2008. For
more information, see
Permissions of Fixed
Server Roles.
Security GRANT ALL GRANT, DENY, and ALL Permission 35

REVOKE specific
DENY ALL permissions.
REVOKE ALL
Security PERMISSIONS Query PERMISSIONS 170

intrinsic function sys.fn_my_permission
s instead.
Security SETUSER EXECUTE AS SETUSER 165

Security RC4 and DESX Use another DESX algorithm 238

encryption algorithms algorithm such as
AES.
SET options SET FMTONLY sys.dm_exec_describe_ SET FMTONLY 250

first_result_set
(Transact-SQL),
sys.dm_exec_describe_
first_result_set_for_obj
ect (Transact-SQL),
sp_describe_first_resul
t_set (Transact-SQL),
and
sp_describe_undeclare
d_parameters
(Transact-SQL).
Server Configuration c2 audit option common criteria sp_configure 'c2 audit 252
Options compliance enabled mode'
default trace enabled Server Configuration 253
option Option sp_configure 'default
trace enabled'
Extended Events
SMO classes Microsoft.SQLServe Microsoft.SqlServer None None

r. .
Management.Smo.I Management.Smo.S
nformation class erver class
Microsoft.SQLServe Microsoft.SqlServer
r. .
Management.Smo.S Management.Smo.S
ettings class erver class
r.Management. .
Smo.DatabaseOptio Management.Smo.D
ns class atabase class
Microsoft.SqlServer None
.Management.Smo.
DatabaseDdlTrigger
.NotForReplication
property
SQL Server Agent net send notification E-mail notification None None
Pager notification E-mail notification
SQL Server Solution Explorer None None

Management Studio integration in SQL
Server Management
Studio
System Stored sp_db_increased_parti None. Support for sp_db_increased_parti 253

Procedures tions increased partitions is tions
available by default in
SQL Server 2017.
System tables sysaltfiles Compatibility views. sysaltfiles 141

For more information,
syscacheobjects see Compatibility syscacheobjects None
Views (Transact-SQL).
syscolumns syscolumns 133
** Important *\* The
syscomments compatibility views do syscomments 126
not expose metadata
sysconfigures for features that were sysconfigures 146
introduced in SQL
sysconstraints Server 2005. We sysconstraints 131
recommend that you
syscurconfigs upgrade your syscurconfigs 147
applications to use
sysdatabases catalog views. For sysdatabases 142
sysdepends Catalog Views sysdepends 123
(Transact-SQL).
sysdevices sysdevices 144
sysfilegroups sysfilegroups 128
sysfiles sysfiles 127
sysforeignkeys sysforeignkeys 130
sysfulltextcatalogs sysfulltextcatalogs 122
sysindexes sysindexes 132
sysindexkeys sysindexkeys 134
syslockinfo syslockinfo 143
syslogins syslogins 140
sysmembers sysmembers 119
sysmessages sysmessages 137
sysobjects sysobjects 125
sysoledbusers sysoledbusers 139
sysopentapes sysopentapes 145
sysperfinfo sysperfinfo 157
syspermissions syspermissions 121
sysprocesses sysprocesses 153
sysprotects sysprotects 120
sysreferences sysreferences 129
sysremotelogins sysremotelogins 138
sysservers sysservers 136
systypes systypes 135
sysusers sysusers 124

System tables sys.numbered_proced None numbered_procedure 148
ures s
149
sys.numbered_proced numbered_procedure
ure_parameters _parameters
System functions fn_virtualservernodes sys.dm_os_cluster_no fn_virtualservernodes 155

des
fn_servershareddrives fn_servershareddrives 156
sys.dm_io_cluster_sha
red_drives
System views sys.sql_dependencies sys.sql_expression_de sys.sql_dependencies 198

pendencies
Table compression The use of the Vardecimal storage Vardecimal storage 200
vardecimal storage format is deprecated. format
format. SQL Server 2017 data
compression,
compresses decimal
values as well as other
data types. We
recommend that you
use data compression
instead of the
vardecimal storage
format.
Table compression Use of the Vardecimal storage sp_db_vardecimal_sto 201

sp_db_vardecimal_sto format is deprecated. rage_format
rage_format SQL Server 2017 data
procedure. compression,
compresses decimal
values as well as other
data types. We
recommend that you
instead of the
vardecimal storage
format.
Table compression Use of the Use data compression sp_estimated_rowsize 202

sp_estimated_rowsize and the _reduction_for_vardeci
_reduction_for_vardeci sp_estimate_data_co mal
mal procedure. mpression_savings
procedure instead.
Table hints Specifying NOLOCK Remove the NOLOCK NOLOCK or 1

or or READUNCOMMITTED
READUNCOMMITTED READUNCOMMITTED in UPDATE or DELETE
in the FROM clause of table hints from the
an UPDATE or DELETE FROM clause.
statement.
Table hints Specifying table hints Use WITH. Table hint without 8
without using the WITH
WITH keyword.
Table hints INSERT_HINTS INSERT_HINTS 34

Textpointers WRITETEXT None UPDATETEXT or 115

WRITETEXT
UPDATETEXT 114
READTEXT
READTEXT
Textpointers TEXTPTR() None TEXTPTR 5
TEXTVALID() TEXTVALID 6
Transact-SQL :: function-calling Replaced by SELECT '::' function calling 166

sequence column_list FROM syntax
sys.<function_name>
().
For example, replace

SELECT * FROM
::fn_virtualfilestats(2,1)
with
SELECT * FROM
sys.fn_virtualfilestats(2,1)
.
Transact-SQL Three-part and four- Two-part names is More than two-part 3

part column the standard- column name
references. compliant behavior.
Transact-SQL A string enclosed in expression [AS] String literals as 184

quotation marks used column_alias column aliases
as a column alias for
an expression in a expression [AS]
SELECT list: [column_alias]
'string_alias' = expression [AS]

expression "column_alias"
expression [AS]
'column_alias'
column_alias =
expression
Transact-SQL Numbered None. Do not use. ProcNums 160

procedures
Transact-SQL table_name.index_na index_name ON DROP INDEX with 163

me syntax in DROP table_name syntax in two-part name
INDEX DROP INDEX.
Transact-SQL Not ending Transact- End Transact-SQL None None

SQL statements with statements with a
a semicolon. semicolon ( ; ).
Transact-SQL GROUP BY ALL Use custom case-by- GROUP BY ALL 169

case solution with
UNION or derived
table.
Transact-SQL ROWGUIDCOL as a Use $rowguid. ROWGUIDCOL 182

column name in DML
statements.
Transact-SQL IDENTITYCOL as a Use $identity. IDENTITYCOL 183

column name in DML
statements.
Transact-SQL Use of #, ## as Use at least one '#' and '##' as the 185
temporary table and additional character. name of temporary
temporary stored tables and stored
procedure names. procedures
Transact-SQL Use of @, @@, or Do not use @ or @@ '@' and names that 186.
@@ as Transact-SQL or names that begin start with '@@' as
identifiers. with @@ as Transact-SQL
identifiers. identifiers
Transact-SQL Use of DEFAULT Do not use the word DEFAULT keyword as 187
keyword as default DEFAULT as a default a default value
value. value.
Transact-SQL Use of a space as a Use a comma to Multiple table hints 168

separator between separate table hints. without comma
table hints.
Transact-SQL The select list of an Use COUNT_BIG (*). Index view select list 2
aggregate indexed without
view must contain COUNT_BIG(*)
COUNT_BIG (*) in 90
compatibility mode
Transact-SQL The indirect None. Indirect TVF hints 7

application of table
hints to an invocation
of a multi-statement
table-valued function
(TVF) through a view.
Transact-SQL ALTER DATABASE MODIFY FILEGROUP MODIFY FILEGROUP 195

syntax: READ_ONLY READONLY
196
MODIFY FILEGROUP MODIFY FILEGROUP MODIFY FILEGROUP
READONLY READ_WRITE READWRITE
MODIFY FILEGROUP
READWRITE
Other DB-Library Although the None None

Database Engine still
Embedded SQL for C supports connections
from existing
applications that use
the DB-Library and
Embedded SQL APIs,
it does not include
the files or
documentation
required to do
programming work
on applications that
use these APIs. A
future version of the
SQL Server Database
Engine will drop
support for
connections from DB-
Library or Embedded
SQL applications. Do
not use DB-Library or
Embedded SQL to
develop new
applications. Remove
any dependencies on
either DB-Library or
Embedded SQL when
you are modifying
existing applications.
Instead of these APIs,
use the SQLClient
namespace or an API
such as ODBC. SQL
Server 2017 does not
include the DB-
Library DLL required
to run these
applications. To run
DB-Library or
Embedded SQL
applications, you
must have available
the DB-Library DLL
from SQL Server
version 6.5, SQL
Server 7.0, or SQL
Server 2000.
Tools SQL Server Profiler for Use Extended Events SQL Server Profiler None
Trace Capture Profiler embedded in
SQL Server
Management Studio.
Tools SQL Server Profiler for SQL Server SQL Server Profiler None
Trace Replay Distributed Replay
Trace Management Microsoft.SqlServer.M Trace Configuration:

Objects anagement.Trace Microsoft.SqlServer.M
namespace (contains anagement.XEvent
the APIs for SQL
Server Trace and Trace Reading:
Replay objects) Microsoft.SqlServer.XE
vent.Linq
Trace Replay: None
SQL Trace stored sp_trace_create Extended Events sp_trace_create 258

procedures, functions,
and catalog views sp_trace_setevent sp_trace_setevent 260
sp_trace_setfilter sp_trace_setfilter 261
sp_trace_setstatus sp_trace_setstatus 259
fn_trace_geteventinfo fn_trace_geteventinfo 256
fn_trace_getfilterinfo fn_trace_getfilterinfo 257
fn_trace_getinfo fn_trace_getinfo
fn_trace_gettable fn_trace_gettable
sys.traces sys.traces
sys.trace_events sys.trace_events
sys.trace_event_bindin sys.trace_event_bindin
gs gs
sys.trace_categories sys.trace_categories
sys.trace_columns sys.trace_columns
sys.trace_subclass_val sys.trace_subclass_val
ues ues
NOTE
The cookie OUTPUT parameter for sp_setapprole is currently documented as varbinary(8000) which is the correct
maximum length. However the current implementation returns varbinary(50). If developers have allocated varbinary(50)
the application might require changes if the cookie return size increases in a future release. Though not a deprecation issue
this is mentioned in this topic because the application adjustments are similar. For more information, see sp_setapprole
(Transact-SQL).
See Also
Discontinued Database Engine Functionality in SQL Server 2016
Deprecated Database Engine Features in SQL Server
2016
This topic describes the deprecated SQL Server Database Engine features that are still available in SQL Server
2016. These features are scheduled to be removed in a future release of SQL Server. Deprecated features should
not be used in new applications.
For SQL Server 2017, see Deprecated Database Engine Features in SQL Server 2017.
You can monitor the use of deprecated features by using the SQL Server Deprecated Features Object performance
counter and trace events. For more information, see Use SQL Server Objects.
The value of these counters are also available by executing the following statement:
SELECT * FROM sys.dm_os_performance_counters

WHERE object_name = 'SQLServer:Deprecated Features';
Features Not Supported in the Next Version of SQL Server

The following SQL Server Database Engine features will not be supported in the next version of SQL Server. Do not
use these features in new development work, and modify applications that currently use these features as soon as
possible. The Feature name value appears in trace events as the ObjectName and in performance counters and
sys.dm_os_performance_counters as the instance name. The Feature ID value appears in trace events as the
ObjectId.
Backup and Restore RESTORE { DATABASE None. BACKUP DATABASE 104

| LOG } WITH or LOG WITH
[MEDIA]PASSWORD PASSWORD 103
continues to be
deprecated. BACKUP { BACKUP DATABASE
DATABASE | LOG } or LOG WITH
WITH PASSWORD MEDIAPASSWORD
and BACKUP {
DATABASE | LOG }
WITH
MEDIAPASSWORD
are discontinued.
Compatibility levels Upgrade from version Compatibility levels Database 108

110 ( SQL Server are only available for compatibility level
2008 and SQL Server the last two versions. 100
2008 R2). For more information
about compatibility
levels, see ALTER
DATABASE
Compatibility Level
(Transact-SQL).
Database objects Ability to return result None Returning results 12

sets from triggers from trigger
Encryption Encryption using RC4 Use another Deprecated 253

or RC4_128 is encryption algorithm encryption algorithm
deprecated and is such as AES.
scheduled to be
removed in the next
version. Decrypting
RC4 and RC4_128 is
not deprecated.
Remote servers sp_addremotelogin Replace remote sp_addremotelogin 70

servers by using
sp_addserver linked servers. sp_addserver 69
sp_addserver can only
sp_dropremotelogin be used with the local sp_dropremotelogin 71
option.
sp_helpremotelogin sp_helpremotelogin 72
sp_remoteoption sp_remoteoption 73
Remote servers @@remserver Replace remote None None

servers by using
linked servers.
Remote servers SET Replace remote SET 110

REMOTE_PROC_TRAN servers by using REMOTE_PROC_TRAN
SACTIONS linked servers. SACTIONS
Set options SET ROWCOUNT for TOP keyword SET ROWCOUNT 109
INSERT, UPDATE,
and DELETE
statements
Table hints HOLDLOCK table hint Use HOLDLOCK with HOLDLOCK table hint 167
without parenthesis. parenthesis. without parenthesis
Tools sqlmaint Utility Use the SQL Server None None

maintenance plan
feature
Features Not Supported in a Future Version of SQL Server

The following SQL Server Database Engine features are supported in the next version of SQL Server, but will be
removed in a later version. The specific version of SQL Server has not been determined.
Compatibility levels sp_dbcmptlevel ALTER DATABASE … sp_dbcmptlevel 80

SET
COMPATIBILITY_LEVE
L. For more
information, see
ALTER DATABASE
Compatibility Level
(Transact-SQL).
Compatibility levels Database Plan to upgrade the Database

compatibility level database and compatibility level
110 and 120. application for a 110
future release.
Database
compatibility level
120
XML Inline XDR Schema The XMLDATA XMLDATA 181

Generation directive to the FOR
XML option is
deprecated. Use XSD
generation in the case
of RAW and AUTO
modes. There is no
replacement for the
XMLDATA directive in
EXPLICT mode.
Backup and restore BACKUP { DATABASE BACKUP { DATABASE BACKUP DATABASE 235
| LOG } TO TAPE | LOG } TO DISK or LOG TO TAPE
BACKUP { DATABASE BACKUP { DATABASE

| LOG } TO | LOG } TO
device_that_is_a_tape device_that_is_a_disk
Backup and restore sp_addumpdevice'tap sp_addumpdevice'dis ADDING TAPE 236

e' k' DEVICE
Backup and restore sp_helpdevice sys.backup_devices sp_helpdevice 100
Collations Korean_Wansung_Uni None. These Korean_Wansung_Uni 191

code collations exist in SQL code
Server 2005, but are 192
Lithuanian_Classic not visible through Lithuanian_Classic
fn_helpcollations. 194
SQL_AltDiction_CP12 SQL_AltDiction_CP12
53_CS_AS 53_CS_AS
Collations Hindi These collations exist Hindi 190

in SQL Server 2005
Macedonian and higher, but are Macedonian 193
not visible through
fn_helpcollations. Use
Macedonian_FYROM_
90 and
Indic_General_90
instead.
Collations Azeri_Latin_90 Azeri_Latin_100 Azeri_Latin_90 232
Azeri_Cyrilllic_90 Azeri_Cyrilllic_100 Azeri_Cyrilllic_90 233
Configuration SET ANSI_NULLS OFF None. SET ANSI_NULLS OFF 111

and ANSI_NULLS OFF
database option ANSI_NULLS, SET ANSI_PADDING 113
ANSI_PADDING and OFF
SET ANSI_PADDING CONCAT_NULLS_YIEL 112
OFF and DS_NULL will always SET
ANSI_PADDING OFF be set to ON. SET CONCAT_NULL_YIEL 36
database option OFFSETS will be DS_NULL OFF
unavailable. 111
SET SET OFFSETS
CONCAT_NULL_YIEL 113
DS_NULL OFF and ALTER DATABASE SET
CONCAT_NULL_YIEL ANSI_NULLS OFF 112
DS_NULL OFF
database option ALTER DATABASE SET
ANSI_PADDING OFF
SET OFFSETS
ALTER DATABASE SET
CONCAT_NULL_YIEL
DS_NULL OFF
Data types sp_addtype CREATE TYPE sp_addtype 62
sp_droptype DROP TYPE sp_droptype 63
Data types timestamp syntax for rowversion data TIMESTAMP 158

rowversion data type syntax
type
Data types Ability to insert null Use a DEFAULT INSERT NULL into 179
values into instead. TIMESTAMP columns
timestamp columns.
Data types 'text in row' table Use varchar(max), Text in row table 9
option nvarchar(max), and option
varbinary(max) data
types. For more
information, see
sp_tableoption
(Transact-SQL).
Data types Data types: Use varchar(max), Data types: text, 4

nvarchar(max), and ntext or image
text varbinary(max) data
types.
ntext
image
Database sp_attach_db CREATE DATABASE sp_attach_db 81

management statement with the
sp_attach_single_file_ FOR ATTACH option. sp_attach_single_file_d 82
db To rebuild multiple b
log files, when one or
more have a new
location, use the FOR
ATTACH_REBUILD_LO
G option.
Database objects CREATE DEFAULT DEFAULT keyword in CREATE_DROP_DEFA 162

CREATE TABLE and ULT
DROP DEFAULT ALTER TABLE 64
sp_bindefault
sp_bindefault 65
sp_unbindefault
sp_unbindefault
Database objects CREATE RULE CHECK keyword in CREATE_DROP_RULE 161

CREATE TABLE and
DROP RULE ALTER TABLE sp_bindrule 66
sp_bindrule sp_unbindrule 67
sp_unbindrule
Database objects sp_change_users_logi Use ALTER USER. sp_change_users_logi 231

n n
Database objects sp_depends sys.dm_sql_referencin sp_depends 19

g_entities and
sys.dm_sql_referenced
_entities
Database objects sp_renamedb MODIFY NAME in sp_renamedb 79

ALTER DATABASE
Database objects sp_getbindtoken Use MARS or sp_getbindtoken 98

distributed
transactions.
Database options sp_bindsession Use MARS or sp_bindsession 97

distributed
transactions.
Database options sp_resetstatus ALTER DATABASE SET sp_resetstatus 83

{ ONLINE |
EMERGENCY }
Database options TORN_PAGE_DETECTI PAGE_VERIFY ALTER DATABASE 102

ON option of ALTER TORN_PAGE_DETECTI WITH
DATABASE ON option of ALTER TORN_PAGE_DETECTI
DATABASE ON
DBCC DBCC DBREINDEX REBUILD option of DBCC DBREINDEX 11

ALTER INDEX.
DBCC DBCC INDEXDEFRAG REORGANIZE option DBCC INDEXDEFRAG 18

of ALTER INDEX
DBCC DBCC SHOWCONTIG sys.dm_db_index_phy DBCC SHOWCONTIG 10

sical_stats
DBCC DBCC PINTABLE Has no effect. DBCC [UN]PINTABLE 189
DBCC UNPINTABLE
Extended properties Level0type = 'type' Use Level0type = EXTPROP_LEVEL0TYP 13

and Level0type = 'USER' only to add an E
'USER' to add extended property 14
extended properties directly to a user or EXTPROP_LEVEL0USE
to level-1 or level-2 role. R
type objects.
Use Level0type =
'SCHEMA' to add an
extended property to
TABLE or VIEW, or
COLUMN or
TRIGGER. For more
information, see
sp_addextendedprope
rty (Transact-SQL).
Extended stored srv_alloc Use CLR Integration XP_API 20

procedure instead.
programming srv_convert
srv_describe
srv_getbindtoken
srv_got_attention
srv_message_handler
srv_paramdata
srv_paraminfo
srv_paramlen
srv_parammaxlen
srv_paramname
srv_paramnumber
srv_paramset
srv_paramsetoutput
srv_paramstatus
srv_paramtype
srv_pfield
srv_pfieldex
srv_rpcdb
srv_rpcname
srv_rpcnumber
srv_rpcoptions
srv_rpcowner
srv_rpcparams
srv_senddone
srv_sendmsg
srv_sendrow
srv_setcoldata
srv_setcollen
srv_setutype
srv_willconvert
srv_wsendmsg
srv_wsendmsg
Extended stored sp_addextendedproc Use CLR Integration sp_addextendedproc 94
procedure instead.
programming sp_dropextendedproc sp_dropextendedproc 95
sp_helpextendedproc sp_helpextendedproc 96
Extended stored xp_grantlogin Use CREATE LOGIN xp_grantlogin 44

procedures
xp_revokelogin Use DROP LOGIN xp_revokelogin 45
IsIntegratedSecurityO
xp_loginConfig nly argument of xp_loginconfig 59
SERVERPROPERTY
Functions fn_get_sql sys.dm_exec_sql_text fn_get_sql 151
Hash algorithms The MD2, MD4, Use SHA2_256 or Deprecated hash

MD5, SHA, and SHA1 SHA2_512. algorithm
algorithms. These are
not available under
compatibility level
130.
High availability database mirroring Always On availability DATABASE_MIRRORI 267

groups NG
If your edition of SQL

Server does not
support Always On
availability groups,
use log shipping.
Index options sp_indexoption ALTER INDEX sp_indexoption 78
Index options CREATE TABLE, ALTER Rewrite the statement INDEX_OPTION 33

TABLE, or CREATE to use the current
INDEX syntax without syntax.
parentheses around
the options.
Instance options sp_configure option System tables are no sp_configure 'allow 173
'allow updates' longer updatable. updates'
Instance options sp_configure options: Now automatically sp_configure 'locks' 174

configured. Setting
'locks' has no effect. sp_configure 'open 175
objects'
'open objects' 176
sp_configure 'set
'set working set size' working set size'
Instance options sp_configure option System tables are no sp_configure 'priority 199
'priority boost' longer updatable. boost'
Use the Windows
start /high …
program.exe option
instead.
Instance options sp_configure option System tables are no sp_configure 'remote 37

'remote proc trans' longer updatable. proc trans'
Linked servers Specifying the SQL Server Native SQLOLEDDB for 19

SQLOLEDB provider Client (SQLNCLI) linked servers
for linked servers.
Locking sp_lock sys.dm_tran_locks sp_lock 99
Metadata FILE_ID FILE_IDEX FILE_ID 15
INDEXKEY_PROPERTY sys.index_columns INDEXKEY_PROPERTY 17
Native XML Web The CREATE Use Windows CREATE/ALTER 21

Services ENDPOINT or ALTER Communications ENDPOINT
ENDPOINT statement Foundation (WCF) or 22
with the FOR SOAP ASP.NET instead. sys.endpoint_webmet
option. hods 23
sys.endpoint_webmet EXT_soap_endpoints
hods
sys.soap_endpoints
sys.soap_endpoints
Removable databases sp_certify_removable sp_detach_db sp_certify_removable 74
sp_create_removable sp_create_removable 75
Removable databases sp_dbremove DROP DATABASE sp_dbremove 76
Security The ALTER LOGIN Replaced by the new ALTER LOGIN WITH 230
WITH SET ALTER LOGIN ADD SET CREDENTIAL
CREDENTIAL syntax and DROP
CREDENTIAL syntax
Security sp_addapprole CREATE sp_addapprole 53

APPLICATION ROLE
sp_dropapprole sp_dropapprole 54
DROP APPLICATION
ROLE
Security sp_addlogin CREATE LOGIN sp_addlogin 39
sp_droplogin DROP LOGIN sp_droplogin 40
Security sp_adduser CREATE USER sp_adduser 49
sp_dropuser DROP USER sp_dropuser 50
Security sp_grantdbaccess CREATE USER sp_grantdbaccess 51
sp_revokedbaccess DROP USER sp_revokedbaccess 52

Security sp_addrole CREATE ROLE sp_addrole 56
sp_droprole DROP ROLE sp_droprole 57
Security sp_approlepassword ALTER APPLICATION sp_approlepassword 55

ROLE
sp_password sp_password 46
ALTER LOGIN
Security sp_changeobjectowne ALTER SCHEMA or sp_changeobjectowne 58

r ALTER r
AUTHORIZATION
Security sp_control_dbmasterk A master key must sp_control_dbmasterk 274

ey_password exist and password ey_password
must be correct.
Security sp_defaultdb ALTER LOGIN sp_defaultdb 47
sp_defaultlanguage sp_defaultlanguage 48
Security sp_denylogin ALTER LOGIN sp_denylogin 42

DISABLE
sp_grantlogin sp_grantlogin 41
CREATE LOGIN
sp_revokelogin sp_revokelogin 43
DROP LOGIN
Security USER_ID DATABASE_PRINCIPA USER_ID 16

L_ID
Security sp_srvrolepermission These stored sp_srvrolepermission 61

procedures return
sp_dbfixedrolepermiss information that was sp_dbfixedrolepermiss 60
ion correct in SQL Server ion
2000. The output
does not reflect
changes to the
permissions hierarchy
implemented in SQL
Server 2008. For
Permissions of Fixed
Server Roles.
Security GRANT ALL GRANT, DENY, and ALL Permission 35

REVOKE specific
DENY ALL permissions.
REVOKE ALL
Security PERMISSIONS Query PERMISSIONS 170

intrinsic function sys.fn_my_permission
s instead.
Security SETUSER EXECUTE AS SETUSER 165

Security RC4 and DESX Use another DESX algorithm 238

encryption algorithms algorithm such as
AES.
SET options SET FMTONLY sys.dm_exec_describe SET FMTONLY 250

_first_result_set
(Transact-SQL),
sys.dm_exec_describe
_first_result_set_for_o
bject (Transact-SQL),
sp_describe_first_resul
t_set (Transact-SQL),
and
sp_describe_undeclare
d_parameters
(Transact-SQL).
Server Configuration c2 audit option common criteria sp_configure 'c2 audit 252
Options compliance enabled mode'
default trace enabled Server Configuration 253
option Option sp_configure 'default
trace enabled'
Extended Events
SMO classes Microsoft.SQLServe Microsoft.SqlServer None None

r. .
Management.Smo.I Management.Smo.S
nformation class erver class
r. .
Management.Smo.S Management.Smo.S
ettings class erver class
r.Management. .
Smo.DatabaseOptio Management.Smo.
ns class Database class
Microsoft.SqlServer None
.Management.Smo.
DatabaseDdlTrigger
.NotForReplication
property
SQL Server Agent net send notification E-mail notification None None
Pager notification E-mail notification
SQL Server Solution Explorer None None

Management Studio integration in SQL
Server Management
Studio
System Stored sp_db_increased_parti None. Support for sp_db_increased_parti 253

Procedures tions increased partitions is tions
available by default in
SQL Server 2017.
System tables sysaltfiles Compatibility views. sysaltfiles 141

For more information,
syscacheobjects see Compatibility syscacheobjects None
Views (Transact-SQL).
syscolumns syscolumns 133
** Important *\* The
syscomments compatibility views do syscomments 126
not expose metadata
sysconfigures for features that were sysconfigures 146
introduced in SQL
sysconstraints Server 2005. We sysconstraints 131
recommend that you
syscurconfigs upgrade your syscurconfigs 147
applications to use
sysdatabases catalog views. For sysdatabases 142
sysdepends Catalog Views sysdepends 123
(Transact-SQL).
sysdevices sysdevices 144
sysfilegroups sysfilegroups 128
sysfiles sysfiles 127
sysforeignkeys sysforeignkeys 130
sysfulltextcatalogs sysfulltextcatalogs 122
sysindexes sysindexes 132
sysindexkeys sysindexkeys 134
syslockinfo syslockinfo 143
syslogins syslogins 140
sysmembers sysmembers 119
sysmessages sysmessages 137
sysobjects sysobjects 125
sysoledbusers sysoledbusers 139
sysopentapes sysopentapes 145
sysperfinfo sysperfinfo 157
syspermissions syspermissions 121
sysprocesses sysprocesses 153
sysprotects sysprotects 120
sysreferences sysreferences 129
sysremotelogins sysremotelogins 138
sysservers sysservers 136
systypes systypes 135

System tables sys.numbered_proced None numbered_procedure 148
ures s
149
sys.numbered_proced numbered_procedure
ure_parameters _parameters
System functions fn_virtualservernodes sys.dm_os_cluster_no fn_virtualservernodes 155

des
fn_servershareddrives fn_servershareddrives 156
sys.dm_io_cluster_sha
red_drives
System views sys.sql_dependencies sys.sql_expression_de sys.sql_dependencies 198

pendencies
Table compression The use of the Vardecimal storage Vardecimal storage 200
vardecimal storage format is deprecated. format
format. SQL Server 2017 data
compression,
compresses decimal
values as well as
other data types. We
recommend that you
instead of the
vardecimal storage
format.
Table compression Use of the Vardecimal storage sp_db_vardecimal_sto 201

sp_db_vardecimal_sto format is deprecated. rage_format
rage_format SQL Server 2017 data
procedure. compression,
compresses decimal
values as well as
other data types. We
recommend that you
instead of the
vardecimal storage
format.
Table compression Use of the Use data compression sp_estimated_rowsize 202

sp_estimated_rowsize and the _reduction_for_vardeci
_reduction_for_vardec sp_estimate_data_co mal
imal procedure. mpression_savings
procedure instead.
Table hints Specifying NOLOCK Remove the NOLOCK NOLOCK or 1

or or READUNCOMMITTED
READUNCOMMITTED READUNCOMMITTED in UPDATE or DELETE
in the FROM clause of table hints from the
an UPDATE or FROM clause.
DELETE statement.
Table hints Specifying table hints Use WITH. Table hint without 8
without using the WITH
WITH keyword.
Table hints INSERT_HINTS INSERT_HINTS 34

Textpointers WRITETEXT None UPDATETEXT or 115

WRITETEXT
UPDATETEXT 114
READTEXT
READTEXT
Textpointers TEXTPTR() None TEXTPTR 5
TEXTVALID() TEXTVALID 6
Transact-SQL :: function-calling Replaced by SELECT '::' function calling 166

sequence column_list FROM syntax
sys.<function_name>
().
For example, replace

SELECT * FROM
::fn_virtualfilestats(2,1)
with
SELECT * FROM
sys.fn_virtualfilestats(2,1)
.
Transact-SQL Three-part and four- Two-part names is More than two-part 3

part column the standard- column name
references. compliant behavior.
Transact-SQL A string enclosed in expression [AS] String literals as 184

quotation marks used column_alias column aliases
as a column alias for
an expression in a expression [AS]
SELECT list: [column_alias]
'string_alias' = expression [AS]

expression "column_alias"
expression [AS]
'column_alias'
column_alias =
expression
Transact-SQL Numbered None. Do not use. ProcNums 160

procedures
Transact-SQL table_name.index_na index_name ON DROP INDEX with 163

me syntax in DROP table_name syntax in two-part name
INDEX DROP INDEX.
Transact-SQL Not ending Transact- End Transact-SQL None None

SQL statements with statements with a
a semicolon. semicolon ( ; ).
Transact-SQL GROUP BY ALL Use custom case-by- GROUP BY ALL 169

case solution with
UNION or derived
table.
Transact-SQL ROWGUIDCOL as a Use $rowguid. ROWGUIDCOL 182

column name in DML
statements.
Transact-SQL IDENTITYCOL as a Use $identity. IDENTITYCOL 183

column name in DML
statements.
Transact-SQL Use of #, ## as Use at least one '#' and '##' as the 185
temporary table and additional character. name of temporary
temporary stored tables and stored
procedure names. procedures
Transact-SQL Use of @, @@, or Do not use @ or @@ '@' and names that 186.
@@ as Transact-SQL or names that begin start with '@@' as
identifiers. with @@ as Transact-SQL
identifiers. identifiers
Transact-SQL Use of DEFAULT Do not use the word DEFAULT keyword as 187
keyword as default DEFAULT as a default a default value
value. value.
Transact-SQL Use of a space as a Use a comma to Multiple table hints 168

separator between separate table hints. without comma
table hints.
Transact-SQL The select list of an Use COUNT_BIG (*). Index view select list 2
aggregate indexed without
view must contain COUNT_BIG(*)
COUNT_BIG (*) in 90
compatibility mode
Transact-SQL The indirect None. Indirect TVF hints 7

application of table
hints to an invocation
of a multi-statement
table-valued function
(TVF) through a view.
Transact-SQL ALTER DATABASE MODIFY FILEGROUP MODIFY FILEGROUP 195

syntax: READ_ONLY READONLY
196
MODIFY FILEGROUP MODIFY FILEGROUP MODIFY FILEGROUP
READONLY READ_WRITE READWRITE
MODIFY FILEGROUP
READWRITE
Other DB-Library Although the None None

Database Engine still
Embedded SQL for C supports connections
from existing
applications that use
the DB-Library and
Embedded SQL APIs,
it does not include
the files or
documentation
required to do
programming work
on applications that
use these APIs. A
future version of the
SQL Server Database
Engine will drop
support for
connections from DB-
Library or Embedded
SQL applications. Do
not use DB-Library or
Embedded SQL to
develop new
applications. Remove
any dependencies on
either DB-Library or
Embedded SQL when
you are modifying
existing applications.
Instead of these APIs,
use the SQLClient
namespace or an API
such as ODBC. SQL
Server 2017 does not
include the DB-
Library DLL required
to run these
applications. To run
DB-Library or
Embedded SQL
applications, you
must have available
the DB-Library DLL
from SQL Server
version 6.5, SQL
Server 7.0, or SQL
Server 2000.
Tools SQL Server Profiler for Use Extended Events SQL Server Profiler None
Trace Capture Profiler embedded in
SQL Server
Management Studio.
Tools SQL Server Profiler for SQL Server SQL Server Profiler None
Trace Replay Distributed Replay
Trace Management Microsoft.SqlServer.M Trace Configuration:

Objects anagement.Trace Microsoft.SqlServer.M
namespace (contains anagement.XEvent
the APIs for SQL
Server Trace and Trace Reading:
Replay objects) Microsoft.SqlServer.XE
vent.Linq
Trace Replay: None
SQL Trace stored sp_trace_create Extended Events sp_trace_create 258

procedures, functions,
and catalog views sp_trace_setevent sp_trace_setevent 260
sp_trace_setfilter sp_trace_setfilter 261
sp_trace_setstatus sp_trace_setstatus 259
fn_trace_geteventinfo fn_trace_geteventinfo 256
fn_trace_getfilterinfo fn_trace_getfilterinfo 257
fn_trace_getinfo fn_trace_getinfo
fn_trace_gettable fn_trace_gettable
sys.traces sys.traces
sys.trace_events sys.trace_events
sys.trace_event_bindi sys.trace_event_bindin
ngs gs
sys.trace_categories sys.trace_categories
sys.trace_columns sys.trace_columns
sys.trace_subclass_val sys.trace_subclass_val
ues ues
NOTE
The cookie OUTPUT parameter for sp_setapprole is currently documented as varbinary(8000) which is the correct
maximum length. However the current implementation returns varbinary(50). If developers have allocated varbinary(50)
the application might require changes if the cookie return size increases in a future release. Though not a deprecation issue
this is mentioned in this topic because the application adjustments are similar. For more information, see sp_setapprole
(Transact-SQL).
See Also
Discontinued Database Engine Functionality in SQL
Server 2016
This topic describes the Database Engine features that are no longer available in SQL Server 2017.
Discontinued Features in SQL Server 2016

SQL Server 2016 is a 64-bit application. 32-bit installation is discontinued, though some elements run as
32-bit components.
Compatibility level 90 is discontinued. For more information, see ALTER DATABASE Compatibility Level
(Transact-SQL).
ActiveX subsytem is discontinued. Use command line or PowerShell scripts instead.
Previous Versions
See Also
Deprecated Database Engine Features in SQL Server 2016
Deprecated Features in SQL Server Replication
Breaking Changes to Database Engine Features in
SQL Server 2017
This topic describes breaking changes in the SQL Server 2017 Database Engine. These changes might break
applications, scripts, or functionalities that are based on earlier versions of SQL Server. You might encounter these
issues when you upgrade.
Breaking Changes in SQL Server 2017 Database Engine

CLR uses Code Access Security (CAS) in the .NET Framework, which is no longer supported as a security
boundary. Beginning with SQL Server 2017 Database Engine, an sp_configure option called
clr strict security is introduced to enhance the security of CLR assemblies. clr strict security is enabled by
default, and treats SAFE and EXTERNAL_ACCESS CLR assemblies as if they were marked UNSAFE . The
clr strict security option can be disabled for backward compatibility, but this is not recommended. When
clr strict security is disabled, a CLR assembly created with PERMISSION_SET = SAFE may be able to access
external system resources, call unmanaged code, and acquire sysadmin privileges. After enabling strict security,
any assemblies that are not signed will fail to load. Also, if a database has SAFE or EXTERNAL_ACCESS assemblies,
RESTORE or ATTACH DATABASE statements can complete, but the assemblies may fail to load.
To load the assemblies, you must either alter or drop and recreate each assembly so that it is signed with a
certificate or asymmetric key that has a corresponding login with the UNSAFE ASSEMBLY permission on the
server. For more information, see CLR strict security.
Previous Versions
Breaking Changes to Database Engine Features in SQL Server 2016
See Also
ALTER DATABASE Compatibility Level (Transact-SQL)
Breaking Changes to Database Engine Features in
SQL Server 2016
This topic describes breaking changes in the SQL Server 2017 Database Engine and earlier versions of SQL Server.
These changes might break applications, scripts, or functionalities that are based on earlier versions of SQL Server.
You might encounter these issues when you upgrade.
Breaking Changes in SQL Server 2016

The sample_ms column of sys.dm_io_virtual_file_stats has expanded from an int to a bigint data type.
The TimeStamp column of sys.fn_virtualfilestats has expanded from an int to a bigint data type.
Using the MD2, MD4, MD5, SHA, or SHA1 hash algorithms (not recommended) requires setting the
database compatibility level to earlier than 130.
Under database compatibility level 130, implicit conversions from datetime to datetime2 data types show
improved accuracy by accounting for the fractional milliseconds, resulting in different converted values. Use
explicit casting to datetime2 datatype whenever a mixed comparison scenario between datetime and
datetime2 datatypes exists. For more information, refer to this Microsoft Support Article.
Previous Versions
See Also
ALTER DATABASE Compatibility Level (Transact-SQL)
SQL Server 2016 or SQL Server 2017 on Windows improvements in handling some data types and uncommon
operations
New and Recently Updated: Database Engine docs
Nearly every day Microsoft updates some of its existing articles on its Docs.Microsoft.com documentation website.
This article displays excerpts from recently updated articles. Links to new articles might also be listed.
This article is generated by a program that is rerun periodically. Occasionally an excerpt can appear with imperfect
formatting, or as markdown from the source article. Images are never displayed here.
Recent updates are reported for the following date range and subject:
Date range of updates: 2017-09-28 -to- 2017-12-02
Subject area: Database Engine.
New Articles Created Recently

The following links jump to new articles that have been added recently.
There are no new articles to list, this time.
Updated Articles with Excerpts

This section displays the excerpts of updates gathered from articles that have recently experienced a large update.
The excerpts displayed here appear separated from their proper semantic context. Also, sometimes an excerpt is
separated from important markdown syntax that surrounds it in the actual article. Therefore these excerpts are for
general guidance only. The excerpts only enable you to know whether your interests warrant taking the time to
click and visit the actual article.
For these and other reasons, do not copy code from these excerpts, and do not take as exact truth any text excerpt.
Instead, visit the actual article.
Compact List of Articles Updated Recently

This compact list provides links to all the updated articles that are listed in the Excerpts section.
1. optimize for ad hoc workloads Server Configuration Option
1. optimize for ad hoc workloads Server Configuration Option

Updated: 2017-11-20
Recommendations
If the number of single-use plans take a significant portion of ..!NCLUDE-NotShown--ssDEnoversion--
../../includes/ssdenoversion-md.md)] memory in an OLTP server, and these plans are Ad-hoc plans, use this server
option to decrease memory usage with these objects. To find the number of single-use cached plans, run the
following query:
SELECT objtype, cacheobjtype,

AVG(usecounts) AS Avg_UseCount,
SUM(refcounts) AS AllRefObjects,
SUM(CAST(size_in_bytes AS bigint))/1024/1024 AS Size_MB
FROM sys.dm_exec_cached_plans
WHERE objtype = 'Adhoc' AND usecounts = 1
GROUP BY objtype, cacheobjtype;
IMPORTANT
Setting the optimize for ad hoc workloads to 1 affects only new plans; plans that are already in the plan cache are
unaffected. To affect already cached query plans immediately, the plan cache needs to be cleared using [ALTER DATABASE
SCOPED CONFIGURATION CLEAR PROCEDURE_CACHE--../../t-sql/statements/alter-database-scoped-configuration-
transact-sql.md), or ..!NCLUDE-NotShown--ssNoVersion--../../includes/ssnoversion-md.md)] has to restart.
Similar Articles
This section lists very similar articles for recently updated articles in other subject areas, within our public
GitHub.com repository: MicrosoftDocs/sql-docs.
Subject areas which do have new or recently updated articles
New + Updated (3+14): Advanced Analytics for SQL docs
New + Updated (1+0): Analysis Services for SQL docs
New + Updated (87+0): Analytics Platform System for SQL docs
New + Updated (5+4): Connect to SQL docs
New + Updated (0+1): Database Engine for SQL docs
New + Updated (2+2): Integration Services for SQL docs
New + Updated (10+9): Linux for SQL docs
New + Updated (2+4): Relational Databases for SQL docs
New + Updated (4+2): Reporting Services for SQL docs
New + Updated (0+1): Samples for SQL docs
New + Updated (21+0): SQL Operations Studio docs
New + Updated (5+1): Microsoft SQL Server docs
New + Updated (0+1): SQL Server Data Tools (SSDT) docs
New + Updated (1+0): SQL Server Migration Assistant (SSMA) docs
New + Updated (0+1): SQL Server Management Studio (SSMS) docs
New + Updated (0+2): Transact-SQL docs
Subject areas which have no new or recently updated articles
New + Updated (0+0): Data Migration Assistant (DMA) for SQL docs
New + Updated (0+0): ActiveX Data Objects (ADO) for SQL docs
New + Updated (0+0): Data Quality Services for SQL docs
New + Updated (0+0): Data Mining Extensions (DMX) for SQL docs
New + Updated (0+0): Master Data Services (MDS) for SQL docs
New + Updated (0+0): Multidimensional Expressions (MDX) for SQL docs
New + Updated (0+0): ODBC (Open Database Connectivity) for SQL docs
New + Updated (0+0): PowerShell for SQL docs
New + Updated (0+0): Tools for SQL docs
New + Updated (0+0): XQuery for SQL docs
1 min to read •
Edit O nline
Configure Database Engine Instances (SQL Server)
THIS TOPIC APPLIES TO: SQL Server Azure SQL Database Azure SQL Data Warehouse Parallel Data
Warehouse
Each instance of the Database Engine must be configured to meet the performance and availability requirements
defined for the databases hosted by the instance. The Database Engine includes configuration options that control
behaviors such as resource usage and the availability of features such as auditing or trigger recursion.
Instance Configuration
When a database is deployed into production there is often a service level agreement (SLA) defining areas such as
the levels of performance required from the database and the required availability level of the database. The terms
of the SLA typically drive configuration requirements for the instance.
An instance is usually configured immediately after it has been installed. The initial configuration is usually
determined by the SLA requirements of the types of databases planned to be deployed to the instance. After the
databases have been deployed, the database administrators monitor the performance of the instance and adjust
the configuration settings as needed if the performance metrics show the instance is not meeting the SLA
requirements.
Configuration Tasks
TASK DESCRIPTION TOPIC
Describes the various instance configuration options and how Server Configuration Options (SQL Server)
to view or change these options.
Describes how to view and configure the default locations of View or Change the Default Locations for Data and Log Files
new data and log files in the instance. (SQL Server Management Studio)
Describes how to configure SQL Server to use soft-NUMA. Soft-NUMA (SQL Server)
Describes how to map a TCP/IP port to non-uniform memory Map TCP IP Ports to NUMA Nodes (SQL Server)
access (NUMA) node affinity.
Describes how to enable the Windows Lock Pages In Memory Enable the Lock Pages in Memory Option (Windows)
policy. This policy determines which accounts can use a
process to keep data in physical memory, preventing the
system from paging the data to virtual memory on disk.
See Also
Database Engine Instances (SQL Server)
Business continuity and database recovery - SQL
Server
This article provides an overview of business continuity solutions for high availability and disaster recovery in SQL
Server.
One common task everyone deploying SQL Server has to account for is making sure that all mission critical SQL
Server instances and the databases within them are available when the business and end users need them, whether
that is 9 to 5 or around the clock. The goal is to keep the business up and running with minimal or no interruption.
This concept is also known as business continuity.
SQL Server 2017 introduces many new features or enhancements to existing ones, some of which are for
availability. The biggest addition to SQL Server 2017 is the support for SQL Server on Linux distributions. For a full
list of the new features in SQL Server 2017, see the topic What's new in SQL Server.
This article is focused on covering the availability scenarios in SQL Server 2017 as well as the new and enhanced
availability features in SQL Server 2017. The scenarios include hybrid ones that will be able to span SQL Server
deployments on both Windows Server and Linux, as well as ones that can increase the number of readable copies
of a database. While this article does not cover availability options external to SQL Server, such as those provided
by virtualization, everything discussed here applies to SQL Server installations inside a guest virtual machine
whether in the public cloud or hosted by anon premises hypervisor server.
SQL Server 2017 scenarios using the availability features

Availability groups, FCIs, and log shipping can be used in a variety of ways, and not necessarily just for availability
purposes. There are four main ways the availability features can be used:
High availability
Disaster recovery
Migrations and upgrades
Scaling out readable copies of one or more databases
Each section will discuss the relevant features that can be used for that particular scenario. The one feature not
covered is SQL Server replication. While not officially designated as an availability feature under the Always On
umbrella, it is often used for making data redundant in certain scenarios. Replication will be added to SQL Server
on Linux in a future release.
IMPORTANT
The SQL Server availability features do not replace the requirement to have a robust, well tested backup and restore strategy,
the most fundamental building block of any availability solution.
High availability
Ensuring that SQL Server instances or database are available in the case of a problem that is local to a data center
or single region in the cloud region is important. This section will cover how the SQL Server availability features can
assist in that task. All of the features described are available both on Windows Server as well as on Linux.
Always on availability groups
Introduced in SQL Server 2012, Always On Availability Groups (availability groups) provide database-level
protection by sending each transaction of a database to another instance, known as a replica, that contains a copy
of that database in a special state. An availability group can be deployed on Standard or Enterprise Editions. The
instances participating in an availability group can be either standalone or Always On Failover Cluster Instances
(FCIs, described in the next section). Since the transactions are sent to a replica as they happen, availability groups
are recommended where there are requirements for lower recovery point and recovery time objectives. Data
movement between replicas can be synchronous or asynchronous, with Enterprise Edition allowing up to three
replicas (including the primary) as synchronous. An availability group has one fully read/write copy of the database
which is on the primary replica, while all secondary replicas cannot receive transactions directly from end users or
applications.
NOTE
Always On is an umbrella term for the availability features in SQL Server and covers both availability groups and FCIs. Always
On is not the name of the availability group feature.
Because availability groups only provide database-level, and not instance-level, protection, anything not captured in
the transaction log or configured in the database will need to manually synchronized for each secondary replica.
Some examples of objects that must be synchronized manually are logins at the instance level, linked servers, and
SQL Server Agent jobs.
An availability group also has another component called the listener, which allows applications and end users to
connect without needing to know which SQL Server instance is hosting the primary replica. Each availability group
would have its own listener. While the implementations of the listener are slightly different on Windows Server
versus Linux, the functionality it provides and how it is used is the same. The picture below shows a Windows
Server-based availability group which is using a Windows Server Failover Cluster (WSFC). An underlying cluster at
the OS layer is required for availability whether it is on Linux or Windows Server. The example shows a simple two
server, or node, configuration where a WSFC is the underlying cluster.
Standard and Enterprise Edition have different maximums when it comes to replicas. An availability group in
Standard Edition, known as a Basic Availability Group, supports two replicas (one primary and one secondary) with
only a single database in the availability group. Enterprise Edition not only allows multiple databases to be
configured in a single availability group, but also can have up to nine total replicas (one primary, eight secondary).
Enterprise edition also provides other optional benefits such as readable secondary replicas, the ability to make
backups off of a secondary replica, and more.
NOTE
Database mirroring, which was deprecated in SQL Server 2012, is not available on the Linux version of SQL Server nor will it
be added. Customers still using database mirroring should start planning to migrate to availability groups, which is the
replacement for database mirroring.
When it comes to availability, availability groups can provide either automatic or manual failover. Automatic
failover can occur if synchronous data movement is configured and the database on the primary and secondary
replica are in a synchronized state. As long as the listener is used and the application uses a later version of .NET
(3.5 with an update, or 4.0 and above), the failover should be handled with minimal to no impact to end users if a
listener is utilized. Failover to make a secondary replica the new primary replica can be configured to be automatic
or manual, and generally is measured in seconds.
The list below highlights some differences with availability groups on Windows Server versus Linux:
Due to differences in the way the underlying cluster works on Linux and Windows Server, all failovers (manual
or automatic) of availability groups are done via the cluster on Linux. On Windows Server-based availability
group deployments, manual failovers must be done via SQL Server. Automatic failovers are handled by the
underlying cluster on both Windows Server and Linux.
In SQL Server 2017, the recommended configuration for availability groups on Linux will be a minimum of three
replicas. This is due to the way that the underlying clustering works. An improved solution for a two replica
configuration will come post-release.
On Linux, the common name used by each listener is defined in DNS and not in the cluster like it is on Windows
Server.
In SQL Server 2017, there are some new features and enhancements to availability groups:
Cluster types
REQUIRED_SECONDARIES_TO_COMMIT
Enhanced Microsoft Distributor Transaction Coordinator (DTC) support for Windows Server-based
configurations
Additional scale out scenarios for read only databases (described later in this article)
A l w a y s o n a v a i l a b i l i t y g r o u p c l u st e r t y p e s
The built-in availability form of clustering in Windows Server is enabled via a feature named Failover Clustering. It
allows you to build a WSFC to be used with an availability group or FCI. Integration for availability groups and FCIs
is provided by a cluster-aware resource DLLs shipped by SQL Server.
Each supported Linux distribution ships its own version of the Pacemaker cluster solution. SQL Server 2017 on
Linux supports the use of Pacemaker. Pacemaker is an open stack solution that each distribution can then integrate
with their stack. While the distributions ship Pacemaker, it is not as integrated as the Failover Clustering feature in
Windows Server.
A WSFC and Pacemaker are more similar than different. Both provide a way to take individual servers and combine
them in a configuration to provide availability, and have concepts of things like resources, constraints (even if
implemented differently), failover, and so on. To support Pacemaker for both availability group and FCI
configurations including things like automatic failover, Microsoft provides the mssql-server-ha package, which is
similar to, but not exactly the same as, the resource DLLs in a WSFC, for Pacemaker. One of the differences between
a WSFC and Pacemaker is that there is no network name resource in Pacemaker, which is the component that helps
to abstract the name of the listener (or the name of the FCI) on a WSFC. DNS provides that name resolution on
Linux.
Because of the difference in the cluster stack, some changes needed to be made for availability groups because SQL
Server has to handle some of the metadata that is natively handled by a WSFC. The most [!IMPORTANT] change is
the introduction of a cluster type for an availability group. This is stored in sys.availability_groups in the
cluster_type and cluster_type_desc columns. There are three cluster types:
WSFC
External
None
All availability groups that require availability must use an underlying cluster, which in the case of SQL Server 2017
means a WSFC or Pacemaker. For Windows Server-based availability groups that use an underlying WSFC, the
default cluster type is WSFC and does not need to be set. For Linux-based availability groups, when creating the
availability group, the cluster type must be set to External. The integration with Pacemaker is configured after the
availability group is created, whereas on a WSFC, it is done at creation time.
A cluster type of None can be used with both Windows Server and Linux availability groups. Setting the cluster type
to None means that the availability group does not require an underlying cluster. This means SQL Server 2017 is
the first version of SQL Server to support availability groups without a cluster, but the tradeoff is that this
configuration is not supported as a high availability solution.
IMPORTANT
SQL Server 2017 does not allow the ability to change a cluster type for an availability group after it is created. This means
that an availability group cannot be switched from None to External or WSFC, or vice versa.
For those who are only looking to just add additional read only copies of a database, or like what an availability
group provides for migration/upgrades but do not want to be tied to the additional complexity of an underlying
cluster or even the replication, an availability group with a cluster type of None is a perfect solution. For more
information, see the sections Migrations and Upgrades and read-scale.
The screenshot below shows the support for the different kinds of cluster types in SSMS. You must be running
version 17.1 or later. The screenshot below is from version 17.2.
R E Q U I R E D _ SY N C H R O N I Z E D _ SE C O N D A R I E S_ T O _ C O M M I T
SQL Server 2016 increased support for the number of synchronous replicas from two to three in Enterprise Edition.
However, if one secondary replica was synchronized but the other was having a problem, there was no way to
control the behavior to tell the primary to either wait for the misbehaving replica or to allow it to move on. This
means that the primary replica at some point would continue to receive write traffic even though the secondary
replica would not be in a synchronized state, which means that there is data loss on the secondary replica. In SQL
Server 2017, there is now an option to be able to control the behavior of what happens when there are
synchronous replicas named REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT. The option works as
follows:
There are three possible values: 0, 1, and 2
The value is the number of secondary replicas that must be synchronized, which has implications for data loss,
availability group availability, and failover
For WSFCs and a cluster type of None, the default value is 0, and can be manually set to 1 or 2
For a cluster type of External, by default, the cluster mechanism will set this and it can be overridden manually.
For three synchronous replicas, the default value will be 1. On Linux, the value for
REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT is configured on the availability group resource in
the cluster. On Windows, it is set via Transact-SQL.
A value that is higher than 0 ensures higher data protection because if the required number of secondary replicas is
not available, the primary will not be available until that is resolved.
REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT also affects failover behavior since automatic failover
could not occur if the right number of secondary replicas were not in the proper state. On Linux, a value of 0 will
not allow automatic failover, so on Linux, when using synchronous with automatic failover, the value must be set
higher than 0 to achieve automatic failover. 0 on Windows Server is the SQL Server 2016 and earlier behavior.
En h a n c e d M i c r o so ft d i st r i b u t e d t r a n sa c t i o n c o o r d i n a t o r su p p o r t
Before SQL Server 2016, the only way to get availability in SQL Server for applications that require distributed
transactions which use DTC underneath the covers was to deploy FCIs. A distributed transaction can be done in one
of two ways:
A transaction that spans more than one database in the same SQL Server instance
A transaction that spans more than one SQL Server instance or possibly involves a non-SQL Server data source
SQL Server 2016 introduced partial support for DTC with availability groups that covered the latter scenario. SQL
Server 2017 completes the story by supporting both scenarios with DTC.
Another enhancement to DTC support for availability groups is that in SQL Server 2016, enabling support for DTC
to an availability group could only be done when the availability group was created, and could not be added later.
In SQL Server 2017, DTC support can also be added to an availability group after it is created.
NOTE
DTC support can only be configured for databases in Windows Server-based SQL Server instances. If DTC is an requirement
for your application, you must use Windows Server as the OS for your SQL Server deployment, and cannot use Linux.
Always on failover cluster instances

Clustered installations have been a feature of SQL Server since version 6.5. FCIs are a proven method of providing
availability for the entire installation of SQL Server, known as an instance. This means that everything inside the
instance, including databases, SQL Server Agent jobs, linked servers, et al., will move to another server should the
underlying server encounter a problem. All FCIs require some sort of shared storage, even if it is provided via
networking. The FCI’s resources can only be running and owned by one node at any given time. In the picture
below, the first node of the cluster owns the FCI, which also means it owns the shared storage resources associated
with it denoted by the solid line to the storage.
After a failover, ownership changes as is seen in the picture below.

There is zero data loss with an FCI, but the underlying shared storage is a single point of failure since there is one
copy of the data. FCIs are often combined with another availability method, such as an availability group or log
shipping, to have redundant copies of databases. The additional method deployed should use physically separate
storage from the FCI. When the FCI fails over to another node, it stops on one node and starts on another, not
unlike powering a server off and turning it on. An FCI goes through the normal recovery process, meaning any
transactions that need to be rolled forward will be, and any transactions that are incomplete will be rolled back.
Therefore, the database is consistent from a data point to the time of the failure or manual failover, hence no data
loss. Databases are only available after recovery is complete, so recovery time will depend on many factors, and will
generally be longer than failing over an availability group. The tradeoff is that when you fail over an availability
group, there may be additional tasks required to make a database usable, such as enabling a SQL Server Agent jobs
job.
Like an availability group, FCIs abstract which node of the underlying cluster is hosting it. An FCI always retains the
same name. Applications and end users never connect to the nodes; the unique name assigned to the FCI is used.
An FCI can participate in an availability group as one of the instances hosing either a primary or secondary replica.
The list below highlights some differences with FCIs on Windows Server versus Linux:
On Windows Server, an FCI is part of the installation process. An FCI on Linux is configured after installing SQL
Server.
Linux only supports a single installation of SQL Server per host, so all FCIs will be a default instance. Windows
Server supports up to 25 FCIs per WSFC.
The common name used by FCIs in Linux is defined in DNS, and should be the same as the resource created for
the FCI.
Log shipping
If recovery point and recovery time objectives are more flexible, or databases are not considered to be highly
mission critical, log shipping is another proven availability feature in SQL Server. Based on SQL Server’s native
backups, the process for log shipping automatically generates transaction log backups, copies them to one or more
instances known as a warm standby, and automatically applies the transaction log backups to that standby. Log
shipping uses SQL Server Agent jobs to automate the process of backing up, copying, and applying the transaction
log backups.
IMPORTANT
On Linux, SQL Server Agent jobs is not included as part of the installation of SQL Server itself. It is available in the package
mssql-server-Agent jobs which must also be installed to use log shipping.
Arguably the biggest advantage of using log shipping in some capacity is that it accounts for human error. The
application of transaction logs can be delayed. Therefore, if someone issues something like an UPDATE without a
WHERE clause, the standby may not have the change so you could switch to that while you repair the primary
system. While log shipping is easy to configure, switching from the primary to a warm standby, known as a role
change, is always manual. A role change is initiated via Transact-SQL, and like an availability group, all objects not
captured in the transaction log must be manually synchronized. Log shipping also needs to be configured per
database, whereas a single availability group can contain multiple databases. Unlike an availability group or FCI, log
shipping has no abstraction for a role change. Applications must be able to handle this. Techniques such as a DNS
alias (CNAME) could be employed, but there are pros and cons, such as the time it takes for DNS to refresh after the
switch.
Disaster recovery
When your primary availability location experiences a catastrophic event like an earthquake or flood, the business
must be prepared to have its systems come online elsewhere. This section will cover how the SQL Server
availability features can assist with business continuity.
One of the benefits of availability groups is that both high availability and disaster recovery can be configured
using a single feature. Without the requirement for ensuring that shared storage is also highly available, it is much
easier to have replicas that are local in one data center for high availability, and remote ones in other data centers
for disaster recovery each with separate storage. Having additional copies of the database is the tradeoff for
ensuring redundancy. An example of an availability group that spans multiple data centers is shown below. One
primary replica is responsible for keeping all secondary replicas synchronized.
Outside of an availability group with a cluster type of none, an availability group requires that all replicas are part of
the same underlying cluster whether it is a WSFC or Pacemaker. This means that in the picture above, the WSFC is
stretched to work in two different data centers which adds complexity. regardless of the platform (Windows Server
or Linux). Stretching clusters across distance adds complexity. Introduced in SQL Server 2016, a distributed
availability group allows an availability group to span availability groups configured on different clusters. This
decouples the requirement to have the nodes all participate in the same cluster, which makes configuring disaster
recovery much easier. For more information on distributed availability groups, see Distributed availability groups.

FCIs can be used for disaster recovery. As with a normal availability group, the underlying cluster mechanism must
also be extended to all locations which adds complexity. There is an additional consideration for FCIs: the shared
storage. The same disks need to be available in the primary and secondary sites, so an external method such as
functionality provided by the storage vendor at the hardware layer or using storage Replica in Windows Server, is
required to ensure that the disks used by the FCI exist elsewhere.
Log shipping
Log shipping is one of the oldest methods of providing disaster recovery for SQL Server databases. Log shipping is
often used in conjunction with availability groups and FCIs to provide cost-effective and simpler disaster recovery
where other options may be challenging due to environment, administrative skills, or budget. Similar to the high
availability story for log shipping, many environments will delay the loading of a transaction log to account for
human error.
Migrations and upgrades

When deploying new instances or upgrading old ones, a business cannot tolerate long outage. This section will
discuss how the availability features of SQL Server can be used to minimize the downtime in a planned architecture
change, server switch, platform change (such as Windows Server to Linux or vice versa), or during patching.
NOTE
Other methods, such as using backups and restoring them elsewhere, can also be used for migrations and upgrades. They
are not discussed in this paper.

An existing instance containing one or more availability groups can be upgraded in place to SQL Server 2017.
While this will require some amount of downtime, with the right amount of planning, it can be minimized.
If the goal is to migrate to new servers and not change the configuration (including the operating system or SQL
Server version), those servers could be added as nodes to the existing underlying cluster and added to the
availability group. Once the replica or replicas are in the right state, a manual failover could occur to a new server,
and then the old ones could be removed from the availability group, and ultimately, decommissioned.
Distributed AGs are also another method to migrate to a new configuration or upgrade SQL Server. Because a
distributed AG supports different underlying AGs on different architectures, for example, you could change from
SQL Server 2016 running on Windows Server 2012 R2 to SQL Server 2017 running on Windows Sever 2016.
Finally, availability groups with a cluster type of None can also be used for migration or upgrading. You cannot mix
and match cluster types in a typical availability group configuration, so all replicas would need to be a type of None.
A distributed availability group can be used to span availability groups configured with different cluster types. This
method is also supported across the different OS platforms.
All variants of availability groups for migrations and upgrades allow the most time consuming portion of the work
to be done over time – data synchronization. When it comes time to initiate the switch to the new configuration, the
cutover will be a brief outage versus one long period of downtime where all the work, including data
synchronization, would need to be completed.
Availability groups can provide minimal downtime during patching of the underlying OS by manually failing over
the primary to a secondary replica while the patching is being completed. From an operating system perspective,
doing this would be more common on Windows Server since often, but not always, servicing the underlying OS
may require a reboot. Patching Linux sometimes needs a reboot, but it can be infrequent.
Patching SQL Server instances participating in an availability group can also minimize downtime depending on
how complex the availability group architecture is. To patch servers participating in an availability group, a
secondary replica is patched first. Once the right number of replicas are patched, the primary replica is manually
failed over to another node to do the upgrade. Any remaining secondary replicas at that point can be upgraded,
too.
FCIs on their own cannot assist with a traditional migration or upgrade; an availability group or log shipping would
have to be configured for the databases in the FCI and all other objects accounted for. However, FCIs under
Windows Server are still a popular option for when the underlying Windows Servers need to be patched. A manual
failover can be initiated, which means a brief outage instead of having the instance completely unavailable for the
entire time Windows Server is being patched. An FCI can be upgraded in place to SQL Server 2017. For
information, see Upgrade a SQL Server Failover Cluster Instance.
Log shipping
Log shipping is still a popular option to both migrate and upgrade databases. Similar to availability groups, but this
time using the transaction log as the synchronization method, the data propagation can be started well in advance
of the server switch. At the time of the switch, once all traffic is stopped at the source, a final transaction log would
need to be taken, copied, and applied to the new configuration. At that point, the database can be brought online.
Log shipping is often more tolerant of slower networks, and while the switch may be slightly longer than one done
using an availability group or a distributed availability group, it is usually measured in minutes – not hours, days, or
weeks.
Similar to availability groups, log shipping can provide a way to switch to another server in the event of patching.
Other SQL Server deployment methods and availability
There are two other deployment methods for SQL Server on Linux: containers and using Azure (or another public
cloud provider). The general need for availability as presented throughout this paper exists regardless of how SQL
Server is deployed. These two methods have some special considerations when it comes to making SQL Server
highly available.
Containers using Docker are a new way of deploying SQL Server, either for Windows Server or Linux. A container is
a complete image of SQL Server that is ready to run. However, there is currently no native support for clustering,
and thus, direct high availability or disaster recovery. Currently, the options to make SQL Server databases available
using containers would be log shipping and backup and restore. While an availability group with a cluster type of
None can be configured, as noted earlier, it is not considered a true availability configuration. Microsoft is looking
at ways to enable availability groups or FCIs using containers.
If you are using containers today, if the container is lost, depending on the container platform, it can be deployed
again and attached to the shared storage that was used. Some of this mechanism is provided by the container
orchestrator. While this does provide some resiliency, there will be some downtime associated with database
recovery and is not truly highly available as it would be if using an availability group or FCI.
Linux IaaS virtual machines can be deployed with SQL Server installed using Azure. As with on premises-based
installations, a supported installation requires the use of STONITH (Shoot the Other Node in the Head) which is
external to Pacemaker itself. STONITH is provided via fencing availability agents. Some distributions ship them as
part of the platform, others rely on external hardware and software vendors. Check with your preferred Linux
distribution to see what forms of STONITH are provided so that a supported solution can be deployed in the public
cloud.
Cross-platform and Linux distribution interoperability

With SQL Server now supported on both Windows Server and Linux, this section covers the scenarios of how they
can work together for availability in addition to other purposes, as well as the story for solutions that will
incorporate more than one Linux distribution.
Before covering the cross-platform and interoperability scenarios, two facts need to be stated:
There are no scenarios where a WSFC-based FCI or availability group will work with a Linux-based FCI or
availability group directly. A WSFC cannot be extended by a Pacemaker node and vice versa.
Mixing Linux distributions is not supported with FCIs or an availability group that has a cluster type of External.
All availability group replicas in that scenario must be configured not only the same Linux distribution, but also
the same version. The two supported ways that SQL Server can operate across the two platforms or multiple
distributions of Linux are availability groups and log shipping.
Distributed availability groups
Distributed availability groups are designed to span availability group configurations, whether those two
underlying clusters underneath the availability groups are two different WSFCs, Linux distributions, or one on a
WSFC and the other on Linux. A distributed availability group will be the primary method of having a cross
platform solution. A distributed availability group is also the primary solution for migrations such as converting
from a Windows Server-based SQL Server infrastructure to a Linux-based one if that is what your company wants
to do. As noted above, availability groups, and especially distributed availability groups, would minimize the time
that an application would be unavailable for use. An example of a distributed availability group that spans a WSFC
and Pacemaker is shown below.
If an availability group is configured with a cluster type of None, it can span Windows Server and Linux as well as
multiple Linux distributions. Since this is not a true high availability configuration, it should not be used for mission
critical deployments, but for read-scale or migration/upgrade scenarios.
Log shipping
Since log shipping is just based on backup and restore, and there are no differences in the databases, file structures,
etc., for SQL Server on Windows Server versus SQL Server on Linux. This means that log shipping can be
configured between a Windows Server-based SQL Server installation and a Linux one as well as between
distributions of Linux. Everything else remains the same. The only caveat is that log shipping, just like an availability
group, cannot work when the source is at a higher SQL Server major version against a target that is at a lower
version of SQL Server.
read-scale
Since their introduction in SQL Server 2012, secondary replicas have had the ability to be used for read-only
queries. There are two ways that can be achieved with an availability group: by allowing direct access to the
secondary as well as configuring read only routing which requires the use of the listener. SQL Server 2016
introduced the ability to load balance read-only connections via the listener using a round robin algorithm,
allowing read-only requests to be spread across all readable replicas.
NOTE
Readable secondary replicas is a feature only in Enterprise Edition, and each instance hosting a readable replica would need a
SQL Server license.
Scaling readable copies of a database via availability groups was first introduced with distributed availability
groups in SQL Server 2016. This would allow companies to have read-only copies of the database not only locally,
but regionally and globally with a minimal amount of configuration and reduce network traffic and latency by
having queries executed locally. Each primary replica of an availability group can seed two other availability groups
even if it is not the fully read/write copy, so each distributed availability group can support up to 27 copies of the
data that are readable.
Starting with SQL Server 2017, It is possible to create a near-real time, read-only solution with availability groups
configured with a cluster type of None. If the goal is to use availability groups for readable secondary replicas and
not availability, doing this removes the complexity of using a WSFC or Pacemaker, and gives the readable benefits
of an availability group in a simpler deployment method.
The only major caveat is that due to no underlying cluster with a cluster type of None, configuring read only
routing is a little different. From a SQL Server perspective, a listener is still required to route the requests even
though there is no cluster. Instead of configuring a traditional listener, the IP address or name of the primary replica
is used. The primary replica is then used to route the read only requests.
A log shipping warm standby can technically be configured for readable usage by restoring the database WITH
STANDBY. However, because the transaction logs require exclusive use of the database for restoration, it means
that users cannot be accessing the database while that happens. This makes log shipping a less than ideal solution –
especially if near real-time data is required.
One thing that should be noted for all read-scale scenarios with availability groups is that unlike using transactional
replication where all of the data is live, each secondary replica is not in a state where unique indexes can be applied,
the replica is an exact copy of the primary. This means that if any indexes are required for reporting or data needs
to be manipulated, it must be done on the database(s) on the primary replica. If you need that flexibility, replication
is a better solution for readable data.
Summary
Instances and databases of SQL Server 2017 can be made highly available using the same features on both
Windows Server and Linux. Besides standard availability scenarios of local high availability and disaster recovery,
downtime associated with upgrades and migrations can be minimized with the availability features in SQL Server.
Availability groups can also provide additional copies of a database as part of the same architecture to scale out
readable copies. Whether you are deploying a new solution using SQL Server 2017 or considering an upgrade, SQL
Server 2017 has the availability and reliability you require.
Next steps
Availability groups
Failover clusters
Overview of Always On Availability Groups (SQL
Server)
Warehouse
For content related to previous versions of SQL Server, see Overview of AlwaysOn Availability Groups (SQL
Server).
This topic introduces the Always On availability groups concepts that are central for configuring and managing one
or more availability groups in SQL Server 2017. For a summary of the benefits offered by availability groups and
an overview of Always On availability groups terminology, see Always On Availability Groups (SQL Server).
An availability group supports a replicated environment for a discrete set of user databases, known as availability
databases. You can create an availability group for high availability (HA) or for read-scale. An HA availability group
is a group of databases that fail over together. A read-scale availability group is a group of databases that are
copied to other instances of SQL Server for read-only workload. An availability group supports one set of primary
databases and one to eight sets of corresponding secondary databases. Secondary databases are not backups.
Continue to back up your databases and their transaction logs on a regular basis.
TIP
You can create any type of backup of a primary database. Alternatively, you can create log backups and copy-only full
backups of secondary databases. For more information, see Active Secondaries: Backup on Secondary Replicas (Always On
Availability Groups).
Each set of availability database is hosted by an availability replica. Two types of availability replicas exist: a single
primary replica. which hosts the primary databases, and one to eight secondary replicas, each of which hosts a set
of secondary databases and serves as a potential failover targets for the availability group. An availability group
fails over at the level of an availability replica. An availability replica provides redundancy only at the database level
—for the set of databases in one availability group. Failovers are not caused by database issues such as a database
becoming suspect due to a loss of a data file or corruption of a transaction log.
The primary replica makes the primary databases available for read-write connections from clients. The primary
replica sends transaction log records of each primary database to every secondary database. This process - known
as data synchronization - occurs at the database level. Every secondary replica caches the transaction log records
(hardens the log) and then applies them to its corresponding secondary database. Data synchronization occurs
between the primary database and each connected secondary database, independently of the other databases.
Therefore, a secondary database can be suspended or fail without affecting other secondary databases, and a
primary database can be suspended or fail without affecting other primary databases.
Optionally, you can configure one or more secondary replicas to support read-only access to secondary databases,
and you can configure any secondary replica to permit backups on secondary databases.
SQL Server 2017 introduces two different architectures for availability groups. Always On availability groups
provide high availability, disaster recovery, and read-scale balancing. These availability groups require a cluster
manager. In Windows, failover clustering provides the cluster manager. In Linux, you can use Pacemaker. The other
architecture is a read-scale availability group. A read scale availability group provides replicas for read-only
workloads but not high availability. In a read-scale availability group there is no cluster manager.
Deploying Always On availability groups for HA on Windows requires a Windows Server Failover Cluster(WSFC).
Each availability replica of a given availability group must reside on a different node of the same WSFC. The only
exception is that while being migrated to another WSFC cluster, an availability group can temporarily straddle two
clusters.
NOTE
For information about availability groups on Linux, see Always On availability group for SQL Server on Linux .
In an HA configuration, a cluster role is created for every availability group that you create. The WSFC cluster
monitors this role to evaluate the health of the primary replica. The quorum for Always On availability groups is
based on all nodes in the WSFC cluster regardless of whether a given cluster node hosts any availability replicas. In
contrast to database mirroring, there is no witness role in Always On availability groups.
NOTE
For information about the relationship of SQL Server Always On components to the WSFC cluster, see Windows Server
Failover Clustering (WSFC) with SQL Server.
The following illustration shows an availability group that contains one primary replica and four secondary replicas.
Up to eight secondary replicas are supported, including one primary replica and two synchronous-commit
secondary replicas.
Availability Databases
To add a database to an availability group, the database must be an online, read-write database that exists on the
server instance that hosts the primary replica. When you add a database, it joins the availability group as a primary
database, while remaining available to clients. No corresponding secondary database exists until backups of the
new primary database are restored to the server instance that hosts the secondary replica (using RESTORE WITH
NORECOVERY). The new secondary database is in the RESTORING state until it is joined to the availability group.
For more information, see Start Data Movement on an Always On Secondary Database (SQL Server).
Joining places the secondary database into the ONLINE state and initiates data synchronization with the
corresponding primary database. Data synchronization is the process by which changes to a primary database are
reproduced on a secondary database. Data synchronization involves the primary database sending transaction log
records to the secondary database.
IMPORTANT
An availability database is sometimes called a database replica in Transact-SQL, PowerShell, and SQL Server Management
Objects (SMO) names. For example, the term "database replica" is used in the names of the Always On dynamic management
views that return information about availability databases: sys.dm_hadr_database_replica_states and
sys.dm_hadr_database_replica_cluster_states. However, in SQL Server Books Online, the term "replica" typically refers to
availability replicas. For example, "primary replica" and "secondary replica" always refer to availability replicas.
Availability Replicas
Each availability group defines a set of two or more failover partners known as availability replicas. Availability
replicas are components of the availability group. Each availability replica hosts a copy of the availability databases
in the availability group. For a given availability group, the availability replicas must be hosted by separate
instances of SQL Server residing on different nodes of a WSFC cluster. Each of these server instances must be
enabled for Always On.
A given instance can host only one availability replica per availability group. However, each instance can be used
for many availability groups. A given instance can be either a stand-alone instance or a SQL Server failover cluster
instance (FCI). If you require server-level redundancy, use Failover Cluster Instances.
Every availability replica is assigned an initial role—either the primary role or the secondary role, which is inherited
by the availability databases of that replica. The role of a given replica determines whether it hosts read-write
databases or read-only databases. One replica, known as the primary replica, is assigned the primary role and
hosts read-write databases, which are known as primary databases. At least one other replica, known as a
secondary replica, is assigned the secondary role. A secondary replica hosts read-only databases, known as
secondary databases.
NOTE
When the role of an availability replica is indeterminate, such as during a failover, its databases are temporarily in a NOT
SYNCHRONIZING state. Their role is set to RESOLVING until the role of the availability replica has resolved. If an availability
replica resolves to the primary role, its databases become the primary databases. If an availability replica resolves to the
secondary role, its databases become secondary databases.
Availability Modes
The availability mode is a property of each availability replica. The availability mode determines whether the
primary replica waits to commit transactions on a database until a given secondary replica has written the
transaction log records to disk (hardened the log). Always On availability groups supports two availability modes
—asynchronous-commit mode and synchronous-commit mode.
Asynchronous-commit mode
An availability replica that uses this availability mode is known as anasynchronous-commit replica. Under
asynchronous-commit mode, the primary replica commits transactions without waiting for
acknowledgement that an asynchronous-commit secondary replica has hardened the log. Asynchronous-
commit mode minimizes transaction latency on the secondary databases but allows them to lag behind the
primary databases, making some data loss possible.
Synchronous-commit mode
An availability replica that uses this availability mode is known as a synchronous-commit replica. Under
synchronous-commit mode, before committing transactions, a synchronous-commit primary replica waits
for a synchronous-commit secondary replica to acknowledge that it has finished hardening the log.
Synchronous-commit mode ensures that once a given secondary database is synchronized with the primary
database, committed transactions are fully protected. This protection comes at the cost of increased
transaction latency.
For more information, see Availability Modes (Always On Availability Groups).
Types of Failover
Within the context of a session between the primary replica and a secondary replica, the primary and secondary
roles are potentially interchangeable in a process known as failover. During a failover the target secondary replica
transitions to the primary role, becoming the new primary replica. The new primary replica brings its databases
online as the primary databases, and client applications can connect to them. When the former primary replica is
available, it transitions to the secondary role, becoming a secondary replica. The former primary databases become
secondary databases and data synchronization resumes.
Three forms of failover exist—automatic, manual, and forced (with possible data loss). The form or forms of
failover supported by a given secondary replica depends on its availability mode, and, for synchronous-commit
mode, on the failover mode on the primary replica and target secondary replica, as follows.
Synchronous-commit mode supports two forms of failover—planned manual failover and automatic
failover, if the target secondary replica is currently synchronized with the avt1. The support for these forms
of failover depends on the setting of the failover mode property on the failover partners. If failover mode is
set to "manual" on either the primary or secondary replica, only manual failover is supported for that
secondary replica. If failover mode is set to "automatic" on both the primary and secondary replicas, both
automatic and manual failover are supported on that secondary replica.
Planned manual failover (without data loss)
A manual failover occurs after a database administrator issues a failover command and causes a
synchronized secondary replica to transition to the primary role (with guaranteed data protection)
and the primary replica to transition to the secondary role. A manual failover requires that both the
primary replica and the target secondary replica are running under synchronous-commit mode, and
the secondary replica must already be synchronized.
Automatic failover (without data loss)
An automatic failover occurs in response to a failure that causes a synchronized secondary replica to
transition to the primary role (with guaranteed data protection). When the former primary replica
becomes available, it transitions to the secondary role. Automatic failover requires that both the
primary replica and the target secondary replica are running under synchronous-commit mode with
the failover mode set to "Automatic". In addition, the secondary replica must already be synchronized,
have WSFC quorum, and meet the conditions specified by the flexible failover policyof the availability
group.
IMPORTANT
SQL Server Failover Cluster Instances (FCIs) do not support automatic failover by availability groups, so any
availability replica that is hosted by an FCI can only be configured for manual failover.
NOTE
Note that if you issue a forced failover command on a synchronized secondary replica, the secondary replica behaves
the same as for a planned manual failover.
Under asynchronous-commit mode, the only form of failover is forced manual failover (with possible data
loss), typically called forced failover. Forced failover is considered a form of manual failover because it can
only be initiated manually. Forced failover is a disaster recovery option. It is the only form of failover that is
possible when the target secondary replica is not synchronized with the primary replica.
For more information, see Failover and Failover Modes (Always On Availability Groups).
Client Connections
You can provide client connectivity to the primary replica of a given availability group by creating an availability
group listener. An availability group listener provides a set of resources that is attached to a given availability
group to direct client connections to the appropriate availability replica.
An availability group listener is associated with a unique DNS name that serves as a virtual network name (VNN),
one or more virtual IP addresses (VIPs), and a TCP port number. For more information, see Availability Group
Listeners, Client Connectivity, and Application Failover (SQL Server).
TIP
If an availability group possesses only two availability replicas and is not configured to allow read-access to the secondary
replica, clients can connect to the primary replica by using a database mirroring connection string. This approach can be
useful temporarily after you migrate a database from database mirroring to Always On availability groups. Before you add
additional secondary replicas, you will need to create an availability group listener the availability group and update your
applications to use the network name of the listener.
Active Secondary Replicas

Always On availability groups supports active secondary replicas. Active secondary capabilities include support for:
Performing backup operations on secondary replicas
The secondary replicas support performing log backups and copy-only backups of a full database, file, or
filegroup. You can configure the availability group to specify a preference for where backups should be
performed. It is important to understand that the preference is not enforced by SQL Server, so it has no
impact on ad-hoc backups. The interpretation of this preference depends on the logic, if any, that you script
into your back jobs for each of the databases in a given availability group. For an individual availability
replica, you can specify your priority for performing backups on this replica relative to the other replicas in
the same availability group. For more information, see Active Secondaries: Backup on Secondary Replicas
(Always On Availability Groups).
Read-only access to one or more secondary replicas (readable secondary replicas)
Any availability replica can be configured to allow read-only access to its local databases when performing
the secondary role, though some operations are not fully supported. Also, if you would like to prevent read-
only workloads from running on the primary replica, you can configure the replicas to allow only read-write
access when running under the primary role. For more information, see Active Secondaries: Readable
Secondary Replicas (Always On Availability Groups).
If an availability group currently possesses an availability group listener and one or more readable
secondary replicas, SQL Server can route read-intent connection requests to one of them (read-only
routing). For more information, see Availability Group Listeners, Client Connectivity, and Application Failover
(SQL Server).
Session-Timeout Period
The session-timeout period is an availability-replica property that determines how long connection with another
availability replica can remain inactive before the connection is closed. The primary and secondary replicas ping
each other to signal that they are still active. Receiving a ping from the other replica during the timeout period
indicates that the connection is still open and that the server instances are communicating. On receiving a ping, an
availability replica resets its session-timeout counter on that connection.
The session-timeout period prevents either replica from waiting indefinitely to receive a ping from the other
replica. If no ping is received from the other replica within the session-timeout period, the replica times out. Its
connection is closed, and the timed-out replica enters the DISCONNECTED state. Even if a disconnected replica is
configured for synchronous-commit mode, transactions will not wait for that replica to reconnect and
resynchronize.
The default session-timeout period for each availability replica is 10 seconds. This value is user-configurable, with a
minimum of 5 seconds. Generally, we recommend that you keep the time-out period at 10 seconds or greater.
Setting the value to less than 10 seconds creates the possibility of a heavily loaded system declaring a false failure.
NOTE
In the resolving role, the session-timeout period does not apply because pinging does not occur.
Automatic Page Repair

Each availability replica tries to automatically recover from corrupted pages on a local database by resolving
certain types of errors that prevent reading a data page. If a secondary replica cannot read a page, the replica
requests a fresh copy of the page from the primary replica. If the primary replica cannot read a page, the replica
broadcasts a request for a fresh copy to all the secondary replicas and gets the page from the first to respond. If
this request succeeds, the unreadable page is replaced by the copy, which usually resolves the error.
For more information, see Automatic Page Repair (Availability Groups: Database Mirroring).
Related Tasks
Getting Started with Always On Availability Groups (SQL Server)
Related Content
Blogs:
Always On - HADRON Learning Series: Worker Pool Usage for HADRON Enabled Databases
SQL Server Always On Team Blogs: The official SQL Server Always On Team Blog
CSS SQL Server Engineers Blogs
Videos:
Microsoft SQL Server Code-Named "Denali" Always On Series,Part 1: Introducing the Next Generation High
Availability Solution
Microsoft SQL Server Code-Named "Denali" Always On Series,Part 2: Building a Mission-Critical High
Availability Solution Using Always On
Whitepapers:
Microsoft SQL Server Always On Solutions Guide for High Availability and Disaster Recovery
Microsoft White Papers for SQL Server 2012
SQL Server Customer Advisory Team Whitepapers
See Also
Availability Modes (Always On Availability Groups)
Failover and Failover Modes (Always On Availability Groups)
Overview of Transact-SQL Statements for Always On Availability Groups (SQL Server)
Overview of PowerShell Cmdlets for Always On Availability Groups (SQL Server)
High Availability Support for In-Memory OLTP databases
Prerequisites, Restrictions, and Recommendations for Always On Availability Groups (SQL Server)
Creation and Configuration of Availability Groups (SQL Server)
Active Secondaries: Readable Secondary Replicas (Always On Availability Groups)
Active Secondaries: Backup on Secondary Replicas (Always On Availability Groups)
Availability Group Listeners, Client Connectivity, and Application Failover (SQL Server)
The Database Mirroring Endpoint (SQL Server)
Warehouse
To participate in Always On availability groups or database mirroring a server instance requires its own, dedicated
database mirroring endpoint. This endpoint is a special-purpose endpoint that is used exclusively to receive
connections from other server instances. On a given server instance, every Always On availability groups or
database mirroring connection to any other server instance uses a single database mirroring endpoint.
Database mirroring endpoints use Transmission Control Protocol (TCP) to send and receive messages between the
server instances participating database mirroring sessions or hosting availability replicas. The database mirroring
endpoint listens on a unique TCP port number.
NOTE
Client connections to a principal server or primary replica do not use the database mirroring endpoint.
NOTE
The database mirroring feature will be removed in a future version of Microsoft SQL Server. Avoid using this feature in new
development work, and plan to modify applications that currently use database mirroring to use Always On availability
groups instead.
Server Network Address

The network address of a server instance (its server network address or Endpoint URL) contains the port number of
its endpoint, as well as the system and domain name of its host computer. The port number uniquely identifies a
specific server instance.
The following figure illustrates how two server instances on the same server are uniquely identified. The server
network addresses of both server instances contain the same system name, MYSYSTEM , and domain name,
Adventure-Works.MyDomain.com . To enable the system to route connections to a server instance, a server network
address includes the port number associated with the mirroring endpoint of a particular server instance.
By default, an instance of SQL Server does not contain a database mirroring endpoint. These must be created
manually as part of setting up a database mirroring session. The system administrator must create a separate
endpoint in each server instance that is to participate in database mirroring. Note that if more than one server
instance on a given computer requires a database mirroring endpoint, specify a different port number for each
endpoint.
IMPORTANT
If the computer running SQL Server has a firewall, the firewall configuration must allow both incoming and outgoing
connections for the port specified in the endpoint.
For database mirroring and Always On availability groups, authentication and encryption are configured on the
endpoint. For more information, see Transport Security for Database Mirroring and Always On Availability Groups
(SQL Server).
IMPORTANT
Do not reconfigure an in-use database mirroring endpoint. The server instances use each other's endpoints to learn the state
of the other systems. If the endpoint is reconfigured, it might restart, which can appear to be an error to the other server
instances. This is particularly important for automatic failover mode, in which reconfiguring the endpoint on a partner could
cause a failover to occur.
Determining the Authentication Type for a Database Mirroring

Endpoint
It is important to understand that the SQL Server service accounts of your server instances determine what type of
authentication you can use for your database mirroring endpoints, as follows:
If every server instance is running under a domain service account, you can use Windows Authentication for
your database mirroring endpoints. If all the server instances run as the same domain user account, the
correct user logins exist automatically in both master databases. This simplifies the security configuration
for the availability databases and is recommended.
If any server instances that are hosting the availability replicas for an availability group run as different
accounts, the login each account must be created in master on the other server instance. Then, that login
must be granted CONNECT permissions to connect to the database mirroring endpoint of that server
instance. For more information, Set Up Login Accounts for Database Mirroring or Always On Availability
Groups (SQL Server).
If your server instances use Windows Authentication, you can create database mirroring endpoints by using
Transact-SQL, PowerShell, or the New Availability Group Wizard.
NOTE
If a server instance that is to host an availability replica lacks a database mirroring endpoint, the New Availability
Group Wizard can automatically create a database mirroring endpoint that uses Windows Authentication. For more
information, see Use the Availability Group Wizard (SQL Server Management Studio).
If any server instance is running under a built-in account, such as Local System, Local Service, or Network
Service, or a nondomain account, you must use certificates for endpoint authentication. If you are using
certificates for your database mirroring endpoints, your system administrator must configure each server
instance to use certificates on both outbound and inbound connections.
There is no automated method for configuring database mirroring security using certificates. You will need
to use either CREATE ENDPOINT Transact-SQL statement or the New-SqlHadrEndpoint PowerShell
cmdlet. For more information, see CREATE ENDPOINT (Transact-SQL). For information about enabling
certificate authentication on a server instance, see Use Certificates for a Database Mirroring Endpoint
(Transact-SQL).
Related Tasks
To Configure a Database Mirroring Endpoint
Create a Database Mirroring Endpoint for Windows Authentication (Transact-SQL)
Use Certificates for a Database Mirroring Endpoint (Transact-SQL)
Allow a Database Mirroring Endpoint to Use Certificates for Outbound Connections (Transact-SQL)
Allow a Database Mirroring Endpoint to Use Certificates for Inbound Connections (Transact-SQL)
Specify a Server Network Address (Database Mirroring)
Specify the Endpoint URL When Adding or Modifying an Availability Replica (SQL Server)
Use the Availability Group Wizard (SQL Server Management Studio)
To View Information About the Database Mirroring Endpoint
sys.database_mirroring_endpoints (Transact-SQL)
See Also
Transport Security for Database Mirroring and Always On Availability Groups SQL Server)
Troubleshoot Database Mirroring Configuration (SQL Server)
sys.dm_hadr_availability_replica_states (Transact-SQL)
sys.dm_db_mirroring_connections (Transact-SQL)
About Log Shipping (SQL Server)
Warehouse
SQL Server Log shipping allows you to automatically send transaction log backups from a primary database on a
primary server instance to one or more secondary databases on separate secondary server instances. The
transaction log backups are applied to each of the secondary databases individually. An optional third server
instance, known as the monitor server, records the history and status of backup and restore operations and,
optionally, raises alerts if these operations fail to occur as scheduled.
In this Topic:
Benefits
Terms and Definitions
Log Shipping Overview
Interoperability
Related Tasks
Benefits
Provides a disaster-recovery solution for a single primary database and one or more secondary databases,
each on a separate instance of SQL Server.
Supports limited read-only access to secondary databases (during the interval between restore jobs).
Allows a user-specified delay between when the primary server backs up the log of the primary database
and when the secondary servers must restore (apply) the log backup. A longer delay can be useful, for
example, if data is accidentally changed on the primary database. If the accidental change is noticed quickly,
a delay can let you retrieve still unchanged data from a secondary database before the change is reflected
there.
Terms and Definitions

primary server
The instance of SQL Server that is your production server.
primary database
The database on the primary server that you want to back up to another server. All administration of the log
shipping configuration through SQL Server Management Studio is performed from the primary database.
secondary server
The instance of SQL Server where you want to keep a warm standby copy of your primary database.
secondary database
The warm standby copy of the primary database. The secondary database may be in either the RECOVERING state
or the STANDBY state, which leaves the database available for limited read-only access.
monitor server
An optional instance of SQL Server that tracks all of the details of log shipping, including:
When the transaction log on the primary database was last backed up.
When the secondary servers last copied and restored the backup files.
Information about any backup failure alerts.
IMPORTANT
Once the monitor server has been configured, it cannot be changed without removing log shipping first.
backup job
A SQL Server Agent job that performs the backup operation, logs history to the local server and the monitor server,
and deletes old backup files and history information. When log shipping is enabled, the job category "Log Shipping
Backup" is created on the primary server instance.
copy job
A SQL Server Agent job that copies the backup files from the primary server to a configurable destination on the
secondary server and logs history on the secondary server and the monitor server. When log shipping is enabled
on a database, the job category "Log Shipping Copy" is created on each secondary server in a log shipping
configuration.
restore job
A SQL Server Agent job that restores the copied backup files to the secondary databases. It logs history on the local
server and the monitor server, and deletes old files and old history information. When log shipping is enabled on a
database, the job category "Log Shipping Restore" is created on the secondary server instance.
alert job
A SQL Server Agent job that raises alerts for primary and secondary databases when a backup or restore operation
does not complete successfully within a specified threshold. When log shipping is enabled on a database, job
category "Log Shipping Alert" is created on the monitor server instance.
TIP
For each alert, you need to specify an alert number. Also, be sure to configure the alert to notify an operator when an alert is
raised.
Log Shipping Overview

Log shipping consists of three operations:
1. Back up the transaction log at the primary server instance.
2. Copy the transaction log file to the secondary server instance.
3. Restore the log backup on the secondary server instance.
The log can be shipped to multiple secondary server instances. In such cases, operations 2 and 3 are
duplicated for each secondary server instance.
A log shipping configuration does not automatically fail over from the primary server to the secondary
server. If the primary database becomes unavailable, any of the secondary databases can be brought online
manually.
You can use a secondary database for reporting purposes.
In addition, you can configure alerts for your log shipping configuration.
A Typical Log Shipping Configuration
The following figure shows a log shipping configuration with the primary server instance, three secondary server
instances, and a monitor server instance. The figure illustrates the steps performed by backup, copy, and
restorejobs, as follows:
1. The primary server instance runs the backup job to back up the transaction log on the primary database. This
server instance then places the log backup into a primary log-backup file, which it sends to the backup
folder. In this figure, the backup folder is on a shared directory—the backup share.
2. Each of the three secondary server instances runs its own copy job to copy the primary log-backup file to its
own local destination folder.
3. Each secondary server instance runs its own restore job to restore the log backup from the local destination
folder onto the local secondary database.
The primary and secondary server instances send their own history and status to the monitor server
instance.
Interoperability
Log shipping can be used with the following features or components of SQL Server:
Prerequisites for Migrating from Log Shipping to Always On Availability Groups (SQL Server)
Database Mirroring and Log Shipping (SQL Server)
Log Shipping and Replication (SQL Server)
NOTE
Always On availability groups and database mirroring are mutually exclusive. A database that is configured for one of these
features cannot be configured for the other.
Related Tasks
Upgrading Log Shipping to SQL Server 2016 (Transact-SQL)
Configure Log Shipping (SQL Server)
Add a Secondary Database to a Log Shipping Configuration (SQL Server)
Remove a Secondary Database from a Log Shipping Configuration (SQL Server)
Remove Log Shipping (SQL Server)
View the Log Shipping Report (SQL Server Management Studio)
Monitor Log Shipping (Transact-SQL)
Fail Over to a Log Shipping Secondary (SQL Server)
Fail Over to a Log Shipping Secondary (SQL Server)
Management of Logins and Jobs After Role Switching (SQL Server)
See Also
Overview of Always On Availability Groups (SQL Server)

SQL DB Toc Fromms01

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

SQL DB Toc Fromms01

Transféré par

Droits d'auteur :

Formats disponibles

Table of Contents

SQL Server 2016 Service Pack 1 (SP1)

SQL Server 2016 RTM

SELECT * FROM sys.dm_os_performance_counters

Features Not Supported in the Next Version of SQL Server

CATEGORY DEPRECATED FEATURE REPLACEMENT FEATURE NAME FEATURE ID

Backup and Restore RESTORE { DATABASE None. BACKUP DATABASE 104

Compatibility levels Upgrade from version Compatibility levels Database 108

Database objects Ability to return result None Returning results 12

Encryption Encryption using RC4 Use another Deprecated 253

Remote servers sp_addremotelogin Replace remote sp_addremotelogin 70

Remote servers @@remserver Replace remote None None

Remote servers SET Replace remote SET 110

Tools sqlmaint Utility Use the SQL Server None None

Features Not Supported in a Future Version of SQL Server

Compatibility levels sp_dbcmptlevel ALTER DATABASE … sp_dbcmptlevel 80

Compatibility levels Database Plan to upgrade the Database

XML Inline XDR Schema The XMLDATA XMLDATA 181

BACKUP { DATABASE BACKUP { DATABASE

Backup and restore sp_addumpdevice sp_addumpdevice ADDING TAPE 236

Backup and restore sp_helpdevice sys.backup_devices sp_helpdevice 100

Collations Korean_Wansung_Uni None. These collations Korean_Wansung_Uni 191

Collations Hindi These collations exist Hindi 190

Collations Azeri_Latin_90 Azeri_Latin_100 Azeri_Latin_90 232

Azeri_Cyrilllic_90 Azeri_Cyrilllic_100 Azeri_Cyrilllic_90 233

Configuration SET ANSI_NULLS OFF None. SET ANSI_NULLS OFF 111

Data types sp_addtype CREATE TYPE sp_addtype 62

sp_droptype DROP TYPE sp_droptype 63

Data types timestamp syntax for rowversion data TIMESTAMP 158

Data types Data types: Use varchar(max), Data types: text, 4

Database sp_attach_db CREATE DATABASE sp_attach_db 81

Database objects CREATE DEFAULT DEFAULT keyword in CREATE_DROP_DEFA 162

Database objects CREATE RULE CHECK keyword in CREATE_DROP_RULE 161

Database objects sp_change_users_logi Use ALTER USER. sp_change_users_logi 231

Database objects sp_depends sys.dm_sql_referencin sp_depends 19

Database objects sp_renamedb MODIFY NAME in sp_renamedb 79

Database objects sp_getbindtoken Use MARS or sp_getbindtoken 98

Database options sp_bindsession Use MARS or sp_bindsession 97

Database options sp_resetstatus ALTER DATABASE SET sp_resetstatus 83

Database options TORN_PAGE_DETECTI PAGE_VERIFY ALTER DATABASE 102

DBCC DBCC DBREINDEX REBUILD option of DBCC DBREINDEX 11

DBCC DBCC INDEXDEFRAG REORGANIZE option DBCC INDEXDEFRAG 18

DBCC DBCC SHOWCONTIG sys.dm_db_index_phy DBCC SHOWCONTIG 10

DBCC DBCC PINTABLE Has no effect. DBCC [UN]PINTABLE 189

Extended properties Level0type = 'type' Use Level0type = EXTPROP_LEVEL0TYP 13

Extended stored srv_alloc Use CLR Integration XP_API 20

Extended stored xp_grantlogin Use CREATE LOGIN xp_grantlogin 44

Functions fn_get_sql sys.dm_exec_sql_text fn_get_sql 151

High availability database mirroring Always On availability DATABASE_MIRRORI 267

If your edition of SQL

Index options sp_indexoption ALTER INDEX sp_indexoption 78

Index options CREATE TABLE, ALTER Rewrite the statement INDEX_OPTION 33

Instance options sp_configure options: Now automatically sp_configure 'locks' 174

Instance options sp_configure option System tables are no sp_configure 'remote 37

Linked servers Specifying the SQL Server Native SQLOLEDDB for 19

Locking sp_lock sys.dm_tran_locks sp_lock 99

Metadata FILE_ID FILE_IDEX FILE_ID 15

INDEXKEY_PROPERTY sys.index_columns INDEXKEY_PROPERTY 17

Native XML Web The CREATE Use Windows CREATE/ALTER 21

Removable databases sp_certify_removable sp_detach_db sp_certify_removable 74

Removable databases sp_dbremove DROP DATABASE sp_dbremove 76

Security sp_addapprole CREATE sp_addapprole 53

Security sp_addlogin CREATE LOGIN sp_addlogin 39