As I sat there, I ended up reflecting back on 2025. I found myself gravitating to these three questions:

• What went well this year?
• What did I learn?
• What should I focus on next year?

If you’re a leader, I’m guessing you rarely get this kind of thinking time during your workday. I know I don’t. Our calendars are packed with calls, team meetings, and those “quick questions” that turn into two-hour troubleshooting sessions.

But here’s what I’ve learned: the quality of your strategic decisions is directly tied to the quality of your thinking time.

And thinking time doesn’t happen by accident. You have to protect it.

What Went Well This Year?

When I asked myself this question, I didn’t think about our biggest projects or flashiest achievements. I didn’t think about when we migrated almost 2,000 databases as part of an upgrade project. Or the performance tuning we did that resulted in a $36,000 reduction in annual Azure spend for a client.

Instead, I thought about the relationships we strengthened. The trust we built with clients. The problems we solved before they became crises.

For you, this might look like:

• The audit that went smoothly because your security documentation was solid
• The successful disaster recovery test that was possible because you kept refining the process
• The team member you mentored who’s now ready for more responsibility
• The support resources you provided your team through a trusted partner

These aren’t always the things that make it into board reports. But they’re the foundation that everything else is built on.

What Did I Learn?

This year reminded me of something Eisenhower once said: “Plans are worthless, but planning is everything.”

The need for planning cannot be overstated. It’s critical. Even if the plan doesn’t always work out the way you intended.

The plan itself wasn’t the point. The thinking I did while creating the plan was the point.

Because I’d thought through our capacity, our ideal client profile, and our service delivery model, I could adjust quickly when reality didn’t match my spreadsheet. I knew which opportunities were a good fit for us and which ones to let go. Because we’ve intentionally built a small but incredibly talented team that genuinely wants to see our clients succeed, we were able to identify and create ways to help them.

I watched the same dynamic play out with clients. The institutions that had documented their SQL Server environments, tested their disaster recovery plans, and mapped their compliance requirements adapted quickly when needed. They were positioned for success even when the unexpected happened.

Planning isn’t about predicting the future. It’s about building the muscle memory to respond when the future surprises you.

What did you learn this year about planning and adapting? Maybe it was:

• That your three-year technology roadmap needs quarterly reviews, not just annual ones
• That the disaster recovery plan sitting in a SharePoint folder isn’t the same as a tested DR plan
• That “we’ll address that next quarter” eventually becomes “why didn’t we address this sooner?”
• That having an expert on call beats having a plan to find an expert when something breaks

These lessons matter. Write them down. They’re not just hindsight—they’re your blueprint for better decisions ahead.

What Should I Focus On Next Year?

For me, the answer was clear: I need to help more financial institutions and healthcare organizations understand that they have options. Most CIOs think they have two choices for database management: hire a full-time DBA (expensive and hard to find) or make do with whoever can “figure it out” (risky and unsustainable).

There’s a third option: fractional DBA services that give you expert oversight without the full-time price tag.

For you, your focus might be different. Maybe it’s:

• Finally getting your SQL Server environment documented and audit-ready
• Building a disaster recovery plan that you’ve actually tested
• Move a little further along the SQL Server Maturity Curve
• Finding a partner who understands banking compliance, not just databases

Whatever it is, the key is to actually choose something. Not everything. Something. And move toward it. Make progress.

The Power of Quiet Reflection

Here’s the thing about those early Saturday morning moments: they’re rare. And precious.

During the week, we’re in execution mode. We’re responding, reacting, solving, and fixing. That’s necessary work. But it’s not strategic work.

Strategic work requires space. It requires stepping back from the urgent to focus on the important.

So, here’s my challenge to you as we wind down 2025 and usher in the new year:

Block Off Time Just to Think, Then Protect It

Maybe it’s Saturday mornings before your family wakes up. Maybe it’s a long walk at lunch. Maybe it’s 90 minutes with your calendar blocked and your office door closed.

Whatever it is, protect it. The decisions you make during that quiet time about where to focus, what risks to address, and which partnerships to invest in will help shape your entire year.

Your Turn

As you think about the year ahead, I’d encourage you to ask yourself those three questions:

1. What went well this year? Celebrate it. Learn from it.
2. What did I learn? Write it down. It’s wisdom you paid for.
3. What should I focus on next year? Pick one or two things. Not everything.

And if one of those focus areas is “finally get our SQL Server environment to a place where I’m confident, not just hopeful,” let’s talk. That’s exactly what we help institutions do.

If you’re a CIO wondering whether your SQL Server environment is as healthy and secure as it should be, I’d be happy to have a conversation. No sales pitch. Just two people talking candidly about database management. Schedule a time here.

The post Why Quiet Reflection Leads to Better IT Strategy Decisions appeared first on The SERO Group.

Whether you’re migrating to a new platform, upgrading legacy infrastructure, or implementing new security and compliance protocols, your SQL Server partner isn’t just a vendor—they’re a strategic collaborator.

So, what should you expect from a SQL Server partner during your next core banking upgrade?

The Best SQL Server Partners for Core Banking Upgrades Deliver:

1. Deep SQL Server Expertise and Core Banking Systems Familiarity

Core banking environments are complex. They handle everything from transaction processing and customer account management to regulatory reporting and data security. Your SQL Server partner must understand not only the technical architecture but also the core banking systems’ operating requirements.

Expect your partner to ask the right questions about your environment, your data dependencies, your peak usage times, and your business continuity and recovery needs. The best SQL Server consultants come equipped with industry experience and a blueprint for helping banks navigate change.

