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.

Observability isn’t just about having monitoring tools. Monitoring tools cannot replace a good DBA. Observability is about building a culture where your team is aware of what’s happening in your SQL Server environment, can spot issues early, and feels confident responding to them.

Here are some things you can do today to start building that culture of observability in your SQL Server environment, even if you don’t have a full-time DBA.

1. Know What You’re Working With

If you don’t already have one, list all the SQL Servers in your environment. Then, do a quick health check on each one to determine their status.

Start with these four steps:

1. Get a list of all your production and lower-level SQL Servers.
2. Make sure your backups are working.
3. Check the integrity of your databases.
4. Determine your SQL Server version and patch levels.

For more information, see Working Without A SQL Server DBA? Do These 10 Things Now.

2. Know What “Normal” Looks Like

You can’t catch problems if you don’t know what healthy looks like. Start by tracking a few key SQL Server metrics:

• CPU usage 
• Buffer cache hits and PLE
• Disk I/O latency and throughput
• Wait stats
• Number of concurrent users
• Batch Requests/sec
• Transactions/sec
• SQL Errors

Even a simple baseline can help your team recognize when something’s off. Tools like SQL Server Management Studio (SSMS), built-in reports, or lightweight third-party monitoring tools can help you get started. You can query the Dynamic Management Views (DMVs) for a lot of this information.

3. Make Monitoring a Shared Responsibility

If you don’t have a DBA, observability has to be a team sport. Encourage your sysadmin or developer to think beyond “Is the server up?” and ask:

• Are backups running and restorable?
• When was the last time an integrity check was run?
• Are there long-running queries or blocking issues?
• Are we seeing unusual growth in database size?

Build a habit of checking these things regularly, not just when something breaks or when users are complaining.

4. Keep It Simple (and Visible)

You don’t have to have a complex monitoring stack to be effective. Start with what you have. Set up email alerts for failed jobs. Schedule maintenance jobs and verify they’re completed successfully. Run the benchmarking queries from Step 2 and monitor the results over time.

Create a shared dashboard with key metrics. Review it in your weekly team meeting.

The goal isn’t perfection. It’s awareness and visibility. It’s observability.

5. Encourage Curiosity

When someone on your team asks, “Why did this query suddenly slow down?”, encourage them to dig deeper. Give them the time and space to investigate. (Just make sure they use trusted sources—be careful downloading scripts from the internet!)

Curiosity is the foundation of observability. Make time to dig into odd behavior, even if it’s not urgent. That’s how you build a team that’s proactive, not reactive.

Know When (and Who) to Ask for Help

If your team doesn’t have the time or expertise to interpret what they’re seeing, important issues may be overlooked. That’s where we come in.

We help IT leaders like you make SQL Server environments more secure, reliable, and observable without the overhead of hiring a full-time DBA. Whether you need help setting up monitoring, tuning performance, or just knowing what to look for, we can help.

Schedule a discovery call, and let’s talk.

The post Creating a Culture of Observability in SQL Server, Even Without a Full-Time DBA appeared first on The SERO Group.

If you’re responsible for operational stability, data integrity, or risk, it’s essential to understand the impact of undermanaged SQL Servers. Read on to discover the biggest issues—and how to prevent them before they cause problems. We’ll also show you how to build a strong business case for proactive SQL Server management.

Three Biggest Liabilities of Undermanaged SQL Servers

1. Downtime Is Costly—and More Common Than You May Think

Let’s start with the hard numbers. In the financial services industry, the average cost of IT downtime is estimated at $9,000 per minute for larger institutions. While community banks and credit unions may not hit that number, even smaller outages can disrupt transaction processing, customer support, and access to critical data—leading to lost revenue and reputational damage.

Infosecurity Magazine recently reported a study from Contrast Security that indicated that over half (54%) of global financial institutions experienced cyberattacks in the past year where data was destroyed by adversaries. 

More tellingly, a 2023 Uptime Institute report found that over one-third of data center outages across all industries stemmed from system and software issues—many of which are database-related. These are not rare events. They’re happening every day in organizations that don’t have a dedicated plan for monitoring and managing their SQL Servers.

2. Security Threats Are Rising—and Databases Are a Target

As financial institutions increase their digital footprint, SQL Servers become even more attractive to cybercriminals. In 2024, the average cost of a data breach in the financial sector rose to $6.08 million, according to industry research reported in the ABA Banking Journal. That’s a 22% premium over the global average, reflecting the high value of financial data and the regulatory scrutiny that follows a breach.

Unpatched SQL Server instances, misconfigured access controls, and lack of encryption are all common vulnerabilities in unmanaged environments. Bad actors know this, and they exploit it.

Without regular audits, patching schedules, and proactive security monitoring, your institution could be one missed update away from its next major incident.

3. Performance Issues Impact Productivity and Customer Experience

An unmanaged SQL Server environment doesn’t just create security risks; it can slow down your business. Query bottlenecks, deadlocks, resource contention, and stale indexing strategies can cripple performance over time.

For your internal teams, this means longer wait times for reports and slower access to operational systems. For customers, it can mean delays in processing payments, loan applications, or online transactions.

Each delay has the potential to damage your reputation with your customers and to frustrate your team. Aren’t you tired of hearing, “I’m sorry, my computer is just slow today,” when you’re trying to get something done over the phone?

There’s Real ROI in Proactive SQL Server Management

The risks and the costs are clear. But that’s not the end of the story.

The upside is just as compelling. Here are some key benefits of a properly managed SQL Server estate.

Enhanced Performance

• Optimized Queries: Properly tuned SQL queries execute faster, leading to quicker application response times and improved user experience. 
• Efficient Resource Utilization: Monitoring and managing resources like CPU, memory, and disk I/O prevent bottlenecks and ensure optimal performance. 
• Database Optimization: Indexing, partitioning, and other optimization techniques improve data access speed and reduce query execution time. 

Reduced Costs:

• Resource Optimization: By identifying and addressing performance issues, you can optimize resource utilization and potentially reduce hardware costs. 
• Lower Downtime: Proactive maintenance and monitoring minimize downtime, reducing business disruption and associated costs. 
• Improved Security: Strong security measures prevent data breaches and compliance issues, which can result in significant financial penalties. 

Improved Data Management:

• Data Integrity: Proper backup and recovery procedures ensure data integrity and prevent data loss. 
• Compliance: Meeting regulatory requirements and industry standards reduces the risk of penalties and legal issues. 
• Data-Driven Decisions: Access to accurate and timely data enables better decision-making and improved business outcomes. 

What Proactive SQL Server Management Looks Like

Proactive management isn’t just about reacting to alerts—it’s about preventing problems before they start. This includes:

• Proactive Daily Health Checks
• Regularly reviewing SQL Server and Windows log files
• Real-time monitoring and alerting
• Regular performance tuning and index optimization
• Patch management
• Vulnerability scanning
• Secure access controls and encryption enforcement
• Backup validation and disaster recovery planning
• Monthly or quarterly health checks and reporting
• Annual Center for Internet Security (CIS) Benchmark Assessments

Whether you manage your servers in-house or partner with a specialized team like The SERO Group, having a defined strategy can reduce your operational risk while maximizing the value of your technology investments.

The Bottom Line: Proactive SQL Server Management is a Sound Investment

Your SQL Servers are too important to be treated as set-it-and-forget-it infrastructure. As regulatory pressures grow and customer expectations rise, your institution needs systems that are healthy, secure, and reliable.

By investing in professional SQL Server management, financial institutions can reduce downtime, strengthen cybersecurity, and improve performance—while freeing internal teams to focus on their primary duties.

Don’t wait for a breach or a breakdown to take action. Make your SQL Server estate’s health and resilience a strategic priority.

Want to learn more about how The SERO Group helps financial institutions keep their SQL Servers healthy, secure, and reliable? Schedule a no-obligation discovery call.

Learn more about our:

• SQL Server CIS® Benchmarks™ Assessment
• SQL Server Health Check

The post The Costs of Undermanaged SQL Servers for Financial Institutions appeared first on The SERO Group.

Multi-Attach EBS volumes in AWS enable organizations to use Windows Server Failover Clusters with shared storage. Attaching a single EBS (Elastic Block Store) to multiple EC2 instances simultaneously makes them ideal for SQL Server FCIs.

What are Multi-Attach EBS Volumes?

These EBS volumes are single Elastic Block Store volumes that can be attached to multiple EC2 instances. The feature is available for io1 and io2 Block Express volumes. However, Windows instances only support io2 Block Express volumes. Multi-Attach facilitates high availability and seamless failover for SQL Server FCIs (similar to how they operate on-premises).

Prerequisites

Before setting up these volumes for SQL Server FCIs, ensure the following prerequisites are met:

1. EC2 Instances in the same Availability Zone

All EC2 instances that will attach to the EBS volume must reside within the same AZ. This ensures low latency and high throughput between the instances and the EBS volume. This is critical for maintaining performance and reliability in a failover scenario.

2. Supported EBS Volume Types

While both io1 and io2 Block Express volumes support the Multi-Attach option, Windows instances only support io2 Block Express volumes. This limitation is due to the enhanced performance and features that io2 Block Express provides.

3. Regional Availability of io2 Block Express Volumes

Verify that io2 Block Express Volumes are available in your AWS region. Not all regions may support this volume type, so review the Amazon EBS Provisioned IOPS SSD volumes user guide to confirm availability.

4. Additional Networking and VPC Configurations

While this post focuses on EBS Multi-Attach, ensure that your networking and VPC configurations meet the requirements for setting up a Windows Server Failover Cluster. See this link to review the full list of prerequisites for WSFC.

io2 Block Express Volumes

These volumes offer the highest-performance block storage. Key features include:

• Capacity: Ranges from 4 GB to 64 TB, accommodating various workloads.
• Performance:
  • IOPS: Up to 256,000 IOPS per volume.
  • Throughput: Maximum throughput of 4 GB/s per volume

These high-performance metrics make io2 Block Express volumes ideal for demanding SQL Server workloads, especially those requiring rapid data access and high transaction rates.

Compatibility

io2 Block Express volumes are available on all Nitro-based EC2 instances. The AWS Nitro system is a collection of hardware and software components designed to provide enhanced security, performance, and flexibility for EC2 instances.

Enabling Multi-Attach for EBS Volumes

By default, this option is disabled but simple to enable. See this link for instructions on using the AWS Console or Command-Line.

Want to work with The SERO Group?

Want to learn more about how The SERO Group helps organizations take the guesswork out of managing their SQL Servers? Schedule a no-obligation discovery call with us to get started.

The post How to Build SQL Server FCIs in AWS with Multi-Attach EBS Volumes appeared first on The SERO Group.

Although Basic AGs were introduced before SQL Server 2022, we’ll focus strictly on the latest version.

Let’s review the requirements and limitations.

Requirements and Limitations

SQL Server Edition and Version:

• Standard Edition: Both the primary and secondary replicas must be running SQL Server 2022 Standard Edition. Basic Availability Groups are unavailable in the Express, Web, or Enterprise editions.
• Same Version: Ideally, all replicas should be running the same build of SQL Server 2022.

Verify the version by running SELECT @@VERSION. In the screenshot below, you can see which update has been applied and the SQL Server version and edition.

Windows Server Failover Clustering (WSFC):

• Cluster Configuration: A Windows Server Failover Cluster must be configured. All nodes participating in the Basic Availability Group must be members of the same WSFC.
• Operating System: The servers must be running a Windows Server version that supports failover clustering (e.g., Windows Server 2019 or 2022 recommended).
• Domain Membership: All nodes must be members of the same Active Directory domain or trusted domains.

In our example, we have a two-node WSFC cluster using Windows Server 2022 Standard Edition.

Network Requirements:

• Connectivity: Reliable network connections between the replicas are essential.
• Name Resolution: A proper DNS setup for name resolution between nodes is preferred.
• Static IPs: It’s highly recommended all replicas utilize static IP addresses vs. DHCP-assigned IPs.

Database Requirements:

• Full Recovery Model: The database to be included in the Basic Availability Group must use the Full recovery model.
• Single Database Support: Basic Availability Groups support only one user database per group.
• Initialization: The database must be initialized on the secondary replica using a full backup and transaction log backups. Automatic seeding can be used as well.

Replica Limitations:

• Number of Replicas: Only two replicas are supported. One primary and one secondary.
• Secondary Replica Limitations
  • Non-Readable: The secondary replica is not accessible for read operations.
  • No backups: You cannot perform backups on the secondary replica.
  • Synchronous Commit: To support automatic failover, Availability Mode must be set to synchronous commit. This is also a requirement for standard Availability Groups.

Licensing:

• Proper Licensing: Ensure that all SQL Server instances are properly licensed under Microsoft’s licensing terms for high-availability setups. See Microsoft’s licensing documentation for full details (SQL Server 2022—Pricing | Microsoft).

Permissions and Roles:

• Service Accounts: To reduce complexity, it’s recommended to use the same SQL Server service account on both replicas. Consider using group managed service accounts for further simplification.
• Firewall Settings: Configure Windows Firewall to allow communication between the replicas on the required ports (default is TCP port 5022).

Endpoint Configuration:

• Database Mirroring Endpoint: This must be configured on each replica for data synchronization. If using the wizard in SSMS, the endpoint is created and configured.

Quorum Configuration:

• Proper quorum configuration is essential to maintain cluster health and support automatic failover. This is done within the WSFC.

Summary of Limitations

• Single Database Limitation: Only one database can be included in a Basic Availability Group.
• Limited to Two Replicas: Only one primary and one secondary replica are allowed.
• No Read-Scale Capabilities: Unlike Availability Groups in Enterprise Edition, Basic Availability Groups do not support readable secondary replicas.
• No Backup Offloading: Backups cannot be performed on the secondary replica.

Conclusion

Basic Availability Groups can fill the gap if your environment doesn’t support a WSFC with the shared disk. However, due to their limitation of supporting only one database, ongoing management of multiple Basic AGs may not be ideal. For example, I’d still use a failover clustered instance if any of the following were true:

• SQL Server Standard Edition is used.
• Not spanning multiple data centers.
• The environment allows for the use of shared disks between machines.

Want to work with The SERO Group?

Want to learn more about how The SERO Group helps organizations take the guesswork out of managing their SQL Servers? Schedule a no-obligation discovery call with us to get started.

The post Basic Availability Groups: Affordable High Availability with Key Limitations appeared first on The SERO Group.

What are contained Availability Groups?

Contained AGs enhance the traditional Availability Groups (AGs) introduced in SQL Server 2012. CAGs include user databases and the associated server objects, such as logins, permissions, and SQL Server Agent jobs. Contained AGs automatically sync these objects across replicas. This saves the DBA from having to manually make these changes.

Key benefits of contained AGs

Ease of Management: Contained AGs bundle both databases and associated instance-level objects, simplifying management. This especially simplifies managing complex environments in which an application depends on resources outside of the database replica. Before CAGs, the synchronization of these objects required home-grown solutions using T-SQL and/or PowerShell.

Seamless Failover: With traditional AGs, failover could sometimes result in missing instance-level objects, leading to broken applications. CAGs ensure that all necessary objects are included within the group, providing a seamless failover experience.

Getting started

To get started, you’ll need:

• A Windows Server Failover Cluster (preferably Windows Server 2022) with at least two nodes.
• SQL Server 2022 Enterprise Edition. Developer Edition works for testing purposes.

Additionally, the following resources can be used as a guide for building your contained AG:

• SQL Server Contained Availability Groups Configuration (mssqltips.com)
• What is a contained availability group? – SQL Server Always On | Microsoft Learn

Want to work with The SERO Group?

Learn how The SERO Group can simplify SQL Server management for your organization. Schedule a no-obligation discovery call with us to get started.

The post Streamline SQL Server Management with Contained Availability Groups appeared first on The SERO Group.

But why now? They’ve been in business for years and are just now interested in HA/DR. What changed?

Reasons vary, but the following are very common:

• A new cyber insurance policy requiring a HA/DR or business continuity plan.
• A need for HA/DR capability in order to create or develop a new revenue stream.
• General curiosity due to SQL Server marketing materials.
• A new client or business group who has asked about HA/DR.
• Concerns raised during a recent audit.
• Recent outage that impacted revenue.

SQL Server has several options to choose from when it comes to HA/DR. These include:

• Log Shipping: No automatic failover capabilities. Available on SQL Server Standard and Enterprise editions.
• Database Mirroring: Deprecated, don’t use it in new environments.
• Failover Cluster Instances: Available on SQL Server Standard and Enterprise editions.
  • What’s the Difference in SQL Server FCIs and AGs?
• Availability Groups

Since you’re here to learn more about availability groups, I’ll introduce you to the two main types.

Availability Groups

Availability Groups were introduced in SQL Server 2012 Enterprise Edition. They provide advanced high availability and disaster recovery capabilities.

• Edition Support: Available in SQL Server 2012 Enterprise Edition and later. FYI: Official support for SQL Server 2012 ended in 2022.
• Number of Replicas: SQL Server 2022 specs – One primary and up to 8 secondary replicas (under asynchronous-commit mode or up to 5 can run under synchronous-commit mode).
• Supports readable secondaries: Yes
• Failover: Supports automatic failover for synchronous-commit replicas and manual failover for asynchronous-commit replicas.
• Use Cases:
  • Ideal for mission-critical applications requiring high availability and disaster recovery across multiple databases.
  • Suitable for enterprises needing advanced features like read-only secondary replicas for offloading read workloads.

Requirements:

• Same OS version on all nodes.
• Proper network infrastructure to support data replication with minimal latency.
• Windows Server Failover Clustering (WSFC). There are some exceptions to this that I’ll cover in a later post.
• SQL Server 2019 Enterprise Edition or later. Available with earlier versions, but those are out of mainstream support. I wouldn’t want you building a new AG on unsupported versions. In fact, that would almost certainly raise flags in other areas of your cyber insurance policy.

Basic Availability Groups

Up until SQL Server 2016, AGs were only available in Enterprise Edition. However, in 2016, Microsoft introduced us to Basic Availability Groups. Basic AGs provide an introduction to high availability and disaster recovery solutions for a single database.

• Edition Support: Available in SQL Server 2016 Standard Edition and later.
• Number of Replicas: Supports two replicas (one primary and one secondary).
• Supports readable secondaries: No. See the limitations here.
• Failover: Supports automatic failover, but only in a single-database environment.
• Use Cases:
  • Ideal for small businesses or environments where budget constraints prevent the use of Enterprise Edition.
  • Suitable for applications that require minimal HA/DR capabilities.

Requirements:

• Same OS version on both nodes.
• SQL Server 2016 Standard Edition or later.
• Windows Server Failover Clustering (WSFC)
• Proper network infrastructure to support data replication with minimal latency.

Which should you choose?

Getting AGs right takes practice. When done wrong, performance and availability can both suffer. Budgets can be destroyed by licenses. Understanding your options, including their requirements and differences, can help you choose the right solution for your environment. Whether you’re driven by audits, insurance policies, or those uncomfortable “could not open a connection to SQL Server” errors, investing in HA/DR solutions is crucial for maintaining business continuity and minimizing downtime.

So, which would I choose? If I had the option to use shared storage, I’d opt for building a failover clustered instance instead of using a Basic AG. FCIs support failover of multiple databases and can be used with Standard Edition. However, if shared storage isn’t an option and you need automatic failover capabilities for a single database or if you’re working in a hybrid environment (Azure and on-premises), Basic AGs may be a good choice for you.

Have questions about HA/DR? Here are two ways we can help.

1. Schedule a call with us to connect with our consultants. We’ve helped numerous clients just like you meet their uptime objectives.
2. Consider SEROShield, our DBA team as a service. Not only will we help build the AG, but we’ll also support it. It’ll be like driving around in a new car (you know, the one with the new car smell) that you know is covered by the best possible insurance.

Next in this series

There are a few lesser-known availability group types that we didn’t discuss today but will in upcoming posts: Contained AGs, Distributed AGs, and Domain-independent AGs.

Follow us on LinkedIn to get notified when we release new blog posts.

The post Availability Groups: What’s Right for Your Business? appeared first on The SERO Group.

Minimum server memory

The minimum server memory setting in SQL Server determines the smallest amount of RAM that SQL Server will grab. SQL Server will always have at least this much memory available to use, even when the system is under heavy load. The default setting for minimum server memory is usually very low, and SQL Server dynamically adjusts its memory usage based on its workload.

Maximum server memory

The maximum server memory setting in SQL Server limits how much of your computer’s memory SQL Server can access. By default, SQL Server grabs as much memory as possible, which can lead to problems. If SQL Server takes up all the available RAM, it slows down other programs running on the same server (such as SSIS, SSRS, or SSAS), making everything feel sluggish.

Configuring minimum server memory

Configuring minimum server memory is usually easy because, in most cases, it’s best to leave it set to the default. Sometimes people will set the minimum and maximum server memory settings to the same value to “lock in” the memory. I’ve seen this in virtualized environments as an attempt to prevent the hypervisor from “ballooning” and taking away the resources that are supposed to be allocated to SQL Server. The risk with this type of configuration is that during a restart, SQL Server will not come online until it has claimed all of the RAM listed in the minimum server memory setting.

You can configure your server’s minimum server memory setting in SQL Server Management Studio. Find the server properties section, then look for the minimum server memory option.

You can also make this change by running the following script:

sp_configure 'min server memory', <desired memory amount (mb)>;
GO

Configuring maximum server memory

The default maximum server memory setting can sometimes cause performance issues. By limiting the RAM SQL Server uses, you can ensure there’s enough memory for the operating system and other applications to run smoothly.

Honing in on the exact number can be tricky, as it depends greatly on the load your SQL Server is under, as well as any other applications that may be running on it. However, configuring the maximum server memory appropriately ensures SQL Server has enough memory to perform efficiently without starving the operating system or other applications of the resources they need. This balance helps maintain system stability and performance.

For example, if you have SSAS installed on the SQL Server, by default it will claim 20% of the RAM on the server, leaving only 80% available for SQL. I’ve seen scenarios where SQL Server crashed with an “insufficient system memory” error every time it tried to go above 80% RAM usage because SSAS refused to release its 20%.

To configure maximum server memory, start by following the same steps as you did above. You can configure your server’s minimum server memory setting in SQL Server Management Studio. Find the server properties section, then look for the maximum server memory option.

You can also make this change by running the following script:

sp_configure 'max server memory', <desired memory amount (mb)>;
GO

Final thoughts and next steps

Although SQL Server will manage its memory dynamically right out of the box, its default settings may not suit every scenario. Fine-tuning minimum and maximum memory settings means efficient server performance without depriving the operating system and other applications of resources. Careful memory configuration can help you achieve an optimized and balanced server environment.

Further reading

• How Much Memory is “Normal” for SQL Servers? – Brent Ozar
• Memory management architecture guide – Microsoft Learn

Previously in this series

• SQL Server Settings: MAXDOP
• SQL Server Settings: Optimize For Ad-hoc Workloads

Work with us

Want help optimizing your SQL Servers? Schedule a free call with us to learn more and get started!

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

In this post, we’ll review why mixing these two backup types can pose risks and how to mitigate these challenges. Here’s what we’ll cover:

• Understanding SQL Server Native Backups – Full, Differential, Log
• Snapshot Backups and SQL Writer
• Impact of snapshot backups on native backups
• Conclusion

Understanding SQL Server Native Backups

We generally recommend using a combination of native SQL Server backups. This can vary a bit depending on a client’s RPO and RTO requirements. Let’s start with the full backup as it serves as the foundation for any backup strategy, establishing a baseline state of the database.

Full Backup

A full database backup creates a complete copy of the entire database at a specific point in time. This type of backup captures the state of the database, including all the data files (mdf and ndf), log files (ldf), and part of the transaction log necessary to ensure the database’s consistency. The main purpose of a full database backup is to provide a starting point for database recovery, allowing the restoration of the database to its state at the time of the backup.

How it Works

