SQL Server has a new feature that’s currently only available in Azure SQL Database: Optimized Locking.
Jeremiah Peschka joins Kendra (aka Kendar) to talk through the docs and nerd out on locks, blocks, and how to pronounce the acronym “LAQ”.
Prefer to explore optimized locking with a diagram? I’ve also got a little sketchnote for ya.
Ever wondered what it’s like to be a VP or Director of Engineering? I chatted with Alex Robson about leadership in technology, what you can get out of coaching or an MBA program (should you be interested), and what makes a high performing team.
Alex’s site and blog: https://robsonconsulting.services
Yesterday, I was writing some Transact SQL to dust off the cobwebs. I got confused when I was playing around with the STRING_SPLIT function, and kept getting the error:
Msg 195, Level 15, State 10, Line 2 ‘STRING_SPLIT’ is not a recognized built-in function name.
I checked my database compatibility level, which must be 130 or higher for the function to be available. My database compatibility level was 160, so that was fine.
The issue? STRING_SPLIT is a table valued function. If your syntax uses it as a scalar function, you will still see a message that it doesn’t exist – but really the issue is that the function exists, but needs to be called with a different syntax.
Let’s look at some examples.
SQL Server performance tuning expert Erik Darling joins the podcast today to chat about how good queries can go bad and how bad queries can get better.
He also answers the question on everyone’s mind: if he was a database, what database would he be?
It can be tiring to have the database constantly be the Prime Suspect for performance problems.
There’s a right way and a wrong way to handle it.
Tech interviews are weird and wacky. How did they get this way, and how SHOULD they be? Jeremiah Peschka joins us to discuss.
Database migration scripts are a popular and effective way to check database code into version control.
In this post I describe the most common features of popular migration script runners for database code deployment, along with the top gotchas that folks hit when versioning their database code with migrations.
There are lots of jobs for data folks. In this episode, I discuss three hot job titles: Database Administrator (DBA), Database Reliability Engineer (DBRE), and Data Engineer (DE).
Sometimes people are annoyed by the term ‘Database DevOps’. Why not call it simply ‘DevOps’? After all, Database DevOps follows the same core principles.
The answer is simple: implementing DevOps is tricky by itself, but most teams are set up to fail when it comes to implementing DevOps for databases. This makes it worth defining as a specialization.
Twenty years ago, database administrators (DBAs) were the primary career path when it came to specializing in data management.
Much has changed: development patterns transformed from Waterfall to Agile, DevOps drives automation and shared ownership of code, and cloud services have made many more kinds of PAAS databases, data lakes, and data lakehouses available to organizations of all sizes.
These changes have introduced new and varied career paths for data folks which have different emphases on skill sets. In this post, I talk through the commonalities and differences between DBAs, Database Reliability Engineers (DBREs), and Data Engineers (DEs). Whether you’re a hiring manager or data professional, it’s worth knowing about these roles.
Copyright (c) 2024, Catalyze SQL, LLC; all rights reserved. Content policy: Short excerpts of blog posts (3 sentences) may be republished, but longer excerpts and artwork cannot be shared without explicit permission.