Core banking system providers are experts in their own software, but they’re not always expert SQL Server administrators. That’s where a specialized SQL Server consultant adds value. They ask the right infrastructure questions, including about Recovery Point Objectives (RPOs) and Recovery Time Objectives (RTOs). These metrics help ensure your SQL environment supports your business continuity and disaster recovery needs. A knowledgeable SQL partner can turn those objectives into strategies like point-in-time recovery, automated failover, and high-availability design.

2. Rigorous Planning and a Clear Project Timeline

A core banking database upgrade isn’t something to approach casually. Your SQL Server partner should help you scope and sequence every phase of the upgrade, including:

• Environment assessments and baseline performance benchmarks
• Compatibility testing with the new infrastructure
• Backup and restore strategies for rollback protection
• Performance settings recommendations
• Cutover planning and go-live support

Look for partners who can produce a detailed project plan and who proactively manage timelines, milestones, and communication. You shouldn’t have to tolerate surprises—and neither should your customers.

3. Zero-Downtime (or Near-Zero) Migration Strategies

Unplanned downtime in core banking systems means customer impact, reputational risk, and possible regulatory scrutiny. SQL Server partners should be able to offer strategies that minimize or eliminate unexpected downtime through:

• High availability (HA) and disaster recovery (DR) design reviews
• Pre-migration dry runs to simulate live scenarios
• Staged cutovers during low-usage periods

Expect your partner to not only explain these strategies but also test and validate them in your environment before launch day.

4. Compliance and Security Oversight

With the FFIEC sunsetting its Cybersecurity Assessment Tool and CIS® Benchmarks™ gaining ground as the new standard, your SQL Server partner must be fluent in financial data security requirements.

They should review your SQL Server configuration for gaps, recommend security hardening, and help you prepare for both internal and external audits. This includes:

• Encrypted backups and secure storage
• Role-based access controls
• Configuration baselines aligned with best practices
• Detailed documentation for compliance reviews

5. Post-Upgrade Monitoring and Support

A good partner doesn’t just help you upgrade. They help you meet your regulator with confidence.

The job isn’t finished when the core system goes live. The first few weeks post-upgrade are critical. Your SQL Server partner should offer extended support to monitor system performance, resolve unexpected issues, and ensure optimal database operation.

Banks should expect:

• Real-time monitoring for performance and error trends
• Rapid-response troubleshooting
• Ongoing patching, maintenance, and tuning
• A smooth transition to in-house teams or ongoing DBA-as-a-Service

This post-upgrade care is what separates good partners from great ones.

Choose a Partner Who Understands Banking

A core banking upgrade isn’t just technical. You need a partner who is not only steeped in SQL Server but also understands your industry, speaks your language, and can deliver with precision. At The SERO Group, we specialize in helping financial institutions modernize their SQL Server environments while prioritizing SQL Server health, security, and reliability.

If you have an upgrade to core banking system on the horizon, let’s talk. We’ll help you plan, execute, and support your transition—every step of the way.

The post Choosing the Right SQL Server Partner for Your Core Banking Upgrade appeared first on The SERO Group.

Goals for your SQL Servers

Although every environment is unique and each business has its own set of important measures for success, here are five goals for your SQL Servers to consider as you plan the coming months. These goals are designed to help build a robust and responsive data infrastructure to support your organization.

1. Assess your SQL Servers
2. Update your SQL Servers
3. Start performing health checks
4. Implement monitoring and alerting 
5. Review your Disaster Recovery plans

Goal 1: Assess your SQL Servers

Whether you’re responsible for one SQL Server sitting in a server room next to you or hundreds of SQL Servers spread around the world, it can be difficult to keep up with the exact configuration of each SQL Server. This is especially true if you’re time is split. For example, when you’re a network administrator, web developer, or systems admin who is also tasked with taking care of the SQL Servers in your spare time.

Uncertainty about the patch level, configuration, and health of each or your SQL Servers creates stress and unease. Doubts creep in.

Do any of these internal dialogs sound familiar? 

• Are the SQL Servers behind on patching? Probably, I’m not sure, but they are working, right? (See Is There an Update for My SQL Server?)
• Are the SQL Servers configured optimally? Probably not. I’ve been meaning to do some research and check. But at least no one is complaining right now. And no new is good news? (See Is My SQL Server Configured Properly?)
• Are the databases healthy? I remember setting up some maintenance jobs a while back, I think. If they weren’t healthy, I’m pretty sure I’d know. 
• We pay a maintenance fee to the application vender. Does that include applying SQL Server updates? I’m not sure.
• Ok, I really should have a look, but ugh, when? 

Now is that time. The new year brings with it an opportunity to examine each of your production SQL Servers to see if they are configured optimally.

So what should you check?

Examine the log files, the configuration settings, the maintenance jobs, the performance DMVs, and patch level of each of your critical servers. Do you have the right number of tempdb files? Do you have any unneeded services running? Are there an excessive number of waits being reported? Are you still using the default values for MAXDOP and Cost Threshold for Parallelism? Etc?

Look for areas of concern, and there will likely be some, and prioritize resolving them. 

Not sure where to start? We can help – Getting Started with a SQL Server Assessment.

Goal 2: Update your SQL Servers 

Once you’ve assessed your SQL Servers, you know your starting point. You know the overall health of each instance. Next, make a plan to address or remediate the instances as needed. 

Start with the most important servers first and attack the Priority 1 issues as soon as you can. The P1 issues are those items that are of grave concern due to security and data integrity, recoverability, and availability. 

