November 2, 2014 at 6:33 am
I'm a contractor at a customer. Sometime on Tuesday, a gremlin installed transactional replication on the production server. As a result, accounting can no longer post to the GL and AP can't write checks. I'm not trying to fix that. The question I am being asked is if there is a way to show who installed transactional replication? Would there be a specific log file for SQL features and such, or would I go to the server event log? My assumption is that it is the DBA pretender and he's finally gone a step too far. But other people had access, so I need to be able to rule out everyone.
Thanks
Adam
November 2, 2014 at 7:46 am
I should also note that I do not have all the permissions to read logs and such. I'll just be passing on some recommendations and maybe looking over someone's shoulder who does have the rights.
AA
November 2, 2014 at 8:15 am
I don't think it gets logged anywhere. At best, if there's anything in the SQL error log (which I've never seen) it'll have the SQL login name. So if it's someone logging in as SA, you're SOL.
It will be someone with high permissions.DB_Owner of the database in question minimal, probably need full on sysadmin to do the full setup.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
November 2, 2014 at 10:44 am
I know it's their DBA, but just because of a process of elimination as no one else would be adding replication. The problem is that their SR DBA isn't qualified to be a JR. I mean this guy uses his login as the service user accounts and uses Log Shipping as a backup for transaction logs. lol. Aside from departments knowing that something isn't right, no one can pinpoint anything because there isn't any other database people in the company. Anyways, he's already a dead man walking. He's getting replaced next year. I think some VPs are wanting to replace him now, but they need proof that it was his incompetence that has caused this. It's the end of the month and their financial side of the business has been at a halt for almost a week.
November 2, 2014 at 10:54 am
Unless you had some auditing in place, I doubt there wouid be any evidence. I've never noticed log entries when setting up replication myself.
You might check the default trace, but since it only contains 5 files of 20 MB, it's quite likely that it will have rolled over and lost any evidence.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
November 3, 2014 at 8:01 am
If there is a subscriber, you could always check to see who the owner of the database is on it.
November 3, 2014 at 8:14 am
All that has been cleaned up now. I was hoping there was a log somewhere to show some history with a login and a time. My theory is that he was setting up replication on DEV, but was one the wrong box. DEV and PROD have the same SA login/password. I was listening to the conversation today and turns out there are a number of people with the SA password for these two servers. Oh well. This is probably the second worst SQL configuration I have seen before. It's just sad that it has taken the client three years to figure it out. Anyways, no evidence just means the hangman will not be showing up early. He's still showing up though. lol
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply