When someone has a question about the SQL Server, it’s always “Go see Tom.”

Tom just gave his two-week notice. He’s retiring to the sandy beaches of Florida to soak in the rays and fish in the blue waters.

You’re happy for Tom. But now what? It’s a bit late to begin thinking about SQL Server succession planning.

The Knowledge That Walks Out the Door

I’ve talked to many bank CIOs who have a “Tom” on their team. He’s no SQL expert, but he’s the in-house SQL go-to guy, and he knows those systems.

And that can be a scary place to be if you’re the CIO responsible for the environment.

Why?

Here’s what typically leaves with an accidental DBA:

• Undocumented configurations. Why is the production server set up that way? Tom knows. Or rather, Tom knew.
• Tribal knowledge about recurring issues. That quirky behavior every third Tuesday? Tom had a workaround. It’s not written down anywhere.
• Recovery procedures. Sure, you have backups. But does anyone else know the exact steps Tom follows when a restore is needed at 2 AM?
• Vendor relationships and escalation paths. Tom knew exactly who to call and what to say to get things fixed quickly.
• Security and access decisions. Why does that service account have those specific permissions? Good question.

Why This Matters More in Highly Regulated Industries

If you’re a community bank, this scenario isn’t just inconvenient; it’s an examiner finding waiting to happen. If you’re in healthcare, regulatory stakes are just as high.

During IT examinations, auditors specifically look for single points of failure in critical systems. If your answer to ‘Who manages your databases?’ is one person’s name, that’s a control weakness. If your answer to ‘What happens if they’re unavailable?’ is ‘We’d figure it out,’ that’s a finding.

In these industries, auditors expect you to have:

• Documented procedures for critical operations.
• Separation of duties for database management.
• Continuity plans that don’t depend on one person.
• Evidence that someone is actually monitoring your databases.

When Tom retires and you can’t answer basic questions about your SQL Server environment, you’ve got a problem. A problem that shows up in your next IT audit. Or worse, a technical issue that you cannot resolve.

The Full-Time DBA Trap

Your first instinct might be to hire a replacement. This time, you’ll hire a real DBA, someone who can also help with network tasks when needed.

Makes sense. Kinda.

However, here’s the reality:

• Really good DBAs are hard to find and are only getting harder to find. SQL Server DBAs work in a specialized niche. They’re not application developers or network administrators. As the number of companies running SQL Server has grown, the supply of experienced DBAs hasn’t kept pace. The talent gap is real.
• You can’t compete for talent. Full-time DBAs with SQL Server expertise command $100K to $150K in most markets. The bigger banks, healthcare companies, and other industries snap them up immediately.
• You don’t need 40 hours per week. Most community banks with 2 to 15 SQL Server instances need expert DBA attention, but not full-time. You’d be paying a full-time salary for a part-time need. Worse, eventually your DBA would get bored and leave.
• Two is one, and one is none. With a single DBA, how do you cover vacation, illness, or parental leave? And when that person leaves in a few years, you’re back to square one. The succession planning problem doesn’t go away. It just resets.

A Better Approach: Building Institutional Knowledge

Instead of replacing one person with another person, forward-thinking institutions are replacing person-dependent processes with documented, repeatable systems.

Here’s what that looks like:

1. Start with a comprehensive assessment. You can’t document what you don’t know. Review your entire SQL Server environment, configurations, maintenance plans, and security posture. Get outside help if needed.
2. Document everything. Create professional documentation that anyone with database knowledge can follow: configuration standards, maintenance procedures, recovery processes, escalation paths, everything.
3. Implement consistent monitoring. Stop depending on someone noticing when things go wrong. Or worse, when your phone rings. Professional monitoring catches issues before they become emergencies.
4. Create a knowledge transfer plan. Whether you’re bringing on a DBA Services team, such as our SEROShield services, or developing internal capability, make sure the knowledge gets captured and shared.
5. Test your procedures. Documentation that sits on a shelf isn’t helpful. Regular testing proves your team can actually execute when needed.

This institutional approach is exactly what managed database services providers deliver.

The Managed Database Services Provider Alternative

More community banks are solving the accidental DBA and succession planning problem by moving to a DBA services model. Instead of one person holding all the knowledge, you get:

• A team of experts who share institutional knowledge
• Documented procedures that survive personnel changes
• Predictable monthly costs instead of salary + benefits
• Professional monitoring and proactive maintenance
• Built-in redundancy and coverage
• Separation of duties that align with auditor expectations
• Examiner-ready documentation

