* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Download Performance?
Survey
Document related concepts
Microsoft Access wikipedia , lookup
Concurrency control wikipedia , lookup
Relational algebra wikipedia , lookup
Entity–attribute–value model wikipedia , lookup
Functional Database Model wikipedia , lookup
Ingres (database) wikipedia , lookup
Open Database Connectivity wikipedia , lookup
Extensible Storage Engine wikipedia , lookup
Microsoft Jet Database Engine wikipedia , lookup
Microsoft SQL Server wikipedia , lookup
Versant Object Database wikipedia , lookup
Clusterpoint wikipedia , lookup
Transcript
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