“As soon as you can” will mean different things to different organizations. Some environments allow minor changes and patches directly to production servers during off hours. For example, want to apply the latest CU? “Sure. Anytime after 7:00 PM Thursday will be fine.” 

Other businesses have a more standardized process in place. Make a remediation plan; confirm with application venders; present the plan to the Change Control Committee for review, deconflicting, and sequencing; apply the changes to a lower level environment; confirm with the QA team that the changes didn’t introduce ill effects; add the patch to the list for the next quarterly patching window, etc. 

Whatever your approach, get the process started. 

Goal 3: Start performing health checks

You’ve assessed and remediated your SQL Servers. Now, let’s ensure that the environment remains up to date and in good health. Make a plan to check on your SQL Servers regularly.

We recommend Daily Health Checks for your SQL Servers. (That’s what we do for our DBA as a Service customers.)

Create a checklist to review each day. Some things we like to check are: 

• Review the SQL Server and Windows log files for errors, unexpected restarts, excessive failed login attempts, and other warnings that could indicate potential issues.
• Check the history for each scheduled SQL Agent job to ensure none have failed. 
• Examine the size and growth of each data and log file to check for anomalies in growth. 
• Verify that each SQL Server is up to date on patches.

Goal 4: Implement monitoring and alerting 

Proactively checking the status of each of your SQL Servers is helpful. But there may be occasions in between the health checks when the SQL Server experiences difficulties. When that happens, it’s really nice to know that before your users and your boss becomes aware. 

It’s best to identify and resolve an issue before anyone else notices. However, the next best thing is to be able to answer a call with “Yeah, I know and I’m working on it,” rather than “Really? When did this start? Tell me the server again.” 

To get to that point, you’ll want to ensure that all SQL Servers are configured with Database Mail, and that standard alerts are created. We recommend creating alerts for all errors with a Severity level 16 or above, along with errors 823, 824, and 825. There may be other alerts you’ll want to create in your environment as well. 

Additionally you’ll want to ensure that all jobs are configured to notify you upon failure. Make sure to enable the Fail Safe Operator, too. You never know when msdb will have an issue.

Often there are other events inside of SQL Server that you’ll want to know about when they happen. Maybe it’s Disk I/O latencies? Or the occurrence of deadlocks? Or perhaps it’s an excessive number of recompiles? 

That’s when a more advanced monitoring solutions can help. We’ve used most of them in our customer environments and all add value over what you can do solely in SQL Server. Our preference is SentryOne’s SQLSentry. It’s well designed and very helpful.

Whichever you choose, install it, configure it, tune it, and then actually use it.

Too often, we see environments where a monitoring tool was purchased and even installed, but ignored because no one had the time to figure it out. There were too many warnings so the team began ignoring or disabling them. 

Goal 5: Review your Disaster Recovery plans 

Despite all of your efforts to create and keep a healthy system, bad things can still happen. 

Hardware can fail. Databases can corrupt. Users can delete data. Not to mention other issues like ransomware hitting your network, tornados hitting your data center, or any of the other things a year like 2020 can throw at us. (See Protect Your SQL Server from MrbMiner and Other Malware Attacks)

We live in a world where the ability to recover from the unexpected is, well, to be expected.

So, now is a great time to review your High Availability and Disaster Recovery plans. 

• Work with your business stakeholders to understand their expectations. What is their Recovery Time Objectives (RTO) and Recover Point Objectives (RPO)?
• Brainstorm ways to accomplish your objectives. Should you consider Failover Clustered Instances? Or maybe other HA/DR options? 
• Create a cadence to test your SQL Server backups. Restore selected database backups to a test system and run an integrity check on the restored database periodically. Schedule it on your calendar.
• Document your processes. Record the steps and all the information you’ll need, including contact names and numbers, that will be important should an event requiring a recovery become necessary. 
• Schedule DR tests. There is nothing more insightful than actually going the process over a weekend. It will reveal shortcomings and gaps in your plans or documentation. Refine your plans and test again a few months later.

Want to work with The Sero Group?

Want to learn more about how SERO Group helps organizations take the guesswork out of managing their SQL Servers? It’s easy and there is no obligation. 

Schedule a call with us to get started.

The post Five Goals for Your SQL Servers in the New Year appeared first on The SERO Group.

In highly secure environments (and what environment shouldn’t be classified as highly secure these days?) all of these permissions can create headaches for auditors, CISOs, and even DBAs.

That’s not good. Yet, it’s not uncommon for individual users to own specific and important databases. In fact, this is one of the common findings we uncover during our SQL Health Checks for customers.

Who Owns Your SQL Server Database?

So how do individual users end up becoming SQL Server database owners?

Take, for example, the Chief Marketing Officer who authorizes her team to build a database to track their activities. Over time, the database grows and becomes more important. Eventually the team doesn’t want to “own” the responsibility for it any longer so it’s handed over to the DBA team for updates, maintenance, backups, HA/DR planning, licensing, etc. Except, no one really thought about the database owner during the transfer. So the power user that created the database still owns it, even though he doesn’t work on the CMO’s team any longer.

So, how can you tell if this may have happened in your environment? Or put another way, how can you tell who the database owner is for a database? Let’s look at three ways.

Find the database owner using Database Properties

One of the easiest ways to determine the database owner is to view its properties. Using either SQL Server Management Studio (SSMS) or Azure Data Studio (ADS) drill down to the database, right click on it, and select Properties to open the following window. Under the Database heading, you’ll see its owner.

