Does Your Database Crash Your LAN?
At first, users may think the new database app is the best thing yet. But they'll change their minds pretty quickly if the database and the network don't get on together.
The explosion of the corporate database has also amplified its impact on the corporate network. At one level, this looks like merely a traffic issue - bigger databases with access deployed to more users running increasingly complex queries means more stress on the LAN. But, there's more to it than that. Because the databases are larger, more complex and are deployed to more users, problems in the database architecture have greater impact on the network. And this has created an opportunity that network analysis specialist Network General is pursuing.
Network General believes that many corporate databases are designed with insufficient understanding of how the database and the network interact. Whether, for example, the design of the database creates traffic that is disproportionate to the information delivered. And that's not counting the myriad of levels at which client / server applications have to interact with the underlying infrastructure.
To most people, client / server consists of a bunch of PCs running applications that talk to a bunch of servers. This simplified model is one that has been promoted heavily by vendors and the press as part of the effort to e v a n g e 1 i s e client/server to the corporate sector. In reality, it's not that simple. For a start, the expression 'client / server' leaves out a vital component of the interaction - the network. In truth, every client / server system in existence is actually a 'client / network / server' system. This single extra element adds a suite of protocols which all client applications and all servers must embrace.
Add to this the fact that most systems have to embrace a multiplicity of clients (even where an IT shop is PC-only, it still has to cope with the constant migration of software versions), various networks, and complex server software, and you've got an environment that is inherently unstable. LAN administrators have long understood this, which is one of the things that has made Network General's Sniffer line of network analysers so common that the word 'sniffer' has almost become a generic term for anything that listens to the network. But, with a range of database decodes launched last year that now embraces Oracle, Sybase and Microsoft SQL Server, Network General is moving into new territory.
Its assumption is that a lot of databases out there are designed with too little regard for the network and therefore, an opportunity exists to improve the performance and reliability of the database using the technology that Network General can apply.
Layer upon layer upon....
To grasp just how complex the environment can become, consider an Oracle Forms application running on a Windows PC, and what lies between this and a TCP/IP network. The seven-layer OSI protocol (figure 1) illustrates this. Oracle Forms runs the application and includes some networking software, operating at the top of the model, the application layer.
Layer six, the presentation layer, deals with data presentation, character sets and data types. This is the TTC (two-task common) layer, which is included in all Oracle 7 application software. At layer five, the session layer, lies SQL*Net v2 (figure 2). This layer organises and synchronises the exchange of data between the client and the server application processes.
The TNS (transparent network substrate) is the lower layer of SQL*Net v2 that establishes, maintains and tears down client-to-server and server-to-server connections in Oracle 7. It resides on top of layer four, the transport layer that provides reliable connections between the two machines. TCP/IP is made up of two protocols covering layers four and three. At layer four, the transport layer, lies the transmission control protocol (TCP), while the Internet Protocol lies at the network layer, layer three. This layer involves routing and providing a path between source and destination.
The remaining layers, one (the physical layer) and two (the data link layer), operate in a similar fashion. The data link layer is specific to how the physical layer puts bits on the wire that carries communications, and detects and recovers errors that may occur on layer one. These two layers are provided by the network interface card installed in a PC. While each layer has a separate role, the result of them all working together is to provide reliable communications between clients and servers. They also help the user application (in this case, Oracle Forms) to communicate with the server application (Oracle7 Server). And, of course, many systems run on a heterogeneous network; for example, the client may be running SQL*Net v2 SPX while the server is running SQL*Net v2 TCP. In such environments, the Oracle Multiprotocol Interchange (MPI) is required to translate protocols (figure 3).
What does it all mean?
What it means is that even before you start designing the database itself, any environment (not just Oracle) will have a host of interfaces which can cause problems: incorrect installations, outdated drivers, mismatched protocol stacks, or systems that aren't fully aware of each other will all cause problems for users. Add to this a database design that places unnecessary stress on the network, and you have a situation tailor-made for finger-pointing between network administrators and system designers.
Please me and tell me if you liked my webpage on Oracle and LANs information, or even if you have any contributing sites on similar info that I can include here.
Click here to go back to my Technical Page
This page has been accessed
Last revised: Sunday, 06 April 1997