A Quick Trip

I’m sure some of you have gone on a quick business trip before, maybe even regularly. I’ve had a lot of travel over the last few years, and quite a few short trips to various cities for events or customer visits. I’m expecting a few other stretches this year that will be busy, but not like this.

I’m off to London today, actually I left last night, and I’ll be there around 940a local time today. I am jumping on an 1130a flight Wednesday to return, so this will be a 50 hours trip to London. I’m going for the Redgate Summit, and I’d usually make this a week trip and get to the office in Cambridge, but I am bookended by prior commitments.

Yesterday (Sunday) had to coach a team at a volleyball tournament in Denver. This coming weekend, I need to be in New Orleans Friday to coach over the weekend. I guess I could try to stay one more day and get to Cambridge, but I would like a minute to decompress at home. So back Wed and head to New Orleans for the weekend.

Fortunately this type of trip is a rarity, but it has happened a few times in the past and I’m sure it will happen again.

Posted in Blog | Tagged | Comments Off on A Quick Trip

Tracking Table Sizes

Managing a production database can be a challenge for many reasons. However storage growth has been one I see often as causing issues. From full logs to filled disks, it seems that we can struggle with dynamic workloads where we have no control over who can add data to systems.

Many DBAs have some sort of alert set on data files or disks, but even with those alerts, an unexpected load or runaway query could still fill a disk. I know I’ve been called back into the office because some business person decided to load an unexpected amount of data. In fact, more than a few times someone thought their load didn’t work for some reason and repeated loaded a large amount of data, filling a disk or log file.

Recently, I had a customer ask about tracking table sizes daily in their databases. They were looking to watch table growth. Another person dismissed this as not valuable, which was interesting to me. I’ve done this in the past, and I’ve found it valuable. No knowing the size every day, but having an idea of the growth factor. I didn’t keep this data long, usually a week rolling older data off as I added more. That was enough for me to trend how quickly a table was growing.

This also allowed me to set an alert if there was unusual growth for a table, and often track down a potential issue quickly. Either I’d realize our workload changed and tables were growing faster, or I could debug a sudden growth issue down to some sort of data load. Often I could catch an issue before I received an alert (or phone call).

I wonder how many of you track table sizes and if you find it beneficial. Is this something that helps you better understand your system or is the total size of the database good enough.

Or maybe you have so much storage allocated you don’t worry about space. Lucky you.

Steve Jones

Listen to the podcast at Libsyn, Spotify, or iTunes.

Note, podcasts are only available for a limited time online.

Posted in Editorial | Tagged | Comments Off on Tracking Table Sizes

A New Word: Waldosia

waldosia– n.  a condition in which you keep scanning faces in a crowd looking for a specific person who would have no reason to be there, as if your brain is checking to see whether they’re still in your life, subconsciously patting its emotional pockets before it leaves for the day.

This is an interesting word to me, and I find myself in waldosia at volleyball tournaments looking for past players. I think it’s a shadow of a desire to see a player I’ve coached in the past and hoping they had made time to come.

This happened recently as I was up in Greeley, CO at a tournament. I have a few former players at CSU, which isn’t far. I somehow hoped I’d see a former player, but they would have no reason to leave college and come, especially early on a weekend morning.

I probably have waldosia at SQL Saturday and other events, sometimes looking (hoping) for a friend that might pop by the event, even if I know they might have moved on in their career.

From the Dictionary of Obscure Sorrows

Posted in Blog | Tagged , | Comments Off on A New Word: Waldosia

A Couple Quick GENERATE_SERIES Tests

I had someone reach out about generate_series() recently, saying they hadn’t realized this was a new feature in SQL Server 2022. They were wondering if it was better than using a tally table.

I didn’t want to do an exhaustive test, but I thought I’d take a minute and try a couple simple things just to see.

A First Test

The first thing was to just generate a million numbers. Rather than just get the numbers. I decided to use a quick DATEADD() to create a list of calendar dates. Here’s the code:

SET STATISTICS IO ON;
SET STATISTICS TIME ON;
-- Create a Tally table with 1 million numbers
WITH Tally (n)
AS ( SELECT TOP (1000000)
             ROW_NUMBER () OVER (ORDER BY
                                   (SELECT NULL)) AS Number
      FROM
        master.dbo.spt_values a
        CROSS JOIN master.dbo.spt_values b)
SELECT DATEADD(DAY, n, GETDATE())
  FROM tally

SELECT DATEADD( DAY, value, GETDATE()) FROM GENERATE_SERIES(1, 1000000, 1)

Since this does read from tables, I ran it twice. The first time, the tally table took 243ms, so I re-ran it and saw this drop to 172ms. The results were consistent for Generate_series, which was 110ms.

2025-02_0343

A Second Test

I grabbed Jeff Moden’s code for random numbers and adjusted a second query to use GENERATE_SERIES(). The code is below.

SET STATISTICS IO ON;
SET STATISTICS TIME ON;

--===== Declare some obviously named variables
DECLARE @NumberOfRows INT,
@StartValue   INT,
@EndValue     INT,
@Range        INT
;
--===== Preset the variables to known values
SELECT @NumberOfRows = 1000000,
@StartValue   = 400,
@EndValue     = 500,
@Range        = @EndValue - @StartValue + 1
;
--===== Conditionally drop the test table to make reruns easier in SSMS
IF OBJECT_ID('tempdb..#SomeTestTable','U') IS NOT NULL
DROP TABLE #SomeTestTable
;
--===== Create the test table with "random constrained" integers and floats
-- within the parameters identified in the variables above.
SELECT TOP (@NumberOfRows)
SomeRandomInteger =  ABS(CHECKSUM(NEWID())) % @Range + @StartValue,
SomeRandomFloat   = RAND(CHECKSUM(NEWID())) * @Range + @StartValue
INTO #SomeTestTable
FROM sys.all_columns ac1
CROSS JOIN sys.all_columns ac2

SELECT TOP (@NumberOfRows)
SomeRandomInteger =  ABS(CHECKSUM(NEWID())) % @Range + @StartValue,
SomeRandomFloat   = RAND(CHECKSUM(NEWID())) * @Range + @StartValue
INTO #SomeTestTable2
FROM GENERATE_SERIES(1, @NumberOfRows, 1)

When I ran this, I see these results:

2025-02_0344

Execution times are close. Slightly faster with GENERATE_SERIES(), but fairly consistent across runs. In running this 10 times, there were 3 runs where the tally table was faster, and once just under 300ms. A few times the time was the same, but always within 15-16ms. Not sure that means much.

This isn’t a really exhaustive test, and don’t take this as a recommendation either way for your code. Test how they both work in your system, and certainly think about the impact of storing a tally table vs. generating one on the fly vs the GENERATE_SERIES().

However, it seems that GENERATE_SERIES() is worth looking at if you are on SQL Server 2022 or later.

Posted in Blog | Tagged , | 2 Comments