Evan B.’s Post

Every DBA has a Sunday night index rebuild job. So do I. But here's what changed: We stopped running it blindly. For years, that job kicked off at midnight every Sunday like clockwork. Did we know which indexes actually needed it? No. Did we check fragmentation levels first? Rarely. It just... ran. And I felt like a responsible DBA because of it. Then we started measuring. Turns out, most of those rebuilds were doing nothing. Fragmentation under 30% on modern SSDs? The query optimizer barely notices. we were burning I/O and locking tables for zero measurable improvement. The job still runs. But now it's smarter. It checks what actually needs attention and skips the rest. My maintenance windows are shorter. My weekends are calmer. And my databases run just as well. The lesson wasn't "stop maintaining your indexes." It was "stop maintaining them with your eyes closed." Full breakdown on the blog: https://lnkd.in/eKJJha9p #SQLServer #DatabasePerformance #DBA #AutoDBA #DatabaseManagement

I built SQLVault Pro as a free tool for the SQL Server DBA community — because keeping track of dozens (or hundreds) of instances shouldn't require a spreadsheet. SQLVault Pro lets you maintain a clean, searchable inventory of your SQL Server instances. Track which application each instance powers, what environment it belongs to (dev/test/prod), and what Always On / HA configuration it's part of. Search by database name, username, table, or index — and get to the right instance fast without digging through notes or tickets. Export functions are already in — database lists, user lists, and instance lists, ready for auditing. 👇 Check the video below to see it in action. One Docker pull and you're running. What's coming next: 📥 Bulk import — add all your instances at once, no more one-by-one entry 🤖 AI-powered search — locate any instance faster with natural language My goal is to make this the go-to inventory tool for SQL Server DBAs. Free. Always. 🔗 https://lnkd.in/dV7BHiVy Contributions and pull requests are very welcome — let's build this together. #SQLServer #DBA #DatabaseManagement #OpenSource #SQLVaultPro #DatabaseInventory #DevOps

L5–L7 file systems failed at scale — redundancy, inconsistency, no access control. dbms fixed that. dbms = structured way to store, retrieve & manage data without the mess. advantages: integrity, concurrency, backups, abstraction. trade-off: cost, complexity, overhead. data abstraction is why you query a table, not a disk sector — physical → logical → view. 3 layers. clean separation. #DBMS #SQL #Databases

🚀 Why TempDB Configuration Can Make or Break SQL Server Performance One of the most underestimated performance boosters in SQL Server is TempDB optimization. Yet, it’s involved in almost everything — sorting, hashing, temporary objects, version store, index rebuilds, row versioning, and more. 🔍 The common mistake? Running production workloads with a single TempDB data file. ⚡ Why multiple TempDB data files matter: When many sessions try to allocate space simultaneously, a single file creates PFS, GAM, and SGAM page contention, leading to: ❌ PAGELATCH waits ❌ Slower query performance ❌ CPU underutilization ✅ The fix: Configure multiple equally sized TempDB data files to enable proportional fill and reduce allocation contention. 📌 Best practices I follow in real-world systems: • Start with # of logical CPUs up to 8 files • Keep all data files same size & auto-growth • Place TempDB on fast storage (SSD/NVMe) • Pre-size files to avoid frequent growth • Monitor waits like PAGELATCH_UP / PAGELATCH_EX 💡 After implementing this in high-concurrency environments, I’ve seen: 📈 Significant reduction in latch contention 📈 Faster ETL & reporting queries 📈 Better overall throughput TempDB is not just a system database — it’s a performance backbone. How have you configured TempDB in your environment? #SQLServer #TempDB #PerformanceTuning #DatabaseAdministration #DBA #SQLServerTips #DataPlatform

🔥 “Just Reboot It!” — The Most Misleading Fix in SQL Server Every DBA has heard this. And honestly… sometimes it works. But here’s the truth from experience 👇 Rebooting SQL Server doesn’t fix the problem — it resets the symptoms. ⚠️ What actually happens after restart? • Buffer cache gets cleared • Execution plan cache is wiped • Bad queries temporarily disappear • Memory pressure drops (for a while) 👉 Result? System looks fast again… but only temporarily. 💡 The Real Problem You’re not solving anything — you’re hiding the root cause: • Missing indexes • Bad execution plans • Parameter sniffing • Blocking / deadlocks • Memory pressure or I/O bottlenecks 🚨 The Danger This creates a cycle: Problem → Reboot → Temporary relief → Problem returns worse 🎯 What Experienced DBAs Do Instead: ✔ Analyze wait stats ✔ Identify top resource-consuming queries ✔ Fix indexes & query design ✔ Monitor memory & I/O patterns ✔ Use Query Store & DMVs 📌 Pro Tip (15+ yrs lesson): If reboot fixes it… 👉 You’ve just confirmed there’s a deeper issue to investigate. 💬 Question for DBAs: Have you ever solved a “reboot fix” problem permanently? What was the root cause? #SQLServer #SQLDBA #DatabasePerformance #PerformanceTuning #DatabaseAdministrator #QueryOptimization #AlwaysOn #AzureSQL #AWSRDS #TechLeadership #DataEngineering #ITOperations

I have created a tutorial on how to build a relational database from scratch in Rust . This tutorial builds a basic RDMS engine :  - Page-based disk storage  - An LRU buffer pool  - A slotted-page heap  - A B-Tree index  - A hand-written SQL parser  - A Write-Ahead Log  - Crash recovery  - Multi-table JOINs  - Concurrent transactions with 2PL locking    The tutorial is structured so that each chapter introduces one layer of the stack, explains the theory behind it, walks through the implementation, and ends with tests you can run yourself. By the end you have a working RDBMS you wrote line by line. I have tested the code only on my Mac ( "it works on my machine")!! Some tweaking may be required on other platforms. https://lnkd.in/dKEAP2eN Nirmalya Sengupta Srinivas Chillara Vsrv Raghavan Pradeep Ck Rajat Singhal Shirish Patwardhan  #Rust #Databases #SystemsProgramming #DatabaseInternals #OpenSource #SoftwareEngineering #LearningInPublic

I tracked my own time for a month as a production DBA. 80% of what I did could have been done by a well-trained intern with a checklist. Not because the work is easy. Because it is repetitive. The same configuration checks. The same index analysis. The same capacity monitoring. The same “compare this number to this threshold and flag if it’s wrong.” Week after week, on every server I’ve ever touched. The 20% that actually needs 15 years of experience is the interesting stuff. Architecture decisions. 3am production incidents where you’re coordinating with app teams and the CEO is calling. Complex query problems where the data distribution is weird and the legacy code can’t be touched. That work requires judgment and context you can’t script. The problem is most DBAs never get to that 20% because the 80% fills the week. If you’re a manager wondering why your DBA never has time for that migration project, that’s probably why. That’s the problem AutoDBA was built to solve. Not to replace your DBA. To give the routine work somewhere else to go. Full write-up: https://lnkd.in/ehR_5VQp #SQLServer #DatabasePerformance #DBA

SQL Server Concurrency Issues with Parallel Query Plans by Mehdi Ghapanvari >>> https://lnkd.in/ebwfH6e5 Parallelism enables SQL Server to execute queries across multiple CPU cores simultaneously. The query optimizer determines whether to execute a query in parallel or not based on cost. When a query is complex and contains expensive operators (such as sorts, aggregations, etc.) and processes many rows, it is more likely to result in a parallel plan than a simple query that processes a few rows.

SQL Server Concurrency Issues with Parallel Query Plans by Mehdi Ghapanvari >>> https://lnkd.in/ecHSEmHN Parallelism enables SQL Server to execute queries across multiple CPU cores simultaneously. The query optimizer determines whether to execute a query in parallel or not based on cost. When a query is complex and contains expensive operators (such as sorts, aggregations, etc.) and processes many rows, it is more likely to result in a parallel plan than a simple query that processes a few rows.

🔐 Escalation in SQL Server 📈🔼🔴 Simple Query - But sudden explode in Production❓ It might be Lock Escalation. 🔎 What is Lock Escalation? In Microsoft SQL Server, when a query acquires too many row/page locks, the engine may automatically convert them into a table-level lock to reduce memory overhead. 👉 Small locks ➜ One big lock 👉 More blocking ➜ Less concurrency 🎯 Why Does It Happen? SQL Server escalates locks when: A statement acquires ~5000+ locks on a single object. The system is under memory pressure Large UPDATE/DELETE operations run in one transaction. 💡 Simple Example BEGIN TRAN; UPDATE Orders SET Status = 'Processed' WHERE OrderDate < '2023-01-01'; -- 100,000 rows affected -- Initially row locks -- Then escalated to TABLE LOCK COMMIT; 🔴 Result? Other sessions trying to SELECT from Orders may get blocked. Even small queries must wait. 🧠 Why It’s Dangerous in Production ➡ Causes sudden blocking chains ➡ Impacts OLTP systems heavily ➡ Can freeze high-concurrency apps ➡ Hard to detect unless monitoring locks 🛠 How to Prevent It ✅ Break large operations into batches WHILE 1=1 BEGIN UPDATE TOP (1000) Orders SET Status = 'Processed' WHERE OrderDate < '2023-01-01'; IF @@ROWCOUNT = 0 BREAK; END ✔ Create proper indexes (reduce rows touched) ✔ Keep transactions short ✔ Monitor using: 👉SELECT * FROM sys.dm_tran_locks; ✅ If Slow queries is not the reason, it might be lock escalation causing blocking storms. 💬 Have you ever faced a production outage because of lock escalation? #SQLServer #DatabasePerformance #SQLTips #LinkedInLearning #TechCareers #InterviewTips