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.

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.

Let’s dive into some of the major risks you might face while managing your SQL Server estate. We’ll also explore some practical ways to mitigate those risks and keep your SQL Server estate running smoothly and securely.

Six Common Business Risks in a SQL Server Estate

Risk 1: Data Breaches

Data breaches are an obvious and constant threat. Hardly a day goes by without a security incident or data breach making the news. A single successful attack can expose sensitive information, damage your company’s reputation, and lead to hefty fines or lawsuits.

Securing your SQL Server estate is essential, and securing the perimeter is not enough. The best security is multi-layered.

To fortify your SQL Server defenses:

• Implement strong access controls and use multi-factor authentication.
• Regularly update and patch your SQL Server instances.
• Encrypt sensitive data both at rest and in transit.
• Conduct regular security audits to identify and address vulnerabilities.
• Train your teams on security best practices and the importance of data protection.

Risk 2: Disaster Recovery

Disasters happen. Sometimes large-scale events like a tornado, flood, or a disruption to your cloud provider’s region may affect your business. Sometimes disasters are more localized, like a hypervisor or operating system crash.

Regardless, without access to your data, operations can be significantly hampered or even completely offline. So, being prepared to quickly recover from such events is crucial for business continuity.

To improve your disaster recovery readiness:

• Develop and regularly update a comprehensive disaster recovery plan.
• Regularly test your disaster recovery procedures to identify and address any weaknesses.
• Consider cloud-based disaster recovery solutions for added flexibility and reliability.
• Ensure your team is well-trained on disaster recovery procedures and their individual roles.
• Implement high availability solutions like clustering or Always On Availability Groups.

Risk 3: Data Loss and Corruption

A common misconception is that data loss or corruption isn’t really an issue anymore. It is.

Database corruption can still happen. Users with higher levels of access can still accidentally delete needed data. And bad actors can still gain access to key systems and encrypt everything. And the results can be painful.

To protect your valuable data:

• Implement a robust backup strategy with regular backups stored securely off-site.
• Test your backups regularly to ensure they can be successfully restored.
• Implement change tracking and auditing to quickly identify and rectify data issues.
• Educate users about the importance of data integrity and proper data handling procedures.
• Use log shipping or Always On Availability Groups for critical databases.

Risk 4: Compliance and Regulatory Issues

Who has elevated permissions to your SQL Server estate? You’ll want to know and review that list regularly. When were users created and given access? When was the access removed? These are good questions to ask and answer, but that may not be enough.

If your company operates in a regulated industry or geographical location, you may be subject to regulatory requirements such as GDPR, CCPA, HIPAA, and others. Ensuring your SQL Server estate complies with relevant laws is crucial. Non-compliance can result in significant fines and legal headaches.

To navigate the complex world of data regulations:

• Stay informed about regulations that apply to your industry and data types.
• Implement data masking and row-level security to protect sensitive information.
• Cleanse data that is copied to lower-level systems such as dev, test, and QA.
• Regularly audit your compliance efforts and maintain detailed documentation.
• Use SQL Server’s built-in compliance features, such as Transparent Data Encryption and SQL Audit.
• Consider working with compliance experts to ensure you’re meeting all requirements.

Risk 5: Performance Issues

Poorly performing SQL Servers are more than just an annoying inconvenience. They can frustrate users, drive away customers, and affect your company’s bottom line. As the amount of data in your SQL Server estate grows, maintaining optimal performance becomes increasingly challenging.

To keep your SQL Servers running at top speed:

• Create a performance baseline.
• Regularly monitor performance metrics to identify bottlenecks.
• Optimize queries and indexing strategies.
• Implement proper capacity planning and scaling.
• Consider upgrading hardware or moving to cloud-based solutions when necessary.

Risk 6: Talent Shortage

SQL Server is a robust and reliable database platform. However, to achieve peak performance, reliability, and security, it must be regularly maintained. However, finding, recruiting, and retaining skilled SQL Server professionals can be a significant (and expensive) challenge.

To address this talent risk internally:

• Invest in ongoing training and professional development for your existing team.
• Create a positive work environment that encourages growth and job satisfaction.
• Offer competitive compensation and benefits packages to attract and retain top talent.
• Utilize managed services or cloud solutions to supplement your in-house expertise.
• If you rely on an Accidental DBA, provide them with the resources needed to succeed.

Managing Your SQL Server Estate

Managing a SQL Server estate is no small feat, but with the right strategies and precautions, you can significantly reduce your risks and keep your data operations running smoothly. Remember, it’s not about eliminating all risks – that’s nearly impossible. Instead, focus on identifying, understanding, and mitigating these risks to the best of your ability.

Remember, you’re not alone in this journey. Don’t hesitate to leverage external expertise when needed, whether it’s for specialized tasks, security audits, or strategic planning. With the right approach and resources, you can turn these challenges into opportunities to showcase the true value of a well-managed SQL Server environment.

