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.

Why SQL Server Maturity Matters

In banking, SQL Server isn’t just a technology platform—it’s the backbone of customer trust, regulatory compliance, and operational resilience. But many institutions operate in reactive, risk-heavy environments that lead to outages, security gaps, and missed opportunities.

Our webinar introduced the SQL Server Maturity Curve, a framework that helps banks understand where they are today and how to move from risk-prone management to proactive, business-enabling excellence.

What You’ll Learn

The Four Stages of SQL Server Maturity

• Reactive (High Risk): Frequent outages and compliance vulnerabilities.
• Managed (Controlled Risk): Basic monitoring for acceptable performance.
• Optimized (Competitive Edge): Proactive management for reliability and scalability.
• Strategic (Business Enabler): Databases as drivers of growth and innovation.

Financial Impact

• Hidden costs of downtime and data breaches.
• ROI models for investing in maturity.
• Budget planning frameworks that align with long-term goals.

Risk & Compliance

• How database maturity affects FFIEC, GLBA, and other regulatory requirements.
• Governance and audit readiness strategies.
• Building resilient infrastructure to ensure business continuity.

Strategic Roadmap

• Tools to assess your current maturity stage.
• How to prioritize the right next steps.
• Resource allocation strategies to minimize disruption.

Who Should Watch?

This session is tailored for:

• CIOs and IT Executives
• VP of Information Technology
• Directors of Infrastructure
• Database Administrators with strategic influence
• Risk Management and Compliance Officers

Why This Webinar?

This wasn’t a tactical training—it’s a strategic briefing for leaders who want to understand the financial and regulatory impact of their SQL Server maturity. You’ll gain clarity on your institution’s current state and a roadmap to move from risk to advantage. We hope you’ll enjoy this high-value webinar and please reach out to us if you have any questions.

The post Webinar: Where Is Your Bank on the Risk-to-Advantage Spectrum? appeared first on The SERO Group.

However, over time, many SQL Server environments quietly drift out of alignment with security best practices. Configurations age. Backups go untested. Access privileges expand without oversight. Multiple vendors are granted elevated access. And without a clear owner, risks grow quietly until something breaks.

5 SQL Server Security Actions to Take

Here are five simple, high-impact actions you can take to reduce SQL Server risk and strengthen your institution’s security posture:

1. Know What SQL Servers You Actually Have

Untracked or “orphaned” SQL Server instances are more common than you think. Over time, shadow IT, legacy systems, or test environments can go unnoticed. As CIO, make sure you have an up-to-date inventory of all SQL Server instances. Get a comprehensive list, along with who’s responsible for maintaining each one.

2. Review Who Has Access—and Why

Access control is one of your biggest areas of exposure. Application vendors often want elevated permissions, especially during the initial installation. Developers or business analysts may have been granted elevated permissions in the past to troubleshoot a query for an important report. The same is true for data engineers.

To check just how many hands are in the cookie jar, ask your team to provide a list of:

• All logins with sysadmin or elevated privileges
• All databases owned by someone other than sa or another designated account
• Any use of shared or generic SQL accounts

Restrict access to only what users need, and tie access to individual, auditable accounts.

3. Make Sure Backups Are Encrypted and Verified

A backup strategy isn’t just about having copies of your data—it’s about knowing those backups will work when you need them most. Ask your team how often backups are tested and whether they’re encrypted. Encryption ensures that sensitive financial data isn’t exposed if backup files fall into the wrong hands.

Equally important is regular verification using tools like RESTORE VERIFYONLY or full restore tests and integrity checks. A corrupted or incomplete backup doesn’t help you during a crisis.

Confirm there’s a clear retention policy in place that aligns with regulatory and business requirements. Backup success logs should be reviewed, and failed jobs should never go unnoticed. Don’t wait until something breaks to find out your recovery plan has holes.

Ask your team:

• Are backups encrypted to protect sensitive data?
• Are they tested regularly using tools like VERIFYONLY or, better yet, with complete test restores followed by an integrity check?
• What’s the retention policy, and is it enforced?

One bad backup can turn a small incident into a costly disaster.

4. Confirm That Audit Logs Are Running and Secure

