Voice of the DBA

Tag: administration

Are You Always Up?

I’ve had the opportunity to work for and with quite a few companies in my career. In some sense working as a database developer or database administratrator is very similar at many places. The “job’s the job,” as I’ve said in more than a few interviews, as I often ask to meet with others and better understand the environment. I’m rarely sold on the technology in use, usually more concerned with management and co-workers, though you might view employment differently.

At the same time, it can be amazing how different the environment may be and how varied the requirements are for my application and systems. One employer was a small, but busy and growing import/export company. We stretched the limits of technology at the time, and it was a challenge to meet the desires of management. At the same time, we were primarily a weekday, roughly 9-5 shop and I had the opportunity to bring down systems at night or on weekends for maintenance.

This was in contrast to my prior position at a nuclear power plant. There systems were expected to be up 24×7, with (grudgingly) scheduled maintenance once a quarter. That was the environment with the most stringent requirements, though I also learned over time that I preferred to have a bit more latitude in how I could architect systems or manage databases. Though that was when I had children, and I might be willing to work in a similar environment now.

Many of you probably have varying requirements by application, but I suspect more of you are expected to keep systems up more often than in the past. It seems the world has moved to a greater dependency on database platforms, with the expectation that the data is always available.

When you plan upgrades or maintenance, can you work with a flexible schedule? Or are changes always carefully managed? I’m sure some of you prefer one type of environment over the other, so chime in today with your preferences and restrictions. I’m sure some of you work in less busy organizations, and I’m curious if that’s the case.

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.

January 26, 2018
Disable or Drop

When I started working with SQL Server and Windows, it seemed that the administrative side of many actions was limited. We could add and drop many items, but that was it. Relatively few tools allowed setting limits or disabling them, which was a pain. After all, I’d gotten used to setting up accounts for vendors and contractors in Active Directory, often disabling them when they weren’t in use. I couldn’t do this in SQL Server for many objects, which was a pain and an administrative burden to reset them up when troubleshooting issues. This was pre-PowerShell and .NET when any SMO access was a project in and of itself.

These days SQL Server has done a great job of adding in the ability to pause or disable many objects. We’ve had the ability to lock out an account for many versions, which is a great way to setup a vendor tech support account when it’s needed. This is especially important for security these days, as we may want to be sure that we prevent access by any suspect accounts. Disabling them allows us to prevent their use, but keep all their rights and permissions in the even they are valid accounts.

We can disable indexes, which can be useful as a precursor to deleting them at some point. We can disable triggers, which is incredibly useful when you are testing or debugging actions on a table. We can disable Extended Events, audits, and more. All of these are useful actions for a developer or administrator, if you use them.

When things go wrong, we’re often stressed and pressed for time. If there are issues with a system, many of us make snap decisions, which might fix the problem or make the situation worse. Even in those cases where we fix an issue, deleting or dropping objects might cause is extra work later. My question for you is what’s your first reaction? When you need to make a quick change to remove something, security access, an index, etc., do you drop or disable?

I would hope that you disable, as this removes the effects but keeps the object in the system with associated meta data. Rebuilding permissions or trying to get the old trigger code is a pain (since few people use a VCS, please start doing this). It’s possible that you won’t even be able to get things reset back up in the same manner. That might be fine, but it’s not ideal as new code should be tested, and in a crisis, it likely won’t be looked at too closely. At least the previous version of the code was tested in production.

Build the habit to disable, not drop, and I think you’ll be glad you did.

Steve Jones

The Voice of the DBA Podcast

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

January 12, 2018
Keeping the Single User Connection

A reader was having issues with a script. They ran their code from PoSh (Invoke-Sqlcmd), setting single user and then trying to rename a database and its files. However, occasionally, they’d lose the single user connection to another user. Frustrating, but it wasn’t a PoSh issue.

The ALTER DATABASE commands don’t really specify how SINGLE_USER works. What happens is that if you set single user, the first user gets the connection, whether that’s sysadmin, dbo, or a regular user. This means that when you set a database to single user mode, you need to be one of the users in the database.

The change to single used is blocked, until all other connections disconnect. One way to ensure this happens quickly is to add the WITH ROLLBACK IMMEDIATE clause, which disconnects users.

The original poster’s issue was that while they used the clause, their connection was in the master database. This meant that another user could potentially connect to the database, grab a shared lock, and prevent renaming files.

If your connection is in the user database, then when you issue the ALTER DATABASE WITH ROLLBACK IMMEDIATE and disconnect users, then you have the only connection. This should prevent any issues.

Quick Demo

Let’s see this in a simple way. I’ve got a demo database that I use, and I’ll open three connections. The first will be as a sysadmin here:

and then the other windows I’ll switch the connection to a non-privileged user.

At this point, I have a few connections to my database.

Let me now reset the database option.

Everything works here, let’s check the next session. If I switch to another tab, I’ll run a query. After a second or two, I get this:

SQL Server has disconnected my session. If I try to reconnect (this login has EncryptionDemo as the default), I get this:

If you need to perform maintenance, and want to ensure you have the connection, change context to the database before setting single user mode.

November 16, 2017
Using xp_delete_file
First, this is an undocumented proc, and there’s nothing in BOL on this. Second, it’s a holdover from previous versions, so you’d be better served by using Powershell or some other type of scripting mechanism. This procedure is not supposed to be supported in the future, so I’d remove this from your code. In fact, if you want to just remove these, use Remove-DbaBackup from dbatools.

If you use this, or want to know what to refactor, Patrick Keisler has a nice post on the proc as does Andy Leonard, and there’s a parameter list on StackOverflow. I dug in recently as a customer was having issues, and I needed to refresh my memory.

Essentially, there are a few parameters that you use with this procedure, but bear in mind this only deletes SQL Server backup files or report files. You choose this with the first parameter, a 0 for backup files, and a 1 for report files. The rest of the items are fairly self-explanatory, but keep a few things in mind.

First, the date is a datetime value. Meaning if you just include a date, this is the beginning of the day (midnight). You can see this here. I’ve got some backup files.

I then run this code:
```
EXEC xp_delete_file 
   0
   , N'D:\SQLServerBackup\MSSQL13.SQL2016\MSSQL\Backup'
   , N'bak'
   , '20170901'
```
Now, I see this:

The file from Sept 1 still exists because it’s at 9:56am, and the parameter is midnight (2017-09-01 00:00:00). Keep that in mind, and use the appropriate values. If I’d run this:
```
EXEC xp_delete_file 
   0
   , N'D:\SQLServerBackup\MSSQL13.SQL2016\MSSQL\Backup'
   , N'bak'
   , '20170901 10:00:00am'
```
The file from Sept 1 is removed.

Next, you need to use the extension to decide which files to remove. That means you might need to have separate calls for .bak and .trn (and .dff), or just remove all old files. The choice depends on what your requirements may be.

Lastly, make sure that if you use separate folders for each database, you set the last parameter.

Again, I wouldn’t use this command, especially not in a modern system, but if you do use this, make sure it’s working.
October 9, 2017