To limit the risk and damage of systems failure and downtime, organizations need to be agile in their response to change. Considering the damage that intentional and planned changes can do, when the changes are unexpected, the outcomes are often far worse. Unexpected database changes can easily go undetected, and the sooner such changes are uncovered, the sooner database teams can set about reversing the change. This makes capabilities like SQL Server monitoring integral in today's data-driven business landscaper. Visit https://www.idera.com to learn more. Speaker: K. Brian Kelley is an author, columnist, and former Microsoft SQL Server MVP, focusing primarily on SQL Server and Windows security. Besides being a database administrator, he has served as an infrastructure and security architect encompassing solutions with Citrix, virtualization, and Active Directory.

1. Detecting and Responding to
Database Change
“Who ran what in production?”

2. About Me
• Security Related:
– Infrastructure & Security Architect
– Certified Information Systems Auditor (CISA)
– Accredited CISA Trainer
– Incident Handler / Penetration Tester
• SQL Server Related:
– Data / Database Architect
– SQL Server security columnist / blogger
– SQL Server and Security speaker & trainer

3. Agenda
• Understanding the Risk
• Default Trace & Server Traces
• Triggers – Data and DDL
• Extended Events

4. Understanding the Risk
DDL is important, too

5. What do I care about?
• Unexpected Changes to Data
• Changes to Objects Themselves
• Creation of New Databases
• Creation of New Objects

6. Default Trace
If you didn’t prepare ahead of time, maybe…

7. Default Trace
• Enabled by default
• Primarily for schema changes
• Contains much more
• Trace files in the Log directory

8. Demo – Schema Changes History

9. Triggers
Capturing & Preventing Changes to Data and Objects

10. DML Triggers
• Two Types
• Protecting Data
• Some Practices to Avoid

11. inserted and deleted Tables
• Special tables available inside the trigger
• Allows us to see data changing
• Can use for auditing

12. inserted and deleted Tables
Operation INSERTED DELETED
INSERT New Rows (not used)
UPDATE New Rows Old Rows
DELETE (not used) Old Rows

13. DML Triggers - Protecting Data
• Parallel table structures for audit
• Enforcement of data integrity rules

14. Demo - DML Triggers

15. DDL Triggers
• Why They Exist
• How to Use
• Turning Them On/Off

16. DDL Triggers – Why?
• Introduced in SQL Server 2005
• Protects the schema / database structure
• SCHEMABINDING is limited

17. DDL Triggers – A Brief Intro
• Two Levels
– Server
– Database
• Fire on events
• Don’t fire on temporary objects
[Temporary objects are created in TempDB]

18. Understanding ROLLBACK
• Effectively an UNDO
• Applies to entire batch
• If event data is important
– ROLLBACK erases it
– Capture in variables first

19. DDL Triggers – EVENTDATA()
• Captured and presented in XML format:
<EVENT_INSTANCE>
<EventType>CREATE_TABLE</EventType>
…
<LoginName>TESTINGDBA</LoginName>
…
<TSQLCommand>
<SetOptions ANSI_NULLS="ON" ANSI_NULL_DEFAULT="ON"
ANSI_PADDING="ON" QUOTED_IDENTIFIER="ON" ENCRYPTED="FALSE"/>
<CommandText>CREATE TABLE foo&#x0D;
(&#x0D;
foo1 int&#x0D;
)&#x0D;
</CommandText>
</TSQLCommand>
</EVENT_INSTANCE>

20. Demo – DDL Triggers

21. Extended Events
The best way to detect anything

22. Audit Object
• Built on top of Extended Events
• Two Levels
– Server
– Database
• SQL Server Version, Edition, Update Level Important

23. Audit Object Support
Server Level Database Level
SQL Server 2014 All Enterprise Edition only
SQL Server 2016 All All as of SP1
SQL Server 2017 All All
SQL Server 2019 All All

24. Extended Events
• Replacement for Profiler / Trace
• New features are only instrumented with Extended
Events
• More Lightweight
• More Customizable

25. Schema Changes
• Note the TWO events
• One event for BEGIN
• Second event for COMMIT

26. Demo – Extended Events Objects