T-SQL Tuesday #19 – Disasters & Recovery

Comments: 1 Comment
Published on: June 14, 2011

When I first read this article, I thought to myself “I have no clue on this one.  What could I write that would be unique or interesting?”

My Disasters

Have you heard that old axiom that bad things come in sets of three?  For me, I have three such tales and two of them have a correlation to SQL Server (at least in some degree).

Disaster the First – You Can see it Coming

This one is a slow, ongoing process.  We are in a state of watch and wait.  But it at least gives us a chance to prepare and thus be prepared.  We live in an area where a flood plain exists but once every 20-25 years.  It just so happens that this is one of those years.  Our neighborhood is preparing by digging ditches, building dykes and sandbagging the most likely flow areas.  We see it coming and we are making plans.

Disaster the Second – Efforts Didn’t Go According to Plan

Last Friday I was applying a software patch.  As you would have guessed, the patch did not go according to plan.  The patch actually corrupted windows files and caused windows to fail reboots.  I tried to repair the corrupted files (default action with Win7).  I also tried to restore to a previous checkpoint.  Last effort was to re-install Windows.  You know that means I had to re-install all of my apps as well.  Any settings in the apps (such as SSMS) would be lost.

In this case, I should have imaged my machine immediately prior to installing the patch.  In this case, I wanted to retrieve all of my SSMS registered servers.  In order to do that (even though I did not export the registered servers) I needed to locate the prior RegSvr.XML from the backup that the Windows Installation makes of an existing windows install.  In some cases this prior install will be relocated to windows.Old.  Search in that directory for the RegSvr.XML file and copy it to %username%\AppData\Roaming\Microsoft\Microsoft SQL Server\100\Tools\Shell.  This will RECOVER the registered servers in SSMS that you had there prior to the reinstall.  Of course you would first need to reinstall SQL Server Tools prior to attempting this.

Disaster the Third – UnPlanned

After successfully recovering from that minor disaster, I encountered a new disaster only after two days of laptop use.  Upon arriving on-site yesterday morning (and mind you the laptop worked at the hotel) in Chicago (which is out of state for me), my laptop froze, rebooted and came back to “No Boot Disk.”  Well, I was completely unprepared for this midlevel disaster.  I didn’t have my reinstall discs with me.  I did not have my laptop backed up from the Friday disaster – I was still trying to get everything back to normal.  I had but one option – buy a new laptop and try to recover the hard drive later.

In trying to make sure it was not going to boot, I booted the system to a Boot CD (UBCD and a couple others) to be certain.  I was getting Int13h errors trying to find the drive.  I checked CMOS and CMOS did not see the drive.  I bought the new laptop and first tried to boot the new laptop from that HDD.  It too did not recognize it.  The drive was not even spinning up at that time.

Today, I have attached that drive to an external cage and connected via USB.  It’s alive!!  The data is still there but some clusters are corrupt.  That is fine so long as I get the data.  In this case, I don’t normally take daily backups of my laptop drives.  In the future, I will be taking more frequent backups of the laptop drives.  And now I have a backup laptop for cases just like this.

And once this last disaster is recovered, I will be copying settings from apps on that laptop to the new laptop – might save a little time.

T-SQL Tuesday #13 – Business Requirements

Comments: 1 Comment
Published on: December 13, 2010

Business Requirements

We have made it yet another month and to yet another episode in the continuing saga known as TSQL Tuesday.  This month we are being hosted by Steve Jones ( Blog | @Wayoutwest ) of SqlServerCentral fame.  Steve has asked us to speak a little bit about business requirements, interpreting those requirements, and some of the pitfalls that may or may not exist in the whole communication process of getting a project done.  Now, can somebody please explain the requirements for me?

What issues have you had in interacting with the business to get your job done?

I think a common area that is easily overlooked when it comes to requirements and interpretation of requirements is report creation.  A common problem is that there are no defined or written requirements for the creation of a report.  When there are inadequate requirements, it is easy to miss the intention of the report and thus frustrate the business group that requested the report.  Another problem that can arise is the perceived inaccuracy of a report – even when all business requirements are properly met and signed off by the requesting business group.  How can that be?  Let me explain.


A recent problem was brought to light that revolved around the creation of two similar reports.  The reports were to be used by different business groups and each was requested by a different group.  The values in the reports no longer match due to a change requested on ReportA by GroupA.  GroupB doesn’t think this is accurate and wants both reports to match.  Small problem is that both reports should not produce the exact same results based on requirements and usage.  The report for GroupA has some extra requirements and filters placed on it to prevent the users from seeing data about former employees.  The report for GroupB is different in that it should show an overall summary for all data, even data of former employees.


Managing business requirements is almost as much about managing the perceptions of the business users as it is understanding what the business truly wants.  It is important that you are able to help them understand what it is you will be doing, what you can accomplish, when you can do it, and what impact it may have on other business parts (if they are known).  When an issue arises, it is best to approach the business and try to understand what the disconnect is.  In the case of the example of two reports outlined, I had to research and test both reports to get a better understanding of what the problem was.  Once I did that, then it was a matter of explaining the findings to the business.  From there, a discussion between business analyst and the two departments for which the reports serve needs to take place and an agreement made.


This is a rather short and straight-forward entry for this month for TSQL Tuesday.  This is a delicate subject and I am sure many people will have many more tales to tell.  I think it is most important to approach the business and try to help them understand what you understand from the requirements and get it hammered out before too much development has been done.

page 1 of 1

November 2018
« Jul    

Welcome , today is Thursday, November 15, 2018