August 8, 2017 at 9:16 pm
Comments posted to this topic are about the item My Problem, or Yours?
August 8, 2017 at 11:22 pm
Some issues that I've had that were "Not the database"tm
Server slow - VMWare balloon driver taking RAM
Failed authentication - Change in AD Server version incompatible with old servers
Failed authentication - Time mismatch between AD server and DB server
Failed authentication - Duplicate SPNs registered
Failed authentication - No SPN registered
Failed authentication for linked servers - Trust this server for delgation not enabled in AD
Slow backups - SAN network teaming not working correctly
Cant connect - firewall
Server not running - firewall
Firewall confirmed port open still cant connect - firewall
No really, we telnet checked, its open - connection string
August 9, 2017 at 1:59 am
Excellent article, thanks.
IMHO it's rarely a problem with the database... often a problem with the user... sometimes a problem with the network... but always somehow my problem!
August 9, 2017 at 5:46 am
Do I relate to that 🙂 I started saying a few years ago 'someone changed nothing somewhere'.
I work in the government, and we outsourced our infrastructure to another governement agency many years ago. So when things stop working right it's always a big administrative problem as who can talk directly to whom....
August 9, 2017 at 7:21 am
Beautiful article, Andy! Life became much easier for me when stopped trying to assign blame and started asking questions.
August 9, 2017 at 8:08 am
Learned a long time ago to not accept the old excuse of 'nothing has changed'.
When I hear this from the teams that I work with, my response is 'prove that your application/code/SQL/network/storage/whatever IS NOT the problem'. This might make for some wasted time among the various teams involved, but I have found that it often pulls up more information that can aid in pinpointing the issue and can actually get the problem solved faster.
August 9, 2017 at 8:13 am
I've taken a fairly straight-forward attitude towards the problems that crop up. Even if I'm *sure* that "it's not me," I'll check everything possible on my end to confirm this (or show it *is* my end) with the expectation that at the same time the devs are working their end as well.
There have been a few cases where, while not me, it was something outside my control (server migrating to a new host in the VMware,) there have been a few that have been me, and there have been some that it turns out it was an on-going issue that the end-user finally complained about to the developer and was on the application side.
And there have been some that mostly boiled down to performance tuning.
If you maintain a good relationship with the developers (even if you're in a silo'ed environment where the only time you talk to them is when something broke,) it becomes remarkably easy to get problems resolved. No finger-pointing, no C-level execs brought in to bring down the hammer.
August 9, 2017 at 8:16 am
I have had three sets of blame:-
I) Slow performance (twice) - both times it was due to other people downgrading the server specification I produced
ii) Problems arising out of poor requirements that are added to post implementation necessitating changes to the database (sometimes major)
iii) Issues arising that go through 'Chinese whispers' so you struggle to know what the real issue is. Clients reporting problems to their account manager is the worse scenario!
How to overcome these problems is another matter!*?
August 9, 2017 at 8:19 am
I think a lot of this depends upon the size of the organization. Now that I work for a larger IT shop than I've ever worked for before, I've been really surprised at how slow things happen. I'm working on a WPF app that I've got to test on some plain Windows installation. Since I've been having a hard time looking for a laptop or desktop available for testing, I've decided to install a VM of Windows 10 Enterprise (since that's what it has to be) and domain join it, so I can use it for testing. Two days ago I sent an email to operations asking for a copy of Windows 10 so I can install it in the VM, explaining what I wanted to do and why. I've yet to get even an acknowledgement of my email. Because of the glacial rate at which anything happens, I've gotten into the habit of getting about 5 different requests started, because I know it will take at least days, perhaps weeks, before any action is taken. I've dreaded the possibility of 2 or more of them becoming available at the same time, but so far in 2 years that's never happened, so this strategy works. I'm guessing that's just the way things are, in large IT shops.
Kindest Regards, Rod Connect with me on LinkedIn.
August 9, 2017 at 9:08 am
Great article, and can I relate. If the error the user sees says Database Connection Timeout, that definitely means it is a SQL problem right? Been working on this error on one application for about 18 months, and only within the last few months have I gotten our Network people to start looking at the network side. Been telling them it is a network, and/or SAN issue, as everything I see points to this. I used to be the network admin, and I configured our first SAN, which had no performance issues, and this connection timeout issue started with the implementation of a new SAN. Hence, what changed? New SAN installed. All applications are seeing performance drops since the new SAN, but the error says Database, so it must be the DBAs problem, right?
August 9, 2017 at 9:53 am
My business rule is that I only click send on an email if it contributes to the solution. So, I never send the "its not me" email.
August 9, 2017 at 10:49 am
I've found that a lot of the problems that are "database" issues turn out to be queries that have either incomplete joins (for tables that have multi-column primary keys) or join on the wrong column, use scalar functions :pinch:, or have missing WHERE clause criteria. I've taken to reviewing stored proc performance (fortunately we always use stored procs) a coupe of times a year, highlighting problem queries, and giving suggested fixes where it's an easy problem to handle, and give this information to the development team's manager. I'd like to do it more frequently, but it usually takes them multiple months to even get to the low hanging fruit quick fixes though.
August 9, 2017 at 11:02 am
If you have a change control process and/or continuous integration process in place, then you can refer to that to see what recent deployments have occurred, not just on the database server but also on application server and infrastructure level. But if you happen to work in an IT shop where there are occasional "BlackOps" deployments going on in addition to officially sanctioned DevOps, you can also use this script to at least confirm what database objects have recently changed.
https://www.sqlservercentral.com/Forums/1399176/Query-all-objects-created-or-modified-after-specified-date
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
August 9, 2017 at 1:21 pm
GeorgeCopeland - Wednesday, August 9, 2017 9:53 AMMy business rule is that I only click send on an email if it contributes to the solution. So, I never send the "its not me" email.
But "it's not me" can contribute to the solution -- if it's followed by solid evidence.
Being a database developer, I'm considered a DBA by the app and network teams and a developer by the data team. So I get a lot of fingers pointed at me.
I've taken the attitude that "maybe it is me" so before I respond to an issue, I make sure I can confirm whether it's related to my code or not. Usually this has the result of also hinting at whether it's related to app code, database settings, or networking when it's not me.
This has gotten me a lot of respect from the various teams. The downside of this approach is that I also get asked to help fix issues that aren't even related to my data/code at all...
August 9, 2017 at 5:17 pm
Good write-up of a very common nuance of human behavior. Over a few decades at the coal-face you see this happen over and over, and it pervades companies of varying size and industry sectors.
This attribute of humanity repeats when a generation of team members moves-on, when the lesson of the last major disaster is lost.
It's an attribute that should go away as AI replaces the human element of our professions.
Bring-on the AI!
Cheer,
Pete Q
Cheer,
Pete Q
Viewing 15 posts - 1 through 15 (of 21 total)
You must be logged in to reply to this topic. Login to reply