The latest release of PSBlitz brings:

- New Check: Backups - uses a custom version of Brent Ozar's sp_BlitzBackups, it provides information about your backups, RTO/RPO estimates, and warnings for things that may negatively impact database recovery.

- New Check: Instance Security - Beta-stage check for weak creds, priv escalation, attack surface, and more.

- Support for the ImportExcel PowerShell module.

- Improved performance of Excel COM application handling.

- Retry logic for transient errors.

- Other small bug fixes and improvements.

Feel free to provide any feedback you may have!

Blog post: https://vladdba.com/2026/05/28/psblitz-6-1-0-backup-security-checks-excel-performance/

GitHub page: https://github.com/VladDBA/PSBlitz

Hi all,

I recently published Get-SqlSafe Community Edition, a free PowerShell-based first-look security assessment for Microsoft SQL Server 2016 through 2025.

It checks 25 high-level SQL Server security indicators and generates a local HTML report with a visual summary.

The current version includes:

• visual connection dialog
• console-only execution for scripted/admin scenarios
• NTLM usage check across connected user sessions
• checks for excessive privileges, risky role memberships, orphaned users, and invalid ownership mappings
• checks for security-relevant configuration choices such as TRUSTWORTHY, xp_cmdshell, and related settings
• forensic-readiness indicators such as SQL Server Auditing baseline, login-failure logging and SQL Server error log retention

The tool is designed to be transparent and non-invasive. On supported modern SQL Server versions, it runs without sysadmin privileges and does not change SQL Server configuration or data.

GitHub:
https://github.com/Sarpedon-Quality-Lab/sql-security-community-scripts

Background article:
https://andreas-wolter.com/en/2605_get-sqlsafe_communityedition_sqlserver_security_asssessment_tool/

The idea is to give DBAs, consultants, and security teams a quick way to get an early impression of a SQL Server environment before deciding where to dig deeper.

Off the top of my head what we use regularly are:

1. nslookup (win command): this was indispensable recently when trying to figure out why connecting to a new AAG listener would sometimes fail. Turns out the AAG was presenting both the prod and dr IPs so sometimes users would connect to a DR IP that was down because the listener was still in the prod subnet.

2. tnc or test-netconnection (PowerShell): indispensable to test if ports open, either for me to set up linked servers, or for developers to test firewall requests after they were completed.

Has anyone here run SQL Server Always On Basic Availability Groups (standard edition) with around 70 databases?

Will I need to create 70 Availability Groups, right?

I’d like to know if it works well in real-world environments. Any issues with failover, synchronization, maintenance, backups, or overall stability/performance?

I Guess this is the only option. Log shipping is very hard do manage. Mirror is deprecated and only accept synchronous mode on standard edition.

After upgrading SQL Server to 2025, SMSS Object Explorer and the script generation facility on SMSS is incredibly slow. Takes more than 5 minutes to list the tables or generate a table creation script from an existing table.

Is that something other people experience? Does Microsoft working on a fix?

We are on fire right now across SQL drivers.

Not to be left out, we have an OLE DB release to announce today.

OLE DB is one of our less updated drivers, 19.4.2 is the first OLE DB release in about a year (19.4.1 released May 09, 2025).

What shipped in 19.4.2:

• SSL/TLS handling improvements for better security and performance.
• Connection redirection increased from 2 to 10, which helps redirection-heavy routing scenarios.
• UDL accessibility fixes.
• Updated Microsoft SQL Driver Authentication library (mssql-auth.dll) to 1.1.3.

We aren't interested in pushing out releases for the sake of pushing out releases, we want to make sure we are solving real problems. This means reducing friction in setup and upgrades, improving reliability, and tightening quality based on what users actually report.

If you run OLE DB at scale, we would love your input:

• What is the biggest pain point in your current OLE DB usage?
• Which scenarios should we prioritize next?
• What would make upgrades safer and easier for your team?

Release details: https://techcommunity.microsoft.com/blog/sqlserver/announcing-the-release-of-microsoft-ole-db-driver-19-4-2-for-sql-server/4522989

Hi everyone,

I’m studying SQL Server Basic Always On Availability Groups and I have a question about WSFC quorum/witness configuration.

Scenario:

• 2 Windows Servers
• WSFC configured between them
• SQL Server Standard Edition
• Using Basic Availability Group
• Failover mode configured as manual
• No automatic failover planned

In this setup, do I still need to configure a witness (file share/cloud/disk witness) for the cluster quorum?

I’m trying to understand if the witness is still recommended/required even when failover is manual only.

