Daily Coping 1 Oct 2020

Posted on October 1, 2020 by way0utwest

I started to add a daily coping tip to the SQLServerCentral newsletter and to the Community Circle, which is helping me deal with the issues in the world. I’m adding my responses for each day here.

Today’s tip is to release yourself from inner demands and self-criticism.

I know a lot of technical people that aim high in their lives. They want great code, they want smooth running servers, they want financial prosperity, they want bigger and better jobs, and success for their families. All things that can help drive someone forward in their lives.

However, it can be detrimental to your mental health to compare yourself to others at a point in time and evaluate your success by theirs.

I was thinking about this after hearing a friend talk about the challenges of recording a session for an upcoming conference. In this case, the person asked if I was getting a green screen, new mic, or any other improvement to my setup for the event. This individual felt pressure because so many speakers have been talking about OBS, StreamDeck, and other devices.

I wasn’t,  and I’m not. I certainly could improve things, but I need to decide what matters for me. I think what some people are doing is interesting, and I do think there might be ways to better build content and engagement for audiences, but I’m not driven to match what others do.

I try hard to set some goals, make plans, and work towards them, but I recognize that things go wrong, life gets in the way, and I need to both acknowledge when I make mistakes and can do better, while also accepting I may miss some milestones. It doesn’t do my any good to beat myself up inside.

Two quotes I keep in mind here:

  • Man plans and god laughs – Yiddish saying
  • Life is what happens when you’re busy making other plans – John Lennon

The latter reminds me to keep moving on, and do things. Not just plan.

Posted in Blog | Tagged , , | Comments Off on Daily Coping 1 Oct 2020

DR as a Service

Posted on October 1, 2020 by way0utwest

It’s not the first task when I start a new job, but often as a DBA or developer, I usually ask about Disaster Recovery (DR) plans sometime within the first six months. If I’m a DBA, of course I need a plan. If I’m a developer, however, I still need to understand how this might work as it can affect how I build the software and prepare for networking, machine changes, etc. Even if I don’t concern myself with production DR, I usually do want to make sure the VCS repos are being protected, which is something I’ve found isn’t always being handled.

I have had to build and test DR plans as a member of an Operations team in the past. While my plans and practice are nothing like Google’s large exercises, they often reveal some issues, even when we duplicate the service without touching production. I’ve usually found the brainstorming and debating of the various ways to build a plan to be fun. Arguing for money and then actually implementing plans is less interesting, but the testing is a great challenge. I’ve had some fun days offsite where we try to recover systems and find all the little things that we take for granted in our production environment.

These days there are companies offering DR as a Service (DRaaS), which is an interesting concept. I found an article from Michael Otey that talks about the features you might want to look for if you contract with a vendor. In the past, I would never consider this, but the more we advance in the world with cloud infrastructures and even full service co-location vendors, the more I think DRaaS makes sense.

I wouldn’t necessarily take anyone’s word that their service meets my needs, so thinking about the requirements, and then working through a few PoCs (proof of concept) is likely very important. We do a lot of PoC work at Redgate to help customers evaluate whether Compliant Database DevOps is a good fit. I think this is important for software development, but even more important for DR plans. After all, downtime is expensive, and the last thing you want to find out when troubles arise is that some critical piece of infrastructure can’t be easily duplicated.

I’ve used DR companies in the past, with their own physical facilities. They have impressive capabilities and marketing, but the mixing of their skills with my systems has often been rocky and lead to changes in our plans, contracts for new or fewer services, and often updated documentation for junior staff. After all, I usually expect DR situations to occur when I’m on vacation, so I plan for that.

You never know when you’ll need to execute DR plans. It pays to think about this ahead of time and periodically test yourself and your staff.

Steve Jones

Listen to the podcast at Libsyn, Stitcher or iTunes.

Posted in Editorial | Tagged | Comments Off on DR as a Service

Running Express Edition in a Container–#SQLNewBlogger

Posted on September 30, 2020 by way0utwest

Another post for me that is simple and hopefully serves as an example for people trying to get blogging as #SQLNewBloggers.

