Highlighting Women in the SQL Community - July 2017

Find a mentor.  Be a mentor.

Build a strong network of women.

Make friendships with other women working in your field.

As most of you know, I think it's my calling to highlight & support women in technology, specifically speakers and leaders in the SQL Community.  Each month, our Virtual Group presents a technical session by a female speaker or a session specific to a female gender related topic, presented by a man or woman.  Part of these sessions involves a list of what women are doing.  That's what this blog psot does.  A highlight of what women in the SQL Community are doing in just the second half of July 2017

Event	Location	Date	Session Title	Presenter
SQL Sat #653	Columbus	7/22/2017	Health: The Most Important Tech Tool	Cassandra Faris
SQL Sat #653	Columbus	7/22/2017	Collecting Baseline Metrics	Tracy Boggiano
SQL Sat #653	Columbus	7/22/2017	Why NULL is not a value (and other SQL gotchas)	Wendy Pastrick
SQL Sat #653	Columbus	7/22/2017	I’m It – Survival Techniques for the Lone DBA	Monica Rathbun
SQL Sat #653	Columbus	7/22/2017	Are You There, DBA? It’s Me, The App Developer	Jacquelyn Keeper
SQL Sat #653	Columbus	7/22/2017	Answering the question, "What happened?" with Query Store	Erin Stellato
SQL Sat #653	Columbus	7/22/2017	Making Your List and Checking It Twice: Introduction to unit testing with tSQLt	Elizabeth Noble
SQL Sat #653	Columbus	7/22/2017	Where Does R Fit Into Your SQL Server Stack?	Stacia Varga
SQL Sat#653	Columbus	7/22/2017	Reduce your DBA (& DEV) task list by using Microsoft BI tools	Tamera Clark
SQL Sat #654	Omaha	7/22/2017	Transitioning from Integration Services to Azure Data Factory	Meagan Longoria
SQL Sat #654	Omaha	7/22/2017	Things I Learned the Hard Way About Azure Data Platform Services So That You Don't Have To	Meagan Longoria
SQL Sat #628	Baton Rouge	7/29/2017	Introduction to SharePoint Patterns and Practices	Theresa Eller
SQL Sat #628	Baton Rouge	7/29/2017	Deadlock, Block & Two Smoking Barrels: Breaking Down Blocking and Deadlocks	Amy Herold
SQL Sat #628	Baton Rouge	7/29/2017	SQL Server Statistics – What Are The Chances?	Lori Edwards
SQL Sat #628	Baton Rouge	7/29/2017	How to Build Your Disaster Recovery Plan	Rie Irish
SQL Sat #628	Baton Rouge	7/29/2017	Beginning Automation with Powershell	Amy Herold
SQL Sat #628	Baton Rouge	7/29/2017	Troubleshooting SQL Server Performance	Stacy Gray
SQL Sat #628	Baton Rouge	7/29/2017	Mastering your Resume & Interview: Tips to Get Hired	Christine Assaf
SQL Sat #628	Baton Rouge	7/29/2017	Let Her Finish: Supporting Women's Voices from meetings to the board room	Rie Irsih
SQL Sat #628	Baton Rouge	7/29/2017	Taking Time for You	Kathryn LeBlanc
SQL Sat #628	Baton Rouge	7/29/2017	Giving Feedback: How to Effectively Communicate to your Employees	Christine Assaf
SQL Sat #628	Baton Rouge	7/29/2017	Women in Technology: Identifying and Understanding Gender Bias & Inequality	Rie Irish
SQL Sat #628	Baton Rouge	7/29/2017	T-SQL's Hidden Support Feature	Jennifer McCown
SQL Sat #622	Albany	7/29/2017	Network your Way to Success!	Lisa Margerum
SQL Sat #622	Albany	7/29/2017	Back to the Basics: T-SQL 101	Deborah Melkin
SQL Sat #622	Albany	7/29/2017	Top 10 Features of a Great Business Intelligence Solution	Rachel Blum
SQL Sat #622	Albany	7/29/2017	Master Your Data using DQS and MDS	Beth Wolfset

24 Hours of PASS

Why Did My Clever Index Change Backfire?

Kendra Little

19 Jul 2017 16:00 GMT

SQL Server is full of advanced techniques to build powerful indexes: indexed views, filtered...

