Previous Next Contents Index


Chapter 4 Managing Directory Server Databases

The directory managed by your directory server is contained in a database. This chapter describes the procedures you use to manage your database in the following sections:


Managing Databases Using LDIF
You can use the LDAP Data Interchange Format (LDIF) to import and export database entries into and out of the directory server. You can also back up your databases by exporting to an LDIF file. These topics are described in:

For a description of LDIF, see Chapter  2, "LDAP Data Interchange Format."

Exporting Databases to LDIF

Exporting your database to LDIF can be useful if you want to back up your database, copy your database to another directory server, export your database to another application, or add an index setting for a currently existing attribute. You can export your database to LDIF either by using the Directory Server Console, or by using the slapd (Windows NT) or ns-slapd (Unix) command-line utility. This section describes both these methods in the following sections:

Exporting to LDIF Using the Server Console

To export your database to LDIF from the Directory Server Console:

  1. On the Directory Server Console select the Configuration tab.

  2. From the Console menu select Export.

    3. The Export Database dialog box displays.

  3. If you are running the Directory Server Console on the server's host machine, skip to Step  4. Otherwise, if you want to export to a file on the local machine, select "Local machine". To export to a file on the server's host, select "Server machine."

  4. Enter the full path and filename you want the server to use to store the LDIF file in the text box provided.

    5. Netscape recommends that you use the <NSHOME>/slapd-<serverID>/ldif directory on the server's host machine to store LDIF files.

  5. If you want to export the whole directory, select the "Entire database" radio button. If you want to export only a single suffix or a particular subtree, select the Subtree radio button and then enter the suffix or subtree you want to export in the Subtree text box. You can also click Browse to select a suffix or subtree.

  6. Click OK.
Exporting to LDIF From the Command Line

You can export your database to LDIF using the slapd (Windows NT) or ns-slapd (Unix) command-line utility with the db2ldif keyword. For information on where you can find the command line utilities, see "Finding the Command-Line Utilities".

Use one of the following syntaxes to export your database to LDIF from the command-line. Parameters in brackets [ ] are optional.

On Windows NT:

slapd db2ldif -f <slapd.conf> -a  <output_file> [-d  <debug_level> -n -r -s <include_suffix> -x  <exclude_suffix>]

On Unix:

ns-slapd db2ldif -f <slapd.conf> -a  <output_file> [-d  <debug_level> -n -r -s <include_suffix> -x  <exclude_suffix>]

where <slapd.conf> is the location of your configuration file. The slapd.conf file is under <NSHOME>/slapd-<serverID>/config. Enter the full path to the slapd.conf file you want to use.

ns-slapd and slapd Parameters for Exporting Databases

-a. Defines the output file in which the server saves the exported LDIF. This file is stored by default in the directory where the command-line utility resides.

-d. (Optional) Specifies the debug level to use during the db2ldif runtime. Debug levels are defined in "Log Level".

-f. Specifies the slapd.conf configuration file to use for the conversion process. Use the full path to the slapd.conf file with this argument. For information on where to find directory server configuration files, see "Directory Server Configuration Files".

-n. (Optional) Specifies that entry IDs are not to be included in the LDIF output. The entry IDs are necessary only if the db2ldif output is to be used as input to db2index.

-r. (Optional) If you intend to import the LDIF file into a consumer server, you must specify this argument. -r causes the server to include the copiedFrom attribute and its contents in the LDIF output. The replication process requires this information. If you use -r, you also need to specify the suffix you want exported using the -s option. You must shut down the server before exporting using this option.

-s. (Optional) Specifies the suffix or suffixes to include in the export. You may use multiple -s arguments. This parameter is optional. If you do not specify -s or -x, the server exports all suffixes within the database. If you use both -x and -s arguments with the same suffix, the -x operation takes precedence. Exclusion always takes precedence over inclusion. If you exclude one or more suffixes from the exported LDIF file, and you intend to import the LDIF file into your configuration directory, do not exclude o=NetscapeRoot. Also, if you use -s to specify a suffix to include, and you intend to import the LDIF file into your configuration directory, make sure that you also use -s to include o=NetscapeRoot.

