In part 1 of the “No One Listens To Me! Why?” series I described a situation where I had to convince my manager to take action on some actions.
This story will again be a true story where this time I had to convince my colleagues.
I went on the the SQL Cruise, which is a fantastic way to learn and meet new people. I attended a session by Argenis Fernandez (t – l) who touched a subject about page verification.
Coming back to the office I wanted to start implementing my new acquired knowledge. I first investigated some of our main databases. What I found was that some of our databases were not configured with the right page verification. They still had the page verification set to “NONE”. These databases were not installed by me and I had not considered this to be set this way.
If you know anything about corruption you’ll know that this setting is crucial to find corruption in your database.
Due to the impact this could have I went to the application engineers and arranged a meeting with them. There was a reluctance to come to the meeting but it was important to discuss, so with upside down smiles they arrived 10 minutes too late to the meeting.
The following conversation took place:
Me: I did some investigating on a couple of databases and found that there are some settings that need changing. We’re now on SQL Server 2012 a we have databases with settings dating back to SQL 2000. One of the I found is that our main database is not being checked for corruption.
Application Engineer (AE) 1: How do you mean doesn’t get checked for corruption we do a weekly DBCC check don’t we?
Me: Yes we do but that has little use because the pages in the databases are not marked with a checksum. Besides it’s only once a week if we’re already doing it due to weekly and monthly processes. There is a setting that enables the verification of pages in the database and this helps us find corruption.
AE 2: Ok but do we need it? Why should we enable it?
Me: Just as I told you it’s for finding out if a corruption took place in the database. Any corruption in the database is a really bad thing and should be avoided at any cause. If we don’t enable this we’ll not know if there is any corruption in an early stage. We would only find the corruption if the page is severely corrupted or if someone accidentally selects the data. To ask you a question, do you want to vouch for a database which could potentially give you corrupt information?
AE 1: When was this setting first released and you still didn’t give an answer why we should enable this.
Me: You’re not listening to what I’m saying. The feature was first released back in SQL Server 2005 and was so important that Microsoft made it a default setting for all new databases. As I answered this question many times, we need this to find corruption at the earliest moment possible.
AE 1: What’s the downside to his? I don’t know if our processes will be hit if we change this.
Me: There is no downside, it’s a setting that helps us. The only thing it’s going to do is from this point on check all the data that’s written and create a checksum for it. The next time it’s being read, it will check the checksum with the page and see if it matches.
But I understand you, I want this setting to be enabled and tested thoroughly before we put it in production.
AE 1 and 2: I’m still not convinced.
Me: You know what I’ll do? I’ll setup a demonstration to show you how this process works and how easy it is to corrupt some data in a database. Based on that we can decide what to do from that point.
As you may read through the conversation I had to deal with people who were scared of change and were reluctant to listen to anything I told them. I still had to cooperate with them to get this change done so I moved on.
Like I said in the previous article, you have to have the facts to build your case and that was the reason I wanted to show them how a corruption could work and why this setting was so important.
I created a demo and did the presentation to the application engineers.
I showed them a healthy database, corrupted the database with the setting we’re currently using and we didn’t find the corruption. I did the same thing with a database with the new setting and of course it showed me the corruption.
The outcome was far from satisfying because they were still not convinced.
Up to this point, let’s check what went wrong:
- Strong arguments did not work
- Nobody cared about the fact that situation could actually happen.
Strong arguments did not work
Even with the evidence in front of them I couldn’t convince my colleagues. The question they asked my in the end was: “But how many times would this actually happen?”.
If I wanted to I could’ve just changed the setting and let nobody know. In previous testing I got no performance loss and had no other symptoms either.
But that’s not what I wanted to do. If something would go wrong for some reason I would get the blame and that wasn’t what I had in mind.
From this point on I should’ve gone higher up the chain of command to my manager.
Nobody cared about the fact that situation could actually happen.
This hit me right after I did the corruption demo, they didn’t care and as long as it all worked they were not going to keen on changing anything. I understand the last part because I don’t want to change that works, but this was different because we didn’t do any thorough checks.
You’ll never be able to convince these people. If you get to this point and you did all the work, laying out the facts (and even demos) than take your losses and go higher up.
I did everything but still they won’t listen
Ok, so this situation is an extreme one. I was not able to convince my colleagues and this was a scenario that I couldn’t have won.
Instead I went higher up the chain because in the end my supervisor would be responsible if something would go wrong. My supervisor first reacted the same way as my colleagues. To make sure I got my point across I went to the IT manager.
I explained the situation and showed him the possible downtime and how much it would cost if we didn’t put this setting in place.
In the end the IT manager was not pleased with the whole situation and my colleagues and supervisor were called in to explain their reasons. That last thing came back came back to bite me.
That didn’t stop me because if we didn’t put the setting in place I would have been responsible to fix everything even though my colleagues were the ones who decided not to change anything.
Like I said this situation was an extreme one. In normal circumstances, with people with right attitudes, this would never happen. I’ve had other situations where it was the opposite of this and that my colleagues would listen to reason.
In the end it was my responsibility to make sure the the data is protected. You’ll always have people who will not agree with you about something. In most situations you’ll be able to get them convinced with the cold hard facts.
If that still doesn’t work you have to go higher up the chain of command. I’ve always been rigorous when it came to my work and if someone was in the way of me doing my work properly I would go around them.
That doesn’t mean you have to do that all the time. Choose you battles wisely and put your effort where it would make the biggest impact for you to deliver the best work you can.