Writing User Stories and Slicing Epics for DW/BI Teams

Lynn Winterboer

 19 Jul 2017 14:00 GMT

Agile is all the rage in software development, and many data warehousing and business intelligence...

DevOps and the Agile DBA

Kellyn Pot'Vin-Gorman

19 Jul 2017 17:00 GMT

DevOps came out of the Agile movement and the idea that operations needed to be part of the...

Help me, Query Store. You're My Only Hope

Erin Stellato

19 Jul 2017 19:00 GMT

The Query Store feature in SQL Server is marketed as a flight recorder for your database. 

PowerShell ❤️ SQL Server: Modern Database Administration

Chrissy LeMaire

19 Jul 2017 21:00 GMT

Join dbatools teammates Chrissy LeMaire and Constantine Kokkinos for a fun, fast-paced session that...

Implementing Advanced Analytics with SQL Server 2017 and Python

Ginger Grant

20 Jul 2017 00:00 GMT

Looking to find out what is coming next with SQL Server? Thinking about learning a new analytical...

Tools and Tips: From Accidental to Efficient Data Warehouse Developer

Cathrine Wilhelmsen

20 Jul 2017 06:00 GMT

You have probably heard about the Accidental DBA, but what about the Accidental Data Warehouse...

SQL Server Data Compression

Kathi Kellenberger

20 Jul 2017 08:00 GMT

When I first heard about data compression back when it was introduced with SQL Server 2008

On Transactions and Atomic Operations

Gail Shaw

20 Jul 2017 11:00 GMT

"If there’s one thing that we, as SQL developers don’t do, it’s use transactions as often as we...

Women in Technology
Upcoming Webinars

uHe’s Assertive. She’s Aggressive (Unconscious Bias in the Workplace)

uAndrea Mascher

uSept 21, 2017

u

uCreating and Maintaining Successful Open Source Projects

uChrissy LeMaire

uOct 4, 2017

Women in Technology 

Today’s Session

uMelissa Coates

uTales from Building a SQL Server Data Warehouse in Azure

uIn this session, we share our experiences and lessons learned from a recent migration to Azure for a SQL Server data warehousing environment. We begin with sharing our reasoning for IaaS vs. PaaS, our carefully-selected naming conventions, and how we structured development, test, and production within subscriptions and resource groups. We cover the what, why, and how for decisions around storage, encryption, and backups. Finally, the session wraps up with a brief discussion of the use of Azure Resource Manager (ARM) templates and PowerShell, as well as techniques for monitoring the environment in Azure.

uMelissa Coates is a Business Intelligence Architect with SentryOne. Based in Charlotte, North Carolina, she specializes in delivering Analytics, Data Warehousing, and Business Intelligence solutions using on-premises, cloud, and hybrid technologies. Formerly a CPA, Melissa is ridiculously proud to be an IT geek and downright giddy to be a Microsoft Data Platform MVP. When Melissa steps away from the keyboard, you can probably find her hanging out with her border collie, paddle boarding, or playing in the garden.  Melissa blogs at sqlchick.com.

SQL Saturday Atlanta is almost here

     Well, it's that time of year again.  No, not summer time, where people take vacations with their family, spend lazy Saturdays at the lake or sitting on their patio with a beer.  It's that time of year when the idea of free time goes out the window. We've been hard at work planning SQL Saturday Atlanta.  We've moved to a new month (July instead of May) and a new venue (Lawrenceville instead of Alpharetta).  These changes have meant almost everything else changes too:  hotel, pre con dinner locations, speaker party location, after party location, struggling with room layout, where to put the sponsors, etc.

The search for a new venue was a treacherous one. We looked everywhere.

     The new venue is lovely, spacious & filled with light in the common areas.  Gwinnett Technical College has been a joy to work with.  Luckily, we've been able to get almost everything on the first floor.  We have multiple rooms that seat 90 people and most seat 50+.  We're going to need it too.  As of today, we have 709 attendees registered.  But as expected there are some last minute details to work out.  Things like having a custodian on staff so we don't run out of toilet paper in the men's room. Making sure we have a tech support person there to show us how this crazy AV equipment works.  Do we have WiFi for everyone? Can the ready room be locked overnight or do I have to move all our things to a different place & bring it back bright & early on Saturday?

     And let's not forget budgeting.  The new place is expensive.  I know a lot of SQL Saturdays get venues for little to nothing.  That isn't how it works here in Atlanta.  Not for 500+ people.  So we do this delicate balancing act of paying over $8,000 for a building that will hold us all, feed 500+ people a decent lunch in a very short window of time, host a speaker dinner & an after party all while making sure sponsors get their monies worth.