In this example, the BaseballData database is owned by the Joe login.

Pretty simple for a single database, but very cumbersome for a few dozen or a few hundred databases spread across dozens of SQL Servers. So let’s look at two programmatic ways to check the database owner.

Find the database owner using T-SQL

Using your SQL Server query tool of choice, SSMS or ADS, run the following T-SQL query to see the owner for every database attached to this instance of SQL Server.

 SELECT name, 
        suser_sname( owner_sid ) AS DBOwnerName
 FROM master.sys.databases;

Or, if you prefer, you can limit the results to show only those databases not owned by a specific user, such as sa.

 SELECT name, 
        suser_sname( owner_sid ) AS DBOwnerName
 FROM master.sys.databases
 WHERE suser_sname( owner_sid ) != 'sa';

In my example, I’d get the following results in an ADS window.

Find the database owner using PowerShell and dbatools.io

For fans of PowerShell and dbatools, the Get-DbaDatabase command can be used to determine the database owner. In the code below I pipe the results to a Where-Object to show only those databases not owned by sa. For readability, I pass the results through Format-Table.

Get-DbaDatabase -SqlInstance localhost -SqlCredential sa | Where-Object {$_.Owner -ne "sa"} | Format-Table -Property Name, Owner 

Who Should Own Your Database

Now that you know who your SQL Server database owners are, the next question is: who should own your databases?

There are differing thoughts on this. Some advocate creating a specific disabled account to own all databases. Others contend that sa should own the databases. Still others opt for other approaches.

We recommend having sa own all databases. It’s not a perfect solution, but it’s consistent, clear, and meets the company and compliance needs in most cases.

How to Change Who Owns Your Database

Once you’ve decided who the SQL Server database owner should be and you’ve identified those databases not owned by that account, let’s look at a couple of ways you can change to database owner.

Change the database owner using T-SQL

To change database owner, use the ALTER AUTHORIZATION command. In the following example, I’m changing the owner of the BaseballData database to sa. If needed, you can script this out for every database on the server that isn’t already owned by sa.

ALTER AUTHORIZATION ON DATABASE::BaseballData TO sa;

Change the database owner using PowerShell and dbatools.io

You can also use the Set-DbaDbOwner command of dbatools.io to do this. In the following command, I’m setting the owner of the BaseballData database to the command default sa.

Set-DbaDbOwner -SqlInstance localhost -SqlCredential sa -Database BaseballData

If I don’t want to use the sa account as the database owner, I can specify who the owner should be using the TargetLogin parameter as shown below.

Set-DbaDbOwner -SqlInstance localhost -SqlCredential sa -Database BaseballData -TargetLogin disabled_login_with_complex_pwd

Or, I can broaden the scope to include all databases on the specified instance by omitting the Database parameter, as shown below.

Set-DbaDbOwner -SqlInstance localhost -SqlCredential sa 

Want to work with The Sero Group?

Want to learn more about how SERO Group helps organizations take the guesswork out of managing their SQL Servers? It’s easy and there is no obligation. 

Schedule a call with us to get started.

Download our free “SQL Server Configuration: 5 Common Issues That May Be Putting Your Data at Risk” PDF and discover some commonly overlooked SQL Server settings that can have dramatic effects on your server’s performance and reliability.

The post Who’s the SQL Server Database Owner and How Can You Change It? appeared first on The SERO Group.

It would be great if there was a one-size fits all approach to data protection – one system that would keep the bad guys out, the good guys within the guardrails, and Murphy’s Law safely neutralized. But, of course, the truth is that it is not that simple.

Securing and protecting your SQL Servers

In April 2020 The Motley Fool reported that Garmin paid $10M for a decryption key. When Baltimore was hit with ransomware, it cost the city an estimated 18.2M. Breaches are a lucrative business for hackers.

Keeping your data assets secure requires a multi-layered approach. Hardening your SQL Servers is a key part of that approach. So, what should you examine to help keep your SQL Servers Secure?

Securing your SQL Server environment

To help protect your SQL Servers and secure your data, we recommend reviewing the following:

1. Physical Security. Limit physical and/or logical access to your SQL Servers.
2. Operating System Security. Ensure that the Windows or Linux operating systems are secure and patched.
3. Patch. Cumulative Updates and other patches should be applied not only for performance reasons, but for security updates as well.
4. Services Accounts. Verify that the SQL Server service accounts have adequate restrictions, are not of Domain Admins, and change regularly. Consider using Group Managed Service Accounts when possible.
5. SQL Server Configuration Options. Limit configuration options such as CLR, Ole Automation, and xp_cmdshell on your systems. Don’t install any unneeded components such as SQL Server Reporting Services, or SQL Server Integration Services.
6. Encryption. Consider encryption; data lost due to bypassed security controls may be useless if encrypted.

Auditing your SQL Servers

On a regular basis, audit the following:

1. Roles and Permissions. Assess server level and database level role membership. Limit membership in the sysadmin role.
2. Authentication. Use Windows Authentication where possible and enable Password Policies for SQL Server Logins. Enable failed login auditing.
3. Strong sa Password. Ensure that the password used for the sa login if strong. Change it frequently. Consider even disabling the login.
4. Backup Strategy. Review your backup strategies and regular perform test restores to lower systems, including running integrity checks. Secure your backups.

Consider SQL Audit

