SQL 2012 Always On Availability Group change (or alter) DB owner does not replicate to secondary - by TC_msp

Status : 

  Won't Fix<br /><br />
		Due to several factors the product team decided to focus its efforts on other items.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.

Sign in
to vote
ID 723879 Comments
Status Closed Workarounds
Type Bug Repros 17
Opened 2/7/2012 10:36:52 AM
Access Restriction Public


When altering a database owner who is a member of an Always On Availability Group the primary DB will get updated but this Alter statement is not replicated to the secondary.  
Sign in to post a comment.
Posted by Johnshaw511 on 8/30/2017 at 1:26 PM
This is still the case in SQL Server 2016.
Posted by David Samson on 8/29/2014 at 12:38 PM
This is still an issue with SQL Server 2014. Instead of failing over, I removed the database from the availability group, dropped it from the secondary, then added it again, making sure to connect to the secondary as the account I want to own the database.
Posted by mikea730 on 8/11/2014 at 1:14 PM
Same issue. Really a pain to do a failover just to set the owner.
Posted by mikegoodtampa on 11/9/2012 at 12:02 PM
We have multi-node cluster, and never intended to failover AGs to all of the nodes. But I do not see any way to fix DB ownership and chaining config issues on secondary replicas without first failing the AG to them. Still trying to figure out a way to resolve this....

What seems like best solution to me is for MS to change things so that these statements are mirrored from primary to secondary AG replicas (like most other DB configuration commands already do):


That, or change things so we can run these successfully on the secondary replicas.

If this proves too hard to implement, then alternatively build this into the initial "add DB to AG" process, so that DBs on secondary replicas are owned by same owner, and have same chaining settings as they do on the primary. That will do nothing to help me with my existing production AGs, but should help prevent this going forward.
Posted by SQLServerRockstar on 2/7/2012 at 10:40 AM
I Had the same issue

after migtating the database , i realised the db owner was my windows id and i chnaged it on the primary side, expecting it to do the same on Secondary side, it did not.

i had to failover the AG to change the db owner on the secondary side.