Karen's Favourite Features of SQL Server 2016

Karen’s Favourite* Features of SQL Server 2016

…from a database designer’s Point of viewKaren Lopez, InfoAdvisors

I Am so HAPPY you are here!

Karen LopezKaren has 20+ years of data and information architecture experience on large, multi-project programs.She is a frequent speaker on data modeling, data-driven methodologies and pattern data models.She wants you to love your data.

A Little About InfoAdvisors…

#TeamData

Data ManagementProject ManagementBusiness AnalysisTrainingAnalysts ServicesConsulting

www.datamodel.com

“Every design decision comes down to cost,

benefit and risk.”

- Karen Lopez

Prelaunch CountdownSome of these slides come from a deck co-developed for a precon on DB Design – with Thomas LaRock www.thomaslarock.com @sqlrockstar

Launch

What is a DBA?

Development DBADatabase EngineerDatabase DesignerOperational DBANoSQL DBA

Security

SQL 2005 gave us cell-level

encryption

SQL 2008 gave us

TDE

BitLocker et al

Nothing new until SQL 2016

Security

Security – SQL 2016

Cell levelTDEAlways EncryptedData Masking*Row Level Security*

New!

Security – Always Encrypted

Enabled at column level

Protects data at rest *AND* in memory

Uses Column Master Key (client) and Column Encryption Key (server)

Security – Always Encrypted

Always!

Always Encrypted

Security – Always Encrypted

Deterministic – good for static values; can be

indexed• MUST use *_BIN2

collation (Latin1_General_BIN2)

Randomized – better security;

cannot be indexed• Not allowed in

WHERE clause!

Security – Always Encrypted

text/ntext/imageXML/hierarchyid/geography/geometryalias types/user-defined data typesSQL_VARIANTrowversion (timestamp)System alias (SYSNAME)Computed columnsIdentity columns

Sparse column setsTemporal tablesTriggers (partial support)Full text searchReplicationCDCIn Memory OLTPStretch database

Security – Always Encrypted

Foreign keys must match encryption types

Client code needs to support AE (currently this means .NET 4.6)

Security – Always Encrypted

Wizard

Why would a DB Designer love it?

Always Encrypted, yeah.Allows designers to not only specify which columns need to be protected, but how.Built in to the engine, easier for Devs

Security – Dynamic Data Masking

CREATE TABLE Membership(MemberID int IDENTITY PRIMARY KEY,     FirstName varchar(100) MASKED WITH (FUNCTION = 'partial(1,"XXXXXXX",0)') NULL,

    LastName varchar(100) NOT NULL,     Phone# varchar(12) MASKED WITH (FUNCTION = 'default()') NULL,     Email varchar(100) MASKED WITH (FUNCTION = 'email()') NULL);

INSERT Membership (FirstName, LastName, Phone#, Email) VALUES ('Roberto', 'Tamburello', '555.123.4567', 'RTamburello@contoso.com'), ('Janice', 'Galvin', '555.123.4568', 'JGalvin@contoso.com.co'), ('Zheng', 'Mu', '555.123.4569', 'ZMu@contoso.net');

Security – Dynamic Data Masking

Done at column level (NOT ENCRYPTION!)

Meant to complement other methods

Performed at the end of a database query right before data returnedPerformance impact small

Security – Dynamic Data Masking

4 function

s available

• Default• Email• Custom String• Random

Security – Dynamic Data Masking

Data in database is not changed

Ad-hoc queries *can* expose data

Does not aim to prevent users from exposing pieces of sensitive data

Security – Dynamic Data Masking

Cannot mask an encrypted column (AE)

Cannot be configured on computed column

But if computed column depends on a mask, then mask is returnedUsing SELECT INTO or INSERT INTO results in masked data being inserted into target (also for import/export)

Security – Dynamic Data Masking

Why would a DB Designer love it?

Allows central, reusable design for standard maskingOffers more reliable masking and more usable maskingRemoves whining about “we can do that later”

Security – Row Level Security

Filtering result sets (predicate based access)

Predicates applied when reading data

Can be used to block write access

User defined policies tied to inline table functions

Security – Row Level Security

No indication that results have been filteredIf all rows are filtered than NULL set returnedFor block predicates, an error returnedWorks even if you are dbo or db_owner role

Security – Row Level Security

Recommended to create schema for RLS objects (predicate functions and security policies)Use ALTER ANY SECURITY POLICY permissions; this does not require SELECT on the columnsAvoid type conversions in predicate functions to avoid runtime errors

Security – Row Level Security

Not Allowed

• DBCC SHOW_STATISTICS• FILESTREAM• Polybase • Indexed views• CDC nor change tracking

Security – Row Level Security

Why would a DB Designer love it?

Allows a designer to do this sort of data protection IN THE DATABASE, not just rely on code. Many, many pieces of code.

Security - Summary

Key differences TDE AE DDM RLS

Encryption Y Y N N

Protect data in memory N Y N N

Overhead Low* High Low Low

Block updates N N N Y

Security - Summary

Data quality?

Data availability?

Data recovery?

Query performance?

Legal requirements?

Which one is right for you?

Advanced Features and Updates

Love them all…

MOAR Foreign Keys!

What was the previous limit?

25310,000What is the new limit?

Why would a DB Designer love it?

…not so sure ….

Columnstore Improvements

Filter on NCI ColumstoreUpdateableIn-memory tables can useTable with Clustered Index Columnstore can have NCIPKs and FKs constraintsEven more performance improvements

Why would a DB Designer love it?

FasterMore optionsBetter

Advanced Features – Temporal Tables

ANSI SQL 2011 basedCurrent dataAccess to historical data Point-in-time analysisUses “period columns”

 System-Versioned Temporal Tables

System Versioned Table: Temporal Table

System Versioned Table: Temporal Table

Why would a DB Designer love it?

Don’t have hand-develop a solutionSQL Server knows what these tables are and can optimize itself when it uses them.

Advance Features: JSON

Not a data type in SQL Server 2016Results as JSON

Import JSON

Store JSON nvarchar()

Requires Compatibility Level 130

FOR JSONOPENJSON

Why JSON?

It’s Hipster!Common for data exchangeCommon for persistence

Tools

Preferred

Getting JSON out…

SSMS

JSON – Getting it in

Why would a DB Designer love it?

Don’t have hand-develop a solutionYour Devs will Love you MoreYou can be faster and better because you now speak a new language

Physical Files – Stretch Database

Stretch Database• Migrate least used data to Azure• Migrate some or entire table if desired• Stretch database ensures no data is

lost• DMVs provided to show progress

Physical Files – Stretch Database

Stretch Database• You can pause migration• No change to queries• Latency expected for querying

historical data

Physical Files – Stretch Database

Stretch Database

Enable Remote Data ArchiveHot & Cold dataOn-Prem & Cloud

EXEC sp_configure 'remote data archive' , '1'; GO RECONFIGURE; GO

Why Stretch?

Smaller backupsApplication ignorantPerformance on hot dataPerformance* on cold data

Why not Stretch?

UniquenessCertain datatypes ReplicationView limitationsIndex limitationsMore…

Uniqueness is not enforced for UNIQUE constraints and PRIMARY KEY constraints on a Stretch-enabled table.

Why would a DB Designer love it?

Don’t have hand-develop a solutionIt’s all automaticYour devs will love you because no app changes required.

Finally…

Many, many performance enhancements. It’s just FASTER. No design changes needed.

One more time… Every Design Decision must be based on Cost, Benefit

and Risk

Thank you!

I’d appreciate feedback of any type about this presentation.

KarenLopez@InfoAdvisors.com