This article talks about how to stop or terminate a process that is running. Stopping a process shouldn't be the first step when troubleshooting as it can possibly make the situation worse.  However, it can sometimes be helpful in clearing blocking chains or other performance issues.  

In order to know what to stop, you will need to know what processes or queries are running.  There are a variety of ways to see all of the processes or queries running right now, including the following:

• Microsoft built in tools - sp_who and sp_who2
• Click here for Kendra's explanation on sp_who2
• Adam Mechanic's tool - Who is Active (Click here to download it)
• Click here for Adam's documentation
• Click here for Brent Ozar's 5 min video tutorial video
• Hand made query using the sys.dm_exec_requests and/or the sys.dm_exec_sessions tables

KILL

Once you know the session ID (spid) of the query or process you want to stop, you can do so by using the KILL command.  The kill command is pretty straight forward. The syntax is simply: KILL spid  (replace the text "spid" with the number of the process desired to be stopped)

A word of caution here, there are times when it is best not to kill a session. One example is if a process has been running for a while and using multiple threads, when it is killed, the rollback operation will only be single threaded. Therefore, the rollback could take much longer than letting the process finish on its own.  All of the same performance issues and/or blocking will still continue, so it actually could things worse, not better.

Some processes are not able to be stopped: per Microsoft, "System processes and processes running an extended stored procedure cannot be terminated."

UNIT OF WORK ID

The kill command can also be used to stop or terminate orphaned distributed transactions. The GUID value that is the Unit of Work ID (UOW ID) can be found in either the error log, the MS DTC monitor, or the sys.dm_tran_locks dmv.

The syntax is simply: KILL uowid

WITH STATUSONLY

While I knew about the kill command, I wasnt aware that you are able to check the status of the rollback process with the WITH STATUSONLY option until semi-recently.

The syntax is simple KILL spid WITH STATUSONLY - or - KILL uowid WITH STATUSONLY

For processes that are in the middle of being rolled back, this will show the status of the rollback. This option doesn't "do" anything, it just shows the progress. Keep in mind that as with other Microsoft provided durations, it isn't an exact number. This is more of a ball park figure that might be semi-right, but may also be a bit off from the actual time.

If you run this option on a spid that isnt part of a rollback, it wont hurt anything. You will just see an error returned indicating a rollback isnt in progress.

Its funny, but whenever I have to kill a process (which is thankfully rare), I cant help but do a bad-guy cackle in my head... lol!

When Doug Purnel (blog) and I became accountability partners, we had to define our goals and share them in order to keep each other accountable.  I wrote out my goals, but hadnt shared them until now (its March).  One of my goals was to find a new job and when I submitted 1 application in January, I didnt expect it to be the job I accepted (and then move out of state and start my new job all within 1 month)!

Now that things have calmed down, I am publishing my goals to everyone.  I will update this main post with links to the other blog posts I create as I complete these goals.

This month's T-SQL Tuesday is being hosted by Adam Machanic (blog | twitter) - Looking Forward 100 Months. He aims to stretch our thinking and calls us to think about what is to come.

I decided to have a little fun with this one (after all Adam bolded that part of the sentence didn't he?). When I read the invitation, and Adam mentioned some people might want to go slightly more science fiction than science, my brain exploded with excitement! Then, I re-read it and picked up on that it was supposed to be a post that might be given in 2026 (8 years or so from now) - I kind of popped my own bubble. I couldn't talk about invisible implants created to give us an edge, or everyone having a pocket assistant robot, etc. One idea, though, still seemed possible to me.

Part of our job in IT involves working with other people. Some of us work with other DBAs, others work with infrastructure folks, some end users, management, etc. Some of the people we talk to are technical, and some arent; some know what they are talking about, and yet others just think they do. One of the biggest things I find absolutely wonderful about our sql family is that the intention of most of us is honest and genuine, and that we are interested in helping others and doing our job well.

Many times, I will fall into a trap (that I lay myself I am sure) where my genuine intent and/or sincerity is not taken into account. Due to office politics, I may be viewed in a negative way, such as come across from a defensive posture, intimidating, or as a threat. My intentions in most cases are pure and I just want to be able to help solve the overall problem in the best way I know how. When some meetings are over, emails starting to fly around, I end up in a situation where someone is vying for more power, has a different idea, or doesn't agree, etc., and next thing you know I am seen as ___(fill in the blank)___ (the bad guy/ not a team player/ a bottleneck).

With the improvements of Siri/Galaxy/Alexa, and devices that can do fairly specifc things such as being able to tell why a baby is crying, my thought is, that at some point in time, I would love to see a device invented which can help read the intentions of others. Many people can read human "signs", such as being able to spot a lie. There are even professions which rely heavily on reading people, such as criminal profilers, or those who play poker much better than me. We are definitely putting enough science into the psychology of human behaviour and such to make it possible to understand the motivations behind actions.

The optimist in me sees this as a wonderful tool to help bring people together and solve the world's problems. I can see where people who are shy or who are interested in working with another group but are hesitant, would be able to trust each other more with such a device! Imagine some of the solutions that could be devised when people from different cultures or walks of life, could actually work together instead of constantly distrust each other.

My thoughts drifted back down from cloud 9 to the relevance in my job, and I could see teams of people working together to come up with incredible solutions to business processes. A device such as this, would help cut through office politics (SOME) and help identify people who are sincere in their passion/dedication to solving issues. While there would still be discussions which from the outside look like shouting matches, because multiple passionate people in the same conversation invokes "interesting" debates, the difference would be, when they walk out of the room, they understand that their ideas were being bounced around by others who are just as invested and genuine as they are.

Then, I started thinking about all the data that this device could produce in order to analyze. Imagine the dashboards and reports that could be built to show how someone grows as a person throughout the interactions they have. By interacting with people with more of a positive nature, we gravitate towards more creativity and productivity. Many psychologists "know" these things, but we would have more data to help prove it.  Of course, I would be remiss if I didn't point out that all of this data could be used to make robotics more human-like as well.  By having a deep understanding, and lots of data to back it up, we could end up with robots that are hard to distinguish from humans.  Although, to be honest, if you want any sci-fi movies and such, it is already on the table.  Therefore, by the time this device rolls out, it is already in place anyway. :)

Yes, the realist in me understands how every device can be learned to be "fooled" or tricked. I realize that a single device isnt going to turn some situations into rainbows and lollipops. I also realize that some people would use this as a way of targeting easier prey and such. In this blog post, though, I am wanting to focus on the positive potential (and forget the bad stuff since I am not in the high-tech engineering field and dont have to worry about creating it myself).

All in all, I know that there are ways of reading people now, and there are skills that I can learn to help out in many situations. I also know how much learning would go into that and want something to help in a much more immediate future. :) I realize I kind of went off the deep end and took the idea to "have a bit more fun" in a way that probably wasnt exactly what Adam intended, but thats the beauty of this - its my blog! lol :)

I had the honor of presenting for the SQL Saturday here in Tampa this year.  I was really looking forward to meeting everyone!  I recently took a new position at a new company in Tampa, and moved literally days before the event.  With all the excitement of the move and being chosen as a speaker, it was a very exciting month!

I cant express how great it was - the staff was helpful and cheerful; the overall energy for the event was great.  I will be submitting to speak at the event next year as well!

In the Dec 2017 #tsql2sday blog chain, the author asked about learning goals (my response is here). I really loved reading all of the other responses! For me, coming up with goals isn't the hard part, but following through on all of them is. I start strong, and fizzle out...

When reading Doug Purnell's response (here is his post), he specifically mentions wanting to find others to help keep him accountable. I took the quiz he mentioned, and no surprise to me, I am also an Obliger. That gave me a great idea: I wrote Doug an email and asked if he wanted to work together to help each other! I will admit, I was a little nervous about writing a virtual stranger, but it helped that I had read his blog before and had seen his name while in the #sqlskinny twitter group a couple of years ago. When I emailed him, I started out with saying "I know we dont know each other, but...". :) I explained how I had heard his name, but then just asked straight out if he wanted to work with a stranger.