-x. (Optional) Specifies a suffix or suffixes to exclude in the export. You may use multiple -x arguments. This parameter is optional. If you do not specify -s or -x, the server exports all suffixes within the database. If you use both -x and -s arguments with the same suffix, the -x operation takes precedence. Exclusion always takes precedence over inclusion. If you intend to import the LDIF file into your configuration directory, do not exclude o=NetscapeRoot.

Database to LDIF Examples

Windows NT:

slapd db2ldif -f  c:\Netscape\Server4\slapd-dirserver\config\slapd.conf -a  output.ldif -s  "o=airius.com" -s  "o=NetscapeRoot"

Unix:

ns-slapd db2ldif -f  /usr/Netscape/Server4/slapd-dirserver/config/slapd.conf -a  output.ldif -s  o=airius.com -s  "o=NetscapeRoot"

Importing Databases From LDIF

You can import LDIF files into your database from the Directory Server Console or by using the slapd (Windows NT) or ns-slapd (Unix) command-line utility with the ldif2db keyword. This section describes both these methods. You can also import LDIF files using the ldif2db script.

When you import an LDIF file using the ldif2db script or by specifying the "Overwrite Entire Database" option (with "Preserve Configuration") through the Server Console, a snapshot of o=NetscapeRoot is saved to a file and stored in <NSHOME>/slapd-<serverID>/confbak. If you need to, you can restore the configuration information in the directory by importing the most recent file in this directory. The files are named according to the date on which the import took place as follows:

YYYY_MM_DD_HHMMSS.ldif

For example, if the file was saved at 42 seconds past 10 PM on July 30, 1998, it would be named:

1998_07_30_224244.ldif

In most cases, you will want to add the configuration information to the existing data instead of overwriting your existing data. To do this from the Directory Server Console, when you import the LDIF file, clear the "Overwrite Entire Database" option on the Import dialog box. You can also use ldapmodify as follows:

ldapmodify -D "<BindDN>" -w <BindDN password> -c -a -f  <NSHOME>/slapd-<serverID>/confbak/filename.ldif

For example,

ldapmodify -D "cn=directory manager"
-w mypassword -c -a -f /Netscape/Server4/slapd-mydirserver/confbak/1998_07_30_224244.ldif

For better performance, you should use the server console to import an LDIF file only if the LDIF file contains a relatively small number of entries (less than 10,000), or if you are importing and overwriting the existing database. Otherwise, you should use the command line. This section describes:

Importing LDIF From the Server Console

You can use the Directory Server Console to import the LDIF file into a directory server database using the Import command. For best performance, you should use the server console to import an LDIF file only if the LDIF file contains a relatively small number of directory entries (less than 10,000), or if you intend to overwrite the existing database. Otherwise, you should use the command-line. For more information, see "Importing LDIF From the Command Line".

Note. You cannot import an LDIF file that contains a root entry unless you bind to the directory as the Root DN (Directory Manager). This is because access to the root entry, for example o=airius.com, is denied to everyone except the Directory Manager (Root DN).

To import LDIF using the Directory Server Console:

  1. On the Directory Server Console select the Configuration tab.

  2. From the Console menu, select Import. This displays the Import Database dialog box.

  3. If you are running the Directory Server Console on the server's host machine, skip to Step  4. Otherwise, if you want to import a file from the local machine, select "From local machine". If you want to import a file from the server's host, select "From server machine."

  4. Enter the full path to the LDIF file in the field provided.

    5. If you chose to import a file from the local machine, or if you are running the Directory Server Console on the server's host machine, you can also click Browse to select the file you want to import.

  5. Select the import method you want the server to use. There are two options:

    6. Overwrite Entire Database. You can only choose this option if you chose to import a file on the server's host (in Step  3) or if you are running the Directory Server Console on the server's host machine. When you import using this option, the server deletes the entire contents of the database and imports the LDIF file. If you do not want the server to overwrite the o=NetscapeRoot suffix, select the Preserve Configuration checkbox.

    If the directory server is running, you are prompted to shut it down.The server must be shut down before you can import using this option.

    Warning! The Netscape Administration Server uses the o=NetscapeRoot suffix to store information about installed Netscape Servers. Deleting this suffix could force you to reinstall all of your Netscape 4.x servers, including the directory server. Netscape strongly recommends you choose to preserve this configuration unless directed otherwise by Netscape Technical Support or other procedures outlined in the directory server documentation.

    Append Data to Database. When you import using this option, the server does not delete the contents of the directory before adding the entries from the LDIF file. You should only use this option if you are importing an LDIF file with a relatively small number of entries (less than 10,000). The server must be running to use this option.

    You cannot import an LDIF file that creates a root entry (such as o=airius.com) using the "Append Data to Database" option unless you bind to the directory as the root DN, for example, cn=Directory Manager. Instead, you must use the "Overwrite Entire Database" option.

    The optional settings you can specify include:

  6. Click OK.
The server performs the import and also creates indexes. (For more information on indexes and index creation, refer to Chapter  7, "Managing Indexes.")

Importing LDIF From the Command Line

You can replace the contents of your ldbm database file with an LDIF file using the slapd (Windows NT) or ns-slapd (Unix) command-line utility with the ldif2db keyword. These utilities create the database in the location specified in the "directory" parameter in your slapd.ldbm.conf file and create the index files that are specified in the slapd.ldbm.conf "Attribute to be Indexed" parameter.

For more information, see the "Database" parameter and the "Attribute to be Indexed" parameter in Chapter  17, "Configuration Parameters."

For information on where you can find the command-line utilities in your directory server installation, see "Finding the Command-Line Utilities".

Warning! Importing LDIF files using ns-slapd or slapd deletes your existing database files and creates new ones. The Netscape Administration Server uses the o=NetscapeRoot suffix to store information about installed Netscape Servers. If you are importing the LDIF file into your configuration directory, make sure this suffix and its contents are included in your LDIF file before you import. If you do not, you may have to reinstall (or restore from backup) all of your Netscape 4.x servers, including the directory server.

To import LDIF from the command line:

  1. From the command line, change to <NSHOME>/slapd-<serverID>/db. Where <NSHOME> is the directory where you installed the directory server and <serverID> is the name of your directory server. The directory server database must be stored in this directory.

  2. Make a backup of all the files in the db directory. Although you can delete the files, you may want to move them to a backup location instead, because deleting these files deletes your directory database.

  3. Change to <NSHOME>/bin/slapd/server.

  4. Run the slapd (Windows NT) or ns-slapd (Unix) command-line utility as follows. Parameters in brackets [ ] are optional.

    5. Windows NT:

    slapd ldif2db -f  <slapd.conf> -C -i  <ldif_file> [-d  <debug_level> -n  <backend_number> -O -s  <include_suffix> -x  <exclude_suffix>]

    Unix:

    ns-slapd ldif2db -f  <slapd.conf> -C -i  <ldif_file> [-d  <debug_level> -n  <backend_number> -O -s  <include_suffix> -x  <exclude_suffix>]

    where <ldif_file> is the name of the file containing the LDIF to be imported and <slapd.conf> is the location of your configuration file. You can find a demo LDIF file under <NSHOME>/slapd-<serverID>/ldif. The slapd.conf file is under <NSHOME>/slapd-<serverID>/config. Enter the full path to the slapd.conf file you want to use.

slapd Parameters Used for LDIF Imports

The following ldif2db parameters are used to complete an LDIF file import:

-C. Required. Used internally by the Directory Server.

-d. Optional. Specifies the debug level to use during runtime. Debug levels are defined in "Log Level".

-f. Specifies the slapd.conf file to use for the import process. This parameter is required. For information on where to find directory server configuration files, see "Directory Server Configuration Files".

