Tag Archives: sqlserver

Back in 2013 I attended my first PASS Summit. I was a first timer and Bill Fellows was my “big brother.” I had no clue what I was getting myself into. This is my story on how I became a speaker.

At my first summit, thanks to Bill, I was meeting people just about from the moment I got there. Bill knew lots of people. He’s tall and bald and hard to miss. And wears shorts. Everywhere. Regardless of temperature.

Where was I…oh yeah…speaking. While at summit that year I met and talked to many people. A few of them asked me “Have you ever thought about speaking?” I politely replied that I hadn’t, but I really wanted to ask them if they had forgotten their medication that day, or if they needed to be examined by a professional. Me – a speaker. LOLOLOLOLOLOL! Bless their hearts!

But then I thought about it. Why not speak? What would I talk about? What was something cool that I had done that people would want to know about? Could I do this? I showed people how to properly gift wrap a present in speech class (oh yes I did…and there is a right way…and you’re probably doing it wrong) – could I teach them something that would actually have some career benefit?

Yes. Yes I could.

I started to think about what I could talk about. I submitted a session to a SQL Saturday event later in 2013…and I was not selected. I didn’t know it at the time but I had picked a topic that was rather niche and would not have a real following. I found this out when I went to the event (yes, I still went…I was going to this one regardless) and talked to the organizers. This also allowed them to know who I was, so when I submitted again, they would be able to put a face with the name.

The following year I submitted a panel to a different SQL Saturday…and they picked it! This allowed me to get my feet wet while having some other more seasoned speakers there to help drive the conversation. In the weeks leading up to the event, we met and ironed out the details of what we would talk about. During those meetings I learned a lot from them, and they helped make that first session for me a success.

As a speaker, there are good days…and not good days.

A few months later I did my first solo session – and it did not go well. This was a tough pill to swallow. What happened? Simply put, my session didn’t reflect my abstract. I was disappointed in myself. It takes a few days for me to get over things like this, but since this was my first solo attempt, it really made me question whether or not I wanted to do this. Could I be good at this? I went home and re-wrote the session. Then looked at it and re-wrote it again. The next time I gave this session it went much better, and my feedback reflected it.

I love things that challenge me. Speaking does this, and does it in ways I would have never imagined. It takes me out of my comfort zone. No matter where I am for the foreseeable future, I will be speaking.

Speaking has taken my love of learning new things to the next level. Not only am I learning for the sake of a problem or making a business case for something, but now I am learning with a goal or being able to facilitate the learning of others. When I refine my skills, my session material gets better too.

My passions have found an outlet with speaking. It’s thrilling and sometimes frustrating. When you are speaking you never know what’s going to happen. Sometimes you have a lot of questions from the audience. Other times you have none. Sometimes you don’t know the answer. As much as you practice, it doesn’t change the fact that as many times as you give a certain session, no two of those are alike because no two audiences are alike. The one thing that is consistent is that the more times I am able to speak, the more people I am able to reach and help improve their SQL Server skill sets or adopt a new skill set with PowerShell. I don’t know where speaking is going to take me, but for now, I’m down for the ride to find out.

If you are interested in speaking, and would like to find out more, here are a few blog posts I found on this subject.

For this T-SQL Tuesday we are asked to look into our crystal SQL Server ball and predict what will be happening at the time of T-SQL Tuesday #200. I went to the garage, dug that thing out, cleaned it up, and boy it had a lot to say!

Assuming we’re all friends here, and there is some fun to be had with this…

T-SQL and JSON had a baby. All queries in SSMS resemble a hybrid of the two languages.

SSDT has been replaced by VSDT. Nothing has really changed but the acronym. As always, you can still expect some things to break when you do updates.

Microsoft bought NHibernate. You still have all the same issues as before but now you post them to Microsoft Party (it replaced Collaborate…after that replaced Connect) and actually watch them not get fixed. And you can’t post work-arounds in MS Party (so it’s not much of a party).

MS NHibernate still generates SQL queries that are long and redundant, but it’s not handling the TSQL-JSON baby very well. So there’s that.

Microsoft acquired ActiveBatch and it is now called SQL Server Batch and has replaced SQL Server Agent for scheduling jobs in SQL Server 2026. Consequently, companies have been reluctant to upgrade from SQL Server 2023 (especially the ones that have used ActiveBatch).

