<Enter course name here> So, when did that change happen. Recognising change, avoiding change and embracing change. Martin Catherall martin@sqldownunder.com SQLDownUnder © 2011

Sponsors Please make sure you visit our fantastic sponsors to get your card stamped to be in the running for a raffle prize:

Senior Consultant SQL Down Under Data Platform MVP Martin Catherall Senior Consultant SQL Down Under Data Platform MVP PASS Regional mentor. Former leader Christchurch SQL Server user group. Committee member (former Organiser) SQL Saturday South Island (Christchurch) Committee member (SQL PASS abstract review) 2014 - 2016

What this session is about As IT (and specifically data) people – we see a lot of change. Some we expected – and maybe we wish to track. Some unexpected. Some we like to avoid. The various change we encounter. How we can detect that change. Do we need to be concerned about the change. How to be ready for change.

What We’ll Cover Stored Procedures (objects) Indexes and Statistics SQL Audit Triggers Service Broker. Temporal Tables. The Query Store. Summary.

Change, SQL – and you! QU :- Where do we encounter change? Data with the database changes Probably the most obvious (but sometimes we need to take action) Meta-data changes Maybe our changing data had an effect on this (eg indexes) Maybe something else changed that had an unintended effect. Functionality changed With our database / application (refactoring – introduce bugs?) With SQL Server (eg. New version, update) Move to the cloud (eg Azure) External Resources Change (fileshares, linked servers, AD) Process Change People Change (Team Members) And more….. Third Party apps detect change – ask yourself how do they do that? You can probably detect the same change with scripts. Does a change in SQL Servers behaviour then dictate a change in our application (eg Triggers to temporal tables) But of course change (in applications) requires development and testing and a process to get tis into production. There must be a business benefit – not simply just a technical one.

Drop and Create (Demo) This can cause big problems (especially in production)

Drop and Create – How to recover If permission are gone, we’ll have to get them back. But HOW? Some DBAs have jobs to script these off regularly. These may be “out of date” – but it’s still a good start. Always double check though against an existing backup. But get up and running first if possible. Restore a backup (on another server) Script off the permissions. Either way – there is downtime involved

DROP and CREATE Summary REALLY try to avoid a DROP on any object. Try to ALTER instead. If this is problematic then get creative! DBAs Check your scripts (from developers) for DROP and CREATE. DO NOT RELY ON CHANGE MANAGEMENT TO PICK THIS UP Developers Be nice to your DBAs  Supply nice ALTER (and maybe re-runnable) scripts (ROBUST scripting)

Drop and Create - INDEX (Demo) This can cause big problems (especially in production)

Question Which statement is the best? Online operation NOT in all versions!

Homework Go have a look at In-Memory OLTP? The rules might just be a little different. No Need to ALTER INDEX REBUILD. If you need to add columns?

Statistics Do you randomly update statistics. Do you drop and create indexes

Triggers – different types. Server Trigger Database creation. Database dropped. Database Trigger Changes at a table level. Insert. Update. Delete. After.

Service Broker Because Triggers….. Service Broker…. Often call synchronous code. Maybe ok on the same instance, machine, LAN Using linked servers may be problematic (slow) Calling disconnected systems may be tricky (slow and UNSAFE) Think webservices. Service Broker…. Is asynchronous Great for long running code or disconnected systems. Can call other systems by passing XML (for instance) Message can be processed automatically Activation. Can call webservices and .NET code (asynchronously)

Service Broker Is worthwhile investing a little time in. CONVERSATION metaphor. Message Type. Contracts Queues. Services. Messages are delivered by Services to Queues. Queues are fully transactions. Messages are delivered in order

Service Broker (DEMO) CONVERSATIONS can be Within a database Within a Server Instance (different databases, same instance) Different instance Same network (eg WINDOWS AUTHENTICATION) Different networks (CERTIFICATES) Think mergers and acquisitions (different systems talking

No change in programming model Temporal Tables Microsoft Ignite 2015 11/19/2018 6:04 PM ANSI 2011 compliant No change in programming model New Insights FOR SYSTEM_TIME AS OF FROM..TO BETWEEN..AND CONTAINED IN Temporal Querying CREATE temporal TABLE PERIOD FOR SYSTEM_TIME… ALTER regular_table TABLE ADD PERIOD… DDL INSERT / BULK INSERT UPDATE DELETE MERGE DML SELECT * FROM temporal Querying Source: https://msdn.microsoft.com/en-us/library/dn935015(v=sql.130).aspx How Does Temporal Work? System-versioning for a table is implemented as a pair of tables, a current table and a history table. Within each of these tables, two additional datetime (datetime2 datatype) columns are used to define the period of validity for each record – a system start time (SysStartTime) column and a system end time (SysEndTime) column. The current table contains the current value for each record. The history table contains the each previous value for each record, if any, and the start time and end time for the period for which it was valid. INSERTS: On an INSERT, the system sets the value for the SysStartTime column to the UTC time of the current transaction based on the system clock and assigns the value for the SysEndTime column to the maximum value of 9999-12-31 – this marks the record as open. UPDATES: On an UPDATE, the system stores the previous value of the record in the history table and sets the value for the SysEndTime column to the UTC time of the current transaction based on the system clock. This marks the record as closed, with a period recorded for which the record was valid. In the current table, the record is updated with its new value and the system sets the value for the SysStartTime column to the UTC time for the transaction based on the system clock. The value for the updated record in the current table for the SysEndTime column remains the maximum value of 9999-12-31. DELETES: On a DELETE, the system stores the previous value of the record in the history table and sets the value for the SysEndTime column to the UTC time of the current transaction based on the system clock. This marks this record as closed, with a period recorded for which the previous record was valid. In the current table, the record is removed. Queries of the current table will not return this value. Only queries that deal with history data return data for which a record is closed. MERGE: On a MERGE, MERGE behaves as an INSERT, an UPDATE, or a DELETE based on the condition for each record. Performance © 2015 Microsoft Corporation. All rights reserved. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

Query Store Query Store SQL Collects query texts (plus all relevant properties) Stores all plan choices and performance metrics Works across restarts / upgrades / recompiles Dramatically lowers the bar for performance troubleshooting New Views Intuitive and easy plan forcing Compile MSG Execute MSG Query Store Durability latency controlled by DB option DATA_FLUSH_INTERNAL_SECONDS Async Write-Back Compile Execute SQL Plan store Runtime stats Query Store schema Query store is a new feature that provides DBAs with insight on query plan choice and performance. It simplifies performance troubleshooting by enabling you to quickly find performance differences caused by changes in query plans. The feature automatically captures a history of queries, plans, and runtime statistics, and retains these for your review. It separates data by time windows, allowing you to see database usage patterns and understand when query plan changes happened on the server. The query store presents information by using a Management Studio dialog box, and lets you force the query to one of the selected query plans. For more information, see Monitoring Performance By Using the Query Store. Performance

Other Methods Jobs (run periodically, could miss something) SQL profiler (deprecated – but still useful…) Extended Events (SQL Audit uses this) Event Notifications (via Service Broker) Third party tools.

Call to Action ! Get the SDU Tools Register at www.sqldownunder.com Thinks about change and what impact it has. On you On your team On your company On your users

Thanks for coming

Sponsors Please make sure you visit our fantastic sponsors to get your card stamped to be in the running for a raffle prize:

Thanks ! Thanks! martin@sqldownunder.com http://www.sqldownunder.com