Audit logs can be an invaluable tool for spotting suspicious activity and proving compliance. However, since audit logs are helpful only if they’re complete, accessible, and protected, make sure that:

• Auditing is enabled on all production servers.
• Logs are stored securely and encrypted.
• Someone is reviewing logs regularly to flag unusual activity.

5. Assign Clear Ownership for SQL Server Security

Securing your SQL Server is a key component of a multi-layered approach to security. But SQL Server security isn’t a “set it and forget it” project. It needs ongoing attention.

If your team doesn’t have a dedicated DBA, consider bringing in outside help. A trusted SQL Server partner (like The SERO Group) can help you monitor, maintain, and secure your environment without adding headcount.

Final Thoughts

SQL Server often holds your institution’s most sensitive data. These five actions can help improve your data security posture and reduce risk.

If you’re unsure where your SQL Server environment stands, or if your team is simply stretched too thin, we can help.

At The SERO Group, we specialize in helping banks and financial institutions reduce risk, improve reliability, and maintain compliance without the cost of a full-time DBA. Let’s schedule a quick call to talk through your current setup and see where we can support you. Schedule a no-obligation discovery call with us to get started.

The post 5 SQL Server Security Priorities Every Bank CIO Must Address appeared first on The SERO Group.

1. Recovering after a database outage
2. Database migrations

What is a tail-log backup?

Tail-log backups capture transaction log records that haven’t been backed up yet and set the database into a “restoring” state. Think of it as the last transaction log backup taken right before a database is restored, moved, or damaged. Its primary purpose is to capture the “tail” end of the log (any transactions that occurred since the last regular log backup to prevent data loss).

When are tail-log backups important?

Scenario 1: Preventing data loss after a failure

Imagine that you schedule transaction log backups to occur every 15 minutes. At 10:05 AM, the server hosting your database experiences a critical failure, taking the database offline. Your last log backup was at 10:00 AM. This means that transactions that have occurred between 10:00 AM and 10:05 AM would be lost without a tail-log backup.

The tail-log backup bridges this gap, capturing those final crucial log records and allowing you to restore the database to the exact point of failure. Depending on the damage, you may need to add additional options for this backup to succeed. See here for those options.

Scenario 2: Supporting a smooth database migration

If you’re migrating a database to a new instance, tail-log backups can be beneficial as well. Let’s say you have a migration coming up from SQL Server 2016 to a new SQL Server 2022 instance. You’ve pre-staged the database on the new instance by restoring the latest Full and have been applying transaction log backups periodically without recovery throughout the week leading up to migration day. On migration day, you need to ensure the following happens:

1. All transactions are captured up to and right after the maintenance window begins.
2. Ensure the database on the old instance can no longer accept new connections. You don’t want new transactions landing here by accident.
3. Restore the final transaction log backup on the new instance and recover the database.

A tail-log backup can help in this scenario as well. You see, once you perform a tail-log backup, the database you performed it on is placed into the “restoring” state, which doesn’t allow connections. This ensures no future transactions can be written. Just in case a connection string wasn’t updated somewhere during the migration (I’d personally rather the connection fail vs. being able to connect to the database that is no longer in use). Once the migration is complete, including testing and validation, the old database can be dropped.

Let’s take a look at the requirements needed before you can utilize tail-log backups.

Requirements for tail-log backups

To perform a tail-log backup, the following conditions must be met:

Recovery model

The database must be in the FULL or BULK_LOGGED recovery model. Tail-log backups are not possible (or needed) in the SIMPLE recovery model, as the transaction log is automatically truncated.

Prior full backup

At least one full database backup must have been taken previously.

Log file accessibility

The transaction log file (.ldf) must be accessible and largely intact, even if the data files are damaged or the database is offline.

You can determine if your database meets the first two requirements by using a query similar to the one below.

