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 servers were to be named PAYROLL, there
would be a naming conflict if an application needed to access them both from
the same server. Note that 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.