Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Karen’s Favourite* Features of
SQL Server 2016
…from a database designer’s Point of view
Karen Lopez, InfoAdvisors
Karen Lopez
Karen has 20+ years of data and information architecture
experience on large, multi-project programs.
She is a...
A Little About InfoAdvisors…
#TeamData
Data Management
Project Management
Business Analysis
Training
Analysts Services
Con...
“Every design decision comes
down to cost, benefit and risk.”
- Karen Lopez
Prelaunch Countdown
Some of these slides come from a deck
co-developed for a precon on DB
Design – with Thomas LaRock
www....
Launch
What is a DBA?
Development DBA
Database Engineer
Database Designer
Operational DBA
NoSQL 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 level
TDE
Always Encrypted
Data Masking*
Row Level Security*
New!
Security – Always Encrypted
Enabled at column level
Protects data at rest *AND* in memory
Uses Column Master Key (client) ...
Security – Always
Encrypted
Always!
Always Encrypted
Security – Always Encrypted
Deterministic – good for
static values; can be
indexed
• MUST use *_BIN2
collation
(Latin1_Gen...
Security – Always Encrypted
text/ntext/image
XML/hierarchyid/geography/geometry
alias types/user-defined data types
SQL_VA...
Security – Always Encrypted
Foreign keys must match encryption
types
Client code needs to support AE
(currently this means...
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
pro...
Security – Dynamic Data Masking
CREATE TABLE Membership(
MemberID int IDENTITY PRIMARY KEY,
FirstName varchar(100) MASKED ...
Security – Dynamic Data Masking
Done at column level (NOT ENCRYPTION!)
Meant to complement other methods
Performed at the ...
Security – Dynamic Data Masking
4
functions
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 u...
Security – Dynamic Data Masking
Cannot mask an encrypted column (AE)
Cannot be configured on computed column
But if comput...
Security – Dynamic Data Masking
Why would a DB
Designer love it?
Allows central, reusable design
for standard masking
Offers more reliable masking and
mor...
Security – Row Level Security
Filtering result sets (predicate based access)
Predicates applied when reading data
Can be u...
Security – Row Level Security
No indication that results have been filtered
If all rows are filtered than NULL set returne...
Security – Row Level Security
Recommended to create schema for RLS objects
(predicate functions and security policies)
Use...
Security – Row Level Security
Not
Allowed
• DBCC SHOW_STATISTICS
• FILESTREAM
• Polybase
• Indexed views
• CDC nor change ...
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 co...
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...
Security - Summary
Data quality?
Data availability?
Data recovery?
Query performance?
Legal requirements?
Which one is rig...
Advanced Features and Updates
Love them all…
MOAR Foreign Keys!
What was the previous limit?
253
10,000
What is the new limit?
Why would a DB
Designer love it?
…not so sure ….
Columnstore Improvements
Filter on NCI Columstore
Updateable
In-memory tables can use
Table with Clustered Index Columnsto...
Why would a DB
Designer love it?
Faster
More options
Better
Advanced Features – Temporal Tables
ANSI SQL 2011 based
Current data
Access to historical data
Point-in-time analysis
Uses...
System Versioned Table: Temporal Table
System Versioned Table: Temporal Table
Why would a DB
Designer love it?
Don’t have hand-develop a
solution
SQL Server knows what these
tables are and can optimiz...
Advance Features: JSON
Not a data type in SQL Server 2016
Results as JSON
Import JSON
Store JSON nvarchar()
Requires Compa...
Why JSON?
It’s Hipster!
Common for data exchange
Common 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
solution
Your Devs will Love you More
You can be faster and bet...
Physical Files – Stretch Database
Stretch Database
• Migrate least used data to Azure
• Migrate some or entire table if de...
Physical Files – Stretch Database
Stretch Database
• You can pause migration
• No change to queries
• Latency expected for...
Physical Files – Stretch
Database
Stretch Database
Enable Remote Data Archive
Hot & Cold data
On-Prem & Cloud
EXEC sp_configure 'remote data archive' , '1';...
Why Stretch?
Smaller backups
Application ignorant
Performance on hot data
Performance* on cold data
Why not Stretch?
Uniqueness
Certain datatypes
Replication
View limitations
Index limitations
More…
Uniqueness is not enfor...
Why would a DB
Designer love it?
Don’t have hand-develop a
solution
It’s all automatic
Your devs will love you because
no ...
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
Karen's Favourite Features of  SQL Server 2016
Karen's Favourite Features of  SQL Server 2016
Karen's Favourite Features of  SQL Server 2016
Upcoming SlideShare
Loading in …5
×

Karen's Favourite Features of SQL Server 2016

466 views

Published on

Slides from a one hour webinar on Karen Lopez's favorite features from database designer's point of view. Topics include Always Encrypted, Data Masking, Row Level Security, Foreign Keys, JSON and more.

Notice an error? Let me know. I welcome this sort of feedback.

Published in: Software
  • Be the first to comment

Karen's Favourite Features of SQL Server 2016

  1. 1. Karen’s Favourite* Features of SQL Server 2016 …from a database designer’s Point of view Karen Lopez, InfoAdvisors
  2. 2. Karen Lopez Karen 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.
  3. 3. A Little About InfoAdvisors… #TeamData Data Management Project Management Business Analysis Training Analysts Services Consulting www.datamodel.com
  4. 4. “Every design decision comes down to cost, benefit and risk.” - Karen Lopez
  5. 5. Prelaunch Countdown Some of these slides come from a deck co-developed for a precon on DB Design – with Thomas LaRock www.thomaslarock.com @sqlrockstar
  6. 6. Launch
  7. 7. What is a DBA? Development DBA Database Engineer Database Designer Operational DBA NoSQL DBA
  8. 8. Security
  9. 9. SQL 2005 gave us cell-level encryption SQL 2008 gave us TDE BitLocker et al Nothing new until SQL 2016 Security
  10. 10. Security – SQL 2016 Cell level TDE Always Encrypted Data Masking* Row Level Security* New!
  11. 11. Security – Always Encrypted Enabled at column level Protects data at rest *AND* in memory Uses Column Master Key (client) and Column Encryption Key (server)
  12. 12. Security – Always Encrypted Always!
  13. 13. Always Encrypted
  14. 14. 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!
  15. 15. Security – Always Encrypted text/ntext/image XML/hierarchyid/geography/geometry alias types/user-defined data types SQL_VARIANT rowversion (timestamp) System alias (SYSNAME) Computed columns Identity columns Sparse column sets Temporal tables Triggers (partial support) Full text search Replication CDC In Memory OLTP Stretch database
  16. 16. Security – Always Encrypted Foreign keys must match encryption types Client code needs to support AE (currently this means .NET 4.6)
  17. 17. Security – Always Encrypted Wizard
  18. 18. 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
  19. 19. 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');
  20. 20. 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 returned Performance impact small
  21. 21. Security – Dynamic Data Masking 4 functions available • Default • Email • Custom String • Random
  22. 22. 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
  23. 23. 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 returned Using SELECT INTO or INSERT INTO results in masked data being inserted into target (also for import/export)
  24. 24. Security – Dynamic Data Masking
  25. 25. Why would a DB Designer love it? Allows central, reusable design for standard masking Offers more reliable masking and more usable masking Removes whining about “we can do that later”
  26. 26. 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
  27. 27. Security – Row Level Security No indication that results have been filtered If all rows are filtered than NULL set returned For block predicates, an error returned Works even if you are dbo or db_owner role
  28. 28. 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 columns Avoid type conversions in predicate functions to avoid runtime errors
  29. 29. Security – Row Level Security Not Allowed • DBCC SHOW_STATISTICS • FILESTREAM • Polybase • Indexed views • CDC nor change tracking
  30. 30. Security – Row Level Security
  31. 31. 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.
  32. 32. 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
  33. 33. Security - Summary Data quality? Data availability? Data recovery? Query performance? Legal requirements? Which one is right for you?
  34. 34. Advanced Features and Updates Love them all…
  35. 35. MOAR Foreign Keys! What was the previous limit? 253 10,000 What is the new limit?
  36. 36. Why would a DB Designer love it? …not so sure ….
  37. 37. Columnstore Improvements Filter on NCI Columstore Updateable In-memory tables can use Table with Clustered Index Columnstore can have NCI PKs and FKs constraints Even more performance improvements
  38. 38. Why would a DB Designer love it? Faster More options Better
  39. 39. Advanced Features – Temporal Tables ANSI SQL 2011 based Current data Access to historical data Point-in-time analysis Uses “period columns” System-Versioned Temporal Tables
  40. 40. System Versioned Table: Temporal Table
  41. 41. System Versioned Table: Temporal Table
  42. 42. Why would a DB Designer love it? Don’t have hand-develop a solution SQL Server knows what these tables are and can optimize itself when it uses them.
  43. 43. Advance Features: JSON Not a data type in SQL Server 2016 Results as JSON Import JSON Store JSON nvarchar() Requires Compatibility Level 130 FOR JSON OPENJSON
  44. 44. Why JSON? It’s Hipster! Common for data exchange Common for persistence Tools Preferred
  45. 45. Getting JSON out…
  46. 46. SSMS
  47. 47. JSON – Getting it in
  48. 48. Why would a DB Designer love it? Don’t have hand-develop a solution Your Devs will Love you More You can be faster and better because you now speak a new language 
  49. 49. 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
  50. 50. Physical Files – Stretch Database Stretch Database • You can pause migration • No change to queries • Latency expected for querying historical data
  51. 51. Physical Files – Stretch Database
  52. 52. Stretch Database Enable Remote Data Archive Hot & Cold data On-Prem & Cloud EXEC sp_configure 'remote data archive' , '1'; GO RECONFIGURE; GO
  53. 53. Why Stretch? Smaller backups Application ignorant Performance on hot data Performance* on cold data
  54. 54. Why not Stretch? Uniqueness Certain datatypes Replication View limitations Index limitations More… Uniqueness is not enforced for UNIQUE constraints and PRIMARY KEY constraints on a Stretch- enabled table.
  55. 55. Why would a DB Designer love it? Don’t have hand-develop a solution It’s all automatic Your devs will love you because no app changes required.
  56. 56. Finally… Many, many performance enhancements. It’s just FASTER. No design changes needed.
  57. 57. One more time… Every Design Decision must be based on Cost, Benefit and Risk
  58. 58. Thank you! I’d appreciate feedback of any type about this presentation. KarenLopez@InfoAdvisors.com

×