November 12, 2014 at 9:13 am
This is a postmortem trying to understand what actually happened.
Last night on one our production systems we executed:
ALTER DATABASE... SET ENABLE_BROKER WITH ROLLBACK IMMEDIATE;
ALTER DATABASE... SET TRUSTWORTHY ON WITH ROLLBACK IMMEDIATE;
(hence why it was done in the middle of the night)
No other scripts or statements were executed against the system, just the two above to prepare a production database for an upcoming SSB deployment. We can do the rest of our deployment and troubleshooting during the day. The two statements above were the only ones that would've been disruptive, so we ran 'em preemptively during our maintenance window.
Unexpectedly, not one minute later the replication log reader agent started failing, complaining about the -owner- for that database. This went a few hours before anyone noticed, but was a simple fix. The database was owned by sa before, so a simple ALTER AUTHORIZATION, and replication is happy as a lark now. Whatever a lark is.
I've tried to duplicate the issue with a test database, but to no avail, not even with a transaction in-flight when the ALTERs are run. The database is owned by sa at the start, and again after. I haven't thrown replication into the mix with the test yet, will probably try that later unless I can get an alternate theory here.
Does anyone happen to know what special condition might have caused either of the two statements above to trigger a database owner change?
Viewing post 1 (of 1 total)
You must be logged in to reply to this topic. Login to reply