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.

Top 10 SQL Server Health Check Issues—and Why They Matter

1. Windows Power Plan Set Incorrectly

SQL Server can be resource-intensive—and yet, many servers are configured to run on the “Balanced” power plan instead of “High Performance.” This can limit CPU availability and throttle performance, especially under load. It’s a simple setting, but one that can have an outsized impact. Read more about checking the power plan setting.

2. SQL Server Can’t Use All Processors

SQL Server 2016 Standard Edition and later supports the lesser of 4 sockets or 24 cores. The key word there is “lesser.” Let’s look at an example.

Let’s say that you’ve licensed SQL Server Standard Edition for 16 cores. But those cores are presented to the VM as 8 sockets, each with 2 cores. Unfortunately, SQL Server Standard will only be able to use 8 cores. Why? Because it can only access cores on 4 sockets. 4 sockets times 2 cores per socket is 8 cores total.

This means that you aren’t leveraging all of the cores that you’ve licensed.

3. Too Few or Too Many TempDB Data Files

Microsoft recommends starting with one TempDB data file per logical processor, up to eight, to reduce contention on allocation structures. However, we find that many environments are configured to use either too few (often just one, leading to PFS, GAM, or SGAM contention) or too many (which can introduce unnecessary overhead and make monitoring more complex).

Misconfigured TempDB can degrade the performance of operations like sorts, joins, temporary tables, and version store activity. Read more about configuring your SQL Server tempdb files.

4. Jobs Without Failure Notifications

SQL Agent jobs that silently fail can be costly accidents waiting to happen. From backups and index maintenance to ETL workflows, you need to know when jobs fail. Yet we routinely find environments with no alerts configured. If no one’s watching, critical failures can go unnoticed for days or weeks.

We’ve received quite a few calls from soon-to-be clients where a restore from a backup is needed, yet none is available because the backup job hadn’t successfully completed in more than 6 months. Or the integrity check jobs failed with errors, but no one noticed.

5. Missing Patches or Updates

Out-of-date SQL Server instances are not only a security risk but also more likely to suffer from performance issues and instability. We often find unpatched servers that haven’t been updated in months—or even years—leaving them vulnerable to known issues with known fixes.

Learn more: Is There an Update for My SQL Server?

6. Missing Maintenance Jobs

SQL Server uses statistics to help determine the most efficient way to execute queries. When statistics are accurate, SQL Server can create effective query plans, leading to better overall performance. Conversely, outdated or inaccurate statistics can result in poor query plans and inefficient query execution.

SQL Server automatically updates statistics by default, which is OK in many cases. However, there are plenty of scenarios where relying solely on automatic updates may not be ideal. In such cases, setting up a scheduled job to manually update statistics can help maintain optimal performance.

Similarly, we find that integrity checks are not scheduled to occur regularly. That can lead to undetected database corruption. To learn more, see 10. Missing DBCC CHECKDB (Integrity Checks).

7. Default Settings That Hurt Performance or Recovery

SQL Server has several settings that can affect performance—MAXDOP, Cost Threshold for Parallelism, max memory, min memory, etc. Prior to SQL Server 2022, these were almost always suboptimal for most workloads. SQL Server 2022 does a better job at defaults, but the settings should be tuned for your workload.

Although there is no “go faster” knob in SQL Server, adjusting these defaults can bring improved performance.

8. Backup Plans That Don’t Support Requirements

One of the most important responsibilities in managing SQL Server is ensuring the integrity and reliability of database backups. SQL Server’s native backups provide powerful tools for protecting your data, especially for databases using the full recovery model. However, combining native SQL Server backups with disk or VM snapshots can cause problems during a restore. So be careful mixing your backup approaches. Read more about these problems.

We also regularly find backups that are saved to the same drive as the database, that don’t support the organization’s Recovery Point Objectives (RPOs), and that haven’t been tested. Learn more about SQL Server backups.

9. Misalignment with RTO/RPO Requirements

Stakeholders might say, “We can’t afford more than 15 minutes of downtime,” but the database configuration tells a different story. In our SQL Server Health Checks, we frequently find gaps between what the business expects (Recovery Time and Recovery Point Objectives) and what the current setup can realistically deliver. That gap needs to be closed.

You have a choice. You can adjust SQL Server to support the stated RTOs and RPOs, or you can realign stakeholder expectations.

10. Missing DBCC CHECKDB (Integrity Checks)

Without database integrity checks, corruption can silently lurk in your database, remaining undetected for weeks, months, or even longer. That’s bad. Backing up a database doesn’t magically get rid of corruption. The corruption is backed up, too. To learn more, see When Was the Last Known Good DBCC CHECKDB Integrity Check?

Stay Ahead with a SQL Server Health Check

If you haven’t reviewed your SQL Server environment recently, now is the time. These common issues don’t announce themselves—they quietly erode performance, recoverability, and reliability until something breaks. Don’t wait for that moment. Schedule a no-obligation discovery call to learn more about our SQL Server Health Check. Take control of your database environment before it controls you!

Dive Deeper: Further Reading and Next Steps

