The next day, we have an election and tariffs are announced on imported parts. We react immediately, cancel the order, start the process to expand a local factory. We place ads to hire workers and order equipment. Things are looking good for our business and our factory will be up and running in a few months.

The next week we find out the tariffs weren't really being enforced, so they're paused. Our AI agent re-places our large order for imported parts and tried to cancel the factory expansion. Of course, it calculates the costs of both sides before deciding, and perhaps consults with me on other uses of our local factory.

How many times can we do this? Or rather, how many times would we let an AI agent keep adjusting our business?

To be fair, humans might do the same thing and over-react, but mostly we become hesitant with unexpected news. That slowness can be an asset. We often need time to think and come to a decision. Lots of our decisions aren't always based on hard facts, and a lot of business isn't necessarily fact driven either. We often put our thumb on the scales when making decisions because there isn't a clear path based on just data.

Things can get worse when we collaborate. I used to run real-time reports for an importing company, and we found that executives would print a report, get busy, and after minutes (or hours), discuss the report with someone in a department. However, their numbers rarely matched because the reports were printed at different times. At first they lost trust in the system because the same report on the same day had different numbers. Even when we added a "print" or an "as of" time, the reports were too annoying to users to be helpful because the numbers didn't match.

Real time isn't what most of us want. Except in the Olympics. There we want the photo finish right away. But not in all sports. A review is good. In the NFL, I've come to like instant reply. It's gotten better/faster and often gives us the right answer. Not always, but often. It's better, arguably, then just real-time humans.

Real-time decisions and reactions can be good in some cases. Adjusting machinery, vehicles, electricity, etc. where we need too-quick-for-humans decisions based on data is a good place for real time data. Lots of business decisions we make aren't the places where we really need real-time insights. Our human brains just don't work that fast.

The post How Important Are Real Time Decisions? appeared first on SQLServerCentral.

It's simple right?

It can seem confusing, and at times I've wished Microsoft would make it simpler. And perhaps even give us some add-ons, like adding some additional hardware capabilities (cough more RAM *cough) in SE.

Then I run into something like the introduction to Oracle licensing. This is one of the smaller guides on a site devoted to Oracle licensing. There are numerous articles on there, with lots of information, perhaps too much, to help anyone get a handle on this process. There are even companies (one, two) built around helping you manage Oracle licenses.

There's a core factor table, where you need to figure out how to adjust your "license cost" based on the CPU. That's after you pick the edition, and likely before you go into the other features you might need. I'm guessing this is why a lot of people might just pay for the Unlimited license and stop worrying. I think this is also why Oracle is still such a huge company and worth billions (or trillions?) of dollars.

I actually asked Claude to help me with Oracle licensing. I got these (partial) results, which talks about the different core licensing, editions, and then other costs. As I ask for more details in any area, this gets very complex and confusing. While some of the rules for SQL Server can be confusing, and certainly the HA and virtualization guidelines sometimes leave something to be desired, overall, I find things simple.

I like simple.

Over the years, many software companies have made licensing more complex and confusing to customers. Often this results in more profit for them without much benefit for the purchaser. Not all vendors do this, but Oracle certainly has created a complexity that spawned a whole business model for a few companies. SQL Server licensing is simpler, and I've learned to appreciate that.

The post SQL Server Licensing is Simple appeared first on SQLServerCentral.

1. small data, small compute (most CRUD app queries)
2. small data, big compute (complex BI queries for this quarter, most reporting)
3. big data, small compute (logs, audit data)
4. big data, big compute (complex BI queries across all our data)

If you examine the costs here, 1 is the cheapest, with 2 and 3 having a similar cost. Number 4 is expensive, and it's why we often have big boxes running our database server software. However, where is most of our work? The majority is in quadrant 1, with 2 getting the second most action. 3 might rarely exist, as does 4, but we often design for 4. We have to as we don't want phone calls, ever. What we want is to provision a system large enough that we don't hear many complaints about performance. On premises, many of us have over-provisioned systems to handle the peak load to avoid phone calls.

Can we handle the peaks or the really important things that someone thinks are important? Everyone thinks their workload is important, and it is. To them. However, there are plenty of cases where someone could think about designing for specific types of workloads, rather than just aiming for quadrant 4. I've got an image of different types of workloads that I grabbed from the Small Data 2025 conference. For example, if I am working with things like Time Series data or streaming analytics, I might not need huge compute. I might be storing a lot of data, and I need space, but the compute is low. The analysis of that data, however, might be compute intensive.