If and when someone on the DBA team moves on, the knowledge stays with the firm. Your bank’s operational continuity doesn’t depend on any single person. In our case, each client has a primary and secondary DBA, along with documentation.

Start Before the Crisis

The accidental DBA model worked fine 15 years ago. But as regulatory expectations have increased and technical complexity has grown, it’s become a business risk you can’t afford.

Don’t wait until Tom is packing his office to figure out what he actually did all day. The time to address succession planning is before Tom gives notice. Once he’s gone, you’re in crisis mode, making rushed decisions under pressure.

Ready to Assess Your Database Succession Risk?

Our SQL Server Health Check documents your current environment, identifies knowledge gaps, and provides a roadmap for building institutional resilience, all before your version of Tom gives notice. Schedule a short, free call with us to discuss your specific situation.

The post The Accidental DBA Retirement Crisis: Is Your Institution Ready? appeared first on The SERO Group.

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.

What are the benefits of enabling Query Store? While there are many technical reasons, here are my top four broad advantages to consider.

1. Free SQL Server monitoring

Your business has already paid for Query Store in the SQL Server licensing. With SQL Server 2016 and later, it is accessible at the database level. This means that for smaller shops that may not have a large enterprise environment, you don’t have to spend large sums of money to get observability from 3rd party software. Query Store’s native capture mechanisms can provide significant insight into your SQL Server’s performance, all without costing you any more money!

2. Capture foundational SQL Server performance indicators

Query Store collects the data already present in your SQL Server, displaying it in easy-to-understand graphs and reports. With Query Store, values for CPU, memory, duration, and more can be viewed based on MAX/AVG/STD Deviation metrics per query. This provides valuable insights into core metrics that shape the performance of your applications. Furthermore, this data allows your company to see not only how specific queries behaved when there was a performance problem but also to trend those queries over time to see shifts in performance.

SQL Server wait statistics are also captured and displayed in Query Store. When a query needs a resource, like CPU, or data read from disk, then a wait type is assigned to the query. These various waits affect query performance in a multitude of ways, and Query Store surfaces those performance-impacting waits for you. For example, the Query Wait Statistics report may show large bar graphs for BUFFER IO and CPU. Queries appearing in both graphs may be suffering from large table scans because of missing indexes.

Additionally, Query Store captures the query plans associated with queries. Think of query plans as the blueprint for how the query will be executed. These plans contain data about the decisions SQL Server is making about your data and how to process it. Some decisions revealed in the query plan can pinpoint performance issues. For example, query plans that regularly contain table scan operators may indicate missing indexes that force SQL Server to scan millions of rows when it only needs to retrieve a few thousand rows.

3. Talk to your vendors with data in hand

COTS vendors need to see hard data when approached with a performance problem. Query Store can provide that data. Without it, you can report a problem, but the software vendor is unlikely to consider making changes.

If you engage a DBA as a Service company, having performance data in hand will go a long way toward building a good relationship with that vendor. They will see your preparedness and be drawn to that. Also, it will allow them to solve your problem faster, and isn’t that what you really want anyway?

4. Allow your applications to take advantage of new performance features

Newer versions of SQL Server have a collection of features known as Intelligent Query Processing (IQP). Features such as memory grant feedback, degree of parallelism feedback, and more are tied into IQP. These features depend on Query Store. Without Query Store running and without using the appropriate database compatibility level, your applications are missing out on performance-enhancing features that make queries execute faster, use fewer resources, or do both at the same time.

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 4 Key Performance Benefits of Enabling Query Store appeared first on The SERO Group.

What if you could retire two aging SQL Server 2016 failover clustered instances, migrate 1,200+ databases to SQL Server 2022, and slash storage spend by 84%—all in the length of a weekend maintenance window?

In this post, I’ll tell you exactly how we did it for a client using AWS.

We had multiple goals for this migration:

• Move to SQL Server 2022 and Windows Server 2022
• Reduce Amazon AWS storage costs
• Minimize the downtime required for the migration

The environment consisted of two SQL Server 2016 Enterprise failover clustered instances hosting over 1,200 production databases. As you may know, mainstream support for SQL Server 2016 ended on July 13, 2021, with extended support ending on July 14, 2026 (which is approaching quickly). This post explains how we successfully migrated this complex environment with less than 3 hours of planned downtime while simultaneously reducing infrastructure costs by transforming their storage architecture and backup strategy.

Key Results:

• 1,200+ databases migrated with minimal business disruption.
• Infrastructure storage costs reduced by 84% (estimated).
• SQL Server platform modernized from 2016 to 2022.

Client Profile

Industry: Education software

Environment:

• Two SQL Server 2016 Enterprise failover clustered instances in Amazon AWS
• FSx file share volumes for database storage
• FSx file share for backups
• Multi-subnet configuration
• 1,200+ production databases ranging from 1GB to 3TB in size
• 24/7 business operations with minimal tolerance for downtime

The Challenge

Business Drivers:

The client approached us with several business requirements:

Cost Reduction: Their existing FSx storage and backup architecture was consuming an unsustainable portion of their IT budget.

Technology Modernization: SQL Server 2016 was approaching the end of extended support, requiring an upgrade path to maintain vendor support and security compliance.

Minimal Disruption: With 1,200+ production databases supporting critical business functions, any migration solution needed to minimize downtime.

Technical Challenges:

The technical landscape presented several significant obstacles:

FSx Storage Cost and Performance

The client’s reliance on Amazon FSx for Windows File Server provided the necessary shared storage functionality for their SQL Server failover clusters, but at a premium price point. The FSx architecture also introduced additional network latency for I/O operations, affecting database performance.

Complex Multi-Subnet Configuration

The existing environment leveraged a multi-subnet configuration, adding complexity to any potential migration solution.

Database Scale and Diversity

With over 1,200 databases that vary dramatically in size, usage patterns, and business criticality, a one-size-fits-all migration approach would be insufficient.

Backup Architecture Limitations

The existing backup strategy relied on additional FSx storage, increasing the storage costs while creating management overhead.

Strict Downtime Constraints

The business could tolerate a maximum of 8 hours of downtime, with a strong preference for staying under 4 hours to minimize impact on operations.

The Solution

After a comprehensive analysis and planning, we designed a phased approach that would transform the client’s database infrastructure while meeting their strict requirements for minimal disruption.

Solution Architecture

We architected a modern SQL Server environment on AWS with the following components:

1. Platform Upgrade:
   • SQL Server 2022 Enterprise Edition
   • Leveraged latest features and extended support lifecycle
2. Storage Transformation:
   • From FSx file shares to Multi-Attached EBS volumes
   • io2 Block Express volumes for critical data files
   • Optimized configuration for SQL Server workloads
3. Backup Modernization:
   • Implement S3-based backup strategy
     • Direct SQL Server native backup to S3
   • Intelligent lifecycle policies for cost-effective long-term retention
   • Elimination of dedicated backup storage infrastructure
4. High Availability Design:
   • SQL Server 2022 FCI
   • Modern monitoring integration

Implementation Approach

We divided the implementation into distinct phases to manage risk and ensure successful outcomes.

Phase 1: Development Environment Migration

We began with the client’s development environment to validate our approach and identify potential issues. We worked with the client’s internal system admins to complete the EC2 instance and Windows Server Failover Cluster builds. This allowed us to focus mainly on the SQL Server FCI components:

1. Infrastructure Provisioning:
   • Deployed new EC2 instances optimized for SQL Server 2022
   • Configured multi-attached EBS volumes
   • Established networking and security configurations
2. Initial Testing:
   • Validated storage performance
   • Confirmed failover functionality and timing
   • Verified backup and restore operations to S3
3. Migration Dry Run:
   • Executed migration process on a subset of development databases
   • Measured migration times
   • Refined automation scripts based on observations

Phase 2: Production Environment Preparation

With lessons from the development migration incorporated, we prepared for the production migration:

1. Pre-Migration Activities:
   • Comprehensive database inventory and dependency mapping (i.e., agent jobs, applications, etc.)
     • Planning, communication, and task tracking were crucial to the overall success of the migration.
   • Database health checks to identify potential migration blockers
     • Including utilizing Microsoft’s Data Migration Assistant to ensure database compatibility
   • Implementation of enhanced monitoring
2. Automation Development:
   • Custom PowerShell script creation for orchestrating the migration
   • Integration with DBATOOLS for database backup and restore operations
3. Infrastructure Deployment:
   • Production SQL Server 2022 cluster provisioning
   • Multi-attached storage configuration and testing
   • S3 bucket preparation with appropriate security and lifecycle policies
   • Tested access to the current backup location from the new SQL Server 2022 instances (permissions and network access)

Phase 3: Production Migration Execution

The production migration followed our carefully orchestrated plan:

1. Pre-Stage Initial Data:
   • Performed initial data copy without taking systems offline
   • Utilized a combination of native Full, Differential, and Log backups
   • Leveraged the rebuilt PowerShell script to perform the initial full restore and differential restore
   • Restored log backups every 30 minutes
   • Scheduled restores via the SQL Server Agent on the new SQL Server 2022 FCIs
   • Established baseline synchronization to minimize final transfer time.
