Call In The Experts
-
Since my data center move last weekend the servers seemed a touch slow. Actually once I checked the mail server I noticed it was substantially slower.
Of course with my 100kbps connection on Sunday and Monday, everything seemed slow to me. I solved that DSL problem noting that the satellite receiver didn't have a filter on it. Once I fixed that, the site was slow, but it was useable. I still wasn't sure that it was me.
But I got a few emails from people, so I called my network guy because I wanted him to check things. He said he'd be happy to meet me at lunch to check things since we didn't have remote switch access (yet).
So we meet at lunch, me with a couple extra cables just in case. We log in and immediately see that there are tons of CRC errors coming from the switch to the firewall. He knows what it is: duplex mismatch. We open the cage, use a serial cable to connect, and see that the switch is set to 100 full and the firewall is auto. Apparently the negotiation when things don't match drops to 10Mbps half duplex and can generate lots of CRC errors. We reset it and things are running quicker now.
The point of this editorial isn't so much that I'm an idiot about networking or that you should check your switches and NICs to be sure that they are set to match, but more that you should know what you don't know.
And quickly call someone in.
It's one thing to try to figure things out yourself, work through issues and learn on the go, but you should know the limits of your knowledge. In most areas I can quickly tell when I don't know something and should just ask. But even in SQL Server I usually have a feel within an hour if I can solve the problem or I'm out of my league. And when I am, I call support or a consultant to help.
Too often I see people beat on a problem for too long without calling in help. Sometimes they call too soon, but usually they work a problem too long because they are afraid to ask for help. Maybe they think they'll look bad or the boss will wonder why he's paying them. I don't think it's a knock against you to call for help periodically. I've been a DBA a long time and it hasn't hurt me.
In any case, knowing what you don't know is a valuable skill. One I'd highly recommend you learn.
Steve Jones
-
I totally agree with this. In 20 years in IT I have never sacked anyone for not knowing something but I have sacked people for not asking.
You can always teach someone something they don't know, if they just blindly blunder on being ineffective but saying everything is OK then it has an impact on the whole team and project
Pete -
We had a similar problem a couple of months ago when our feed was accidentally changed from 100 to 10, it was annoying because it took us around 4 hours to work out that was the problem and another day to have it resolved by the hosting centre.
Very annoying but like us next time you'll know what it probably is straight away, I agree that it's best to ask for help when it's needed but always find out what the problem was and what was done to fix it, that way you benefit from the experience too.
-
In small companies or departments it is important to follow this advise. But in large companies or organizations it can be a political football. In my experience the database is seldom the problem, it is usually network, server, workstation or OS. Working through a problem that users identify is an exercise in finger pointing, because the users is almost always wrong. The manager or vp of the affected user is all over the DBA because of the problem, because it shows up in application response or lack of, after doing as much as humanly possible, proving the problem is elsewhere, in most meetings it remains the DBA's fault due to the initial user thinking the problem is application or database related. Most of the sys admin and network dudes try to keep as much info to themselves, so no one else can fix the problem should it arise again and they must have discovered long ago that if you are identified with a problem, you are the problem. When will we all grow up!
-
For years our company has had a SOP to manually set speed/duplex on all machines. Auto detect cannot be trusted.
Interestingly auto detect is more likely to work if the unit is physically unplugged, not just turned off. Even a cold boot does not always initiate the full handshake protocol.
...
-- FORTRAN manual for Xerox Computers --
-
I think this is an area I need some work at... Although, I think the problem I have is not wanting to ask for help, but not having a more knowledgeable individual in house to go to for help, and none of the other IT people know this stuff either. (Speaking of MSSQL/PHP primarily)
I don't have a real problem going online to get help, but in the past the questions I've asked sometimes take days to get answers. What are some of your favorite/respected/timely online resourses?
Are there any 'live' online help sites where I could chat with individuals and ask the questions as they come up? (Note: IRC is blocked, or severly limited)
Thanks,
Steve (DBA in my dreams) :0)
-
I think the real issue is the fact that IT people (aka: programmers and dbas) are curious, problem solvers by nature. Thus when a problem arises they go into problem solving mode and will work a problem, and work it, and work it. Saying give tends to be hard because the answer to the problem seems so close, yet so far away. In my 20+ years in IT, I have found that maturity of an individual (whether by fire or age) allows them to identify when they are out of their knowledge space, back away from the problem and seek help. True knowledge is the realization of not what you know, but how much you don’t know.
Page
-
When we moved our office we switched from DSL to a fiber/coax solution with the local cable carrier, Cox.
The service has been rock solid but setup wasn't.
For example - Cox hires a local contractor to do wiring and quite honestly I wouldn't give you a dime for that contractors services. For example, they committed the ultimate sin - wiring stranded connectors onto solid conductor wire.
So first we had the 100-Mbps vs. Auto issue that was quickly resolved but we were still seeing errors. Me being the global picture guy said that it was the poor termination. Sure enough - once the end was replaced the CRC errors went away.
Now don't ask me about Verzion. They completely dropped the ball.
-
> In any case, knowing what you don't know is a valuable skill. One I'd highly recommend you learn.
In a previous job, I had a network user who didn't know what he didn't know, and repeatedly managed to screw up his machine. Between troubleshooting, virus cleanup, software reinstallation, and hardware replacement, over a period of a year or so I spent more time working on his computer alone than on the other 30-some computers in our agency put together.
Viewing 9 posts - 1 through 8 (of 8 total)
You must be logged in to reply to this topic. Login to reply