When a full database backup is initiated, SQL Server begins by writing a portion of the transaction log to ensure that the backup reflects a consistent state of the database. This means that the backup will include all committed transactions up to the point at which the backup was taken. Uncommitted transactions are not included in the backup, but the data necessary to roll back these transactions is and ensures the database can be restored to a consistent state.

Full backups are straightforward to manage. They do not require additional log or differential backups to restore the database to the specific point in time. However, they can be large and time-consuming. Depending on the database size and available storage, full backups might not be feasible to perform very frequently. This can influence the recovery point object.

We recommend a full backup at least once per week. Next, we move on to nightly differential backups.

Differential Backup

Differential backups only include the data that has changed since the last full backup. Instead of backing up the entire database every time, a differential backup captures only the modifications, making it a faster and more storage-efficient way to maintain up-to-date backup copies of your data.

How it Works

The starting point for differential backups is the last full backup. This full backup serves as the baseline from which all changes are tracked. Tracking is done by marking extents in the database as changed whenever data is modified. Differential backup operations rely on a bitmap page that contains a bit for every extent. Each extent updated since the last full backup is set to 1 in the bitmap.

Subsequent differential backups will also contain all changes since the last full backup, not since the previous differential backup.

This is extremely important when considering a mix of SQL Server native backups and VM or disk based snapshots. Snapshots, using volume shadow copy services and the SQL writer are full backups and will reset the starting point for differentials which occur after them (unless specified to use the COPY ONLY option). We’ll see this scenario later in the demo.

The main advantage of differential backups is efficiency. They are typically much quicker to complete than full backups because they involve less data. They also require less storage space. However, they do add to the complexity of database restores. You first restore the most recent full backup without recovery and then restore the latest differential. Or the differential that occurred closest to the point in time you need to recover to. You do not need to apply each differential backup sequentially.

Let’s look at log backups next. A good starting point, again dependent on your RPO, is to perform a log backup every 15 minutes.

Log Backup

To perform a log backup, the database must be using the full or bulk-logged recovery model. These backups allow for point-in-time recovery of the database, providing a high level of data protection by ensuring that all transactions are recoverable. They capture all transaction log records since the last log backup. The transaction log is a serial record of all changes made to the database, including both data modifications, and enables rollbacks of those modifications if transactions are not completed successfully.

How it Works

SQL Server continuously records all database transactions in the transaction log file. This log includes every insert, update, delete, and schema change operation. Regular log backups are essential for truncating the transaction log file. Truncation does not reduce the file size but marks the space as reusable for new transactions. Without log backups, the transaction log can grow indefinitely, consuming disk space and potentially impacting database availability and performance. The database must be in full recovery or bulk-logged recovery. Full being the most prominent.

To restore you’ll begin by restoring the last full backup (without recovery), the last differential (without recovery) if part of your backup strategy, and then all log backups up to a specific point in time. This is a sequential process requiring all log backups to be applied in order. If one is missing then the restore will fail and you’ll be limited to the point in time just before the break.

It’s important to note some 3rd party VM snapshot solutions include an option to truncate the log after taking a snapshot backup. They do this by initiating a “BACKUP LOG DatabaseName TO DISK = ‘NUL’” command. This will break your transaction log backup sequence and impact your RPO.

Snapshot Backups and the SQL Writer Service

Snapshot backups, using volume shadow copy service and SQL writer, are extremely fast. VSS is a Windows-based technology that allows backup applications to safely back up locked and open files. It’s particularly useful for creating snapshots of databases and other applications that continuously run and handle data.

VSS operates at the file system level and can create a snapshot – a read-only, point-in-time copy of data in seconds. This snapshot technology ensures that files are in a consistent state when backed up.

SQL Server VSS Writer is a Windows service that uses the VSS framework to facilitate creating backups and restores for SQL Server databases. When a VSS-based backup is initiated, the SQL Server VSS Writer ensures that database files are in a transactionally consistent state, making them suitable for backup purposes. The writer is aware of SQL Server’s data files and log files and can freeze and thaw database operations intelligently to ensure data consistency without shutting down the database. You’ll see these operations reported in the SQL Server error log as “I/O is frozen…” events. Log backups are not supported (see here for additional details).

How They Work Together

1. When a snapshot backup is requested, the backup application communicates with the VSS to initiate the backup process. Snapshots that do not use the COPY ONLY option will reset the starting point for your native differentials.
2. VSS communicates with the SQL Server VSS Writer to prepare the databases for a consistent snapshot. This involves ensuring that all transactions are complete and that the databases are in a stable state. I/O is paused.
3. Once the databases are prepared, VSS instructs the storage system to create a snapshot. This process is usually quick and efficient. This does not involve copying data but rather capturing the state of the data at a specific point in time.
4. After the snapshot is taken, the SQL Server VSS Writer allows SQL Server to resume its normal operations, minimizing downtime and impact on the system. However, this can vary if there’s a large number of databases.
5. The snapshot can then be used to create a backup copy of the database files without affecting the running database(s).