2. Migration Window Execution:
   • Implemented application maintenance mode at the start of the maintenance window, blocking access
   • Executed the final data synchronization using our custom migration script
     • Tail-log backup was used to capture all transactions and place the database on the SQL Server 2016 instances into “recovering” status
       • This accomplished two important goals:
         • Capture all transactions that have occurred since the last transaction log backup
         • Place the database into a “recovering” state so that new connections were not allowed in the old environment
   • Performed database restores on the new SQL Server 2022 instances using all transaction log backups, including the final tail-log backup
     • Databases were then recovered and placed into a multi-user read-write state
   • Raised the database compatibility level to 160
   • Changed the database owner
   • Validated each database post-migration
   • Initiated post-migration full backups
3. Cutover:
   • Updated connection strings and DNS entries
   • Performed final validation testing
   • Opened systems for production use

The Technology

Multi-Attached Storage Architecture

The shift from FSX to multi-attached EBS volumes represented one of the most significant technical innovations in this project. We configured the volumes with performance characteristics matched to their specific workloads:

• Data volumes: 3,000 IOPS
• Log volumes: 3,000 IOPs
• TempDB volumes: Amazon EC2 instance store volume (local to each EC2 instance)

This approach delivered both performance improvements and significant cost savings compared to the FSx solution.

Custom Migration Automation

The scale of this migration—over 1,200 databases—demanded sophisticated automation. We developed a custom PowerShell script that utilized multiple commandlets from the DBATools module.

DBATools Integration

While our custom script orchestrated the overall migration process, we leveraged the power of DBATools—an open-source PowerShell module for SQL Server management—for many of the core database operations. This combination of custom automation with proven community tools provided the perfect balance of flexibility and reliability.

Key DBATools functions employed included:

• Get-DBABackupHistory to retrieve the latest backup information for each database.
• Restore-DbaDatabase for restoring the initial full, differential, and all t-log backups.

The Results

The migration was completed successfully with impressive metrics:

Cost Reduction

• 84% reduction in monthly storage costs

Business Impact

• Minimal disruption: Total downtime of only 2 hours and 55 minutes, well under the 8-hour target
• Extended support lifecycle: Movement to SQL Server 2022 provides support through 2032
• Performance headroom for growth: New infrastructure accommodates projected 55% database growth

Migration Metrics

• Total databases migrated: 1,235

Key Lessons Learned

Throughout this project, we gained valuable insights that would benefit any organization undertaking a similar database migration:

1. Thorough database inventory is critical
   • Understanding dependencies between databases was crucial
   • Early identification of current database sizes allowed for proper allocation of storage to support the migration.
2. Storage strategy has an outsized impact
   • Moving to multi-attached EBS volumes delivered both cost and performance benefits
   • SQL Server 2022 introduced the ability to backup directly to S3, delivering significant storage savings vs. FSx
3. Automation is non-negotiable at scale
   • Manual migration for 1,200+ databases not possible within time constraints
   • Investment in custom automation paid dividends in reliability and speed
4. Pre-staging reduces risk
   • Copying the bulk of data before the migration window dramatically reduced the final migration time
   • Delta synchronization proved highly efficient using t-log backups
5. Multi-phase approach validates methodology
   • Starting with the development environment allowed refinement of techniques
   • Lessons learned in initial phases improved production migration execution

Conclusion

This post demonstrates how even the most challenging database migrations can be accomplished with minimal downtime when approached with careful planning, appropriate technology choices, and custom automation. By transforming the storage architecture and leveraging modern AWS services, we not only successfully migrated 1,200+ SQL Server databases but also delivered substantial cost savings and performance improvements.

For organizations facing similar challenges with aging SQL Server environments, this project provides a proven blueprint for success—combining the best of cloud infrastructure, modern database platforms, and sophisticated automation techniques.

The client now enjoys a modern, cost-effective SQL Server environment that provides room for growth while reducing ongoing operational costs. Most importantly, they achieved this transformation with minimal disruption to their business operations—proving that with the right approach, large-scale database migrations don’t have to be painful or disruptive.

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 We Migrated 1,200+ SQL Server Databases in Under 3 Hours (While Cutting Storage Costs by 84%) appeared first on The SERO Group.

In today’s always-on business environment, database downtime isn’t just an inconvenience—it’s a direct hit to revenue, productivity, and customer trust. Despite this, many organizations delay modernization efforts due to perceived costs and complexity. However, the real question is: can your business afford not to modernize?

Read on to learn more about the financial and operational costs of database downtime as well as a clear framework to build a compelling business case for modernization.

