Neha Chaudhari’s Post

I previously wrote about how the underlying technology for Fabric mirroring changed with SQL Server 2025. In this blog post, we will look at how to monitor this process, both in SQL Server and in Fabric.

For any of my folks out there using SQL 2025 and mirroring into Fabric, Meagan Longoria explains this process very well.

For 3 years now, using SESSION_CONTEXT in SQL Server has either given you incorrect results, crashes, or single-threaded queries, depending on which workaround you pick: https://lnkd.in/gSXPX3Uz

🚨 SQL Server Timeout Errors? Here's How to Fix Them! Have you ever faced this frustrating error? "Timeout expired. The timeout period elapsed prior to completion of the operation." In my latest blog, I break down: ✔️ What timeout errors really mean ✔️ Common causes like slow queries, blocking, and missing indexes ✔️ Practical troubleshooting steps ✔️ Proven fixes to improve performance If you're working with SQL Server, this guide will help you debug and resolve timeout issues efficiently. 🔗 Read here: https://lnkd.in/etNmNQ8R #SQLServer #Database #PerformanceTuning #BackendDevelopment #TechBlog

When SQL Server Eats All Your Memory… What Do You Do? Last week, I faced a classic yet critical issue — A production SQL Server suddenly started consuming almost 100% of available memory. At first glance, it looked alarming. Applications were slowing down, alerts were firing, and users were not happy. But here’s the thing — 👉 High memory usage in SQL Server is not always a problem. It’s often by design. So instead of panicking, I followed a structured troubleshooting approach 👇 🔍 Step 1: Understand SQL Server Memory Behavior SQL Server will utilize as much memory as allowed to improve performance (Buffer Pool, Plan Cache). So the real question is: ➡️ Is it using memory efficiently or causing pressure? 📊 Step 2: Check for Memory Pressure Key indicators I looked at: Page Life Expectancy (PLE) Memory Grants Pending Resource Monitor (sys.dm_os_ring_buffers) Wait stats (RESOURCE_SEMAPHORE) 👉 If queries are waiting for memory → That’s a red flag. 🧠 Step 3: Validate Max Server Memory Setting One of the most common issues: Max memory set too high OS left starving ✔️ Best practice: Leave memory for OS + other services (e.g., don’t allocate 100% to SQL Server) 📦 Step 4: Identify Memory Consumers Used DMVs like: sys.dm_exec_query_memory_grants sys.dm_os_memory_clerks sys.dm_exec_cached_plans 👉 Found a few heavy queries consuming large memory grants. 🐢 Step 5: Look for Poor Query Design Missing indexes Large sorts / hash operations Outdated statistics ✔️ Fixing queries = reducing memory pressure 🔄 Step 6: Check for External Factors Multiple instances on same server Other applications consuming RAM Sudden workload spikes 💡 Key Takeaway Not all high memory usage is bad. 👉 Memory pressure is the real problem — not memory consumption. 🔥 Pro Tip: If SQL Server is using a lot of memory but performance is good, 👉 You’re actually in a healthy state. #SQLServer #DBA #PerformanceTuning #DatabaseAdministration #SQLTips #TechCareers #AzureSQL

Every DBA's first move when something's slow: check wait stats. But most of us are looking at the wrong ones. CXPACKET is probably the most over-diagnosed wait type in SQL Server. It's almost always flagged as a parallelism problem. Usually it just means parallel queries are running. That's... expected. ASYNC_NETWORK_IO gets blamed on the network. It's almost never the network. It's the client app doing row-by-row processing. Meanwhile, RESOURCE_SEMAPHORE - queries silently sitting in a queue, not running at all because they can't get a memory grant - barely gets a mention. Neither does WRITELOG, which can quietly bottleneck every single write operation on the server when log drive latency creeps up. The other thing most people miss: sorting waits by total time buries the ones that actually hurt users. A wait that happens 100 times at 5 seconds each will rank below a wait that happens a million times at 1ms. But which one are your users complaining about? Wrote up the full breakdown - which waits deserve more attention, which ones are noise, and the signal waits metric that almost everyone overlooks. https://lnkd.in/dq9WSSXF