-i. Specifies the LDIF file to be imported. This parameter is required. You can use multiple -i arguments to import more than one LDIF file at a time. When you import multiple files, the server imports the LDIF files in the order in which you specify them from the command line.

-n. Optional. Specifies the database in your slapd.conf file for which the conversion is performed. If this parameter is not specified, then the server uses the first database defined in the slapd.conf file.

-O. Optional. When you use this argument, no attribute indexes are created for the imported database. If you specify this option and you want to restore the indexes later, you will need to recreate the indexes by hand. See Chapter  7, "Managing Indexes," for more information.

-s. Optional. Specifies the suffix or suffixes within the LDIF file you want to import. If you use -s to specify a suffix to include, and you are importing the LDIF file into your configuration directory, make sure that you also use -s to include o=NetscapeRoot. You can use multiple -s arguments. If you use both -x and -s with the same suffix, -x takes precedence. Exclusion always takes precedence over inclusion. If you do not specify -x or -s, then all available suffixes will be imported from the LDIF file.

-x. Optional. Allows you to specify suffixes within the LDIF file to exclude during the import. You can use multiple -x arguments. This option lets you selectively import portions of the LDIF file. If you use both -x and -s with the same suffix, -x takes precedence. Exclusion always takes precedence over inclusion. If you do not specify -x or -s, then all available suffixes will be imported from the LDIF file. If you are importing the LDIF file into your configuration directory, do not exclude o=NetscapeRoot.

Warning! If you are importing the LDIF file into your configuration directory, do not exclude the suffix o=NetscapeRoot. The Netscape Administration Server uses this suffix to store information about installed Netscape Servers. Deleting this suffix could force you to reinstall all of your Netscape 4.x servers, including the directory server.

LDIF to Database Examples

Warning! If you are importing the LDIF file into your configuration directory, make sure the o=NetscapeRoot suffix and its contents are included in your LDIF file before you import. Do not exclude the suffix o=NetscapeRoot using -s, -x, or a combination of the two. The Netscape Administration Server uses this suffix to store information about installed Netscape Servers. Failure to import o=NetscapeRoot into your configuration directory could force you to reinstall (or restore from backup) all of your Netscape 4.x servers including the directory server.

Windows NT:

slapd ldif2db -f  c:\Netscape\Server4\slapd-dirserver\config\slapd.conf -C -i  c:\Netscape\Server4\slapd-dirserver\ldif\demo.ldif -i  c:\Netscape\Server4\slapd-dirserver\ldif\demo2.ldif

Unix:

ns-slapd ldif2db -f /usr/Netscape/Server4/slapd-dirserver/config/slapd.conf -C -i  /usr/Netscape/Server4/slapd-dirserver/ldif/demo.ldif -i  /usr/Netscape/Server4/slapd-dirserver/ldif/demo2.ldif

Deleting LDIF Files

If you want, you can delete LDIF files you have created. The Directory Server Console does not provide functionality to do this. Instead, you need to delete the files from the command line or through your operating system's utilities.


Backing Up and Restoring Your Database
You can back up and restore your database from the Directory Server Console. To back up your database, you can perform an online backup using the Directory Server Console or the db2bak command-line script. You can also manually copy your database directly to a backup directory.

When restoring your database, you must shut down your server. However, you can back up your database while the server is running.

The following sections describe the options available to you:

Exporting your database to and importing from LDIF is described in "Exporting Databases to LDIF" and "Importing Databases From LDIF".

Backing Up Your Database From the Server Console

When you back up your database from the Directory Server Console, the server copies the entire database and associated index files to a backup location.

To perform an online backup of your database from the server console:

  1. On the Directory Server Console select the Tasks tab.

  2. Click "Back Up the Directory Server". The Backup directory dialog box appears.

  3. Choose a directory name where you want the backup stored in one of two ways: type in the name of the directory in which you want the backup placed in the Directory text box, or click "Use default" and the server provides a name for the backup directory.

    4. If you choose to use the default, the backup files will be placed in the following location:

    <NSHOME>/slapd-<serverID>/bak/<backup_directory>

    where <backup_directory> is a directory given the name of the backup. By default, the backup directory name identifies the time and date when the backup was created in the format YYYY_MM_DD_HHMMSS.

  4. Click OK.
