So How Did It Go?

My first time speaking at a SQL Saturday is now behind me.  I cannot wait to do it again. The support from the SQL Family leading up to and after the event was nothing I expected, it was beyond AMAZING. From high fives in the halls to virtual hugs. I had my own cheering section.

I was a little nervous and talked probably too fast at times, I am sure, but I hear everyone does on their first time out, right? (Evidently, I say that a lot) The good part was that the audience looked to be truly engaged and listening to what I had to say. I even had a few attendees come up to me afterwards and tell me they enjoyed the session and wanted my card. I can’t describe the high you get from that. I, totally, know now why speakers give up their time to do this.comments

Anyhow, I just wanted to say thanks for all the support and I am looking forward to speaking and sharing my knowledge with others.

Moving Forward

To continue to feed my new found addiction, I have already submitted to speak at a couple more SQL Saturday’s.  More specifically, I submitted to speak at SQL Saturday #478 in Albuquerque, New Mexico and to SQL Saturday #470 in Washington, D.C.. I hope that these events will allow me to move forward in becoming a better speaker and to continue giving back to this awesome community! Either way speaking or not, I’ll see you at my next SQL Saturday in DC.

Admit You Can’t Do Everything

As most of you know, I have been a Lone DBA for 15+ years and during that time I have learned a thing or two about how to survive on my own in relatively large environments.  One of those things is knowing when to admit you cannot do it all.  Working alone on 56 servers you can imagine how the workload can seem insurmountable.  There are times when in one week I will do 70+ tasks, not including project work and daily monitoring.  To manage and get this type of workload accomplish you have to learn to work smarter not harder. That’s when you have to enlist help and hire consultants.

But I am Afraid

Many people think that hiring consultants is admitting you are incapable of doing your job. Some think that if you hire consultants, it opens the door for the company to think that they may not need an “in house” DBA. It may lead them to just hire a consulting company to do the work. At the last company I worked for employees frowned and complained every time a consultant was brought in for anything.  Some even refused to share knowledge hoping to protect their jobs somehow.   I think this is nonsense.  You shouldn’t worry about being replaced by consultants.  A consultant only has superficial knowledge of the company.  You are the one that knows the whys, how’s, and understand the needs of the business.  The consultants don’t.  Don’t let it scare you.

Free Up Your Time

The biggest opponent I have to contend with as a Lone DBA is time. I have no time; every minute of my work day is used.  My world is all about prioritizing what needs to get done. Sometimes there is just not enough time in the day.  Hiring a consultant doesn’t mean you can’t do the work; it means you are managing your work load.

I hire consultants from time to time to free up my plate and cover some of the workload so I am able to focus on higher priorities. At times, I use them to do the normal redundant or routine admin work, little things that add up to a lot of time in a week.  On other occasions, I admittedly give them stuff I don’t want to do, or get tired of doing (but if you know me, I never really get “tired” of doing anything DBA related, I am just proving a point).  I will also give them the big projects that take too much time. Time is invaluable. For example, I may need to build a new cube. That as you may know, takes a lot of time. I know how to build and design cubes, but why should I spend hundreds of hours working on that when I can farm that out?

Do You Want to Take Vacation Ever?

Vacation, what’s that? Most DBA’s can take vacation without having to do work, because there is someone to cover and share your responsibilities. When it’s just you; you take work on vacation with you. One of the best benefits of hiring a consultant or a DBA service is to be able to leave that work load at work and take a real vacation. It took me years to realize this. I took my first vacation without work just earlier this year, it was wonderful to hand the reins over for a week and not have to worry about it.

Gotachas

However, there are a few gotchas to admitting you can’t do everything and hiring a consultant. One of the main one for me is giving up what you like to do. I love the core DBA stuff; turning that over to someone else to do is not easy for me. Relinquishing that can be very tough.  I also find that having to spend time hand holding the consultant is another gotcha. Consultants do not know the ins and outs of your environment. Getting them started on a project can take time away from you but in the end it’s worth it.

Embrace It

The moral of the story is I think it’s hugely important to admit to yourself that you can’t do it all. It took years for me to realize that I don’t have to do it all.  If you are juggling a workload for many when you are just one consider hiring help. You’ll thank me for it.

My First Speaking SQL Saturday

sqlsat

