The best way one can learn SQL Server is by trying out things on their own and I am no different. I constantly am trying to explore the various options one can use when working with SQL Server. In the same context, when I was playing around with backup restore commands, I made a mistake and unfortunately restarted SQL Server. After that I was unable to start SQL Service. If I start the service, it doesn’t give any error but gets stop automatically.

Whenever I have any weird problems with SQL, I always look at ERRORLOG files for that instance. If you don’t know the location of Errorlog, you should refer Balmukund’s blog (Help : Where is SQL Server ErrorLog?)

I’ve been very active in the SQL Server community in one way or another. A lot of people ask me why I do what I do. It all started in late 1999 when, fresh out of college with no one wanting to hire me, a potential customer asked me to write an inventory application for their small business. This might sound really exciting for somebody who would consider this their very first consulting opportunity immediately out of college. This plus considering the fact that my potential customer was willing to pay me any price I would charge them for it. But not for me. You see, I didn’t have…

As a DBA, it is perfectly normal to forget your password from time to time. No need to hold your breath or panic. In case of emergency that you need to recall your password or the ‘sa’ password, no need to panic because you can do it via the backdoor any way. These steps should get you going and move on with your administration tasks.

From the SQL Server configuration manager, stop the SQL services.

Open a cmd window as an administrator or elevated rights

From the command prompt, you need to locate the folder path of where your SQL Server binary files are located. Go to that path and type; sqlservr.exe –m.

Once the SQL server service succesfully starts with single user, open another cmd window as administrator or account with elevated rights

Type in command prompt; sqlcmd –S <servername> or (local) if your SQL Server is in the same machine.

Then you can reset the ‘sa’ password and also enable or unlock it at the same time.

There you have it. You have successfully taken control of the ‘sa’ account. From this point, close all the previous command windows and go back to SQL Configuration Manager. Start the SQL Server services. Try to connect to your SQL Server and start to use ‘sa’ account. :)

Problem : Surely you have scheduled jobs to run DBCC CHECKDB across your SQL Servers to check database integrity. But sometimes you miss checking reports on these scheduled jobs if they did run or completed but failed. So how do you monitor when was the last run of DBCC CHECKDB in your database?

Solution : There are many ways to do this. Also there is a very good in depth post from Paul Randal about DBCC CHECKDB which was a great help for me.

Generally, to check the last run of DBCC CHECKDB you can always use the command

DBCC DBINFO (yourdatabasenamehere) WITH TABLERESULTS

and look for the dbi_dbccLastKnownGood field which contains the date time stamp of the DBCC activity. But this is good only if the DBCC actually ran against the database and not on the snapshot of the database. For cases in which mirrored databases are involved you would usually run DBCC CHECKDB against a snapshot of the mirrored database.

To check the last DBCC CHECKDB run against these mirrored database, you may use a query i use frequently across all the SQL Server I monitor.

In the above method that I use, i check the SQL Server Logs for any run of DBCC CHECKDB activity. This way I get the correct date whether the DBCC actually ran on the database or a snapshot of the database as long as the DBCC CHECKDB command was actually invoked.

Next Step : You can add this query as part of your daily health check monitoring reports.