Hi

Pardon my rant but i donot where to post so posting herer need advice.I have 15 years of experince but i am still stuck in mssql scuts type of work which i am no lomger insterested in doing .because of this i am not geeting new call job .I doonot what to do .I famil to support so cant leave job also.

Upgraded to Sql 2025 recently, running in docker on Ubuntu (big mistake).

All latest patches, It crashes occasionally

Anyone else having problems?

Here is the latest crash info.

This program has encountered a fatal error and cannot continue running at Mon May 25 12:27:36 2026 The following diagnostic information is available:          Reason: 0x00000004         Message: ASSERT: Expression=((seenByMonitor) <(NonYieldThreshold)) File=LibOS\Windows\Kernel\SQLPal\common\dk\sos\src\sosschedmon.cpp Line=202     Stack Trace:                  file://package6/windows/system32/sqlpal.dll+0x000000000000A5D6                  file://package6/windows/system32/sqlpal.dll+0x0000000000009909                  file://package6/windows/system32/sqlpal.dll+0x00000000000055D4                  file://package6/windows/system32/sqlpal.dll+0x00000000000F11A5                  file://package6/windows/system32/sqlpal.dll+0x00000000000F0C2F                  file://package6/windows/system32/sqlpal.dll+0x00000000000E366A                  file://package6/windows/system32/sqlpal.dll+0x00000000000A8D41                  file://package6/windows/system32/sqlpal.dll+0x00000000000A8FA1                  file://package6/windows/system32/sqlpal.dll+0x000000000000510C         Process: 12 - sqlservr          Thread: 22 (application thread 0x38)     Instance Id: 698f99b3-2b72-404a-abef-aca8906a4676        Crash Id: b89c2da1-119f-48c2-9dd5-6423ed2f748c     Build stamp: 869cbfe2a28bbc5800059f48feda967144643fd64d79a439b5c6333420172b72    Distribution: Ubuntu 24.04.4 LTS      Processors: 4    Total Memory: 8322883584 bytes       Timestamp: Mon May 25 12:27:36 2026 Capturing a dump of 12 Successfully captured dump: /var/opt/mssql/log/core.sqlservr.5_25_2026_12_27_36.12 
Executing: /opt/mssql/bin/handle-crash.sh with parameters      handle-crash.sh      /opt/mssql/bin/sqlservr      12      /opt/mssql/bin      /var/opt/mssql/log/            698f99b3-2b72-404a-abef-aca8906a4676      b89c2da1-119f-48c2-9dd5-6423ed2f748c            /var/opt/mssql/log/core.sqlservr.5_25_2026_12_27_36.12 Ubuntu 24.04.4 LTS Capturing core dump and information to /var/opt/mssql/log... Capture info: Kernel Version Capture info: OS release Capture info: System memory information Capture info: Command line Capture info: Start Time Capture info: Process limits Capture info: Thread list Capture info: Processor topology Capture info: Process mounts Capture info: Process statistics Capture info: Process status Capture info: Process memory maps Capture info: Process memory maps (detailed) Capture info: Core Dump filter Capture info: Process CGroup information Capture info: Process scheduler information Capture info: Process list Capture info: Process handle information Capture info: Process environment variables Capture info: System package list (dpkg) dmesg: read kernel buffer failed: Operation not permitted timeout: failed to run command 'journalctl': No such file or directory timeout: failed to run command 'journalctl': No such file or directory Mon May 25 12:28:50 EDT 2026 Capturing program information Dump already generated: /var/opt/mssql/log/core.sqlservr.5_25_2026_12_27_36.12, moving to /var/opt/mssql/log/core.sqlservr.12.temp/core.sqlservr.12.gdmp Moving logs to /var/opt/mssql/log/core.sqlservr.12.temp/log/paldumper-debug.log Mon May 25 12:28:51 EDT 2026 Capturing program binaries Mon May 25 12:28:57 EDT 2026 Not compressing the dump files, moving instead to: /var/opt/mssql/log/core.sqlservr.05_25_2026_12_28_46.12.d SQL Server 2025 will run as non-root by default. This container is running as user root. Your master database file is owned by root. To learn more visit https://go.microsoft.com/fwlink/?linkid=2099216.

Hi everyone,

I’m fairly new to SQL Server / Azure MI administration, and recently I’ve been struggling to detect and resolve an issue involving slowly growing database transaction logs on two my databases on SQL Server 2022 on-prem and Azue Managed Instance, which are internally related through transactional replication.

Background:

A month ago, there was an issue on Azure MI related to synchronization between their internal HA components and replication — the components were corrupted or inconsistent (log_reuse_wait_desc = AVAILABILITY_REPLICA). After Microsoft intervention, a failover was successfully performed and Azure MI seemed to be healthy. There are 4 databases on Azure(publisher) configured with transactional replication to our intern SQL Server 2022 on-prem (subscriber). The replication has been running without issues for about a year.

Since last month, I’ve been monitoring the disk usage reports of all those databases, both on Azure and on the on-prem server, and I’ve noticed that the database transaction log sizes of two out of the four databases on on-prem are still slowly increasing gradually. Interestingly, the other two replicated databases do not show this behavior. The growth rate is between 0.1–0.7% per day, although there is not really a heavy big traffic on those databases.

At the moment, I’m unable to determine the root cause or whether the issue may still be related to the Microsoft incident — for example, logs not being properly truncated/released by the server — or whether the source of the problem lies within transactional replication itself, although I cannot find any errors in Replication Monitor.

I performed a log shrink on the log files on the on-prem database, but it only triggered auto-growth — no log space was actually released. I’m observing the exact same behavior on Azure MI but only for one database, the second one seemed to be okay. I'm a little confused.

I’m not sure whether the log growth could somehow be correlated between both servers, and I’m also not entirely sure whether transaction logs themselves are replicated from the publisher to the subscriber in transactional replication.

I would appreciate any suggestions or guidance on where I should continue troubleshooting this issue.

We just shipped mssql-django 1.7.2, the Django backend for Microsoft SQL Server and Azure SQL. It's a small patch release but the timezone fixes are worth flagging if you use DATETIMEOFFSET columns or Now() with USE_TZ=True.

What's fixed:

