Voice of the DBA

Category: Blog

  • DevOps Basics–Git log

    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.

    In a few previous posts I’ve looked at getting going with git, and in this post we continue by looking at how we can get some information about the actions we’ve taken.

    If we want to see what has happened in our repo, lots of clients will show a list of changes, but from the command line we use a simple “git log”. When I do this, I see the reverse chronological view of commits.

    2017-07-05 11_21_52-cmd - git log

    There are a lot of options for the log command, but there are a few I use often.

    Limit Entries

    I often use a –n, where n is a number, to limit what’s returned. For example, I’ll use –3 to show the last 3 commits.

    2017-07-05 11_27_17-cmd

    I also like the –p option, which will show differences. As you can see here, I added the UserRoles.SQL file, putting in new lines.

    2017-07-05 11_28_53-cmd - git log -3 -p

    At times, I like the –decorate option, which lets me know which branch was affected. This is helpful if I’m moving around on branches and I get confused. That does happen.

    2017-07-05 11_32_29-cmd - git log -4 --decorate

    There are lots of search options, and I use them at times, but rarely, so I’m usually searching for the documentation to know the dates or patterns. I do look at the –committer= syntax with my name. That lets me find my changes among others.

    I also like to keep things small, so using the –pretty=oneline option is handy.

    2017-07-05 11_36_04-cmd

    Now I can easily see what I’ve done lately.

    There are lots of ways to look at history, and certainly a client makes things easier, but I’d say that you should learn the command line, just in case there’s some issue and your client doesn’t display it properly.

    Last thing, when you run git log and end up with a colon prompt, you’re in the less utility (I think, been a long time since Unix). To get out just type:

    q

  • SQL Server 2017 RC1 is Here

    And I’ve got it.

    2017-07-17 10_33_19-SQLQuery1.sql - 192.168.1.210.master (sa (52))_ - Microsoft SQL Server Managemen

    Glenn Berry posted a a link to the MSDN blog and almost immediately a note that the link was still the CTP. I decided to fire up my Ubuntu install and check. No updates there, though a few people reported Docker had the new bits.

    A short while later, the Windows link was correct, and my Linux update worked.

    I did re-register the repository

    curl https://packages.microsoft.com/config/ubuntu/16.04/mssql-server.list | sudo tee /etc/apt/sources.list.d/mssql-server.list

    And then the rest was the same as previous updates. Quick and easy, a few command line things to type and I was updated.

    Now I need to get Docker working, since I’m betting we’ll see updates and changes there faster than anywhere else.

  • PowerShell $env Variables

    I was playing with containers the other day, reading a Simple Talk article on the topic, and noticed the code in PowerShell (PoSh) used the $env:xx syntax for variables. I know I’ve seen this before, but for some reason this struck me as something I knew little about.

    I decided to search a bit. One of the first links was from WindowsITPro, and they had some great code: Get-ChildItem ENV:. When I run that, I get lots of information:

    2017-06-14 14_59_52-powershell

    There are more items, but there are some interesting ones that I think could be useful for me, especially with automation. I have a OneDrive path, my home path, the Username, and more.

    I know I’ll never remember most of these, but really I just need to remember one: Get-ChildItem ENV:

  • T-SQL Tuesday #92–Hard Lessons

    A quick post, written last week as I’m relaxing in the mountains.

    This month the topic is lessons learned the hard way, from Raul Gonzalez. It’s interesting, and certainly one where I have experience. I make mistakes regularly, though I tend to fix them.

    You can read more about T-SQL Tuesday and learn how to participate, or even respond to old prompts at tsqltuesday.com.

    A Hard Lesson in Preparation

    I worked for a financial services company at one point, managing the live systems as well as performing database development. I had a few people working for me, some in each area, and we had contracts with a number of clients. Quite a few of these contracts specified a yearly DR test at a remote facility.

    The first year I was there, we packed up tapes and documentation, carpooled for 4 or 5 of us as if this were a disaster, and started rebuilding systems. Our contractor supplied xx servers as per our contract, and we had to start from scratch.

    We didn’t do well, and couldn’t get our web app or client server apps running completely. The db restored, but the system and docs were out of date. I knew this, and we updated some things, but we didn’t take the process seriously.

    A few months later our largest client was unhappy. Since we couldn’t get the website running, they wanted another test. At their site.

    Myself and another were chosen to fly to their site, shipping out spare servers and software. We had to wipe the drives and rebuild the system from scratch. Since the two of us had been at the DR test, we assumed we’d learned enough to do this in two days, sure we could rectify all the mistakes from the test team.

    We couldn’t. After two days, we didn’t have everything running, with too many dependencies and issues from various web components. Our developers had been running wild, with admin access to the webserver and database server, resulting in wonderful unique, snowflake servers that were hard to reproduce.

    Inadequate preparation, as well as poor security for years, contributed to the failure. I did get the database working, but that didn’t matter since this client used web access only. I had to take a large portion of the blame since I managed systems, and our company paid a penalty.

    It was embarrassing for me, personally and professionally. I hadn’t done a good enough job being ready for a disaster. This did server to motivate me to start cleaning up the systems and ensuring we could rebuild a new web server if needed, but it was a hard, and expensive lesson, to learn.