Karen's Favourite Features of SQL Server 2016
61
Karen’s Favourite* Features of SQL Server 2016 …from a database designer’s Point of view Karen Lopez, InfoAdvisors
-
Upload
karen-lopez -
Category
Software
-
view
250 -
download
2
Transcript of 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', '[email protected]'), ('Janice', 'Galvin', '555.123.4568', '[email protected]'), ('Zheng', 'Mu', '555.123.4569', '[email protected]');
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.