Luckily he said yes! We decided to meet every other week to help keep each other accountable for the goals we have set for the year. On top of that, we also decided to bring in someone once a quarter to help keep us even more accountable too. There are many people in the community who are open to "mentoring" others if they have the time. We chose 4 people, one for each quarter, so that each person is only having to commit to a 1 hour meeting, once. That will help us not only be accountable to each other, but also to someone else. So far, 3 of them have said yes, and I am anxiously awaiting the response from the last.

I wanted to write this blog post because early in my career when I wondered how to find a mentor, I thought there was a way they would find me, or maybe there was a way to sign up somewhere and it was arranged, etc. In reality, many times you just reach out to someone and ask for what you want. In addition to that, you can check out your existing work relationships. In looking back over the last 20 years, I realize I have had some mentors along the way, I just didnt "label" it with that term specifically. In the #tsql2sday blog chain for Nov 2017, the topic was who made a difference in your life/career. I listed 3 people and none of them were someone I have thought of with the term mentor, but it does actually fit.

I have been enjoying having Doug as an accountability partner. I almost didnt get a chance to write and post a blog recently (one of my goals is to blog twice a month), but was very excited to be able to email him when I finally got it done in time! I will make sure to post from time to time as things progress to give an update on how things are working out. Make sure to follow Doug on his blog too: sqlnikon.com

This month's T-SQL Tuesday is being hosted by Arun Sirpal (blog) - Your Technical Challenges Conquered. I love how Arun wants to jump in at the start of the new year and talk about something we have conquered... it really sets the tone for the year!!

While this isn't the most challenging thing I have ever done, it was (and still is) something I am proud of.  For my post, I am writing about a scenario that stretched my boundaries on planning things out well in order to come up with a robust solution.

My company provides visits to patients in their home, hospice care, or long term care in an acute care setting.  We have multiple facilities throughout the USA.  The vendor of one of our EMR systems creates a separate database for each facility.  Therefore, the vendor currently has 40+ databases for our company.  For reporting and analysis needs, we needed to bring a copy of the data into our data center.  Of course when the business asks for something, they want it right away.  The easiest and quickest way was to set up log shipping.  Discovery led us to realize that the end result would be used by the etl team for importing into the data warehouse, the reporting team for ad-hoc reporting, and the application development for various custom built in-house applications.  Therefore, on top of the log shipping, I also needed to make things easy for them to pull the data in a consistent way, without them having to keep up with new agencies and change connection strings, etc.

When thinking about the project as a whole, I knew I had the following requirements:

• agencies would be added as we transition them from another software to this EMR
• agencies would be added as we acquire new companies
• vendor folder structure which held the backup files was a root folder and every database had its own sub-folder
• handle issues that arise for one or multiple databases without interfering with the other database restore processes
• report on the "up-to-date" date for each database when users ask (there will always be someone who doubts the data is up to date because they dont see something they expected)
• combine/aggregate all data into a single database so that data can be queried in a consistent manner
• encryption process needs to be included in order to have the files encrypted in transit (even though using SFTP) and at rest

After planning, then polishing, then throwing that away, then planning some more, then polishing some more, etc., my end result is something that flows fairly well.  I have a table which lists all of the databases, the folder where the log backups are, a flag to indicate "PerformLogBackups" and a flag to indicate "AggregateData".  I have a decent sized script which queries a list of all of the databases which need to be updated, copies the encrypted file off the SFTP server onto a file share (just in case...), and then moves the file to the SQL Server local drive.  Then, it decrypts all of the files, and loops through each database and restores each file in order.  Once all of the restores are completed, another job runs which aggregates the data into a single database for reporting needs.  Lastly, it cleans up the files and sends appropriate notifications.

The table which holds the list of databases solves the requirement of new agencies added easily.  It also solves the scenario if issues arise with some, not all databases, by toggling the flags appropriately.  If a certain database is having an issue, toggling the flag will stop it from being restored, but others will continue as normal.  Easy peezy... lemon squeezy...

I have checkpoints in the process, which will be covered as a topic in an upcoming post, and presentation.  Also, I still need to do more, just to make it even more well-rounded and hardy, but that is another reason I am writing about it today - it is still ongoing!  I love the idea of having something that works but that I can tweak and polish to make it better and better.  After all... is anything ever really done? :)