This may help to learn SQL

1. SQL Server 2016 New Features
 Columnstore Indexes
 In-Memory OLTP
 Live Query Statistics
 Query Store
 Temporal Tables
 Managed Backup
 Multiple TempDB Database
Files
 Format Query Results as JSON
with FOR JSON
 Always Encrypted
 PolyBase
 Stretch Database

2. Database Engine Feature Enhancements
• Columnstore Indexes
new improvements for columnstore indexes including updateable nonclustered columnstore indexes, columnstore indexes on in-
memory tables, and many more new features for operational analytics.
Below is the list of them:
 Columnstore Indexes Versioned Feature Summary –includes what’s new
 Columnstore Indexes Data Loading
 Columnstore Indexes for Operational Analytics
 Columnstore Indexes for Data Warehousing
 Columnstore Indexes Maintenance Tasks
• In-Memory OLTP
 Support for performing ALTER operations for memory-optimized tables and natively compiled stored procedures.
 Use MARS (Multiple Active Result Set) connections to access memory-optimized tables and natively compiled stored procedures.
This allows leveraging In-Memory OLTP in existing applications that rely on MARS.
 Support for natively compiled, scalar user-defined functions.
 Support for natively compiled, scalar user-defined functions.
 Storage improvements
 Enhancements to transaction performance analysis reports
 Support for nesting of natively compiled stored procedures, and other increases in the Transact-SQL surface area.
 Support for subqueries in natively compiled stored procedures.
 PowerShell cmdlet for evaluating the migration fitness of multiple objects in a SQL Server database. eywords in documents
• Live Query Statistics
 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

3. Database Engine Feature Enhancements
• 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, 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
• 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
• Why Temporal?
Real data sources are dynamic and more often than not business decisions rely on insights that analysts can get from data evolution.
Use cases for temporal tables include:
 Understanding business trends over time
 Tracking data changes over time
 Auditing all changes to data
 Maintaining a slowly changing dimension for decision support applications
 Recovering from accidental data changes and application errors
• Considerations and Limitations
 A temporal table must have a primary key defined
 The SYSTEM_TIME period columns used to record the SysStartTime and SysEndTime values must be defined with a datatype of
datetime2.
 If the name of a history table is specified during history table creation, you must specify the schema and table name.
 By default, the history table is PAGE compressed.
 If current table is partitioned, the history table is created on default file group because partitioning configuration is not replicated
automatically from the current table to the history table
• Limitations

4. New Temporal Table
• Creating a New Temporal Table

5. Database Engine Feature Enhancements
• Limitations
 Temporal and history tables cannot be FILETABLE and
 Can contain columns of any supported datatype other than FILESTREAM
 While temporal tables support blob data types, such as (n)varchar(max), varbinary(max), (n)text, and image, their will incur significant
storage costs and have performance implications due to their size. As such, when designing your system, care should be taken when
using these data types.
 Temporal querying over Linked Server is not supported.
 History table must be created in the same database as the current table.
 History table cannot have constraints (primary key, foreign key, table or column constraints).
 temporal tables cannot be used in conjunction with In-Memory OLTP.
 INSERT and UPDATE statements cannot reference the SYSTEM_TIME period columns. Attempts to insert values directly into these
columns will be blocked.
 TRUNCATE TABLE is not supported while SYSTEM_VERSIONING is ON
 Direct modification of the data in a history table is not permitted.
 INSTEAD OF triggers are not permitted
 AFTER triggers are permitted only on the current table. They are blocked on the history table to avoid invalidating the DML logic.
 Usage of replication technologies is limited
 Always On: Fully supported
 Change Data Capture and Change Data Tracking: Supported only on the current table
 Snapshot and transactional replication : Only supported for a single publisher without temporal being enabled and one
