You can use the change management function in Optim™ Database
Administrator to
create, alter, and drop wrappers, server definitions, user mappings,
nicknames, and federated stored procedures.
Overview of federated systems
The various
organizations in a large enterprise often use different database management
systems to store and access their data. A federated system transparently
unifies the information from the various sources, which allows the
enterprise to use the full value of the data.
A federated
system is a special type of distributed database management system. A
federated system consists of a DB2® instance
that operates as a federated server, a database that acts as the federated
database, one or more data sources, and clients (users and applications)
that access the database and data sources.
The DB2 sever in a federated system is referred to
as the federated server. Any number of DB2 instances can be configured to function as
a federated server. The DB2 instance
that manages the federated system is called a server because it responds
to requests from users and client applications. Users and applications
interface with the federated database that is managed by the
federated server.
A federated system is typically created on
a DB2 for Linux, UNIX,
or Windows system by:
- Updating the database manager configuration properties for SVCENAME
and FEDERATED.
- Creating a DB2 database
to manage federated access.
- Installing any prerequisite software that is required by the target
data sources, and configuring network access to the systems on which
those data sources reside.
- Creating wrapper, server, and user mapping objects for each data
source that is to be accessed.
- Creating nicknames for the objects that are to be accessed at
each data source.
Supported federated objects and data sources
With
Optim Database
Administrator,
you can create, alter, and drop wrappers, server definitions, user
mappings, nicknames, and federated stored procedures:
- Wrappers
- The mechanism that the federated database uses to connect to and
retrieve data from a data source. A wrapper must be created for each
type of data source that is to be accessed.
- Server definitions
- Information that identifies and defines the data source to the
federated database.
- User mappings
- The association between the authorization ID on the federated
server and the information that is required to connect to the remote
data source. The user ID and passwords that you use to access the
federated server are mapped to the user ID and password that you use
to access the data source server.
- Nicknames
- A local name that you create to identify each object at the data
source that you want to access. The object that the nickname identifies
is referred to as a data source object.
Table 1. Data source
objects that can have nicknamesData source |
Object |
DB2 for Linux, UNIX, and Windows |
Nicknames, materialized query tables, tables,
and views |
DB2 for System i® |
Tables, views P/L (physical/logical files and
table types |
DB2 for
VM and VSE |
Tables and views |
DB2 for z/OS® |
Tables and views |
- Federated stored procedures
- A local stored procedure that is mapped to a stored procedure
at the data source.
When creating these objects for a federated
system, you must create the objects in the following order:
- The wrapper
- The server definition
- The user mapping
- The nicknames and federated stored procedures
The definitions of the federated objects are stored in the federated
database.
Restriction: You can define and deploy
changes for these supported federated objects only for data sources
that use DRDA® wrappers, which
means the DB2 family of products.
The DB2 family of products includes: DB2 for Linux, UNIX, and Windows; DB2 for System i, DB2 for
VM and VSE, and DB2 for z/OS.
Generated change commands for federated objects
As
with any changes that you make by using the change management feature,
you generate change commands for your federated object changes that
you then run against the federated system.
When you alter a
nickname, an ALTER NICKNAME statement is generated only if you change
the constraint for the nickname or change the data type of the column.
For all other nickname changes, a DROP NICKNAME statement and a CREATE
NICKNAME statement are created.
Data preservation
and data maintenance commands are not included in the generated change
commands. Data does not need to be preserved because the federated
object changes do not affect remote tables. You can use always update
statistics by using the utility actions that are available by right-clicking
an object in the Object List.