USE MSDB
SELECT distinct
	backupSet.[Database_Name],  
	s.recovery_model_desc AS RecoveryModel,
	backupmediafamily.logical_device_name AS LogicalDeviceName, 
	backupmediafamily.physical_device_name AS PhysicalDeviceName, 
	backupset.expiration_date AS ExpirationDate, 
	backupset.name AS Name, 
	backupset.[description] AS [Description], 
	backupset.user_name AS UserName, 
	backupset.backup_start_date AS StartDate, 
	backupset.backup_finish_date AS EndDate, 
	DATEDIFF(mi, backupset.backup_start_date, backupset.backup_finish_date) AS DurationInMinutes,
	CAST(CASE backupset.type 
	WHEN 'D' THEN 'Database' 
	WHEN 'L' THEN 'Log' 
	WHEN 'I' THEN 'Differential' 
	WHEN 'F' THEN 'File' 
	WHEN 'G' THEN 'Diff File' 
	WHEN 'P' THEN 'Partial' 
	WHEN 'Q' THEN 'Diff Partial' 
	END AS NVARCHAR(128)) AS BackupType, 
	--backupset.compressed_backup_size / 1048576 , 
--	backupset.backup_size / 1048576,
	ISNULL(backupset.compressed_backup_size, backupset.backup_size) / 1048576 as SIZE,
	is_snapshot,
	is_copy_only,
	GetDate() AS DateChecked --, *
FROM msdb.dbo.backupmediafamily AS backupmediafamily
INNER JOIN msdb.dbo.backupset AS backupset ON backupmediafamily.media_set_id = backupset.media_set_id
INNER JOIN master.sys.databases as s ON backupset.database_name = s.name
WHERE     (CONVERT(datetime, backupset.backup_start_date, 102) >= GETDATE() - 1)
AND backupset.server_name = @@servername  --Filters out databases that were restored from other instances.
AND backupSet.[Database_Name] = 'YourDatabaseName'
AND backupset.type = 'D'
--AND backupSet.Type = 'D'
ORDER BY StartDate --DurationInMinutes DESC

How to perform a tail-log backup (high-level)

The command is a variation of the standard BACKUP LOG statement. The key difference often lies in the options used, particularly WITH NORECOVERY or WITH NO_TRUNCATE.

Scenario 1: Database damaged/not starting (log file intact)

In this scenario, you may have lost a drive containing your data files (.mdf). You’re lucky because you’ve been following the old adage of keeping your data files and log files on separate disks so the log file is available.

If the database data files are damaged or missing, the database cannot start normally. You can attempt a tail-log backup using WITH NO_TRUNCATE. This tells SQL Server to back up the log records without trying to access the data files or truncate the inactive portion of the log, which might fail since the database is damaged.

BACKUP LOG ExampleDB
TO DISK = '\\YourBackupShare\Backup\ExampleDB_TailLog_NoTruncate.trn'
WITH NO_TRUNCATE;

Scenario 2: Planned migration

In scenario 2, you’re migrating the database to a new instance and must ensure all transactions are captured. I’ll typically switch the database into SINGLE_USER mode and kill all other connections when doing so.

ALTER DATABASE ExampleDB SET SINGLE_USER WITH ROLLBACK IMMEDIATE

Perform this step once your migration window has started and any applications, scheduled tasks, jobs, etc. have been stopped.

Perform the tail-log backup.

BACKUP LOG ExampleDB
TO DISK = '\\YourBackupShare\Backup\ExampleDB_TailLog.trn'
WITH NORECOVERY;

Here’s what happens when you run this backup.

1. The final log records are backed up to ExampleDB_TailLog.trn.
2. The ExampleDB database is put into the RESTORING state.
3. No further transactions can occur in the original ExampleDB database.
4. You can now proceed to restore any subsequent differential/log backups that you haven’t restored yet and, finally, this tail-log backup (using WITH RECOVERY) on the target server.
5. Once restored and recovered, don’t forget to place ExampleDB into MULTI_USER mode on the target server.

Tail-log backup process checklist

Here’s a quick checklist for performing a planned tail-log backup (like for a migration):