To further protect your SQL Servers, consider implementing the built-in SQL Audit to record changes to important security facets such as additions to security role membership, new logins are created, and impersonation operations. If you have questions about SQL Audit, we have some demo scripts available to help you to get started. Feel free to contact us for the scripts.

By reviewing and auditing your SQL Servers, you’ll have a greater sense of confidence that they are protected and secure, and you’ll help to take the guesswork out of managing them.

Other Considerations

Keeping your data protected and available is much broader than just the security aspect. You’ll want to also look at High Availability and Disaster Recovery options,

Here are some other post that may help.

• High Availability and Disaster Recovery in SQL Server
• Protect Your SQL Server from MrbMiner and Other Malware Attacks
• How to Create SQL Server 2019 Failover Clustered Instances in Azure
• Is There an Update for My SQL Server?
• Is My SQL Server Configured Properly?

Want to work with The Sero Group?

Want to learn more about how SERO Group helps organizations take the guesswork out of managing their SQL Servers? It’s easy and there is no obligation. 

Schedule a call with us to get started.

The post Securing Your SQL Servers, What Should You Audit? appeared first on The SERO Group.

Running DBCC CHECKDB

You’d be surprised at how many times in our SQL Server Assessments we discover that DBCC CHECKDB hasn’t been run on a critical database. That’s a problem.

Running DBCC CHECKDB checks the physical and logical database objects and will help to spot corruption before too much time passes. As with many things, early detection is important.

So, let’s start there. To perform an integrity check, run the following command in a query window.

DBCC CHECKDB(master); 

Depending on a number of factors, including the size of the database, this may take some time to complete, so you’ll want to do this during periods of lesser activity.

When I ran this on the master database of my test container, it took about a second to run and I received 421 lines of output in the messages window.

At the very bottom of the output, it tells me that the command finished successfully and that I should check the output for error messages. So, I review all 421 lines, looking for any unexpected output. Bigger databases with more objects will take longer to run and will have more output to review.

So, is there a way to see if DBCC CHECKDB completed with no errors without having to review all of the output?

When did DBCC CHECKDB last complete without errors?

Fortunately, DBCC CHECKDB will log each time it completes without finding any errors or corruption in the database. That’s called the Last Known Good date. Let’s look at three ways you determine the Last Known Good date. We’ll use a T-SQL query, a PowerShell command with dbatools, and the SQL Server Logs via Management Studio.

Finding the last known good date using T-SQL

From a query window in either SQL Server Management Studio or Azure Data Studio, run the following command. Replace ‘master’ with the database for which you’d like to find the Last Known Good date.

USE master; 
GO 

DBCC DBINFO() WITH TABLERESULTS;

I ran it on my test container for a SQL Server 2019 instance and received 94 lines of output. Approximately half-way down, at line 51, you’ll see a line where the third column (called Field in the output) shows dbi_dbccLastKnownGood. That’s what you’re looking for. The forth column for that row, called Value, shows the date that DBCC CHECKDB last completed successfully. That’s the DBCC CHECKDB Last Known Good date.

That’s not a heavy lift, but it still takes some effort to sift through the results.

Finding the last known good date using PowerShell and dbatools

If you’re a fan of PowerShell and dbatools, you can use the combination to find DBCC CHECKDB Last Known Good Date using the following command where localhost is the SQL Server instance, sa is the credential I’m using to connect to the instance, and master is the name of the database I want to run the DBCC CHECKDB command on.

Get-DbaLastGoodCheckDb -SqlInstance localhost -SqlCredential sa -Database master

The results are shown below. As you can see, the output shows some additional information about the database, including how many days it’s been since the Last Known Good.

By the way, I can omit the -Database parameter and find the Last Known Good date for all databases on the instance.

Get-DbaLastGoodCheckDb -SqlInstance localhost -SqlCredential sa | Format-Table 

I’ve formatted the output in table format for ease of reading.

Finding the last known good date using the SQL Server Logs

DBCC CHECKDB logs information into the SQL Server ERROR LOG files. You can view the logs using Management Studio. Drill down into instance, Management, SQL Server Logs, and right-click on the Current log as shown below.

You’ll see the following window where your search for the DBCC CHECKDB output.

What if DBCC CHECKDB has never been run?

But, what will the output show if it’s never been run on a database?

Using the Get-DbaLastGoodCheckDb dbatools command in PowerShell, the LastGoodCheckDb value will be blank if the DBCC CHECKDB has never been run on this database, as in the BaseballData in the following example.

Using T-SQL, the Value column will show the default value for a date that is NULL in SQL Server, 1900-01-01 00:00:00.000.

Of course if you find this to be the case, you should run DBCC CHECKDB as soon as you can. Again, it should be run during times of lesser activity since it takes some resources and time to complete.

Want to work with The Sero Group?

Want to learn more about how SERO Group helps organizations take the guesswork out of managing their SQL Servers? It’s easy and there is no obligation. 

Schedule a call with us to get started.

The post When Was the Last Known Good DBCC CHECKDB Integrity Check? appeared first on The SERO Group.

When Microsoft SQL Server is installed, by default one SQL Server tempdb file is defined. For many systems that may be enough. But, over time, as the database sizes grow, as the number of users increases, and type of queries grow in complexity, one tempdb file may not be able to handle the load. It may become a source for contention.

How to find your tempdb data files

Checking the number of tempdb data files is straightforward. Here are three easy ways: one graphical, one T-SQL, and one PowerShell, so you can use your tools of choice.

List tempdb data files using database properties

