With all the trouble NULLs cause...
You'd think people would be more inclined to avoid them. Slap a NOT NULL constraint and a default value on your column and call it a day. I'm perfectly fine with bizarro world canary values. If it's an integer column, some really high (low?) negative number. If it's date-based, why not have it be the lowest value your choice accomodates?
Before SQL Server 2016, you might have used a function like Jeff Moden's DelimitedSplit8k function or Adam Machanic's CLR version. (Aaron Bertrand has a huge post comparing performance of different string splitting methods, too.)
But there's a new, faster game in town! SQL Server 2016 introduces a brand new STRING_SPLIT function:
[crayon-6a37d658312d4266331995/]
Here's how the results look:
Oh God, he's talking about statistics again Yeah, but this should be less annoying than the other times. And much shorter. You see, I hear grousing. Updating statistics was bringin' us down, man. Harshing our mellow. The statistics would just update, man, and it would take like... Forever, man. Man. But no one would actually…
Confession time This started off with me reading a blurb in the release notes about SQL Server 2016 CTP 3.3. The blurb in question is about statistics. They're so cool! Do they get fragmented? NO! Stop trying to defragment them, you little monkey. Autostats improvements in CTP 3.3 Previously, statistics were automatically recalculated when the…
Learning is hard It's rare that I get things right the first, or even tenth time. I have a horrible memory. Seriously. Most of the time I wouldn't know what day of the week it is if it weren't printed on my vitamin case. When it comes to SQL, especially commands or complicated syntax, I…
TL;DR
As of CTP 3.3, it's the same behavior as Trace Flag 2371, in 2008 R2 SP1 and onward. That basically means that the bigger your table is, the fewer rows need to be modified before an automatic statistics update occurs.
Slightly longer...
The change was announced over here. At first I thought, woah, cool, they thought about this and made big changes. But no, much like Trace Flags 1117 and 1118 being enabled for tempdb, it's just...
True story A long time ago, I had to actually do stuff to databases. One thing I had to do was move data files around. Maybe some knucklehead had put system databases on the C: drive, or a LUN was filling up, or we got a new LUN. You know, whatever. Natural curiosity oft leads…
There's an old DBA saying...
May you already have a backup restored
A half hour before your boss knows there's corruption
What? There's no such thing as old DBA sayings? Well, maybe if you all said something other than "no" once in a while, you'd be more quotable. Hmpf.
Anyway, this is a serious question! And there are a lot of things to consider
Ask not for whom the bell tolls
It tolls for SQL Server 2005. Which means in a few short months, you'll need to get out of Dodge. I'm sure you all have your upgrade ducks in a row, you've studied the breaking changes, the upgrade path, and maybe even downloaded the latest upgrade advisor. Smarty pants you are! I'm proud of you.
Math is math is math I haven't found any tremendous differences working with numbers between Oracle and SQL Server. Both offer pretty standard functions to calculate your calculations. Oracle has MOD(), SQL Server uses %. This is likely something you'll want to be aware of if you're working cross-platform, but nothing earth shattering. One really…
The almighty string
It's so good for holding all sorts of things. Chicken roulade, beef roulade, salmon roulade. It's also the way you should store phone numbers. If I could go back in time to when I first started working with SQL, that's what I'd tell myself. Stop. Just, please, for the love of Codd, STOP TRYING TO STORE PHONE NUMBERS AS INTEGERS. It will only end in heartbreak and weird exponential notation.
As soon as you store a date value
Someone is going to want to do something with it. Bucket it into a 30/60/90 day window, figure out how many times something happened between it and current, filter on it, or send you creepy anonymous cards on your birthday full of doll hair and coupons for lotion.
Contrary to popular belief
You will not burst into eternal flames if you're a SQL Server guy or gal, and you happen to be within 100 feet of an Oracle database. You might feel lost and confused for a while, but you probably felt the same way when you opened up SSMS for the first time.
Most of you are going to hate this And TL;DR, there's a script at the end of the post. But like The Monster At The End Of This Book, it's worth it not to skip the middle. There are about a billion but-what-ifs that could come into play. I can't possibly answer all of those…
I love living in the city
Blog posts about people's favorite data sets seem to be popular these days, so I'm throwing my hat in the ring.
NYC has been collecting all sorts of data from all sorts of sources. There's some really interesting stuff in here.
I've set up Mirroring about a billion times I'm not bragging about that. I'd rather say that I set up a billion AGs, and not one of them ever failed. But then I'd be lying to you; those things fail like government programs. One thing I'd never done, though, is set up Mirroring with a…
Scalar functions in computed columns cause all queries that hit that table to execute serially. But it gets worse!
Scalar functions in computed columns
cause index maintenance to go single-threaded.
If you're running Expensive Edition, index rebuilds can be both online and parallel. That's pretty cool, because it keeps all your gadgets and gizmos mostly available during the whole operation, and the parallel bit usually makes things faster.
With each new version of SQL comes a slew of new stuff
While some changes are cosmetic, others bewildering, and the rest falling somewhere between "who cares about JSON?" and "OH MY GOD TAKE MY MONEY!", but not really my money, because I only buy developer edition. Aaron Bertrand has done a better job finding, and teaching you how to find new features than I could. Head over to his blog if you want to dive in.
Everybody wants to know about index fragmentation
It is an inescapable vortex of malaise and confusion. Like that swamp in The Neverending Story that killed the horse. Sorry if you haven't seen that movie. The horse wasn't that cool, anyway.
Neither is index fragmentation, but it's not worth losing sleep over. Or a horse.
TL;DR
Unless you're on SQL 2000, don't worry about scheduling log backups during full backups
Log backups during full backups won't truncate the transaction log
You want to keep taking log backups in case your full backup fails
The first time I ever set up backups
Was, unfortunately, using a maintenance plan. All of the databases were in simple recovery. It was largely used for staging and tenderizing data during ETL. No log backups need apply.
