1. How to keep your database servers out of the news Matt Gordon

2. Speaker info Matt Gordon Data Platform Solution Architect

3. About ME 15+ years of SQL Server experience Managed 24x7 datacenters
Worked on development teams
MCSE: Data Management and Analytics
PASS Summit 2017 Speaker
Home cook and car geek

4. How I picked my twitter handle and domain name

5. About you How many first-timers do we have here today?
What version of SQL Server are you running?
Are you a database developer?
Are you a DBA?
Is the answer to the last two questions yes?
Were you just looking for a place to hang out until lunch?

6. agenda Security HADR Terms And Concepts Replication Log Shipping
Database Mirroring
Always On Availability Groups
Always On Failover Cluster Instances
Basic Availability Groups
Takeaways

7. security SQL Server Security Basics Physical security OS security
Patching
Windows Firewall
Surface area
Ad Hoc Distributed Queries
Xp_cmdshell

8. security SQL Server Security Basics (continued) Smart role assignment
Not everyone needs to be a sysadmin!
Not everyone needs to be db_owner!
Authentication mode
Password policies for SQL logins
SQL Server patching
Encryption
TDE, Always Encrypted, Column-level Encryption

9. security SSMS Vulnerability Assessment
Introduced in SQL Server Management Studio 17.4
Released December 2017
Can run at database and server level
Supported for SQL Server 2012 or later
Also works on Azure SQL Database

10. SSMS Vulnerability assessment
Image from The PFE Chronicles MSFT blog

11. SSMS Vulnerability assessment
Image from The PFE Chronicles MSFT blog

12. SSMS Vulnerability assessment
Image from The PFE Chronicles MSFT blog

13. What Is HADR? HA = High Availability DR = Disaster Recovery
Related topics
Different approaches needed
HADR, not Hader!

14. What Is high availability (HA)?
Techopedia.com says…
“[it] refers to systems that are durable and likely to operate continuously”
Layman’s terms
Minimize downtime
Minimize the impact of necessary downtime
May or may not mean the system is always available

15. Setting high availability goals
HA goals cannot be set in a vacuum
Collaboration with operations
Collaboration with customer-facing teams and personnel
Collaboration with contract personnel
Service level agreements (SLA)
Legal consequences
Corporate consequences

16. Setting high availability goals
Customer needs
Business dependent
Set expectations based on implementation and support costs

17. implementing high availability
NOT only a software decision
Choose tools/technology supportable by your team
Technical decision is only part of the battle
Processes are critical
Defined
Repeatable
Testable

18. Setting high availability goals
Personnel are critical
Best design hamstrung by lack of training
Talent and training are key

19. What is disaster recovery (DR)?
Similar but different than HA
Focuses on re-establishing availability
AKA business continuity

20. What is disaster recovery (DR)?
Natural disasters
Regional impact
Direct datacenter impact
Technical disasters
Database team members
Non-database team members

21. Implementing a disaster recovery plan
Processes and personnel still critical
Processes must be recorded and accessible
Personnel must be trained

22. Implementing a disaster recovery plan
Regular testing required
Difficult conversation
If you do not test your DR plan, you don’t have one
Project-level understanding
Should be considered at all times during a project
Communication is key

23. Replication terms and concepts
Copies data and database objects
Publisher, Distributor, and Subscriber

24. Replication terms and concepts
No automatic failover
Code must account for outage
Three typical steps:
Initial synchronization (snapshot)
Publisher data changes picked by distributor
Data flows to subscriber
Three main types of replication…

25. Types of replication Snapshot Generated by Snapshot Agent
Completely overwrites existing data
Transactional
Log Reader Agent on Distributor reads data changes out of the Publisher’s transaction log
Data changes are written to the distribution database
Data flows to Subscriber via Distribution Agent
Transactionally consistent

26. Types of replication Merge Exactly what it sounds like
Merges changes between publisher and subscriber(s)
Would say more but am not supposed to swear in PASS talks