Five Hidden Costs of Database Downtime

When a database goes down, the impact ripples across the entire organization. Some of the most significant costs include:

1. Lost Revenue

For companies reliant on digital transactions, every second of downtime translates to lost sales. Amazon, for example, once reported that a one-second slowdown could cost $1.6 billion annually. While your business might not operate at Amazon’s scale, even brief outages can lead to significant revenue loss.

2. Lost Productivity

A database failure means employees can’t access critical systems, resulting in downtime that halts operations. Whether it’s finance teams unable to process invoices or customer service reps locked out of support portals, downtime disrupts workflows and reduces overall efficiency.

3. Damaged Customer Trust and Brand Reputation

Today’s consumers expect 24/7 availability. If your database fails, customers may turn to competitors instead of waiting for service to resume. Worse yet, frequent outages can erode long-term trust, leading to customer churn and negative brand perception.

4. Regulatory and Compliance Risks

Many industries require strict uptime guarantees due to compliance regulations. Unexpected outages can result in hefty fines, legal liabilities, or audit failures, increasing both financial and reputational risks.

5. Emergency Recovery Costs

Beyond lost revenue, the costs of emergency IT interventions can be staggering. Organizations often pay a premium for after-hours IT support, expedited cloud migrations, and patchwork fixes—all of which can add up quickly.

How to Make the Case for Modernization in Five Steps

Given these risks, database modernization isn’t just a technical upgrade—it’s a strategic investment. Here’s how to build a strong business case for modernization:

1. Quantify Downtime Costs

Start by making a rough calculation of your organization’s downtime costs using this formula:

[(revenue per hour/operating hours) × downtime hours] + recovery costs + employee productivity loss + damage to customer trust + damage to reputation = total downtime cost

Even conservative estimates often reveal that the cost of inaction outweighs the cost of modernization.

2. Highlight Competitive Advantages

Modernized databases offer improved scalability, enhanced security, and better performance. Faster access to real-time data can unlock competitive advantages, from personalized customer experiences to data-driven decision-making.

3. Emphasize Security and Compliance Benefits

Outdated databases are vulnerable to cyber threats and compliance failures. Upgrading to a modern system strengthens security, reduces breach risks, and ensures regulatory compliance.

4. Include Cloud and Automation Savings

Modern cloud-based databases offer built-in redundancy, automated backups, and real-time monitoring, reducing the likelihood of costly outages. They also eliminate maintenance burdens, freeing up IT resources for more strategic initiatives.

5. Showcase ROI and Long-Term Savings

While modernization has upfront costs, the long-term benefits—fewer outages, lower maintenance costs, and better performance—lead to substantial ROI. By framing modernization as an investment rather than an expense, leadership is more likely to approve the initiative.

Take the Next Step

Database downtime is a preventable risk that businesses can no longer afford to ignore. By making a clear, data-driven case for modernization, IT leaders can secure executive buy-in and drive long-term resilience for their organizations.

Are you ready to evaluate your database infrastructure? Schedule a free, no-obligation discovery call to learn how modernization can future-proof your business.

The post The True Costs of Database Downtime—and Why Modernization Can’t Wait appeared first on The SERO Group.

To start 2025 with confidence, focus on these ten critical questions auditors are certain to ask. Addressing them now not only ensures compliance but also strengthens the overall health of your SQL Server environment.

Need a refresher before diving in? Explore our introduction to planning for audit-ready SQL Servers for helpful background information.

10 Must-Answer Questions for DBAs to Ace IT Audits in 2025

1. What is your backup and recovery strategy?
   Auditors expect proof that your data is protected and recoverable in case of failure or breach. Demonstrate recent, tested backups and maintain a clear, documented recovery plan.
2. How do you manage access controls and permissions?
   Auditors need to see a detailed, up-to-date record of who has access to what. Regularly review and limit unnecessary permissions to strengthen security and ensure compliance.
3. Are there unpatched vulnerabilities in your SQL Server environment?
   Outdated versions and unpatched servers raise immediate concerns. Consistently apply updates to minimize security risks and meet compliance requirements.
4. How do you monitor database performance and availability?
   Be ready to provide performance logs and show how your monitoring tools prevent downtime and maintain operational stability.
5. What disaster recovery plans are in place?
   Auditors look beyond backups for a comprehensive disaster recovery (DR) plan. This should include failover strategies and incident response protocols to cover all scenarios.
6. Can you demonstrate data encryption practices?
   Encryption is essential. Show proof that sensitive data is encrypted both at rest and in transit, with documentation to back up these measures.