• 📋 Do I Still Need a SQL Server Health Check?
  Learn when and why Health Checks are essential—even if your SQL Server seems to be running fine.
• 🚨 The Impact of SQL Server Downtime (and How to Prevent It)
  Explore the real costs of downtime and what steps you can take to keep your environment resilient.
• 🛠️ Our SQL Server Health Check Services
  See how our structured assessments uncover hidden risks and help you align performance with business needs.
• 🎥 Recorded Webinar: RTO/RPO Considerations for Your SQL Server
  Understand how Recovery Time and Recovery Point Objectives affect your backup and disaster recovery strategy.
• 🔐 Free SQL Server Security Self-Assessment
  Quickly evaluate your environment’s security posture and receive bonus guidance on preventing ransomware attacks.
• 🔎 Public SQL Health Check Priorities (sp_Blitz)
  A community-ranked list of common SQL Server issues, created by Brent Ozar and maintained as part of his open-source tools.

The post SQL Server Health Checks: 10 Issues That Show Up Again and Again 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.

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.

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.

RTO and RPO considerations webinar

In an upcoming webinar and in-person session for the Middle Tennessee Chapter of ISACA, we’ll discuss discuss using VM snapshots as part of your backup strategy. We’ll pose eight important questions you should ask before adopting the snapshot approach.

Here’s the agenda:

How to attend?

The webinar is Tuesday, April 11, 2023, 11:00 AM – 12:30 PM CDT

Interesting in joining us for the webinar? If you’re in the Middle Tennessee area and would like to attend the event in-person, we’d love to have you. Just click here to register. The location is: Vaco Nashville 5501 Virginia Way #Suite 120 Brentwood, TN 37027.

If you would like to attend the webinar presentation, you can register here.

If you’re not able to attend, here’s some additional information that may help. You can also email me and I’ll send the slide deck presentation.

Want to work with The SERO Group?

Backups are good. But it’s the ability to restore that is important.

We help a lot of companies prepare their SQL Server environment so that when a disaster strikes, they’ll be prepared. They know they have good backups. They know they can restore in a timely manner (RTO) and to a point-in-time (RPO) that is important to them.

Want to learn more? We can help. Schedule a call or send us an email. It’s easy and there is no obligation

The post Webinar: Virtual Machine Backups – RTO and RPO Considerations for you SQL Server appeared first on The SERO Group.

The gift of SQLSaturday

If you’ve been around SQL Server very long, you know just how wonderful the SQL Server community is. People around the world regularly and selflessly share what they’ve learned to help someone else. They share online in blog posts and YouTube videos. They answer questions on Microsoft forums, on Twitter, and on SQLServerCentral.com. And they speak at user groups and other meetups.

And for years, SQLSaturdays have played an integral role in the community, providing local venues where SQL professionals could gather together to learn, to share, and to connect.

The SQLSaturday founders, Steve Jones, Brian Knight, and Andy Warren, gifted the brand to PASS years ago. (This is an example of the goodness that is the SQL Community.) When the gift was made, I served on the PASS Board of Directors, and no one could have predicted then what was to happen.

In January 2021, PASS ceased operations after more than 20 years. (See Has PASS Outlived Its Purpose? for some background.) So, SQLSaturdays came to a screeching halt. And the future of SQLSaturdays became uncertain.

Uncertain, that is, until Redgate stepped in.

What’s next for SQLSaturdays

Redgate is widely recognized as a corporate member of the SQLFamily. The company sponsors events, provides speakers, and even hosts community platforms.

Earlier this year, Redgate acquired PASS’ assets, including SQLSaturday. They are donating the SQLSaturday brand to a non-profit foundation.

So it seems fitting that Steve Jones, now member of the Redgate team, has been tasked with launching the non-profit. Creating a board of directors to oversee the non-profit’s operations and management is one of his first priorities. In Rebuilding SQL Saturday–Picking a Board of Directors, Steve shares his thoughts and vision for the future of SQLSaturday.

If you’re interested in helping Steve rebuild SQLSaturday, please consider volunteering. His blog post has the information you’ll need.

Ours is a giving community. And I feel fortunate to be a part of it.

Want to work with The Sero Group?

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

Schedule a call with us to get started.

The post The Future of SQLSaturday appeared first on The SERO Group.

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

Is My SQL Server Out of Support?

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

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

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

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

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

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

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

Well, yes. And no.

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

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

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

Want to work with The Sero Group?

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

Schedule a call with us to get started.

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

To help answer that question, I went to the PASS website to look for its mission statement. I couldn’t find it in the dropdown menus. I searched the site. No results found.

That’s disappointing.

And perhaps it explains why the organization is struggling as it is now.

The Mission of PASS

I served on the PASS Board of Directors from January of 2001 through December of 2007. I poured my heart and soul, not to mention thousands of volunteer hours, into the organization. I served in many capacities, including Executive Vice President of Finance, during some very trying times. In fact, I was in the EVP role when we decided the relationship with the former management company was unsalvageable and we needed to move in a different direction. But that’s another story.

Thinking back, I’m struggling to remember the official Mission Statement we had back then. I’m certain we had one.

But I remember well what my mission was. I know exactly why I served.

I served in appreciation for those who had gone before me in the SQL community, who had given freely of themselves so that I, and many others like me, could benefit from their experiences.

I served to create a place where we could connect with fellow SQL Server professionals and improve our craft.

I served to pay it forward to the up-and-coming SQL professionals who would undoubtedly surpass all I could do. I wanted to do for them what others had done for me.

I was but a small part of much larger effort. My role was tiny compared to those I served along side – both on the board and other volunteers. And that’s not false humility on my part. At times, I really was in over my head. But the team I served with was strong and we carried each other when needed.

Although I don’t want to speak for them, I suspect they served for the same reasons I did.

Connect. Share. Learn.

The reasons that I served those many years ago still exist today. I believe there are seasoned SQL Server veterans who still want to connect with those following in their footsteps. I believe that good data professionals still want to share with other good data professionals to sharpen their skills. And I believe still that our SQLFamily actively wants to help the next generation learn.

Connect. Share. Learn.

I did see that on the PASS website. Connect. Share. Learn.

That’s the closest thing that I could find on the PASS website that could be counted as a Mission Statement. I think those three words encapsulate why SQL professionals from around the globe are PASS members. Imagine, hundreds of thousands of people worldwide with a shared heart for the SQL Server community.

So, if we run with that. PASS has not outlived its usefulness or its purpose.

Are there other places to connect? Other places to share? To learn?

Absolutely. PASS has never had a monopoly on those things. It wouldn’t be healthy for the SQL Community if PASS did. But that doesn’t mean the community isn’t better for the organization’s efforts and presence.

I know I have benefited personally and professionally. The knowledge I’ve gained. The relationships I’ve made. The friendships that I cherish. I’ve certainly benefited from PASS.

An Organization on Life Support

But now, PASS is in dire straits. I don’t believe that’s been officially communicated, but we all know it’s true.

The pandemic has exposed and amplified every weakness in PASS’ operations and structure. From its complete dependence on in-person events for revenue to the way it relies on a for-profit company for senior leadership and staffing, every aspect of PASS that could be a liability has become a massive, potentially devastating death nail for the organization.

That grieves me.

I wish PASS was not in this predicament. I wish decisions had been made differently over the past 10 years. I wish there was a better revenue model. I wish there was a different arrangement with the management company. And, I wish the Board of Directors had a trusted advisor, one with sound business acumen, that could provide unbiased advice.

I don’t mean to cast stones. That’s not the point here.

I’m not second guessing any specific decisions or arrangements. Now is not the time for that. That time will come.

I hope.

But it’s not guaranteed.

Helping PASS

Let’s face it. Without support from the SQL Community that it helped nurture, PASS may not exist in 6 to 12 months.

It may not survive.

If you’ re like me, you don’t want to see that happen. You’d like for PASS to be around next year, and the year after that. Maybe not in its current form. Maybe not without significant changes. But at least still be around.

So, how can we help? How can we give back to an organization that’s benefited our careers and enriched our friendships? A few ways come to mind.

First, register for the PASS Virtual Summit. It’s 100% online so there are no travel costs. It’s reasonably priced, currently 599 USD for the 3-day event and 399 USD for a pre-conference seminar. Or you can opt for the bundle which provides 5 full days of training for 999 USD. That’s 200 USD per day, and you can access the content for 12 months.

Second consider buying a PASS Pro Membership. I know. You get almost nothing for that membership. It was a kneejerk reaction to try to bring in a bit of revenue. That’s OK. Just consider your PASS Pro Membership a vehicle to donate approximately 100 USD to an organization you support in principle.

Third, assuming PASS comes through this, scathed or not, consider running for the Board of Directors. Be the change you’d like to see. Applications are open until 9 October, 2020.

Objections

But wouldn’t giving money to PASS simply enable them to continue making bad decisions, decisions that I disagree with? Wouldn’t the money just go into the pockets of the for-profit the management company, C&C? Isn’t supporting PASS now the same as endorsing every decision they’ve made to this point? Besides, haven’t they lost their way and don’t they treat the SQL Community they claim to love poorly these days?

Those are tough questions, ones I’ve wrestled with myself. This has been a difficult post for me to write because there is an element of truth in each of those questions.

But I can tell you that I believe we are past the point of enabling, past the point of disagreeing on principle.

For PASS to be around to reform, it must first survive. And frankly I’m doubtful it can without substantial help. If we can help it survive, we can change it and make it better.

Has PASS Outlived Its Purpose?

I don’t think PASS has outlived its purpose. I think it’s just as relevant today as when founded twenty-plus years ago.

The question is: will it have a future?

I, for one, hope so.

[Edit – 10/2/2020] After this post was originally published, Chris Yates (@YatesSQL), the current Vice President of Marketing for PASS, reached out to me. The PASS Mission Statement may be found here. It reads: “Empower data professionals who leverage Microsoft technologies to connect, share, and learn through networking, knowledge sharing, and peer-based learning.”

The post Has PASS Outlived Its Purpose? appeared first on The SERO Group.