I will be speaking at my first SQL Saturday on September 26th in Spartanburg SC.  I am so excited to have been selected to give my session on Survival Techniques for the Lone DBA.  After a year of, not so subtle hints from the SQL Family (John Morehouse (b|t), Rie Irish (t), Melody Zacharias (b|t), Mike Fal (b|t), Argenis Fernandez (b|t) , Kirsten Benzel (b|t), Andy Yun (b|t), Lindsay Clark (t)), I submitted my first session and got selected.   I will be finally standing up before a room of colleagues and talking about my experience as a lone DBA for the last 15+ years.

What did I just do?

Unless you have ever submitted to a SQL Saturday, you have no idea how it feels to input your biography and abstract into the site and hit that submit button. It is exhilarating and scary all at once. You get this “Oh crap! what did  I just do?!” feeling. Part of you hopes you get selected to speak and the other little part of you wants to say “Ok I submitted, let that be enough for now.“ I am very happy to have gotten selected and I’m looking forward to hitting that submit button on many more events.

Feedbackfeedback

I gave this session last month at my local user group and I now totally understand why so many take the opportunity to speak.  The thrill you experience as the audience engages in what you have to share is overwhelming. I loved to see the proverbial light bulb turn on, after showing another way of doing something. It was so much fun (yes I am a dork, I know).  One of the best things I experienced after doing the session was reading the session feedback forms.  If you are one of the ones that normally don’t give feedback I ask you to reconsider. The feedback is how we as speakers (yep me included now) can improve. I was pleasantly surprised at the comments and happy to learn they got more out of the session they expected. Mission accomplished in my book. I can’t wait to see the feedback from SQL Saturday! Hopefully I’ll get some feedback on what to improve upon.

Look! I am on the schedule! Come join me at 3:45-4:45.Capture

I’m It – Survival Techniques for the Lone DBA

Abstract: Are you the only database person at your company? Are you both the DBA and the Developer? Being the only data professional in an environment can seem overwhelming, daunting, and darn near impossible sometimes. However, it can also be extremely rewarding and empowering.  This session will cover how you can keep your sanity, get stuff done, and still love your job. We’ll cover how I have survived and thrived being a Lone DBA for 15 years and how you can too.  When you finish this session, you’ll know what you can do to make your job easier, where to find help, and how to still be able to advance and enrich your career.

Why not attend?

So, if you are in the Spartanburg, SC area that weekend come out and get come free SQL Training and stop by my session that afternoon. You can register for the event at https://www.sqlsaturday.com/431/EventHome.aspx and here is the lineup of sessions https://www.sqlsaturday.com/431/Sessions/Schedule.aspx .

Hope to see you there; it’s going to be a great event!

So let’s talk naming conventions

How many of you have come across a database that had stored procedures, views or functions and you had no clue, by name, what they were for? Having standard naming conventions helps to prevent that. Everyone has their own preferences and opinions on what they should be, so I thought I’d share mine.

My opinion

In a nutshell, the name of any object should be informative; specifically what the object is used for and where it is used. This is accomplished by utilizing prefixes in conjunction with specific naming conventions.  I apply these standards to all of my stored procedures, views, and functions, whenever possible. Of course there are always times where naming conventions don’t fit the situation, you have to be flexible and logically choose a name that fits that scenario.

Here Are My Standards

standards

Stored Procedures

  • Stored Procedure name should accurately reflect the content and function
  • No Spaces
  • No Underscores
  • Use Camel Case Only example “rptTheNewStoredProcedure”
  • The following prefixes should be used for all names
  • New Prefixes can be added as needed when a deemed applicable
Prefix Use
rpt Reporting Services Report
app Applications
web Website Exclusively
xls Direct Excel Data Pull
ssis Store Procedure only used in SSIS packages
job SQL Agent Job Step
cube Analysis Services Cube Data

If a stored procedure has multiple uses, I choose the highest entry in the usage hierarchy as the prefix. For example, a job that calls a stored procedure for an application. The job is what calls it, so it would be named with the job prefix. Using the prefix job will point me to SQL Agent. There I should see a job having a job step with same name as stored procedure minus the prefix and a stored procedure of the same name prefixed with job. At any point in it should give the DBA a trail to follow. Don’t duplicate a stored procedure to use in multiple places. Otherwise, any change will have to be done multiple times.