Recently I was looking through the forums and someone had a question on JSON and the Express edition of SQL Server 2019. I was sure JSON worked, but I also didn’t have Express set up on my machine. I decided a container would be a quick way to test this.

I’ve started lots of containers, but I rarely do anything other than the Developer edition. I know you can set the edition, but didn’t know how, so I had to look it up. This post covers the quick way to do this.

Environment Variables

There are a lot of environment variables that we can use to configure containers, and SQL Server in particular. There are two that are required:

  • ACCEPT_EULA
  • SA_PASSWORD (or MSSQL_SA_PASSWORD)

These two need to be supplied to start the container. Beyond that, you can add others that are useful for you.

To run as Express, you will want to MSSQL_PID variable, which can be set to any of these:

  • Evaluation
  • Developer
  • Express
  • Web
  • Standard
  • Enterprise
  • A product key

For my situation, this means I run Express like this:

docker run -e "ACCEPT_EULA=Y" -e "SA_PASSWORD=password" -e "MSSQL_PID=Express" -p 51433:1433 --name express2019 -h express2019 -d mcr.microsoft.com/mssql/server:2019-CU7-ubuntu-16.04

This starts up a new container, and I can connect, where I’ll see the correct version.

2020-09-14 11_15_49-SQLQuery2.sql - .,51433.master (sa (55))_ - Microsoft SQL Server Management Stud

SQLNewBlogger

It took me about 5 minutes to get this working, and then it was a question of writing this post and capturing an image. I had the code, because I’d just used it.

Overall, a good way to show a few things about containers and SQL Server, and a skill that an interviewer might ask about.

Posted in Blog | Tagged , , | Comments Off on Running Express Edition in a Container–#SQLNewBlogger

The Value of Metadata

Posted on September 30, 2020 by way0utwest

A long time ago, nearly two decades ago, I had a manager come ask me about metadata, specifically, what it was. This was a technical manager, who understood software well but wasn’t a data expert. I tried to explain data about data, but at that time, the world primarily dealt with client-server type technologies, with data being something that was primarily about a think. Metadata like types, scales, etc., weren’t seen as that useful. Descriptive items, like we might store in the MS_Description extended property, were rare.

Today, we use metadata quite often, and I think in many ways we’ve “consumer-ized” metadata with tagging and other structures that let the users of our software add descriptive attributes to the data they store in our systems. In some sense, we get metadata at a deeper level, almost the row or cell level from actual users, as if we were tracking column or entity level markers.

There is a lot of value in this metadata, both to the technical staff and to business users. This article talks about the value of having detailed metadata for data scientists and similar roles, where understanding the meaning of the data can be very valuable. The more focused data scientists and analysts can be, and the easier with which they can find data, the more productive they can be.

At Redgate, we work with customers all over the world, but it’s outside the US where we’ve seen the value of metadata grow. Primarily in response to the GDPR, we find many business people want to know about their data, it’s meaning, it’s sensitivity, and really, the risk of data loss. This has expended into our Data Catalog and Data Masker products, which exist to help organizations keep track of their data. It’s a big job, one that isn’t fun, and often has debatable value when starting from the beginning. It can be a large time sink when one person has to track down the meanings of all the data in databases. It’s also not a very interesting job.

Many find, however, that knowing this information can be quite useful when it’s available. Archive plans, decisions on masking data, even choosing technologies for protection become more focused when you know what data you have. We continue to research and work on finding ways to improve the help software gives users in applying this metadata, as do many others. Privacy and compliance have driven a lot of work in this area, but potentially data science, data lineage, security, and more could find ways to use this information in all our organizations.

The one thing I think is important is that we maintain this information as a part of our regular work. Customers might do some metadata work themselves (which can be extremely valuable information), but asking most people to classify and tag lots of information is a mind-numbing job. It’s better if we can tag sections of data as we add features to software, whether as developers, or someone else as a part of the software process. That way, when someone goes looking, most data is already partially tagged.

Steve Jones

Listen to the podcast at Libsyn, Stitcher or iTunes.

Posted in Editorial | Tagged | Comments Off on The Value of Metadata