This is the PASS DW|BI virtual chapter webinar on SQL Server Reporting Services Disaster Recovery with Ayad Shammout and myself - hosted by Julie Koesmarno (@mssqlgirl)

1. SSRS Disaster Recovery
PASS DW|BI Webinar
Ayad Shammout (@aashammout) and Denny Lee (@dennylee)
Hosted by Julie Koesmarno (@mssqlgirl)

2. Agenda
• Review of Scale Out Architectures
• It’s all about the Catalog
• SSRS Disaster Recovery Infrastructure
• Optimizing the Catalog with SQL Server 2012 Always On

3. RSDB
Clients
Flat Files,
OLE DB,
ODBC
SQL, AS,
DB2, Oracle,
Teradata, etc.
RS Server
NLB
Clients
Clients
Reporting Services Architecture
Typical One-Box Deployment
Report Server
ReportCatalog
DataSources(toreportagainst)

4. RSDB
Clients
Flat Files,
OLE DB,
ODBC
SQL, AS,
DB2, Oracle,
Teradata, etc.
RS Server
NLB
Clients
Clients
Reporting Services Architecture
Remote Report Catalog = Higher Availability
Report Server
ReportCatalog
DataSources(toreportagainst)

5. RSDB
Clients
Flat Files,
OLE DB,
ODBC
SQL, AS,
DB2, Oracle,
Teradata, etc.
RS Server
RS Server
RS Server
NLB
Clients
Clients
Reporting Services Architecture
Scale Out and High Availability Infrastructure
ReportingScaleOutDeployment
Report Server Cluster
ReportCatalog
DataSources(toreportagainst)

6. Report Catalog
Architecture
Report Server Catalog (RSDB)
Stores all report metadata including report definitions,
report / history snapshots, scheduling, etc.
Report Server TempDB
Stores temporary snapshots while running reports
 These databases can be a bottleneck
 Optimize by applying standard SQL DB techniques
 Catalog has a lot of I/O and transactions
– RS2005: Many inserts to ChunkData, SnapshotData, and SessionData tables
– RS2008: Many inserts Segment; takes majority of transactions of RSTempDB
RSDB
ReportCatalog

7. Report Catalog
Best Practices > Use a dedicated server
• Same server as SSRS Server
• Great for small environments
• In enterprise environments, too much resource contention
• Same server as data source database
• SQL resource contention (TempDB, plan cache, memory buffer pool) between
data source and RS catalogs
• As load increases need to monitor CPU, I/O, network resources, and buffer
pool
• Reduce resource contention by having a dedicated RS catalog server you can tune.
• Apply high availability and disaster recovery procedures (e.g. clustering, mirroring,
log shipping) to protect the RSDB

8. Report Catalog
Best Practices > High Performance Disk
• Check out Predeployment I/O Best Practices
• Have more smaller size disks with faster rotation speeds (e.g. 15K RPM) vs. fewer larger disks with
slower rotations
• Maximize/balance I/O across ALL available spindles
• Separate disks between RSDB and RSTempDB
• RSDB a lot of small transactions (report metadata)
• RSTempDB has more (not as many) larger transactions
• Pre-grow your databases
• Stripe dB files to number of cores (0.25 – 1.0)
• Minimize allocation contention
• Easier to rebalance database when new LUNs are available
• Use RAID 10, not RAID 5

9. Report Catalog
Best Practices > Operations Best Practices
• Data in RSTempDB is highly volatile
• Report lifetime policy of data = SessionTimeout value (10min)
• CleanupCycleMinutes guides background cleanup thread
• Once session timeout reached, cleanup temporary snapshot from tempDB
• This is done every CleanupCycleMinutes
• Data is RSDB is long lived; should be backed up
• Backing Up and Restore Databases in SQL Server
• Optimizing Backup and Restore Performance in SQL Server
• Backing Up and Restore Encryption Keys
• Maintain your RS catalogs
• Remember, these are SQL databses
• E.g. Re-indexing catalog tables or updating stats may improve query performance

10. Report Catalog
Best Practices > Report Catalog Sizing
• RSDB database size
• Varies by number of reports published and number of history snapshots
• General rule of thumb:
• Moderate size report definition takes 100-200KB of disk space
• This is larger than the actual RDL as SSRS persists both RDL and compiled binary
• Assume 5:1 compression ratio (e.g. 10MB of data, snapshot is 2MB in size)
• RSTempDB database size
• Varies by number of users whom are concurrently using the Report Servers
• Each live report execution generates report snapshot persisted in the RSTempDB
• General rule of thumb:
• 10-20% concurrency of user base, e.g. 1000 users, then max 200 concurrent users.
• If most users are accessing 10MB reports, then you will need 400MB of storage
• 200 users x 10MB reports / 5:1 compression ratio= 400MB
• Want to calculate for the maximum number of concurrent users

11. Scale Out ≠ Disaster Recovery