This is a reason why we might separate analytic systems out as they often are in quadrants 2 and 4, and we might want serverless or scale up/down systems to handle the rare cases, and get a real cost for them. I found it particularly interesting that the Bronze tier might be where we have big data and big compute, but once we've moved to Silver or Gold, we might have lower compute and data requirements. This makes sense as Bronze is more staging, but it is a good reason why we might aim for a Gold layer in our organization and only keep that data for the long term; it's more cost-effective.

Often, for simplicity, we build a bigger system for all types of queries. In other words, we are letting corner cases drive our design. That might be required, but it might not be. In this area of cost concerns, especially in the cloud, designing systems with appropriate resource usage is something that might override the analyst's desire for queries across all data running as quickly as order lookups in an OLTP system. This might be even more true if we can predict some patterns in our workloads during system design. We can't scale up or down instantly, but in a lot of places, I wish I had been able to scale financial or reporting systems up for a few days as we close out the period and scale them down for the rest of the month.

When building a system, think about the practical nature of your requirements and assign a cost to them. Let users know what workload you're building a system to handle and set expectations on performance and cost. If you do that, you can let others decide when we handle corner cases and when we don't. That's often a much easier conversation when we have cost numbers to help customers understand the implications of their request.

The post Don't Let Corner Cases Drive Your Design appeared first on SQLServerCentral.

First, FinOps is not a new concept. We have been doing the core work for most of our careers, and I have been speaking to people about this for years. There have been conference sessions from luminary speakers in the data community like Paul Randal, Kendra Little, Eric Darling, and many others at events for years. Right about now you are probably thinking, I don’t remember seeing or hearing them talk about FinOps…

That is because FinOps is all about performance tuning our workloads, getting the most efficient usage out of the resources we allocate to run these workloads. The only real difference is that now we have much better cost visibility through virtualization platforms and cloud. Historically we only had limited opportunities to optimize our spend, if we were buying hardware for a three- or five-year lifecycle then most of the work was concentrated around those refresh cycles. Now, our ability to create and scale resources on-demand and see the costs change almost monthly means that we can also affect it monthly.

Things that came up as top of the list for FinOps practices in my conversations were.

• Monitoring seasonality of workload so you know when to scale up/down or out/in based on resource needs.
• Turning off what is not being used.
• Performance tune queries to be as efficient as possible.
• Shift performance analysis left into development, understand the resource profile of the app and define what is an acceptable increase for a release to consume.

There are nuances to all of these and the wider processes, but this is all something that we are familiar with. So, when someone comes along and starts telling you about the latest and greatest trend called FinOps you can say that you’re familiar with it and have been doing parts of that for years.

It would be great to hear about whether you have access to all the things you need to move towards FinOps models, or about a time when you tuned a query that freed up a load of resources to the system.

The post FinOps - the new name for performance tuning appeared first on SQLServerCentral.

The format for the conference is a little different, with 3-5 talks in a row, all on one stage, each about 25 minutes long. These are talks with or without slides, but no live demos, just speaking and expressing a point of view. What I found fun was that each person picked their own music to play as they walked onto stage (or ran/danced in the case of Glauber from Turso). It was a bit of fun, with the DJ letting the music play as the person made their way to the front and were welcomed by the audience. I heard rock, metal, hip hop, and more.

It's Friday during the week of the PASS Data Community Summit, and I had the chance to deliver part of the keynote on Wednesday. I've done this before, and no one has every asked me if I wanted a pick a piece of music, but it got me thinking. What would I pick?

For a fun Friday during the holiday season, think about if you were going to give a presentation. Maybe to your team, maybe other groups in the company, or (for some of you) on a conference stage. What music would you choose to accompany your walk into the bright lights? Imagine you get between 10 and 30 seconds.

Have some fun, and remember this is a professional setting. My first thought was something from the Notorious BIG, but I realized I'd have to walk fast as most of his lyrics wouldn't be appropriate. I'm not sure, but I lean towards one of these: one, two, three, or four.

The post What's Your Theme Music? appeared first on SQLServerCentral.

My initial reaction was "that's right."