I find it helps to know your limitations.

     The best part is my team.  SQL Saturday Atlanta has done it again.  They've surpassed my expectations when it came to presenting ideas and executing on it.  They're pictured here, hard at work.

Our attitude for this upcoming quest?  Keep calm.

On Being Awarded my Microsoft MVP on the Data Platform

The email came on Saturday, April 1st.  It was already a crazy day, with my daughter competing in regionals, several hours away that evening.  Things were a bit of a whirlwind that morning getting her to dress rehearsal in full hair & makeup, costume ready to go and packing bags for our over night stay.  I'm having a very late, very rushed lunch with my boyfriend as 3 MVP calendar invites show up in my inbox.  There's been some mistake, I think.  It is April Fool's Day after all. I wasn't awarded an MVP with this latest round.  Was I?  

Time to check the Social & Promotional folders on my Gmail. And there it is

Congratulations 2017 Microsoft MVP!

I'm actually at a loss for words for a couple of minutes.  I place my phone, face down on the table and quietly say "I've been awarded the MVP.  I can think of so many other people that are more deserving."  To be considered among such company is incredibly humbling.  I'm immediately aware of the responsibility now upon my shoulders.   

So what is an MVP & how did I become one?

According to Microsoft, this award is given to exceptional community leaders who share their remarkable passion, real-world knowledge and technical expertise with other through a demonstration of exemplary commitment.  I suppose I do that.  I'm very active with my local user group and I organize SQL Saturday Atlanta (register or submit NOW!).  I speak at SQL Saturdays all across the US every year.  I'm an Idera ACE for 2017 where they encourage me to blog, answer questions in their forums, host #SQLChat and present webinars for them.  I'm co-leader of the PASS Women in Technology Virtual Chapter and host 15+ webinars a year where women speak on technical topics and highlight women technical speakers weekly as they're speaking at different events, presenting webinars or Pre Cons.  I mentor other women to GET OUT THERE and speak.  

Know someone else that should be?

Do you know someone that does all of this and probably more?  If so, I encourage you to NOMINATE that person to be a Microsoft MVP as well.  It applies for women in business and the same holds true for being an MVP.  Once you make it through the door, it's your responsibility to drag someone along with you.  I've already nominated someone that I felt was truly deserving of the award.  

Creating a Disaster Recovery Plan

        So your boss asked for a copy of your DR plan.  Once you've wiped that deer-in-the-headlights look off your face, you realize "We've got database backup.", isn't exactly a plan.  You'll need to define what a disaster could be, document the business impact identify your limitations.  So where to you start? Well, that's the easy part. 

Define what's important... before a disaster.

    There are lots of questions to ask before you have a disaster. They're even more important before you build your disaster recovery plan.  It's essentially the WHO, WHAT & WHEN of your plan. How long can you be down & how much data you can lose. Define what data is important.  Who is responsible for declaring a disaster? Who is responsible for doing the actual recover work? Even knowing where you store your plan is something to think about now.

Who are my stakeholders?

    In a single statement, they're the people that can answer all of the questions we're asking here.  This starts with C-level execs, since they'll be the ones that have to answer to the board after a disaster.  They're also the ones that have to pay for it.  Next, identify the people that will be affected by any data loss or a system outage.  Who can't do their job? Go through each application and ask yourself "Who cares?" and then follow up with them.  Finally, talk to the people that will have to implement the DR plan: System admins, networking & security, Operations, Storage & Infrastructure, DBA team, etc.

RPO & RTO

