If not, the other choice may be rebuilding the system databases. This should put you in the original environment before the backup. Replace the master database or all system database files (mdf/ldf) with the copies you made before the backup (from step 2). If all hell break loose and you couldn't get the server to start up. You could then restart SQL Server service, or set the user database online. If not, use the alter database statement to change the meta data. Verify if the physical name is pointing to the current user databases location. When connecting with SSMS, if user databases are stuck in recovery pending state, it is very likely due to the user databases physical path meta data in master database is mapping to different location. Once the service is started successfully, SSMS could be used to connect to the instance for verification. Stop the service and start the service in SSCM without any parameter. NAME = modellog, FILENAME = 'D:\MSSQLSERVER\DATA\modellog.ldf'Ĭhange other system databases if required. NAME = modeldev, FILENAME = 'D:\MSSQLSERVER\DATA\model.mdf' The meta data of physical path of system databases could then be modified in the master database. Trace flag T3608 may be utilized to start the service restricting SQL Server from starting other databases except master database. It is because SQL Server requires other system database like model database during the startup process and it is unable to find the system database files as the newly restored master database maps the files to different location. If the current system databases physical path differs from the physical file path when the backup was taken, SQL Server may fail to start up. 7) Bring up SSMS and connect to the SQL Server instance for verification.
0 kommentar(er)
