In August we started taking a look at replication. We learned some of the terms used, and set up a (probably) pretty basic example of replication. Now it’s time to work with it a bit more.
- Open the Replication Monitor.
- Right click on different entries. See what options you have.
- Left click on them and see what shows up.
- Insert a tracer. What does the tracer do? What does the output mean?
- Configure an alert. There are a fair number of options here but hopefully you’ve created an alert before so this should be pretty familiar.
- If you have the option connect to a listener for an instance that has replication and open the replication monitor. What was different?
- Go to the subscriber of an publication. Insert a row into one of the replicated tables. To make this easier make sure that table has a primary key. Then go back to the publisher and insert the same row into the same table. Give it a few minutes and check the replication monitor again. You should see that this is a particularly bad idea. How do you fix it? How do you prevent it?
- Add a new table to the subscriber database. Insert some data into that table. Did that cause a problem with replication? What are some reasons you might do this? What are some reasons why you shouldn’t? How do you avoid problems?
- Modify a replicated stored procedure. Modify a replicated table. Add a column, or change a column’s datatype. Take a look at the subscriber. Did the changes make it there? How about if you add an index?
- Add a second subscriber to a publication. Insert some rows into a replicated table (to be clear add it on the publisher). Take a look at both subscribers. Did the data make it? Why might you want multiple subscribers?