27. Replication usage scenarios
Report server
Direct intense queries away from primary database
Applicable for data that may not need to be real-time
Remote office
Ensure data lives at another site
Network connectivity may not allow for synchronous data
Data movement
ETL may be kicked off from replicated data
May make data accessible to other groups

28. Replication pros and cons
GUI to manage and monitor
Enterprise Edition not required for basic functionality
Control of frequency and amount of data replication
Cons
No automatic failover
Can filter data but performance may suffer
Administrative effort increases exponentially

29. What is log shipping? Consists of three steps Transaction log backup
Log backup sent to one or more secondary servers
Log backup is restored on secondary servers
Monitor server
Optional
Records history and status of configuration

30. Log shipping terminology
Primary server
SQL Server instance serving as primary
Primary database
Database on primary server being backed up to other servers
Secondary server
SQL Server instance storing warm standby copy of primary

31. More log shipping terminology
Backup job
Performs log backup and does cleanup
Copy job
Copies backup files to secondary servers(s)
Restore job
Restores copied backup files to secondary servers
Alert job
Alerts when backup or restores are not completed within specified thresholds

32. Log shipping diagram

33. Log shipping pros and cons
Database-wide DR solution
Possible read-only access to secondary databases
Can set delay between backup and restore
Cons
Secondary data only available when replica in STANDBY status
Manual failover only
Requires broad permissions to move files throughout the network

34. Database mirroring SQL Server 2012 release indicated deprecation
Microsoft recommends avoiding this feature for new solutions
Still exists in SQL Server 2016(+)

35. Database mirroring description
Log records are sent from the principal (primary) database servers to the mirror server
Optional witness server enables automatic failover

36. Database mirroring modes
High-Safety
Always commits changes at both principal and mirror server
Required for automatic failover (along with a witness)
Transaction latency may increase
High-Performance
Asynchronous operation
Manual failover only permitted failover
Data loss is a possibility

37. Database mirroring usage scenarios
Automatic failover is required but Always On AG or FCI is not feasible
High-safety mode ensures no data loss at mirror
Supporting SQL Server 2005 or 2008

38. Always on availability groups
Containers for sets of databases to failover together
They are not “Always On” by themselves
Database mirroring on steroids

39. Always on availability group terms
Availability database
Database that belongs to an availability group
Primary database
Read-write copy of an availability database
Secondary database
Read-only copy of an availability database

40. Always on availability group terms
Availability replica
Instantiation of an availability group that is hosted by a specific SQL Server instance
Primary replica
Availability replica that makes the primary databases available for read-write connections

41. Always on availability group terms
Secondary replica
Availability replica maintaining secondary copy of each availability database and serving as a potential failover target
Availability group listener
Virtual network name to which clients can connect to access a database on a replica

42. Always on availability group features
Multi-database failover
Built-in compression and encryption
Automatic page repair
Synchronous or asynchronous data movement options
8 total secondaries, 3 synchronous replicas allowed in SQL Server 2016(+)

43. Always on availability group pros/cons
Failover groups of databases
Flexible failover policies
Basic load balancing (SQL 2016 and above)
Database-level health detection (SQL 2016 and above)
Cons
Relies on WSFC so interaction with Windows ops is required
Need to consider load on infrastructure with quantity of data moving
Requires Enterprise Edition (except for Basic Availability Groups)
Constant communication forces review of maintenance procedures

44. Always on failover cluster instances
Installed via SQL Server Setup
Unit of failover is the SQL Server instance
Requires shared storage
Same virtual network names used regardless of node

45. Basic availability groups
Eventual replacement for database mirroring
SQL Server 2016(+) only
Limited to one database
Similar behavior, but not as fully featured as Enterprise Edition
Gateway to Always On Availability Group functionality
Management similar to full-featured AGs
Cannot offload reads to replica
Cannot offload backups to replica

46. Key takeaways Tools and technologies change – keep abreast of those
Notice we did not discuss Azure options at all
Communicate within your team
Communicate with all teams involved in design and support
No perfect answer for every scenario

47. Questions?

48. How to contact me Matt Gordon Data Platform Solution Architect