C
Calen Slezash
Guest
I have two SQL Server 2005 Standard servers - running on Server 2003
Standard x86.
After running to the Microsoft Update site last night, I selected the SQL
high-priority update KB948109 along with the other Server 2003-centric
updates. All updates were successful except for the SQL update. I then tried
downloading the KB file directly from Download Centre and ran it from the C:
drive. Again, the update failed.
After rebooting both servers, SQL services would not start. Here is what was
done by the onsite DBA to fix the problems:
It seems that one of the patches applied to the SQL Servers (KB948109)
attempted to access the MSSQLSYSTEMRESOURCE database. This database holds
all of the objects in SQL Server and is a new "database" for SQL Server
2005. The items that are in this database were previously held in the
MASTER database but this is no longer the case. I say this is a "database"
because it's a hidden database that's not managed in the normal way (can't
access it through Management Studio, can't back it up using maintenance
plans, etc.).
The issue appears to be the fact that we have put the data and log files for
all of our databases in the non-default location of C:\Programs Files\etc...
Of course this is a Microsoft recommended practice to distribute the data
and log files and something we've been doing since SQL Server 7. We saw
this issue first with the application of SQL Server 2005 Service Pack 2 when
we were building the server. This appears to be a known issue and is in my
opinion a huge bug in the application of patches and service packs. This
was not an issue with SQL Server 7 or SQL Server 2000 but of course SQL 2005
is a different beast.
Specifically what appeared to happen is the patch affected the log file of
that database causing it to be a different version than the data file (the
log file showed a modified date of December 2007 which should be
impossible - we installed SQL Server in late May). This means that the .MDF
file in D:\SQLData was modified differently than the .LDF file in
E:\SQLLogs. I found that you cannot restore this database in the normal
way - you have to restore these files from a file-based backup. We don't
currently have this (but that will change immediately). However, I found a
..LDF file sitting in the same directory as the .MDF file with the same
modified dates. So, I renamed the "broken" .LDF file and copied the file
from the D: drive to the E: drive and voila, the problem is fixed. Didn't
have to restore any files so there should not be any issue of losing any
objects in SQL Server.
I still can't fathom how this update was deemed "ready for public
consumption".
Good luck.
Standard x86.
After running to the Microsoft Update site last night, I selected the SQL
high-priority update KB948109 along with the other Server 2003-centric
updates. All updates were successful except for the SQL update. I then tried
downloading the KB file directly from Download Centre and ran it from the C:
drive. Again, the update failed.
After rebooting both servers, SQL services would not start. Here is what was
done by the onsite DBA to fix the problems:
It seems that one of the patches applied to the SQL Servers (KB948109)
attempted to access the MSSQLSYSTEMRESOURCE database. This database holds
all of the objects in SQL Server and is a new "database" for SQL Server
2005. The items that are in this database were previously held in the
MASTER database but this is no longer the case. I say this is a "database"
because it's a hidden database that's not managed in the normal way (can't
access it through Management Studio, can't back it up using maintenance
plans, etc.).
The issue appears to be the fact that we have put the data and log files for
all of our databases in the non-default location of C:\Programs Files\etc...
Of course this is a Microsoft recommended practice to distribute the data
and log files and something we've been doing since SQL Server 7. We saw
this issue first with the application of SQL Server 2005 Service Pack 2 when
we were building the server. This appears to be a known issue and is in my
opinion a huge bug in the application of patches and service packs. This
was not an issue with SQL Server 7 or SQL Server 2000 but of course SQL 2005
is a different beast.
Specifically what appeared to happen is the patch affected the log file of
that database causing it to be a different version than the data file (the
log file showed a modified date of December 2007 which should be
impossible - we installed SQL Server in late May). This means that the .MDF
file in D:\SQLData was modified differently than the .LDF file in
E:\SQLLogs. I found that you cannot restore this database in the normal
way - you have to restore these files from a file-based backup. We don't
currently have this (but that will change immediately). However, I found a
..LDF file sitting in the same directory as the .MDF file with the same
modified dates. So, I renamed the "broken" .LDF file and copied the file
from the D: drive to the E: drive and voila, the problem is fixed. Didn't
have to restore any files so there should not be any issue of losing any
objects in SQL Server.
I still can't fathom how this update was deemed "ready for public
consumption".
Good luck.