Webinar: Auditing with Extended Events

I’m giving a webinar today, April 5th, at 3 PM Eastern, on using Extended Events to audit your SQL Servers. I’ll be covering the basics of why you should migrate from Profiler to Extended Events, what Extended Events are and how they are structured, as well as some initial use cases for you to try out and explore further. On a related note, we’ll also look quickly at how SQL Server uses Extended Events for Audit objects. If you’re interested in attending:

Register for the free webinar

Advertisements

Webinar: Identify and Eliminate SQL Server Performance Issues

I’m giving a webinar tomorrow, March 22, 2018, at 3 PM Eastern.

Free Registration Link

Here’s what I’ll be covering:

Are you struggling with pesky SQL Server performance issues that are impacting your business? Are you not sure where to turn next to focus your efforts to resolve the issue?

In this session we’ll look at what built-in tools are available through SQL Server and the OS. We’ll consider both performance and security auditing. We’ll also investigate built-in options to manage multiple servers to ease the workload. Finally, we’ll discuss how to report on the metrics and information we have gathered. We’ll conclude on alerting and notifications to keep you in the loop when something goes outside of your desired thresholds.

In this session you will learn about:

  • How to start monitoring SQL Server
  • Key scripts for SQL Server Performance Monitoring
  • Best Practices to address both SQL Server and Windows issues
  • Proactive alerting to minimize the issues to the business

Speaking at the 2018 Techno Security and Digital Forensics Conference

One of my favorite conferences is held in Myrtle Beach, SC, in June. It’s a security and digital forensics conference which I try to make each year.

This year I’ve been selected as a speaker. Here is the talk I’m currently scheduled to give:


Auditing SQL Server in Every Way Possible 

Microsoft SQL Server is in just about every enterprise and government organization in the world and it is trusted to store and serve up even the most sensitive of data. As a result, Microsoft has instrumented SQL Server in such a way that you can audit just about every action a user performs, whether it’s changing data, reading data, or manipulating the structure of the data itself. In this session, we’ll show you all the places you can turn the knobs and flip the switches in order to audit what you need to and give you some tips into getting that info into downstream systems like an SIEM. We’ll also cover if a certain feature has a SQL Server version or edition restriction, so you can determine what you can do with your current technology investment.
If you’re looking for a security centric conference at a great venue during the right season, consider attending the Techno Security and Digital Security Conference in Myrtle Beach.

Settings Goals Professionally

I was reminded of this topic after yesterday’s #SQLChat. Have you set professional goals for yourself? If so, have you set them professionally? What do I mean?

There’s a difference between a wish and a goal. A wish is something we want to happen but we don’t make any effort towards seeing it come to pass. Perhaps we can’t. I can’t be back in high school to warn myself about playing with several of the injuries that continue to nag me today. But quite a few wishes are within our grasps. We just don’t move forward towards them. The thing about a goal is that we have to decide to move towards accomplishing it. We won’t accomplish all of our goals. However, we will make attempts to accomplish each of them.

With that defined, let’s talking about setting them professionally.

First, you have to clearly outline your goal. If you’re familiar with the SMART acronym for goal setting, this is the Specific part of it. What are you trying to accomplish? How do you know when you’re successful? An example of a bad goal: I want to be happy in my job. What’s wrong with this goal? How do you know what happy looks like? Your specifics could include details about pay, about how much you work (hours is a measurable quantity), or it could be something like, “Each morning I will wake up and determine if I look forward to going to work each morning. 3/4 of the mornings for the year, I want that answer to be yes. That’s how I know I’ll be happy.” We’ve taken something abstract and made it measurable.

Second is the M in SMART, that the goal is Measurable. I’ve already given an example on specific, but we must be able to measure if we’ve accomplished our goal. We also would like to be measure possible progress. Being able to measure means we have a good idea where we stand on accomplishing a goal and what it looks like when we have met that goal. If you don’t measure, you’ll be less likely to push forward towards accomplishing your goal.

Third is the goal should be Attainable. We want it to be a goal, not a wish. I’m not going to be able to reverse time back to high school. At least, not right now. And even if I could, that might not be the best plan as my past determines who I am now. Goals should cause us to strive and stretch, but they shouldn’t be completely out of reach. Goals like that serve to discourage us, not help us move forward.

Relevance is the fourth part of setting goals professionally. Why does the goal matter to you? If the goal doesn’t matter, you won’t make it a priority. Perhaps someone has suggested something be your goal. This often happens to us professionally. Maybe there is motivation to move a goal to relevant status when it normally would not be (such as continued employment at a place where you’re “happy”). However, if you can’t see a goal as relevant to you, it’s very unlikely you’re going to put much effort towards accomplishing it.

The final part is ensuring your goals are Time Bound. What’s the timeline for you to accomplish that goal? We can define goals with no expected completion date. That’s generally not a good idea. If you do this, how do you know your current rate of progress? How do you give yourself that kick in the tail to work harder if there’s no end date? But the end date isn’t the only part of the goal. If you’ve got steps to get towards that end date, when should you be accomplishing those steps.

Got all this? Great! Now, write it all down. Put your goals somewhere you can regularly review. And then do the review. Recalibrate based on how you’re doing. Don’t let goals be like most folks’ New Year’s Resolutions. Make them something you set and achieve.

Tinker as You Learn

In recent weeks I’ve seen my brother from another mother, Andy Leonard (twitter | blog), write or post about his learning activities. In one case he remarked that he liked it when he went to complete a learning lab exercise and it didn’t work as expected the first time around. When the lab doesn’t work, you have an opportunity to troubleshoot why. You learn more than if you just are able to follow the steps perfectly. Basically, what you’re doing is tinkering. And you gain more knowledge as a result.

