July 27, 2017 at 1:03 pm
We have a production database running in snapshot isolation level.
The application have a functionality where the user can selected a few records and command it to be processed.
A lot is done while the process run (executes SP, create temp tables,run CURSORS (sic) etc).
All those things takes several minutes to run.
This morning a users selected a big chunk of records and got this message:
Snapshot isolation transaction failed in database 'Master' because the object accessed by the statement has been modified by a DDL statement in another concurrent transaction since the start of this transaction. It is disallowed because the metadata is not versioned. A concurrent update to metadata can lead to inconsistency if mixed with snapshot isolation
After a few minutes the user tried again , this time with small chunks of records and was able to workaround the problem.
Maybe it's a performance problem but I was puzzled by the **Master* DB being the place where the problem ocurred.
I can expect it to happen in the production DB or even in the TempDB.
My Question is? What is the role of the Master DB in this problem? Can it be just a misleading error message anyway?
August 1, 2017 at 2:25 pm
Fortunately we have trace running in production.
Analysing the data I found an 'ALTER LOGIN' being doing in the 'MASTER' system db.
But it still strange because those commands are from a *DIFFERENT APP* using a different connection, technology, etc.
Basicaly costumer got an "COA - Client Online App" and support have an "ALA - Adm Local App".
Locks like support changed the password of a user in the ALA and caused the COA to raise a error in a DB intensive operation.
It's still strange because even the users/costumers in both instances are different and don't share any data.
I was naively expecting two unrelated transactions from two unrelated connections to not crash one another.😛
Viewing 2 posts - 1 through 1 (of 1 total)
You must be logged in to reply to this topic. Login to reply