Perhaps the most frequently used way to check the number of tempdb data files for a SQL Server is to view the Database Properties. This can be done using either SQL Server Management Studio (SSMS) or Azure Data Studio (ADS). I’m using ADS in images below.

Drill down into the SQL Server instance, Databases, System Databases, and right click on the tempdb database. Select Properties in the pop-up menu.

The Database Properties window will open. As you can see in the image below, the SQL Server 2019 container I downloaded is configured with four tempdb data files. That’s not bad, although the size and auto growth settings are concerning.

Of course, while you’re in the Properties window you can adjust the number, sizes, etc, of the data files. Your SQL Server should be restarted afterward.

List tempdb data files using T-SQL

As with most everything you can do using point-and-click in SSMS or ADS, the same can be accomplished using Transact-SQL. Sometimes, it’s just nice to have a library of commonly used scripts on hand so you can quickly, easily, and consistently run them.

In this case, the query below can be used to check the number of tempdb data files currently defined.

SELECT  file_id, 
        type_desc, 
        name, 
        physical_name, 
        [size],
        state_desc
FROM    tempdb.sys.database_files 
WHERE   type = 0 ; 

Here are the results. Of course, you can add additional output columns to see other properties as well, such as max_size, growth, and is_percent_growth.

List tempdb data files using PowerShell and dbatools

Experienced SQL Server DBAs often make extensive use of the dbatools PowerShell module. You get all the flexibility and capabilities of PowerShell combined with the ability to administer most every aspect of your SQL Server.

In the code below, I’m using the Get-DbaDbFile command. The command is fully documented here. I’m connecting to the localhost using the -SqlInstance parameter and authenticating as sa using the -SqlCredential parameter. I will be prompted for the password each time. The -Database parameter allows me to find the datafiles for a specific database. I’m then piping the output to table format for readability.

Get-DbaDbFile -SqlInstance localhost -SqlCredential sa -Database tempdb |Format-Table

Here’s the output from the Get-DbaDbFile command.

Want to know more about your SQL Server configuration?

Here are few other posts for SQL Server configuration settings and tempdb that may be helpful.

• Is My SQL Server Configured Properly?
• How Many tempdb Data Files Should My SQL Server Have?
• Why 9 Out of 10 SQL Servers Aren’t Configured with Best Practices

[EDIT Oct 5, 2021] – Also see How to Configure SQL Server tempdb? for other tempdb configuration settings that can affect performance.

Want to work with The Sero Group?

Want to learn more about how SERO Group helps organizations take the guesswork out of managing their SQL Servers? It’s easy and there is no obligation. 

Schedule a call with us to get started.

The post 3 Ways to Find Your SQL Server tempdb Data Files appeared first on The SERO Group.

You also need to be able to recover from an unexpected disaster quickly. Whether due to corruption, theft, or a natural disaster, you need to be able to recover the data and database systems quickly. (A process that should be clearly documented and periodically practiced.)

The last thing you want is for your business to grind to a halt while the IT team attempts to figure out what happened and how to respond. Your customers will be waiting while your employees are idled despite wanting to do their jobs. Running a database system without considering HADR is like walking a tightrope without a net.

The Cost of Unplanned Downtime

Unplanned downtime costs companies an average of $5,600 per minute according to a 2014 Gartner study. A more recent 2016 study from the Ponemon Institute put the figure at $8,850 per minute. That’s over a half million dollars an hour of lost revenue, decreased productivity, and incident response costs. Other studies suggest that many unplanned outages involved database servers. Ouch!

So, it goes without saying that good HADR is important, but it’s not a replacement for performing Daily Health Checks and actively monitoring the SQL Server to ensure their health. 

4 High Availability and Disaster Recovery Options in SQL Server

Although High Availability and Disaster Recovery is a much broader topic than the database servers, the following SQL Server options should be considered as part of the larger discussion.

1. SQL Backup and Restore

Database and log backups are the foundation of any HADR implementation. It’s the basic blocking and tackling of any database implementation. Every SQL Server should be backed up periodically in addition to any other HADR solutions you may have implemented.

We recommended using native SQL Server backups. Of course, to recover from a catastrophic failure, you’ll have to (re)create a new SQL Server system to restore the backups. Taking frequent snapshots of the virtual server can help with the system recovery but those are no substitute for true database backups.

Backing up is important. But it’s really the ability to restore that important. Periodically restore selected databases to another system and run integrity checks on those databases. Document the process so that in a true disaster recovery scenario, you’ll have a proven protocol.

2. Logshipping in SQL Server

Log shipping leverages the native SQL Server log backup processes and creates a more controlled and automated recovery story. By automatically sending transaction log backups to a secondary SQL Server instance, you’ll have a standby server available with as little as a few minutes of lost data. That’s good news.

Should a disaster strike, client applications and other systems will have to be adjusted to point to the new SQL Server instance. This typically requires manual intervention and will not be seamless for the end users. They’ll know that a failure has occurred, however, recovery times are typically faster and the recovery points more granular than with an ordinary backup approach.

3. Failover Clustered Instances (FCIs)

Failover Clustered Instances takes your HADR game up several levels. Leveraging Windows Server Failover Clusters (WSFC), a single instance of SQL Server can be installed across multiple WSFC nodes. Should one of the nodes experience a hardware or software failure, key services such as SQL Server, are automatically shifted to another node.

With FCIs, SQL Server appears to client applications as one instance running on one Windows Server. Since services are automatically shifted to another node during an unexpected failure or planned maintenance cycle, client applications are automatically redirected to the active node. They typically do not notice any disruption in service.