• Verify Recovery Model: Ensure the database is in FULL or BULK_LOGGED mode.
• Check Backup History: Confirm a recent full backup exists. Regular log backups should be running.
• Notify Users: Inform users of the planned downtime. Work with all other teams that depend on the database to determine a sufficient maintenance window for the migration. They’ll need to update connection strings, scheduled jobs, SSIS packages, etc., to point to the new database location.
• Restrict Access: Prevent new connections/transactions just before the backup.
• Execute BACKUP LOG … WITH NORECOVERY: Run the command, specifying a clear path and filename.
• Verify Backup File: Ensure the .trn file was created successfully.
• Confirm Database State: Check that the source database is now in the RESTORING state.
• Proceed with Restore: Use the tail-log backup as the final restore step on the target server or for recovery.
• Set database to MULTI_USER: If you’ve placed the source database in SINGLE_USER mode just prior to performing the tail-log backup, the restored database on the target will be in SINGLE_USER mode as well. To allow connections, be sure to switch it to MULTI_USER.

In conclusion

While often overlooked in basic backup discussions, the tail-log backup is a vital tool in the SQL Server DBA’s toolkit. It provides the critical ability to capture the very last transactions before a database restore or migration, minimizing data loss and ensuring the most up-to-date recovery possible. Understanding when and how to use it is key to robust data protection and seamless database migrations.

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 Why Tail-Log Backups Matter for SQL Server Recovery and Migration appeared first on The SERO Group.

Event details: GBA Operations and Technology Conference

February 26-28, 2025
The DeSoto, Savannah, GA
Want to register? Sign up here.

What You’ll Learn at the Conference

The GBA Operations and Technology Conference isn’t just about networking—it’s a valuable opportunity to gain insights into the latest trends shaping banking technology. With sessions covering cybersecurity best practices, fintech partnerships, vendor risk management, and payments innovation, attendees will walk away with actionable strategies to improve operational efficiency and security.

For financial institutions managing mission-critical data in SQL Server, staying ahead of these trends is crucial. As technology evolves and regulations tighten, banks must ensure their database environments are secure, compliant, and optimized for performance. That’s where The SERO Group comes in—we’ll be there to discuss best practices, answer your questions, and provide expert guidance tailored to your institution’s needs.

Would you like a dedicated time to chat with our team at the event? Contact us today to schedule a quick meeting!

Why visit our booth?

Stop by our booth to enter our raffle, grab a free gift, or chat about how The SERO Group can support your banking technology needs. We help financial institutions keep their SQL Server environments secure, reliable, and efficient—whether you’re tackling security, compliance, or performance challenges.

Can’t make it to the event? Connect with us for a call.

If you won’t be at the event, we’d still love to connect! Schedule a free, no-obligation discovery call to see how we can support your organization in 2025.

The post Visit Us at the Georgia Bankers Association Operations and Technology Conference! appeared first on The SERO Group.

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

Let’s review the requirements and limitations.

Requirements and Limitations

SQL Server Edition and Version:

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

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

Windows Server Failover Clustering (WSFC):

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

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

Network Requirements:

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

Database Requirements:

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

Replica Limitations:

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

Licensing:

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

Permissions and Roles:

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

Endpoint Configuration:

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

Quorum Configuration:

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

Summary of Limitations

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

Conclusion

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

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

Want to work with The SERO Group?

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

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

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

Six Common Business Risks in a SQL Server Estate

Risk 1: Data Breaches

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

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

To fortify your SQL Server defenses:

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

Risk 2: Disaster Recovery

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

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

To improve your disaster recovery readiness:

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

Risk 3: Data Loss and Corruption

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

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

To protect your valuable data:

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

Risk 4: Compliance and Regulatory Issues

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

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

To navigate the complex world of data regulations:

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

Risk 5: Performance Issues

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

To keep your SQL Servers running at top speed:

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

Risk 6: Talent Shortage

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

To address this talent risk internally:

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

Managing Your SQL Server Estate

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

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

Want to work with The SERO Group?

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

The post Reducing Business Risks for a SQL Server Estate appeared first on The SERO Group.

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.

The event will be at the Louisville Marriott East from 8:30 a.m. to 3:15 p.m. If you’re in the area, stop by our table to say hi or just to get some free database-themed socks. Haven’t you always wanted database-themed socks?

Hope to see you there!

Can’t make it to the event, but want to connect? Sign up for our Newsletter or follow us on LinkedIn.

The post Join Us: 8/21 IT Symposium in Louisville 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.