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.

The answer is not simple.

Data roles are diverse and constantly evolving. Similarly, the lines that separate data disciplines are inherently blurred. The reality faced by active data professionals is also complex, with business and project requirements often requiring them to extend their expertise across disciplines. Consequently, data professionals often wear many hats.

Still, it’s useful for those entering the field or looking to hire a data professional to understand some of the important distinctions between data disciplines.

Here are just a few.

Common Data Roles

Data Architect

Data architects design the overall blueprint for your organization’s data environment. They define how data is stored, organized, integrated, and accessed across systems. They also ensure that your data infrastructure is scalable, secure, architected for efficient retrieval, and aligns with your long-term business goals.

Database Administrator (DBA)

DBAs are the administrators of your database systems. They possess a deep knowledge of the database engine itself, including all its native functionality and features. They are also responsible for keeping databases updated, backed up, secure, and performing optimally. DBAs also manage database upgrades and migrations, as well as database recovery in a disaster or emergency.

Data Engineer

Think of data engineers as the builders of your data infrastructure. They design, construct, and maintain the pipelines that collect, store, and process your data. Their toolkit is diverse and often includes programming languages like Python and SQL. It is also common to leverage cloud platforms like Azure, AWS, or GCP. These professionals ensure that your data is accessible, reliable, and ready for analysis.

Data Analyst / Business Intelligence Analyst

Data analysts are the storytellers of the data world. They take the data that engineers have prepared and draw out insights through creating reports, dashboards, and visualizations. Furthermore, their strong analytical skills and ability to recognize patterns allow them to turn data into knowledge. They tell stories with data to help guide decisions. Tools often include Excel and BI reporting platforms like Tableau or Power BI.

Data Scientist

Data scientists take analytics to a deeper level. They use advanced statistical techniques and machine learning to uncover hidden patterns that are often difficult for humans to detect. Similarly, the algorithms used by data scientists can predict future trends, and the outputs of their models are used to drive decision-making. Data scientists possess mathematical expertise, programming skills in languages like Python or R, and domain knowledge relevant to their industry.

Machine Learning Engineer

Machine learning engineers take the models created by data scientists and make them operational in real-world production environments. They leverage both data science and software engineering skills. ML engineers are responsible for building the systems that deploy, monitor, and scale data science models. They also manage these systems to ensure that they deliver accurate and timely predictions once deployed in a real-world context.

Tips for Choosing Your Future Data Role

Shadowing some different data professionals is a great way to get started. Depending on which role appeals to you, there are different pathways to getting started.

If you have a background in system administration, data architecture and database administration may be good avenues to investigate. Likewise, people who have enjoyed building their own home labs may also enjoy these data roles.

Similarly, if you love automation and problem-solving for technical efficiency, one of the engineering roles may be right for you. Engineers enjoy designing and building solutions for technical challenges.

Finally, if you have a mind for analytics and statistics, an analyst or data science role may be a great fit. These roles uncover the root causes of the problems under investigation in order to unlock potential solutions.

There are a variety of ways to kick-start your journey for any of these data disciplines.

1. Self-Education. There are many resources available online that can guide you through learning specialized skills. Set up a home lab environment in which to safely practice. Start to build a profile of projects and/or certifications that can showcase your new skills.
2. Bootcamps. The number and variety of bootcamps for data have increased dramatically in the last 5 years. If your schedule allows for participation in one of these intense programs, they can be a great way to upskill rapidly.
3. Formal education. If you are looking to go into a highly specialized role in a particular knowledge domain or industry, obtaining an advanced degree can be a great way to get started.

Determining which path to take will depend on what appeals to you and on the circumstances in which you are beginning your journey. The key, however, is just taking the first step.

Tips for Hiring: Which Data Role Do You Need?

Just as the path to becoming a data professional depends on individual circumstances, the type of data professional to hire will also depend on your organization’s needs and where you are in your data maturity journey.

Here are some hiring considerations for several common scenarios:

Just Starting Out

If you are building your data capabilities from the ground up, a data engineer with versatile skills is a great first hire. While partnering with system administrators and business experts, as well as potentially seeking external assistance from a DBA or data architect, a data engineer can lay the foundation for your future data work.

Business Optimization / Improved Operations

If you are looking to use your data for improved operations, a data or business intelligence analyst can work with business partners to track key metrics, identify trends, and drive data-driven decisions to find ways to improve. Likewise, by developing an understanding of the business, this person can work as a bridge between business and IT teams to help harness the full potential of your data.

Complex or Outdated Data Environment

A data architect can bring order to chaos by ensuring that your data is well-organized, accessible, and scalable as your organization grows and expands. Data architects can also be instrumental in reshaping legacy structures to meet current business requirements and make the best use of modern technologies.

Predictive Insights and Automation

Data scientists and machine learning engineers are ideal for building models that can make important predictions, optimize processes, and/or automate complex AI tasks. It is important to note, however, that having a robust, well-governed data infrastructure is a prerequisite for success for these types of initiatives.

Diverse Needs, Large-Scale Projects, or Complex Remediation

Partnering with an external data team with diverse areas of expertise can be an affordable way to: remediate complex problems, make infrastructure improvements rapidly, or design and implement large-scale solutions. Leveraging this type of support also allows you to access professionals with expertise in different data roles and may offer flexibility for scaling up or scaling down your level of support as needed.

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 estate? Schedule a no-obligation discovery call with us to get started.

The post What’s in a Job Title? Understanding Changing Data Roles appeared first on The SERO Group.

It might seem that way, but the risks will only grow while you wait.

So, why do so many businesses delay making essential improvements to their SQL Servers?

Roadblocks to creating a better SQL environment (and how to navigate them)

Budget is frequently an issue. However, there are likely other factors compounding that barrier. Let’s look at some common reasons companies choose to delay making changes that would help to create a more stable and secure SQL Server environment.

1. “That’s part of a future project.”
2. “We don’t know where to start.”
3. “We don’t know what we don’t know.”
4. “We just can’t.”
5. “We’re not sure who owns those.”

“That’s part of a future project.”

Sometimes companies will postpone tackling an issue with their SQL Server environment because it gets lumped into a much larger project.

For example, a company may recognize the need to regularly test their SQL Server backups. It’s important, and they know that. After all, an untested SQL Server backup file and process is only a hope that they can restore. (See How Often Should I Test My SQL Server Backups? for some background here.)

Creating a process to regularly test SQL Server backups may still be deferred because “that will be part of the Disaster Recovery initiative.” However, if that DR initiative isn’t budgeted and doesn’t have a start date, that means delaying improvements indefinitely.

So, what can you do?

Start small. Take baby steps that lead you in the right direction. Often those baby steps will contribute to the larger project anyway.

In our backup example, check the status of your backup jobs every day. Schedule a job or another process to verify the backup files. Create reminders to periodically restore a key database to another server and run an integrity check on it.

Is this a perfect solution? No. But it’s far better than ignoring the gap until the larger project is funded.

“We don’t know where to start.”

Sometimes, the hardest part is knowing where to start. Even worse, not knowing where to start can make getting started seemingly insurmountable.

For example, let’s say a company has 15 SQL Server instances and they’d like to get that down to 8 or 10 through a consolidation project. But before they begin, they have questions.

• Which application databases can be moved to another SQL Server?
• Which ones will play nicely together, and which will compete for limited resources?
• Are there security considerations that require some applications to remain separate?
• Will we have to add resources to the target instances?
• And what haven’t we thought about that we should?

Those unknowns can seem overwhelming, especially if you don’t know how to go about finding the answers.

So, what can you do?

Start small, build momentum, and keep your eye on the end-goal while making incremental progress.

In our SQL Server Consolidation Project example, can you build a high-level project plan with only the most basic steps? Then you can drill down into the details, step by step.

For example, the first step is to get a list of all of the SQL Servers that may be candidates for the consolidation project. Then, determine what applications use these SQL Servers. Then, identify the applications’ requirements, and so on.

We know projects like this can become dauntingly complex if you’re not used to doing them. As with most anything, breaking things down into smaller, more manageable steps will help.

“We don’t know what we don’t know.”

This one is common and can take many forms. As an example, let’s say IT wants to decommission a SQL Server, but they’re unsure whether it’s being used. It’s got a dozen databases on it, but some are from older applications that may not be used anymore. Maybe the guy who created the database isn’t even with the company anymore.

Another example: IT would like to do a side-by-side upgrade of a SQL Server. They know there are a lot of data pipelines that rely on that SQL Server. However, do they know how many pipelines? Who owns them? Will they have to be redeployed? Are there any other aspects they’ve overlooked?

What should be a relatively simple request can become a larger issue. It can seem safer not to upset the apple cart when there are so many unknowns at play.

So, what can you do?

Having a long list of open questions with no clear path to find the answers can feel paralyzing. To find your way forward, focus on your goal and your reasons for wanting it. In the upgrade example, your goal is to upgrade your SQL Server. Why? Using an older, unsupported SQL Server version could cause serious issues; an upgrade would improve security, compliance, and supportability, which means you’re less likely to encounter problems.

Once you’re clear on your motivation, determine how you can begin to answer the first unknown. Then the next one. Then the one after that. Incremental progress will help you grow in confidence about your ability to improve the environment in addition to answering those unknowns.

“We just can’t.”

Sometimes limitations are self-imposed. Other times, limitations are implicitly imposed by stakeholders, even if they don’t have the authority to make the call outright.

This can happen with patching. As an example, vocal and influential stakeholders may insist that a SQL Server cannot go down for maintenance, period. IT may accept that limitation rather than fight it. As a result, things may progress until neither the SQL Server nor the Operating System have been patched in over two years. Not good!

So, what can you do?

This one can become overly politicized or personalized. Look for and emphasize common ground.

In the patching example, the common ground may be that everyone wants the SQL Server to be available and secure. From there, you can communicate how patching will help achieve that common goal. Planned downtime is always better than unplanned downtime, and reminding stakeholders of that can help put things in perspective.

Sometimes, IT has a reputation for implementing technology for technology’s sake, regardless of what’s in the best interest of the business or its stakeholders. Keep that in mind. Present your points so that the other party can see how they’ll benefit.

“We’re not sure who owns those.”

Sometimes there’s no clear owner of your SQL Servers. No one wants to make decisions about them, even if it helps to create better SQL environment. This can happen after an acquisition, during a re-org, or when responsibilities are not clearly spelled out.

For example, IT may become aware of some new SQL Servers. However, the team isn’t sure if those instances fall within their purview or the responsibility of another team or department. Spoiler alert: if something happens to one of the SQL Servers or its databases, IT almost always ends up having to fix it.

So, what can you do?

Uncertainty in areas of responsibility can lead to big problems. Get clear on who is responsible for SQL Servers (and any other assets) as soon as possible. Otherwise, those SQL Servers will become increasingly vulnerable to breaches or data loss.

Moving forward to create a better SQL Server environment

I’m sure this list of roadblocks isn’t comprehensive. There are likely other reasons companies don’t improve their SQL environment. Many of them may even be good and valid reasons.

However, in cases where creating a better SQL environment would be in everyone’s interest, don’t let the perfect be the enemy of the good. Look for ways to make incremental progress, however small, toward a more reliable and more secure SQL environment that performs.

If you’re not sure where to start, we can help. Helping clients overcome barriers to create better SQL environments is what we do for a living. Schedule a call to see if working with our team of DBAs makes sense for you.

The post “We Want a Better SQL Environment, Just Not Yet.” appeared first on The SERO Group.

First, what is the transaction log?

The SQL Server transaction log is a crucial element within each database that records all database changes across time. This log enables point-in-time recoverability and rollbacks in the event of mistakes, corruption, or failure. This recoverability is critical to ensuring the integrity and resilience of the database.

What is contained in the transaction log?

There are several key concepts and log components to be aware of when dealing with SQL Server’s transaction logs.

1.     Log Records

Within SQL Server’s transaction logs, individual change operations are enclosed within log records. Each log record represents one UPDATE, INSERT, or DELETE operation in the database and is associated with one transaction. Each transaction, however, may have numerous log records.

Every data modification made in the database has one or more log records associated with it. Log records contain either the logical operation performed with the modification made, or they contain before and after images of the modified data. Start and end times of each transaction are also recorded.

2.     Log Blocks

A log block is the basic unit of I/O when it comes to transaction logs. The sizes of the log blocks vary but are at least 512 bytes and can be as large as 60 KB. Log blocks can contain multiple log records or none. According to Microsoft, “a log block is a container of log records that’s used as the basic unit of transaction logging when writing log records to disk.”

3.     Virtual Log Files (VLFs)

When considering the database transaction log, it is important to keep in mind the concept of the physical log file and its composite VLFs, or virtual log files.

The division of the log into multiple log segments (or virtual logs) is handled automatically by SQL Server and is the foundation of the circular nature of the physical log file (see below). Each VLF is in turn composed of numerous log blocks.

VLFs are created dynamically as needed by SQL Server. While we as administrators are not able to set a static size for these file divisions, we can manage the auto-growth settings of the log file, which will in turn impact the size and number of the VLFs that SQL Server creates.

4.     Log Sequence Number (LSN)

Within the database’s transaction log, the chronological consistency of transactions is preserved across the VLFs through LSNs, or log sequence numbers. These numbers allow SQL Server to arrange the transactions in their correct chronological order for the purposes of rollback and recovery despite the potential for having been written to different VLFs.

The LSN is a concatenation of the VLF ID, the Log Block ID, and the Log Record ID separated by colons. You can see examples of the LSN by querying the sys.dm_db_log_info view and looking at the [vlf_create_lsn] field:

5.     Minimum Recovery LSN (MinLSN)

The MinLSN, or minimum recovery LSN,is the LSN that would be needed for a full recovery of the database. Put another way, the MinLSN is the first LSN in the sequence of the active section or tail of the log, which is the section of the log that has not yet been written from memory to disk by a checkpoint operation.

How does SQL Server logging work?

6.     Checkpoint Process

Checkpoints are the SQL Server operations by which database modifications that are being stored in memory are written to disk. Checkpoints are usually triggered by a log backup or automatically by the recovery interval setting of the database.

The active section of the log that has not yet reached a checkpoint can never be truncated, so paying attention to the recovery settings of each database helps to manage checkpoints and transaction log truncation optimally.

7.     Cyclical Logging

The SQL Server transaction log can be thought of as a revolving log file.

Consider that the physical log is allocated a designated amount of space in the database properties when it is configured. As mentioned above, the transaction log is made up of smaller segments (VLFs) that SQL Server writes to as part of its internal logging process – adding a new VLF each time the last one fills up. This process is internally controlled by the application.

If the physical transaction log is never truncated, it will continue to grow, adding new VLFs as it grows, until it uses up all the space available to it and SQL Server fails.

If, however, the transaction log is truncated, older VLFs containing transactions with LSNs prior to the MinLSN will be cleared. When those files are truncated, the space that was being used by the deleted log records will be released and made available for new log records to be created as more transactions are committed. This circular process allows the overall size of the log to remain consistent despite ongoing transaction logging.

This log-and-truncate cycle will continue successfully unless the logging rate exceeds the truncation rate. Note once again, however, that truncation of the transaction log cannot occur in full or bulk-logged recovery models if log backups are not taken first.

For this reason, administrators should pay careful attention to the recovery and log file settings to avoid unnecessary disruptions in the SQL Server environment.

What else should you know about SQL Server transaction logs?

In an upcoming post, we will discuss how to troubleshoot some common issues with SQL Server transaction logs and give some best practices for transaction log management.

When configured carefully, the logging process within SQL Server can operate seamlessly for years without DBA intervention.

Here are some resources that contain more information about some of the topics we touched on:

• Log Blocks
• LSNs
• Virtual Log Files and Growth Algorithms
• SQL Server Checkpoint Process
• Transaction Log Backups and Log Shrinking

Want to work with The SERO Group?

If you’re concerned about your backup strategy, or more to the point, your ability to restore a critical database, contact us. We’re happy to help.

The post Anatomy of a SQL Server Transaction Log appeared first on The SERO Group.

MAXDOP is short for Maximum Degree of Parallelism. SQL Server uses the MAXDOP setting to determine the maximum number of processors that can be used for the execution of a single query or operation. In simple terms, it controls how many CPU cores SQL Server can utilize to process a query.

How MAXDOP works in SQL Server

When SQL Server processes a query, it can break down the task into multiple smaller tasks and execute them concurrently on different processors. This is known as parallel execution, or “parallelism.”

MAXDOP specifies the maximum number of CPU cores that can be utilized for this parallel execution. This parallelism can improve query performance for large datasets or complex operations. However, an incorrect MAXDOP setting can also lead to inefficient query execution plans, increased CPU utilization, and potentially degraded performance.

MAXDOP is set at the server level. The default configuration setting for MAXDOP is usually set to 0 (unlimited). This means SQL Server can use all available processors for parallel queries. While this setting can be suitable for some workloads, it may not be optimal in all situations.

If SQL Server is allowed to use too many CPU cores for parallel execution, it may cause excessive contention and actually slow down the performance of other tasks and queries running on the server. On the other hand, if SQL Server is restricted to use too few CPU cores, it might not fully utilize the available hardware resources, resulting in slower query processing times.

It’s the Goldilocks Principle as applied to SQL Server. Not too many cores, nor too few. It needs to be just right.

Configuring MAXDOP for your SQL Server

Microsoft provides some initial guidance for MAXDOP. However, configuring MAXDOP appropriately for your specific environment and workload is crucial. You may need to adjust MAXDOP based on factors such as the number of processors, the nature of your queries, workload characteristics, and the specific requirements of your SQL Server environment. It is essential to carefully tune this setting based on the characteristics of your database and the queries it processes to achieve the best overall performance.

How to Check the MAXDOP Setting

You can view your server’s MAXDOP setting by viewing the sever properties in SQL Server Management Studio. Simply right click on your server and select “Properties”, and navigate to the “Parallelism” section under “Advanced”.

You can also use the built-in sp_configure system stored procedure to view and change the MAXDOP setting. sp_configure is a system stored procedure designed to show and change server-level configuration settings on SQL Server. To use sp_configure to find your MAXDOP setting, run the following code:

EXEC sys.sp_configure 'max degree of parallelism'; 

How to change the MAXDOP Setting

Changing your server’s MAXDOP setting is just as easy as viewing it. From SQL Server Management Studio simply change the existing value to the desired value and click “OK” at the bottom of the properties widow.

To change the MAXDOP setting using sp_configure, use the below code to set the desired value:

EXEC sys.sp_configure 'max degree of parallelism', '<desired value>';
RECONFIGURE;

Of course, you should be careful when changing MAXDOP or any other setting in SQL Server. A change may help or hurt performance. And remember, since MAXDOP is set at the SQL Server instance level, it will affect all databases on the SQL Server. A change that helps one query for one database may adversely affect other queries and other databases.