subscriber with temporal enabled. In this case, the publisher is used for an OLTP workload while subscriber serves for
offloading reporting (including ‘AS OF’ querying). Use of multiple subscribers is not supported since this scenario may lead to
inconsistent temporal data as each of them would depend on the local system clock.
 Merge replication: Not supported for temporal tables
 The following objects/properties are not replicated from the current to the history table when the history table is created
 Period definition
 Identity definition
 Indexes
 Statistics
 Check constraints
 Triggers
 Partitioning configuration
 Permissions
 A history table cannot be configured as current table in a chain of history tables.

6. 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
• 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
• 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.
• 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.

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

8. Managed Backup
Managed Backup
 SQL Server Managed Backup to Microsoft Azure uses the new block blob storage for backup files.
 Support for both automated and custom scheduling of backups.
 Support backups for system databases.
 Support for databases that are using the Simple recovery model.
Multiple TempDB Database Files
 Setup adds multiple tempdb data files during the installation of a new instance.
 By default, setup adds as many tempdb files as the CPU count or 8, whichever is lower.
 You can configure the number of tempdb database files using the new command line parameter
“SQLTEMPDBFILECOUNT”
 setup.exe /Q /ACTION="INSTALL" /IACCEPTSQLSERVERLICENSETERMS /FEATURES="SqlEngine"
/INSTANCENAME="SQL15" .. /SQLTEMPDBDIR="D:tempdb" /SQLTEMPDBFILECOUNT="4“
 SQLTEMPDBFILECOUNT parameter is supported only in the following scenarios or actions: Install,
InstallFailoverCluster, CompleteImage (sysprep), CompleteFailoverCluster (sysprep), and RebuildDatabase
 The number of tempdb database files can be configured using the new UI input control on the Database Engine
Configuration section.
 The primary database file tempdb will still be tempdb.mdf.
 The additional tempdb files are named as tempdb_mssql_#.ndf where # where # represents a unique number
for each additional tempdb database file created during setup.
 Uninstalling an instance of SQL Server deletes the files with naming convention tempdb_mssql_#.ndf.
 Do not use tempdb_mssql_*.ndf naming convention for user database files.
 RebuildDatabase scenario deletes system databases and installs them again in clean state.
 The value of number of tempdb files is not known during setup.

9. Format Query Results as JSON with FOR JSON

10. Always Encrypted
• To quickly start using Always Encrypted:
 Enter a name of a new column encryption key and define its corresponding column master key by selecting an existing
certificate. To create a new certificate in Windows Certificate Store, click New in the Column Master Key Definition box.

11. PolyBase
 No knowledge about Hadoop or
Azure is required to use PolyBase.
 Use T-SQL statements to access
and query in an ad-hoc fashion
data stored in Hadoop or Azure
Blob Storage
 use T-SQL to store data originating
in Hadoop or Azure Blob storage as
regular tables. Users and
applications
 It integrates seamlessly with all BI
tools for example: Reporting
Services, SQL Server Analysis
Services, PowerPivot, PowerQuery,
and PowerView. Or use third party
BI tools, such as Tableau,
Microstrategy or Cognos
 sp_configure 'hadoop
connectivity', 5;
reconfigure

12. How to install PolyBase
 On the feature selection page, select
PolyBase Query Service for External
Data.
 On the Server Configuration Page,
configure the PolyBase Engine
Service and PolyBase Data Movement
Service to run under the same
account.
 Create an external data source, file
format, and table
 Similarly for File format and table.
 Query Examples : Run SQL SELECT
statements against external tables or
use BI tools to query external tables.

13. Stretch Database
 Once we enable Stretch Database
 it silently migrates your historical
data to an Azure SQL Database
 No need to change existing queries
and client apps
 local queries and database
operations against current data
typically run faster
 Right-click and select Tasks, and then
select Enable Database for Stretch.
 Microsoft Azure Sign-in
 On the Stretch Settings page of the
wizard
 Select an Azure location for the
server.
 Create the credential for the server.
 Configure a firewall rule to allow
connections to the server
 On the Summary page of the wizard,
review your choices and then
click Finish