January 28, 2012 at 1:58 pm
Hi,
We have a test server with 3 SQL Server 2008 R2 instances installed on it.
1 instance is the default instance & 2 named instances are there. In addition, 1 of the named instance is Express Edition rest are enterprise.
Now, we were applying the SQL Server 2008 R2 Service Pack on this. We choose to apply the patch on all instances in one go. The installation was completed successfully (it didn't give us any error during installation ).
To our surprise, after the installation was complete, both named instances of SQL Server Serives were running fine but the default instance failed to start. We went through the error log file & got following messages there:
1. Error: 5173, Severity: 16, State: 1.
One or more files do not match the primary file of the database. If you are attempting to attach a database, retry the operation with the correct files. If this is an existing database, the file may be corrupted and should be restored from a backup.
2. Log file 'C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\Binn\mssqlsystemresource.ldf' does not match the primary file. It may be from a different database or the log may have been rebuilt previously.
The log cannot be rebuilt when the primary file is read-only.
3. Error: 945, Severity: 14, State: 2.
Database 'mssqlsystemresource' cannot be opened due to inaccessible files or insufficient memory or disk space. See the SQL Server errorlog for details.
When we checked at the path of the MSSQLSystemResource database files we found that the log file is of newer date ( Jun 2011) but the data file is still of old date (April 2010). We understood that the upgrade has not replaced the data file for MSSQLSystemResource database.
Therefore we replaced the data file also by copying the latest MSSQLSystemResource database's data file from the named instances, because they were running successfully. After this, we were able to start the default instance also & it worked fine after that.
So the problem has been resolved, however I would like to know if any body else has faced this issue. Is it a bug in SQL Server upgrade process? Is there any other better approach to resolve it or to avoid this issue?
Any help is appreciated 🙂
January 31, 2012 at 5:02 am
Divine Flame (1/28/2012)
Hi,We have a test server with 3 SQL Server 2008 R2 instances installed on it.
1 instance is the default instance & 2 named instances are there. In addition, 1 of the named instance is Express Edition rest are enterprise.
Now, we were applying the SQL Server 2008 R2 Service Pack on this. We choose to apply the patch on all instances in one go. The installation was completed successfully (it didn't give us any error during installation ).
To our surprise, after the installation was complete, both named instances of SQL Server Serives were running fine but the default instance failed to start. We went through the error log file & got following messages there:
1. Error: 5173, Severity: 16, State: 1.
One or more files do not match the primary file of the database. If you are attempting to attach a database, retry the operation with the correct files. If this is an existing database, the file may be corrupted and should be restored from a backup.
2. Log file 'C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\Binn\mssqlsystemresource.ldf' does not match the primary file. It may be from a different database or the log may have been rebuilt previously.
The log cannot be rebuilt when the primary file is read-only.
3. Error: 945, Severity: 14, State: 2.
Database 'mssqlsystemresource' cannot be opened due to inaccessible files or insufficient memory or disk space. See the SQL Server errorlog for details.
When we checked at the path of the MSSQLSystemResource database files we found that the log file is of newer date ( Jun 2011) but the data file is still of old date (April 2010). We understood that the upgrade has not replaced the data file for MSSQLSystemResource database.
Therefore we replaced the data file also by copying the latest MSSQLSystemResource database's data file from the named instances, because they were running successfully. After this, we were able to start the default instance also & it worked fine after that.
So the problem has been resolved, however I would like to know if any body else has faced this issue. Is it a bug in SQL Server upgrade process? Is there any other better approach to resolve it or to avoid this issue?
Any help is appreciated 🙂
You can installed SP with 3 or 30 instances, when you going to update with SP, it will ask you - which instances u want to update.
Before you start with update take a backup of copy MSSQLSystemResource database's LDF & MDF.
If you got a error, then restore data MSSQLSystemResource with mdf & ldf.
This way you going to resolves error message's.
Let me know
January 31, 2012 at 5:17 am
M.Kahn (1/31/2012)
You can installed SP with 3 or 30 instances, when you going to update with SP, it will ask you - which instances u want to update.
Before you start with update take a backup of copy MSSQLSystemResource database's LDF & MDF.
If you got a error, then restore data MSSQLSystemResource with mdf & ldf.
This way you going to resolves error message's.
Let me know
I think you didn't get the question. I am not asking whether we can OR can't install the service pack on many instances. We know that it can be done & SQL Server provides us the option to choose the instances that we want to upgrade.
Also, We had already resolved the error by replacing the MSSQLSystemResources files by copying it from other instance which was already updated to SP1.
Divine Flame
Therefore we replaced the data file also by copying the latest MSSQLSystemResource database's data file from the named instances, because they were running successfully. After this, we were able to start the default instance also & it worked fine after that.
So the problem has been resolved, however I would like to know if any body else has faced this issue. Is it a bug in SQL Server upgrade process? Is there any other better approach to resolve it or to avoid this issue?
SO , here it's not about the solution, its about have you also seen the same behavior when installing the service pack on many instances in a single installation? Is it common?
I think this makes it clear 😎
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply