Kevin Hill

A good DBA is solid gold. CNCs are often jack of all trades, master of quite a few; I’m reasonably good with SQL Server, I get by with Oracle, but a decent DBA will leave me in the dust. I once had a DBA fix a 90 second query to milliseconds just by changing the number of histogram buckets the query used. I don’t even know what those are! At one client we ran the MRP in subsystem mode, where it populates the F986113 table with wave after wave of records to be processed, most nights it took 45 mins to run, but every fourth night the jobs would suddenly take over four hours. A DBA figured it out, it was the High-Water Mark on the table, once it hit a threshold performance would plummet. The fix was simple, but drastic, as it’s a working table, it was dropped and recreated every night. A few years back I was hauled into a P1 incident having been told that following a data refresh of a PP environment, the auditing (21CFR Part 2) was failing in Production (PD). In front of a cast of hundreds I reviewed the logs and sure enough when a Kernel started there was a configuration error in the logs, this generally means that auditing has been defined but the underlying shadow tables, triggers and views aren’t there. What was really strange was that not all kernels had the error, and not all transactions would fail. The client also observed that transactions that did run OK, sometimes weren’t appearing on the system. I trawled through the configuration and found no issues, I was mystified. Eventually we located a DBA and he spotted the issue almost straight away. The refresh of Production to a PreProduction (PP) dataset was done via Pluggable Databases as its fast and convenient, the only real drawbacks are the tables have the same schemas and there’s some additional configuration and security overhead. The process of completing the refresh also had some scripts to switch off the auditing in PP. Against advice, the PP pluggable database was on the same server as PD, and the customer had set up a number of custom listeners so they could separate connectivity to different groups. The nett result was that when the PP Pluggable Database came online, it connected itself to the SAME LISTENER AS PD. OUCH is the correct reaction to that, because what’s happening is that when JDE makes a connection to the database; half the connections were going to PD and the other half to PP. The DBA saw those connections and worked backwards. The log files weren’t lying, those kernels connecting to PP were indeed looking at a dataset that wasn’t configured with auditing. If that hadn’t been configured that way, I’m not sure how long it would have taken to spot it, as it was it was a few hours of business transactions. For only the second time in my career, I recommended the client reach for the backup tapes. They elected not to do so as some payment runs had gone out, and they somehow fixed the data.

62

4 Comments

I’ve published an Enterprise DBA Security Framework focused on permission visibility, drift detection, and audit-safe governance for SQL Server and Azure SQL environments. This isn’t a “self-healing” demo or a security tool that makes blind changes in production. The framework is intentionally: *Read-only by default *Human-in-the-loop *Audit-first, remediation-optional *Designed to fit real enterprise change control It demonstrates how Senior DBAs and DBREs can detect permission drift, generate audit evidence, and integrate automation without violating separation of duties or trust boundaries. The repo includes: *Permission snapshot scripts (SELECT-only) *Python-based drift detection *PowerShell orchestration with rollback safety *Threat modeling, architecture docs, and audit Q&A This reflects how I approach database security in regulated, large-scale environments: visibility first, automation second, governance always. This repository demonstrates production-ready Database Reliability Engineering (DBRE) practices for SQL Server environments. It includes rollback-safe automation, permission drift detection, auditable baselines, and validation workflows designed to reduce operational risk and improve system reliability. The project reflects my approach to treating databases as first-class production systems, with observability, control, and repeatable patterns at the core. 🔗 GitHub: https://lnkd.in/g8yGcM7A I’m always interested in thoughtful discussions around database reliability, security, and operational maturity.

"It’s cool to see SSIS support continues for the many Microsoft customers still using the platform for data integration." - from my latest blog post titled "Add the SSIS Extension to Visual Studio 2026 Insiders." Read more at the link in the comments. #SSIS #VS2026

55

9 Comments

For database health monitoring and alerting, I focus on early detection, actionable alerts, and business impact, not just “is the server up.” Here’s how I typically structure it, especially in Microsoft SQL Server environments, but the principles apply broadly. Layered Monitoring Strategy I monitor at four layers so no single failure blindsides the team. 1. Infrastructure *CPU, memory pressure, disk latency, IOPS *Network latency / packet loss *VM host health (VMware / Hyper-V) Why: Most “database problems” start outside the database. 2. SQL Server Instance *Wait stats (PAGEIOLATCH, SOS_SCHEDULER_YIELD, CXPACKET) *Blocking and deadlocks *TempDB contention *Memory grants pending *File growth and free space Key approach: Baseline normal behavior first → alert on deviation, not raw numbers. 3. Database-Level Health *Backup success/failure (FULL, DIFF, LOG) *Index fragmentation trends *Corruption checks (DBCC CHECKDB) *Long-running queries *Replication / AG / Log shipping status 4. Application / Workload *Query duration changes *Sudden plan regressions *Connection pool exhaustion *Error rates from the app side Best signal: “Users feel it” metrics > system metrics.

