views:

343

answers:

3

Data from another system is replicated into a SQL Server 2005 database in real-time (during the day, it's hundreds of transactions/second) using Goldengate. I'd like to be able to tell if there's been a transaction recently, which will tell me if replication is currently happening. Even in the off-hours, I can expect a transaction every few minutes, though I won't know which of the 400 tables it will go into.

Here's my current process:

  1. IUD trigger on most popular replicated table
  2. Updates date in "Sync Notification" table every time there's any activity on that table
  3. SQL Agent job runs every few minutes and compares this date with GETDATE(). If it's been too long, it emails me.

This works for the most part, but I get false positives if there's activity in other tables, but not the monitored one, which can happen overnight.

Any other suggestions short of adding this same trigger to every table in the database? If I do add the triggers, how to I prevent deadlocks and contention on the "Sync notification" table? Since I don't care about the most recent date being exact during high-contention periods, is there a way I can have SQL try to update the date but just skip it if some other process has locked it?

The only "application-level" choice I have is to TELNET to the Goldengate monitor and ask for the replica lag, then screen scrape the results. I'm open to that, but I'd like to do something SQL-side if it's more feasible.

+2  A: 

Is this for an automated job or something you want to look at every now and then? If the latter, then you could use a transaction log examination tool (Redgate Log Rescue, Apex SQLLog, probably others).

Another option open to you is look at sysindexes (SQL Server 2000: dbo.sysindex; 2005: sys.sysindexes). The column rowmodctr (to quote MSDN) "Counts the total number of inserted, deleted, or updated rows since the last time statistics were updated for the table". It may not return everything you need to know but, providing you've got covering indexes, it would give an indication of how many and where the changes there have been if sampled on a regular basis.

Chris J
I'd prefer that it be for both - I'd like an automated process to run every minute or two and email me if it goes "out of sync" by some time limit, and I'd also like to query it on-demand when I'm running certain sync-critical processes that require the data to be up to date. Running "select sum(rowmodctr) from sys.sysindexes" seems to update every few seconds, so this might be the way I end up going.
rwmnau
This works like a champion - thanks!
rwmnau
+1  A: 

You can check SELECT * FROM ::fn_dblog(@startLSN, NULL) and see if any LOP_MODIFY_ROW operation occured since the last check (since last LSN you checked).

Remus Rusanu
We're currently using Simple logging - would this method require that full logging be enabled?
rwmnau
yes, full or bulk recovery model would be required. With a simple recovery model the log records may be deleted and re-used as soon as a checkpoint occurs.
Remus Rusanu
A: 

Good answer , Thank you very much

Neelam