Want to work with The SERO Group?

Want to learn more about how The SERO Group helps organizations manage their SQL Server estates? Schedule a no-obligation discovery call.

The post Reducing Business Risks for a SQL Server Estate 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.

The risks of delaying code analysis

Delaying an analysis of code compatibility is surprisingly common for businesses undertaking a migration to the cloud. Early cost-benefit analyses often address the hardware and infrastructure changes involved but can sometimes neglect to consider the impact of required code changes.

Infrastructure concerns are critical considerations when evaluating a move to the cloud. However, limiting our analysis to these considerations may hide the costs and risks associated with any necessary re-engineering. Unfortunately, it is very possible for these hidden risks and costs to turn out to be deal-breakers. To avoid a sticky situation, learn about these factors up front before investing time and energy into migration preparations.

Azure options: SQL VM vs. Managed Instance vs. SQL Database

It is important to note that a “move to the cloud” can come in many forms. Some examples are migrations to a hybrid environment, “lift and shift” moves to Azure-hosted VMs or SQL Managed Instances (SQL MI), or full or partial migrations to multi-tenant Azure SQL Databases (SQL DB). You will need to know what type of migration is being considered before evaluating code changes since the different options have different levels of compatibility with SQL Server.

Here’s a quick breakdown of the options in Azure with SQL Server compatibility.

IaaS Option

SQL Server on an Azure VM
Since this option constitutes a full installation of SQL Server on a dedicated Azure-hosted virtual machine, there are no code or feature incompatibilities to be concerned about. Azure SQL VMs achieve complete feature parity with on-premises SQL environments. With this option, the primary difference between the Azure implementation and an on-premises installation is the management of the underlying server.

PaaS Options

Azure SQL Managed Instance
SQL MI boasts “near 100% compatibility” with the latest Enterprise Edition of the SQL Server database engine, while still including automated backups, patching, and high availability of the SQL environment. This option uses a single-tenant database engine intended to enable the least disruptive migration from an on-premises or Azure-hosted SQL Server instance to a full PaaS environment. This means that many of the incompatibilities that exist with Azure SQL Database are minimized or eliminated with Azure SQL MI. However, functionality that requires access to the file system or OS is still impacted.

Azure SQL Database
Azure SQL DB is another fully managed PaaS option consisting of a multi-tenant database engine that is optimized for cloud-native applications. While this option is generally less expensive than Azure SQL MI, there is less overlap with SQL Server and greater potential for code or data flow incompatibilities.

10 Common Incompatibilities

There are several very helpful tools (see the “Resources and tools” section below) that can help you identify data flow issues prior to migration. As you go through your analysis, keep in mind that Microsoft has established workarounds for a good number of these incompatibilities, so their presence in your code does not necessarily mean they are a barrier to migration.

For a high-level overview, here are some of the most common sticking points we see for migrating SQL code. The differences between SQL MI and SQL DB are included where applicable, as well as some potential workarounds.

1. Uses linked servers

Linked servers can be used in SQL MI to access SQL Server and Azure SQL Databases without distributed transactions. SQL DB requires the use of elastic queries instead.

2. Performs cross-database queries or transactions

These are supported with SQL MI, but not with SQL DB. In SQL DB, cross-database queries may be able to be converted to elastic queries.

3. Uses Database Mail

This is available for SQL MI but not SQL DB. There are workarounds available for sending email in the Azure platform, but they will require some re-engineering.

4. Uses system tables, views, functions, or stored procedures

Some system objects are available in both SQL MI and SQL DB but not all. Consult Microsoft’s documentation for a full comparison of what is available.

One important note is that the amount of space available to tempdb is provisioned in both SQL MI and SQL DB based on the number of cores available and the service tier licensed. Consult the documentation of each for details.

5. Accesses Windows command line or file system

Neither SQL MI nor SQL DB supports direct access to the file system or the Windows command line.

One workaround is to migrate files to Azure Blob Storage or Azure Files. For SQL MI, with the appropriate security and firewall configurations, it is also possible to establish connectivity between your Managed Instance’s VNet and the location of an on-premises file share.

SQL MI also supports SSISDB configuration and the Integration Services Catalog, allowing SSIS packages to be used for file manipulation. Azure Data Factory can also be leveraged to load and transform files for both SQL MI and SQL DB. An Azure-SSIS Integration Runtime (IR) can be installed and configured, and SSIS packages can be run directly from Azure Data Factory.

6. Uses change data capture (CDC)

Change data capture is supported for SQL MI. It is also supported for SQL DB, but only in the S3 service tier and above.

7. Uses BULK INSERT or OPENROWSET

BULK INSERT and OPENROWSET are only supported from a supported Azure file source (e.g.: Azure Blob Storage or Azure Files).

8. Uses .NET Framework: common language runtime (CLR)