It’s important to baseline performance and monitor the results after making a change.

For more information

Do you have questions about your SQL Server’s MAXDOP setting? Or are you having some performance concerns? Here are some other posts and links that may be helpful.

• Configure the max degree of parallelism (server configuration option) – SQL Server | Microsoft Learn
• dbatools docs | Set-DbaMaxDop
• dbatools docs | Test-DbaMaxDop
• Infographic: 5 Commonly Overlooked SQL Server Settings
• What is a SQL Server Recovery Model?
• Why is My SQL Server Slow? 14 Common Reasons
• Do I Still Need a SQL Server Health Check?

If you’d like some assistance assessing your SQL Server workload, contact us. We’re happy to help.

The post SQL Server Settings: MAXDOP appeared first on The SERO Group.

The specs for the VM we’re using are:

• Standard B4ms (4 vcpus, 16 GiB memory) – Supports up to 2880 IOPs or 35 MBps.
• Target disk – Standard SSD E10 – 500 IOPs or 60 MBps. This drive is capable of bursting to 600 IOPs or 150 MBps.

We’ll use Microsoft’s diskspd utility to generate the load using the 8kb block size.

Azure VM Metrics – Reviewing disk-related counters

Using Azure VM Metrics, you can review numerous counters related to the VM and create alerts based on a set threshold. We’re focused on the following counters within the Virtual Machine Host namespace. Three separate charts are used. FYI, filters can be added if you’re only interested in a specific disk. Identify the disk LUN and then add the LUN filter to the chart.

Disk Throughput / Sec – Write and Read

• Data Disk Write Bytes/sec
• Data Disk Read Bytes/sec

Disk Operations / Sec (IOPs) – Write and Read

• Data Disk Write Operations/sec
• Data Disk Read Operations/sec

Disk Latency

• Data Disk Latency (Preview)

The screenshot below shows each one of the counters. The time range has been set to the last 30 minutes, which refreshes every 5 minutes.

In the example above, we’ve maxed out on read IOPs, leading to severe latency (above 1 second). By maxing out on IOPs, we’re also limiting in how much data can be read from the disk. At 8kb blocks * 524 IOPs, the disk maxes out at 4.1 MB/s. It’s important to note that if your application reads or writes in larger block sizes it is possible to increase throughput at the cost of lowering IOPs.

Conclusion

The example above represents a bottleneck encountered at the disk vs. the VM size. We’re nowhere near the VM’s limit of 2,880 IOPs or 35 MBps. Azure VM Metrics is a fantastic way to review performance counters directly from within the Azure portal.

For more information

If you’d like some assistance assessing your SQL Server workload on an Azure Virtual Machine, reach out. We’re happy to help.

In the meantime, here are some other posts you may find interesting.

• Identifying SQL Server Disk Latency
• Identify Disk I/O Performance Issues for Your SQL Server Using DiskSpd
• Azure shared disks – Failover Clustered Instances
• How to Create SQL Server 2019 Failover Clustered Instances in Azure
• Why is My SQL Server Slow? 14 Common Reasons
• 10 Data Storage Considerations for Growing Companies

The post Analyzing Disk Latency in Azure Virtual Machines – Part 2 appeared first on The SERO Group.

RTO and RPO considerations webinar

Many companies take virtual machine snapshots. They snapshot their web servers and their file servers. They snapshot before software patching, before server upgrades, and before other configuration changes.

And with good reason. Snapshotting can be a great way to ensure you can recover the VM if something goes wrong.

What about SQL Server? Should you use VM snapshots to backup SQL Server? Are there RTO and RPO considerations of using snapshots instead of other approaches to backups?

In an upcoming webinar, we’ll discuss using VM snapshots as part of your backup strategy. We’ll pose eight important questions you should ask before adopting the snapshot approach.

Here’s what we’ll cover:

• Why backup?
• RPOs and RTOs
• 8 questions to ask
• Best practices
• Frequently Asked Questions

Who should attend:

This webinar will provide a discussion for those responsible for setting backup and recovery policies. It will benefit those who work with key stakeholders to understand the organization’s Recovery Point Objectives, and Recovery Time Objectives.

Want to attend?

The webinar is Wednesday, February 28 at 11:00 AM – 12:30 PM CDT. That’s 18:00 UTC.

To register, visit the Eventbrite page, or complete the embedded version below.

Have some specific questions?

Backups are good. But it’s the ability to restore that is important. How confident are you that you can restore a critical database? Are you sure that your backup strategy meets your RTO’s and RPO’s?

Here are some posts that may help.

