June 30, 2009 at 4:36 am
I have successfully implemented Transactional replication yet only tables which has primary key has populated on subscriber and the data is also not replicating on subscriber. I have used push subscription and no schedule.
Thanks
June 30, 2009 at 5:02 am
guptaajay1985 (6/30/2009)
I have successfully implemented Transactional replication yet only tables which has primary key has populated on subscriber and the data is also not replicating on subscriber. I have used push subscription and no schedule.
The first criteria of transactional replication is you should have a primary key on the table you want to publish. I didn't understand 2nd part of your question.
June 30, 2009 at 5:12 am
Schedule it (or) Start the process thru Replication monitor or run the relevent job in sqlagent --> jobs. Ensure the Log reader agent is in running state.
June 30, 2009 at 5:21 am
Dear PS,
2nd part means if I am changing any data at publisher side then it should also reflect at subscriber side immediately,but it is not.
LogReader is in running state is visible in replication monitor
Thanks
June 30, 2009 at 5:27 am
your log reader agent must be running continously or at specified intervals to read the log of the published database and bring 'changes' to subscribed articles to the distribution database. Once the transactions are moved to the distribution db, the distribution agent moves the database to the subscribers.
As suggested by Rajan, your log reader job must be scheduled for the transactions to move to distribution db.
side-effect - Since you've not scheduled your log reader agent, your publisher db's log will keep on growing (backing up the log wont truncate log as the db is replicated).
June 30, 2009 at 5:31 am
ps (6/30/2009)
your log reader agent must be running continously or at specified intervals to read the log of the published database and bring 'changes' to subscribed articles to the distribution database. Once the transactions are moved to the distribution db, the distribution agent moves the transactions to the subscribers.As suggested by Rajan, your log reader job must be scheduled for the transactions to move to distribution db.
side-effect - Since you've not scheduled your log reader agent, your publisher db's log will keep on growing (backing up the log wont truncate log as the db is replicated).
EDIT - corrected word in BOLD above.
June 30, 2009 at 6:02 am
Now data is reflecting...
Thanks
June 30, 2009 at 6:11 am
Glad you got it working.
did you schedule the job to run at specific intervals or manually ran it once? I suggest u schedule it at regular intervals (may be off-peak hours too).
June 30, 2009 at 10:41 pm
Should I schedule all jobs or which one I should schedule
AjayG-----publisher/distributor machine name
cicenrich--database name
MADANB--Subscriber machine name
These are the jobs:
Agent history clean up: distribution
AJAYG-cicenrich-1
AJAYG-cicenrich-Pub_enrich-1
AJAYG-cicenrich-Pub_enrich-MADANB-3
Distribution clean up: distribution
Expired subscription clean up
Reinitialize subscriptions having data validation failures
Replication agents checkup
Replication monitoring refresher for distribution.
Thanks
June 30, 2009 at 10:59 pm
one more error:
" The row was not found at the Subscriber when applying the replicated command"
in view synchronization monitor
Thanks
June 30, 2009 at 11:08 pm
Dear All,
I want to know meaning and working of all jobs...
Thanx
Thanks
June 30, 2009 at 11:22 pm
guptaajay1985 (6/30/2009)
Dear All,I want to know meaning and working of all jobs...
Thanx
Due to the depth and breadth of this request, the best I can do is tell you to start reading all about Replication in BOL (Books Online, the SQL Server Help System that you should have installed along with your client tools).
You may access BOL from SSMS (SQL Server Management Studio) by pressing the {f1} function key.
June 30, 2009 at 11:49 pm
one more error:
" The row was not found at the Subscriber when applying the replicated command"
in view synchronization monitor
This error would normally occur due to while publication is trying to any IUD (insert/update/delete) operation and referred row is missing in the subscriber and replication is not synchrnozing further. The mismatch can be found using TableDiff utility or other thirdparty tools.
Solution, either to reinitiliaze or find out the missing row and update/insert... in the subscriber.
July 2, 2009 at 5:28 am
This is the common error that you see in the replication. Seems like you are new to replication? The definition is correct. A row is there at the publisher and the same is not in the subsscriber. You should not have snapshot the publication for various reasons. You can chose to skip them if that is OK. You can do that by going to replication monitor and right click on the subscriber and change the agent profile to Skip errors on dataconsistency.
Or you can alternatively remove this error in the corresponding proc at the subsciber.
July 2, 2009 at 10:46 am
Agent history clean up: distribution
Default schedule is daily, every 10 minutes.
AJAYG-cicenrich-1
This is your queue reader agent job. It doesn't really matter for traditional transactional replication. By default it's set to start automatically when SQL Server Agent starts
AJAYG-cicenrich-Pub_enrich-1
This is your log reader agent job. Set it to start automatically when SQL Server Agent starts
AJAYG-cicenrich-Pub_enrich-MADANB-3
This is your distribution agent job. You can either set it to start automatically when SQL Server Agent starts (recommended) or to some regular frequency like once a minute.
Distribution clean up: distribution
Default schedule is daily, every 10 minutes.
Expired subscription clean up
Default schedule is daily at 1:00 AM.
Reinitialize subscriptions having data validation failures
Default is no schedule
Replication agents checkup
Default schedule is daily, every 10 minutes
Replication monitoring refresher for distribution.
Default is that this job is disabled
Viewing 15 posts - 1 through 15 (of 18 total)
You must be logged in to reply to this topic. Login to reply