Backing Up Your Database From the Command Line

You can back up your database from the command line by using the db2bak command-line script. This script assumes you are using the slapd.conf file located in <NSHOME>/slapd-<ServerID>/config. Where <NSHOME> is the directory where you installed the directory server and <serverID> is the name of your directory server.

To perform an online backup of your directory from the command line:

  1. At the command prompt, change to <NSHOME>/slapd-<serverID>.

  2. Run the db2bak command-line script as follows:

    3. db2bak [backup_directory]

    You can choose to specify a full path or just a directory where you want the server to store the backup. If you only specify a directory, the server creates the directory under <NSHOME>/slapd-<ServerID>/.

    If you do not specify either a full path or a single directory, the script makes a copy of your database and stores it in <NSHOME>/slapd-<ServerID>/bak/<backup_directory>. Where <backup_directory> is a directory given the name of the backup. By default, the backup directory name identifies the time and date when the backup was created in the format YYYY_MM_DD_HHMMSS.

Restoring Your Database From the Server Console

If your database becomes corrupted, you can restore from a previously generated backup using the Directory Server Console. This process consists of copying the database and associated index files from the backup location to the database directory. See "Backing Up Your Database From the Server Console" for more information.

Warning! Restoring your database overwrites your existing database files, if any.

To restore your database from a previously created backup:

  1. On the Directory Server Console select the Tasks tab.

  2. Click "Restore Directory Server". The Restore Directory dialog box displays.

  3. The Console lists all backups in the default directory (<NSHOME>/slapd-<serverID>/bak/<backup_name>) in the Available Backups list box.

    4. You can either select the backup from this list or enter the full pathname to a location containing a valid backup in the Directory text box.

  4. Click OK.

    5. If the server is running, you are prompted to shut it down. The restore cannot continue while the server is running.

Restoring Your Database From the Command Line

You can restore your database from the command line by using the bak2db command-line script. This script assumes you are using the slapd.conf file located in <NSHOME>/slapd-<ServerID>/config. Where <NSHOME> is the directory where you installed the directory server and <serverID> is the name of your directory server.

To restore your directory from the command line:

  1. At the command prompt, change to <NSHOME>/slapd-<serverID>.

  2. If the server is running, type stop-slapd to shut it down.

  3. Run the bak2db command-line script as follows:

    4. bak2db [backup_directory]

Deleting Database Backups

By default, the server console places backup files that it creates in a directory under <NSHOME>/slapd-<serverID>/bak. If you want to remove old backups, you need to delete the files from this directory using the command line or through your operating system's utilities.

Restoring Databases That Include Replicated Entries

If you are restoring a database that is supplying entries to other servers, then you must reinitialize all of your consumer servers. A message will be logged to the consumer servers' log files indicating that reinitialization is required. If you want reinitialization to occur automatically, you can modify the ORCauto parameter. See Chapter  17, "Configuration Parameters," for information.

If you are restoring a database containing data received from a supplier server, then one of two situations can occur:

For information on managing replication, see Chapter  13, "Managing Replication." For information on initializing consumers, see "Initializing Consumers".


Placing a Database in Read-Only Mode
You must put a database in read-only mode if you are manually initializing a consumer. For information on manually initializing a consumer, see "Initializing Consumers".

When a database is in read-only mode you cannot create, modify, or delete any entries.

If your directory server manages multiple databases, you can place all of them into read-only mode at the same time by placing your entire server in read-only mode. For instructions on how to do this, see "Placing the Entire Directory Server in Read-only Mode".

If you want to place a database into read-only mode from the command line, set the slapd.conf Read-only parameter to on. You must shut the server down before you edit the configuration files.

To place a database into read-only mode from the server console:

  1. On the Directory Server Console select the Configuration tab.

  2. Select the Database icon in the navigation tree in the left pane.

  3. Select the Settings tab in the right pane.

  4. Select the "Make Database Read-Only" checkbox.

  5. Click Save.