1

I’ve been thinking a lot about how to share DBA training materials and create a space where admins and professionals can really engage—not just read posts, but actually connect, ask questions and learn together. The thing is… I’m not sure where the best place is to do this. Should I: Build a dedicated website or portal? Use an existing platform (like LinkedIn Groups, Slack, Discord or something else)? Focus on more interactive formats like webinars and workshops? I’d love to tap into your experience:  If you’ve built or joined a community before, what worked best?  Where do you usually go when you want to learn, share, or connect with others in your field? Your input will help me figure out the right path to grow this into something truly valuable. Thanks in advance for sharing your thoughts! #CommunityBuilding #DBATraining #ProfessionalDevelopment #KnowledgeSharing

9

5 Comments

The new, shiny thing gets all the buzz for awhile and that's normal. There have been a deluge of blog posts and announcements about SQL Server 2025 preview. Many new features have been discussed in a very short amount of time. I set up Windows Server 2025 DataCenter Eval edition and installed SQL Server 2025 CTP 2.0 this morning. Oh, and I set up SSMS 21, which is based more on Visual Studio. There was an interesting prompt to sign in with Github when launching SSMS, and there is the option to enable the previously stand-alone Database migration Assistant into SSMS. From that, I learned that the stand-alone product is deprecated but still available. Have you set up your SQL Server 2025 test environment yet? What are you looking forward to experimenting with in this release? #sqlserver #databases

12

3 Comments

MSP service desks are under constant pressure; tickets piling up, engineers burning out, and hiring always a step behind. The fix isn’t another recruiter on standby. It’s a retainer model that gives you consistent access to the right people when you actually need them. This approach helps MSPs: • Build teams, not patch holes • Reduce hiring lead times • Protect client SLAs and profit margins We’ve detailed the full framework in our latest blog: MSP Service Desk Hiring: How Retainer-Based Recruitment Builds Unstoppable Teams. (Link in first comment 👇) #Recruitment #MSPHiring #MSP #Retainer #ServiceDesks

1

1 Comment

Turned ClickOps documentation used by thousands into Infrastructure as Code 🚀 When setting up Home Assistant MS365 integrations, I experienced friction in setup - spending a berth of time on initial setup and copy/pasting the wrong things leaving me scratching my head. Great docs from the maintainer, but lots of manual clicking through portals. My process: ✅ Used the existing ClickOps docs as my blueprint ✅ Translated each manual step into Terraform resources ✅ Tested individual pieces (permissions, app registration, secret rotation) ✅ Condensed the entire workflow into 3 simple commands ✅ Documented it so others can deploy and maintain their infra even with no Terraform knowledge The magic of Terraform: What used to be "copy this output, paste it there, don't forget this permission" became: terraform init terraform apply terraform output client_secret Key learnings: - Good documentation translates beautifully into IaC - Testing individual Terraform resources before combining them saves headaches - The best automation starts with understanding the manual process first - Colocating all outputs dramatically improves UX Sometimes the most satisfying engineering is taking something awesome that has extra friction to setup and optimizing setup it make it effortless. Curious in the module? Published to Terraform Registry: https://lnkd.in/gxravpY7 #Terraform #InfrastructureAsCode #CloudEngineering #Automation #HomeAssistant

10

Transitioning from #Azure EA to MCA is often framed as a contract change by Microsoft but in practice it has very real impacts for FinOps teams during and post transistion. I recently wrote an article based on my experience going through an EA → MCA transition as a FinOps lead. The goal wasn’t to re-explain what EA or MCA are, but to highlight the operational and FinOps considerations that tend to show up after the paperwork is signed. If you’re planning an MCA move or already in the middle of one, I hope this helps set expectations and reduces a few surprises. 📖 Read the article here: https://lnkd.in/ezqQBnEu #FinOps #Azure #MCA #EnterpriseAgreement #CostTransparency

95

5 Comments

Data processing and data sovereignity are more and more important. For Copilot there will be "in country data processing" for selected countries. there is an updated announcement here. https://lnkd.in/ggZrb28y #microsoft365 #Copilot

22

2 Comments

