 |
|
^ click above ^ |
07.03.03
 By Randy
Dyess
Every now and then we all have to reread something we may already know because
frankly if you are like me, you can't keep everything in your head. I tend to
go back over tips and tricks and even database concepts when I have time so I
will maybe remember enough about it so when a problem arises I at least know where
to go look and find the answer. It is with, that I want to write about my latest
re-education attempt.
A few years ago, I was working with a SQL Server database and something
went wrong. Yea I know, how weird nothing ever goes wrong with SQL Server or any
other product out there but in this case something did go wrong and corrupted
my master database. At least I can say that this particular problem was
not SQL Server or a bug in one of my procedures, it was actually a problem with
a disk controller. Go figure, according to my network and hardware folks, nothing
is ever wrong with the network or hardware. The problem is always internal to
the application. To make a short story short, a drive controller was going out
and corrupted the master database causing me to do what I hope was a once
in a lifetime job of restoring a master database. While this particular
article is not about rebuilding or restoring a master database, it is about
something that a lot of DBAs overlook, startup parameters.
SQL Server allows you to control a few of its configurable options during startup
with the use of startup parameters. These parameters are usually useful for troubleshooting
purposes - usually in case of extreme emergencies, but they can also be useful
for some long-term configuration changes as well. Before we go any further, I
want to add a little warning here - do not learn about startup parameters on any
SQL Server installation that you are not willing to completely rebuild. It is
possible to set a parameter and cause serious problems that may affect your installation,
like setting the location of the master database to a false one. |