Press "Enter" to skip to content

Category: T-SQL Tuesday

DB File Space Usage

Published 2016-05-11 by Kevin Feasel

Andy Mallon looks into sys.dm_db_file_space_usage:

SQL Server 2016 is coming out next month, and it’s chock full of new features that I can learn. Row-level security is interesting. Dynamic data masking sounds fun.

If you’re a regular reader of my blog, you probably know I try to approach questions from a unique angle. Instead of blogging about something cutting edge or sexy, I decided to scroll through the list of system views until I found one I didn’t recognize.

sys.dm_db_file_space_usage

The name is pretty self-explanatory, but I never noticed this existed until now. Seems like the type of DMV that I should have known about, but I didn’t. Quick look at BOL, and I got the verbose description from Microsoft:

Andy goes on to compare the outputs from this DMV to methods he’s historically used.

Comments closed

T-SQL Tuesday Roundup

Published 2016-04-18 by Kevin Feasel

Jens Vestergaard has his round-up of favorite SQL Server features:

This week, I have been looking forward to the time where I got to read through all the contributions to my#TSQL2SDAY invitation: Favorite SQL Server Feature. Very happy to see this many. I have added a short description of each blog post, as well as my own personal key take-away(s).

So, in no particular order, I give you the round-up:

I like T-SQL Tuesday for several reasons; one of the more selfish reasons is that each month, I get to expand my blogroll a little bit further.  This was a particularly good one, so check out the entrants.

Comments closed

Partition Switching

Published 2016-04-15 by Kevin Feasel

James Anderson gives his favorite feature in SQL Server:

The good news is that the SWITCH command works on regular tables and in any edition. This means I can quickly transfer all of the data from one table to another in Standard Edition.

In reality, I have found few uses for the regular table to regular table switch; the trick to add the IDENTITY property to a column with existing data is the most recent. SWITCH is most useful when partitioned tables are involved. Sorry, Standard Edition users.

Partition switching is a fascinating solution for a difficult technical problem.

Comments closed

DMVs

Published 2016-04-14 by Kevin Feasel

Andy Yun talks about his favorite SQL Server feature:

Much earlier in my SQL Server career, I never knew much about how SQL Server operated under the hood. I only had knowledge of the things I could do directly, but I never questioned what was really happening behind the scenes. Then I attended SQLskills IE1 training, which was a turning point in my career. Among other things, it was my first exposure & deep dive into SQL Server Internals. I became enamored with learning how things really worked under the hood and the DMVs/DMFs became one of my best friends.

This is a big part of SQL Server administration.  It boils down to asking the server where it hurts and understanding how it responds.  DMVs are extremely helpful in that regard.

Comments closed

Restraint

Published 2016-04-14 by Kevin Feasel

Andy Mallon comes out of left field with his favorite feature:

It’s really tempting to implement cool-sounding features. It’s really tempting to hyper-tune solutions to be the absolutely perfect, most-optimal solution. But it takes a real expert to realize when you’re over-engineering a solution.

Take a moment to appreciate your own restraint. Appreciate all the features that you didn’t implement because you didn’t have to. Be happy that you looked at the big picture and decided the best solution was the one you were able to support.

It’s definitely an interesting approach to the T-SQL Tuesday challenge, so full credit for that.

Comments closed

Azure Transactional Replication

Published 2016-04-14 by Kevin Feasel

John Sterrett names transactional replication into Azure as his favorite feature:

In the field, I see a lot of people using Availability Groups to have a near real-time replica for reporting.  I talked a little bit about this above.  What isn’t mentioned here is you have to maintain a Windows Failover Cluster, Quorum, Active Directory (Unless using Windows 2016 Preview) and more. This gets you a replica that is just a copy of the database. What does this mean? You cannot change database objects like security, indexes, etc. Also, what if you don’t need the whole database(s) for reporting? If not, you can replicate only the data you truly need.

So, let’s recap here.  You only have to replicate the data that you need.  You can have different security and indexes on your reporting subscriber database(s).  The reporting subscriber database can be scaled up or down as needed based on your needs.  The reporting database can now be an Azure Database. Folks, I call this a huge win!

There’s a lot more replication love out there than I’d expect.  John promises to follow up with a guide on how to implement this, so keep an eye out for that.

Comments closed

Database Mirroring

Published 2016-04-13 by Kevin Feasel

Derik Hammer has chosen Database Mirroring as his favorite feature:

With the end of SQL Server 2005, we also will soon see the end of database mirroring. There is a new feature releasing with SQL Server 2016 called Basic Availability Groups. This is the replacement for database mirroring. The use cases and limitations will appear very similar to database mirroring but it will use the Availability Group technology. In theory this will be like a stim-pack for the database mirroring feature while leaving it available in Standard Edition. Let’s cross our fingers that the Windows Failover Cluster components don’t slow down the failovers like it did with AGs.

A bold choice, but that “available in standard edition” thing is huge for smaller organizations which can’t afford Enterprise (especially with The Licensing Changes of 2012).

Comments closed

Delayed Durability

Published 2016-04-13 by Kevin Feasel

Kenneth Fisher talks about Delayed Durability as his favorite SQL Server feature:

In the end I decided it would be fun to post about one of the newer features;Delayed Durability. To understand DD (delayed durability) you have to understand how SQL Server implements durability. To start with there are two pieces of any data change. The actual data page and any log records that are created. In order to keep SQL Server as fast as possible the data pages are changed in memory and then written to disk as part of a background process. Unfortunately this means that you could lose those changes if the server crashes or shuts down before they are written to disk. In order to avoid this, and keep the changes durable, the transaction can not complete until the log information is actually written to disk. This means that one of the big bottlenecks in any given transaction is writing that log record to disk. The DD option basically changes that write from a synchronous to an asynchronous operation. The log writes are bundled together in 60k chunks before being written to disk. This can (depending on your work load) provide a huge increase in speed. I’m not going to bother discussing that part of it since Aaron Bertrand (b/t) and Melissa Connors (b/t) wrote great posts on just that (Aaron’s and Melissa’s).

What I want to discuss is the actual risk of data loss.

My philosophy on this is simple:  if you need delayed durability and you can afford the data loss, then maybe there’s a better data platform.  I want my SQL Server like I want my Grateful Dead concert:  ACID compliant.

Comments closed

Replication

Published 2016-04-13 by Kevin Feasel

Jon Morisi loves him some replication:

Seriously though, replication has been around since the beginning and it’s not going anywhere.  I can’t think of any other feature more prolific than replication.  Name another SQL Server HA/DR technology that is as extensible as replication.  Replication has gotten a bad rap over the years mostly on anecdotal comments that it “breaks all the time” or “it takes too much time to manage”.  I’ve worked in many environments and have setup dozens and dozens of instances of log shipping, mirroring, clusters, availability groups, and replication.  From my anecdotal experience, I can tell you I’ve had more trouble with availability groups than I have with replication.  If you have a good DBA that understands replication, uses it correctly, and is provided the correct tools (read $ for hardware/infrastructure) replication works just fine.  I have setup replication in a global environment in which multiple databases, publications, subscriptions, and agents ran around the clock and without issue.

Replication is very powerful, I agree…but it still breaks.  A lot.  I’m grateful for its existence and also for the fact that I’m not the one maintaining it…

Comments closed