Voice of the DBA

Author: way0utwest

SSoL: Adding disk space with a repartition

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.

While working with some SQL Server 2017 tests, I ran out of disk space. I tend to size my VMs around 40GB, and that works for some things, but I’ll run out of space.

I needed to expand the VMWare disk. That doesn’t mean Linux sees the space directly, and I had to figure out how to make the partition bigger. I could have added another disk, but I wanted to work through this process. I learned I needed to have an inactive partition, so I download gparted on a live cd and booted to that.

Next I started working through a few of the tutorials on Linux partitions. This one on AskUbuntu was helpful, as I ended up having to move my swap partition to the end of the disk.

GParted isn’t completely intuitive for a Windows guy, but I muddled through it.

Once I had the operations I wanted, I applied them, and partitions moved.

I rebooted, and checking the main partition properties, I had space.

Now, back to SQL Server on Linux.

August 1, 2017
The Second Best Job

I think I have one of the best jobs in the world. I get to run SQLServerCentral, focusing on the Microsoft Data Platform, writing articles, experimenting with technology, speaking at events, and more, all with a bit of autonomy. I’ve been doing this job for well over a decade, and I’ve built routines and rhythms that have allowed me to balance work, family, and life. I really enjoy my job with Redgate.

Redgate also runs Simple Talk, a companion site that seeks to educate and inform the community, just like SQLServerCentral. Simple Talk runs somewhat longer pieces and has fewer newsletters, but it’s a part of Redgate’s effort to give back to the community and help our current and future customers get better at their jobs. And now, we’re hiring a new editor for Simple Talk, which means the second best job in the company has an opening.

This isn’t necessarily the easiest job, and it does take a certain kind of person. I’ve told many people for years that almost anyone versed in SQL Server could do my job for a few days, but few could do it for a month. Or maybe, few would want to do it for a month. Producing new content on a regular basis, handling some of the tedious duties of an editor, these can be difficult tasks for many people over time. Even managing yourself (we need an independent self-starter) can be a challenge.

We have a great team in marketing, and Redgate is a fantastic company. The highest praise I can give them is that they have been the kind of company I’d want to build if I were to start a new venture. There are great benefits, you can work from home and work with autonomy. Plus, you get to work with me.

We need good technical skills, strong communication skills, and someone that wants to help grow the site even further. If you think this might be your kind of job, think about applying. Who knows, maybe the second best job could be yours.

Steve Jones

The Voice of the DBA Podcast

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

August 1, 2017
Auto DevOps

As much as I like DevOps, this scares me. There are a lot of employees (20%) at BMW that are software engineers. They want to increase that to a larger percentage, which I assume means that we’ll have more and more code in our automobiles, with more systems tightly integrated. We’re even gathering more and more data in modern vehicles. Maybe there are good database job opportunities for some of you with automakers.

If there’s one thing we’ve learned in a few decades of writing software, it’s that large monolithic systems are a mess. They contain vulnerabilities, and more importantly, they are very difficult to patch and change. All of the DevOps success stories I’ve seen from large systems have either been a complete rewrite, or a long term refactoring that removes dependencies and tight couplings between modules.

In cars, we’ve seen all sorts of hacking issues. Hackers can attack a vehicle remotely and a faulty (or hacked) update might leave you in trouble. Granted these things aren’t that likely, yet, though I think this piece understates the potential problems. I think that because once a hack is discovered, how sure are we that a) it will be reported to vendors (hackers might just exploit it), or b) that a fix will certainly be developed that works well and doesn’t cause any issues (remember 10s of millions of lines of code current year cars), and c) consumers will apply the patch. That last item worries me, especially if cars become more connected and share data about operation or as we move to autonomous (semi- or total) vehicles.

Personally I’m not against code in vehicles. I’m not even against some connected systems. What I am against is a monolithic, tightly coupled system. I don’t want engine control or drive by wire sharing a network or code with a CD player or navigation system. I don’t want one computer controlling vehicular functions, entertainment, and climate control. I also want to be sure that there is some protection for all this data, to be sure it doesn’t overwhelm any system. I’ll also admit I like idea of upgrading or replacing parts from different vendors, some of whom might do a much better job of building systems.

We’ve learned a lot about software and complex systems. While I don’t want all manufacturers to use one system or have tight regulations, I would like to see some mandates that separate critical systems from each other. Both in code, and physically. We don’t need to specify code standards, or encryption, or any details, but let’s ensure that a base bar of building software is being used in any of the mass produced vehicles, planes, trains, automobiles, or anything else of substantial size that is operated by the general public.

Steve Jones

The Voice of the DBA Podcast

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

July 31, 2017
Backup Log to Nul– #SQLNewBlogger
Another post for me that is simple and hopefully serves as an example for people trying to get blogging as #SQLNewBloggers. This is also a part of a basic series on git and how to use it.

There are times when you might be working on your demo/lab system and you generate a lot of tranasaction log activity. This isn’t data you want to save, so perhaps you want to remove the activity without saving it.

There are a few choices:
1. Run a normal log backup to a file, then delete the .trn file.
2. Switch to simple mode
3. Run a log backup to nul
The first one is easy, but it’s a pain. I have to go to explorer, or open a VM, delete the file once I find it. The second one is what I’d suggest. In fact, as soon as you install SQL on a lab system, set model to Simple.

The third item is valid, and I ran across this recently. When you use this syntax, make sure you use “nul” and not “null”. We are trying to send to /dev/nul, which is nowhere. If you backup here, then nothing happens. You can use this command:

BACKUP Log sandbox2 TO DISK = N’nul’

This will run a backup, and discard all of the backup data. When I say discard, I mean it’s not written anywhere.

However, this is a real backup. It’s marked as such. This breaks a log chain, and you can do this with a full database backup as well, which means you really need another full backup after this to reestablish a baseline.

Again, I ran across this, but it’s not what you want to do. If you need to clear the log, use

ALTER DATABASE xx SET RECOVERY SIMPLE

ALTER DATABASE xx SET RECOVERY FULL

and take a full backup.

More thoughts from Gail Shaw.
July 31, 2017