Impact of snapshot backups on native backups

I’ve mentioned the impact snapshot backups can have on native SQL Server backups a few times. Especially when using a mix of full, differential, and log backups as recovery relies on a carefully orchestrated sequence. Let’s see this in practice. I’m going to use a tool built into Windows, called DISKSHADOW, which will mimic a backup application to create a VSS snapshot. Here’s the breakdown (please don’t do this in production).

Test Environment:

The demo database is using the full recovery model.

Step 1: Create a native full backup of BackupDemo.

Step 2: Create a native differential backup of BackupDemo.

Step 3: Create a snapshot backup using DISKSHADOW.

Step 4: Open notepad and add the following. In this demo the BackupDemo database files reside on F and G. Save the file as snapshot.txt in the C:\backup folder.

#Diskshadow script file
writer verify "SqlServerWriter"
set metadata C:\Backup\diskshadow_c_f_g.cab
begin backup
add volume F: alias SQLVMDATA1
add volume G: alias SQLVMLOG
create
end backup
#End of script

Step 5: Open a command prompt as an administrator.

Step 6: Run the following.

cd C:\Backup
diskshadow -s C:\Backup\snapshot.txt

Step 7: Once complete, run a second differential backup.

Step 8: Attempt a database restore using the native full backup and the second differential.

RESTORE DATABASE BackupDemo
FROM DISK = 'G:\BACKUP\SQL1\BackupDemo\FULL\SQL1_BackupDemo_FULL_20240306_104745.bak'
WITH NORECOVERY, REPLACE, STATS = 10

RESTORE DATABASE BackupDemo
FROM DISK = 'G:\BACKUP\SQL1\BackupDemo\DIFF\SQL1_BackupDemo_DIFF_20240306_114303.bak'
WITH RECOVERY, STATS = 10

The error below will be encountered due to the snapshot backup occurring between the native full backup and the last differential.

Msg 3136, Level 16, State 1, Line 44
This differential backup cannot be restored because the database has not been restored to the correct earlier state.

Msg 3013, Level 16, State 1, Line 44
RESTORE DATABASE is terminating abnormally.

Conclusion

Mixing SQL Server native backups and snapshot backups in an environment isn’t ideal due to the complexities it introduces.

If your organization is using VM or disk snapshots be sure those can meet recovery point objectives. Document and test the restore process using the backup application.

If both types of backups are required, use the COPY ONLY option for all snapshot-based backups and make sure the backup application is not set to truncate transaction logs.

Want to know more?

Here are some additional posts that may be helpful.

• How to Align Your SQL Server to Your RPO and RTO Goals
• What is a SQL Server Recovery Model?
• Using VM Snapshots to Backup SQL Server?
• Where to Start with Disaster Recovery in SQL Server

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

The post The Risks of Mixing SQL Server Native Backups with Snapshot Technologies appeared first on The SERO Group.

A severe error occurred on the current command.  The results, if any, should be discarded.

You give it a try and receive the same error, then proceed to call the support desk, and the conversation may go something like this.

You: “Hey, I’ve been hearing reports about some issues with the application’s database. Do you have any insights on what might be happening?”

Support: “Sure, the server is online and accessible; all the monitoring dashboards are showing green indicators.”

You: “Great, thanks for checking that. What about the database itself? Is it online and accessible for direct querying outside of the application?”

Support: “Absolutely, I’ve verified that as well. I actually used SQL Server Management Studio to run a few test queries directly on the database. The data is coming back without any errors.”

You: “Hmm, that’s really puzzling. If the server and database seem to be in good shape, then why are users encountering problems? Can you do a specific test for me? Try performing an update on the dbo.Sales table, focusing on the row that’s causing issues in the application.”

Support: “Sure, I’ll give it a shot right now… Oh, that’s strange. I just attempted the update, and I’m getting the same error that users are reporting.”

It’s at this point you realize the database may be corrupted, and you’re beginning to experience abdominal pain (database corruption has a funny way of doing that). Now what?

5 Ways to Detect Database Corruption Early

You’ll likely encounter this situation if you use databases long enough. Corruption is going to happen. The key is to detect database corruption early and to know how best to recover from it. For some great insights on dealing with database corruption, see Paul Randal’s https://www.sqlskills.com/blogs/paul/sqlskills-sql101-dealing-with-sql-server-corruption/. I can’t recommend his post enough. It’s great.

Let’s look at 5 ways to detect database corruption early.

1. Backups (with checksum)
2. Integrity Checks
3. PAGE_VERIFY database option
4. Test restores
5. SQL Server Agent alerts

1. Backups (with checksum)

Backups are extremely important in most production environments. Having backups in place and regularly testing restores ensures you can recover from corruption, if needed. Make sure the process meets your RTO / RPO requirements (see here for more details on RTO / RPO and setting SQL Server backups).