12. Disaster Recovery Environment
Overall Infrastructure
RSDB
Content Switch
RSDB
RSDB
Primary Data Center
SSRSSSRS
Content Switch
SSRS SSRS SSRS
Failover Cluster
Bostonsql4
Montréalsql4
Disaster Recovery Site
- Closely duplicates primary
- Separate Geographic location
- Non-critical can utilize fewer
resources
- But Mission Critical ssytems
shoul dhave 1:1 duplication
Primary Data Center
- SSRS servers
- Separate Report
Catalog
- With own Failover
cluster

13. Disaster Recovery Environment
Network Configuration
RSDB
Content Switch
RSDB
RSDB
Primary Data Center
SSRSSSRS
Content Switch
SSRS SSRS SSRS
Failover Cluster
Bostonsql4
Montréalsql4
Network Config
- Ensure network
connectivity for clients
- Use content switch to
load balance and redirect
traffic
- Direct fiber between PDC
and DR to minimize
latencies

14. Disaster Recovery Environment
Database Configuration
RSDB
Content Switch
RSDB
RSDB
Primary Data Center
SSRSSSRS
Content Switch
SSRS SSRS SSRS
Failover Cluster
Bostonsql4
Montréalsql4
Database Config
- Bostonsql4 is primary
RSDB instance w/
active/passive cluster in
PDC
- Content switch points to
sql4 alias
- Mirrored Montréalsql4
on DR site

15. Disaster Recovery Environment
Database Configuration: Active / Active vs. Active / Passive
Content Switch
RSDB
Primary Data Center
SSRSSSRS
Content Switch
SSRS SSRS SSRS
Montréalsql4
RSDB
RSDB
Failover Cluster
Bostonsql4
Advantages of Active/Passive Failover Cluster
- Allows other Active database instances to be
located on Passive node
- Works well if passive node is not over-utilized
Not good if passive node has a lot of traffic,
concurrent users, etc. Then should go with
Active/Active cluster

16. Disaster Recovery Environment
Database Configuration: Asynchronous Mirroring
Content Switch
RSDB
Primary Data Center
SSRSSSRS
Content Switch
SSRS SSRS SSRS
Montréalsql4
RSDB
RSDB
Failover Cluster
Bostonsql4
Async Mirroring
All RS Operations must connect to RSDB
for its metadata
Async Mirroring has minimal to no
impact on response time performance
OK to be async as report metadata is not
frequently updated

17. Disaster Recovery Environment
Database Configuration > Initializing Database Mirror
A relatively easy way to initialize a database mirroring setup is to:
1. Make full and transaction log backups of the Reporting Services
databases on the principal server.
2. Copy the backups over to the disaster recovery site, restoring each
Reporting Services database in no-recovery mode.
3. Set up the failover partner on the mirror (that is, the DR site) before
you set up the failover partner on the principal server.

18. Failover Scenarios
• Primary Data Center Reporting Servers go offline
• Primary Data Center RSDB Active server goes offline
• Primary Data Center RSDB cluster goes offline
• Primary Data Center Outage

19. Failover Scenario
Primary Data Center Reporting Servers go offline
RSDB
Content Switch
RSDB
RSDB
Primary Data Center
SSRSSSRS
Content Switch
SSRS SSRS SSRS
Failover Cluster
Bostonsql4
Montréalsql4
Automatic Failover

20. Failover Scenario
Primary Data Center RSDB Active server goes offline
RSDB
Content Switch
RSDB
RSDB
Primary Data Center
SSRSSSRS
Content Switch
SSRS SSRS SSRS
Failover Cluster
Bostonsql4
Montréalsql4
Automatic Failover

21. Failover Scenario
Primary Data Center RSDB Active server goes offline
RSDB
Content Switch
RSDB
RSDB
Primary Data Center
SSRSSSRS
Content Switch
SSRS SSRS SSRS
Failover Cluster
Bostonsql4
Montréalsql4
Manual Failover

22. Failover Scenario
Primary Data Center Outage
RSDB
Content Switch
RSDB
RSDB
Primary Data Center
SSRSSSRS
Content Switch
SSRS SSRS SSRS
Failover Cluster
Bostonsql4
Montréalsql4
Content Switch suspends
primary IP addresses and
activates DR site IP address so
all connections are redirected
to DR site

23. Failover Scenario
Primary Data Center Outage: Planned Outage
RSDB
Content Switch
RSDB
RSDB
Primary Data Center
SSRSSSRS
Content Switch
SSRS SSRS SSRS
Failover Cluster
Bostonsql4
Montréalsql4
Manually execute script to
manually switch to partner
database.

24. Failover Scenario
Primary Data Center Outage: Unplanned Outage
RSDB
Content Switch
RSDB
RSDB
Primary Data Center
SSRSSSRS
Content Switch
SSRS SSRS SSRS
Failover Cluster
Bostonsql4
Montréalsql4
Manually failover script to
force service to switch with
possible data loss

25. Disaster Recovery Environment
Database Configuration: Always On
Content SwitchPrimary Data Center
SSRSSSRS
Content Switch
SSRS SSRS SSRS
SSRS - Always On Availability Group
RSDB
SecondaryReplica
RSDB
PrimaryReplica
AG Listener VNN

26. Q&A
Hope you enjoyed the session!