Skip Navigation Links | |
Exit Print View | |
Oracle Directory Server Enterprise Edition Administration Guide 11g Release 1 (11.1.1.5.0) |
Part I Directory Server Administration
2. Directory Server Instances and Suffixes
3. Directory Server Configuration
6. Directory Server Access Control
7. Directory Server Password Policy
8. Directory Server Backup and Restore
9. Directory Server Groups, Roles, and CoS
10. Directory Server Replication
To Fix Schema Compliance Problems
Extending Directory Server Schema
Extending Schema With a Custom Schema File
To Extend Schema With a Custom Schema File
When Creating Custom Schema Files
Extending Schema Using a Schema File and Replication
To Extend Schema Using a Schema File and Replication
Default Directory Server Schema
Naming Attributes and Object Classes
When Defining New Object Classes
Managing Attribute Types Over LDAP
Managing Object Classes Over LDAP
13. Directory Server Attribute Value Uniqueness
15. Directory Server Monitoring
Part II Directory Proxy Server Administration
16. Directory Proxy Server Tools
17. Directory Proxy Server Instances
19. Directory Proxy Server Certificates
20. Directory Proxy Server Load Balancing and Client Affinity
21. Directory Proxy Server Distribution
22. Directory Proxy Server Virtualization
23. Virtual Data Transformations
24. Connections Between Directory Proxy Server and Back-End LDAP Servers
25. Connections Between Clients and Directory Proxy Server
26. Directory Proxy Server Client Authentication
27. Directory Proxy Server Logging
28. Directory Proxy Server Monitoring and Alerts
Part III Directory Service Control Center Administration
Whenever you configure the replication of one or more suffixes between two servers, schema definitions are automatically replicated as well. The automatic replication of schema definitions ensures that all replicas have a complete, identical schema that defines all object classes and attributes that can be replicated to the consumers. Master servers therefore also contain the master schema.
However, schema replication is not instantaneous, even when you modify schema over LDAP. Schema replication is triggered either by updates to directory data or at the start of the first replication session after the schema is modified.
To enforce the schema on all replicas, you must at least enable schema checking on all masters. As the schema is checked on the master where the LDAP operation is performed, the schema does not need to be checked when updating the consumer. To improve performance, the replication mechanism bypasses schema checking on consumer replicas.
Note - Do not turn off schema checking on hubs and dedicated consumers. Schema checking has no performance impact on a consumer. Keep schema checking on to indicate that the replica contents conform to its schema.
Master servers replicate the schema automatically to their consumers during consumer initialization. Master servers also replicate the schema automatically any time the schema is modified through DSCC or through the command-line tools. By default, the entire schema is replicated. Any additional schema elements that do not yet exist on the consumer are created on the consumer and stored in the 99user.ldif file.
For example, assume that a master server contains schema definitions in the 98mySchema.ldif file when the server is started. Also assume that you then define replication agreements to other servers, either masters, hubs, or dedicated consumers. When you subsequently initialize the replicas from this master, the replicated schema contains the definitions from 98mySchema.ldif, but the definitions are stored in 99user.ldif on the replica servers.
After the schema has been replicated during consumer initialization, modifying the schema in cn=schema on the master also replicates the entire schema to the consumer. Therefore, any modifications to the master schema through the command-line utilities or through DSCC are replicated to the consumers. These modifications are stored in 99user.ldif on the master, and by the same mechanism as described previously, the modifications are also stored in 99user.ldif on the consumers.
Consider the following guidelines for maintaining consistent schema in a replicated environment:
Do not modify the schema on a consumer server.
Modifications to the schema on the consumer server can cause replication errors. This is because differences in the schema on the consumer can result in updates from the supplier not conforming to schema on the consumer.
In a multimaster replication environment, modify schema on a single master server.
When you modify the schema on two master servers, the master most recently updated propagates its version of the schema to the consumer. The schema on the consumer might then become inconsistent with the schema on the other master.
When configuring fractional replication, also consider the following guidelines:
As schema is pushed by suppliers in fractional replication configurations, schema on a fractional consumer replica are a copy of the master replica’s schema. Therefore, schema might not correspond to the fractional replication configuration being applied.
In general, Directory Server replicates all required attributes for each entry as defined in the schema to avoid schema violations. When you configure fractional replication to filter out required attributes, you must disable schema checking.
If schema checking is enabled with fractional replication, you might not be able to initialize the replica offline. Directory Server does not allow you to load data from LDIF if required attributes are filtered out.
If you have disabled schema checking on a fractional consumer replica, schema checking is not enforced on the whole server instance on which that fractional consumer replica resides. As a result, avoid configuring supplier replicas on the same server instance as a fractional consumer.
By default, whenever the replication mechanism replicates the schema, it sends the entire schema to its consumers. In the following situation, it is not desirable to send the entire schema to consumers:
Modifications to cn=schema using DSCC or from the command-line are limited to the user-defined schema elements, and all of the standard schema are unchanged. If you modify the schema often, sending the large set of unchanged schema elements every time has a performance impact. You might be able to improve replication and server performance by replicating only the user-defined schema elements.
You cannot use DSCC to perform this task. Use the command line, as described in this procedure.
$ dsconf set-server-prop -h host -p port repl-user-schema-enabled:on
The default value, off, causes the entire schema to be replicated when necessary.