In a second case he was asked by a friend if he could write a quick SSIS package. Andy did. But he also spent time figuring out different ways he could do the same task using BIML. More tinkering. More learning. He had the time. He invested it.

If you think about it, this is often how children learn. They don’t start following a series of steps: 1, 2, and 3. They pull things apart. They try things you aren’t supposed to try. Sometimes it works. Sometimes it fails spectacularly. And sometimes something new is the result. For instance, I wonder how the first kid got the idea to secure a baseball card in the spokes of his or her bicycle to make that clicking sound as the wheel turned. It doesn’t matter how the kid came up with it I suppose, but it was definitely a popular thing to do. Nowadays we have little pieces of plastic that do the same thing. But the first occurrence was found by tinkering.

I know that I enjoy tinkering, even if it is with something I supposedly know well. That’s how I was able to get so deep into SQL Server security. It’s also how I learned how to read network traces to understand how DNS, Active Directory, SQL Server, web servers, and other applications communicate at the network layer. That’s how I learned to spot and understand when something isn’t right in those communications.

Don’t just be content with the checklist or 1,2,3 types of learning. Play. Tinker. Try new things. If you’re using VMs, understand how you can roll back to a snapshot and how you can apply/commit changes forward. If you know these things, you can always get back to where you were if you do have that spectacular failure. And you can also set your new starting point if you figure out something interesting or effective. But most of us, don’t be afraid to tinker.

WIT: A Quick Thought

I recently had the opportunity to be a Dungeon Master (DM) at a gaming convention. It was my first time. I loved it. So what does that have to do with Women in Technology (WIT)?


The young lady standing up also DMed her first convention. She’s my daughter and she’s 12. When we were signing up for DM slots, I asked the organizer if he felt there was any issue with her signing up to DM just like any other DM. He didn’t. She had been DMing D&D Adventurers League locally and had done well enough that he didn’t have any issue with it. 

He evaluated her on the merits of her body of work. He could have said no because she was 12. He could have said no because she was a girl. He could have said no for a whole host of reasons that had nothing to do with her ability to unravel the story, adjudicate the rules, and provide for a pleasant and entertaining player experience. He chose to judge her on her capabilities as a DM. 

When I work with colleagues, I care about their skills: technical and soft skills. I want to work with top folks so we can deliver excellent results as quickly as possible. I’m not interested in wasting time on the job because we have a less capable person that was hired and included only because that person meets some cliquish requirements that have nothing to do with the job. See, I have a personal life that’s important to me. I have folks outside of work I want to spend time with, like my daughter pictured above. 

I also want to deliver the best results I can to be competitive in the workplace and so my organization is as competitive as possible. Wasting cycles because somebody reminds me of my high school or college friends or because that person has more in common with me for non-work related characteristics than another is just plain foolishness. To do so negatively impacts my ability to stay gainfully employed and make a way for the people who are most important to me, like my family. 
As a group, the females in IT are in every work-related way as competent as men. They don’t need a helping hand. They aren’t less capable. They don’t cause problems unless folks go looking to cause issues with them. Yes, there are individual exceptions. But the keyword is “exception,” as in outside the norm and that’s true of any group of any reasonable size. 

Women should be evaluated based on their ability to do the work. And they should be compensated properly for that ability. And they should be treated properly as valuable coworkers who help us make stuff happen. They don’t want anything more than these things. It’s not hard to do these things. We only hurt ourselves and deny ourselves opportunities when we don’t do these things.

That’s what some gamers learned after giving that young, female DM a chance. At first, these gamers were skeptical. But they had signed up for those slots and wanted to play, so they did. And they soon realized she had developed the skills to be a good DM. They had fun. Difficult players were managed. The modules were moderated to be just the right challenge level and kept at the right pace. And they left with more stories about their characters and new found friends at the gaming table. They gave her a chance to compete fairly and she won them over. That’s how it is supposed to be for women in our career field, too. 

DevOps Does Not Make Admins Obsolete

As a follow up to my tweet, I stand by my belief that DevOps does not make administrators obsolete. I include Database Administrators in my statement. The core point of embracing DevOps is to determine what is repeatable and see if you can automate it. Why?

  • You’re trying to move faster.
  • You’re trying to reduce mistakes due to human error.
  • You’re trying to free up time of knowledge workers to work on more important things.

Let’s look at the DBA. Every time a DBA has to manually run a script, what is the DBA not doing? The DBA isn’t monitoring performance. The DBA isn’t checking code to see if it can be improved. A DBA isn’t reviewing audit exceptions that have hopefully been reported by an automated check. Think about the typical tasks a DBA has to do every time a new script is ready for modifying the database:

  1. Check out the new script from source control.
  2. Back up the database (possibly).
  3. Execute the script.
  4. Verify the results of the script.
  5. Report back that the script has been run.
  6. Back up the database again (possibly).

These steps, in and of themselves, aren’t hard. We expect a DBA to bring a professional eye to minimize mistakes, but mistakes do still happen (guilty as charged). What if all of that was automated? Then the DBA wouldn’t have to spend the time running through each step. As a result, the DBA is free to do so much more. The DBA can become a key player rather than someone who just executes code. That means a DBA has more time to show his or her importance to the organization. We talk about career security. Becoming a stronger knowledge worker helps move us towards that.

Which is why I say DevOps doesn’t make admins obsolete. It makes the ones who embrace it for what it is potentially more valuable to their current and future organizations.

Previous Older Entries