Category: T-SQL Tuesday

T-SQL Tuesday #108 – Logic Apps & Cognitive Services

T-SQL Tuesday #108 – Logic Apps & Cognitive Services

For this 108th edition of T-SQL Tuesday, Malathi Mahadevan (b|t) has come up with a wonderful topic – non SQL Server technologies. As the Microsoft data platform continues to expand, our jobs as data professionals are requiring us to learn and embrace technologies outside of the traditional relational database platform. After spending last week at PASS Summit 2018 and being reminded again about the amazing diversity of the SQL Server/Microsoft Data Platform ecosystem, this topic seems especially well-timed. Nicely done, Mala!

The non SQL Server technologies that I’ve selected for this post are the pair of technologies that have been oddly involved in my life for the last year or so: Azure Logic Apps and the Cognitive Services API. I was fortunate enough to be selected to speak about these topics at PASS Summit this year and it’s been a strange journey from, in a little over a year, never having heard of Logic Apps and Cognitive Services to creating training for them and speaking in the community about them. Long story short, I heard a Men in Blazers podcast last October where they jokingly mused about ranking English Premier League teams by the supporters’ feelings rather than actual results on the pitch. I had recently read some logic apps blogs from Brad Ball (b|t) and thought I could take what I learned from those and turn it into the “mood table” that was discussed on the pod. If you’re interested in the technical details of what I did, click here and read my blog from last year about how I did it. That post also links to a deep dive post with even more detail.

That post, and the mood table’s weekly appearance on the podcast for months, set the table for me to begin presenting a logic app and Cognitive Services session at PASS community event and non-PASS technical meetups as well. That drove me to better understand the power of logic apps and what else I can do with them with or without wiring in Cognitive Services as well. I submitted that session for this year’s PASS Summit and it was selected so I dove into these topics even further in order to build a robust 75-minute session.

The story behind my initial effort for the podcast and how that turned into a session brings us to today. What are my plans for learning more about this? I’ve partnered with a company on some logic apps training and will release that information when the course is released. There is a possibility of building onto that course with a subsequent advance course. Creating that training content forced me to really dig into some concepts within logic apps and cognitive services that I was not very familiar with from just my “playing” with these technologies for the mood table. It’s also really opened my eyes to just how powerful logic apps are for coordinating workflows for real companies with real data flows (not silly soccer-related podcasts :-)). I’m looking forward to integrating Azure Logic Apps and Cognitive Services with customer work in 2019 so customers can see how useful Logic Apps can be when moving and transforming their data. Cognitive Services can offer huge value to customer-facing departments such as customer support and marketing. I can’t wait to begin talking more about these technologies with my customers and learning more about them as we work together.

T-SQL Tuesday 99: Racing Brings Me #sqlibrium

T-SQL Tuesday 99: Racing Brings Me #sqlibrium

Thanks to Aaron Bertrand (b|t) for hosting this month’s edition of T-SQL Tuesday, the 99th in the blog party series, and for an interesting topic choice for this edition. You can find Aaron’s T-SQL Tuesday #99 introductory post here, but Aaron gave us a choice this time around: share a passion of ours with the SQL community or write about a favorite/most annoying T-SQL bad habit. While I gave some thought to the technical post, I couldn’t turn down an opportunity to talk about my love for racing and how much I enjoy getting to actually drive a race car a few times each year. Since thinking about, talking about, and planning for racing does help bring some balance to my life, #sqlibrium as Drew coined the term, let’s talk for a few minutes about how cool (and yes, relaxing) it is to drive race cars once in a while.

“There are only three sports: bullfighting, motor racing, and mountaineering; all the rest are merely games.” – Ernest Hemingway

I was a big enough racing dork when I was a kid that I had a t-shirt with this on it when I was in elementary school. I honestly don’t remember a time in my life when I didn’t want to look at, read about, or drive race cars. However, if this post turns into “Matt waxes poetically about racing”, it will be about 5,000 words long and incredibly boring to everybody but me. Put much more simply, while a lot of people look for relaxation from a good hike or a relaxing day on the beach, my beach is at a racetrack. Whether I’m watching the cars, working on them, or driving them, it has a way of clearing my head unlike anywhere else. For the sake of brevity(-ish), I’ll focus the rest of this blog on my on-track exploits, such as they are.

File_003

