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

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

3. 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)

4. 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.

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

6. 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.

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

8. 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

9. 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)

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

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

12. 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?

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

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

15. 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)

16. 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

17. 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

18. No change in programming model
Temporal Tables
Microsoft Ignite 2015
11/19/2018 6:04 PM
ANSI 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:
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 – 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
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.

19. 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

20. 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.

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

22. Thanks for coming

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

24. Thanks !
Thanks!