For the companies that are upgrading, they have found that calling PowerShell scripts from scheduled tasks to be a good way to bypass using SQL Server Batch. Increase the in the demand for DBA’s with extensive PowerShell experience sky rockets!

The rumors back in 2018 proved to be unfounded – DBA’s are still in high demand. All the talk of SQL Server tuning itself turned out to be DTA 2.0.

Microsoft brought back the MCM. And then killed it again the next year.

Azure has been replaced by Rainbow. Data is no longer in the “cloud” – it is in “rainbows.” Pricing is based on the colors of the rainbow and the color names are garnet, citron, lemon, lime, azure, and violet.

PASS still exists. Due to some bylaw changes, elections have not been held since 2019. Grant Fritchey [B|T] is still president and attends meetings remotely from his nursing home.

Just kidding – Grant’s not in a nursing home. That’s just where he says he is. There was some backlash when PASS did away with SQL Saturday events. Grant’s really in witness protection and goes by the name Thomas LaRock [B|T].

Thanks to Adam Machanic [B|T] for hosting the T-SQL Tuesday this month, and for coming up with this whole thing to inspire all of us to write more and continue to share knowledge. While there was absolutely no knowledge in this post, I do hope that I got a giggle from at least one person.

When performance issues rear their pretty little heads I tend to look at the simplest things last. I am the person who is looking at the code first – because in many cases, if your code was better we wouldn’t be having this discussion. Whether it’s a series of nested views or one single user-defined function that doesn’t play well with the optimizer, there is usually something in the code itself that is contributing to the performance issue.

But what about the times when it isn’t the code or you can’t touch the code (I’m looking at you NHibernate…and all of your red-headed step-child offshoots and fellow ORMs). What about the cases when the poor performance situation only occurs periodically, or once a week on the same day, every week, and while you can see the slow-downs in your queries, and all of your waits and plans, the source of the problem isn’t any particular smoking gun – it’s lots of guns, firing off at random times, and the casualties are in your interfaces that depend on the data from the queries.

The one thing I don’t immediately go to is UPDATE STATS – and I should be looking at this. It’s something easy to run and if you still have issues, you have ruled it out.

Over estimation on rows = bad times for the optimizer.

In this case, I ran UPDATE STATS on one table in particular and immediately saw a marked improvement in my test query.

Ahhhh….much better.

This morning I ran the same query and things were back to where they were with performance. This was somewhat disheartening, but the troubleshooting must continue.

But what about auto-update stats? Is this on? Yes, but auto update statistics is only going to update based on a percentage sample of the records in the table. If your table contains millions of records, you may not be updating your statistics sufficiently to see an improvement. I am updating statistics with a FULL SCAN of the table. For larger tables, this may take some time, but you may also see a difference in your execution plan versus only updating statistics based on a sample.

In an effort to rule out whether or not statistics are definitely a factor, I want to UPDATE STATS on all the tables in my query, and at a specific time – sometime the day before we expect our slowdown to occur. I also want to be able to easily see how long the process ran and the duration of the update for each table. I could write all this to a table, and maybe I will do this later, but viewing this from job history is what I want right now – it is easy to look at and easy for everyone else to find and see as well.

Creating a job with multiple steps can sometimes be a bit painful and tedious, if the job is going to have A LOT of steps. With PowerShell, a server name and a database, I can dynamically create this job.

PowerShell

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60

61

62

63

64

65

66

67

68

69

70

71

72

73

74

75

76

77

78

79

80

81

82

83

84

85

86

87

88

89

90

91

92

93

94

95

96

97

98

<#

Name: create update stats job for specified tables.ps1

Author: Amy Herold

Date: 8 February 2018

Purpose: With a specified server, database and list of tables, create a job to update stats.

The result from this is a job that will update statistics on your list of tables, one at a time. All you have to do from there is give it a schedule.

All those steps…courtesy of the magic that is POWERSHELL!

For this script, I was getting my list of tables based on a specific query that was problematic. If you are doing this for a stored procedure, you can query for the list of dependent tables instead, and instead of hard coding the tables in this code, pass in the name of your stored procedure and get the list that way.