7. How do you track and document changes to the database?
   Maintain thorough change management logs. These should capture schema changes, patches, and updates, reinforcing accountability and transparency.
8. Are user activities within the database logged and monitored?
   Audit logs tracking user activity are vital. They help identify suspicious behavior and demonstrate proactive risk management.
9. What is your incident response plan?
   Prepare to explain how your team reports, manages, and resolves incidents. A clear, well-documented incident response plan reflects readiness and resilience.
10. How do you handle data privacy and compliance regulations?
    As regulations like GDPR and CCPA evolve, auditors want evidence that your SQL Server environment aligns with current data privacy laws. Stay ahead by keeping documentation updated and accessible.

Want expert help to prepare for your next audit?

The SERO Group specializes in helping organizations achieve audit readiness. Schedule your free, no-obligation discovery call today to take the next step toward IT confidence in 2025.

The post 10 Essential IT Audit Questions: The DBA’s Guide to SQL Server Compliance and Security in 2025 appeared first on The SERO Group.

Does that sound familiar? I hope not. It’s not a good place to be. Scheduled downtime is always better than unscheduled downtime.

So, what can you do about it?

What is preventative maintenance?

So, what do we mean by “preventative maintenance?”

Broadly speaking, preventative maintenance can be thought of as a set of tasks that are performed regularly to keep that SQL Server and the databases it hosts healthy, secure, and reliable. These tasks help optimize performance, ensure data integrity, and prevent potential issues before they become disruptive events.

Examples of scheduled preventative maintenance

Scheduled preventative maintenance frequently includes these tasks.

• Index maintenance: Rebuilding or reorganizing indexes to reduce fragmentation and improve query performance
  • Example: Optimize index maintenance to improve query performance and reduce resource consumption
• Statistics update: Updating database statistics to ensure the query optimizer makes efficient execution plans based on current data distribution
  • Example: Update Statistics
• Backup (and restore tests): Performing regular database backups to safeguard data against potential corruption or accidental deletion
  • Examples: Backup Overview and Restore and Recovery Overview
• Database integrity checks: Running checks to identify any data inconsistencies or corruption
  • Example: DBCC CheckDB
• Monitoring and alerting: Setting up monitoring tools to identify potential problems early through performance metrics and alerts
  • Example: Alerts

Of course, this is just a starting point. It’s the base set that we use for our clients. Depending on the workload and scenario for each SQL Server, we adjust what we schedule and how often we schedule it.

What can we do about the “too important SQL Server?”

So, if you have a “friend” who works in an environment where a SQL Server is just too important to schedule preventative maintenance tasks, what can you tell them? What are their options?

Do nothing

You could do nothing and leave things as they are. But, as you can probably guess, that’s not a good option. It will likely get worse—either things will continue to deteriorate, or they may suffer a disruptive event.

Get a SQL Health Check

Is the SQL Server configured to provide a good foundation for performance and reliability? Often, the answer is no. If that’s the case and your configuration settings are set incorrectly for the workload, a SQL Health Check can identify those issues before they become bigger problems. 

Perform a baseline

Review the metrics. Is the system I/O bound? Does it have enough memory? Would it benefit from additional cores?

Tune performance

Review the most resource-intensive queries and look for ways to improve them. Can you add a non-clustered covering index? Is there significant blocking occurring? Would some procedures benefit from being rewritten?

Off-load reporting workloads

Transactional systems are typically normalized for performance. Unfortunately, however, that often means that complex reports significantly hinder performance. Moving the reporting workload to a separate system could improve performance.

Implement high availability

If the applications are too important for preventative maintenance, perhaps HA will help. Implementing a failover cluster instance or even an availability group could allow for patching and other changes to be made with minimal disruption.

Separate workloads

If this is a multi-use SQL Server, perhaps some databases may be moved to another SQL Server.

Something to keep in mind

Your friend may not have all of those options available to them. For example, tuning performance for a purchased application often requires close coordination with the vendor. However, trying to do something to maintain your SQL Server is better than doing nothing. 

Additional information and assistance

Want to learn more? Here are some other posts that may be helpful.

• Why Is My SQL Server Slow? 14 Common Reasons
• SQL Server Maintenance: 10 Things to Keep Your SQL Server Running Well
• 10 Unseen Things Successful DBAs Do

If you have an important SQL Server that’s not being maintained, we can help. Schedule a no-obligation discovery call and let’s talk.

The post Schedule Preventative Maintenance for SQL Server: Key Steps to Protect Your Database appeared first on The SERO Group.

Just to be clear, storing sensitive information as a clear text string is a really, really, really bad idea.

