Administering federation

Administration tasks include modifying configuration settings, working with federated DDL, DML, stored procedures, nicknames, and more.

Modifying data source configurations
Over time you might find the need to modify the data source configurations for your federated system. For example, if your data sources change, you might need to update server definitions, nicknames, and user mappings. You might also need to add or remove access to data sources from your federated system.
Data types and data type mappings
Data type mappings associate the federated database data types with the data types at the data source. This association allows the federated server to retrieve data from the data source.
Mapping functions and user-defined functions
Function mappings associate federated server functions and user-defined functions with the existing functions at the data source.
Creating index specifications
For relational data sources, create index specifications to store information about the columns of remote indexes in the global catalog and to ensure optimal performance of search queries.
Developing federated procedures
Federated procedures enable you to invoke procedures at a data source as if the remote procedure is a local procedure.
Creating and modifying remote tables by using transparent DDL
With transparent DDL, you can use procedures that you are familiar with to create and modify remote tables by using the federated database without using a pass-through session.
Managing transactions in a federated system
Federated system transaction processing allows you to read and update databases in a single transaction while maintaining the consistency of the data. Federated systems support single-phase and two-phase commit protocols. When you administer your federated system, you must set up the appropriate protocol.
Inserting, updating, and deleting data in a federated system
During the development of your federated environment, whether you modify remote information or move data among data sources, you must insert, update, and delete data on your data sources.
Authorization privileges for INSERT, UPDATE, and DELETE statements
The privileges required to issue INSERT, UPDATE, and DELETE statements on nicknames are similar to the privileges required to issue these same statements on tables. In addition, you must hold adequate privileges on the data source to perform select, insert, update, and delete operations on the underlying object.
Federated system INSERT, UPDATE, and DELETE restrictions
Some restrictions apply to using INSERT, UPDATE, or DELETE statements in a federated system.
Referential integrity in a federated system
In a federated system, the federated database does not enforce referential integrity among data sources.
INSERT, UPDATE, and DELETE statements and large objects (LOBs)
You can run read operations on remote large objects (LOBs) on federated systems. Write operations on LOBs are supported for some data sources.
Preserving statement atomicity in a federated system
During update operations, federated systems always attempt to keep data in an atomic state at the completion of a DML statement. When data is in an atomic state, it is guaranteed to either be successfully processed or to remain unchanged.
Modifying data in a federated system
You can modify data in a federated system by inserting, updating, and deleting data in data source objects.
Assignment semantics in a federated system
When you assign data to a nickname column, the data type might change based on the assignment rules that the federated system uses. You should understand the assignment rules so you get the results that you expect.
Data source restrictions on data type values
For some data types, the federated server supports a wider range of values than the data source.
Federated updates with application savepoints
Application savepoints in a federated system help you control the work that is performed by a subset of SQL statements in a transaction.
Federated updates with application savepoints - examples
This example of application savepoints illustrates the effect of rollback operations within nested savepoints.
Restrictions on federated updates with application savepoints
Federated systems impose some restrictions on savepoint operations.
Importing and exporting data for nicknames
You can use the IMPORT command to import data into a nickname and the EXPORT command to export data from a query that references a nickname.
Working with nicknames
A nickname is an identifier that an application uses to reference a data source object, such as a table or view. In a federated system, you use can nicknames to access data source objects and improve the performance of queries on remote data sources.
Federated three-part names
With federated three-part names, you can reference remote objects directly. When you reference remote objects directly, you do not need to create nicknames for the remote objects.
Working with remote XML data
Federation supports the remote XML data type that gives you the ability to access and manipulate XML data in a database.
Error tolerance in nested table expressions
Error tolerance is a mechanism that allows query execution to continue while tolerating certain SQL errors in nested table expressions. With error tolerance, instead of receiving an error for a part of a query and terminating the entire query, you can obtain maximum query results from available data.
High availability for federation
Federation provides a high availability feature. High availability disaster recovery (HADR) is a database replication feature that protects against data loss by replicating data changes from a source database to a target database.
Monitoring federated servers and nicknames
You can use the health monitor and systems monitor elements to monitor a federated system.