February 21, 2012 at 1:25 pm
I think I can... I think I can... 🙂
Jared
CE - Microsoft
February 21, 2012 at 2:07 pm
Success! 😎
To tell you the truth I am blown away that there wasn't more information on this on BOL or MS forums...almost makes me feel special that I AM THE ONLY ONE 😛 who's ever ran into this...
1421813 transactions rolled forward in database 'distribution' (25). This is an informational message only. No user action is required.
0 transactions rolled back in database 'distribution' (25). This is an informational message only. No user action is required.
Recovery is writing a checkpoint in database 'distribution' (25). This is an informational message only. No user action is required.
CHECKDB for database 'distribution' finished without errors on 2012-02-15 21:08:54.840 (local time). This is an informational message only; no user action is required
A strange observation: There errors arose the entire time the distribution DB was recovering:
Error: 18456, Severity: 14, State: 38.
Login failed for user MYCOMPANY\ThatUser'. Reason: Failed to open the explicitly specified database. [CLIENT: <local machine>]
After the Recvoery completed, the errors stopped. I've verified that user has in no way anything that ties it to the distribution database???
______________________________________________________________________________Never argue with an idiot; Theyll drag you down to their level and beat you with experience
February 21, 2012 at 2:12 pm
MyDoggieJessie (2/21/2012)
Success! 😎To tell you the truth I am blown away that there wasn't more information on this on BOL or MS forums...almost makes me feel special that I AM THE ONLY ONE 😛 who's ever ran into this...
1421813 transactions rolled forward in database 'distribution' (25). This is an informational message only. No user action is required.
0 transactions rolled back in database 'distribution' (25). This is an informational message only. No user action is required.
Recovery is writing a checkpoint in database 'distribution' (25). This is an informational message only. No user action is required.
CHECKDB for database 'distribution' finished without errors on 2012-02-15 21:08:54.840 (local time). This is an informational message only; no user action is required
A strange observation: There errors arose the entire time the distribution DB was recovering:
Error: 18456, Severity: 14, State: 38.
Login failed for user MYCOMPANY\ThatUser'. Reason: Failed to open the explicitly specified database. [CLIENT: <local machine>]
After the Recvoery completed, the errors stopped. I've verified that user has in no way anything that ties it to the distribution database???
Could have been a user specified for creds to the subscriber?
Jared
CE - Microsoft
February 21, 2012 at 2:31 pm
Yep that was exactly it 🙂
It slipped my mind (until you said that) that I set up the security using the default "Impersonate agent process account (Windows Authentication)" (I know, this isn't reccomended)
______________________________________________________________________________Never argue with an idiot; Theyll drag you down to their level and beat you with experience
February 21, 2012 at 2:42 pm
At least you found the source of the problem and were able to rectify it! Happy Fat Tuesday!
Jared
CE - Microsoft
February 21, 2012 at 2:48 pm
The source of the login errors, yes, but still completely in the dark as to what happened to the distribution DB. Well, at least it could be recovered!
Thanks to everyone for the extra set of eyes and suggestions 🙂
______________________________________________________________________________Never argue with an idiot; Theyll drag you down to their level and beat you with experience
February 21, 2012 at 3:27 pm
Congrats buddy, enjoy the success 🙂
March 15, 2012 at 6:37 pm
I know I'm late to the party -- I'm guessing that you have your database files on a netapp san unit.
I'm early on in this theory so take it with a block of salt. I'm betting you have a replicated database and are using the SQL Snap Manager to take backups throughout the day?
I think that can interfere with both replication and long running transactions.
Again, this is a theory, not fact yet.
----------------
Jim P.
A little bit of this and a little byte of that can cause bloatware.
January 28, 2013 at 12:30 am
Although I am late to this thread but would like to share my thoughts.
VM snapshots does cause issues in replication which is nothing but some latency. However, after reading your description it looks to me that the problem with your replication is huge distribution database. It is holding up history for a long time(subscriptions never expire or retention period too high for your environment). The huge size leads to long running distribution cleanup job and causes issues for the distribution agent to add new commands which are ready for replication.
You need to work on reducing the retention period, thus size and you will see huge benefits.
Thanks
Chandan Jha
August 5, 2014 at 12:31 am
Dear Everybody..
I had created a transaction publication and working properly.. Then after I had un installed sql server.
After Installed new instance, previous replication remains same in object explorer. But when checking syspublications.. I didn't get the details of that publication.. In object explorer itself I can't able to delete. Now how can I will remove the replication?
Pls help me....
Viewing 10 posts - 16 through 24 (of 24 total)
You must be logged in to reply to this topic. Login to reply