Starting LocalDB–#SQLNewBlogger

Posted on March 28, 2022 by way0utwest

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

Lots of people have never worked with LocalDB, which is an in-process version of SQL Express. No service account, just a SQL Server instance running with your app. It’s a nice lightweight way to get SQL Server running quickly without a hassle.

This is a SQL Server Express version, but the bare bones for development. This post looks at how you can get this running.

This version of SQL is installed with SQL Express, and with Visual Studio. If you look in this path: C:\Program Files\Microsoft SQL Server\150\Tools\Binn, there is a SQLLocalDB.exe. You can see that here.

2022-03-03 09_08_00-Binn

This is my SQL Server 2016 version of LocalDB. I can start a new instance by calling this with the CREATE option. I can give this a name as well, as I might want to stat multiple instance for different apps. Here I’ll create an instance called app1.

SQLLocalDB create app1

I then call the same command, but use START instead of CREATE. You can see this reports as started from the CLI. I also add the INFO call to get status.

2022-03-03 09_10_35-C__Windows_System32_cmd.exe

Now I can connect. I use (LocalDB)\app1 to connect:

2022-03-03 09_11_39-Connect to Database Engine

I see I’m connected to a version of LocalDB then:

2022-03-03 09_12_03-SQLQuery2.sql - (localdb)_app1.master (ARISTOTLE_Steve (70))_ - Microsoft SQL Se

Now it’s just an instance of SQL Server I can use.

 

SQL New Blogger

I needed to check something for a customer and realized I hadn’t started LocalDB in a long time, so I needed to check the docs. I spent 10 minutes putting this post together.

An easy type of post for any of you out there. Learn something, try something, write something.

Posted in Blog | Tagged , , , | 2 Comments

Easily Repeating Work

Posted on March 28, 2022 by way0utwest

I love this idea from Ken Fisher: saving your work. I don’t act as a DBA anymore, but when I did, I did something similar. We often logged the scripts we used in a file,  as a part of a log, so that if we broke something and another DBA got a new ticket, they could check what you had done. Over the years, we tried two different methods. First was using the desktop of the instance itself, since we often went to a room to log into the server in those days

The second way was in an Exchange public folder, where we added a new entry for each day. This way we could note the server and the scripts run. Since most tickets were dated, we could easily find the scripts if we were looking at a ticket. Since a user often updated or re-opened the ticket, we could use the public folder as a central note location from the DBA team. We could even point to this folder for our ISO and SOX auditors to show them what had been logged by people who supported the systems. Not a perfect auditing system, but one that often was accepted by auditors.

However, the one thing missing in there, from my perspective, is version control. While I think it is important to track these scripts in a team of DBAs, I also think we want to ensure that as we grow and change these scripts, we know how and why. Junior people can learn from changes made by senior ones, and if a DBA alters one of these scripts and breaks something, just as a developer might refactor code and introduce a bug or break functionality. After all, these scripts are code.

If there is a problem, we want to be able to roll back, which means that we ought to save these scripts into a repository of some sort. While I like the idea of a share that all DBAs can access, I more like the idea of a (secure) Git repository that can be downloaded anywhere, provides a second backup, and can be audited over time. All of these are important features that any enterprise should implement, especially one that is regulated. We want to protect ourselves if a DBA gets hit by the proverbial bus.

I like collaboration, sharing knowledge, and tracking the work you do in a team. It’s important for raising the skills of everyone on the team and helping new members get up to speed quickly. This facilities consistent results, and if done using a tool like version control, helps ensure that your scripts are backed up in a way that preserves the knowledge in your code through any changes made by the team.

Steve Jones

Listen to the podcast at Libsyn, Stitcher, Spotify, or iTunes.

Posted in Editorial | Tagged , | Comments Off on Easily Repeating Work

Daily Coping 28 Mar 2022

Posted on March 28, 2022 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. All my coping tips are under this tag.

Today’s tip is to listen to a piece of music without doing anything else.

I saw a list of acoustic guitar songs recently and on it was Babe I’m Gonna Leave You by Led Zeppelin. I listened to a lot of their music as a youth, and I’d forgotten about this song. So, I pulled it up on Spotify, closed my eyes, and just listened.

Like many of their songs, there is some beautiful, peaceful guitar part that moves into a rock opera. An interesting lick that quickly gets buried inside of a heavy bass and drum part. At times, the loud singing is at odds with the guitar.

An interesting piece.

Another one, which I actually heard while swimming recently, was Starship by Kanye West. I was moving along and found myself distracted by this tune, actually hearing the words. I know I’d heard the song before, but I don’t know I had listened to the words, but enjoyed that one, completely distracted from the effort of the monotonous laps.

Posted in Blog | Tagged , , | Comments Off on Daily Coping 28 Mar 2022

Would You Want to be on the Red Team?

Posted on March 26, 2022 by way0utwest

In the world of cybersecurity, a red team is a team of hackers that try to infiltrate a company, but at the request of the company. The idea is they look for vulnerabilities and issues and find them before criminal hackers do. They are the opposite of the blue team, who is trying to stop the red team and create defensive measures that prevent the red team from accessing data.

Many large companies use red teams. Microsoft maintains a red team (and a blue team) that are constantly competing to break into their systems and defend them (depending on which side you are thinking about). I’m sure Amazon, Google, and other large companies do the same thing. It’s an interesting idea, though I bet this is a lot of repetitive work where you constantly repeat similar attacks with slight variations. There certainly is some creativity and research as well, and some acting if you social engineer situations, but it’s not the type of work I would want to do. I doubt it’s as exciting as Hollywood movies portray hacking.

An organization could assemble a red team from external resources and use them to evaluate the security of your software, your infrastructure,  or even your people. There’s an article this week on getting started with a red team. Since companies are seeing more and more attacks against their systems, I would expect more to be proactive and either assemble or hire someone to test them. In fact, I bet there will be lots of cybersecurity people setting up their own companies to help here.

Many of us might feel we are careful with security, and that we check for issues. I’m sure we do some of that, and many of us know how to secure things well. However, it’s easy to make a change and make a mistake. It’s easy to forget to include a group, or include the wrong group, in a security ACL. It’s easy to forget to check a setting or leave access open while we test and forget to go back and secure it properly.

Attackers think differently. We can learn to do this, but it might be helpful to have someone else doing the attacking and then giving us a report on what to fix.

Steve Jones

Posted in Blog | Tagged , | Comments Off on Would You Want to be on the Red Team?