Category: General

Working in a technical field has it’s ups and downs. One of the more common annoyances I run into is people that can either not explain what they mean in simple terms or that choose not to in order to appear knowledgeable. I still have a long way to go before I can suggest a sure-fire approach to curtailing this behavior. Quite honestly, I have been known to fall back on “fancy tech words” on more than one occasion to hide ignorance or to try to seem smart (OK that was hiding ignorance twice but it sounds better the way I said it). What I can offer is a great resource to understand what people are saying and maybe even have some fun with them/me.

The National Institute of Standards and Technology, NIST, maintains a Dictionary of Algorithms and Data Structures. The dictionary is a great place to go to find out what people are talking about. It is also a great place to looking for different ways of doing things. I sometimes even go to the site just to look for entertaining technical concepts, like the “Cactus Stack”, “Stooge Sort” or even “Big-O Notation”.

Have fun with the big words but please only use them for good or at least funny evil. Go ahead and post any you feel are interesting or just plain funny in the comments of this post. The more time I spend on that site the more terms I find I was overlooking.

Introduction

Recently I have been thinking through the best ways to get the people I support trained to the same level in SQL. The constraints I am running into are that I do not have the time or even maybe the skill to develop a syllabus and course materials to launch my own SQL Server course. I also know that getting training dollars appropriated for large scale training is difficult even in good economic times.

The Idea

I see the need for an option that splits the difference.

There is a real un-served niche in the market for DBA delivered community training materials. The idea would be to work together as a community to create common course materials and delivery scripts that would be presented by individual DBAs to the teams they support. Everyone would get roughly the same experience while having a trainer that can speak directly to their specific questions or even look at examples using their specific data.

The First Course

The first course I see in the series would be an introduction to TSQL. I am currently reading Microsoft SQL Server 2008 T-SQL Fundamentals (PRO-Developer) by Itzik Ben-Gan to pick up pointers and it strikes me as to how teachable the text is. I feel like if I could just get people to read the book they would be trained. I think that if a few people came together and developed presentations, reading assignments and homework assignments the result would be a powerful teaching tool that any DBA could use to further their organization. The key is that this would be extremely cheap training owned by the community.

I need to pause here and add that I have never developed courseware so I am not sure of the copyright implications or any other details that go with creating courseware from someone else’s text. I picture an author being happy that books will be bought for each participant, but I am sure there is much more to it than I am thinking of.

I Need Feedback

Does this sound like a good idea?

Would you be interested in working on it?

Do you know of something like this that already exists?

Please let me know. I would have to consider no feedback at all to be strong feedback as well.

Introduction

I am frequently getting requests for a new server to do this or that. Running through the usual questions to determine scope and scale, the price can get high pretty quickly. Inevitably,  talk turns to ideas on how to cut the cost while still delivering a robust platform. Typically this is when the questions about skipping the Test, QA or Stage environments come out. The logic is usually that a production server is a must have, a Development server is good to have and anything else is gravy.

Applications running third party (off the shelf) tools can get by just fine without even a Development environment while heavily customized applications need many more environments.

My goal here is to lay out the different environments as well as what I see as a the use for each.

Local

The Local environment refers to an individual developer’s desktop. On this desktop there may be a database server, web server and application server. This is the primary Development environment where things are often built and tried out without fear of angering the rest of the project team.

Chances are that if your organization has a developer you have a Local environment.

Development

The Development environment is the place where everyone’s work starts to come together. It is the first environment that would contain any true servers. Depending on application architecture, this environment may be entirely composed of servers or in the case of client applications still include developer desktops.

Servers in the Development environment are typically given the drive layout as production to allow for restores and Testing of scripts but may only have a fraction of the number of processors, memory and spindles that a production server would have.

I like to compare the Development environment to a busy lake on a hot summer day. There are a lot of people doing their own thing, headed in their respective directions at high speed. The size of your boat (project) usually determines who has the right of way and everyone must adhere to the local customs while keeping their eyes open to prevent collisions.

Testing

The Testing environment is much more of a nice to have environment. For all intents and purposes it is a second Development environment with one important difference, change control. The Testing environment is where code is tested before turning it over to the QA department. It is also the environment where builds are rehearsed to minimize downtime during releases to the QA environment. Developers typically do not have access to change any objects in the Testing environment.

It is very important that the drive layouts between all environments match for manageability purposes. It is even more so for the Testing environment due to how often restores are done to quickly get back to a clean state before Testing the next build.

QA

The QA environment is one of the more important environments. This is the environment where the QA team does their magic. The usage pattern here tends to be low volume and slow paced, so hardware for the QA environment can be the same as that used in the Development environment.

The big thing to remember about the QA environment is that it must be as stable as possible. This is not the best environment to rehearse releases because any problems are likely to put the QA team behind schedule but, absent a test environment, it is the only place many organizations have.

Staging

The Staging environment is tied with production for being the most expensive environment. The Staging environment must be run on exactly the same equipment as production. The typical usage of Staging is automated load testing, user acceptance Testing and even training on important new features.

Without a Staging environment careful scheduling would have to be done to prevent collisions in the QA environment. Otherwise QA testers may be entering defects for behaviors caused by user acceptance or load testing activities. User acceptance testers may also report back to their peers that the changes to the application make it slower when in fact it is just the environment they are testing in.

Many organizations house their Staging and Production servers in separate locations for disaster recovery purposes. Attempting to do the same with only a QA environment would make the release process much more complicated in a disaster recovery scenario as changes would have to go directly from Development or Testing to Production.

Production

This is where the magic happens. I think everyone understands the need for a Production server so I am not going to spend a lot of time here. The point I would like to make is that the more money you spend on your production environment, the more environments you should have to back it up. There is no point to spending a small fortune on the best HA cluster you can find without having the capability to do real release management and disaster recovery or worst case: release management in disaster recovery.

Conclusion

I hope I have provided enough information to begin to ask the right questions when working with users to price out servers. Being able to properly educate users either helps them come to a realistic evaluation of their needs or a business case for 6 or 7 brand new servers that you can brag to your DBA friends about.