As my employer (Red Gate) puts it. The blog is shutting down for a few days as my family and I enjoy a few days I Steamboat Springs before Christmas. As of Saturday night, we should be in the Western side of Colorado, skiing until Thursday. We’ll return for Christmas at home, but likely I won’t be back at work until Monday the 27th.
Happy Holidays to everyone.
This is an editorial reprinted from April 27, 2005.
It’s viral marketing, but it’s not bad. Livevault produced a short video starring John Cleese as the director for this institute that seeks to counsel those that have had problems with tape backups. “Such an unreliable medium”, this one is straight out there. An advertisement for Livevault, a little silly, satirical, but not that bad.
It’s an interesting concept and one that I’ve debated with various colleagues over the years. Tape v disk. Which one is better for securing and ensuring the integrity of your data, which one is better for business continuity, which one works for your budget.
When I started in this business, it was a no brainer. Disk was way more expensive than tape and there wasn’t even a choice. Nowhere I worked could afford to backup their data to disk. On top of that, the technology for managing disk backups wasn’t great. I remember working for a small company and we couldn’t afford a VCS system. At least, I couldn’t pry money out of my boss for one, despite the fact that the business lived and died based on the code that was written. So we setup 5 folders on the network: Monday, Tuesday, Wednesday, Thursday, and you guessed it, Friday. Under each one, the other developer and I each had our own folder and a batch job that would copy data off our desktops to the appropriate folder on the appropriate day. We erased everything older than 5 days, though we still had tapes if we needed them.
Today, with disk being nearly as cheap and much, much faster than tape, and the need to go back more than one version in a business environment being fairly rare, it makes some sense to use disk. Microsoft released their own software, that helps with data recovery on disk, so there must be either some growth or a very high profit margin in this area 🙂
Personally, I think that the idea is a good one, but like many new technologies that change the way a user works, this one will take some time to get used to. I’m all for users being able to recover their own data without calling an admin, especially when the admin is me, but I’m sure that there will be lots of calls on how to find the files, which version, I forgot to save it, but my machine crashed and I want to go back 3 versions, annoyed calls when the last version on disk rolls off, etc.
But I wouldn’t give up my tape. At J.D. Edwards, we backed up the databases to disk, then to tape that night, with two copies of the tapes being made. One went offsite and one was in a rotation on site. The triple protection served me well and we never had issues getting data off disk or one of the two tapes.
Of course, that was expensive, so it’d not an option I’ve had often. Still, one disk and one tape worked out well and these days having disk be so cheap, a second copy on disk is something I’d shoot for.
Steve Jones
you can help me for the visule studio 2005 programe I have assigment
I do not how to use for these program
you can help me plase
That’s literally the text of an email that came to me at SQLServerCentral. Apart from the language barriers and issues, it is the type of frustrating email that I don’t really like to see on a Friday afternoon. It’s a waste of my time to read it, even if I delete it.
After my call for “What the Business Says Is Not What the Business Wants”, there were quite a few people that responded. Including my blog post, I found 43 comments posted on with links back to the thoughts.
Here’s a quick summary, along with a short comment on each.
Matt Whitfield wrote on issues with letting the customer decide how, in addition to what, a project should be built. Wise words, and often a place where trouble ensues when technical people take things literally. A great cartoon to start out the topic is in this post as well.
Rob Farley talks collation issues. In this case, the collation issues are misunderstandings due to the different way we express ourselves in our particular industry or career. It’s a common problem, and it shows why the technical people need to make very, very sure they understand what the business person said, not what they meant.
Mark Broadbent stresses that we need to provide alternative solutions when what is proposed won’t work, and talk in terms of value, something the “business” should understand.
Roger Noble wants to take off the white coat and tells us to remember that communication is the key. On both sides.
Aaron Bertrand has seen issues with outsourcing and requirements. This technique works well in some cases, but not others, and with development projects, it can be problematic.
Reporting is the area where Jason Brimhall has found confusion in different departments wanting separate reports, but then somehow having them match for comparison purposes.
Performance is always an issue, and Alexander Kuznetsov talks about the need to actually define carefully what types of performance, and what the metrics we use, will mean.
I have horses, well, my wife has horses. I love my wife, so there are horses at the ranch. Noel McKinney asks what to do with the business wants a pony? Not literally a pony, but worth the ready anyway to understand what he means.
Shrinking Databases is the scenario that Pinal Dave uses for his post. He describes a scenario where the business requested that the smallest file be used for DR, but a lack of understanding of how backups worked resulted in a regular shrink job.
Nicholas Cain talks about this mysterious business, and has a few examples of the problems that can be caused when too much design input comes from non-technical people.
Chris Shaw channels the Soup Nazi in a quick note about a former manager who wants the database locked down, to everyone but him.
Jen McCown starts with a classic joke and gives a few examples of where the business has caused issues with technical systems.
John Sansom, DBA from across the pond, has some advice for DBAs on how to better develop understanding with your business people as well as understand politics a little better yourself.
Bradley Ball tells a story of how he has had to build trust with the business. A story similar to one I’ve had, and worth the read to remind you how to deal with mistakes.
Joshua Feierman wonders how we can better build good software the meets the business’ needs, budget, and timelines. I can sympathize here, but also understand that the business wants things done, and not necessarily in the best way possible.
Bob Pusateri describes the problems that come when the business has a little knowledge and tries to work too closely with technical people.
Matt Velic reminds us to listen to the business and ask questions to be sure that the communication is understood by both sides. A good reminder that ultimately this is a job and you shouldn’t get too upset.
Jeremiah Peschka tells us to listen in a not-so-subtle way. Listening, and understanding, what users say to you is important. We shouldn’t design the software we want, we should design the software users want. Not as easy as it sounds.
Gethyn Ellis, one of SQLServerCentral regular bloggers, runs into the classic Full-Recovery-Mode-with-No-Transaction-Log-Backups.
Mike Walsh tells us we need to listen. And tells us again. And again. Get the hint? We (IT people) don’t listen well.
Erin Stellato uses quotes to remind us that teamwork and relationships are important.
Kendra Little talks features. What people want, but what they then forget or don’t consider. This is a nice post to send to your business people, or perhaps paraphrase to try and help them understand your point of view.
My good friend, Andy Leonard, talks ego, as a part of his series on interactions with business people. Check your ego. Good advice.
Audrey Hammons has a top 5 list. These are the top five things the business has asked for. It’s a funny list.
The very talented Wendy Pastrick from Chicago found some nice blog fodder with this month’s topic. Is your business like the blind men describing the elephant? If so, you might like Wendy’s post.
Jason Bacani uses some great images to show why the business has trouble with us. They want everything yesterday and we want our procedures to get in the way.
Richard Handloff tells us how to ask questions to get better information from the business.
Meredith Ryan-Smith gives us a method that has worked well for groups in her cmpany.
Cade Roux tells us that IT needs to be a strong partner with the rest of the business.
John Welch has to convince the business of the value of data quality. I’ve fought this battle before as well and it’s a tough one.
Amit Benjeree writes his second T-SQL post and talks about the classic things you need: requirements and priorities.
Allen Kinsel tells us to plan on changing. It’s a lesson I learned early, and not only do I plan for change, I design with the idea that my design will need to change for future requirements.
Jes Borland learned about the business and learned just how valuable that knowledge can be.
SQL Soldier, Robert Davis, warns us of the dangers when the DBA does not push back on business demands.
Brian Kelley, longtime SQLServerCentral author and security expert, reminds us that technical people and business people start from different places. Neither knows what the other knows, and that can be a source of problems.
Thomas Rushton left a job when the business didn’t appreciate the value of people. I’m sure he’s glad he’s not at that job anymore.
Ryan Adams says that we need to be the interpreters. DBAs have to translate what is said into what is needed. Now if we just had a decent piece of software to help us, this would be easy. Ryan has a good example of a situation where things can get confused without someone acting as interpreter.
Oscar Zamora talks about the importance of a strong business analyst in the software development process.
Stacia Misner rounds out this months’ party with “a picture worth a thousand words” and gives us some insight into how she designs systems and works through projects. Rather than go left to right, she goes right to left. Read her post to understand more.
This was a neat experience, but a lot of work. I’ll admit that I don’t always read that many T-SQL Tuesday posts. I tend to read 5-10 tops, and going through 40 and summarizing was hard.
However I’m glad I did it, and I bet you will too. Contact Adam to host a month in 2011 and pick your topic.
