Voice of the DBA

Category: Blog

DevOps Basics–Getting Started with Git
Git is taking over the world as a Version Control System (VCS) and it’s actually fairly easy to use. This is a quick post on getting started using git.

Git is free and you can get it from: https://git-scm.com/

I use Chocolatey, and you can also download it for windows with this code:
```
choco install git
```
or
```
choco update git
```
In any case, this is a simple install on your machine. If you’re on OSX or Linux, you can download and install it in whatever way you want for those systems.

Once Installed

You can check that git is installed at the command line. There are also clients, but I like the command line, especially when getting into DevOps.

git version

This code tells you if git is installed. In this case, you can see my version (after I updated).

Now it’s installed, what do I do? Well, I first want to create a repository to track my code. A repository (or repo) is really a folder where all changes to code are tracked. I can do this with the “git init” command, but I need to do this in an empty folder.

I have some code in e:\Documents\GitHub\EndtoEndAlwaysEncrypted\SQLCode for a presentation I do. I can see lots of .sql files in here:

I want to track this code, so I’ll make a repo for it. On Windows machines, there is a Source\Repos folder under your user profile. For this machine, that is C:\Users\Steve\Source\Repos. You can see I have a few folders here:

Let me create a new folder, called EndtoEndAlwaysEncrypted. Once I do that, I’ll change to that folder and run
```
git init
```
This initializes a repository. There’s nothing in there bit a hidden .git folder, but that’s fine. I now paste in my code.

So far nothing is different with my code. However, if I check my status at the command line, I’ll see there are no files. I do this with
```
git init
```
This gives me some results.

Don’t worry about the master branch item. The thing to notice here is that all the files in red are new and aren’t being tracked by git. To add these to my git VCS, I need to track them and then commit them. To track them, I’ll “stage” them with
```
git add –all
```
This will add all the files. I could use git add with a filename after it, or use the dot (.) to add everything.

Notice now that the files are in a lighter color, as they are tracked, but not committed. A commit means that git now knows about this version of the code and will be able to return to this version if you need it.

To commit, use “git commit”. You need a message for the commit. Most GUIs make this easy, and git will pop up a text editor if you want. I prefer the command line, and use the –m parameter with a message. For the first commit, “initial commit” is usually a good message.
```
git commit –m “initial commit”
```
Once you do this, the status shows clean, which means everything is being tracked by git.

That’s it for getting started. This doesn’t seem like much, but it’s the basis for now tracking code. No more need for me to do something like “00_db_setup_old.sql” or “oo_db_setup_2.sql” for filenames. I can make changes, capture (commit) them, and then easily see what each version looks like.

I’ll cover more later.

If you want to see this as a video post, I’ve got it on my Voice of the DBA YouTube playlist here: https://youtu.be/hyyy9obHmw8
May 8, 2017
Copy-SqlJob, a handy dbatools cmdlet

I really like the dbatools project. This is a series of PowerShell cmdlets that are built by the community and incredibly useful for migrations between SQL Servers, but also for various administrative actions. I have a short series on these items.

One of the things I’ve often needed to do is move jobs around between instances of SQL Server. I’ll often test a job on one instance, maybe run it for awhile to see if it’s a useful addition to my instance, and then deploy the same job to other instances.

I do this often with jobs that help each instance manage itself independently. While each new build often includes some standard settings and jobs, I do find that I’ll adjust jobs over time, fix bugs, enhance them, and I’ll need to move the job over. This has usually involved scripting the job on one instance, adding delete code, and then running the script on other instances.

No longer.

Enter Copy-SqlJob

One of the cmdlets in dbatools is Copy-SqlJob, which does what you’d expect. It copies jobs from instance to instance. If you look at the docs, but default it copies all jobs, but I rarely need that. Though I might start using that for new builds along with Copy-SqlDatabase to move my DBA database from machine to machine.

However, I can copy specific jobs, which is perfect for my purposes. Just put a list of jobs to be copied in a script and run that. Let’s see how this works. On one instance I have a number of jobs.

Another instance has fewer jobs.

Let’s move just the CommandLog Cleanup and Output File Cleanup jobs over. I can fire up a PowerShell and go from there. I’ll start with the –WhatIf parameter, which lets me test without moving anything.

That’s easy enough. Let’s just move one job for now, the CommandLog Cleanup job.

And refreshing the second instance:

That’s useful, and it works easily across these instances with Windows Auth. What if I need SQL Auth? I can use SourceSqlCredential and DestinationSqlCredential to specify accounts. I can even have this prompt me for the password:

Once I type it in, the copy works.

What if I update a job on the source server, and need to ensure the changes get copied to the destination? I can use –Force. If I don’t, I’ll get a message that the job exists. With the Force parameter, the job gets copied.

This is a simple, but handy way to move jobs between servers. Many of the dbatools cmdlets are designed for migrations, and this is no exception. You can migrate jobs easily if that’s your requirement.

I’d urge you to download dbatools and see which of these cmdlets might make your administration of SQL Server easier than you ever expected.

May 8, 2017
I’m on dbatools!

I made the front page of dbatools, as a part of the community that is supporting this project. Along with quite a few others, I’m happy to be there and doing my part to make SQL Server administration and scripting easier.

Maybe I’ll even write a cmdlet some day. Since I keep working on my PoSh skills and playing with the various cmdlets.

May 5, 2017
Finding the Service Name–#SQLNewBlogger

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

A quick one today, and this one I remembered without looking anything up.

I recently needed the service name to kill it for a test. I was using the sc.exe command line and couldn’t get it to give me the SQL Agent service name. I could have hit Windows, typed services, scrolled down, found the Agent, right clicked it, selected properties, and gotten the name.

Or I could do this:

Get-Service | Where {$_.Name –Like ‘SQL*’}

That worked and I could quickly see all the names.

The only thing that threw me was I forgot the hyphen before “like”. One of these days I’ll actually remember that.

May 4, 2017