These are terms you see thrown around in sessions, in meetings and on twitter.  The official definitions are little wordy & not as helpful as you might think.

    Your Recovery Time Objective is a way of defining how long can you be down.  Or put another way, how long until you have to come back up.  So find out how your business defines RTO and then build toward that.  Of course, this can vary based on the nature of your disaster.   Did you lose a database, an instance or did someone kick the storage out from under everything? Did you have to fail over to your DR site?  Were you the victim of a DDOS attack, either directly or indirectly?

    Your Recovery Point Objective is easily summed up by asking "How much data can you lose?"  Some systems, like payments and healthcare systems, that answer will be zero.  The approach and expense for those systems is greatly different than others.  The infrastructure, build and design will vary by a large degree when you're allowed to lose milliseconds of data versus up to 15 minutes. For slow changing systems, could you restore on Tuesday from a Sunday full backup and Monday's differential? In some instances, rebuilding is faster and easier than restoring, so be sure to explore that as an option.  

    While Execs can help you define RTO & RPO, they aren't the ones who have to make it happen.  If you can't meet their requirements, be honest. You also need to be aware of contractual obligations to external clients.  While these are out of your direct control, you should encourage sales & legal to work with you while you prep a contract.  If they're promising 5 9's in uptime but you can only deliver 3 9's, they need to know.  Use phrases like "claw back", "refund of fees" or "violation of terms".  That should get their attention. 

Building a Backup Strategy

    Start with the basics.  Now that you know how much data you can lose and how long you've got to get things back up and running, set about making that happen.  Start documenting your backup processes then put them into place across the enterprise. Make sure all of your servers are following the rules you've established.  If you can lose 15 minutes worth of data and take 2 hours to come back online, then set the schedule.  Make sure you know how to restore the tail end of a log. Here, Tim Radney [T|B] shows us how in an older blog post that's timeless.

    We're not just talking about database backups.  If you use it, you'll need it.  Defining items to backup other than databases means an end to end examination of our business.  Plan on having to recovery things like Active Directory, Application configs, development source code, external files, encryption keys and passwords.  Script out some things ahead of time like SQL Agent jobs, a create logins script, database restores, service accounts, etc.  

Building a Recovery Strategy

    Any DBA is only as good as their last restore. That means you should be doing that regularly.  You'll want to establish recovery baselines.  During a disaster, the longer something takes, the more likely you are to panic. Make sure you know ahead of time everything you'll need to do for a restore and how long you'll expect it to take.  Make sure you have copies of database backups locally and a copy at your DR site. You should know how long it's going to take to restore.  Of course, the biggest pay off to practicing restores is knowing that your backups work.  

Test your plan. 

  

    Some sage advice from Allan Hirt, "If you don't test your D/R plan, you don't have a plan.  You have a document." Document your DR plan.  Practice.  Automate. Adjust. Document. Practice again.  It's the only way to really be sure.  That being said, if your business can't support a full fail-over test, consider a tabletop test instead.  Once your plan is documented, have a meeting with all of the people responsible for recovery.  Go through each and every step of your DR plan.  Make sure every one agrees this should work.  Make sure every one understands their role.  Make sure they have all the pieces they need to put this plan into action.

    Don't just practice for the big disasters either.  Practice for those smaller disasters & disruptions.  Things like DDOS, ISP going down, a data center power outage, natural and unnatural disasters.  While these aren't directly a DBA problem, if they cause you to fail to your secondary data center, it just became your problem.  Then there are the smaller but potentially devastating events: forgetting a where clause in production, drive failure, storage corruption or a malicious insider.  A pissed off employee can cause real issues deleting or modifying data that is vital to your company.  Be prepared to do an object level restore or a side-by-side restore to recover data that may have been compromised. 

Building it out. 

    Let's be honest.  Most companies can't afford to build & maintain a hot standby environment equal to your current production.  If yours can, good for you.  Feel free to skip this section.  But if they're like many companies, DR is currently sharing real estate with staging, QA or UAT.  It's not a hot site or it barely has the processing power you'd need to run your business.  

    Identify your wants versus your needs.  Lay out what you WANT your DR site to look like and how you need for it to function. Identify how you're going to keep it up to date.  Then lay out what you NEED to have for your disaster recovery site.   I suspect the final product will fall somewhere in the middle of your wants and needs.  

    Don't forget hardware, licensing and maintenance.  Plan for enough storage space for the live databases and backups. You'll need enough web servers to run your applications.  Don't forget to factor in enough time each & the peop0le required to build this out and maintain it on a monthly basis.  You'll have to patch all those servers & keep versions aligned. 

How much will it cost you to build?  Probably less than it will cost in lost revenue, client trust and public relations.