--- title: Corruption detected when attaching/restoring master database description: Don’t be alarmed if ‘corruption’ is found when attaching or restoring master database as a user database. This blog post takes you through the problem. image: https://blog.coeo.com/hubfs/Master2.png --- [![](https://www.coeo.com/wp-content/themes/coeo/images/logo.svg)](https://blog.coeo.com/) +44 (0)20 3051 3595 | [info@coeo.com](mailto:info@coeo.com) | [Client portal login](https://my.coeo.com) # Corruption detected when attaching/restoring master database # The Coeo Blog ![Ryan Allport](https://blog.coeo.com/hubfs/Profile%20photos/RyanCircle.jpg) Recently, while working with a customer to help restore their SQL services, I came across an issue I hadn’t seen before and more interestingly, one where little information can be found within the community. This can be replicated by yourself by attaching or restoring a copy of the master database as a user database. You may never need to do this but just in case you do, don’t be alarmed if ‘corruption’ is found within the user database once it’s attached. The problem was that the customer didn’t have access to their backups. So, my task was to attach all the databases to a recovery instance and execute a DBCC CHECKDB against them. All the user databases were fine and most of the system databases (restored as user databases too) were also fine. All except for the master database. Or so I thought… I attached the master database as a user database by executing the below TSQL: USE \[master\] GO CREATE DATABASE master2 ON  ( FILENAME = N'E:\\SystemDbs\\master.mdf' ),  ( FILENAME = N'E:\\SystemDbs\\mastlog.ldf' )  FOR ATTACH GO   To replicate the problem for this blog I’ll be backing up and restoring the same master database that I have on my own development instances’.   First, backup the master database:    BACKUP DATABASE MASTER TO DISK = N'C:\\BACKUPS\\MASTER.BAK'  WITH INIT, CHECKSUM   When executing a DBCC CHECKDB at this point, you’ll notice this completes successfully:   ![DBCC CHECKDB - Success.png](https://blog.coeo.com/hubfs/DBCC%20CHECKDB%20-%20Success.png)Moving onto performing the restore. To restore the master database as a user database, you’ll need to use RESTORE FILELISTONLY to determine to file locations. This is handy as the ‘WITH MOVE’ clause will be required when restoring the database files to a different location:    RESTORE DATABASE MASTER2 FROM DISK = N'C:\\BACKUPS\\MASTER.BAK'   WITH   MOVE 'master' TO 'C:\\Program Files\\Microsoft SQL Server\\INSTANCELOCATION\\MSSQL\\DATA\\master2.mdf',   MOVE 'mastlog' TO 'C:\\Program Files\\Microsoft SQL Server\\INSTANCELOCATION\\MSSQL\\DATA\\mastlog2.ldf'   Refreshing the databases node, you should now see the new ‘MASTER2’ database: ![Master2.png](https://blog.coeo.com/hubfs/Master2.png)   Now the database has been restored we can execute the DBCC CHECKDB against it. Below you can see a snippet of the errors that are output:   Msg 8992, Level 16, State 1, Line 1 Check Catalog Msg 3851, State 1: An invalid row (class=12,depid=0,depsubid=0) was found in the system table sys.syssingleobjrefs (class=12). Msg 8992, Level 16, State 1, Line 1 Check Catalog Msg 3851, State 1: An invalid row (class=13,depid=1,depsubid=0) was found in the system table sys.syssingleobjrefs (class=13). Msg 8992, Level 16, State 1, Line 1   Don’t be alarmed by this, the newly restored MASTER2 user database isn’t corrupt at all; it’s a symptom of the database being restored as a user database. If we backup the new MASTER2 database and this time restore it over the top of our existing master (system) database, you’ll find the corruption is no longer reported.   The master database has special structures at the start that no user (or other system) database has. When DBCC CHECKDB is executed against the master (system) database DBCC CHECKDB considers this special structure and ignores the ‘corruption’. As you can see, if the master database is restored as a user database CHECKDB doesn’t know its past life and treats it like any other user database reporting corruption.   Once the master database has been restored executing DBCC CHECKDB against the newly restored master system database will show the database is corruption free. ![DBCC CHECKDB - Success2.png](https://blog.coeo.com/hubfs/DBCC%20CHECKDB%20-%20Success2.png)     *If you'd like to know more about our dedicated support service and how we can help you manage your SQL Server environment click the link below:*   *[![New call-to-action](https://no-cache.hubspot.com/cta/default/3356718/fc34b96a-aa04-4a87-a152-5ef947afec19.png)](https://cta-redirect.hubspot.com/cta/redirect/3356718/fc34b96a-aa04-4a87-a152-5ef947afec19)* ### Subscribe to Email Updates ## Related posts --- ### [Troubleshooting Ola Hallengren’s Maintenance Solution](https://blog.coeo.com/troubleshooting-ola-hallengrens-maintenance-solution) ### [Domain-Independent Windows Failover Cluster for SQL Server AlwaysOn Availability Group](https://blog.coeo.com/domain-independent-windows-failover-cluster-for-sql-server-alwayson-availability-group) ### [We're in Reading for Data Relay 2022](https://blog.coeo.com/coeo-are-attending-data-relay-2022) ### [SQLBits 2022 session - Field Testing Ola Hallengren’s Maintenance Solution](https://blog.coeo.com/sqlbits-2022-session-field-testing-ola-hallengrens-maintenance-solution) ![](https://www.coeo.com/wp-content/uploads/2016/12/logo-invert.png) +44 (0)20 3051 3595 | info@coeo.com ## Contact Us By clicking submit below, you consent to allow Coeo to store and process the personal information submitted above to provide you the content requested. You may unsubscribe from these communications at any time. For more information on how to unsubscribe and our commitment to your privacy, please review our **[Privacy Policy](https://www.coeo.com/privacy/)**. ## Upcoming Events [See all events](https://www.coeo.com/events/) #### NOW Building, Thames Valley Park Drive, Reading, RG6 1RB [![](https://www.coeo.com/wp-content/themes/coeo/images/social-glass.png)](https://www.glassdoor.co.uk/Overview/Working-at-Coeo-EI_IE959052.11,15.htm)[![](https://www.coeo.com/wp-content/themes/coeo/images/social-in.png)](https://www.linkedin.com/company/coeo-ltd)[![](https://www.coeo.com/wp-content/themes/coeo/images/social-twitter.png)](https://twitter.com/CoeoLtd)[![](https://www.coeo.com/wp-content/themes/coeo/images/social-fb.png)](https://www.facebook.com/coeoltd/) ![](https://www.coeo.com/wp-content/themes/coeo/images//menu-icon.png) ![](https://www.coeo.com/wp-content/themes/coeo/images//menu-close.png) ![](https://www.coeo.com/wp-content/uploads/2016/12/logo-invert.png) +44 (0)20 3051 3595 | [info@coeo.com](mailto:info@coeo.com) - [Solutions](https://www.coeo.com/solutions/) - [Next Steps](https://www.coeo.com/next-steps/) - [Dedicated Support](https://www.coeo.com/dedicated-support/) - [Case studies](https://www.coeo.com/case-studies/) - [Technologies](https://www.coeo.com/solutions/technologies/) - [Industries](https://www.coeo.com/industries/) - [Finance](https://www.coeo.com/industries/finance/) - [Retail](https://www.coeo.com/industries/retail/) - [Technology](https://www.coeo.com/industries/technology/) - [The Team](https://www.coeo.com/people/) - [Join Us](https://www.coeo.com/careers/) - [Graduate Programme](https://www.coeo.com/graduate-programme/) - [About Coeo](https://www.coeo.com/about-coeo/) - [The Coeo Blog](https://www.coeo.com/blog/) - [Contact us](https://www.coeo.com/contact-us/) - [Privacy Notice](https://www.coeo.com/privacy/) - [Cookie Policy](https://www.coeo.com/privacy#Cookie_Policy) - [Events](https://www.coeo.com/events) Sign up to our newsletter ![go arrow](https://www.coeo.com/wp-content/themes/coeo/images/newsletter-go.png) Back to top