Not encrypting information in a database can cause serious problems. As just one example, if the database is compromised, all user passwords could be exposed. Data breaches are becoming more and more common. If the authorities come knocking on your door, you need to be able to show them that you at least made a concerned effort to protect that data.

Encrypting text that will need to be decrypted

In some cases, you may be able to store your sensitive data as strongly encrypted text that will never need to be decrypted. For example, hashing a password used for your application login and then just comparing the hashed password for the login instead of the actual password. But, in most cases, being able to decrypt the sensitive data is going to be necessary.

In these cases,  ENCRYPTBYPASSPHRASE (available in SQL Server 2008 and up) offers one of the simplest ways for you to encrypt sensitive information in a way that can also be decrypted (by using DECRYPTBYPASSPHRASE). At its very basic, ENCRYPTBYPASSPHRASE requires two mandatory arguments: a passphrase used to generate the encryption key and the text to be encrypted.  Notice that it specifies a passphrase, not password. There is an important difference between these two.

A passphrase vs. a password

As described in the ENCRYPTBYPASSPHRASE documentation: 

A passphrase is a password that includes spaces. The advantage of using a passphrase is that it is easier to remember a meaningful phrase or sentence than to remember a comparably long string of characters.

Many people don’t realize that you can use a space as a legitimate special character in most passwords. By doing this, you can generate a much more secure password sentence (or phrase) instead of a single word. An example of a passphrase may be something like “I forgot my password!”

Just to be clear, a space is not required in your passphrase for ENCRYPTBYPASSPHRASE. If you wanted to use a GUID for your passphrase or a random string such as “Zgt9$Ex%*unZO8Z},” that is perfectly acceptable.

Using ENCRYPTBYPASSPHRASE

For the examples in this post, I am going to use the encryption passphrase “This is my Passphrase!”, and the text to be encrypted is “ABC123”.

The basic syntax is:
ENCRYPTBYPASSPHRASE(‘encryption passphrase’, ‘text to encrypt’)

There are other arguments that can be used with ENCRYPTBYPASSPHRASE (see MSDN Doc), but for this simple example we are just using the two mandatory arguments.

To view the encrypted value of the text “ABC123”, you would use this script:

SELECT ENCRYPTBYPASSPHRASE(N'This is my Passphrase!', N'ABC123');

That SELECT statement will return a VARBINARY value such as: 0x0100000093EEC20B790EF208B1FB631F0AB3028E3A8C196643C4BD578528A0DFAE7AB45B

It is important to note that the VARBINARY value returned from ENCRYPTBYPASSPHRASE is nondeterministic, meaning that even with the same input it will not generate the same output every time.  So you can run the exact same SELECT statement multiple times and get a different result each time.

Thankfully, this output has no bearing on using the DECRYPTBYPASSPHRASE function. As long as you have the correct passphrase, DECRYPTBYPASSPHRASE will successfully decrypt any of those VARBINARY results to their original value.

Storing an encrypted value in a table

Now that we know how to encrypt a sensitive text string, let’s take a look at how to store that encrypted value in a table.  Since the value returned from ENCRYPTBYPASSPHRASE is a VARBINARY data type, that is how we want to store it since this is also the data type required by DECRYPTBYPASSPHRASE.

The first thing we need to do is determine the size of our encrypted column in our table. The VARBINARY values returned by ENCRYPTBYPASSPHRASE can vary in size, with maximum size of 8,000 bytes. The size of the returned value is going to depend on the size of the actual text being encrypted. You can use the DATALENGTH function to help figure that out. If you have a way to control the maximum allowed length of the sensitive text value you want to encrypt, use that size for your table column, but try not to use VARBINARY(8000) if you don’t have to.

Here is a simple example of storing our encrypted text in the [Password] column of a table:

CREATE TABLE dbo.Users ([UserName] VARCHAR(50), [Password] VARBINARY(50))
 
INSERT INTO dbo.Users ([UserName], [Password])
VALUES ('Charlie Brown', ENCRYPTBYPASSPHRASE(N'This is my Passphrase!', N'ABC123'))
 
SELECT [UserName], [Password]
FROM dbo.Users

Using DECRYPTBYPASSPHRASE

Now that we have our sensitive text encrypted, we need to be able to decrypt it as well.  This is easily done by using the DECRYPTBYPASSPHRASE function with the same passphrase we encrypted our text string with. However, DECRYPTBYPASSPHRASE also returns a VARBINARY value, which we will have to convert to a string.  This can be done by adding a CONVERT function to our SELECT statement.