Then I thought about software, and poor queries impacting database performance, and thought, "No, that's not right." My next reaction was to think maybe it's "done is better than great". I do see plenty of engineers trying to build great software. Code that would impress their peers or their former professors. Or maybe their future self.

Then I thought, no, Elizabeth is right. If things don't get done, then what's the point?

At the same time, I think that "done" and "good" (or great) aren't mutually exclusive. We can get things done and make them great, which is something to strive for. We can also get good things done.

Sometimes.

Sometimes we don't have that luxury of time, for various reasons. If I had to make a trade, I push for good (or quality) as much as possible if the delay isn't substantial. If it is, then done is likely the choice I'd make. I do try to return and refactor, improve, etc. to raise the quality over time, but I recognize that sometimes getting something done is important. Certainly, on the ranch, I need to fix things to get by, with the aim of doing a better job later. I have mixed success at returning to improve a patch with a better fix later, but so far, that's worked well. I'd say the same thing has happened while building software or managing systems, with enough success to be comfortable with my choices.

What about you? What choices have you had to make about being done over delivering something that's good? Or maybe great.

The post Done is Better than Good appeared first on SQLServerCentral.

There's a fascinating piece over at O'Reilly that looks at what we might consider Artificial Intelligence (AI) to be. The discussion looks at Deep Blue, Watson, and AlphaGo, all of which have defeated humans in game competitions where we might expect some intelligence is needed. We could argue that, but certainly, these computing machines have done more to display knowledge than the best humans at certain endeavors.

What is interesting is that each of these machines, while very competent in its area, is specialized. AlphaGo can't play chess, nor can DeepBlue play Go. Each has been tuned to a specialized area, and also trained to excel in that area. This isn't fundamentally different than humans that train and specialize themselves, though certainly we find humans have more capabilities in a general sense (for now) than machines.

As we look to grow intelligence, however, there is one thing that's commonly needed in both artificial or machine intelligence and human intelligence: data. Whether a human is training themselves to solve a particular problem, compete in a game, or even excel in a sport, they need lots of data. We gather this with our senses as well as by examining what others have one, contemplating actions, trying out different actions, ideas, or concepts, and then adjusting to improve.

This is what researchers are also trying to do with gaming machines, with self-driving cars, and even with bots. That last item is interesting to me, as I haven't paid much attention to bots. A long conversation with another SQL professional got me interested in, and intrigued by, the idea of software robots that might handle various complex tasks better than the FAQ method that so many applications and websites use. I wasn't sure these would be useful, but I have found the Slackbot to be more helpful than the help or searches for some tasks.

There's work to be done, and I know the Slackbot (and other machine intelligence software) needs to be trained better. This requires data. Lots of data, and possibly lots of hand holding from a human. For many areas, such as relatively low-level customer support or problem solving, I wonder if a bot could be trained to work better than the simple decision tree algorithms like those found in the Windows Troubleshooter.

There are various ways we might grow this software to help us, and make no mistake, we will need to grow it. Plenty of businesses are becoming excited about machine learning, the R language or Python, software bots, and more. In all the cases of implementing these systems, the one demand that will impact many of us is the need for lots of data. Data that's organized, that is relevant, that we can use to separate out successes from failures, and evaluate our particular problem better. We will need to group data into knowledge and then feed it into software.

I think this is a bit different than how most of us have used data over the years. We've often collected, manipulated, aggregated, summarized, and spit data back out to (ultimately) some human that can make a decision. Most of us haven't worked with sending data to a machine intelligence and somehow then helping it to understand how to respond on make a decision.

My suspicion is there will be lots of work for us in the next decade in helping machines to use data and understand it, maybe even to use them to help us gather, organize, clean, and manipulate data better ourselves. It's an exciting time to be a data professional, and I'm sure some of you will work on a few very exciting projects in the future.

The post Growing Artificial Intelligence appeared first on SQLServerCentral.

A table with a primary key

On the second day of Christmas my new DBA sent to me

Two Foreign Keys, and

A table with a primary key

On the third day of Christmas my new DBA sent to me

Three stored procs

Two Foreign Keys, and

A table with a primary key

On the fourth day of Christmas my new DBA sent to me

Four database roles

Three stored procs

Two Foreign Keys, and

A table with a primary key

On the fifth day of Christmas my new DBA sent to me

Five execution plans

Four database roles

Three stored procs

