Why Identical Definitions are Useful
Maintaining entities with identical definitions can be useful in situations such as the following:
How to Maintain Identical Definitions
To maintain identically defined entities, you must explicitly specify physical attributes whose values would otherwise be automatically assigned when the entity is created or altered. The physical attributes that must be explicitly specified for this purpose are:
The appropriate DDL statements (such as CREATE TABLE, ALTER AREA, and so on) provide clauses for the specification of these physical attributes.
Determining the Physical Attributes of Existing Entities
You can determine the values of the physical attributes assigned to an existing entity by specifying either FULL PHYSICAL or WITH TIMESTAMP on a DISPLAY or PUNCH statement for the entity. The FULL PHYSICAL option generates syntax for all attributes of an entity including physical attributes such as table IDs and synchronization stamps. The WITH TIMESTAMP option generates only the syntax for specifying a synchronization timestamp.
If you display a schema specifying FULL PHYSICAL, syntax is generated for all entities in the schema. The syntax includes specifications for all physical attributes of those entities. A final set of ALTER statements is generated to establish the value for the synchronization timestamp for all entities that have one.
Note: For more information about these clauses and the syntax used to specify physical attributes, see the SQL Reference Guide.
Specifying Synchronization Timestamps
While the ability to specify physical attributes can be useful in certain situations, it should be used with care. If you change the value of a synchronization timestamp, you can disable the ability for the database engine to detect definition-based changes. This could result in data corruption if an out-of-date access module updates the database.
At a minimum, you should ensure that every version of an entity's definition has a unique synchronization timestamp associated with it. You should also be aware that while some entities, such as indexes and constraints, do not have an associated timestamp, changing their definition is, in effect, changing the definition of their associated table(s) and must also result in a unique sychronization stamp value.
If a table resides in an area that is controlled by area-level synchronization stamps, you must update the area's synchronization timestamp. Updating the table's synchronization stamp is optional but recommended. If a table resides in an area that is controlled by table-level synchronization stamps, you must update the table's stamp and cannot update that of the area.
Specifying Table and Index IDs
It is not always possible to create a table with a specific table ID or an index with a specific index ID. You are able to do so only if the value specified is not assigned to another table or index in the same area. Consequently, manipulation of physical attributes is generally only appropriate for schemas that define the entire contents of a database area or segment.
Stamp Synchronization
The SYNCHRONIZE STAMPS utility lets you compare stamps in the data area and the catalog and to update one from the other.
This utility provides an alternative mechanism for maintaining identical synchronization timestamps and may be an aid in recovery situations in which either the catalog or a data area must be restored independently of the other.
For example, suppose that you want to take a copy of a production database for testing purposes. Assuming that the definitions of both are identical except for the synchronization timestamps, you can use operating system facilities for copying the data files and then use the SYNCHRONIZE STAMPS utility to update the copied areas with the timestamps from the test catalog.
Note: For more information about the SYNCHRONIZE STAMPS utility, see the CA IDMS Utilities Guide.
|
Copyright © 2014 CA.
All rights reserved.
|
|