| Previous | Table of Contents | Next |
Earlier, when we were discussing data warehouses, we described the data-propagation tools used to move data from the operational database to the informational database. DataPropagator is one of those tools. DataPropagator also can be used between any DB2 databases, not just data warehouses.
In a distributed system environment, multiple copies of the same database file can exist on separate systems. A change to one copy is not immediately reflected in another copy. The same file can exist on many systems at a different level of update. DataPropagator provides a mechanism to replicate changes to a file on all systems. At some user-defined time interval, the changes for a particular file are replicated across all systems. Because this approach uses IBM’s replicator technology, the changes can be replicated across any DB2 database in the network.
With a single system, everything from the processing capabilities to the data itself must be contained on the system. There are, however, customers who have performance and capacity requirements beyond what is available with a single AS/400. Even with a network of systems, the overhead of the communications links will limit the amount of performance improvement that can be realized by splitting an application across multiple systems. OptiConnect may provide the answer to increased performance for such application and database processing. In Chapters 10 and 11, we look at the newest high-speed system interconnection, SAN. Only the AS/400e series supports SAN, so OptiConnect will be used for some time to connect multiple AS/400s.
OptiConnect is a product that allows AS/400s to be coupled together, via fiber optics, to achieve greater transaction processing power. Often, large AS/400 customers separate database processing from application processing and put the database on a server model of the AS/400. In this way, the separate systems are configured into a tiered processing cluster, with some machines dedicated to database processing and others dedicated to application processing.
OptiConnect uses DDM, but with an important difference. DDM in a network uses communications protocols across the communications lines or LANs. A communications protocol assumes transmission over a “noisy” line and builds layers of redundancy and checking into the transmission. This tends to reduce the speed at which the useful data is transmitted across the line. An optical bus connection is clean enough that most of this redundancy can be eliminated, thereby greatly enhancing the performance of the link. With OptiConnect, as few as 3 milliseconds are added to the time required to access the database on a remote system compared to the time it takes to access the local database. This is equivalent to increasing the access time of the disk drives on the local system by 3 milliseconds.
The exact performance improvement that results by splitting application and database operations varies depending on a number of factors, such as percent of database utilization. However, with the capability to include up to 32 machines in an OptiConnect cluster, it is safe to say that a very large configuration can be created.
OptiConnect can be used for more than just growth. The fiber-optics-based cabling system can replace existing LAN connections that use DDM to provide faster, more reliable network connections. OptiConnect also can be used between duplicate systems to create a high-availability and high-recovery option for critical applications and data.
We are now at a point where we can drop down a level and look at the internal implementation of the database functions. Following that, we will see how we can use a machine index to support many of the database operations we have just discussed.
As we saw in Chapter 3, implementation of the AS/400 database functions is split across the MI boundary. Most of the discussion in the previous sections has dealt with the database that is implemented as part of DB2/400 above the MI. In this section, we look at some of the MI system objects that are used by DB2/400. We will also see how some of the operations on these system objects are implemented in the SLIC below the MI. We don’t have space to describe in detail the implementation of all the database features and functions that have been covered so far in this chapter, but we will look at some of the more important ones. Following this, we will look at the implementation of the machine index the database and other AS/400 components use. We single out the machine index implementation not only because it is important to many AS/400 components, but also because it is an interesting structure to study.
The size of the database the SLIC supports is very large, as shown in the following list of maximum sizes:
I should point out that these database size limitations are imposed by the current SLIC implementation. The MI has no inherent limit on the size of the system objects, because it is technology independent. The SLIC is technology dependent, meaning field sizes in certain internal data structures have to be preassigned, which in turn defines certain upper limits. We will see some of these limits as we look at the internal implementations. As with any good design, there is some room built in for expansion should the need arise. Let’s start by looking at those MI system objects that support the database.
In the previous chapter, we introduced the three main system objects that support the database. These objects are data spaces, data-space indexes, and cursors. Like all the other system objects, they occupy multiple segments in the single-level store. Each has a base segment containing a segment header, an EPA header, and a customized header for the object. Each also has an associated space segment.
| Previous | Table of Contents | Next |