Restoring a corrupted master database is one of the most difficult tasks you may have to deal with. If this catastrophic event happens, here's how to proceed.
First, you need to rebuild the master database. Details on this operation depend on the SQL Server version you run. With SQL Server 6.5 the only way is to re-install the program, whereas SQL Server 7.0 provides an utility called Rebuildm.exe, in the \Mssql7\Binn directory.
Set SQL Server on single-user-mode, by starting it with the -m switch. Next, restore the master database from the latest avaible backup. At the end of the restore procedure, after verifying that all databases are working correctly, you can proceed restoring the MSDB database. When this step completes, stop SQL Server and start it again in normal mode. After the restart remember to check that all the user databases are working properly. If they aren't, the action to undertake depends on the SQL Server version.
With SQL Server 6.5, perform a DISK REINIT, which restores the data about the system tables usage in case of an existent device but missing data in the sysusages table.
DISK REINIT
NAME = 'logical name'
PHYSNAME = 'physical name'
VDEVNO = virtual device number
SIZE = number of 2K blocks
[, VSTART = 'virtual address']
SQL Server 7.0 doesn't support DISK REINIT any longer, but the same operation is available through the sp_attach_db system stored procedure, which connect a database to a server:
sp_attach_db [@dbname =] 'database name', [@Filename1 =] 'File 1 name' [, ... 16].
If this sequence of operations can't solve the problem, you'll need to rebuild each device and database and then perform the individual restores. The importance of regular backups, and in particular the master database master, can't be overemphasized enough, as it can assure the server stability and a quick restart in case of problems.
Wednesday, August 10, 2005
IE 7.0 Technical Changes Leave Web Developers, Users in the Lurch
In a recent blog posting , Microsoft Internet Explorer (IE) Lead Program Manager Chris Wilson revealed many of the technical improvements that Microsoft will add to IE 7.0 for its final release. Almost all the improvements are related to bugs in IE's implementation of Cascading Style Sheets (CSS), an HTML-like technology that Web developers use to create Web sites. Many of these bugs aren't fixed in the currently available IE 7.0 Beta 1 release, Wilson noted. Wilson's post raises some serious questions about IE 7.0, not the least of which is this: If IE 7.0 Beta 1 doesn't include the fixes that most Web developers need, why did Microsoft release IE 7.0 Beta 1 only to a small group of Web developers and other testers, not to the general public as originally promised?
Wilson's post is disappointing because Microsoft doesn't plan to fully support the latest CSS standard in IE 7.0. Instead of using well-established Web standards, IE 7.0 will continue to foist proprietary technologies on Web developers, forcing them to choose between two competing ways of creating Web sites. "In IE 7.0, we will fix as many of the worst bugs that Web developers hit as we can, and we will add the critical most-requested features from the standards as well," Wilson said. "Our intent is to build a platform that fully complies with the appropriate Web standards, in particular CSS 2. I think we will make a lot of progress against that in IE 7.0 through our goal of removing the worst painful bugs that make our platform difficult to use for Web developers."
The most critical point in Wilson's post, in my mind, is Microsoft's admission that it will fail the crucial Acid2 browser-compliance test , which the Web Standards Project (WaSP) designed to help browser vendors ensure that their products properly support Web standards. Microsoft apparently disagrees. "Acid2 ... is pointedly not a compliance check," Wilson noted, contradicting the description on the Acid2 Web site. "As a wish list, [Acid2] is really important and useful to my team, but it isn't even intended, in my understanding, as our priority list for IE 7.0." Meanwhile, other browser teams have made significant efforts to comply with Acid2.
Microsoft blames backward-compatibility problems for the stalemate over true Web standards compatibility. Put succinctly, the company has gone its own way for so long and now has to support so many developers who use nonstandard Web technologies that it will be impossible to make IE Web-standards-compliant without breaking half the commercial Web sites on the planet. Furthermore, by halting all IE development for several years before reconstituting the IE team to create IE 7.0, Microsoft has set back Web development by an immeasurable amount of time.
Wilson's post is disappointing because Microsoft doesn't plan to fully support the latest CSS standard in IE 7.0. Instead of using well-established Web standards, IE 7.0 will continue to foist proprietary technologies on Web developers, forcing them to choose between two competing ways of creating Web sites. "In IE 7.0, we will fix as many of the worst bugs that Web developers hit as we can, and we will add the critical most-requested features from the standards as well," Wilson said. "Our intent is to build a platform that fully complies with the appropriate Web standards, in particular CSS 2. I think we will make a lot of progress against that in IE 7.0 through our goal of removing the worst painful bugs that make our platform difficult to use for Web developers."
The most critical point in Wilson's post, in my mind, is Microsoft's admission that it will fail the crucial Acid2 browser-compliance test , which the Web Standards Project (WaSP) designed to help browser vendors ensure that their products properly support Web standards. Microsoft apparently disagrees. "Acid2 ... is pointedly not a compliance check," Wilson noted, contradicting the description on the Acid2 Web site. "As a wish list, [Acid2] is really important and useful to my team, but it isn't even intended, in my understanding, as our priority list for IE 7.0." Meanwhile, other browser teams have made significant efforts to comply with Acid2.
Microsoft blames backward-compatibility problems for the stalemate over true Web standards compatibility. Put succinctly, the company has gone its own way for so long and now has to support so many developers who use nonstandard Web technologies that it will be impossible to make IE Web-standards-compliant without breaking half the commercial Web sites on the planet. Furthermore, by halting all IE development for several years before reconstituting the IE team to create IE 7.0, Microsoft has set back Web development by an immeasurable amount of time.
Subscribe to:
Posts (Atom)
Posts
