Summit Submission Feedback Response

I’m It Survival Tips for the Lone DBA – Level 100

(Not Accepted: Higher rated session selected)

Track: Professional Development

As others have done I also will share my feedback from my submission to speak at PASS Summit in hopes it will lend some more insight into the process.

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.

Topic: Handling High Stress Situations

Prereqs:
None

Goals:

  • Show how to manage the people you work with (boss, developers, etc) to control expectations around your life and environment.
  • The importance of tools and how to build out the best tool set to support you in your job.
  • Discuss tips on building out your support resources (people, blogs, etc) to help you get through your day.

Feedback:

  • This is more related to dba track rather than prodev. Also is survival really career development? Many would say that working 15 years as a lone dba could equate to failure in some peoples eye’s and I would struggle to want to see this session based upon info provided.
  • Interesting topic; 1st/2nd/3rd person tense shift -bad. Borderline PD topic.
  • I like the title. Good topic and goals. I’d like to have more details in the abstract of what content to expect.
  • Well written abstract with clear goals and a well-developed outline. The topic is one that should appeal to a large audience. The title and abstract are catchy. Overall a really good abstract. Sounds like a session I would enjoy attending.

My Thoughts:
Honestly, I was a little taken a back at the first comment. I found it insulting and not helpful. I am not sure how telling someone working as a Lone DBA for 15 years is seen as a failure. Especially when those of us that do it, manage to do the work load of multiple people by ourselves.  After considering it, I forwarded the comment on to PASS as being inappropriate and unconstructive. I was pleasantly surprised at their response. I give kudos to all the hard work that goes into reviewing the comments before they send them out.

Secondly, I fully understand how some would feel that this is not a Professional Development session, maybe I should have put in under Database Administration. I still have mixed views on that. In any case, I have found this session to be well received and always have 15-25 in attendance at SQL Saturday’s. Regardless of the feedback I will continue to submit it to SQL Saturdays and Summit next year. There are many Lone DBA’s out there and I will to continue to lend them a hand by sharing my 15 years’ experience with them.

 

Back to Basics: Why not parameterize?

I think sometimes those of us that have been doing database administration/development for a while take it for granted that everyone knows the basics. One such basic is parameterizing stored procedures. This allows us to potentially consolidate multiple stored procedures into a single procedure.  It’s as simple thing to do that many don’t.

I try to parameterize as many stored procedures as possible. This not only minimizes the amount of procedures I need to maintain, it in my opinion is a much cleaner way to code. It disturbs me when I see multiple stored procedures that pull the exact same data, but may have slight differences between them. Whether it be a sort, a where clause, or even just an extra field or two that makes it different, some developers think you need a different procedure for each one . Why not consolidate and parameterize?

Exhibit A

The code below is an example of a real work scenario.  Originally, it was 8 stored procedures and with 8 correlated reports. By simply adding a Report Type parameter I was able to make it one stored procedure and as well as consolidate to a single report.

To add a new dataset just right click on Datasets and choose Add Dataset. Since the report is a stored procedure we set the dataset connection string to the stored procedure name and its parameters. This is just my preferred method. You can also choose the stored procedure from the drop down.

rep

rptTrackMonthlyStats @ReportType, @year, @startdate, @enddate

rp

In the Report Type parameter, choose add Available Values. I typed in each option so the user could choose which report layout/data they wanted to see from drop down. That parameter will be passed to the stored procedure upon execution and the proper dataset will be returned. The users will never see the T, TD etc. they only see the label so it doesn’t make any difference to them what those are.

Parareport connectiom

You can even go as far as using these parameters to hide and show different report elements, but that’s for another time. Stay tuned for more back to the basics.

NOTE: There are some reasons not to do this, like the reuse of the execution plans and parameter sniffing but in these cases consolidating would not be an issue as they use the same parameters.

Attending Summit as a New Leader

It’s that time again where everyone writes their post PASS Summit Blog and tells of the great time they had with SQL Family and all the exciting new things they learned.  While those are both very true for me as well, I want to talk about how it felt to go to Summit as a new leader in the community.

This year I became a Chapter Leader and spent Tuesday at Summit in the PASS Chapter Leader and SQL Saturday meetings. It was an honor for me to walk into those meetings and collaborate with such a phenomenal group of people.  It was even more remarkable to be called out by name by more than a few.  I even commented to a couple of people that I can’t believe I was there legitimately (yes, I have crashed a few speaker dinners in my day, while not being a speaker).  Since it was only Tuesday, being involved in these meetings really helped to set a positive outlook for the remainder of my time at the Summit.

Sports-Leadership-Quotes-4

Now there were more than a few “old timers” there that had been running their chapter for years and wasn’t nearly as enthralled with some of the information being presented in the meeting. They had heard it all before, but for me it was all new and stimulating. As I sat back and listened to their input and looked at the slides, I was impressed to see how many active chapters PASS has and how many SQL Saturdays were delivered in 2015. The staggering amount of effort and time that people freely give to help build others and improve this community is astounding to me.  I don’t think people realize how much time, effort and passion goes into running a chapter or putting on a SQL Saturday.  I was inspired.

One of my favorite parts of the meetings were the question and answer sessions with vendor representatives. It really opened my eyes on how both parties need and support the other’s initiatives. It was a reminder that they are not just there to give us money, they also provide education, and give backing to community members willing to share their knowledge with others. Programs such as the Idera Ace Program and Friends of Red-gate do just that.  In return for their funding chapters and community members give them exposure, contact lists, and help promote their products. It’s very much a give and take. The vendors also gave great advice for chapter leaders as when and how to get sponsorship; timing and planning ahead are essential. I took lots of notes.

For the remainder of Summit, I talked to other leaders and got ideas to take back to my chapter. I worked on making even more connections and getting speakers lined up for our upcoming 2016 calendar year. I engaged in discussions on how to get more involved and build future leaders.

It was kind of different take on Summit for me. Don’t get me wrong I attended my share of sessions including a great Pre Con by Argenis Fernandez, David Klee and Jimmy May on Virtualization. I went to all the PASS Sponsored night time events and attended more than my fair share of Vendor parties. It was a fantastic week with the #SQLFamily as always.  There is nothing like spending a week with like-minded people discussing things you are passionate about.

Now that it’s wrapped up, I want to take that inspiration I gained and do something more with it. This year I have set a goal for myself to be an example of how to get involved and make a difference.  I would love to help inspire future leaders by spreading my enthusiasm through speaking at SQL Saturdays, running my chapter and volunteering where ever needed. I challenge you to do the same.

See you guys at the next PASS Summit I will be there for sure!

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.

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.

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.