As you can see, we take this racing stuff quite seriously. The picture is of me waiting on the grid at Indianapolis Motor Speedway in June 2017 before taking to the track for the first of two races. The grid marshals thought it would be funny to give us silly umbrellas to block the sun while we waited – and it was.

That said, this picture does a decent job of showing what my Formula First looks like up close. For those that are interested in the technical specs (which is likely very few of you), the basics are that Formula Firsts are 1600cc air-cooled Volkswagen engines mated to purpose-built open wheel chassis riding on Hoosier R60 tires. Hoosier has been a great sponsor of our U.S. Formula First Championship, which is a 5-6 weekend series that is currently in its 12th year of competition this year. We run at great tracks all over the eastern half of the U.S., from Road America in Wisconsin, to Watkins Glen in New York, to Road Atlanta in Georgia. If you’d like to read more information on the series (and see some great videos), the link is here.

Now that we’ve covered the basics of the car and the series that I race in, you’re probably wondering “what cool stuff have you done in these cars, Matt?”. Now, some of you asking that question may think cool stuff is “what have you won?” and others may think cool stuff is “what have you crashed into?”. I’ll cover both angles before we wrap up this blog, but if you’re just here for the crashes, here’s a picture of a crash I just missed at Indy last year (thanks to Brian Schell for the image).

indy_crash_edited

First, what have I won? I’ve been fortunate enough to win trophies and take podiums (finishing in the top 3) at places like Indy, Watkins Glen, and Road America. Road America (in Elkhart Lake, WI) was my favorite race track (other than Indy) growing up and it still is, which makes this next story particularly frustrating even though it happened 12 years ago. After doing a couple weekends in 2005, I committed to running a full Formula First season in 2006. I went to Road America in the top 3 in championship points and was looking to have a great weekend. I qualified 2nd for the our race on Saturday but, near the end of the first lap, the right-front suspension spectacularly came apart, ending my day quite early and giving my right hand a gnarly bruise to boot. I went into Sunday morning’s qualifying hopeful but still frustrated and qualified 5th – then a clutch problem reared its ugly head towards the end of the session. That sent the crew into a massive thrash to get the clutch replaced, an effort that was completed just minutes before we had to head to grid for the race.

Once the race started, the car was really good. I could run comfortably in the draft and started picking off cars and working my way up the order. With 3 laps to go, I passed for the lead and was leading for the first time in my career! The other driver and I traded the lead (and fast laps) back and forth over those last few laps and, on the last lap, I exited the final turn (turn 14) in the lead. I didn’t get the best launch off the corner, though, and the other driver had a run on me. I put on a within-the-rules blocking move but ended up losing the race by roughly the length of the nose of the car. I was crushed, especially as my wife and dad were there to see it. The picture below was taken just after the race while the top 3 finishers waited in line to make sure our cars met minimum weight. I’m still in the car chatting with the guy who beat me. My wife, as you can see, was not thrilled with the loss (she’s a bit competitive)!

roadamerica_2006_postrace

Our series’ next race that season was at Nelson Ledges in Ohio, and after a solid finish during the Saturday race, I was involved in a nasty crash near the end of Sunday qualifying. I was hit from behind by another driver after sliding through the first turn, and that contact resulted in his left side tires bouncing off my roll bar and then my helmet and him flipping end over end numerous times. The impact cracked the shell of my helmet, so I was incredibly fortunate to only be checked out for a concussion and treated for bruises and scrapes – that could have been far, far worse and it really put the previous race’s frustration into perspective. It did not, though, knock any sense into me and I’ve continued racing through the years (except for a break when the kids were born) as time and budget allowed.

I could go on for hours, but this ~1000 words is long enough. As I said, the racetrack is my beach. I love it and it must be in my blood, because I don’t remember not loving it. Based on the picture below (taken after my 3rd place finish at Indy in 2017), one of my kids might end up writing this same blog post in several years’ time. Thanks for reading – hopefully I’ll see you at the track.

indy_podium_kids

tsql2sday-300x300

 

T-SQL Tuesday #93: Shock and Subtlety of Sexist Interviewers

T-SQL Tuesday #93: Shock and Subtlety of Sexist Interviewers

First of all, thanks to Kendra Little (b|t) for hosting this month’s T-SQL Tuesday. This month’s topic (Interviewing Patterns & Anti-Patterns) is a great topic that’s generating a lot of interesting responses from many different perspectives. Beyond that, I’ve seen Kendra present at PASS events and various webinars and she presents deep technical content in a very engaging way. Definitely check out her blog and follow her on Twitter!

