Download Performance?

A Few of My SQL Server
2016 Favorite Things
Sharon Dooley
In-Memory OLTP
enhancements
ALTER TABLE Sales.SalesOrderDetail
ALTER INDEX PK_SalesOrderID
REBUILD
WITH (BUCKET_COUNT=100000000)
ALTER support
Full schema change support: add/alter/drop
column/constraint
Add/drop index supported
Surface area improvements
T-SQL surface area: New
{LEFT|RIGHT} OUTER JOIN
Disjunction (OR, NOT)
UNION [ALL]
SELECT DISTINCT
Subqueries (EXISTS, IN, scalar)
Almost full T-SQL coverage including scalar user-defined
functions
Improved scaling
Increased size allowed for durable tables; more sockets
Other improvements
MARS support
Lightweight migration reports
Performance
Altering memory-optimized tables
| ADD
{
<column_definition>
| <table_constraint>
| <table_index>
} [ ,...n ]
| DROP
{
[ CONSTRAINT ]
{
constraint_name
} [ ,...n ]
| COLUMN
{
column_name
} [ ,...n ]
| INDEX
{
index_name
} [ ,...n ]
} [ ,...n ]
| ALTER INDEX index_name
{
REBUILD (WITH <rebuild_index_option>)
}
}
Performance
The ALTER TABLE syntax is
used for making changes to the
table schema, as well as for
adding, deleting, and rebuilding
indexes
Indexes are considered part of
the table definition
Key advantage is the ability to
change the BUCKET_COUNT with
an ALTER INDEX statement
Altering natively compiled stored procedures
CREATE PROCEDURE [dbo].[usp_1]
WITH NATIVE_COMPILATION, SCHEMABINDING, EXECUTE AS OWNER
AS BEGIN ATOMIC WITH
(
TRANSACTION ISOLATION LEVEL = SNAPSHOT, LANGUAGE =
N'us_english'
)
SELECT c1, c2 from dbo.T1
END
GO
ALTER PROCEDURE [dbo].[usp_1]
WITH NATIVE_COMPILATION, SCHEMABINDING, EXECUTE AS OWNER
AS BEGIN ATOMIC WITH
(
TRANSACTION ISOLATION LEVEL = SNAPSHOT, LANGUAGE =
N'us_english'
)
SELECT c1 from dbo.T1
END
GO
Performance
You can now perform ALTER
operations on natively compiled
stored procedures using the
ALTER PROCEDURE statement
Use sp_recompile to
recompile stored procedures on
the next execution
Greater Transact-SQL (T-SQL) coverage
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
CREATE PROCEDURE (Transact-SQL)
DROP PROCEDURE (Transact-SQL)
ALTER PROCEDURE (Transact-SQL)
SELECT (Transact-SQL) and INSERT SELECT statements
SCHEMABINDING and BEGIN ATOMIC (required for natively compiled stored procedures)
NATIVE_COMPILATION
Parameters and variables can be declared as NOT NULL
Table-valued parameters.
EXECUTE AS OWNER, SELF, and user.
GRANT and DENY permissions on tables and procedures.
Nesting natively compiled stored procedures
RIGHT OUTER JOIN, LEFT OUTER JOIN, INNER JOIN, and CROSS JOIN in SELECT statements
NOT, OR, and IN operators in SELECT, UPDATE and DELETE statement
UNION ALL and UNION
SELECT DISTINCT
GROUP BY clause with no aggregate functions in the SELECT clause (<select> list).
COLUMNSTORE
COLLATE
Performance
Improved scaling
Other enhancements include:
7x
Performance
In-Memory OLTP
engine has been
enhanced to scale
linearly on servers up to
4 sockets
Improvements in Management Studio
Lightweight performance analysis
• Transaction Performance Analysis report pinpoints
hotspots in the application
Generating migration checklists
• Migration checklists show unsupported features used
in current disk-based tables and interpreted T-SQL
stored procedures
• Generated checklists for all or some tables and
procedures
• Use GUI or PowerShell
Performance
Query Store
Your flight data recorder
for your database
Problems with query performance
Website
Is down
Database
is not
working
Fixing query plan choice regressions is
difficult
•
Temporary
perf issues
Impossible
to predict /
root cause
DB
upgraded
Regression
caused by
new bits
Performance
Query plan cache is not well-suited for performance troubleshooting
Long time to detect the issue (TTD)
•
•
Which query is slow? Why is it slow?
What was the previous plan?
Long time to mitigate (TTM)
•
•
Can I modify the query?
How to use plan guide?
The solution: Query Store
Dedicated store for query workload performance data
Captures the history of plans for each query
Captures the performance of each plan over time
Persists the data to disk (works across restarts, upgrades, and recompiles)
Significantly reduces TTD/TTM
Find regressions and other issues in seconds
Allows you to force previous plans from history
DBA is now in control
Performance
Query data store
Collects query texts (plus all relevant properties)
Stores all plan choices and performance metrics
Compile
Execute
Plan store
Runtime
stats
Works across restarts / upgrades / recompiles
Query
Store
schema
Dramatically lowers the bar for performance
troubleshooting
New Views
Intuitive and easy plan forcing
Durability latency controlled by DB option
DATA_FLUSH_INTERNAL_SECONDS
Performance
Query Store write architecture
Compile
Query text and plan
Query and
Plan Store
async
Execute
Query Execution
Performance
Query exec. stats
Runtime stats
store
Query Store
Internal
tables
Query Store read architecture
Views merge in-memory and on-disk content
Users always see ‘latest’ data
Compile
Query text and plan
Query Store views
Query and
Plan Store
async
Execute
Query Execution
Performance
Query exec. stats
Runtime stats
store
Query Store
Internal
tables
Query Store schema explained
Internal tables
1-n
Query text
Query
Context
settings
One row per query text per
plan affecting option
(example: ANSI NULLS on/off)
Performance
Exposed views
1-n
Plan
Runtime
stats
Compile stats:
query_store_query_text
query_context_settings
query_store_query
query_store_plan
Runtime
stats
interval
One row per plan
(for each query)
sys.
One row per plan
per time interval
(example: 5 min)
Runtime stats:
query_store_runtime_stats_interval
query_store_runtime_stats
Keeping stability while upgrading to SQL Sever 2016
SQL Server 2016
QO enhancements tied to database compatibility level
Install bits
Keep
existing
compat.
level
Performance
Run Query
Store
(create a
baseline)
Move to
vNext
CompatLevel
Fix
regressions
with plan
forcing
Monitoring performance by using the Query Store
The Query Store
feature provides DBAs
with insight on query
plan choice and
performance
Performance
/* (6)
analysis
using Query Store views*/
(1) Performance
Turn ON Query
Store */
SELECT q.query_id, qt.query_text_id, qt.query_sql_text,
SUM(rs.count_executions)
AS total_execution_count
ALTER DATABASE MyDB SET QUERY_STORE
= ON;
FROM
sys.query_store_query_text
JOINparameters */
/* (2) Review current Queryqt
Store
sys.query_store_query
q ON qt.query_text_id =
SELECT * FROM sys.database_query_store_options
q.query_text_id JOIN
sys.query_store_plan
p ONvalues
q.query_id
= p.query_id JOIN
/* (3) Set new parameter
*/
sys.query_store_runtime_stats
rs ON p.plan_id = rs.plan_id
ALTER DATABASE MyDB
GROUP
BY q.query_id,
qt.query_text_id, qt.query_sql_text
SET QUERY_STORE
(
ORDER
BY total_execution_count
OPERATION_MODE
= READ_WRITE, DESC
CLEANUP_POLICY = (
/* (7)
Force plan for a given query
STALE_QUERY_THRESHOLD_DAYS
= 30 */
exec
), sp_query_store_force_plan
12DATA_FLUSH_INTERVAL_SECONDS
/*@query_id*/, 14 /*@plan_id*/
= 3000,
MAX_SIZE_MB = 500,
INTERVAL_LENGTH_MINUTES = 15
);
/* (4) Clear all Query Store data */
ALTER DATABASE MyDB SET QUERY_STORE CLEAR;
/* (5) Turn OFF Query Store */
ALTER DATABASE MyDB SET QUERY_STORE = OFF;
Performance
DB-level feature exposed
through T-SQL extensions
ALTER DATABASE
Catalog views (settings, compile, and runtime stats)
Stored Procs (plan forcing, query/plan/stats cleanup)
Live query statistics
View CPU/memory usage, execution time, query
progress, and more
Enables rapid identification of potential
bottlenecks for troubleshooting query
performance issues
Allows drill down to live operator level statistics:
Number of generated rows
Elapsed time
Operator progress
Live warnings
Performance
Summary: Query Store
Capability
Query Store helps customers quickly find and fix query performance issues
Query Store is a ‘flight data recorder’ for database workloads
Benefits
Greatly simplifies query performance troubleshooting
Provides performance stability across SQL Server upgrades
Allows deeper insight into workload performance
Performance
Row-level security
SQL Server 2016
SQL Database
The need for row-level security
Protect data privacy by ensuring
the right access across rows
Customer 1
Fine-grained access control over specific rows in a database
table
Customer 2
Help prevent unauthorized access when multiple users
share the same tables, or to implement connection filtering
in multitenant applications
SQL Database
Administer via SQL Server Management Studio or SQL
Server Data Tools
Enforcement logic inside the database and schema is
bound to the table
Security
Customer 3
Benefits of row-level security (RLS)
Fine-grained
access control
Application
transparency
Centralized
security logic
Keeping multitenant
databases secure by limiting
access by other users who
share the same tables
RLS works transparently at
query time, no app changes
needed
Enforcement logic resides
inside database and is
schema-bound to the table it
protects providing greater
security. Reduced application
maintenance and complexity
Compatible with RLS in other
leading products
Store data intended for many consumers in a single database/table while at the same time
restricting row-level read and write access based on users’ execution context.
Security
RLS concepts
Performance?
Inline functions get optimized to provide comparable
performance to views, as if the logic were directly
embedded in the original query statement
Predicate function
User-defined inline table-valued function (iTVF) implementing security logic
Can be arbitrarily complicated, containing joins with other tables
Security predicate
Binds a predicate function to a particular table, applying it for all queries
Two types: filter predicates and blocking predicates (coming soon)
Security policy
Collection of security predicates for managing security across multiple tables
CREATE SECURITY POLICY mySecurityPolicy
ADD FILTER PREDICATE dbo.fn_securitypredicate(wing, startTime, endTime)
ON dbo.patients
Security
Example
CREATE FUNCTION dbo.fn_securitypredicate(@wing int)
RETURNS TABLE WITH SCHEMABINDING AS
return SELECT 1 as [fn_securitypredicate_result]
FROM
StaffDuties d INNER JOIN Employees e
ON (d.EmpId = e.EmpId)
Fine-grained access control over
rows in a table based on one or
more pre-defined filtering
criteria, such as user’s role or
clearance level in organization
WHERE e.UserSID = SUSER_SID()
AND @wing = d.Wing;
CREATE SECURITY POLICY dbo.SecPol
ADD FILTER PREDICATE dbo.fn_securitypredicate(Wing)
ON Patients
WITH (STATE = ON)
Security
Concepts:
Predicate function
Security policy
RLS in three steps
Two
App user (e.g., nurse) selects from Patients table
Nurse
Database
Security
Policy
Policy Manager
Filter
Predicate:
INNER
JOIN…
One
Patients
Application
SELECT * FROM Patients
Three
CREATE FUNCTION dbo.fn_securitypredicate(@wing int)
RETURNS TABLE WITH SCHEMABINDING AS
return SELECT 1 as [fn_securitypredicate_result] FROM
SELECT *StaffDuties
FROM Patients
d INNER JOIN Employees e
SEMIJOIN
APPLY dbo.fn_securitypredicate(patients.Wing);
ON (d.EmpId
= e.EmpId)
WHERE e.UserSID = SUSER_SID() AND @wing = d.Wing;
SELECT
FROM Patients,
CREATE Patients.*
SECURITY POLICY
dbo.SecPol
StaffDuties
d
INNER
JOIN
Employees e ON (d.EmpId = e.EmpId)
ADD FILTER PREDICATE dbo.fn_securitypredicate(Wing)
ON Patients
WHERE
= SUSER_SID() AND Patients.wing = d.Wing;
WITH e.UserSID
(STATE = ON)
Security Policy transparently rewrites query to apply filter predicate
Security
Create a security policy
-- The following syntax creates a security policy with a filter
predicate for the Customer table, and leaves the security policy
disabled
CREATE SECURITY POLICY [FederatedSecurityPolicy]
ADD FILTER PREDICATE [rls].[fn_securitypredicate]([CustomerId])
ON [dbo].[Customer];
-- Create a new schema and predicate function, which will use the
application user ID stored in CONTEXT_INFO to filter rows.
CREATE FUNCTION rls.fn_securitypredicate (@AppUserId int)
RETURNS TABLE
WITH SCHEMABINDING
AS
RETURN (
SELECT 1 AS fn_securitypredicate_result
WHERE
DATABASE_PRINCIPAL_ID() = DATABASE_PRINCIPAL_ID('dbo') -application context
AND CONTEXT_INFO() = CONVERT(VARBINARY(128), @AppUserId);
GO
Security
Creates a security policy for
row-level security
The following examples
demonstrate the use of the
CREATE SECURITY POLICY
syntax
For an example of a complete
security policy scenario, see
Row-Level Security
Common RLS use cases
Traditional RLS workloads
Custom business logic to determine which rows each user can SELECT, INSERT, UPDATE, and DELETE
based on their role, department, and security level
Target sectors: Finance, insurance, healthcare, energy, and government
Multitenant databases
Ensuring tenants can only access their own rows of data in a shared database, with enforcement
logic in the database rather than in the app tier
For example: multitenant shards with elastic database tools in SQL Database
Reporting, analytics, and data warehousing
Different users access same database through various reporting tools, and work with different
subsets of data based on their identity/role
Security
Summary: RLS
Capability
Row-level security provides fine-grained access control over rows in a table based on
conditions you set up
Benefits
Store data for many users in the same databases and tables while limiting access by other users
who share the same tables
Security
Temporal
Query back in time
Why temporal
Data changes over time
Tracking and analyzing changes is often important
Temporal in DB
Time travel
Data audit
Automatically tracks history of data changes
Enables easy querying of historical data states
Advantages over workarounds
Slowly changing
dimensions
Performance
Repair record-level
corruptions
Simplifies app development and maintenance
Efficiently handles complex logic in DB engine
How to start with temporal
ANSI 2011
compliant
No change in programming model
CREATE temporal
TABLE PERIOD FOR
SYSTEM_TIME…
ALTER regular_table
TABLE ADD
PERIOD…
DML
SELECT * FROM temporal
INSERT / BULK INSERT
UPDATE
DELETE
DDL
Performance
MERGE
Querying
New Insights
Temporal
Querying
FOR SYSTEM_TIME
AS OF
FROM..TO
BETWEEN..AND
CONTAINED IN
Temporal database support: BETWEEN
SELECT * FROM
Person.BusinessEntityContact
FOR SYSTEM_TIME BETWEEN @Start AND @End
WHERE ContactTypeID = 17
Provides correct information
about stored facts at any
point in time, or between
two points in time
There are two orthogonal sets of scenarios with
regards to temporal data:
System (transaction)-time
Application-time
Performance
How does system-time work?
Temporal table (actual data)
History table
* Old versions
Update */ Delete *
Insert / Bulk Insert
Performance
How does system-time work?
Temporal table (actual data)
History table
* Include historical
version
Regular queries
(current data)
Performance
Temporal queries *
(Time travel, etc.)
Application-time temporal
Limits of system-time
CREATE
TABLE
Employee
SELECT
* Employee
FROM
Employee
ALTER
UPDATE
TABLE
Employee
(
int NOT
NULL,
WHERE
VALID_TIME
CONTAINS
'2013-06-30'
ADD
FOR[EmployeeNumber]
CONSTRAINT
PORTION
OF FK_Employee_Department
VALID_TIME
[Name]
nvarchar(100)
NOT
NULL,VALID_TIME)
FOREIGN
FROM
'2010-01-01'
KEY
(LocationId,
TO '2012-01-01'
PERIOD
[LocationId]
int
NOT
NULL,
REFERENCES Location (LocationId, PERIOD VALID_TIME);
varchar(50)
NOT NULL,
SELECT
* FROM Employee
SET[Position]
[Position]
= 'CEO'
[AnnualSalary]
decimal
WHERE
EmployeeNumber
=
1
AND
WHERE EmployeeNumber = 1 (10,2) NOT NULL,
Time flows ‘forward only’
System-time ≠ business-time
(sometimes)
Immutable history, future does not
exist
ValidFrom
datetime2
NOT ('2013-06-30',
NULL,
VALID_TIME
OVERLAPS
PERIOD
'2014-01-01')
ValidTo
datetime2
NOT
NULL,
DELETE FROM Employee
PERIOD FOR VALID_TIME (ValidFrom,ValidTo),
/*FOR
Temporal
*/
PORTIONjoin
OF VALID_TIME
SELECT
* FROM Employee
E
FROM '2012-01-01'
TO '2013-01-01'
CONSTRAINT PK_Employee
PRIMARY
KEY
JOIN
Position
D CLUSTERED
ON E.Position
= D.Position AND
WHERE
EmployeeNumber
= 1
(EmployeeNumber,
WITHOUT OVERLAPS)
D.VALID_TIME
CONTAINSVALID_TIME
PERIOD E.VALID_TIME
App-time = new scenarios
)
Consistency
Easy time
travel
querying
Performance
Temporal
edits
Correct past records as new info is
available (HR, CRM, insurance,
banking)
Project future events (budgeting,
what-if, loan repayment schedule)
Batch DW loading (with delay)
Temporal data continuum
SQL Database
Performance
In-Memory OLTP and temporal
Extreme OLTP with
cost-effective data history
Disk-based history table
Super-fast DML and current data querying
Temporal querying in interop mode
Fast DML
Internal
data
retention
Performance
Summary: temporal
Capability
Greatly enhances developer productivity
Benefits
Added temporal database support so you can record, audit, and query data changes over time