Comments on: Reattach Will Reset Database Chaining

By: John Sansom

John Sansom — Wed, 12 Aug 2009 20:28:32 +0000

Ah yes I have seen this cheeky little issue before too when working with log shipping. This was when I was working on a project to offload reporting from a production server.

When setting up the secondary server (in standby mode) I restored the database from a backup of the primary and in doing so noticed that the CLR capabilities could not be accessed. This was because the TRUSTWORTHY database property was being reset to the default of false on the secondary database in spite of the property being set to true on the primary.

Of course the only way to change the property on the secondary was by bringing the database online which in turn breaks the log shipping configuration. In time a more robust Replication solution was devised and proved to be more suitable in this particular scenario but still, this is a sneaky little issue.

By: Buck Woody

Buck Woody — Wed, 12 Aug 2009 20:28:17 +0000

Thomas – I’m sure there would be a way to do that. The only issue, I think, would be not just the DBID, but then all of the security account GUIDS as well. And you couldn’t really key off of the database name to re-establish the chains and so on, because you can re-name the database in-flight. So if you don’t have the ID to match up against, and you can’t rely on the database names to re-tie everything, I’m not sure what other attribute to use to keep those options handy.

I think the point is that it is something to keep in mind when moving or restoring a database. My suspicion is that there are possibly other security related issues to keep in mind as well, such as orphanded users, certificates, aliases and so on.

Thanks -

Buck

By: Pankaj

Pankaj — Wed, 12 Aug 2009 19:56:08 +0000

Thank You Tom for putting this info as a blog and giving us more insight to it.

By: Thomas LaRock

Thomas LaRock — Wed, 12 Aug 2009 19:20:45 +0000

to be fair, i did a backup, dropped the database, then did a restore and found it reset. so, as buck mentions, it could be a result of the new db id.

i just did another test. i enabled the options, did a dump, disabled the options, did a restore, and found the options disabled.

i then enabled the options and did a restore to the dump i had just taken, and the options were still enabled.

i did not drop the database, so it would appear that whatever the options are set to for that db id, the options will persist for a same-server restore. i would expect that if you were recovering in the event of a disaster the options would persist for you as well. but if you are restoring to a different server then you would probably need to remember to have these enabled.

all the more reason to be capturing the info in the sysdatabases tables every night, i guess.

By: Jack Corbett

Jack Corbett — Wed, 12 Aug 2009 18:37:15 +0000

I’m not sure that the detach/reattach issue surprises me, but the fact that it gets reset on a restore. For me the whole point of a restore is so my application(s) will work the same after a disaster.

By: Thomas LaRock

Thomas LaRock — Wed, 12 Aug 2009 18:23:54 +0000

oh sure…that’s what you expect. but i expect that if i restore my database that had chaining on originally, that it would remain on after a reattach or restore.

would it not be possible for the attach/restore operation to (1) recognize the option is set and then (2) update the system tables for the new db id?

By: Buck Woody

Buck Woody — Wed, 12 Aug 2009 16:41:15 +0000

I would think this has to do with the database ID. I’m sure you don’t get the same ID when you restore/attach/adopt/add in/create a “new” database. Seems to me that ID would be used in system tables for chaining and so on. so to me this makes sense, and is the behavior I would expect.