Save the backups on a different server via UNC path and possibly in the cloud as a secondary location. Azure Blob Storage is one possible solution.

2. Integrity Checks

Another key method to detect database corruption early is to run database integrity checks often.

DBCC CHECKDB checks the logical and physical integrity of all the objects within the specified database. It performs the following operations; DBCC CHECKALLOC, DBCC CHECKTABLE, DBCC CHECKCATALOG, validates the contents of every indexed view, validates link-level consistency between table metadata and file system directories and files when storing varbinary(max) data in the file system using FILESTREAM, and validates the Service Broker data in the database.

We recommend using Ola Hallengren’s maintenance solution to perform integrity checks. These scripts are freely available and are very well documented. If you don’t already have a maintenance solution, grab Ola’s scripts here.

Don’t have enough time to run DBCC CHECKDB due to database size or limited resources? Brent Ozar has a few methods that can be used to help speed things up. See here for details.

It’s extremely important to ensure you’re running integrity checks on important databases. It’s better to find corruption early vs waiting months or even years before knowing and being unable to recover when needed.

3. PAGE_VERIFY database option

The third way to detect database corruption early is to enable PAGE_VERIFY for all databases that you care about. There are three PAGE_VERIFY database options:

• NONE – Database page writes won’t generate a CHECKSUM or TORN_PAGE_DETECTION value. SQL Server will not verify a checksum or torn page during a read even if a CHECKSUM or TORN_PAGE_DETECTION value is present in the page header.
• TORN_PAGE_DETECTION – SQL Server saves a specific 2-bit pattern for each 512-byte sector in the 8-kilobyte (KB) database page and stored in the database page header when the page is written to disk. When the page is read from the disk, the torn bits stored in the page header are compared to the actual page sector information. Unmatched values indicate that only part of the page was written to disk, and error message 824 is reported to the SQL Server error log and Windows event log.
• CHECKSUM – SQL Server calculates a checksum over the contents of the whole page and stores the value in the page when written to disk. When the page is read from disk, the checksum is recomputed and compared to the checksum value stored in the page header. If the values don’t match, error message 824 is reported to the SQL Server error log and Windows event log. A checksum failure indicates an I/O path problem and requires further investigation.

SQL Server 2000 used a PAGE_VERIFY default setting of TORN_PAGE_DETECTION for all databases. If you’ve migrated databases over the years and are now running on a more recent version of SQL Server, check this setting. Restoring from an older version will not automatically set PAGE_VERIFY to the new default of CHECKSUM.

Verify that all databases are using the CHECKSUM page_verify option. You can use the t-sql statement below to do a quick check. Any that return a page_verify_option of NONE or TORN_PAGE_DETECTION should be evaluated.

USE MASTER
GO
select [name], page_verify_option_desc from sys.databases

4. Test restores

I’d recommend a regularly scheduled restore for your most critical databases. Having backups are great, but only if they can be used to recover a database when the need arises. I’d restore the databases and then run DBCC CHECKDB to ensure no corruption is encountered. Once every 90 days, or more frequently if needed, is where we generally start.

One solution you can use to test backups is the Test-DBALastBackup commandlet found in the dbatools module.

5. SQL Server Agent alerts for I/O errors

SQL Server includes built-in monitoring capabilities. However, you’ll need to configure the agent alerts, operators, and notifications manually. During our SQL Server health check, we’ll check for common alerts that should be enabled. Those include alerts for 823, 824, and 825 errors which could serve as early warning indicators of catastrophic disk I/O errors:

• Error 823 – SQL Server uses Windows APIs to perform file I/O operations. After performing these I/O operations, SQL Server checks for any error conditions associated with these API calls. If the API calls fail with an Operating System error, then SQL Server reports Error 823. These errors usually indicate a problem with the underlying storage system or hardware or a driver that is in the path of the I/O request. See more on this error here.
• Error 824 – SQL Server encounters this error message when a logical consistency check fails after reading or writing a database page. The error indicates that Windows reports that the page is successfully read from disk, but SQL Server has discovered something wrong with the page. It’s similar to 823, except Windows didn’t detect the error. There could be a problem with the I/O subsystem such as failing disk drives, firmware problems, faulty device drivers, and so on. See more on this error here.
• Error 825 – This message indicates that the read operation had to be reissued at least one time, and indicates a major problem with disk hardware. This message does not currently indicate a SQL Server problem, but the disk problem could cause data loss or database corruption if not resolved. See more on this error here.

Worried about database corruption?

Looking for more information about detecting database corruption and what to do about it? Read Paul’s post mentioned earlier. He provides an overview and steps on how you may potentially be able to recover. Our hope is that you never find yourself in a situation where you can’t recover.

Worried that your database is corrupt? Let’s set up a SQL Server health check.

If you’ve already detected database corruption, give us a call. We can help.

The post A Severe Error Occurred! 5 Ways to Detect Database Corruption Early appeared first on The SERO Group.