Voice of the DBA

Author: way0utwest

SSoL–Exiting Root
I don’t think most of us need to know Linux, but if you end up managing a system, it’s good to have a little idea of how to get around. This is a short series of posts as I remember the skills I used to have back in university.

There are times you need to execute a bunch of commands as root. Rather than sudo x, sudo y, sudo z, you might just sudo –i to change to root.

For example, I often will do this:
```
sudo apt-get update

sudo apt-get install mssql-server

sudo systemctl start mssql-server
```
I could just run those as root. However, when I’m done, how do I get back to my normal user? It’s been a long time, so I had to look it up. I wrote this post so I’ll remember since I don’t use Linux daily.

Type
```
Exit
```
That’s it.
July 5, 2017
Independence Day 2017

Today is July 4, Independence Day in the US, more commonly known as the Fourth of July. This is the day that the United States declared it self a separate nation from the British Empire. For most of my life, this has been a day of celebration with kids, or as a kid. A time when we cook outside, watch fireworks, and have an enjoyable day away from work. The last decade or so I’ve also re-read the Declaration of Independence, as a way of remembering the history of my country.

As I was preparing for this year’s holiday, it struck me that so often inside of companies we find groups and departments that almost separate themselves from others. We get silos and habits of working that are distinct, often because they feel that trying to work within the constraints of others’ requirements is too stifling or non-productive. Unlike the U.S .Declaration of Independence, I’m not sure that most of the people that work separately could list a defined set of reasons why they work by themselves.

As I talk about and promote DevOps, the one fundamental action needed for success is communication. Disparate groups need to work together, from architecture to development to business analysts to QA to operations. Every person needs to provide help and feedback to other groups, being willing to modifty the ways in which they work to smooth the out the entire process.

In other words, we need to work together.

I hope that as you move forward in building software for your company, you learn to work with others, finding ways to smooth out the process to deliver valuable features and functions to your customers.

And if you’re in the US, have a great Fourth of July.

Steve Jones

July 4, 2017
Backup Preparations

I’m sure that many data professionals recognize the importance of having backups in the event of some issue. Many of you will schedule these as soon as you create a database, and then not think much of the process, ignoring it as long as the backup job continues to run.

As you gain experience, you may even set up backups on new instances and versions without much thought, assuming you know how the process works. That’s probably true of SQL Server, as the backup system and structure hasn’t changed for years. However, do you think backups work the same on other platforms, such as Oracle, PostgreSQL, or MySQL? What about MongoDB or Neo4j? Don’t we just run the backup command to a file and the restore from file sequence if there is an issue?

Backups aren’t the same on all platforms, and they may function differently enough that you can find you aren’t prepared for a disaster situation. I was considering this over the last week as I read about the challenges of restoring from Azure SQL Database and Amazon RDS. With the popularity of both cloud computing and SQL Server, we have a few different flavors of platforms between on-premises installs, AWS, Azure, and likely other hosted solutions.

Whenever you work on a new platform, even if it’s a variant of one you have experience working with, there is a chance that the techniques and commands you run to manage backup or restore will change. Since a restore situation is often a stressful event, with the pressure of an RTO upon you, this isn’t the time to learn that your backup preparations are inadequate.

As much as I might joke about ensuring your resume is up to date in case of a restore problem, I would emphasize that your resume isn’t going to be as helpful if you are negligent and unprepared because you haven’t done everything you could to be ready for a disaster. While your employer might not allocate enough disk space or other resources to ensure their RTO and RPO can be met, you can certainly ensure that your skills, knowledge, and recommendations aren’t the reason that data is lost.

I periodically practice restores, I’ll take a tail log backup, I’ll ensure that I understand how to export a BACPAC, all to be sure that my skills are up to date. I don’t want to encounter a situation where I need a filegroup, point in time, or striped backup restore and not know what I’m doing. You might want to do the same, taking time every month to ensure that you perform some different restore technique. Just in case disaster strikes next week.

Steve Jones

July 3, 2017
Replication Silliness
I wrote an editorial asking about things that needed to be done to improve replication. There are plenty of things that need help, but as I was testing some replication, I got this the other day.

I am trying to setup a secure home network (other than the same password for a few services to make life easier). I have firewalls running and open specific ports for SQL Server. In this case, I have multiple instances on this machine, so I opened a port for a named instance. I didn’t want the SQL Browser running, and connected with the port.

These are all valid connections for the server:
- Atlas,51433
- Atlas\SQL2016,51433
- Atlas.home.xxx.net,51433
- Atlas\SQL2016
- 192.168.1.201, 51433
- 192.168.1.201\SQL2016, 51433
Guess which ones work? Only the name/instance.

Perhaps I’m doing something wrong, or there’s a setting, but this is a bit silly that valid connection strings with ports don’t seem to work with replication.

Especially after seeing this:
July 3, 2017