I hope if you have a situation where some one-off stats updates are needed you find this script to be useful. As always, comments and feedback are appreciated. 🙂

When I was growing up I remember my mom talking about an old, scary, movie that she saw when she was young. In the movie some teenagers were making prank phone calls saying “I saw what you did and I know who you are.” One of the calls happened to be made to a guy that just killed his wife. Joan Crawford played a woman that was romantically inclined to said murderer. She eventually meets her demise when he stabs her because she knew about the first murder.

How every DBA feels when there is blocking

While blocking in SQL server might not be a felony offense (it isn’t…but it should be – WHO’S WITH ME?) as the DBA you not only want to know what is being blocked, but also who is doing the blocking and what in the H-E-Double-Hockey-Sticks they are doing.

At SQL Saturday Orlando I talked about this very thing and the query I defer to for the information.

IMA GONNA HUNT U DOWN!

It might look complicated but it is actually very simple – query sys.sysprocesses with a cross apply using the sql_handle to get the text of the query, and then an outer apply with the same query again but you are joining to the blocking spid so you can get the text for the query that is doing the blocking. Beyond that, you can filter on various columns and refine your output

WHY ARE YOU BLOCKING YOURSELF? WHY ARE YOU BLOCKING YOURSELF? WHY ARE YOU BLOCKING YOURSELF?

Of course, I know you can’t run this without the code (and I know that’s why you’re here…because I SAW WHAT YOU DID!)

Transact-SQL

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

SELECTx.textASblocking_text

,x.nt_username

,x.nameASblocking_db

,st.text

,a.nt_username

,d.nameASblocked_db

,a.status

,a.*

FROMmaster.sys.sysprocessesa

INNERJOINsys.databasesdONa.dbid=d.database_id

CROSSAPPLYsys.dm_exec_sql_text(a.sql_handle)ASst

OUTERAPPLY (SELECTblock.text,aa.nt_username,aa.spid,dd.name

FROMmaster.sys.sysprocessesaa

INNERJOINsys.databasesddONaa.dbid=dd.database_id

CROSSAPPLYsys.dm_exec_sql_text(aa.sql_handle)ASblock

WHEREa.blocked=aa.spid)x

WHERE1=1

--AND a.hostname LIKE 'SOME-HOSTNAME%'

--AND a.program_name LIKE 'Some program name%'

--AND a.dbid = ????

--AND a.spid IN (???)

--and a.status not like 'sleeping%'

----AND (st.text LIKE '%text string you want to isolate%')

---and a.blocked != 0

--AND (a.nt_username LIKE '??????%')

If you are looking for a good way to troubleshoot blocking I hope this helps. If you have some folks running queries that are making you stabby, run this, find out what is going on, and then remove their access try to help them so they aren’t making you stabby any more. Then tell them they need to buy you a beverage because they are still alive.

Next week I am returning to Orlando not only to visit the mouse at his house, but also to speak at SQL Saturday Orlando! Last year was my first time there and I had a great time. This also happened after the event was pushed back to November 2016 because of Hurricane Matthew.

This year I will talking about deadlocking and blocking – something that is an issue for so many DBAs. Whether this issue is indexes or bad code…or you have been trying in use indexes to cover up bad code, blocks and deadlocks can happen in even the best environments under the right circumstances. If you are going to be at SQL Saturday Orlando come to my session where we will talk about detecting and preventing these arch enemies of the DBA!

I’ve been teaching my 17 yr old SQL Server and other various topics. I have quite a bit of experience training technology and speaking but it never fails; after about 5 minutes his eyes glaze over and he nods and “umhums” and then starts checking his phone.

I have one nephew that is already intrigued by the PowerShell that I am doing and seems to have a genuine desire to write code. This makes me SOOOOOOOO HAPPY! My hope is that he is able to continue what he is learning now and migrate into a skill set that will afford him a good career. And if he happens to maybe “hack” into something that he shouldn’t have, I will help with his bail, smother him with hugs and kisses and tell him “OMG…I AM SO PROUD OF YOU!!!”

Check out Daniel’s blog post, download the game and give it a whirl. I plan on showing my nephews this to get the opinions of the younger, not-a-teenager set. I doubt my niece will be interested in this right now…unless there was a Disney princess in there with the sea monsters. I will leave it to Daniel to incorporate that in the 2.0 version. 🙂

