Some people are just born to live in a data center. Mark Crawford and computers have always been on the same wavelength. Being an IT guy "came naturally to me," he said.
During Mark Crawford's 22 years in the IT business, he's worked in application development, systems development and network design. "I prefer development over management, but I prefer mentoring over development," he said.
Today, Crawford gets to dabble in management, development, and mentoring. He's a network design specialist for health care insurance provider Keystone Health Plan Central (KHPC) in Camp Hill, Penn. For the past four years, Crawford's responsibilities at KHPC have included system design as well as network design and maintenance.
Crawford's decades of experience help him analyze, diagnose and resolve network problems quickly. Those skills are put to the test far too often because, despite all his know-how, he can't do the impossible and make his network 100% glitch-free.
One of those glitches caused KHPC users to flood the helpdesk with calls. Recounting the incident, Crawford described a connectivity issue that wreaked havoc at a remote site. The branch office in the Lehigh Valley, about 50 miles from KHPC's main office in Camp Hill, was connected to the main office by a T-1 line. Work in Lehigh Valley almost came to standstill when performance mysteriously faltered on the T-1 line.
Besides providing basic connectivity for e-mail, the T-1 line allowed the remote workers to use an application that accessed an Access database. Workers used the Access database was throughout the day. With a slow line, the database became nearly inaccessible. Frustrated, they called the helpdesk.
Because Crawford works closely with the KHPC network, he was immediately notified. That night, he stayed at the office analyzing the information the remote workers had given him. The clues led him to a hypothesis about the causes of the T-1 slowdown.
Before Crawford could divulge his suspicions about the cause of the T-1 glitch, he had to meet with KHPC's application development and help desk managers. He knew he had to follow office protocol and gather as much information as he could before suggesting a solution to the problem. He set up a meeting for early the next morning. The results of the meeting confirmed his analysis.
After the meeting, just to make sure he was right, Crawford used a network sniffer to see what was going across the T-1 each day. The evidence was clear: the network connection was slow because users were completely saturating the 1.5M byte T-1 line!
At this point, many IT managers may have indulged in finger-pointing, laying all the blame on the remote workers. Crawford's gut feeling, based on his experience, was that the problem resided in the system not the users. He began a second round of analysis, snooping around to find the root cause of the overload. That detective work paid off. He discovered that the Access database, not his users, was the real culprit.
KHPC's Access database is a non-client database, which means that whenever users query the database, the entire contents of the database are sent over the T-1 line. Even if one little piece of information is needed, the entire database still gets sent, Crawford said. This means that if 10 people are trying to access the database at one time, the line will become useless. Since the Access database contained nearly 1G bytes, it was no wonder that the line was saturated.
Finding the cause of the problem was tricky, but solving it was a real brain-teaser. Implementing a SQL database would be one solution. A SQL database is a client-server database, which only sends the needed information over a network connection. Unfortunately, Crawford said, "we didn't have the resources to rewrite the database into a SQL database."
Unable to change databases, Crawford tried a subtler approach to eliminating bandwidth saturation. He implemented a Meta frame client in all the remote users' desktops. Meta frame clients allow pictures of the data to go across the network, he explained. Essentially, he said, "the server does the work for you." Even though the Meta frames "cut the bandwidth down from 100% to 11%," he was still not satisfied.
Going for performance gold, Crawford tried another tactic. "I played around with the performance parameter in the network," he said. He tried to increase the buffer size to make the Access database data transfer more efficient. Once again, the results didn't meet his criteria.
Finally, Crawford decided that only a complete database re-haul would solve the issue permanently. "Ultimately, we had to rewrite the Access database" to only allow the needed information through the T-1 line, he said. This course of action wasn't the easy way out, but it did deliver the goods. Since re-hauled, bandwidth saturation hasn't been an issue for the remote office.
WE WANT TO HEAR FROM YOU!
>> Share your IT history and tips with us. Become a star in our IT Pro File series! E-mail Editor@searchWindowsManageability.com
>> Share your bloopers with us. You could win a prize! E-mail Editor@searchWindowsManageability.com