Setting Suffixes for Your Database
Your directory server can simultaneously manage many different directory trees. Each directory tree is represented by a suffix, and each suffix corresponds to the root (or topmost) entry in the directory. When the directory server receives a request, the server checks its list of suffixes against the request to see if the server is managing the directory tree the client wants to access. If the directory request does not match the directory trees the server is managing, then the server sends the client a referral, if one has been configured. If a referral has not been configured, the server returns an error.

Your Netscape Directory Server always uses multiple suffixes. However, most of these are used only for internal purposes, and only one corresponds to the primary directory that you are using the server to manage (such as o=Airius.com). Other suffixes correspond to directory trees used internally by the server (such as o=NetscapeRoot, or the change log).

You can add, modify, and delete suffixes for your database. If you delete an existing suffix, then LDAP clients will not be able to access the entries represented by that suffix.

For information on the Suffix parameter, see "Suffix".

To manage suffixes for your server:

  1. On the Directory Server Console select the Configuration tab.

  2. Select the Database icon in the navigation tree. This displays the database settings in the right pane.

  3. Select the Settings tab. This tab contains a list of all the current suffixes in your directory.

  4. To add a new suffix, click Add and enter the new suffix in the field that appears.

    5. If the suffix value contains a comma, you must precede the comma with a backslash (\). For example, to add Airius Bolivia, S.A. as a suffix, you would enter Airius Bolivia\, S.A. in the Suffix field.

  5. To delete a suffix, select it in the list and click Delete.

    6. Warning! Do not delete the suffix o=NetscapeRoot. The Netscape Administration Server uses this suffix to store information about installed Netscape Servers. Deleting this suffix could force you to reinstall all of your Netscape 4.x servers, including the directory server.

  6. To modify an existing suffix, double-click the suffix in the list and make your changes.

  7. Click Save.

Enabling and Disabling Plug-Ins From the Server Console
You can enable and disable plug-ins over LDAP using the directory server console. To do this:

  1. On the Directory Server Console, select the Configuration tab.

  2. Double-click the Plugins folder in the navigation tree.

  3. Select the plug-in in the plug-ins list.

  4. To disable the plug-in, clear the "Enabled" checkbox. To enable the plug-in, select this checkbox.

  5. Click Save.

  6. Restart the directory server.

Managing the Referential Integrity Plug-in
Referential integrity is a database mechanism that ensures that relationships between related entries are maintained. In the Directory Server, referential integrity can be used to ensure that a directory update to one entry is correctly reflected in any other entries that may refer to the updated entry.

For example, if a user's entry is removed from the directory and referential integrity is enabled, the server also removes the user from any groups of which the user is a member. If referential integrity is not enabled, the user remains a member of the group until manually removed by the administrator. This is an important feature if you are integrating the directory server with other Netscape products that rely on the directory for user and group management.

Whenever you delete or rename a user or group entry in the directory, the operation is logged to the referential integrity log file (<NSHOME>/slapd-<serverID>/logs/referint). After a specified time, known as the update interval, the server searches the directory for all attributes that have been set for integrity updates that have a DN equal to the value of the deleted or modified entries. If the log file shows that the entry was deleted, the corresponding attribute is deleted. If the log file shows that the entry was changed, the corresponding attribute value is modified accordingly.

To maintain referential integrity in a replicated environment, you should configure the plug-in on the supplier to record any changes made (due to integrity updates) in the change log. You should also disable the referential integrity plugins on all consumer servers. The supplier server sends any changes made by the referential integrity plug-in to consumer servers. It is therefore unnecessary to run the referential integrity plug-in on consumer servers, unless your consumer servers master data locally and you want to maintain referential integrity within that locally-mastered data.

By default, the referential integrity plug-in is enabled and set to perform integrity updates on the member, uniquemember, owner, and seeAlso attributes immediately after a delete or rename operation. You can; however, disable the plug-in if you do not need this feature, configure the plug-in to record changes in the change log, change the update interval, and choose the attributes you want the plug-in to update. The rest of this section explains how in the following sections:

Managing Referential Integrity From the Server Console

You can enable or disable the Referential Integrity Postoperation plug-in from the Directory Server Console as described in "Enabling and Disabling Plug-Ins From the Server Console".

Managing Referential Integrity From the Command Line

You can enable or disable the referential integrity plug-in from the command line by editing the plugin postoperation parameter in the slapd.ldbm.conf file (for information on the location of the configuration files, see "Directory Server Configuration Files").

Note. On Unix, quotes may appear only around the name of the plug-in, that is, "referential integrity postoperation". On Unix, you do not need to put quotes around any other elements in the plug-in syntax. On Windows NT, you need to use quotes exactly as documented in these procedures.

To enable or disable the plug-in:

  1. Stop the server. See "Starting and Stopping the Directory Server" for information.

  2. Open the slapd.ldbm.conf file and locate the line that begins:

    3. plugin postoperation on "referential integrity postoperation"

  3. To disable the plug-in, change on to off. For example:

    4. plugin postoperation off "referential integrity postoperation" "<NSHOME>/lib/referint-plugin.dll" referint_postop_init "0"
    "<NSHOME>/slapd-<serverID>/logs/referint" "0"
    "member" "uniquemember" "owner" "seeAlso"

    To enable the plug-in, change off back to on.

  4. Save the file.

  5. Start the server.
Configuring Referential Integrity for Replicated Environments

From the command-line, you can configure the plug-in on a supplier server to record any changes it makes in the change log. The supplier server will then send any changes made by the referential integrity plug-in to consumer servers. If you configure the plug-in on the supplier server to maintain referential integrity for replication, you do not need to enable referential integrity on its consumers.

To configure the plug-in to record changes in the change log:

  1. Stop the server. See "Starting and Stopping the Directory Server" for information.

  2. Open the slapd.ldbm.conf file and locate the line that begins:

    3. plugin postoperation on "referential integrity postoperation"

  3. Change the integer value immediately after <NSHOME>/slapd-<serverID>/logs/referint to 1. For example:

    4. plugin postoperation on "referential integrity postoperation" "<NSHOME>/lib/referint-plugin.dll" referint_postop_init "0"
    "<NSHOME>/slapd-<serverID>/logs/referint" "    1"
    "member" "uniquemember" "owner" "seeAlso"

    To disable this feature, change the 1 back to zero (0).

  4. Save the file.

  5. Start the server.
Changing the Integrity Update Interval

By default, the referential integrity plug-in searches the database and updates related entries immediately after a delete or rename operation. If you want to reduce the impact this operation has on your system, you may want to increase the amount of time between updates. Although there is no maximum update interval, the following intervals are commonly used:

To modify the update interval:

  1. Stop the server. See "Starting and Stopping the Directory Server" for information.

  2. Open the slapd.ldbm.conf file and locate the line that begins

    3. plugin postoperation on "referential integrity postoperation"

  3. Change the integer value that immediately follows referint_postop_init to the number of seconds between updates.

    4. For example, if you want to change the update interval so that updates occur once a day (every 86,400 seconds), you edit the line as follows:

    plugin postoperation on "referential integrity postoperation" "<NSHOME>/lib/referint-plugin.dll" referint_postop_init 86400
    "<NSHOME>/slapd-<serverID>/logs/referint" "0"
    "member" "uniquemember" "owner" "seeAlso"

  4. Save the file.

  5. Start the server.
Modifying Which Attributes to Update

By default, the referential integrity is set up to update the member, uniquemember, owner, and seeAlso attributes. You can either add or delete attributes to be updated by editing the slapd.ldbm.conf file (for information on the location of configuration files, see "Directory Server Configuration Files"). For best performance, the attributes set for updating should also be indexed. For information on indexing, see Chapter  7, "Managing Indexes."