The FCI is online as long as its underlying WSFC cluster is in good quorum health. This instance level redundancy provides substantially reduced potential for noticeable downtime for clients.

4. Availability Groups (AGs)

With Always On Availability Groups, transaction logs are synchronized from the primary replica to one or more secondary replicas. Should the primary replica become unavailable, either due to a failure or scheduled maintenance, a secondary replica transitions to the primary role. Clients, which connect to a listener, are unaware of any changes to the actual location of the primary replica.

Availability Groups further decrease the likelihood of a noticeably disruptive event.

Looking for Additional HADR Information?

Of course, this is a high-level overview of some options for High Availability and Disaster Recovery options in SQL Server. There are many other factors to consider as well, including backup methodologies, cloud strategies, and virtualization techniques. You can even implement Distributed Availability Groups or Failover Clustered Instances across multiple subnets. These are topics for another post.

Additionally, you’ll need to fully understand the business requirements of your stakeholders for Recovery Point Objectives (RPO) and Recovery Time Objectives (RTO). The approaches mentioned here obviously come with varying levels of RTO and RPO capabilities and with different licensing price points.

If you’re looking for additional information, check out Microsoft’s Business Continuity and Database Recovery on SQL Docs. Additionally Luke Campbell (@luke7621) has a series on Creating Failover Clustered Instances in Azure.

Want to work with The Sero Group?

Want to learn more about how SERO Group helps organizations take the guesswork out of managing their SQL Servers? It’s easy and there is no obligation. 

Schedule a call with us to get started.

The post High Availability and Disaster Recovery in SQL Server appeared first on The SERO Group.

Running production systems on a platform that is no longer supported by the vendor is worrisome. If something goes wrong, you’ll no longer be able to call the vendor and receive technical support. But worse, you’ll no longer release updates, fixes, security patches, etc, for the out of support version. This could leave your production systems vulnerable to exploits and unrecoverable crashes. But this begs the question “Should I Upgrade All SQL Servers that Are Out of Support?”

Is My SQL Server Out of Support?

First off, let’s answer the question of “Is my SQL Server out of support?” Microsoft typically supports their products for 10 years. The first five years are Main Stream Support, which includes incident support (either paid or no-charge depending on circumstances and cause) hotfixes, updates, etc.

Then for the next five years, the product will be in Extended Support. In that level of support, Microsoft will continue to provide some updates and hotfixes to the product, especially those that affect security. Paid support is still available.

You can check to see where your version of SQL Server stands by going to the Microsoft Life Cycle page. Also see Is There An Update for My SQL Server?

But, Should I Upgrade SQL Servers that Are Out of Support?

Ok, you’ve checked and your SQL Server is no longer in Mainstream Support. It’s not what you wanted to find, but it’s not the end of the world, either. You’ve still got some time in the Extended Support world to make some plans.

But what if your SQL Server is out of Extended Support. Should you immediately drop everything and upgrade? Sure, in an ideal world where both money and time are a-plenty. But, of course, none of us live in that world.

So, do you prioritize upgrading all of your SQL Servers systems?

Well, yes. And no.

As with many questions in technology, the real answer is “it depends.” This short video explains some of the options and criteria for answering that question. This post, 4 Options Now That Your SQL Server 2008 Is Out of Support, may help as well.

Although, running production systems on versions that are out of date is very concerning and can be risky, many factors will ultimately influence your decision on whether you should upgrade all of your SQL Servers.

Running a vintage car can fun and make for a great hobby. But running a vintage version of SQL Server can be dangerous.

Want to work with The Sero Group?

Want to learn more about how SERO Group helps organizations take the guesswork out of managing their SQL Servers? It’s easy and there is no obligation. 

Schedule a call with us to get started.

The post Should I Upgrade SQL Servers that Are Out of Support? appeared first on The SERO Group.

Here’s a short introduction video for how DiskSpd can be used to gather the necessary performance metrics without using the SQL Server Dynamic Management Views (DMVs). Having a way to support your case without using SQL Server to capture these metrics can sometimes be helpful.

Using DiskSpd on Your SQL Server System

Using Diskspd we can benchmark the raw performance of storage without relying on SQL Server DMV information at all. It’ll report on write and read latency, on sequential and random disk activity. It’s very granular and can be extremely insightful.

For example, I downloaded the utility and ran it on my laptop using the following command.

Diskspd.exe -b8K -d60 -h -L -o2 -t4 -r -w30 -c100M c:\test\io.dat > c:\test\output.txt

In this simple case, I set the block size to 8K using the -b parameter, ran the test for 60 seconds using the -d parameter, disabled hardware and software caching with the -h parameter, measured latency statistics with -L, used 2 overlapped IOs with the -o parameter, created 4 threads per target with the -t parameter, defined a workload of random input/output with the -r parameter, defined 30% of the I/O to be writes with the -w parameter, had the utility create a 100MB test file at c:\test\io.dat, and configured the output to be written to c:\test\output.txt.

There are many more parameters available in DiskSpd. For a complete list, run DiskSpd -?.

Interpreting the DiskSpd Disk I/O Performance Results

In my case, I received the following results in the c:\test\output.txt file. Keep in mind this is on a laptop and not a production SQL Server.

Command Line: Diskspd.exe -b8K -d60 -h -L -o2 -t4 -r -w30 -c100M c:\test\io.dat

