When IT pros troubleshoot they often have to think "outside the box" to find and solve a problem. Sometimes, however,...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
they get too creative in their thinking, overlooking the simple solution in favor of a grand scheme.
That's what happened to Neil Drinkall, a customer support engineer for a company that provides satellite tracking for fleets of vehicles. He installs, configures and supports software that clients use to track autos and run business reports. The software runs on Windows NT 4.0 and SQL Server 6.5.
One of the company's largest clients was having trouble running reports at a workstation 300 miles from its corresponding server. Drinkall made his way to the workstation and began troubleshooting.
"I determined that the speed of the server was causing the problem," he said. "The client machine was dialing in to the server using a 56K modem, and large amounts of data were causing the client software to time out before receiving a response from the SQL Server."
Easy enough, Drinkall thought, and he cleared the server of some old data and rebuilt the indexes. But reports still wouldn't run.
"Things were not looking good," he said.
Drinkall next used SQL Enterprise Manager to check the SQL Server configuration from the workstation and decided to allocate more memory to the SQL Server. He thought that surely would improve the server's performance. "It's something I have done successfully many times," he said.
Here's where doing the simple task correctly becomes important.
Any SQL database administrator knows that SQL memory levels come in 2MB increments. The workstation's configuration was set for the default 16MB, meaning 32MB of RAM were actually allocated for the SQL Server.
"In a moment of pure madness, I entered 64MB as the new memory setting, figuring I would use half of the 128MB of RAM available," Drinkall said. "I was thinking that would leave 64MB to run Windows NT."
Not realizing he actually had set the SQL Server to use 128MB, Drinkall restarted the system, and was greeted by the famous Windows blue screen. He booted up twice more. He got two more blue screens.
"As soon as the system started the SQL Server service, it grabbed all the memory and the machine would die," he said. "I had no way of getting it back up."
He had to recruit the customer's IT folks to visit the site and install more RAM in the server -- which took two days. "They were not particularly happy," he said.
Drinkall complicated a simple problem and sent customer satisfaction down the drain. The good news, however, is that the customer has been running reports smoothly ever since.