Share via

The Mount-SPContentDatabase operation consistently fails

Titus Tolbert (Sr. Dev Operation, Hoka corp) 540 Reputation points
2026-02-05T04:27:45.09+00:00

We are in the process of upgrading our SharePoint 2016 content databases to a new SharePoint 2019 farm. The Mount-SPContentDatabase operation consistently fails for several large content databases (over 500GB) after running for approximately 3-4 hours. This failure occurs even after ensuring all prerequisites are met and running the Test-SPContentDatabase cmdlet successfully.

The upgrade process rolls back, preventing us from attaching these critical databases to the new SharePoint 2019 Web Applications. This is a critical blocker for our farm migration.

Error Log:

Reviewing the SQL Server error logs and running extended events during the Mount-SPContentDatabase operation reveals persistent deadlock events (Error 1205) on several SharePoint internal tables, specifically those related to content types, features, and security scopes.

SQL Server deadlock graph analysis points to contention between the Schema Upgrade process (executed by the SharePoint Timer Service account) and internal data migration/re-indexing operations on the same tables.

Category: Upgrade
EventID: 1046
Level: Unexpected
Message: "Database <DBName> on SQL Server <SQLServerName> is not accessible.
Additional error information from SQL Server is included below.
SQL Server Message: 'Transaction (Process ID 123) was deadlocked on lock resources { transaction lock } with another process and has been chosen as the deadlock victim. Rerun the transaction.'"

I have checked in the newest topic Feb 2: https://getsharepoint.com/common-sharepoint-mistakes-we-see-after-migration/
but nothing relevant
Any insight ?

Microsoft 365 and Office | SharePoint Server | Development
0 comments
Answer accepted by question author
  1. Matthew-P 11,235 Reputation points Microsoft External Staff Moderator
    2026-02-05T06:27:02.1733333+00:00

    Hi Titus Tolbert (Sr. Dev Operation, Hoka corp), 

    Welcome to Microsoft Q&A Forum!

    Have a good day and I hope you're doing well!

    Based on my research and experience with similar SharePoint 2016 to 2019 migrations involving large datasets (500GB+), the behavior you are seeing is, unfortunately, a common bottleneck caused by resource contention, but it is usually solvable without data loss. 

    The reason Test-SPContentDatabase passes is that it is a read-only operation checking for logical orphans and missing dependencies. However, Mount-SPContentDatabase performs heavy write operations upgrading the schema, transforming features, and re-indexing security scopes. 

    With a 500GB database, these parallel operations create massive contention on internal system tables. SQL Server detects this cycle and kills one process (the deadlock victim) to save the system, which triggers the SharePoint rollback. 

    Here are the steps I recommend to resolve this:

    1. Force Sequential Execution: Deadlocks often occur because multiple SharePoint servers are trying to access the DB, or the local Timer Service is spinning up too many parallel threads. 

    • Stop the "SharePoint Timer Service" on all servers in the SharePoint 2019 farm, except for the one server where you are running the PowerShell command. 
    • Stop Search Services (Search Host Controller, Search Query and Crawl) temporarily. 

    This isolates the upgrade process to a single node, significantly reducing lock contention. 

    2. Adjust SQL Server MAXDOP: In some upgrade scenarios, temporarily reducing SQL parallelism has been observed to reduce contention and allow schema upgrades to complete successfully. 

    • Check the Max Degree of Parallelism (MAXDOP) setting on your SQL Server instance. 
    • Temporarily set MAXDOP = 1 for the duration of the upgrade. 

    This forces SQL Server to use a single processor core for the query execution plan, effectively eliminating the possibility of parallel threads fighting for the same row locks. 
    Reference: Server configuration: max degree of parallelism 

    3. Retry the Operation: The SQL error advises to "Rerun the transaction," which is valid here. Since SharePoint upgrades are incremental, the first run likely completed some schema updates. A second attempt often succeeds simply because there is less work remaining to process. 

    While 500GB is supported, it is well above the recommended "soft limit" for ease of maintenance. If you still have access to the SP2016 environment, the cleanest path is to split the site collections into smaller Content Databases (<200GB) and attach them individually. This drastically reduces upgrade risk and future backup/restore times. 

    I hope this information provides you with some valuable insights. If I misunderstood the situation or if anything is unclear, or if you have any further questions or concerns, please feel free to reach out. 

    If the answer is helpful, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment".    

    Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.  

    1 person found this answer helpful.

1 additional answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. Q&A Assist
    2026-02-05T04:27:57.47+00:00
    AI generated content. This question contains an answer created with AI from Q&A Assist. Learn more

    The issue you are experiencing with the Mount-SPContentDatabase operation failing due to deadlocks during the upgrade process can be quite challenging. Here are some insights that may help you troubleshoot and resolve the problem:

    1. Check SQL Server Configuration: Ensure that your SQL Server is configured optimally for handling large databases. This includes checking memory allocation and ensuring that there are no resource constraints that could lead to deadlocks.
    2. Review Deadlock Events: Since you are encountering persistent deadlock events, analyze the deadlock graphs to identify the specific queries that are causing contention. This may provide insights into which operations are conflicting and help you adjust your approach.
    3. Staggered Upgrades: If possible, consider upgrading smaller content databases first before attempting to upgrade the larger ones. This can help isolate the issue and reduce the load on the SQL Server during the upgrade process.
    4. Increase Timeout Settings: You may want to increase the timeout settings for the Mount-SPContentDatabase cmdlet, allowing more time for the operation to complete before timing out.
    5. Run in Off-Peak Hours: If your SharePoint environment is under heavy load, try running the upgrade during off-peak hours to minimize contention with other operations.
    6. Verify Custom Features: Ensure that all custom features and solutions from the SharePoint 2016 environment are installed in the SharePoint 2019 environment before starting the upgrade. Missing custom elements can lead to failures during the upgrade process.
    7. Use Test-SPContentDatabase: Continue to use the Test-SPContentDatabase cmdlet to check for any missing customizations or issues before attempting the Mount-SPContentDatabase operation again.

    If the problem persists, you may want to consider reaching out to Microsoft support for further assistance, especially since this is a critical blocker for your migration process.

    References:

    0 comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.