• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 332
  • Last Modified:

Triggers on replicated SQL-server database

I am using sql-server 2005. My setup is like this:

Server A ----> Server B.

Server A is replicated to server B synchronously. (No data needs to come back from server B) I am using the built in transcription replication.


I have written triggers that need to fire when data is modified on Server A. I only need to read the data generated by these triggers on server B.

The triggers involve some complex views and will be quite taxing on server A. Server A is mission critical, server B is not.  I want there to be minimal impact on Server A.

Is it possible to have triggers fire on Server B when the transactions from Server A change things, as opposed to have them fire on Server A when the tables are first modified?

To illustrate:

SCENARIO ONE:

a. User modifies table x on Server A.
b. an update to table x causes a trigger to fire which records data in table y.
c. Server A replicates the data in table x and table y to server B.

SCENARIO TWO:

a. User modifies tabel x on Server A.
b. Server A replicates the data in table x to server B.
c. An update trigger on Server B fires when it detects that the replication transaction has changed the data in table x.
d Server B records data in table y.


I want Scenario Two, can it be done?
0
rdun25
Asked:
rdun25
  • 2
  • 2
1 Solution
 
David ToddSenior DBACommented:
Hi,

The thing to be careful of is what is the replication synchronisation set to? Is it delete table and create a new one? (this will delete your triggers) or truncate and insert records?

I can't see why scenario two would work.

The catch for me is that you said the replication is synchronous - doesn't that mean that before ServerA commits a transaction, it sees that it committed in ServerB first? Therefore anything you do by way of a trigger on either server will affect performance.

Do you need a trigger? Can it be done on ServerB with a regularly scheduled job?

Regards
  David
0
 
rdun25Author Commented:
Thank you for your response. I am sorry, I may be confusing terms here (I've only had cursory experience with SQL).

The replication from Server A to Server B is a transactional replication. So any changes to Server A are replicated to Server B. I am using the built in Replication system.

Could you elaborate on  how a scheduled job would work? I need to record if any changes have been made to several tables in the database. At the moment there are UPDATE, CREATE and DELETE triggers which record the Primary Key of the altered table and a timestamp.
0
 
David ToddSenior DBACommented:
Hi,

I understand the inbuilt transactional replication, as I used it extensively on a previous job.

Scheduled Job. What I'm asking here, is there any way to identify new data without the use of a trigger. Can you have a separate table with the id's of the rows already processed. Then a select to find the new ones is

select t.*
from dbo.sometable t
left outer join idtable i
    on i.id = t.id
where
    i.id is null

So instead of a trigger, write a stored procedure to do what you need, and then in SQL Agent create a job with the job-step which calls the procedure, and schedule it every couple of minutes.

HTH
  David
0
 
rdun25Author Commented:
Thanks, that's brilliant. Probably be better and less demanding than triggers.
0

Featured Post

Get your problem seen by more experts

Be seen. Boost your question’s priority for more expert views and faster solutions

  • 2
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now