GitOps is an Enterprise Problem, Not a Kubernetes Problem A Fortune 2000 once called me about a defect problem in their mainframe environment. They’d given each developer their own virtual environment to work faster. It worked—individually. Collectively, it broke their CICD process. Integration testing was no longer part of every update, and defects spiked. That’s the same risk I see with Kubernetes GitOps rollouts. If Kubernetes is the platform in your enterprise, GitOps can be your operational backbone. If it’s just a platform, GitOps needs to extend your existing delivery methodology—not create a new silo. This is where many teams get stuck: Do you adopt a Central Console Model or a Distributed Controller Model? It’s not a tooling decision first—it’s an operating model decision based on your governance, scale, and developer experience goals. While Argo CD and Flux can both adapt, their philosophies naturally align to different models. Pick the one that fits how your enterprise already delivers software, not just Kubernetes software. The goal isn’t to make Kubernetes special. It’s to make it just another lane on the same operational highway.

2

🚀 AZ-305 – Designing Microsoft Azure Infrastructure Solutions I’m scheduled to take my Microsoft Azure certification exam (AZ-305) this Friday, September 12, 2025. 💡 Planning focused revision and last-minute practice! If anyone else is preparing for AZ-305, let’s connect and do a virtual group study session 🤝 👉 We can share revision notes, discuss case studies, and solve practice questions together. Let’s help each other succeed! 🌟 #Azure #MicrosoftCertification #AZ305 #Cloud #GroupStudy #LearningTogether

19

9 Comments

𝗪𝗵𝘆 𝗡𝗼𝗿𝘄𝗮𝘆 𝗯𝗿𝗲𝗮𝗸𝘀 𝗲𝘃𝗲𝗿𝘆 𝗬𝗔𝗠𝗟 𝗽𝗮𝗿𝘀𝗲𝗿 (𝗮𝗻𝗱 𝘄𝗵𝗮𝘁 𝘁𝗵𝗮𝘁 𝘁𝗲𝗮𝗰𝗵𝗲𝘀 𝘂𝘀 𝗮𝗯𝗼𝘂𝘁 𝘀𝘆𝘀𝘁𝗲𝗺 𝗱𝗲𝘀𝗶𝗴𝗻) I came across an interesting article on StrictYAML's documentation that perfectly captures a problem I've wrestled with in configuration management. The "Norway Problem" is one of those edge cases that reveals deeper issues with how we handle data parsing. Here's the scenario. You have a simple YAML configuration listing supported countries: countries: - GB - IE - FR - DE - NO Run this through a standard YAML parser and you get something unexpected: {'countries': ['GB', 'IE', 'FR', 'DE', False]} Norway's country code (NO) gets silently converted to the boolean False. This isn't a bug in the parser, it's actually following the YAML specification correctly. The spec defines implicit type conversion rules that automatically interpret certain values as booleans, numbers, or null values. The same thing happens with version numbers. If you write "9.3" it becomes a float instead of staying a string. Someone with the surname "Null" would see their name converted to None. These conversions seem helpful until they break your application logic in subtle ways. What makes this particularly tricky is that your code doesn't crash when parsing the configuration. Instead, you get type mismatches or key errors later when the application tries to use False as a dictionary key or perform string operations on what it expects to be text. The broader principle here is that implicit behavior in systems creates hidden failure modes. When software tries to be clever and interpret your intent, it will occasionally guess wrong. And when it does, the resulting bugs are often harder to track down than if the system had just done exactly what you told it to do. Source: https://lnkd.in/emYQyQCS

12

2 Comments

Here is another very "interesting" tidbit. The next major Windows server release will kill any app that relies on SQL Server connections over named pipes instead of using certificates. That is because not only is NTLM v1 is being phased out rapidly (not a problem for most people) but NTLM v2 is *also* phased out in the next major release. And for a lot of people using on-premise SQL Server, that means their ODBC connections go down. If you are on a modern driver version (like Microsoft OLE DB Driver 19 for SQL Server), the setting for modern connection security is already on by default. But you can turn it back to the old connection security and that may have happened in legacy software. If you run SQL Server with legacy software, you should start asking questions from your vendors and your developers right now, to avoid either being taken offline with the next major Windows server release, or have a long delay in deployment of the release. Source: https://lnkd.in/ejyiFY7u (PS: I recommend subscribing to the SQL Server Central mailing list if you use SQL Server regularly)

34

“Your Cloud Can Look Great and Still Be Fragile” We've seen clients with: – All the dashboards – All the alerting – Clean Terraform… …who still fell over because of one bad IAM config or one untested failover plan. Health isn't cosmetic. It's structural. What's the one thing your team does to test cloud resilience?

4

1 Comment