Press "Enter" to skip to content

Month: August 2026

The Importance of Disaster Recovery Testing

Vlad Drumea performs some tests:

After the ANCPI hack that took down Romania’s land registry, Andrei Avădănei, CEO of Bit Sentinel and founder of DefCamp, published on LinkedIn a detailed proposal for a national offensive security program.
It covered pentesting frameworks, vulnerability disclosure, continuous monitoring, and accountability measures. The proposal was thorough, logical, and exclusively focused on prevention and detection.

I left a comment suggesting one addition: mandatory disaster recovery simulations.
Can institution X recover after their entire production environment is encrypted? If so, how long does it take and what data is lost? Are there backups? And if yes, are they actually viable, or are they Schrödinger’s backups, where you only find out whether they work at the exact moment you need them?

This exchange made me realize that organizations, especially in the public sector, rarely consider doing disaster recovery tests.

I’ve been on the edges of DR scenarios at prior jobs, including one at a state agency. Most of the time, the tests have to be hypothetical or piecemeal because we rarely had the hardware to support a full switch-over, or the budget to spin up an equivalent set of hardware in a different region.

Leave a Comment

Taking Advantage of Newer Date Functions in SQL Server

Andy Brownsword gets beyond SQL Server 2000:

Date handling in SQL Server tends to accumulate tried and trusted combinations of DATEPART()DATEADD(), and DATEDIFF() – with nested variations. The challenge with these isn’t raw performance, but more with conveying intent and readability.

So let’s look at some simpler patterns to try and avoid some of these and be clearer with what we’re trying to achieve.

Click through for some functions that have been around since 2012, and others that just became available in 2022.

Leave a Comment

The Perfect Trick to Speed Up Databases

Louis Davidson becomes a cracker jack developer:

This week, I want to sell you on two ideas. First, that you can make any query faster with:

  • Zero hardware changes
  • Zero index changes
  • Zero structure
  • Just a few simple character changes in every one of your queries

This change I will guarantee will make your queries screamingly faster. Never will your customer’s wait on query results again. You will have no blocking, no latch waits, no waiting whatsoever.

He probably should sell this as a training course, along with its administrator equivalent: databases hate date, and you can’t have data problems if you don’t have any data.

Leave a Comment

Displaying Detail Rows Expression Results in Power BI

Chris Webb works around a limitation:

In last week’s post I mentioned that while Power BI reports (unlike Excel PivotTables) do not support the Detail Rows Expression feature, it is possible to partially work around this limitation by using the paginated report visual. In this post I’ll show you how I was able to do this and what is and isn’t possible.

Click through to see how. I’m unclear as to whether this also applies to Power BI Report Server, though my default expectation is “No, it does not apply, because nothing new ever applies for Power BI Report Server, because Power BI Report Server users don’t deserve nice things.” But that’s just because of years of experience in not having nice things with PBIRS, not any specific information.

Leave a Comment

Blocking Database Project Deployment on Data Loss

Jerry Nixon flips a switch:

This important feature shows up in a few places. This article discusses its role in Database Projects and in SQL Server Management Studio (SSMS); it defaults to true in both. This simple setting evaluates the delta between your desired schema and your actual schema and calculates if applying your desired schema would result in data loss. If the answer is “yes,” it stops.

An easy example is dropping a table or column. Doing so would clearly lose data. Another, perhaps less obvious, is reducing the range of a column’s data type, like from INT to TINYINT, where any existing value under zero or over 255 could be lost. These evaluations are done by the engine when BlockOnPossibleDataLoss is set to True and, as a result, you can trust that data in your database is not accidentally destroyed by publishing a schema.

The tricky part becomes dealing with database changes when there will be data loss. For that scenario, I’m not sure the database project approach offers anything significant over writing your own database change scripts.

Leave a Comment

Building a SQL Server Estate Summary from Get-SqlSafe Reporting

Andreas Wolter digs into an environment and builds a report:

Have you ever needed to understand an unfamiliar SQL Server estate quickly? Perhaps you inherited an environment, started working with a new customer, or discovered that the existing server inventory is no longer trustworthy.

In the previous article, Running Get-SqlSafe at Scale Across a SQL Server Estate, I showed how to run Get-SqlSafe across a list of SQL Server instances.

Each report contains a System Overview section. I originally added this section to provide context for the security findings, but it also provides useful estate information such as the SQL Server version, build number, edition, and selected usage indicators.

Click through to see how.

Leave a Comment

Dual Y Axes in R with ggplot()

Andrea Onofri builds a complex chart:

I have often found myself needing to plot a single graph with two y-axes having different scales. For example, this might be useful for representing temperature and rainfall data at a given location. Unfortunately, doing this with ggplot() is not straightforward.

As Andrea mentions, there are specific circumstances in which having a dual-axis chart is reasonable, and click through to learn how. ggplot2 tends to be rather opinionated regarding visual choice and design. I happen to like those opinions and think they are generally correct, but I can also recognize that there may be exceptions to the rules. For those instances, I think “Somewhat difficult but not impossible” is a solid answer, as it keeps people from doing things inappropriately with a couple of mouse clicks, like setting up those stupid 3D bar charts in Excel. H/T R-Bloggers.

Leave a Comment

Applying Color Thoughtfully

Amy Esselman provides some guidance:

One of our top tips for explanatory communications is to use color sparingly and purposefully to help your audience understand your data and message. Color should be an explicit choice, not something your software applies by default, whether that’s a graphing tool or an AI assistant generating your first draft. These tools can build a chart in seconds. They might even add highlighting on their own. But they don’t know which data matters most to your audience. That call is still yours. Used thoughtfully, color is often one of the quickest ways to improve a graph.

Color is an extremely powerful pre-attentive attribute, meaning that it’s something we intuitively see and respond to without explicit thought. That’s why choosing what to color can be so powerful. If everything has bright, distracting colors, you lose an avenue to guide the viewer’s eye. But Amy’s example is a good one to show the particular element(s) in the visual that you want people to focus on, and the viewer’s eyes will automatically go there.

Leave a Comment

The Value of TRY_PARSE()

Steve Jones answers a question:


Someone asked why I would use TRY_PARSE after I posted a question at SQL Server Central: Getting the Average. Isn’t is slower?

A fair question. This quick post looks at why.

I’d use TRY_CAST() or TRY_CONVERT() in this particular scenario. The main reason I’d use TRY_PARSE() would be if you need .NET-specific parsing functionality, such as parsing dates by a specific locale. The reason is that PARSE() and TRY_PARSE() are an order of magnitude slower than their CAST() and CONVERT() cousins.

That said, Steve’s example reminds me of a PolyBase demo I used to do, in which I took a CSV of North Carolina populations by county and read in the information. In that particular dataset, they would use the letter “A” to describe either “Not enough people to show an answer without potentially violating PII” or “We don’t know what the answer is.” So even though it was clearly a numeric attribute in “Population,” the output process overloaded the definition of that attribute and the only way you would know is to happen to see the three rows in ~1500 that happened to have an A in the column value.

Leave a Comment