The first article in the book has this title, which might seem strange, but the short piece then talks about how many Redgaters, as we call ourselves, love working for the company and tell our friends how great a place this is to work.
The question it asks is why is Redgate great? It’s not the benefits, the gatherings, the fun things, the inside jokes. It’s not even the open, collaborative way or working, the no BS no politics attitude. It’s not anything that’s easy to put into words.
It’s really the culture, which is hard to describe. It’s like a family, which is similar to what I felt at J. D. Edwards as well. We have good and bad, we have disagreement and arguments, but overall we’re all in this together.
We’ve grown since then, and it’s a different place, but it’s still a great place to work and one that I hope I stay with until I retire.
I have a copy of the Book of Redgate from 2010. This was a book we produced internally about the company after 10 years in existence. At that time, I’d been there for about 3 years, and it was interesting to learn a some things about the company. This series of posts looks back at the Book of Redgate 15 years later.
In a week I’m heading to London for the Redgate Summit. I enjoyed these last year and had some very interesting conversations with customers, prospects, and a few Redgate fans.
This year the event is on Mar 11 at the Tottenham Hotspur Stadium, which should be fun given that I’ve been re-watching Ted Lasso (I still need to make a pilgrimage to Richmond…).
The schedule has a variety of tracks for leadership and tech people. There are even some breakfast sessions if you want to learn more about Oracle or PostgreSQL. I’ve got the keynote session and a panel for leadership on my agenda.
Check out the video from last year, and register to come this year. I’ll see you in London next week.
Virtual Log Files (VLF) are sections inside of your physical log file (.ldf). These have no fixed size or number per file, but there can be many. The architecture of the log is explained in this doc and it varies according to a number of factors.
That doc also explains there are issues with too many VLFs inside of a log file. There are plenty of other posts about this (Brent Ozar, Kimberly Trip) and it is somethin you want to keep track of.
Redgate Monitor changes and grows every week with new releases and one of the resent releases (14.0.41) included a new alert for VLFs.
To configure this, select the gear icon in the upper right of Redgate Monitor.
On the configuration page, select the Alert settings. This will bring you to the details for your alerts.
There are a number of items on the Alert Settings page, but scroll down to the bottom of the SQL Server Alerts section. The Virtual log file count is the last alert.
The default setting is to raise multiple alerts here. The settings are:
low: 100
medium: 300
high: 1000
These may or may not be appropriate for your system, and for me, I don’t know I’ve ever had time to worry about this and I might disable a low level alert and only have two, but you can decide what’s important to you.
The important thing is that if you worry about VLFs in your environment, you can get alerted and track this over time.
Redgate Monitor is a world class monitoring solution for your database estate. Download a trial today and see how it can help you manage your estate more efficiently.
A previous post showed how add starting tables for the subsetter to look at, however that didn’t get me a good data set for testing. This post continues looking at the subsetter by adding manual relationships to our configuration.
In my previous post, I’d picked a starting table and had reduced the dbo.players table from 16564 to 1800. However, I only had player information. If I query my subset database, I see there is a player, but I have no batting statistics for this player.
This is because my table has no declared FKs in it. If I check the dbo.batting table, I can see only a PK.
Let’s fix this.
Declaring Manual FK Relationships
In the options file documentation, there is a section that notes manual relationships can be declared with a key called “manualRelationships”. If I copy/paste the example section into my options file, I’ll see this:
I don’t have a SourceTest table, so let me edit things. I’ll set a relationship between dbo.players.playerID and dbo.batting.playerID. This gives me the following in my options file.
Before I run my subsetter, here are the row counts by table.
I’ll re-run this subset command, which includes my option file at the end.
rgsubset run --database-engine=sqlserver --source-connection-string="server=localhost;database=BB_FullRestore;Trusted_Connection=yes;TrustServerCertificate=yes" --target-connection-string="server=localhost;database=BB_Subset;Trusted_Connection=yes;TrustServerCertificate=yes" --target-database-write-mode Overwrite --options-file E:\Documents\git\TDM-Demos\rgsubset-options-bb.json
When I do that, I know see these row counts. Note I now have batting rows.
My player query won’t work, so I still need to declare another relationship with the dbo.teams table. That is shown below:
I can re-run the same command above, and then I see this set of rowcounts (original on left, subset on right).
There is teams data, and if I re-run my queries from the top, I can see stats now.
Now I have a dataset that I can perform development work with in terms of players, teams, and batting.
I can also add more relationships as needed, for example, I’ll add this section to include pitching, batting post, and fielding. Here’s my complete options file:
After re-running the subsetter, I have these row counts. Note there are rows in all the tables defined in the options file.
I can keep adding in more tables as needed to ensure the subsetter can walk down the data relationships I need in my database to produce a useable dev/test dataset that’s smaller than production.
TDM can help your devs build better software and with the subsetter, this can create lots of agility to ensure the data you need to accurately build this software is available.
Give TDM a try today from the repo and a trial, or contact one of our reps and get moving with help from our sales engineers.