Views

  • View name should accurately reflect the content and function
  • No Spaces
  • No Underscores
  • Use Camel Case only example “rptVwTheNewView”
Prefix Use
rptVw Reporting Services Reports
appVw Applications
webVw Website Exclusively
jobVw Job Related
cubeVw Analysis Services Cube

I add Vw just so I can differentiate it from a stored procedure or table. Now you may question why I add Vw to views but not p or proc prefix to stored procedures. It’s simply because for me stored procedures are the default and doesn’t need it.

Functions

  • Function name should accurately reflect the content and function
  • No Spaces
  • No Underscores
  • Prefix with fx
  • Use Camel Case only example “fxTheNewFunction”

Because functions can be called by lots of objects I tend only to use fx and not add rpt etc. Functions are the only objects that deviate from the norm for me.

Right Way

The best use example I can give for how I try to implement naming conventions as a way to identify its use is a stored procedure for a reporting services report. The stored procedure should be named exactly what the report is or will be named, but will have the prefix of rpt. Whoever comes into the database should look at the name and know it’s;

  1. A stored procedure called by a report
  2. There will be an .rdl file that has the exact same name minus the prefix.

Exhibit A

Stored Procedure: rptCostofManufacturedItems

Report Services Report: CostofManufacturedItems.rdl

The Not So Right Way

wrong

The not so correct way

Like the toilet paper roll being put on the wrong way. It is a huge pet peeve of mine to see stored procedures named something that you cannot tell what it is. I get irritated when people prefix a stored procedure it p_ or proc, it’s just a thing for me.  I also despise the wretched underscore and mismatched casing. As you can probably tell, I am particularly persnickety when it comes to naming conventions.

Exhibit B (a real exhibit I have encountered)

Stored Procedure: p_DatabaseA_Skus_customers_ROLLING_vj_v5

Report Services Report: customer items.rdl
The name, as I figured out, was “p” for procedure, database name (which makes no sense since I can find it under that database), then procedure use, the developers initials, and finally a version number.  As you can see the report that is it associated with, tells you in absolutely no way shape or form, that it uses that procedure. Notice the “v5” in the name.  Yep, there were 5 of these puppies.  I could not tell without locating the report which one was actually used. Finding which report was a task in and of its self since the report was named completely different from the stored procedure. With naming conventions like this you waste time just trying to figure out what goes with what.

What’s your standard?

Everyone’s environment is different and some may not agree with my opinion, but it works for me. I’d be interested to hear other standards people use. Maybe I can pick up an idea or two.

The key to this is to come up with standards of your own and implement them.  Use them not only for the objects I listed but also for  triggers, indexes, jobs, and replication. It’s less important WHAT your conventions are. It’s more important that you have them. Pick what works for your company’s business model and push all those who deploy to production, including report writers, to use the same naming conventions.  Cleanly named objects make for happy DBA’s.

The Outpouring

I’ve wanted to write about this for months, now that I have a blog I can finally do it.

Earlier this year, I found out, thru Twitter that fellow SQL Family member Larry Toothman (@IowaTechBear), had suffered a stroke. Having never met Larry in person, but having spoken to him on occasion via Twitter I wanted to let him know that people in his SQL community wished him well. That morning I tweeted that I was going to collect money for flowers to send him on behalf of the SQL Family.

larrystartUnfortunately, we soon got word that Larry was on life support. A few days later he passed away. Within those few days and the week that followed the outpouring of generosity the SQL Family was incomprehensible.  The small flower fund I was trying for turned into a substantial memorial fund.
Larry1

To collect the funds, I set up a PayPal account and tweeted that I would continue to accept money for a few days. The money would be used to send something to Larry’s husband on our behalf. I really only expected but a few $5 donations here and there. To my surprise it took just a simple tweet and the dollar total rapidly climbed. I could not believe that SQL Family members started blindly sending me money (Me, just a DBA, in Virginia that happens to tweet a lot).

People I never met were giving me $25, $50 and $100 at a time towards this fund. Let’s think about that for a moment.  What group of “strangers” do you know that just sends money to help the family of “another DBA from Iowa”?   That is exactly what happened.
larry 3