As for my submission to this month’s blog party, I was excited to cover the original topic I had for this post – “Interviews Aren’t Trivia Contests”. I may still blog that at some point, as I believe I’ve definitely improved as an interviewer and would like to pass along some things I’ve learned the hard way so you don’t make the same mistakes I have.

That said, a couple of conversations I had at SQL Saturday Louisville this weekend changed my mind on my post for this edition of T-SQL Tuesday. Hearing women discuss the subtle and overt sexism that they have to deal with in IT is always jarring and it prompted me to relate an interview story from my wife. Even though my wife has been in technical fields her entire career and I’ve both managed and worked alongside women in IT, hearing these types of stories is always jarring, upsetting, and thought-provoking. This post is most certainly about a couple of interviewing anti-patterns, as you’ll see below.

While my wife is currently in IT (she is a PMP-certified project manager specializing in software delivery and implementation), this story dates from 2012 when she was interviewing for a ceramic and materials engineering position in the Midwest. She has a B.S. in Ceramic Engineering, an M.S. in Materials Science and Engineering, and has her name on at least one patent and multiple academic papers. Long story short, she was indisputably qualified for the position for which she was interviewing.

Anti-Pattern 1: Subtle Sexism

This interview, as many others are, was a series of one-on-one meetings with folks in HR, on the technical side, and points in-between. There had been nothing particularly noteworthy until she interviewed with a guy in a very senior technical position. After a few minutes, he asked my wife a seemingly innocuous, albeit cringe-worthy, question (but more on that in a bit): “how does a woman get into engineering?”. My wife explained her interest in and aptitude for math and then a little more about what drove her specifically towards materials science and engineering.

Anti-Pattern 2: Shocking Sexism

His response was “interesting, most women who get into engineering are more flat-chested.” This is the part of the blog where you should hear a record-scratching noise in your head as you’re shocked by what you just read. Sadly, the few times I’ve relayed this story over the years the women I tell are not nearly as surprised as the men I tell. It goes without saying that this is an interviewing anti-pattern of the highest order. It’s sexist, demeaning, crude, lawsuit-worthy at best, and illegal at worst.

Summary

But I said I’d take you back to the seemingly innocuous question, as over the years it’s troubled me nearly as much as the obviously horrifying commentary on my wife’s figure during an interview. “How does a woman get into engineering?” As one of my wife’s friends said, the proper response was “the same way a man does”. The subtlety of this is perhaps more insidious than the overt sexism of the crude comment, as the implication is “why are you here, you don’t seem to belong?”.

If you take anything away from this post, I want it to be this sentiment: as an interviewer, that candidate across the desk/phone from you is there because they believe they’re qualified for the opportunity and want to work with you and your company. Everybody’s career journey is different, but the subtle or overt implication that because they don’t fit the stereotype in your head they don’t belong there is simply unacceptable. Not only could you be costing your company the best candidate for the position, you may plant a seed in that person’s head that takes them years to overcome or puts them off their chosen career path entirely.

To end this on a positive note, this did not have a negative impact on my wife’s mentality and she’s fantastic at her current job. I still wish she would have slapped the guy, though!

 

 

T-SQL Tuesday #87 – The Roundup

T-SQL Tuesday #87 – The Roundup

