Network considerations for a distributed relational database
The design of a network directly affects the performance of a distributed relational database.
To properly design a distributed relational database that works well with a particular network, do the following things:
- Because the line speed can be very important to application performance,
provide sufficient capacity at the appropriate places in the network to achieve efficient performance to the main distributed relational database applications.
- Evaluate the available communication hardware and software and, if necessary,
your ability to upgrade.
- For Advanced Program-to-Program Communication (APPC) connections, consider the session limits and conversation limits specified when the network is defined.
- Identify the hardware, software, and communication equipment needed (for both test and production environments), and the best configuration of the equipment for a distributed relational database network.
- Consider the skills that are necessary to support TCP/IP as opposed to those that are necessary to support APPC.
- Take into consideration the initial service level agreements with end user groups (such as what response time to expect for a given distributed relational database application), and strategies for monitoring and tuning the actual service provided.
- Understand that you cannot use an APPC-protected DUW conversation to connect to a database from an application requester (AR) which has been set to an auxiliary storage pool (ASP) group for the current thread.
- Develop a naming strategy for database objects in the distributed relational database and for each location in the distributed relational database. A location is a specific relational database management system in an interconnected network of relational database management systems that participate in distributed relational database. A location in this sense can also be a user database in a system configured with independent ASP groups. Consider the following items when developing this strategy:
- The fully qualified name of an object in a distributed database has three (rather than two) parts, and the highest-level qualifier identifies the location of the object.
- Each location in a distributed relational database should be given a unique identification; each object in the database should also have a unique identification.
Duplicate identifications can cause serious problems. For example, duplicate locations and object names might cause an application to connect to an unintended remote database, and once connected, access an unintended object. Pay particular attention to naming when networks are coupled.
- Each location in a user database should also be given a unique identification. If a user database on two different systems were to be named PAYROLL, there would be a naming conflict if an application needed to access them both from the same system. When an independent ASP device is configured, the user has an option to specify an RDB name for that device that is different from the name of the ASP device itself. It is the RDB name associated with the primary device in an ASP group by which that user database is known.
- The fully qualified name of an object in a distributed database has three (rather than two) parts, and the highest-level qualifier identifies the location of the object.
Parent topic:
Designing the application, network, and data for a distributed relational database