• Where to Start with Disaster Recovery in SQL Server
• High Availability and Disaster Recovery in SQL Server
• What is a SQL Server Recovery Model?
• Script: How Long Until My SQL Server Backup/Restore Completes?
• How to Test SQL Server Backups Using dbatools
• How Often Should I Test My SQL Server Backups?

We help a lot of companies configure their SQL Server environment so that when a disaster strikes, they’ll be prepared. Want to learn more? Schedule a call and let’s talk.

The post Should I Use VM Snapshots to Backup SQL Server? A Webinar appeared first on The SERO Group.

When hosting SQL Server on Azure Virtual Machines, choosing the right combination of VM size and disk types is essential from both a cost and performance perspective.

However, workloads change over time and may require resizing the Azure VM or disks. For example, perhaps you deployed a new application that utilizes SQL Server on an Azure Virtual Machine. At first, usage was low, but now the application has become critical to the organization, and usage has increased significantly. You’ve noticed disk-related waits in SQL Server have increased, and you are wondering how to address the latency and end users have started to complain.

Tracking down disk performance issues can be tricky. There are multiple layers to consider. Is it the virtual machine or the disk(s) causing the bottleneck?

In Azure, disks and VMs have a cap on how much throughput and IOPs can be performed. When looking into disk performance issues, it’s essential to account for the following at both the VM level and Disk level, as each has different levels of performance:

• VM – Max cached and temp storage throughput (IOPs/MBps). Not all VMs support premium storage caching.
• VM – Max uncached disk throughput (IOPs/MBps)
• VM – Max data disks
• Disk – Max disk size
• Disk – Max throughput (MB/s)
• Disk – Max IOPs

To understand the VM level caps mentioned above, let’s review the three paths an IO can take: Cached, Uncached, Local/Temp disk.

Azure Virtual Machine Disk IO Paths

Cached

Purpose: Host caching in Azure is designed to improve performance by storing frequently accessed data closer to the VM. This caching mechanism enhances read operations and can significantly reduce latency.

Types of Operations: It’s typically used for read-heavy workloads. You can configure host caching to be read-only or read/write (not recommended for disks hosting transaction log files). Read-only caching is ideal for workloads that predominantly involve read operations, while read/write caching is suitable for a balance of read and write operations.

Performance: Cached I/O allows for higher IOPS and throughput as it utilizes the VM’s cache, which is faster than accessing data directly from the disk.

Limitations: The amount of storage available for host caching is limited and specified in the VM’s documentation. Also, cached I/O counts towards the VM’s cached limits.

Data Integrity: For read/write caching, writes are initially written to the cache and later written to the disk, which can be a concern for workloads requiring immediate persistence on disk.

Uncached

Purpose: Uncached disk I/O involves direct interaction with the disk without the intermediate caching layer. It is used for less frequently accessed data or when the latest data is required.

Types of Operations: Suitable for workloads that involve a significant amount of write operations or where data integrity and immediate persistence are crucial.

Performance: Generally, uncached disk I/O has lower performance compared to cached I/O due to the absence of the caching layer. The IOPS and throughput are limited by the disk’s and VM’s capabilities.

Limitations: The performance is constrained by the disk type and size and VM size. For example, a P30 disk can handle up to 5,000 IOPs.

Data Integrity: Since all operations are directly on the disk, there is immediate persistence of data, which is critical for certain applications and data security protocols.

Local/Temp disk

Purpose: Temporary disks provide short-term storage for applications and processes running on the VM. They are primarily used to store data that doesn’t need to be persistent, such as swap files, system caches, page files, or temporary data files (tempdb for example).

Performance: Temporary disks are typically faster than standard storage disks because they are located on the same physical machine as the VM. The performance of the temporary disk is tied to the VM size and offers high I/O throughput and low latency, making them ideal for temporary workloads and caching.

Data Persistence and Reliability: Data on the temporary disk is volatile. This means it persists only during the lifetime of the VM instance. If the VM is stopped or de-allocated (not just restarted), data on the temporary disk is likely to be lost. During some maintenance events or when the VM is moved to a different host hardware, the data on the temporary disk can also be lost.

Therefore, temporary disks should not be used for any data you need to keep.

To learn more on how Azure High-Scale VMs utilize disk caching, see here.

Azure VM Size Limitations

Each Azure Virtual Machine size has the following properties defined (some VM sizes include additional properties such as burstable credits and cached throughput):

• vCPU – Number of virtual CPUs
• Memory GiB
• Temp Storage
• Max Data Disks – Number of data disks that can be attached.
• Max Network Bandwidth (Gbps)
• Max NICs – Max number of network interface cards.
• Max uncached disk throughput IOPS/MBps – Combined total of all disks. For example, the remaining disks will encounter latency if one disk uses all available IOPs.

We’ll focus on the disk-related properties throughout this series.

Conclusion

In part 2, we’ll review an Azure VM experiencing high disk latency. We’ll use Azure VM Metrics to help identify where the bottleneck may be and how to alleviate the issue.