First of all, a sincere thanks to everybody that took the time to contribute posts to this month’s T-SQL Tuesday (#87) – Fixing Old Problems with Shiny New Toys. I realize the time it takes to put a post together, so thanks for participating and helping the community.

Secondly, I couldn’t decide whether or not to call this the “rollup” post or the “roundup” post, but since I’m in Texas this week for work, “roundup” won the day. If you think I should have gone “rollup”, by all means email Adam Machanic (amachanic at gmail dot com) after taking a look at the T-SQL Tuesday hosting rules, agree to host a month, and call your summary post whatever your heart desires!

On a personal note, one of my goals for 2017 was to be more disciplined about blogging and this has gotten that initiative off to a solid start. I highly recommend hosting/participating in T-SQL Tuesday and hope you’ll return here to read my regular posts as the months and years go on.

Finally, as a first time host, I was obviously hoping that this topic would garner some responses, but you never know until you hit that post button whether you’ve selected something of interest to the community or not. Thankfully, this month’s topic picked up views from over 20 countries and over 20 blog responses. The list (with a brief post-by-post commentary from me) is below. Happy reading and thanks again for reading/writing/participating!

This Month’s Responses

Row Level Security – Steve Jones provides an intriguing solution using very new toys (SQL Server 2016 and/or Azure SQL Database) to solve a very old problem (users seeing data they shouldn’t).

Fixing Old Security Problems with Shiny New Toys – Duncan Greaves reviews four new or new-ish security features that you need to understand (and should probably be using).

SQL Server 2016’s JSON Functionality – Bert Wagner details JSON support in SQL Server (from community support to official support) and some use cases for it as well.

Calculated Tables and Role-Playing Dimensions – I was really pleased to get a few responses on SQL Server topics outside of the database engine. My colleague Ginger Grant provides a blog that’s guaranteed to save a few SSAS users some hassle.

Data Theft and Backup Encryption – Mark Southall provides a fascinating object lesson on how useful it can be to encrypt your backups. This one should give all of us something to think about.

Server Level Database Permissions – Kenneth Fisher gives us a great reminder that server level database permissions exist and that they make our lives easier.

Solving the Net Changes Problem with Temporal Tables – Adam Machanic (thanks again for letting me host!) gives us a detailed look at how we can use temporal tables (a shiny new toy) to potentially replace the functionality of change tracking (a less shiny, older toy).

String Splitting – Aaron Bertrand gives us a look at string splitting in SQL Server 2016 along with a bonus look at the STRING_AGG() we’ll see in SQL Server vNext.

Granting Read Permissions on Everything! – Shane O’Neill gives us an interesting look at easily granting read permissions to users.

STRING_SPLIT – My colleague Steve Hughes gives us another look at one of SQL Server 2016’s hidden gems.

New Way to See Wait Stats for a Single Query – Robert L Davis gives us a great look at how to zero in on the wait stats (including the worst offenders) for a single query.

Beware Shiny New Toys – Wayne Sheffield turns my topic on its head and warns us about the danger of blindly trusting shiny new toys.

Better Index Maintenance in Maintenance Plans – SQL Cyclist shows us the improvements in index maintenance tasks within maintenance plans.

Where Did My Backup Compression Go? – Garry Bargsley gives us a great look at backup compression on TDE databases in SQL Server 2016.

Angle Brackets vs. Curly Braces – Riley Major reminds us that not everybody has these shiny new toys but that there may be some different ways, in older versions, to approximate the way some shiny new toys (like JSON support) behave.

Using AT TIME ZONE to Fix a Report – Rob Farley gives us a great new solution to solve those brain-bending timezone issues for reports and other query-driven datasets.

Providing Data to Customers More Quickly – Jens Vestergaard gives us an interesting look at how SQL Server 2016 SP1’s performance improvements (and an Azure VM) provided the horsepower to generate data that had been previously requested but whose generation used to take far too long before now.

Power BI in SSRS – James Anderson gives us a look at a cool new innovation in the BI realm of the SQL Server world: Power BI in SSRS 2016.

Musings on SESSION_CONTEXT() – Ewald Cress takes a deep dive into SESSION_CONTEXT(). Great, in-depth thoughts here.

Temporal Tables – My colleague Bob Rubocki gives us a blog version of his well-received temporal tables webinar. This is a good, easy-to-understand walk through this shiny new toy.

Performance Tuning Out of the Box (tempdb) – Björn Peters gives us a good look at the tempdb configuration options Microsoft included in SQL Server 2016 setup. Although I took 3+ years of German, I had to break out the English translator for his one, but it was awesome to get responses in multiple languages!

Two New Useful DMV Columns – Rodney Landrum points us to a very convenient way to check whether or not two important configuration options are set without having to fire up Microsoft Management Console.

 

 

 

 

 

Announcing T-SQL Tuesday #87 – Fixing Old Problems with Shiny New Toys

Announcing T-SQL Tuesday #87 – Fixing Old Problems with Shiny New Toys

T-SQL Tuesday is a monthly blog party for the SQL Server community. It is the brainchild of Adam Machanic (b|t) and I am thankful for the opportunity to host this month’s edition. The concept is straightforward – each month a blog hosts the party and everybody who wants to contribute can write a post about the topic that is selected.

I’ll get into a few more specific rules at the bottom of this post, but first let’s dive into this month’s topic!

This Month’s Topic: Fixing Old Problems with Shiny New Toys

While the SQL Server ecosystem is constantly evolving, it seems like that evolution has sped up considerably in the last year or two. From the constant improvements in Azure, to the rapid changes in Power BI, to the powerhouse release of SQL Server 2016 last year, those of us whose professional life resides within the SQL Server world have a multitude of new tools in our toolbox.

What I’d like to see from the blog responses for this T-SQL Tuesday is how you’ve used a “new” Microsoft data platform toy to fix an old problem. We’ll define new toys as something from SQL Server 2014’s release date until now. We’ll even accept a SQL Server vNext response if you’ve got one!

Did you work around a database design/performance issue by using memory-optimized tables and natively compiled stored procedures (brought to us in SQL 2014)? Did you use Power BI to present data visualizations to a client in a way you couldn’t have previously? Did you use SQL 2016’s mobile reporting ability to extend SSRS reports to a mobile client and solve an issue that way? Did you solve an archival issue by stretching your database into Azure? Basically, did you solve a data problem with a cool new Microsoft data platform toy?

I think many of us settle into old habits when it comes to solving problems with our data, so I can’t wait for the responses to this topic to see what cool new things people are doing to solve some old problems.

The Fine Print (aka The Rules)

  • Your post must be published between 00:00:00 UTC and 23:59:59 UTC on Tuesday, February 14th (yes, feel free to throw a Valentine’s joke or two into your blog)
  • Include the T-SQL Tuesday logo in the top of your post and link your post back to this one (preferably via a comment on this post, but a trackback is OK as well)
  • If you’re on Twitter, tweet your post using the #tsql2sday (if you’re not on Twitter, get on it!)

 

T-SQL Tuesday #84: Growing New Speakers

tsql2sday-150x150Thanks to Andy Yun for hosting this month’s T-SQL Tuesday #84: Growing New Speakers. This is a topic near and dear to my heart as I made my first presentation at SQL Saturday 531 in Louisville, KY in August. Since I’m a rookie, I’m not going to pretend that I have any brilliant tips for new speakers beyond the ones that I am sure are being shared throughout the community today. You should definitely practice your demos, you should definitely practice your speaking, and you should definitely go watch other experienced speakers to see how they approach a session, how they handle the room, and how they manage questions. However, none of that matters if you don’t commit to speaking and presenting to the community and that is where I want to focus this post.

Speaking in front of a group of people is not something that comes naturally to me. I am, as some in the community are, a bit of an introvert. I don’t come charging out of bed in the morning fired up to speak to a large room full of people. That said, I am fortunate enough to work at a place where I am encouraged to share my knowledge with the community. While that encouragement is important, my first session taught me two important things.

The first important thing that I learned is that any real world experience you have is useful to the community. While you may think something you are doing is boring or old hat to everybody, it’s not. Everybody is in a different place in their career journey and could be receptive to the information you have to share.

The second important thing I learned is that the community of SQL Server data professionals is full of wonderful, supportive people. Even if it’s not your natural inclination, volunteer to speak. Beyond that, if possible, go to the speaker’s dinner and introduce yourself to people. You may glean some knowledge, you may make some important networking connections, and you may even make some friends.

As I said, some or all of this may not come naturally to every single one of us. In my experience, it’s worth forcing yourself through that wall and out of your comfort zone and presenting to the community. In fact, my experience was so positive I volunteered to do it again and will be presenting two sessions at SQL Saturday 552 in Lincoln, NE on Saturday, November 19. Come see me and introduce yourself!

 

T-SQL Tuesday #83: Can’t We All Just Get Along?

When the topic for this month’s T-SQL Tuesday was announced here, it really got the wheels turning in my mind. So, in the spirit of this month’s topic, here is my spin on the official topic: “In the 10+ years I have been a database professional, we’re still dealing with a lack of communication between DBAs and developers as well as DBAs and operations staff”. In other words, can’t we all just get along?

tsql2sday-150x150

Let us go ahead and separate this into two sub-topics: DBAs not talking to developers (and vice-versa) as well as DBAs not talking to operations staff (and vice-versa). While the consequences of each communication gap may be different, in my mind the solution is the same in both cases.

First, both when I was an operations DBA and now that I am a data platform consultant, I would consistently talk to DBAs who say “I don’t need to understand the applications running on my server(s), I just need to keep the lights on.” While that may technically be true by your job description, that will cause two problems, one for that type of DBA and one for the team with which they’re interacting. The problem for the team is that any performance and/or design guidance the team requests from that DBA will be, at best, misguided or, at worst, destructive. Blindly offering generic database advise or approving index or code changes from the team without the DBA(s) having a thorough understanding of the impacts truly does a disservice to the team being supported and will likely eventually lead to the team turning to Google/Bing for “expert” advice rather than their internal DBA staff. The problem for the DBA can be much more significant – if all you’re doing is keeping the lights on you are A) replaceable as you do not have much specialized knowledge and B) replaceable because your job may be automated or outsourced.