This Saturday will mark the fourth year that I will be speaking at SQL Saturday Baton Rouge at LSU. Out of all the SQL Saturday events I have participated in since 2014, Baton Rouge is one of the few that I have been to every year since. Houston is another one…and actually, these may be the only ones only because they have had an event every year.

Not only am I speaking on Automation with PowerShell and Deadlocks and Blocking, but I am also participating in a panel discussion on Careers in IT. I’m excited to be invited along with some of the other speakers to be a part of this. Looking back on my own school days, I knew I would have a career in IT, but little did I know I would detour from a path in development to the world of SQL Server, and becoming a DBA.

How do they make this happen? Work. Lots of hard work. After helping with SQL Saturday Dallas 2015, joining the NTSSUG board in 2016, and then having an organizing role in 2016, I found out how much goes into the planning of these events. If you have attended a SQL Saturday or you are going to in the future, be sure to say “THANK YOU!” to all the organizers and sponsors. If you want to get more involved in the SQL Server community, SQL Saturday is a great way to do that – just show up at the event, find an organizer and tell them that the SQL Kitten sent you to be their humble servant volunteer for the day…or you could just say you want to volunteer and leave out the other stuff because it might make it weird.

Recently I had the pleasure of meeting Carlos Chacon with SQL Data Partners and found out he had a podcast (I know…I live under a rock…with cats). He asked if I was interested in being on said podcast – ummmm…yes, please! Click here (Episode 33) if you wanna go listen to the podcast or here if they get all up in your grill about streaming stuff at the office and you wanna just read the transcript. Thanks to Carlos for the opportunity! Enjoy! 🙂

Since I have not blogged in a while, and I saw it was T-SQL Tuesday, I thought I would participate in this FOR THE FIRST TIME EVER! This month SQLBalls asks us if our SQL Servers are on the naughty or nice list. Since I have recently transitioned to a new role, I am still getting familiar with the servers and the environments I am working with. The servers of my past are but a memory, but a fresh one. I cannot even begin to think of all the different “naughty” things that were done on those servers, and how some days it felt like a losing battle. How can you fight a security or code change when you have been over ridden by management, only to have that change come back and bite you weeks or months later? The “I told you so” you might feel like popping off will fall on deaf ears and you will just be stuck fixing the problem…until it gets to be too much and you decide it is time for action.

I have done this before. The day had been a long one and I thought I was finally going home when I got drug into a call on a data issue – something was changed that shouldn’t have been. When and by whom? I didn’t know or have any way of finding this information (days later when I tried to get a backup that was several months old to validate this data from when it was deployed; there was no backup – all all – but that is a completely different issue for another time). I had my suspicions but no proof. Could have been a naughty developer elf logging in with an elevated SQL account they knew the password for. Changing the password? “Out of the question” they say. It is everywhere.

If this were the only event that had happened THAT DAY. It wasn’t. This one was production (hence the conference call). The others (yes, more than one) were pre-production. Messes that had to be cleaned up because the developer elves thought they knew better than the DBA and that they could do it on their own. This production issue was the last straw. Elves were running a muck and had to be reigned in, and they weren’t going to like it.

All the elevated permissions in the pre-production servers – gone. I didn’t care if it was a DEV server. Am I the meanest DBA in the world? So says some. Scrooge? Well, if you are into name calling and want to go there, then ok, but I get to call you names too. In this case I did not care – I was fixing things that were only broken because someone abused a privilege. It should also be said that there was some relation in the names off all the tables involved with all the issues that occurred on this day.

If I had to wag my finger and any naughty part of the SQL Server instances it would have to be at security…and I am partially to blame. It can be difficult to keep up with all the changes that happen across a large environment when it comes to assigning permissions, and if you have more than one DBA, the situation is compounded by the fact that you might not always know what the other is doing and vice versa. They might grant something that you would otherwise veto for cause. You might take care of a permissions issue one way when they would handle it differently.

While I worked on some Powershell code to pull back users from specific AD groups and incorporate alerts for some of those groups, sadly the bandwidth was not there to fully roll this out. I did however create some triggers that would send email alerts when a change was made at the server and database levels, and I made them nameless and encrypted.