Over the next week, money continued flooding in from all over the world. I got donations from as far away as Denmark, Australia, South Africa, Norway, Canada, London, and all over the United States. Some people would send me a direct message to simply say they didn’t know Larry, but wanted to donate so that his husband knew people from across the globe cared.

All in all the family raise over $2000, Frank (@IowaCub), Larry’s husband,  was overcome by our generosity and truly grateful for what we had done.

last larry

This just another example of the unique nature of our SQL Family, thanks to everyone that contributed.

How I joined the SQL Family

For my first blog I want to talk about my experience as a member of SQL Family.

My Start

I started my career as a lone DBA, 15 years ago, with zero knowledge of what SQL Server actually was. I was promoted into a sole DBA job with expectations I would get certified and take the bull by the horns to manage the 50+ SQL Servers .  The company, The Port of Virginia, took a big risk with me, but within 6 months’ time the gamble had paid off. In the beginning, most of what I learned to do the job was from a site called SSWUG.org. This is where a man by the name of Chris Shaw “Shaw” (t|b) unknowingly mentored me for three years. Twice a year I would register for the virtual training conferences the site had to offer where I attended almost every session Shaw presented.

My First PASS Summit

After a several years as DBA, I was given the opportunity to attend my very first PASS Summit. This is when I began to find out what SQL Family was and when my exposure to SQL Server grew exponentially. Prior to going to Summit I registered for Summit’s “First Timers” program, I was assigned to a volunteer, SQL Family member, TJay Belt (t|b). His job was to tell us how to prepare for Summit and how to get the most out of it. In his first email, he suggested we setup a Twitter account before doing anything else. He said to use SQL as part of your handle and just start following the #summit11 hash tag. So I did. Creating a Twitter account was one of the best pieces of advice that I could have gotten.

On the first day at Summit, I attended a session given by Shaw and after the session I introduced myself to him. I told him that he was my mentor and thanked him for sharing his knowledge with me. For me it was like meeting a celebrity (cheesy, I know). I was pleasantly surprised how nice he was and humbled he was to hear how much his sessions had meant to me. Shaw ended up being the first SQL Family member I met in person. I ran into him a few more times that week and by the end of the week he made a promise to me to get me an autographed SSWUGGIE.  A “SSWUGGIE” is a Snuggie blanket with the SSWUG logo on it. Some speakers wore them in the virtual conference sessions and I thought they were cute at the time. A month later, I received it in the mail.

swwug

During Summit I traded business cards with so many people, talked with so many different DBA’s, attended all the events, and some after parties. Luckily for me, I am very outgoing and just jumped in with both feet taking advantage of everything Summit offered (which I highly encourage others to do). I met more than a dozen active SQL Family members that week. Upon returning home I logged into Twitter and began following everyone who gave me a business card.

My New Virtual Co- workers

As a lone DBA, Twitter has given me an outlet and supplied me with thousands of new co- workers.  Over the years, I have relied heavily on these connections. I can find help by just tweeting questions or using the #SQLHelp hash tag. All hours of the day and night SQL Family will come out of the woodwork to help me and others. I can’t tell you how many times I’ve been able work through an issue, talk through ideas, and just vent to them. SQL Family has generously shared their knowledge and guidance which has in turn helped me grow as a DBA.

Becoming a Valued Member of the Family

Now that I, myself, am a seasoned DBA with knowledge to share, I want to begin doing for others what SQL Family has done for me. I have started speaking at SQL Saturdays (thanks to being encouraged by SQL Family members), I am running my local SQL Server User Group (thanks to Derik Hammer (t|b)), and now look at me I am blogging. I find myself immersed daily in SQL Family. Each morning when I log into work I also log into Twitter and say good morning to them. I have Twitter open on my desktop all day looking to see what’s going on with #SQLHelp, reading blogs I see tweeted, and just staying part of ongoing SQL conversations.  Every day the SQL Family continues to teach me something new.

Thankful

I never imagined that when I started as a lone DBA that I would be able to walk in the footsteps of my mentor Chris Shaw and contribute to others in the SQL community.  I’ve been able to begin to give back to the family that helped raise me in the SQL world. Thanks to all of you that knowing or unknowingly impacting my career and for bringing me into the amazing community we lovingly call SQL Family.  Looking forward to our Annual SQL Family Reunion they call PASS Summit. I am proud to be a member.