Second, I still talk to some database professionals who proudly declare their agnosticism regarding the servers their databases reside on, the network rails their data rides, and the storage their data uses. While I understand this decision, especially given the always-increasing amount of things “SQL Server people” are supposed to know, my experience in a lot of middle of the night phone calls over the years is that “I don’t know” is not a popular answer when it’s 3 AM, there’s something wrong with “the database”, and the company’s creeping ever closer to violating an SLA if the issue isn’t resolved ASAP.

I do understand our frustration, as a data professional, when a non-technical person accuses “the database” of being broken when what’s actually down is the SAN, the network, the battery backup on the UPS during a power outage, etc. That said, this is where having some basic knowledge of the system you support can go a long ways. If your answer to the manager called into the fire alarm call and demanding a response is “I don’t know” that will not reflect well on you. If your answer is “there doesn’t appear to be a SQL Server issue but let’s look at <storage, network, etc.> because I see X in my monitoring tools” that will not only bring about a faster resolution of the issue, most likely, but it will show those up the chain from you that you are a professional who thoroughly understands the environment you’re supporting.

The solution to all these issues is simply this: communicate. In a very real sense, the developers, the DBAs, and the network/storage/operations folks are all in this together because if the application you’re coding/refining/supporting runs into significant issues it can put everybody’s career at risk. Even if management doesn’t realize this and doesn’t facilitate the communication, make it happen for yourself and your colleagues. Break bread with them, have a beer, setup inter-departmental lunch and learns, or just ask them what’s new in their field or if they got any shiny new toys at work. I’ve done all of these things and seen them all work. Even if all else fails, maybe try this after receiving appropriate responses from all parties:

