1. SQL Replication for RCSQL 4.5
Presented by Mary Monroe and Todd Endicott

2. Process Scheduling Downtime Using a Service Account
Preparing the Database
Setup Distribution
Setup Publication
Setup Subscription
Working with RNDB v4.5
Downtime – Replication can take a considerable amount of time to get setup the first time around. If you have a large database you should plan on a day just in case.

3. Using a Service Account
Create the user account

4. Using a Service Account
Make sure that SQL Server and SQL Server Agent are running as this new user.

5. Using a Service Account
Create a REPLDATA folder in a location of your choosing.
Make sure that the SQLREPL account has FULL CONTROL to this location.
Make sure that you have a Windows Authentication account in the Security Settings in SQL.

6. Using a Service Account
Should be a sysadmin account and allow the SQLREPL account DBO rights on the RCSQL database.
During the creation of the Publication and Subscriptions you will use this account to run the Agents.

7. Preparing the Database
Backup the RCSQL database
Copy (.bak or mdf/ldf)
Restore (Attach)
Choice depends on how you intend to move the files.
If you allow the users to remain in the system during the replication setup you will have to use the Backup/Restore method
If you kick them out and stop the SQL Services you can copy and then let them back in. Then re-attach on the Replica side.
Copy is typically faster unless there are network issues.

8. Setup Distribution
The distribution database stores metadata and history data for all types of replication, and transactions for transactional replication.

9. Setup Distribution
The Snapshot Folder should be set to the location you created the REPLDATA folder in.

10. Setup Distribution
The Generate script option allows you to create the distribution database at a later time.

11. Setup Distribution

12. Setup Publication

13. Setup Publication
Make sure to remove the RescueNetCentralReportingLog table; it can be quite large and there is virtually no reason to report on its contents.
There are also some tables that are not automatically selected and they have the well known “NO” symbol in front of them. These tables do not have primary keys and should not be replicated. There is a way to create the primary keys so that they can be used, but none of the standard ZOLL reports use these tables.

14. Setup Publication
Create the Snapshot immediately, or schedule it for a later time. We are going to create it immediately.
Click the “Security Settings” button to set the user who will be running the Snapshot and Log Reader Agents.

15. Setup Publication
You will want to use your SQLREPL account to run the agents, select to impersonate the process account in the Connect To Publisher section.

16. Setup Publication
As with the snapshot, you can script the creation of the publication for later use. We will create it immediately.
Verify that your settings are correct and click Finish.

17. Setup Publication
Once you see success in the wizard you are done. You can view the Publisher in SQL Studio Manager under the Local Publications section. This shows the Publisher on this server is sending data to the RNDB45-2 server and the DB that is replicating is RCSQL.

18. Wait for it... Snapshot Agent Status
Once you are at this point you need to check out the Snapshot Agent before moving forward! If you do not then the jobs will step all over each other and you will not likely get replication to work correctly.
From the Local Publications section, right click the upper most level and choose View Snapshot Agent Status.
If it is 100% complete then move on to creating the Subscription.

19. Setup Subscription
Right click the Local Subscriptions listing and choose New Subscription.
Selecting the wrong method can lead to serious performance issues, especially during peak database usage.
Choosing the server with the lesser load to request the transactions is best. If your production server is very busy, you would run the distributor to another location and then potentially have the subscriber PULL the transactions.
If your reporting server has the heavier load then choosing the PUSH may benefit you by not making the Subscriber responsible for getting data.
==============
Reword:
Consider the following example scenarios based upon the key factors I just mentioned; and these are by no means exhaustive:
1. Your Publisher receives millions of records per day in a high-transaction environment. Running Distribution remotely would be ideal, but budgetary constraints have forced you to run Distribution on the Publisher.
Solution: Strongly consider using the Pull method.  The server running Publishing and Distribution will be under heavy load so place the burden of receiving replicated data on the Subscriber.
2. Your Publisher is moderately busy. Distribution is running remotely.  Your Subscriber is a highly-used reporting system with heavy disk I/O and periods of high CPU usage.
Solution: Strongly consider using the Push method.  A heavy reporting load on the Subscriber need not be further complicated by forcing the Subscriber to Pull replicated data from the Distributor.  Let the Distributor handle that task.
Selecting the correct method (Push vs. Pull) to move data from the Distributor to the Subscriber(s) is a key factor in deploying a successful replication topology.  It is worth spending some extra time in the planning stages to work out the method you will use.  Your client, end users and DBAs will thank you in the end.

20. Setup Subscription

21. Setup Subscription

22. Setup Subscription

23. Setup Subscription

24. Setup Subscription

25. Replication Monitor Troubleshoot Issues with Replication
View Replication Transactions
View Replication Health
View Job History

26. Replication Monitor

27. Already Replicating? Database Structure Upgrading RNDB to v4.5
DSS Setup for Reporting

28. Database Structure RCSQL RCSQL_VIEWS RCSQL_ARCHIVE DTC
Unions between Live and Archive
RCSQL_ARCHIVE
Archived Runs
DTC
Method used to push records to Archive
Microsoft Distributed Transaction Coordinator
Requires Integration Services installed w/SQL

29. Upgrading RNDB to v4.5 Remove Replication Remove DSS Server Setting
If moving to a new server with Archiving
Upgrade RNDB
Reconfigure Replication

30. Replication

31. Archiving

32. “Reporting” Database

33. DSS Settings

34. RCSQL_VIEWS Offloading reporting to the Replica
This database allows you to report off both Production and Archive
Do NOT replicate this database
Copy RCSQL_VIEWS db to the Archive server.
RCSQL_VIEWS db always looks locally for RCSQL
Point the RightCad_DSS DSN to this database

35. RCSQL_ARCHIVE Location of Archived records
Do NOT replicate this database
Same Server / Different Instance
Not recommended in large environments
Defeats the purpose of archiving

36. Using DSS Configure RN Admin Configure RightCAD32-DSS DSN
Configure RescueNet Reporting
Launching the report

37. RN Admin Config

38. RightCAD32-DSS DSN

39. RightCAD32-DSS DSN

40. RightCAD32-DSS DSN

41. RightCAD32-DSS DSN

42. RescueNet Reporting

43. Maintenance Plans Backup and Update Stats Rebuild Index
Reorganize Index

44. Maintenance Plans
Backup
RCSQL
RNEnterprise
UDXMapping

45. Maintenance Plans

46. Maintenance Plans

47. Maintenance Plans

48. Maintenance Plans
Reorganize can be done online. It should be done on a regular basis either from the beginning of the database or from the time that you perform a full Re-Index.

49. Maintenance Plans
Rebuild can be done on a yearly or even bi-annual basis at the least. If you are seriously fragmented you should perform this plan offline and follow it up with a regular Reorganize plan.

50. Maintenance Plans

51. Thanks for coming!