CLR support is not available for SQL DB, but it is available in SQL MI with some important differences.

9. SQL Server Agent

SQL Server Agent is not available in SQL DB, and elastic jobs should be used instead. In SQL MI, SQL Server Agent is supported with important differences.

10. Uses semantic search

Full-text semantic search is not available in either SQL MI or SQL DB.

Other important things to remember when migrating to a PaaS environment

• High availability: Since high availability is included in the PaaS offerings, SQL Server functionality and syntax connected with Always On Availability Groups is not supported.
• Maintenance: Updates, patches, backups, and restores are likewise managed automatically in the PaaS offerings. Therefore, associated T-SQL syntax will not work in SQL DB and will be different for SQL MI.
• Credential management: Windows authentication is not supported in SQL DB, and is replaced by Windows Authentication for Microsoft Entra in SQL MI.
• Collation: Catalog collation is set when an instance (SQL MI) or a database (SQL DB) is created, and it cannot be changed afterwards.

Resources and tools

I hope this provided you with a jump-start for thinking about whether your SQL Server code is Azure-ready.

Here are a few more resources and tools that can help you take the next steps toward a full compatibility analysis:

• Data Migration Assistant – Microsoft’s robust tool for enabling database compatibility assessments, recommendations, and migration assistance.
• Azure Migrate – this service can be used as a start-to-finish hub for planning and facilitating a cloud migration.
• Pro Database Migration to Azure – An excellent and comprehensive book covering the best practices for successful on-premises migrations to the Azure cloud platform.

Want to learn more?

Want to learn more about how The SERO Group helps organizations prepare for a SQL Server cloud migration? Schedule a call and let’s talk.

The post Is your SQL Server Code Ready for Azure? 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.

Azure Arc is a set of technologies from Microsoft that extends Azure management and services to any infrastructure, including other clouds, on-premises, and edge. This enables you to manage all your SQL Server instances across environments from a single, unified interface.

Why use Azure Arc-enabled SQL Server?

Organizations operating in hybrid environments often face challenges in maintaining consistency across their SQL Server instances. This is especially acute with complex compliance requirements and security policies. Azure Arc addresses these issues by: 

• Streamlining operations: Having a unified platform for managing all SQL Servers simplifies the DBA’s tasks.
• Enhancing security: Leveraging Azure’s robust security framework helps protect data across all environments.
• Improving compliance: Automated compliance tools reduce the risk of violations.

Let’s take a look at a few key features.

Key features of Azure Arc-enabled SQL Server

• Unified Management: Azure Arc provides a centralized portal for managing all your SQL Server instances. Whether your databases are on-premises, in the cloud, or at the edge, you can see them from the Azure Portal. 
• Automated Updates: One challenge with managing SQL Servers across different locations is ensuring they are all updated and patched consistently. Azure Arc can automate this process, ensuring instances are always up to date with the latest security patches and performance improvements. 
• Advanced Security: You can apply Azure’s security management and threat protection capabilities to your SQL Server instances, no matter where they reside. This includes advanced threat detection using Microsoft Defender, vulnerability assessments, certificate rotation, and access controls.
• Compliance and Governance: Azure Policy can be applied to SQL Servers managed through Azure Arc, helping ensure compliance with external regulations and internal policies through automated checks.
• Business Continuity: Azure Arc enables you to configure automated backups to local storage, perform point-in-time restores, view Always On failover cluster instances, and view Always On availability groups.
• Migration Readiness: The Azure SQL readiness assessment evaluates the readiness of SQL Server migrations to Azure SQL (Azure SQL Managed Instance, SQL Server on Azure VM, Azure SQL Database).
• SQL Server Assessment: The best practices assessment provides a method to evaluate the configuration of SQL Server. Once enabled, an assessment scans the SQL Server instance and databases to provide recommendations.

How it works

Setting up Azure Arc for SQL Server involves installing the Azure Connected Machine Agent on your physical or virtual server first. This agent communicates with Azure and brings the SQL Server under Azure management. From here, you can perform operations like monitoring, setting up alerts, implementing backup solutions, and more from within the Azure Portal. 

In conclusion

Azure Arc-enabled SQL Server simplifies management, enhances security, and ensures compliance across all your SQL Server instances, regardless of their location. By extending Azure’s management capabilities to your on-premises and multi-cloud environments, Azure Arc helps you harness the power of the cloud wherever your servers may be.

Additional Resources:

• Azure Policy
• SQL Server enabled by Azure Arc
• Azure Connected Machine Agent Prerequisites
• YouTube – Azure Arc-enabled SQL Server Experience

Want to work with The SERO Group?

Are you interested in simplifying the management of your SQL Servers? Schedule a no-obligation call with us to learn more!

The post Azure Arc-Enabled SQL Server: Centralized Management for Hybrid Environments appeared first on The SERO Group.