grouphug

Feel free to contact me on Twitter with any follow-up questions or comments. Thanks for reading!

T-SQL Tuesday #080: Change Always On Endpoint Ports

T-SQL Tuesday #080: Change Always On Endpoint Ports

Thanks to Chris Yates for hosting this month’s T-SQL Tuesday (https://chrisyatessql.wordpress.com/2016/07/06/t-sql-tuesday-080/)! This month’s topic is fairly broad (a SQL-related present so I wanted to put together a quick post whose information definitely would have saved me some time if it had existed a few years ago.

birthday_present

I’ve seen this particular Always On issue occur at two different customers. Both would occasionally have issues where one (or more) of the replicas would fail to restart their communication within the availability group. The error message was usually something like this: The Database Mirroring endpoint cannot listen on port 5022 because it is in use by another process. 

In a large, complex corporate environment, the DBAs may not always have permission to run the netstat commands necessary to figure out what application is “stealing” the port. Even if they’re able to figure out which application is causing the port conflict, it may take a fair amount of time to change that application’s behavior.

Since a communication failure within an AG is usually a “hair on fire” kind of event, a quick fix may be desired. The quickest fix I’ve found is to change the port on which the AG endpoint is listening. While the Microsoft help pages on this contain enough information to put together the right script eventually, the first time this happened to me I really would have liked a blog post specific to this issue that gave me the right script to use.

In keeping with this T-SQL Tuesday’s theme, below is my SQL Server present. Please note that I used 5023 as an example but your choice can be flexible depending on what else is consuming ports on your machine. Hopefully this helps somebody (or me if I manage to travel back in time and encounter this same issue):

ALTER ENDPOINT [<endpoint name>]
STATE = STARTED
AS TCP (LISTENER_PORT = 5023)
GO

ALTER AVAILABILITY GROUP [<AG name>]
MODIFY REPLICA ON ‘<replica name>’ WITH (ENDPOINT_URL = ‘<server name>:5023’)
GO

If this post helped you and you live in the Louisville, KY area, please consider registering for SQL Saturday 531 on August 6, 2016 and attend my Always On session there – you’re guaranteed to get what you pay for since SQL Saturdays are free!

Thanks for reading! This weekend I’m competing in rounds 3 and 4 of the The Hoosier Tire US Formula First Championship Series at Mid-Ohio Sports Car Course so I’ll be interrupting the SQL Server stuff usually posted here with some news about my first event of the 2016 racing season.