Bad Parameter Sniffing – A Hidden Cause of High CPU in SQL Server When troubleshooting high CPU utilization in SQL Server, we often look at the obvious causes first. Previously, I discussed four common reasons: Missing Indexes Stale or Outdated Statistics Implicit Conversion Non-SARGable Predicates But there is another important and often overlooked cause: Bad Parameter Sniffing What is Parameter Sniffing? Parameter sniffing occurs when Microsoft SQL Server examines the parameter values during the first execution of a stored procedure or parameterized query and uses those values to generate the execution plan. The word “sniff” simply means “examine.” During the first compilation, the SQL Server Query Optimizer: Reads the input parameter values Combines them with column statistics Estimates the number of rows to process Generates the execution plan accordingly Where Parameter Sniffing Occurs Parameter sniffing typically happens when parameters are passed to: • Stored Procedures • Parameterized Queries • Functions Example: EXEC GetCustomerOrders @FirstCustomer, @LastCustomer When this query runs for the first time, the optimizer examines the parameter values and builds an execution plan based on those values. If later executions use very different parameter values, the same plan may perform poorly—leading to slow queries and high CPU usage. Understanding parameter sniffing behavior is critical when diagnosing performance issues in SQL Server systems. In the next post, I'll share how to detect and fix bad parameter sniffing in production systems. #SQLServer #DatabasePerformance #QueryOptimization #DBA #SQLTips #DataEngineering

A common misconception by beginner (and even some intermediate) engineers in SQL Server transactions 👇 “If I have multiple statements inside a "BEGIN TRAN", and one fails, SQL Server will still execute the remaining statements and commit everything at the end (default behavior).” This is only partially true — and relying on it can lead to serious data inconsistencies. Here’s what actually happens: When you use "BEGIN TRAN" (with default "XACT_ABORT OFF"): - If a statement fails, SQL Server does NOT automatically rollback - The transaction may still remain active - Subsequent statements might continue executing - "COMMIT" may succeed — resulting in a partial commit Example outcome: - 1st ✅ - 2nd ✅ - 3rd ❌ (failed) - 4th ✅ - 5th ✅ 👉 Final commit includes: 1,2,4,5 But here’s the catch ⚠️ Not all errors behave the same: - Some errors stop execution immediately - Some make the transaction uncommittable ("XACT_STATE = -1") - In such cases, "COMMIT" will fail and only "ROLLBACK" is allowed So the behavior is not predictable unless you control it explicitly ✅ Best practice: Always write transactions like this: SET XACT_ABORT ON; BEGIN TRAN BEGIN TRY -- your statements COMMIT END TRY BEGIN CATCH ROLLBACK END CATCH This ensures: - No partial data commits - Consistent behavior - Safer production systems 👉 Moral: SQL Server does not guarantee “all-or-nothing” unless you enforce it. #SQLServer #DotNet #BackendEngineering #Transactions #SoftwareEngineering #DatabaseDesign

Resource Governor in SQL Server 2025. A Good Change. Someone runs a massive SELECT INTO #temp, tempdb fills the drive, and the entire instance freezes up dead. You get paged at 2 AM, kill the session, shrink the files, and spend the next day writing a monitoring script that you hope will catch it next time. SQL Server 2025 finally lets you stay ahead of this….more https://lnkd.in/eS7Yuipx

Shamir’s Secret Sharing in SQL Server by Sebastiao C. Pereira >>> https://lnkd.in/ePEXDbZi Shamir’s Secret Sharing is a cryptographic algorithm that allows a secret to be split into multiple components and shared among a group in such a way that the secret can only be revealed if a minimum number of components are combined. Is it possible to have this algorithm implemented in SQL Server without using external tools?