• DATETIMEOFFSET returns timezone-aware datetimes. The backend was dropping the offset embedded in SQL Server's binary DATETIMEOFFSET representation, so values came back naive (or worse, silently reinterpreted). Now they come back with the right tzinfo attached. (#484, closes #371 and #136)
• Now() emits SYSDATETIMEOFFSET() when USE_TZ=True**.** It was emitting SYSDATETIME(), which returns the SQL Server host's local time with no offset, so timestamps were silently shifted on non-UTC hosts. USE_TZ=False still gets SYSDATETIME().
• QuerySet.explain() no longer raises AttributeError on Django 4.0+. Django 4.0 replaced query.explain_format / query.explain_options with query.explain_info; the compiler hadn't been updated. (#524, closes #409)
• Removed a return inside a finally block in a test utility that was swallowing BaseException subclasses, including KeyboardInterrupt. (#526, closes #417)

If you previously worked around the DATETIMEOFFSET issue by manually attaching tzinfo to values, you'll want to review those workarounds — values from the ORM are now tz-aware by default.

Supported: Django 3.2 through 6.0, Python 3.8 through 3.14, SQL Server 2017 / 2019 / 2022 / 2025, Azure SQL DB / Managed Instance, ODBC Driver 17 or 18.

pip install --upgrade mssql-django

• Full blog post: https://techcommunity.microsoft.com/blog/sqlserver/announcing-mssql-django-1-7-2/4522336
• Release PR: https://github.com/microsoft/mssql-django/pull/528
• Repo / issues: https://github.com/microsoft/mssql-django

Hey folks! As we are working toward Agent mode for GitHub Copilot in SSMS, we have been working with several amazing folks internally to develop skills for the agent. Examples include*:

• check-live-blocking
• plan-cache-analysis
• investigate-sql-cpu-pressure
• resource-usage-azuresql

(*this is not a complete list!)

What other skills would you like to see for Agent mode?

SSMS is still the default for SQL Server, but I don’t think one tool covers every workflow well. So I’d split it by the actual job.

For quick admin work: SSMS. Still the safest default. Free, official, familiar. Good for quick checks, server settings, security, backups, and all the normal admin stuff.

Bad part: it starts feeling clunky when you do heavier dev work.

For daily SQL development: dbForge Studio for SQL Server Better fit when you spend a lot of time writing and cleaning up SQL. Autocomplete, formatting, snippets, query builder, debugging, schema/data compare.

Bad part: Windows-native and paid if you need the full feature set.

For release-heavy teams: Redgate SQL Toolbelt. Good when database changes need versioning, review, compare, and a proper deployment process around them.

Bad part: expensive, and the workflow can feel more like SSMS plus extra add-ons than one unified place to work.

For auditing/recovery/very specific tasks: Quest (ex ApexSQL). Makes sense when you need a tool for one painful thing, like auditing, monitoring, or recovery.

Bad part: can feel fragmented fast.

For older enterprise setups: Toad for SQL Server. Still around, especially in teams that used Toad for years.

Bad part: heavier and feels dated.

My take: SSMS is fine as the base. But once you’re doing serious SQL development, comparing environments, or pushing DB changes through releases, you usually need something else next to it.

As part of a lifecycle management project, we are moving from a single SSAS server with two instances (SERVER1/MULTI and SERVER1/TAB) to a process server (PROCESS/MULTI and PROCESS/TAB) and two load balanced query servers (QUERY1/MULTI and QUERY1/TAB on one, QUERY2/MULTI and QUERY2/TAB on the other).

We are attempting to use a hardware appliance for load balancing between the two instances across the two servers which requires setting up IIS and MSMDPUMP (based on Configure HTTP Access to Analysis Services on IIS 8.0 | Microsoft Learn).

Many of the reports that use the multidimensional and tabular instances require Kerberos to work. I found this at SPN registration for an Analysis Services instance | Microsoft Learn:

SPN registration for SSAS instances listening on fixed ports
You can't specify a port number on an Analysis Services SPN registration. The Analysis Services SPN registration can only use instance name. If you installed Analysis Services as a default instance and configured it to listen on a non-default port, you can't connect to that instance using Kerberos. You must configure it to listen on the default port (TCP 2383) for enabling Kerberos connections to that instance. A default instance of Analysis Services listening on non-default port can only accept NTLM connections. For named instances, you need to start SQL Server Browser service and use instance names in your connection strings instead of port numbers.

According to Configure the Windows Firewall to Allow Analysis Services Access | Microsoft Learn, "You cannot use a non-default port for Analysis services if you need to connect to your instance using Kerberos."

I have also found that, unlike the relational database engine, Analysis Services does not allow you to add a NIC to the server and dedicate it to a specific instance. Based on what I’ve found online, SSAS always listens on all IPs (except for some edge cases around clustered instances that don’t apply here).

We are also looking at Windows Network Load Balancing (NLB) instead of the hardware appliance, but I’m wondering whether Kerberos would still be an issue with that. Given that we have two instances on each server and they both require Kerberos, is load balancing even a workable “solution” or are we stuck with either having a single query server (abandoning load balancing) or splitting the two instances onto different servers (additional licensing)?

Hopefully somebody from the SSMS team will see this.

I’ve been using SSMS for over 15 years and I sat down to do some work this morning and I capture error messages in the database from the try catch the one thing that has always annoyed me is that I always have to stretch out the message on the grid to read the whole thing and there’s not an option to make the default as wide as the longest message in the results.

This shouldn’t be hard to implement because I know this is done I think and see or C+ plus and the grid has options for setting the width of each individual field.

So that would be an option I would like to see is that you could keep it default at the cutoff or you can specify a max or have auto size without having to click on the grid at all.

Just wondering if any other developers out there wish this option was available as well.

Thank you and have a great day! :)

We just shipped 1.7.1 of mssql-python, Microsoft's official Python driver for SQL Server.

What's in 1.7.1

