Experience Comes from Mistakes

In my opinion the big difference between a Database Administrator (DBA) and a Senior Database Administrator (Sr. DBA), comes down to experience, sounds simple enough right? If we explore that a little deeper, wouldn’t it be easy enough to base the differences on knowledge? A Sr. DBA would have a wider knowledge base to draw from as they face every day challenges, otherwise said as someone who has an extensive amount of time spent studying and learning quite a bit about SQL Server combined with opportunities to work with the product. Knowledge comes from many sources, in my experience I gain the most knowledge from making mistakes. As an example, I learned quite a bit about relationships when I purchased race day tickets for my wife’s birthday I had even purchased tickets to sit and eat lunch with my favorite driver. This was lesson was reinforced when the year after I bought her the vacuum cleaner she had mentioned she wanted.

All men make mistakes, but only wise men learn from their mistakes. – Winston Churchill

When I reflect to my first full time IT position, I often think about the lesson I learned about troubleshooting issues. I had just completed a week long class on how to install the Windows OS (NT 4.0) and how to create a new domain where I could then add the entire collection of PC’s. The class was great and I was confidant in my skills, because I had eventually completed all the lab work in the class. My confidence quickly faded over the next week (including the weekend) with each reinstall of the Domain Controller simply because each attempt resulted with errors stating the workstations could not find the domain. The biggest blow to my self-confidence came when I realized all my issues were resolved when I determined I should start with the basics and power on the network switch.

At first I consider the mistake a lesson in how that network switch worked, but today I realize the true lesson learned was all about troubleshooting and more importantly the importance of learning from the mistakes I have made. Everyone has different learning experiences, I often wonder about the mistakes other database professionals have made and what they have learned from them. There are many people I respect in the SQL Server Community, and I can see a true value in learning from them. If they have the time available, I would love to hear about the lessons they have learned:

Paul Randal

Andy Leonard

John Morehouse

If you have had an experience that you are willing to share I would love to read about it, and share it with others. Please post on it and let me know so I can share it with my network.

 

 

Join SQL Server Expert Andy Leonard at the Colorado Springs SQL Server users Group.

Extra info for the next Colorado Springs SQL Server Users Group.

We are thrilled to announce Andy Leonard, will be presenting at the January 22 meeting!

 

Main Session:
“Using BIML as a Design Patterns Engine” by Andy Leonard

Business Intelligence Markup Language provides a powerful solution for creating and managing SSIS Design Patterns. Andy Leonard, one of the authors of SSIS Design Patterns, demonstrates the flexibility of BIML in this session.
 

Meeting Location:

Hyatt Place – Garden of the Gods

503 West Garden of the Gods Road

Colorado Springs, CO 80909

 
 

Andy was asked to tell us a little more about his session here is the information he passed along. We were excited to hear Andy was coming; now we are even more excited.

   Generally speaking, it takes 1-2 hours to code an SSIS package that
moves data from a source to a destination. If you use a simple pattern for
the integration, it can take less time. But the work is mostly manual and
repetitive. It really stinks when you want to create one SSIS package per
table and you have several (or several hundred) tables.
   Business Intelligence Markup Language (Biml) helps in these scenarios,
as my presentation demonstrates. We’ll start with some simple Biml used to
create empty and basic packages, but then we will leverage BimlScript –
.Net inside the Biml file – to build a single Biml file that can create
hundreds of SSIS packages.
   Because the packages are dynamically created from the same pattern, they
are functionally equivalent. This translates to higher quality. And because
of the automation provided by Biml, SSIS package creation time drops
drastically. My best use-case is an incremental load project I worked on to
transfer data from approximately 900 tables into a SQL Server database.
Incremental load patterns are somewhat involved, and usually take a couple
hours per package. I like to build one package per table for separation of
concerns, testing, and support reasons. Building this by hand would have
taken 2 hours per package, or just under one person-year. Using Biml, I was
able to generate these packages in a morning.

   I will be covering this in the presentation.

Hope this helps.
Andy

About Andy Leonard
Andy Leonard is CSO of Linchpin People, an SSIS Trainer and Consultant, SQL Server database and Integration Services developer, SQL Server data warehouse developer, community mentor, blogger, and engineer. He is a co-author of SSIS Design Patterns. His background includes VB and web application architecture and development; and SQL Server 2000-2012.

 

 

Anyone, Everyone, Someone and No-One is “On Call”

I am sure you have heard the old bit about…. This is the story I think about every time I hear about a shop that doesn’t have an on-call rotation or some sort of coverage for afterhours work.

There was an important job to be done and Everyone was sure that Someone would do it. Anyone could have done it, but No-one did it. Someone got angry about that because he thought that it was Everyone’s job. Everyone thought that Anyone could do it, but No-one realized that Everyone wouldn’t do it. It ended up that Everyone was angry with Someone because No-one did what Anyone could have done!

I have seen shops do everything they can to avoid official on-call routines. I am not sure why, I can only assume it means the organization officially recognizes after hours work is required. Is it because when a company posts a position and being on-call is listed in the requirements, the job posting does not look as attractive? Or is the requirement itself lead to increased salary requirements. I am sure to be honest there are a number of potential other reasons why organizations don’t have an official on-call. Rather than identify all the potential reasons why an organization avoids an on-call call rotation, we might achomplish more if we identifying the benefits of having an on-call rotation.

• On-Call rotations allow for problem ownership. Even if the on-call doesn’t fix the problem, then can notify the people needed to correct the problem.
• Ensures that someone is available during times when no-one is around. For example, many people have plans around Holidays. Without an on-call schedule where there is a defined responsibility for that time frame everyone may be away and assuming someone else will take care of it.
• Share the workload. Even if you are on a team now where everyone contributes equally I am sure you have been in a situation where you see a small number of people doing the majority of the work. If you haven’t seen that, consider yourself lucky.
• On-call schedules will get things back to normal faster.

One of my past employers didn’t have an on call schedule, so when there were times I was traveling or spending critical time with the family I could be called at any time, and I was. Rather than look at an on-call schedule as time you may be required to do even more hours, look at an on-call schedule as an opportunity to ensure your off time is being spent focused on something you want. Or in other words, don’t consider a one week a month on-call a week of extra work. Consider it as 3 weeks a month of extra you time.