Author: way0utwest

  • The Best Ever

    Every few years, or every year now, we see a new version of SQL Server proclaimed as the best ever. A few weeks ago, I saw a number of people leaving hte MVP Summit, rating it as the best ever summit. At SQL Bits or the PASS Summit every year, there’s no shortage of people posting about that event being the best conference.

    Is this a human view, that the latest one is often the best one ever if we enjoyed it? Perhaps we learn something and we’re excited about the latest new SQL thing and so we’re excited to proclaim it the best?

    What’s the best SQL Server version? Is there one for you? Some of you might be new to SQL Server or have worked with few versions, but perhaps one stands out. I’ve had the opportunity to work with a lot of versions, so the choices are hard. I’ve written code for SQL Server: 4.2, 6.0, 6.5, 7.0, 2000, 2005, 2008, 2008R2, 2012, 2014, 2016, 2017.

    I have two votes here. You might like one, and likely will disagree with one. First, I’ll say that I have a fondness for SQL Server 2000. This was a stable, long awaited version that dramatically improved my life from SQL 6.5. It was more reliable and faster, and since it came after a relatively short time after v7, I ended up standardizing on this at a few jobs. Most of my upgrades were to SQL Server 2000 and it lasted a long time as the standard version. It was 5 years before SQL Server 2005 was released, an eternity in today’s software lifecycle. There were some bumps in the road (SQL Slammer), but a better security coding model came about at Microsoft during this version as well as SSRS (added later).

    My other choice, maybe the top one, is SQL Server 2016. A number of security changes (AE, RLS, etc) as well as the inclusion of many features in Standard Edition (with SP1) make this my favorite. We got stability from the second version of OLTP tables and the third version of Availability Groups. I think SQL Server 2016 was perhaps the best version of SQL Server I’ve seen.

    You might have other votes, and let me know today. Is there a version that’s near and dear to your heart.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 3.0MB) podcast or subscribe to the feed at iTunes and Libsyn.

  • Code Snippet Cove on the #SQLPrompt Treasure Map

    I’ve been away a bit in the last week with personal and family commitments. As a result, I feel a bit out of touch with work, and I have some catching up to do. However, when I ran across the SQL Prompt Treasure Island, I had to take a few minutes and go through it.

    Code Snippet Cove

    I love snippets. I first loved the idea in Visual Studio and Query Analyzer a long time ago, but SQL Prompt has taken this to a new level. I’ve used snippets quite often to make life easier and speed up development.

    This part of the island talks about all the tokens that are available. There are all sorts, but some of my favorite are using $CURSOR$ to ensure the cursor gets dropped where I want it. This lets me immediately start typing.

    I love $DATE$ and $USER$ for pre-populating comment sections of code, and there are plenty more metadata/environment type tokens that you can use, including the $PASTE$ for the clipboard.

    While the tokens are great, I think that just the Snippets themselves, with custom placeholders, such as $userrole$, which I use for adding security to object creates, are incredibly handy. I’ve even used partial snippets for joins. For one job, we constantly needed to put together  these tables: Product, ProductCategory, OrderHeader, OrderLine, and Address. We had a snippet that just contained these tables with the appropriate ON clauses for joins.

    Explore snippets, and you might never want to work without SQL Prompt again.

    In the next post, I’ll take at look at the rest of the map.

  • What’s Downtime?

    There was a time when I worked for a company that sold products on-line  Since our wares could be purchased at any time of the day or night, we wanted to ensure that our systems were running all the time. This led us to build some sort of monitoring, which we tried. That led us to buy some monitoring software, which we did. This led us to build more tools, and it felt like we were in an endless loop for a period of time.

    Eventually we stepped back and tried to answer the question that many Operations people have asked themselves and others: what is downtime?

    It’s a tough question, and I want to give you a few examples of how I’ve viewed things, and debates I’ve had. For example, we had a database server and a web server. We used a simple script to ensure that the services (IIS and SQL) were running on both machines. If they weren’t, we received a page. Is that sufficient to detect if our system is working?

    We also had a process that would ping our web server from outside the data center, using a public machine. If that works, is the system working?

    In this job, we deployed new code every week, in a DevOps style process that existed before anyone had ever uttered the term. These updates sometimes included schema changes, but almost always included application changes. If a page on our website broke after a deployment, was our system up or down?

    We integrated with some third party software to perform various tasks. There were times that we couldn’t communicate with the third party, or received broken communications. In those cases, were we up or down?

    We built our application to work with multiple browsers, but at times there would be a new piece of functionality that didn’t render or work correctly on either a new (Firefox)  or old browser (IE6). Did that mean the application was down?

    Determining uptime isn’t a single thing. Even when you provide mechanisms that ensure all parts of your application are working, are they working for everyone? Many of us might see this in various online calls, where a system like GoToMeeting or Skype might work for some of the audience and not others. I see this at times with Microsoft sites where some of us can use one of their online systems, but others can’t, sometimes because of the browser of the end user.

    I was thinking about this while researching zero-downtime deployments, which can be hard for database changes. There are people that have success, but many others don’t. At Redgate Software, we are trying to build tools to make this easier for everyone, but there seem to be plenty of edge cases that cause issues. There are also many different processes and flows that groups use to perform database development, which often affects the final deployments. It is hard to build a general solution that needs to apply to specific environments.

    I tend to learn towards measuring uptime of the systems I’m responsible for and letting others worry about intermediate infrastructure. I’ll caveat that with the note that I sometimes only worry about sections of the system and if those are broken. It’s good to be clear when talking about this topic with others. For example, we might be able to take orders, but can’t report on them, or can’t add new customers. That’s downtime for some sections of our application, but less stressful than if we couldn’t take orders.

    Let us know today. How do you measure downtime or uptime, and where is your responsibility?

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 5.5MB) podcast or subscribe to the feed at iTunes and Libsyn.

  • In Memory of Robert

    I was returning from a trip yesterday when I got an email from a friend that Robert Davis (@sqlsoldier) had passed away. Unfortunately, this happens more and more to me as I age. Family and friends are getting older and some will leave us sooner than we’d like. A Memorial and Grief fund has been set up, if you’d like to contribute.

    There are various tributes from Kendra Little, Thomas LaRock, Jen McCown, and likely a few others. Robert was a friend, and I’m again saddened by his passing. If you knew of Robert, either from reading his blog, following him on Twitter, or attending one of his talks in person, you know he was a very intelligent, humorous, and as Tom says, quite generous soul. I was honored he syndicated his blog at SQLServerCentral, but it wasn’t because of me or the site. Robert was overly giving of his knowledge, always looking to help others with their problems. He probed and questioned the questioners, trying to ensure that he could provide the best advice and solutions to others.

    It wasn’t easy, physically, for Robert to always get around, but he made the effort to attend many events in person, and help others even though it was a challenge. I was always pleased to see him in person, shake his hand, and marvel at the lengths he was willing to go in order to help others and share his wisdom and experience. Others have noted his sharp mind and amazing recall. I’ll point to the 92,800 tweets he left behind, many of which were in service to others.

    Kendra noted his New Year’s Resolutions for 2018 included more time for Robert and less work. Those are important mantras for us all.

    I encourage people to work on their brand, or their career, or improve their skills. I really want all of you to do those things. Become better craftsman and craftswomen and improve the state of our industry. I want you to work at being better. When I present this live, or even write, I do want you to always keep this in mind.

    We work to live; we don’t live to work.

    Find a balance in life, find time for family, faith, hobbies, and friends. In the last decade, I’ve lost a number of family and friends, far too many in their 40s or 50s. I’m at the age where I likely have less life ahead than behind me. Each of us never knows how many days we have left.

    Find a balance and ensure you enjoy your life along the way.

    Robert, you are missed, and I hope Chrissy finds solace and strength in your memories. Please consider contributing to the Memorial and Grief fund.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 5.1MB) podcast or subscribe to the feed at iTunes and Libsyn.