Two Foreign Keys, and

A table with a primary key

On the sixth day of Christmas my new DBA sent to me

Six unnested views

Five execution plans

Four database roles

Three stored procs

Two Foreign Keys, and

A table with a primary key

On the seventh day of Christmas my new DBA sent to me

Seven maintenance jobs

Six unnested views

Five execution plans

Four database roles

Three stored procs

Two Foreign Keys, and

A table with a primary key

On the eighth day of Christmas my new DBA sent to me

Eight tables to remove

Seven maintenance jobs

Six unnested views

Five execution plans

Four database roles

Three stored procs

Two Foreign Keys, and

A table with a primary key

On the ninth day of Christmas my new DBA sent to me

Nine unit tests

Eight tables to remove

Seven maintenance jobs

Six unnested views

Five execution plans

Four database roles

Three stored procs

Two Foreign Keys, and

A table with a primary key

On the 10th day of Christmas my new DBA sent to me

Ten database containers

Nine unit tests

Eight tables to remove

Seven maintenance jobs

Six unnested views

Five execution plans

Four database roles

Three stored procs

Two Foreign Keys, and

A table with a primary key

On the 11th day of Christmas my new DBA sent to me

Eleven Extended Events

Ten database containers

Nine unit tests

Eight tables to remove

Seven maintenance jobs

Six unnested views

Five execution plans

Four database roles

Three stored procs

Two Foreign Keys, and

A table with a primary key

On the 12th day of Christmas my new DBA sent to me

Twelve tickets already closed

Eleven Extended Events

Ten database containers

Nine unit tests

Eight tables to remove

Seven maintenance jobs

Six unnested views

Five execution plans

Four database roles

Three stored procs

Two Foreign Keys, and

A table with a primary key

The post The DBA's Twelve Days of Christmas appeared first on SQLServerCentral.

I saw a someone post a question recently about solving a T-SQL problem. One of the answers given used a tally table, which the original poster didn't understand. A few follow up links pointed them in the right direction, but it got me wondering.

How many of you know what a tally table is and how to create one? I bet a few of you don't, which might mean you've never had the need. Or it might be a hole in your skill set and you didn't realize that a tally table can be very useful in solving a number of problems. Anything from generating dates to splitting strings. There are plenty more ways to use one, and feel free to mention more in the comments that others might not have tried.

I'm not sure the tally table is a core T-SQL skill, but I think it's an important one you should learn as you grow your skills. After you've mastered the basics (Insert/update/delete, aggregates, outer joins) Adding in an understanding of window functions, the APPLY operator, and CTEs are also important to allow you to become better at solving the problems you run into with more efficient T-SQL.

The post The Tally Table appeared first on SQLServerCentral.

I ran across a great quote that made me laugh, but also struck me as being quite true. The quote is from Scott Curie's post on the PASS Summit Speaker's Contract and goes like this: "You would laugh at a lawyer who tried to build their own data warehouse, so why would you try to write your own legal agreement?" Having used lawyers for a few contracts, I am well aware that I'm not remotely qualified to put together a detailed contract. I know if I need a business agreement, I need to either use a lawyer or make it really simple. "I'll cut your grass, and you'll give me $25" is probably the last well-written contract I wrote.

We all have strengths and useful skills, things we are really good at performing. We often improve those skills over time and may develop some level of expertise in our field. However, even if we were the best T-SQL coder in the world, or the hands-down, acknowledged world-renowned expert on replication, that wouldn't mean that we necessarily had any skill in some other area of the SQL Server platform, such as Integration Services. We might know something, we could learn, and certainly be competent quickly, but would a company that had a mission-critical, multi-TB import or export of data want us to patch their ETL process today? Probably not.

Usually, when we have a problem with a specific technology, we want someone who knows that technology well to guide us or do the work. The same thing is true in business. If an inventory specialist questions the way some system works, or a financial guru wonders about the calculations in an application, we should defer to them and ensure that we can explain how the code works, double-checking the accuracy. After all, specifications could contain bugs as easily as code, and an expert in the end user of software might have a better idea of whether a system is working properly than the developer.

We should remember that when we venture outside of our own area of specialization. Many technology professionals are quite intelligent, but they aren't going to be experts in all problem domains, and they shouldn't present themselves as such.

The post What's Your Area of Expertise? appeared first on SQLServerCentral.