Input parameters:

	timespan:   1
	-------------
	duration: 60s
	warm up time: 5s
	cool down time: 0s
	measuring latency
	random seed: 0
	path: 'c:\test\io.dat'
		think time: 0ms
		burst size: 0
		software cache disabled
		hardware write cache disabled, writethrough on
		performing mix test (read/write ratio: 70/30)
		block size: 8192
		using random I/O (alignment: 8192)
		number of outstanding I/O operations: 2
		thread stride size: 0
		threads per file: 4
		using I/O Completion Ports
		IO priority: normal

System information:

	computer name: DESKTOP-K9DJS56
	start time: 2020/10/21 14:18:01 UTC

Results for timespan 1:
*******************************************************************************

actual test time:	60.00s
thread count:		4
proc count:		4

CPU |  Usage |  User  |  Kernel |  Idle
-------------------------------------------
   0|  71.35%|  13.26%|   58.10%|  28.65%
   1|  66.28%|  15.23%|   51.04%|  33.72%
   2|  70.03%|  13.41%|   56.61%|  29.97%
   3|  68.15%|  17.73%|   50.42%|  31.85%
-------------------------------------------
avg.|  68.95%|  14.91%|   54.04%|  31.05%

Total IO
thread |       bytes     |     I/Os     |    MiB/s   |  I/O per s |  AvgLat  | LatStdDev |  file
-----------------------------------------------------------------------------------------------------
     0 |      4398579712 |       536936 |      69.91 |    8948.90 |    0.222 |     0.740 | c:\test\io.dat (100MiB)
     1 |      4435599360 |       541455 |      70.50 |    9024.22 |    0.221 |     0.739 | c:\test\io.dat (100MiB)
     2 |      4433772544 |       541232 |      70.47 |    9020.50 |    0.221 |     0.757 | c:\test\io.dat (100MiB)
     3 |      4367548416 |       533148 |      69.42 |    8885.77 |    0.224 |     0.787 | c:\test\io.dat (100MiB)
-----------------------------------------------------------------------------------------------------
total:       17635500032 |      2152771 |     280.31 |   35879.40 |    0.222 |     0.756

Read IO
thread |       bytes     |     I/Os     |    MiB/s   |  I/O per s |  AvgLat  | LatStdDev |  file
-----------------------------------------------------------------------------------------------------
     0 |      3077742592 |       375701 |      48.92 |    6261.66 |    0.256 |     0.669 | c:\test\io.dat (100MiB)
     1 |      3101097984 |       378552 |      49.29 |    6309.18 |    0.256 |     0.751 | c:\test\io.dat (100MiB)
     2 |      3100819456 |       378518 |      49.29 |    6308.61 |    0.254 |     0.606 | c:\test\io.dat (100MiB)
     3 |      3055476736 |       372983 |      48.57 |    6216.36 |    0.258 |     0.715 | c:\test\io.dat (100MiB)
-----------------------------------------------------------------------------------------------------
total:       12335136768 |      1505754 |     196.06 |   25095.82 |    0.256 |     0.688

Write IO
thread |       bytes     |     I/Os     |    MiB/s   |  I/O per s |  AvgLat  | LatStdDev |  file
-----------------------------------------------------------------------------------------------------
     0 |      1320837120 |       161235 |      20.99 |    2687.24 |    0.144 |     0.879 | c:\test\io.dat (100MiB)
     1 |      1334501376 |       162903 |      21.21 |    2715.04 |    0.139 |     0.702 | c:\test\io.dat (100MiB)
     2 |      1332953088 |       162714 |      21.19 |    2711.89 |    0.144 |     1.023 | c:\test\io.dat (100MiB)
     3 |      1312071680 |       160165 |      20.85 |    2669.41 |    0.145 |     0.928 | c:\test\io.dat (100MiB)
-----------------------------------------------------------------------------------------------------
total:        5300363264 |       647017 |      84.25 |   10783.58 |    0.143 |     0.890



total:
  %-ile |  Read (ms) | Write (ms) | Total (ms)
----------------------------------------------
    min |      0.054 |      0.048 |      0.048
   25th |      0.168 |      0.082 |      0.121
   50th |      0.192 |      0.095 |      0.174
   75th |      0.228 |      0.113 |      0.211
   90th |      0.337 |      0.144 |      0.292
   95th |      0.557 |      0.203 |      0.454
   99th |      1.394 |      0.610 |      1.291
3-nines |      4.510 |     14.778 |      5.577
4-nines |     18.031 |     26.059 |     20.629
5-nines |    117.426 |    117.574 |    117.502
6-nines |    153.091 |    161.708 |    153.091
7-nines |    162.048 |    161.708 |    162.048
8-nines |    162.048 |    161.708 |    162.048
9-nines |    162.048 |    161.708 |    162.048
    max |    162.048 |    161.708 |    162.048

As you can see, DiskSpd creates quite a bit of information.

According to the results, the test consumed nearly 69% of the CPU resources. As for the latency, the last section shows the metrics broken down by percentiles. In my case, the minimum read latency was 0.054 ms and the best write latency I could achieve was 0.048 ms. The maximum latencies were read 162.048 ms and write 161.708 ms. At the 50th percentile, my system had a read latency of 0.192 ms and a write latency of 0.095 ms.

This output can help you determine whether the disk I/O subsystem is delivering the performance your SQL Server system needs.

Where to Get DiskSpd

DiskSpd is available on GitHub, and additional how-to documentation can be found on TechNet here.

For other checks to run on your SQL Server system, check out Is My SQL Server Configured Properly.

The post Identify Disk I/O Performance Issues for Your SQL Server Using DiskSpd appeared first on The SERO Group.