SET@mailbody=&#039;The following change has been made to the &#039;+@database+&#039; database on &#039;+@servername+&#039;:&#039;+CHAR(13)+CHAR(10)

+&#039;Change Made By: &#039;+@adding_user+CHAR(13)+CHAR(10)

+&#039;Event Type: &#039;+@event_type+CHAR(13)+CHAR(10)

+&#039;Server Name: &#039;+@servername+CHAR(13)+CHAR(10)

+&#039;Database Name: &#039;+@database+CHAR(13)+CHAR(10)

+&#039;Date/Time: &#039;+@datetime+CHAR(13)+CHAR(10)

+&#039;SQL Statement: &#039;+@command+CHAR(13)+CHAR(10)

EXEC msdb.dbo.sp_send_dbmail

@profile_name=&#039;DBMailProfile&#039;,

@recipients=&#039;alert@yourcompany.com&#039;,

@body=@mailbody,

@subject=@mailsubject;

END

The lack of a name for each of these is intentional, as is the encryption. The last thing I wanted was someone seeing these ans what they were doing, and if they had permissions to do so, disabling or dropping them to avoid having their nefarious behavior tracked. Even better would have been to put additional triggers in place to prevent the dropping of these no matter what, but I decided not to go there.

Note there is nothing there for the name for each of these – this is courtesy of the devious mind of Rob Volk. He might have too much time on his hands but this is pretty darn crafty. What you name these triggers is up to you but you have to MAKE NOTE OF WHAT THE NAME ARE!!! When I did these they were a combination of a few tabs and spaces – like “space space space tab tab” but with those actual characters. The result looks like this:

It should go without saying use this code at your own risk and always thoroughly vet and test anything before applying it to a production environment.

If this helps further cement my meanest DBA creds then I guess I am doing it right. Sometimes the elves developers can get out of hand and it is up to Santa the DBA to make sure they know they are being watched.

I have now officially submitted to SQL PASS Summit 2015. Five sessions. All me (well, and a few others on the panel I submitted). The hard part is over…but how did this all happen?

My story starts back in the year 2013. My first time to attend a SQL PASS Summit. It was in Charlotte, NC. I didn’t know these were normally in Seattle. It didn’t really seem to matter too much either. I was a first timer. And they labeled me as such.

I didn’t mind. I knew I was a newb. I embraced it. I signed up for and watched the webinar for first timers put on by Denny Cherry. I also got a first timer buddy (aka Someone I can follow around like a puppy until I am comfortable enough and have found other suitable, like minded, people that will welcome me and allow me to accompany them to places that sell beer).

I met so many new people while at Summit that year and out of all the conferences I had been to in the past, this was by far the best experience I had ever had. One this that happened numerous times when talking to people was hearing the words “Have you thought about presenting?” I’m all “Wow…these people are nice…and encouraging…wait…presenting? Say what?”

Did they need fresh meat? A new crop of willing yet unsuspecting folks to throw their hat in the ring, to hopefully be selected, and dive head first off that cliff into something that might become an obsession that would challenge them in ways they had never thought of before? Maybe. Maybe they did. Maybe it was a little cultish. Well, pass the kool-aid.

I came home and gave it some thought. I really wanted to do this but did not know where to start. I felt like I had stuff to say. Stories to tell. Experiences to share. But where to start? I decided I would do a panel. I rounded up some experienced speakers for a particular SQL Saturday, created my session and submitted it. That was the easy part. I then decided we would have weekly internet video chats so that everyone could get acquainted, and I could get their take on how they saw the panel going. They were also able to provide me much needed guidance with my slide deck (something else I had never done before) and how the session needed structure. I took all this in and did my slides accordingly.

The time finally came for the SQL Saturday event and my panel session. I made the trip out there and met up with everyone. I attended my very first speaker dinner. I could not believe I was there and in the same room with some of the brightest and well known minds in the SQL community. This was it – my first taste of what would consume that entire year.

The panel went well. My fellow panelists and other patted me on the back for a job well done. Feedback was good. I was elated. I was hooked. I thought I was ready to handle what was up next – my first solo session. Just me and my slides. Another SQL Saturday. Another city.