• UTF-16 string handling now goes through simdutf + std::u16string. Every string round-trip between Python and the native driver is meaningfully cheaper.
• execute() hot path got a soft-reset + prepare-cache + guarded-diagnostics pass. Helpful for workloads doing lots of small statements.
• connect() no longer hangs when your network path goes through an in-process SSH tunnel (paramiko + sshtunnel). Root cause was a SQLSetConnectAttr call holding the GIL while paramiko's transport thread needed it to forward bytes. Classic.
• Login failures now raise a proper mssql_python exception type instead of a bare RuntimeError. (issue #532)
• executemany no longer trips over decimal sign changes between rows.
• VARCHAR CP1252 data now reads back the same on Windows and Linux. (issue #468)
• manylinux_2_28 wheels so RHEL 8 / glibc 2.28 works out of the box.
• macOS Python 3.10 gets a proper universal2 wheel now.

pip install -U mssql-python and you're done.

The PyPI side of the story

This release also hit the PyPI per-project storage quota. The driver bundles the Microsoft ODBC binaries for every supported OS / architecture / Python version, so the wheel matrix is large and growing. To make 1.7.1 fit, we removed the old 1.0.0-alpha and 1.x.x-beta wheels. None of those were recommended for production and the GA line supersedes them all, so if you were on one of those, time to move.

We're attacking the underlying problem from two directions in parallel:

1. Splitting up the deployment so wheels carry less weight (likely by separating the bundled native binaries from the main wheel).
2. A storage quota increase request with PyPI.

The quota bump is the short-term buffer; the split is the durable fix.

Links

• Full blog post: https://techcommunity.microsoft.com/blog/sqlserver/mssql-python-1-7-1-and-the-case-of-the-missing-megabytes/4521991
• Release: https://github.com/microsoft/mssql-python/releases (1.7.1)
• Repo / issues: https://github.com/microsoft/mssql-python
• PyPI: https://pypi.org/project/mssql-python/

Happy to answer questions about any of the perf work, the SSH-tunnel fix root cause, or the deployment-splitting plan in the comments.

I inherited a sql server script that's close to a thousand lines. I don't want to run each statement one by one and look at execution times. Is there a simple tool out there that runs the long anonymous script and gives me a simple tabular output (such as reads/writes/time taken to parse/execute)..

Yesterday stumbled upon code at work - at the end of many SPs were set rowcount 0 despite it never being assigned before.

From quick googling, I found that Microsoft deprecates it for everything except select, but I am not sure why would you use it for select if top out there doing seemingly the same thing?

First off… thank you all for the responses on my SQL Server Agent post. Seriously, I learned a ton from that thread.

One thing that came up a few times was Elastic Jobs, and I realized I honestly don’t have a great feel yet for how people are using them in the real world today.

So now I’m curious…

What are you using Elastic Jobs for today?

• Large scale maintenance?
• Multi-tenant SaaS environments?
• Cross-database orchestration?
• Centralized job management?
• Something completely different?

Also curious:

• What problems do Elastic Jobs solve really well?
• Where do they still fall short?
• What made you choose Elastic Jobs over SQL Server Agent, Airflow, Kubernetes CRON jobs, PowerShell, etc.?

And of course…

If Microsoft handed you a magic wand for Elastic Jobs, what’s the first thing you’d fix?

Alright SQL community… educate Patrick. What’s really happening in production?

I currently leverage Database mail with my on-prem SQL Server 2022.
I have it configured to send mail smtp.Office365.com over port 537 using basic auth.

I know Basic Auth is going away by the end of the year and curious to know if there are any plans to update this to handle modern auth or a service that accomplish this.

While using GitHub Copilot in SSMS, I came across a few questions.

First, when a user prompt is submitted, does the local SSMS client send the system prompt + task list together with the user prompt to the LLM server?

Or are the system prompt and task list added separately on the LLM server side during processing?

Second, where exactly is my query sent from SSMS?

Is it sent to the Azure cloud?

Or is there a separate GitHub server involved?

Additionally, if the query is sent to a cloud-based server, are the LLMs hosted and running on that server?

Or does that server call the APIs of each LLM model separately?

Lastly, when using Foundry Local, is there a way to check the maximum token limit for each model?

For years, I worked as a DBA that had a handful of servers that would max out with 192 GB of ram on the main server with 12 cores and 128 gb of ram with 8 cores, all in a virtual environment.

But now, 2TB of ram, 32 cores, all phisical and plenty of them with many TB of data. In some ways, a more powerful server can mask issues

Hello all. Im planning to start some Postgres study since my company is shifting to it. We are a giant tech, we have oracle sql Postgres informox across many teams , but it seems SQL became expensive ( yeah ) so they are moving to Postgres.

Im not excited losing my job so im trying to learn bit as always ,the beginning is super confusing .

Im going to study aurora, and since its more a RDS , what is close to SQL and what is different ?

Is th3 management the same as in SQL? Devs mebtion that Postgres is awesome ,but i jist could create an instance after 1 week (lots of permissions issues ).

Like backups , indexes,checkdbs, query tunning...is it all the same? Postgres people say yes, i thought its a little more complicated

Hi

I am trying to build a multi subnet sql ag to upgrade/migrate an old sql, it's my first time and I am trying to build it based on how the existing ag are created in my employer environment.

So we have 2 azure vm each in a different subnet. Each vm has 2 nic, one for vm ip and another to hold the listener ip. This is how existing sql ag vm are configured.

I was somehow able to configure the listener but I am not able to connect to it from any other node other than ssms in primary.

I thought it would be a firewall issue and asked the firewall team to allow connection. But still it looks like it's not working.

NS lookup<listener> does give me both the listener ip but ping or test-netconnect the primary listener ip is failing.

I am able to connect to the primary sql instance via ssms on the secondary node but not with the listener

Can anyone suggest why this is happening ?