Karen's Favourite Features of SQL Server 2016
Download as PPTX, PDF2 likes680 views
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.
Ad
More Related Content
What's hot (20)
Similar to Karen's Favourite Features of SQL Server 2016 (20)
Ad
More from Karen Lopez (13)
Ad
Recently uploaded (20)
Karen's Favourite Features of SQL Server 2016
- 1. Karen’s Favourite* Features of SQL Server 2016 …from a database designer’s Point of view Karen Lopez, InfoAdvisors
- 3. 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.
- 4. A Little About InfoAdvisors… #TeamData Data Management Project Management Business Analysis Training Analysts Services Consulting www.datamodel.com
- 5. “Every design decision comes down to cost, benefit and risk.” - Karen Lopez
- 6. 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
- 7. Launch
- 8. What is a DBA? Development DBA Database Engineer Database Designer Operational DBA NoSQL DBA
- 9. Security
- 10. SQL 2005 gave us cell-level encryption SQL 2008 gave us TDE BitLocker et al Nothing new until SQL 2016 Security
- 11. Security – SQL 2016 Cell level TDE Always Encrypted Data Masking* Row Level Security* New!
- 12. Security – Always Encrypted Enabled at column level Protects data at rest *AND* in memory Uses Column Master Key (client) and Column Encryption Key (server)
- 14. Always Encrypted
- 15. 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!
- 16. 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
- 17. Security – Always Encrypted Foreign keys must match encryption types Client code needs to support AE (currently this means .NET 4.6)
- 19. 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
- 20. 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]');
- 21. 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
- 22. Security – Dynamic Data Masking 4 functions available • Default • Email • Custom String • Random
- 23. 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
- 24. 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)
- 25. Security – Dynamic Data Masking
- 26. 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”
- 27. 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
- 28. 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
- 29. 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
- 30. Security – Row Level Security Not Allowed • DBCC SHOW_STATISTICS • FILESTREAM • Polybase • Indexed views • CDC nor change tracking
- 31. Security – Row Level Security
- 32. 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.
- 33. 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
- 34. Security - Summary Data quality? Data availability? Data recovery? Query performance? Legal requirements? Which one is right for you?
- 36. Advanced Features and Updates Love them all…
- 37. MOAR Foreign Keys! What was the previous limit? 253 10,000 What is the new limit?
- 38. Why would a DB Designer love it? …not so sure ….
- 39. 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
- 40. Why would a DB Designer love it? Faster More options Better
- 41. 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
- 43. System Versioned Table: Temporal Table
- 44. System Versioned Table: Temporal Table
- 45. 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.
- 46. 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
- 47. Why JSON? It’s Hipster! Common for data exchange Common for persistence Tools Preferred
- 49. SSMS
- 50. JSON – Getting it in
- 51. 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
- 52. 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
- 53. Physical Files – Stretch Database Stretch Database • You can pause migration • No change to queries • Latency expected for querying historical data
- 54. Physical Files – Stretch Database
- 55. Stretch Database Enable Remote Data Archive Hot & Cold data On-Prem & Cloud EXEC sp_configure 'remote data archive' , '1'; GO RECONFIGURE; GO
- 56. Why Stretch? Smaller backups Application ignorant Performance on hot data Performance* on cold data
- 57. 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.
- 58. 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.
- 59. Finally… Many, many performance enhancements. It’s just FASTER. No design changes needed.
- 60. One more time… Every Design Decision must be based on Cost, Benefit and Risk
- 61. Thank you! I’d appreciate feedback of any type about this presentation. [email protected]