To modify which attributes should be updated:

  1. Stop the server. See "Starting and Stopping the Directory Server" for information.

  2. Open the slapd.ldbm.conf file and locate the line that begins

    3. plugin postoperation on "referential integrity postoperation"

  3. Add or delete attribute names from the end of the line.

    4. For example, to modify the plug-in to perform integrity updates on the manager attribute, add "manager" to the end of the plug-in postoperation line as follows:

    plugin postoperation on "referential integrity postoperation" "<NSHOME>/lib/referint-plugin.dll" referint_postop_init 0 "<NSHOME>/slapd-<serverID> /logs/referint" "0" "member" "uniquemember"
    "owner" "seeAlso" "manager"

  4. Save the file.

  5. Start the server.

Managing Database Transaction Logging
Whenever a directory database operation such as a write is performed, the server logs the operation by default to the transaction log. For best performance, the operation itself may not be performed immediately. Instead, it is stored in a temporary memory cache on the directory server until the operation is completed. If the server experiences a failure, such as a power outage, and shuts down abnormally, the information about recent directory changes that were stored in the cache are lost. However, when the directory server restarts, it automatically detects the error condition and uses the database transaction log file to recover the database.

Although database transaction logging and database recovery are automatic processes that require no intervention, you may want to tune some of the database transaction logging parameters for best performance.

The following sections describe the parameters:

Changing the Location of the Database Transaction Log

By default, the database transaction log file is stored in the <NSHOME>/slapd-<serverID>/db directory along with the directory files themselves. Because the purpose of the transaction log is to aid in the recovery of a directory database that was shut down abnormally, it is a good idea to store the database transaction log on a different disk from the one containing the directory database. Storing the database transaction log on a separate physical disk may also improve directory server performance.

You can move the location of the database transaction log file by adding the db_logdirectory parameter to the end of the slapd.ldbm.conf file.

For information on the location of the configuration files, see "Directory Server Configuration Files". For information on the db_logdirectory parameter syntax, see "Database Transaction Log Directory".

Changing the Database Checkpoint Interval

Whenever a directory database operation such as a write or modify is performed, the operation is logged to the directory server database transaction log. For best performance, the results of the operation itself may not be written to disk immediately. Instead they are stored in a temporary memory cache on the directory server. At specific intervals, the directory server writes the previously cached data out to the disk and logs a checkpoint entry in the database transaction log. By indicating which changes have already been written to the directory, checkpoint entries tell the directory server where in the database transaction log to begin recovery, thus speeding up the recovery process.

By default, the directory server is set up to send a checkpoint entry to the database transaction log every 60 seconds. Increasing the checkpoint interval may increase the performance of directory server write operations. Increasing the checkpoint interval may also significantly increase the amount of time required to recover the directory database after a disorderly shutdown and may waste disk space due to overly large database transaction log files. Therefore, you should only modify this parameter if you are familiar with database optimization and can fully assess the impact of the change.

To modify the checkpoint interval, you must add the db_checkpoint_interval parameter to the end of the slapd.ldbm.conf file.

For information on the location of the configuration files, see "Directory Server Configuration Files". For information on the db_checkpoint_interval parameter syntax, see "Database Checkpoint Interval".

Disabling Durable Transactions

By default, durable database transaction logging is enabled. This means that every time a write is performed on the directory, a corresponding entry is physically written to the database transaction log disk. To improve performance, you can disable durable transaction logging. When you do so, every directory database operation is logically written to the database transaction log file, but it may not be physically written to disk immediately. That means that if a directory change was written to the logical database transaction log file but not physically written to disk at the time of a system crash, you cannot recover the change. When durable transactions are disabled, the recovered database is consistent, but does not reflect the results of any LDAP write operations that completed just before the system crash.

You can disable durable transactions by adding the db_durable_transactions parameter to the end of the slapd.ldbm.conf file and set its value to off.

For information on the location of the configuration files, see "Directory Server Configuration Files". For information on the db_durable_transactions parameter syntax, see "Database Durable Transactions".
 

© Copyright 1999 Netscape Communications Corporation, a subsidiary of America Online, Inc. All Rights Reserved.