SELECT [UserName], CONVERT(NVARCHAR, DECRYPTBYPASSPHRASE(N'This is my Passphrase!', [Password]))
FROM dbo.Users

Now you should see your decrypted value returned correctly in clear text. ENCRYPTBYPASSPHRASE offers a quick and easy way for you to encrypt text in SQL Server and can be useful for encrypting sensitive information if you need to be able to decrypt it later. 

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 Encrypt Sensitive Text in SQL Server with ENCRYPTBYPASSPHRASE appeared first on The SERO Group.

I should also mention that the results of these queries will only go back to the last SQL Server start time. Anything that occurred before then won’t be available.

Logins Vs. Users

First, let’s take a look at the difference between “logins” and “users” in SQL Server, as people sometimes get them confused, or think they’re the same thing. A “login” allows access to a SQL Server instance. A “user” allows access to a specific database on that instance. Usually, a user is tied to a login, although you can have a user that is not tied to a login (known as a loginless user).

When was the last time a login was used?

--list of logins and last time each logged in
SELECT [Login] = login_name 
	,[Last Login Time] = MAX(login_time)
FROM sys.dm_exec_sessions
GROUP BY [login_name];

Which logins have logged in within the last X hours?

--all logins in the last 4 hours
SELECT [Login] = login_name
	,[Last Login Time] = login_time
	,[Host] = HOST_NAME
	,[Program] = PROGRAM_NAME
	,[Client Interface] =  client_interface_name
	,[Database] = DB_NAME(database_id)
FROM sys.dm_exec_sessions
WHERE [login_time] > DATEADD(HH,-4,getdate())--modify date as needed
ORDER BY [login_time] desc

How many times has each login logged in within the last X hours?

--login counts for the last 4 hours
SELECT [Login] = login_name
	,[Last Login Time] = MAX(login_time)
	,[Number Of Logins] = COUNT(*)
FROM sys.dm_exec_sessions
WHERE [login_time] > DATEADD(HH,-4,getdate())--modify date as needed
GROUP BY [login_name]
ORDER BY [Login] desc

Which logins have Sysadmin access?

--check for logins with sysadmin access
SELECT [Login] = name
	,[Login Type] = type_desc
	,[Disabled] = is_disabled
FROM     master.sys.server_principals 
WHERE    IS_SRVROLEMEMBER ('sysadmin',name) = 1
ORDER BY [Login]

Checking A User’s Access To Databases

This query will return a list of databases that the specified user has access to. This will work for SQL Server Logins as well as Active Directory Logins. This is done by specifying EXECUTE AS LOGIN just before the query. (also be sure to specify REVERT after the query runs)

It should be noted that this query only shows you what databases the user can access, not the permissions the user has on the databases.

EXECUTE AS LOGIN = 'YourDomain\User.Name' --Change This
	SELECT [name]
	FROM MASTER.sys.databases
	WHERE HAS_DBACCESS([name]) = 1
REVERT

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 Useful Scripts For SQL Server Logins and Permissions appeared first on The SERO Group.

So, why is this considered a bad practice?

It’s inefficient.

The “sp_” prefix is used by SQL Server to designate internal system procedures. So, whenever SQL Server sees “sp_” at the beginning of a stored procedure, it looks in the master database first.

CREATE PROCEDURE (Transact-SQL) – SQL Server, 2023, learn.microsoft.com

So, using the “sp_” prefix for a stored procedure is like giving SQL Server bad directions and then wondering what’s taking it so long.

It causes conflicts with system procedures with the same name.

If you accidentally named your stored procedure the same thing as one of those system procedures, SQL Server will execute the system procedure instead of your database procedure.

It means taking the long way around every time.

This what SQL Server is triggered to do every time an “sp_” stored procedure is called:

1. Stop processing in your database.
2. Jump over to the master database.
3. Scan every stored procedure.
4. Come back to your database.
5. Find and execute the procedure you were looking for in the first place.

All of those steps take time. Multiplying that time by the number of stored procedures, then multiplying that by the number of times those procedures are called per day, you can end up with significantly slower performance.

The simple solution

When you avoid the “sp_” prefix, you ensure that SQL Server immediately looks in your database. This makes the procedure faster to find and execute. What’s not to like about that?

One exception: utility procedures

If you’re creating a utility procedure, like sp_whoisactive, that you intend to run everywhere, then using the “sp_” prefix can be useful. Do so sparingly and only when creating a procedure in the master database that you want to have accessible from all other databases.

Want to work with us?

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

The post Quick Tips for Faster SQL Servers: Don’t Name Your Stored Procedures Using The “sp_” Prefix appeared first on The SERO Group.