In the meantime, here are a few other articles that may be helpful.

• Azure shared disks – Failover Clustered Instance – SQL Server 2016
• Azure shared disks – Failover Clustered Instances
• How to Create SQL Server 2019 Failover Clustered Instances in Azure
• Identifying SQL Server Disk Latency
• 10 Data Storage Considerations for Growing Companies

If you’d like some assistance assessing your SQL Server workload on an Azure Virtual Machine, reach out. We’re happy to help.

The post Analyzing Disk Latency in Azure Virtual Machines – Part 1 appeared first on The SERO Group.

HADR for binkies? What? And how does this relate to SQL Server?

Sometimes the difference between the HA (High Availability) and DR (Disaster Recovery) can be difficult to grasp. There a nuances and the approaches can overlap. So, let’s consider an analogy – binkies and HADR in SQL Server.

As an infant, one of our daughters was very partial to her binky. She was seldom without one. Day or night, she “needed” her binky.

The Disaster Recovery analogy

We knew that life was better when she had a binky. Every time we left home, we strapped her into her infant car carrier, also known as a her “cry bucket”, and ensured she had a binky in her mouth.

If it was lost during our trip, life would be unpleasant. So we were prepared. We carried extra. At least one, sometimes more than one, just in case the unthinkable happened.

If she somehow managed to lose her binky, if it fell out along the way unnoticed, we would open the diaper bag and retrieve the spare.

That was binky DR. We would have to manually step in to solve the problem. She was disrupted until the fix was in place. But it was better than long periods of screaming about it. We could handle a little disruption and still avoid an all out disaster.

How this applies to SQL Server

The same is true for SQL Server. DR is a way to recover from some kind of disaster. It could be at the data center level, or at a SQL Server instance level. In either case, we need to recover from some kind of failure as quickly as possible.

In SQL Server, that could mean:

• Restoring from a backup. Assuming your backup process is robust, meets your RTOs and RPOs, and is regularly tested, you can apply the various backup files to get you back to whole again. Typically, you’ll restore a full backup, a differential backup, and then a serious of transaction log backups.
• Restore a virtual machine. If the failure affects the instance and not just a database, you may have to restore a virtual machine image. You may be done after that. Or you may have to restore a the backup files as described before to meet your RPO requirement.
• Switch to a stand-by SQL Server. Log-shipping can be a cost effective way to implement a level of DR. If you’re leveraging it as part of DR strategy, to recover you’ll need to make the standby SQL Server the new production SQL Server. You’ll stop log-shipping, recover database on the standby server, and point everything to the new production instance.
• Site-wide DR. Of course, some companies have a site-wide DR plan. If the entire data center is out of commission, they can failover to the DR site in another city or region. Properly configured, that can work very well. Typically, however, you don’t want to do that for a single instance of SQL Server. It’s reserved for disasters on a larger scale.

Disaster Recovery Summary

In all of these cases, manual intervention is required. Someone had to do something to get things back to normal. In our analogy, someone had to dig through the diaper bag to find the spare and give it to our daughter. Until that point, everyone was unhappy.

It’s also worth noting that we checked and double checked that we had a spare binky before leaving home. For SQL Server, you want to regularly test your backups to make sure you can indeed recover from them when needed.

High Availability

Our approach to binky DR when we left home tended to work pretty well. There were times when we weren’t able to recover quickly enough and drew awkward glares from those around us. However, for the most part it was a success.

At night it was a different story.

We would go through the bedtime process – reading a story, rocking for a little while, maybe even humming a lullaby, and gently placing her in her crib. Then we’d tip toe out of the room.

Unfortunately, at some point during the night, her binky would slip from her mouth. And before long, she’d notice. And when she noticed, we all were quickly made aware. One of us would have to get up, search through the blanket and put the binky back into her mouth.

Fortunately, we discovered a better way.

We began putting her in her crib with a binky in her mouth, and a spare one in each hand. That way, when the binky slipped from her mouth, she could quickly and easily replace it with one from her hand. This allowed her to sleep for longer periods and time. And us too!

Binky high availability at its finest.

How this applies to SQL Server

Many mission critical systems depend on SQL Server. For example, Practice Management Systems or Electronic Medical Records in healthcare, Project Management Systems or Job Costing Systems in construction, and core systems in the banking. They all rely on SQL Server. If SQL Server is down, the business is down. And that can be costly.

For those situations, we can leverage High Availability in SQL Server. Two technologies are commonly used.

