Announcing the Release of SSMS 22.7.0 - and many previews!
Today we shipped SQL Server Management Studio (SSMS) 22.7.0, and this is one of the bigger releases we've had in a while. The headline items are we’ve introduced a “What’s New” page, SQL formatting (preview), schema compare (preview), Agent Mode for GitHub Copilot in SSMS (preview), and a new execution context for GitHub Copilot. There's also continued investment in Database DevOps and a solid round of bug fixes. Thank you, as always, for taking the time to log issues and upvote what matters. It really does shape what we work on. Let's dig in. Introducing the "What's New" page When you update to 22.7, you’ll see something new: an in-product “What’s New” page that showcases our top features and fixes in the release. It’s a short, abbreviated summary that gives you the chance to quickly skim and understand the highlights of the release. This page automatically appears the first time you open SSMS after updating. Once you close it, it won’t show again the next time you launch SSMS. You’ll only see it again after a future update. If, at any time, you want to see the What’s New page again, you can go to Help > What’s New. Let us know what you think about it – I’ve created a suggestion ticket on Developer Community for folks to leave thoughts. If you encounter a bug with the page itself (something not loading, broken links, etc.) please open a separate Developer Community ticket so our engineering team can triage and investigate it properly. T-SQL formatting in the query editor (preview) If you’re one of the hundreds of SSMS users who has been asking (and patiently waiting) for T-SQL formatting capabilities, I am very happy to report that as of today, this feature is available in preview! This functionality has been built into the core SSMS experience, no workloads or components required. To get started, simply right-click any query editor window and find the Format SQL menu item. The formatter supports a range of options that let you control how your SQL is styled. You can configure keyword casing (uppercase, lowercase, or PascalCase), indentation size, semicolons after statements, and how clauses like FROM, WHERE, and JOIN are broken across lines. Alignment options let you line up clause bodies, column definitions, and SET clause items for a clean, readable layout. Multi-line list options control whether SELECT columns, WHERE predicates, and INSERT values each get their own line. We're continuing to expand the available options, and we encourage you to file feedback if there's a formatting behavior you'd like to see. The SQL formatting functionality in SSMS is built on top of the open-source .NET library for T-SQL parsing, ScriptDOM, also known as SqlScriptDOM. Get to know ScriptDOM in its GitHub repository, where the GitHub issues system can be used to discuss ideas and challenges encountered. Pull requests are welcome! Learn more in the SQL formatter documentation. GitHub Copilot in SSMS Agent mode (preview) GitHub Copilot capabilities have expanded significantly in this release with the introduction of Agent mode. Currently in preview, Agent mode allows you to offload complex, multi-step tasks to Copilot. Where Ask mode helps with quick answers, Agent mode helps you solve problems. Agent mode acts, with your approval, reducing your operational effort. Agent mode is available in the mode picker, in the bottom left of the chat window. In the bottom right of the chat window you’ll find options for tools and skills, and you can use the plus icon to add a specific skill (listed under MCP resources) to the chat as context. Agent mode doesn’t inherit connection context from Object Explorer or the active editor, so it’s recommended to specify your database and/or server in the prompt to reduce ambiguity (e.g., the WideWorldImporters database on the SQL 2025 instance is slow, can you help me figure out what's going on?). With your prompt submitted, you remain in control through tool approvals – giving you the opportunity to review and approve (or reject) any queries executed on your behalf. Further, Agent mode operates as READ_ONLY by default to give you the opportunity to get comfortable with how it works in a database environment. Use Agent mode for investigation, analysis, and assessment, and extend its capabilities by creating your own skills. Check out the documentation and our YouTube playlist for examples and scenarios. Copilot execution context Perhaps more important than making Agent mode available, we introduced the ability to configure the execution context for GitHub Copilot - a feature that has been requested every session and in feedback items. We’ll have more details in tomorrow’s blog post, but for those of you that want to restrict what GitHub Copilot can access, this is your solution. The execution context is configured per database, using the CONSTITUTION.md for the database (as an extended property). Within the frontmatter (a metadata block at the top of a Markdown file) of the CONSTITUTION.md, you specify a database user or SQL login as the agentExecuteAsUser. When GitHub Copilot connects to your database, it reads the CONSTITUTION.md for the database, and if it sees the agentExecuteAsUser specified, all queries are executed under the context of the user or login. This configuration applies to both Ask and Agent mode. Database DevOps (preview) updates, including schema compare (preview) Earlier this year we introduced SQL projects in SSMS via the Database DevOps workload. This release, we’re expanding the available capabilities with graphical schema compare (preview) and SQLCMD variable support in the publish dialog. I won’t say too much more, because Drew has an entire blog post dedicated to these features, but I hope these features supercharge your experience in SSMS and give you back some time. Other improvements and bug fixes The full list is in the release notes, but a few that I expect folks will be happy to see: Azure SQL Managed Instance — Added support for creating a new login using your Windows domain account directly from SSMS. Small change, frequently requested, and it removes a workflow that previously required dropping into scripts. Command Line — Fixed an issue where the Connect to Server dialog still appeared even when both -S and -d were provided alongside a filename. See Unable to skip the Connect dialog, even with -S and -d parameters, if you pass as filename. Connection — Selecting Activity Monitor (Ctrl+Alt+A) from the toolbar no longer opens the legacy connection dialog when no Object Explorer connection is active. See If there is no open connection on object explorer and I click Activity Monitor (Ctrl+alt+A) from toolbar, it opens the old connect to server dialog. Object Explorer — Pressing F2 on a schema-qualified object and then clicking away no longer warns about unsaved name changes when nothing actually changed. See Object Explorer rename on Schema Database objects – warns on out of focus after F2 with no name change. Results Grid — The Save Results As dialog no longer filters All files as *.txt. See Results Grid "Save Results As" dialog filters "All files" as *.txt. Settings — Debug-only settings errors are no longer displayed in the Output window. See SQL Server Management Studio 22 versions later than 22.2.1. Query Hint Recommendation Tool — The Do not consider combinations of hints label is now theme-compliant. In summary As always, thank you for using SSMS, for the feedback items, the upvotes, the comments, and the patience as we keep iterating. With Agent mode, the new execution context for Copilot, schema compare, and SQL formatting all landing in the same release, there's a lot to try in 22.7 - please tell us how it goes.mssql-python 1.9.0: Row-friendly Bulk Copy, smarter NULL parameters, and a more portable wheel
We just shipped mssql-python 1.9.0, the official Microsoft SQL driver for Python. This release focuses on day-to-day ergonomics for data loading, a long-standing correctness gap around NULL parameter binding, and a build change that makes the published wheels work on clean macOS and Linux machines. pip install --upgrade mssql-python Highlights Bulk Copy now accepts Row objects (and lists) Bulk Copy previously required tuples. In 1.9.0 you can hand it Row objects straight from a SELECT, or plain lists, and the driver converts each row to a tuple internally before passing data to the Rust backend. rows = source_cursor.execute( "SELECT id, display_name, created_at FROM users" ).fetchall() target_cursor.bulkcopy("staging.users", rows) The common "fetch from one table, bulk-insert into another" pattern just works, with no manual row reshaping and no type errors on the boundary. NULL parameters now resolve to the right SQL type When you bound None to a parameter, the driver used to fall back to SQL_VARCHAR. That was fine for character columns and quietly wrong for everything else, especially VARBINARY and all-NULL columns where the server had no other type signal to lean on. 1.9.0 adds a thread-safe per-statement cache for SQLDescribeParam results, so NULL parameters resolve to the parameter's actual declared type. The cache is invalidated when a new statement is prepared, which also cuts redundant round-trips to the server during repeated executions of the same prepared statement. simdutf is now statically linked into the extension The published wheels (especially the macOS universal2 wheel) previously dynamically linked simdutf against a path that only existed on the CI build machine. On a clean install, import mssql_python could fail with missing-symbol or dlopen errors. The build no longer calls find_package(simdutf). FetchContent is used unconditionally, simdutf is built as a static library, and its symbols are embedded directly in the extension. There is nothing for end users to do; reinstall the wheel and the import works on a clean machine. Thanks to @edgarrmondragon for the contribution. Bug fixes worth calling out executemany with large Decimal values. Batch inserts of Decimal values larger than the SQL Server MONEY range raised an SQL_C_NUMERIC type-mismatch at runtime. executemany now binds DECIMAL / NUMERIC parameters as SQL_C_CHAR and sizes the column to fit the longest string representation, so large-decimal batches (including NULLs and multi-column inserts) succeed. Exception pickle round-trips. ConnectionStringParseError and the DB-API exception subclasses now implement __reduce__, so driver exceptions survive pickle / copy.deepcopy with every attribute intact. multiprocessing, distributed task queues, and anything that ships exceptions across process boundaries no longer lose context on the way through. nextset() and PRINT output. nextset() now collects diagnostic messages whenever SQL returns SQL_SUCCESS_WITH_INFO. Previously, PRINT output from secondary result sets in multi-statement batches and stored procedures was silently dropped after the first set. executemany data-at-execution path with Row objects. The DAE fallback used by large columns such as varchar(max) only recognized primitive types, so passing Row objects in that path failed. The fallback now converts Row to a tuple before mapping types. Fetch methods now type-check under ty. Catalog and metadata result-set handling no longer monkey-patches fetchone, fetchmany, and fetchall as instance attributes. A cached _column_map is built instead, so the fetch APIs stay proper class methods and static type checkers like ty stop tripping on cursor fetch calls. Upgrading For most users, pip install --upgrade mssql-python is all you need. If you had any workarounds for NULL parameter typing (manually setting inputsizes, casting in SQL, or sending sentinel values), you can drop it. If you were converting fetched rows to tuples before handing them to bulkcopy or executemany, that's no longer required either. Thanks Thanks to everyone who filed issues, sent repros, and reviewed PRs in this cycle. The NULL parameter fix, the Row handling in Bulk Copy and executemany, and the simdutf linking change all came directly from user-reported scenarios, and the simdutf change was a community contribution from @edgarrmondragon. Full changelog and PR list: microsoft/mssql-python releases.Announcing SQL Server Management Studio 22.6.0
It's been a minute since I've posted here - but rest assured that the SSMS team has been working hard to bring you lots of exciting features and fixes! Today we shipped SQL Server Management Studio (SSMS) 22.6.0, and it's a really nice mix of work: continued investment in Database DevOps (preview), a security-related update to how we authenticate against Azure Storage, a handful of quality-of-life improvements in the editor and tools, and a solid roundup of bug fixes (many of which came directly from items filed on the feedback site!). Thank you, as always, for taking the time to log issues and upvote what matters to you. It really does shape what we work on. Let's dig into what's new! Database DevOps (preview) SQL projects support in SSMS continues to evolve with incremental changes, including an adjustment to the Solution Explorer icon for solutions to match the '.slnx' icon found in Visual Studio. This release also introduces the ability to create a SQL project directly from an existing database. Once a project is created, you can check it into source control and work with it in VS Code or vice versa, enabling a flexible experience across different tools and teams. If a database changes over time, you can use the SQL projects "Import From Database..." menu item in Solution explorer to update your project with the latest schema changes. This allows you to keep your project in sync with the database and maintain a single source of truth for your database schema. Once your database definition is captured in a SQL project, CI/CD pipelines and the SqlPackage CLI can be used to automate deployments and manage the quality of database changes. Documentation is available at aka.ms/sqlprojects-docs, and our public roadmap at aka.ms/sqlprojects-roadmap shows what's coming next. Unified Settings We're continuing to migrate settings from the classic Tools > Options dialog into the new Unified Settings experience. In 22.6, Transact-SQL IntelliSense and Keyboard Query Shortcuts are now available in Unified Settings. If you haven't opened Unified Settings yet, give it a try. The search and filtering experience is significantly better than what we had before, and we'd love your feedback as we keep moving more settings over. I also recorded a Data Exposed episode with Anna Hoffman where I talk about a few ways you can customize your SSMS 22 installation to work for you. Storage Account access - now with Entra authentication This one is worth calling out for anyone who connects to Azure Storage accounts from SSMS. The Storage Browser, DACPAC import/export, and Merge Audit File dialogs have all been updated to support Microsoft Entra-based authentication instead of shared key access. Shared keys have been a long-standing concern from a security perspective, and moving these flows to Entra brings them in line with modern authentication guidance. Quality-of-life improvements A few smaller changes that I think are worth highlighting: Registered Servers: Multi-server connection attempts can now be cancelled. If you've ever kicked off a connection to a large group and immediately realized you picked the wrong one, you no longer have to wait it out. There's now a Cancel button. Results Grid: Hovering over a column header in the results grid now shows the column's data type in the tooltip. Small, but handy, this comes straight from a feedback item. Query Designer: In the Show Criteria pane, there's a new right-click option to Change Column Width for an individual column. GitHub Copilot in SSMS On the GitHub Copilot side, this release is primarily about stability and cleanup rather than new capabilities. We fixed a crash that some of you ran into when using Copilot Edit, and we removed the GPT-5* models from Ask mode. They may return down the road; for now, the remaining models should give you a more consistent experience. If you missed Erin's blog post about 22.5.2, code completions are still disabled by default. You can opt back in under Tools > Options > Text Editor > Inline Suggestions. Fixes worth highlighting The full list is in the release notes, but a few that I expect folks will be happy to see: Connection Dialog: Passwords are no longer displayed in plain text when viewing a connection string. This came in as a feedback item for SQL Lakehouse connections specifically, but the fix applies broadly. Object Explorer: Fixed the "object reference not set to an instance of an object" error that some of you saw when deleting multiple items at once and addressed an issue where newly created objects sometimes didn't appear in Object Explorer until you disconnected and reconnected. Migration Landing Page: the Migration page we introduced in 22.5 now supports dark theme! Query Editor: Editor tooltips are no longer unreadable when you're using a dark theme with a light editor appearance. A reminder on rolling back We say this from time to time, but it's worth repeating: if a release ever creates trouble for you, you can roll back to a previous version of SSMS 22 from the Visual Studio Installer. From the SSMS 22 entry, select More > Rollback to previous version. And if you're ever in a spot where you need a specific older build, the Release History page lists them. Summary You can find the complete release notes here. As always, thank you for using SSMS, for the feedback items, the upvotes, the comments, and the patience as we keep iterating. Please keep them coming, the feedback site is the best way to influence what shows up in the next release.mssql-python 1.6: Unblocking Your Threads
The last two mssql-python releases shipped big features: Bulk Copy in 1.4 for high-throughput data loading, and Apache Arrow in 1.5 for zero-copy analytics. Version 1.6 is about what happens next: you take those features into production, scale up your thread pool, and find out where the driver was quietly holding you back. This release unblocks your threads during connection setup, fixes crashes and incorrect results in common cursor patterns, and hardens security for passwords with special characters and log file paths. pip install --upgrade mssql-python Your threads can run while connections are opening If you're running mssql-python behind Flask, FastAPI, Django, or any WSGI/ASGI server with thread-based workers, this one matters. Opening a database connection is slow. There's DNS resolution, a TCP handshake, TLS negotiation, and SQL Server authentication. In previous versions, every other Python thread in your process was frozen while that happened, because the driver held the Global Interpreter Lock (GIL) during the entire operation. One thread opening a connection meant no other thread could serve requests, process data, or do anything at all. Version 1.6 releases the GIL during connect and disconnect. Your other threads keep running while the network round-trip completes. If you have a multi-threaded web server handling concurrent requests, this removes a serialization bottleneck you may not have realized you had. The connection pool was also reworked to stay safe under this change. Previously, the pool held an internal lock while calling connect, which would have created a deadlock now that connect releases the GIL. The pool now reserves a slot first, connects outside the lock, and rolls back the reservation if the connection fails. Decimal parameters work with setinputsizes If you use cursor.setinputsizes() to declare parameter types for performance-sensitive batch inserts, you may have hit a crash when specifying SQL_DECIMAL or SQL_NUMERIC. This is fixed. Decimal values now bind correctly whether you're using execute() or executemany(): cursor.setinputsizes([ (mssql_python.SQL_WVARCHAR, 100, 0), (mssql_python.SQL_INTEGER, 0, 0), (mssql_python.SQL_DECIMAL, 18, 2), ]) cursor.executemany( "INSERT INTO Products (Name, CategoryID, Price) VALUES (?, ?, ?)", [ ("Widget", 1, Decimal("19.99")), ("Gadget", 2, Decimal("29.99")), ], ) Iterating catalog results with fetchone() If you've used cursor.tables(), cursor.columns(), or other catalog methods and tried to walk the results with fetchone(), you may have gotten incorrect data. Row tracking was broken for catalog result sets. This now works the way you'd expect: cursor.tables(tableType="TABLE") while True: row = cursor.fetchone() if row is None: break print(row.table_name) This also applies to primaryKeys(), foreignKeys(), statistics(), procedures(), and getTypeInfo(). Reusing prepared statements without reset If you call cursor.execute() with reset_cursor=False to reuse a prepared statement across calls, this no longer raises an "Invalid cursor state" error. Passwords with special characters stay masked in logs If your SQL Server password contains semicolons, braces, or other ODBC-special characters (e.g., PWD={Top;Secret}), previous versions could accidentally leak part of it in sanitized log output. The password masking logic has been rewritten to correctly handle all ODBC connection string formats. If the connection string can't be parsed at all, the entire string is now redacted rather than partially exposed. The logging system also now rejects log file paths that attempt directory traversal, preventing setup_logging(log_file_path="../../somewhere/else.log") from writing outside the intended directory. Better type checker support for executemany If your type checker flagged executemany() when you passed dictionaries as parameter rows, that warning is gone. The type annotations now correctly accept Mapping types, matching the DB API 2.0 spec for named parameters. Get started pip install --upgrade mssql-python For questions or issues, file them on GitHub or email mssql-python@microsoft.com.mssql-django 1.7.1: Microsoft Fabric Support and Migration Fixes
We just shipped mssql-django 1.7.1 with two fixes that matter if you're running Django on Microsoft Fabric or using descending indexes in your migrations. JSONField Now Works on Microsoft Fabric SQL Database in Microsoft Fabric reports itself as EngineEdition 12, which our backend didn't previously recognize. The result: JSONField queries, hash functions, collation introspection, and test teardown all broke on Fabric because the backend couldn't correctly identify the server capabilities. In 1.7.1, we added full detection for Fabric's engine edition. The backend now correctly treats Fabric as an Azure SQL-class database, which means JSONField, MD5, SHA1, SHA224, SHA256, SHA384, SHA512, and collation-dependent lookups all work as expected. We also combined the ProductVersion and EngineEdition queries into a single round trip, so connection setup is faster too. If you've been waiting to use Django with SQL Database in Microsoft Fabric, this is the release that makes it work. Descending Index Migrations No Longer Crash If you had a model with a descending index and ran an AlterField migration on one of the indexed columns, Django would crash with FieldDoesNotExist. The issue was in how our schema editor looked up fields during index reconstruction: it was reading index.fields (which only contains field names for simple indexes) instead of index.fields_orders (which correctly handles the (field_name, order) tuples that descending indexes use). This was a one-line fix, but it blocked anyone whose migrations touched fields covered by descending indexes. If you've been working around this, upgrade and your migrations will run cleanly. SQL Server 2025 in CI We upgraded our Windows CI pipeline to run against SQL Server 2025, so every commit is now tested against the latest version. Combined with our existing coverage across SQL Server 2016-2022, Azure SQL Database, Azure SQL Managed Instance, and now Microsoft Fabric, you can be confident the backend works across the full Microsoft data platform. Upgrade pip install --upgrade mssql-django Full compatibility: Component Supported Django 3.2, 4.0, 4.1, 4.2, 5.0, 5.1, 5.2, 6.0 Python 3.8 - 3.14 (Django 6.0 requires 3.12+) SQL Server 2016, 2017, 2019, 2022, 2025 Azure SQL Database, Managed Instance, SQL Database in Fabric ODBC Driver Microsoft ODBC Driver 17 or 18 Questions, bugs, or contributions? Find us on GitHub. mssql-django is open source under the BSD license. Built and maintained by Microsoft.Introducing Pacemaker HA Agent v2 for SQL Server on Linux (In Preview)
We are excited to introduce the next generation of high availability (HA) Agent for SQL Server on Linux: Pacemaker HA Agent v2. This release is a major step forward, designed to reduce planned and unplanned failover times, compared to the previous agent, based on internal engineering improvements. Why Pacemaker Is Required for SQL Server HA on Linux For users new to Linux, it’s important to understand how high availability works on this platform. On Windows Server, Always On availability groups use an underlying Windows Server Failover Cluster (WSFC) to: Monitor node health Detect failures Orchestrate automatic failovers Always On availability groups on Linux rely on an external cluster orchestrator for health monitoring and failover coordination, with Pacemaker HA Agent being one of the cluster orchestrators, responsible for: Monitoring node and application health Coordinating failover decisions Helping mitigate split‑brain scenarios through improved write‑lease evaluation Managing resources such as availability groups and listeners The Pacemaker HA Agent is the integration layer that allows Pacemaker to understand SQL Server health and manage availability groups safely. Evolution of the SQL Server Pacemaker HA Agent With SQL Server 2025 CU3 and later, Pacemaker HA Agent v2 is available in preview for Red Hat Enterprise Linux and Ubuntu through the mssql-server-ha package. Pacemaker HA agent v2 uses a service‑based architecture. The agent runs as a dedicated system service named mssql-pcsag, which is responsible for handling SQL Server–specific high availability operations and communication with Pacemaker. You can manage mssql-pcsag service by using standard system service controls to start, restart, status and stop this service by using the operating system's service manager (for example, systemctl). # Start the mssql-pcsag service sudo systemctl start mssql-pcsag # Restart the mssql-pcsag service sudo systemctl restart mssql-pcsag # Check the status of the mssql-pcsag service sudo systemctl status mssql-pcsag # Stop the mssql-pcsag service sudo systemctl stop mssql-pcsag Limitations of Pacemaker HA Agent v1 While the original agent enabled SQL Server HA on Linux, customers running production workloads encountered several challenges: Failover delays of 30 seconds to 2 minutes during planned or unplanned events Limited health detection, missing conditions such as I/O stalls and memory pressure Rigid failover behavior, unlike the flexible policies available on Windows (WSFC) Incomplete write‑lease handling, requiring custom logic No support for TLS1.3 for Pacemaker and SQL Server communications How Pacemaker HA Agent v2 Addresses These Gaps Pacemaker HA Agent v2 is a ground‑up improvement, designed to improve the reliability characteristics of SQL Server HA on Linux. 1. Faster & Smarter Failover Decisions The new agent introduces a service‑based health monitoring architecture, moving beyond basic polling. This allows SQL Server to report detailed diagnostic signals - improving detection speed and helping reduce failover delays in supported configurations. 2. Flexible Automatic Failover Policies inspired by the WSFC health model Pacemaker HA Agent v2 supports failure‑condition levels (1–5) and health‑check timeout model aligned with those available in Always On availability groups on Windows. This provides: Fine‑grained control over failover sensitivity, allowing administrators to tune when failover should occur. Improved detection of internal SQL Server conditions, such as memory pressure, internal deadlocks, orphaned spinlocks, and other engine‑level failures. Failover decisions are now driven by detailed diagnostics from sp_server_diagnostics, enabling faster and more accurate response to unhealthy states and providing enhanced resiliency capabilities for SQL Server AG on Linux. You can configure the failure condition level and health check timeout using the following commands: -- Setting failure condition level ALTER AVAILABILITY GROUP pacemakerag SET (FAILURE_CONDITION_LEVEL = 2); -- Setting health check timeout ALTER AVAILABILITY GROUP pacemakerag SET (HEALTH_CHECK_TIMEOUT = 60000); After applying the configuration, validate the setting using the sys.availability_groups DMV: 3. Robust Write Lease Validity Handling To prevent split‑brain scenarios, SQL Server on Linux uses an external write‑lease mechanism. In v1, lease information was not fully integrated into failover decisions. In v2, the agent actively evaluates the write-lease validity, before initiating transitions. This supports controlled role changes and improved data consistency behavior during failover events, depending on cluster configuration. 4. TLS 1.3 Support Pacemaker HA agent v2 includes design updates to support TLS 1.3–based communication for health checks and failover operations, when TLS 1.3 is enabled. Supported Versions & Distributions Pacemaker HA Agent v2 supports: SQL Server 2025 CU3 or later RHEL 9 or later Ubuntu 22.04 or higher. Preview upgrade & migration guidance for non-production environments New or existing non-prod deployments running SQL Server 2025 (17.x) can migrate from Pacemaker HA Agent v1 to v2 using following approach: Drop the existing AG resource sudo pcs resource delete <NameForAGResource> This temporarily pauses AG synchronization but does not delete the availability group (AG). After the resource is recreated, Pacemaker resumes management and AG synchronization automatically. Create a new AG resource using the v2 agent (ocf:mssql:agv2) sudo pcs resource create <NameForAGResource> ocf:mssql:agv2 ag_name=<AGName> meta failure-timeout=30s promotable notify=true Validate cluster health sudo pcs status Resume normal operations References Create and Configure an Availability Group for SQL Server on Linux - SQL Server | Microsoft Learn Thank You, Engineering: David Liao Attinder Pal Singh