• Failover Cluster Instance (FCI). With an FCI, one SQL Server instance is effectively spread across multiple Windows Server Failover Cluster nodes. SQL Server runs on the primary node. In the event of a planned or unplanned downtime, a secondary node will start its services, take ownership of the shared resources, and begin servicing application requests. This can happen automatically, often with minimal disruption to users.
• Availability Groups (AG). With an AG, SQL Server is installed on two or more nodes of a Windows Server Failover Cluster. (Strictly speaking the nodes don’t have to be WSFC. Linux clusters can be used.) As with the FCI, if a disruption occurs on the primary node, a secondary node will be promoted to primary and all application requests will be automatically directed to the new primary node. There are a lot of nuances to configuring an AG including synchronous / asynchronous transactions, automatic or manual failover, etc. The point here is that it can be configured to happen automatically and will little noticeable disruption to the end users.

High Availability Summary

One really nice distinction with High Availability is that it can happen automatically, without someone having to do something to make it happen. For businesses running critical applications on SQL Server, this can prevent costly unplanned and planned downtime.

For parents with kids dependent on binkies, this could mean hours of additional uninterrupted sleep each night.

In either case, HA can be really worth looking into.

Want to learn more?

Hopefully this analogy has helped. Here are a few addition resources that may likewise be helpful.

• What’s the Difference in SQL Server FCIs and AGs? – The SERO Group
• High Availability and Disaster Recovery in SQL Server – The SERO Group
• How to Create SQL Server 2019 Failover Clustered Instances in Azure – The SERO Group
• Azure shared disks – Failover Clustered Instances – The SERO Group
• Using VM Snapshots to Backup SQL Server? – The SERO Group
• Availability groups: a high-availability and disaster-recovery solution – SQL Server Always On | Microsoft Learn

If you’d like to talk though how improve your SQL Server’s reliability, give us a call. We’re happy to help.

The post HADR for Crying Out Loud appeared first on The SERO Group.

The same is true for SQL Server. A well maintained SQL Server is more reliable, performs better, and is more secure than one that’s neglected.

Required maintenance to keep your SQL Server running well

Like a car, SQL Server generally starts off running well. But to keep it running at peak performance, and to prevent an untimely and disruptive issue, you’ve got to maintain it.

Here are ten maintenance activities we recommend that will help.

1. Regularly backup your databases. Backups are crucial for protecting your data and ensuring that you can recover should a crisis happen.
2. Verify your backups. Regularly perform test restores of key databases. Run integrity checks on the restored databases. Document the process. See How Often Should I Test My SQL Server Backups?
3. Maintain indexes. Keeping your indexes optimized helps with database performance. We recommend Ola Hallengren’s SQL Server Backup, Integrity Check, Index and Statistics Maintenance
4. Update the statistics. Regularly updating statistics helps the SQL Server query optimizer generate better query plans. Bad statistics = bad query plans = bad performance.
5. Proactively monitor your SQL Servers. SQL Server has some alerting and monitoring capabilities. Use them. Third-party tools provide far greater insight into what’s going on under the hood.
6. Implement security best practices. Enforce security best practices such as separation of duties, the principle of least privilege, SQL Auditing, etc. See Who Has sysadmin Access to your SQL Servers?
7. Apply SQL Server patches. Keep your SQL Servers up to date with the latest security patches and Cumulative Updates to ensure that it is running efficiently and securely. See Should I Upgrade SQL Servers that Are Out of Support?
8. Daily health checks. Perform regular health checks to identify potential problems. Don’t rely on alerting and monitoring. Review the SQL Server logs daily. See Do I Still Need a SQL Server Health Check?
9. Monitor server resources. Monitor resources such as CPU, memory, and disk usage to ensure that the server can handle the load. Compile trends over time such as database growth, etc, so you can predict when additional resources will be required.
10. Performance tuning. Although this may not strictly fall under maintenance, regularly reviewing the most resource intensive operations and looking for ways to optimize them will help to keep your SQL Server running. See SQL Server Performance Tuning and the OODA Loop

That sounds like a lot

These ten maintenance activities will help. They will help improve your SQL Server’s performance, reliability, and security. That’s good. No one wants to be stranded by a car or by SQL Server.

However, the list above is not comprehensive. It’s a start. There are many other activities that can be regularly done to help your SQL Server, things an experienced DBA does on a regular basis.

• Translating and implementing the organization’s Recovery Point Objectives (RPOs) and Recovery Time Objectives (RTOs) in the organizations SQL Server estate
• Planning, testing, and documenting Disaster Recovery scenarios
• Implementing High Availability requirements
• Benchmarking performance and predicting when additional resources will be required
• Coordinating workload placement within the SQL estate
• Evaluating cloud options and comparing to colocation sites
• Reviewing problematic code with application developers
• Providing insights to and coordinating with venders to improve performance
• Documenting the SQL Server estate

We do these things and more for our SEROShield DBA Team as a Service clients.

If you’d like to learn more, contact us to schedule a short introductory call.

The post SQL Server Maintenance: 10 Things to Keep Your SQL Server Running Well appeared first on The SERO Group.