- The NDS 6 DIB
- NDS 7 DIB
- NDS 8 and eDirectory DIB
- Locating the DIB
- Backing Up the DIB
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
NDS 8 and eDirectory DIB
Versions of NDS prior to NDS 8 use a database engine called Recman, which, as the name suggests, is a record-based database management engine. NDS 8 and eDirectory uses a database engine called FLAIM, which stands for Flexible and Adaptable Information Manager. It is a database engine that is optimized for search and retrieval for a large number of small interrelated objects. (Novell's GroupWise email system also uses the FLAIM engine for its database.)
What Is FLAIM?
The initial idea for what later became FLAIM came from the genealogy world. Genealogical databases can be huge. When you consider that there are now more than 6 billion people on the planet, and a genealogical database stores information about the ancestors of these people, the sheer size of the data store and the complex relationships between arbitrarily structured data items challenges conventional database techniques. FLAIM was designed to handle databases of this scale and to have the very desirable attribute of handling information whose interrelationships (and hence the database schema) may not be known in advance of adding data to the database.
WordPerfect Corporation acquired the initial idea for FLAIM and developed it for use in the WordPerfect product. Over time, the database came to be known as FLAIM. With Novell's merger with WordPerfect in 1994, FLAIM became the property of Novell. At that time, NDS was just being introduced to the world and already had its own database. However, a few years later, when looking to make the next generation of NDS more scalable and more efficient, Novell investigated several databases as potential candidates but then realized that a high- performance, expandable, and quick database had already been developed in-house. To make a long story short, Novell eventually investigated FLAIM and decided to use it for NDS 8. The FLAIM development team joined the NDS development team, and the result was a much more robust directory.
As an impressive demonstration of the increased capabilities of eDirectory due to FLAIM, Novell has publicly showcased, several times since 2000, eDirectory running on a single server with 1.5 billion objects in the database!
A FLAIM database file is divided into logical files called containers. A FLAIM database can have multiple containers, including custom containers. Each FLAIM database must have at least a Default Data, a Local Dictionary, and a Tracker container. Data in one container can reference data in another container, by using the data record number (DRN) of the data being referenced. Table 3.1 lists the containers used in DS 8 and eDirectory databases.
FLAIM Container Descriptions
|
FLAIM Container |
Description |
|
Default Data |
Actual data records (entries, values, schema definitions, and so on) |
|
Local Dictionary |
Container and field definitions |
|
Tracker |
A tracker for record changes |
|
Partition_Cont |
Partition records |
|
AttrInfo_Cont |
Attribute syntax information |
|
Stream_Cont |
Stream records |
|
PCC0_Cont |
The change cache for system-created Partition 0 (System) |
|
PCC1_Cont |
The change cache for system-created Partition 1 (Schema) |
|
PCC2_Cont |
The change cache for system-created Partition 2 (External Reference) |
|
PCC3_Cont |
The change cache for system-created Partition 3 (Bindery) |
|
PCC4_Cont |
The change cache for user-created Partition 4; this is the first user-created partition, and other containers will be created for each new partition |
|
Attr_246_Cont |
The Member container |
|
Attr_277_Cont |
The Private Key container |
|
Attr_281_Cont |
The Public Key container |
|
Attr_286_Cont |
The Reference container |
|
Attr_361_Cont |
The Equivalent to Me container |
|
Attr_431_Cont |
The NLS:Common_Certificate container |
|
Attr_455_Cont |
The NLS:List_Of_Handles container |
|
Attr_518_Cont |
The NDSPKI:Key_File container |
|
Attr_468_Cont |
The NLS:Cert_Peak_Used_Pool |
These logical files may be stored in one or more physical files. eDirectory's implementation is that each physical file can grow to 2GB in size for NDS 8/eDirectory 8.5 and to 4GB in size for eDirectory 8.6 and higher; then the content is "spilled" over to another file. Therefore, depending on the size of your DS database, you will at least have a file called NDS.01, and when it reaches the maximum allowed size, an NDS.02 file is created, and when that file reaches the maximum allowed size, an NDS.03 file is created, and so on.
TIP
The FLAIM database can be compressed to remove blank or deleted records. Therefore, one of the options in DSRepair for DS 8 and eDirectory is to reclaim unused space. In Figure 3.6 later in this section, you can see the option about halfway down the list.
The following is a list of files employed by eDirectory 8.5 and higher:
NDS.xx—These are the main eDirectory database files, where xx is 01, 02, and so on. These files contain several types of records (such as partition and schema records) and also any eDirectory attribute indexes (such as CN and Surname, which can be used to speed up DS and Lightweight Directory Access Protocol queries) defined on the server.
NDS.RFL\xxxxxxxx.LOG—These are the RFL files, where xxxxxxxx ranges from 00000001 to FFFFFFFF. In order to protect against loss of data from a catastrophic failure such as a server crash, eDirectory uses an RFL to track all changes made to the database. Hence, if necessary, eDirectory can recommit lost data to the database by examining the xxxxxxxx.LOG files when the server is restarted.
NDS.DB—This is the roll-back log file. Because changes to the eDirectory database can include operations that require many data packets' worth of information to be sent to the server, eDirectory commits each packet to the database as it is being received—even though the entire transaction may not yet be complete. To safeguard against communication failure, eDirectory writes these transactions to a roll-back log. If an incomplete operation is encountered, eDirectory can use the roll-back log to undo incomplete transactions. (This is why TTS is not required for eDirectory to function.)
NDS.LCK—This is the NDS lock file. During database maintenance, sometimes the eDirectory database needs to be closed or locked for modifications. The NDS.LCK file is used to designate this locked condition. For eDirectory 8.5 and higher, this file shows as a 0 byte file. When the database is locked, attributes are changed on this file to signify that condition, and the file still shows as a 0 byte file. The timestamp of the file is updated whenever the database is locked or unlocked.
_NDSDB.INI—This is the database cache configuration file. When an eDirectory tuning parameter, such as the hard limit of the database cache size, is statically assigned, the setting is stored in the _NDSDB.INI file.
*.FRS—These are the temporary FLAIM record set files used by FLAIM.
NDT.DB—This is a DSRepair temporary database file for NDS.DB.
NDT.xx—These are DSRepair temporary database files for NDS.xx.
NDT.RFL\xxxxxxxx.LOG—These are DSRepair temporary database files, where xxxxxxxx ranges from 00000001 to FFFFFFFF.
As records are modified in the eDirectory database, but before they are committed to the disk, a copy of the changes is stored in the RFL file. These entries are completed transactions that had not been written to disk. Upon server failure, the records committed to the disk may be lost, but the changes are maintained in the RFL file. This process is handled by the checkpoint thread on the server, and the size of the RFL file should decrease in time as transactions are written to disk.
TIP
The RFLs are typically stored in the NDS.RFL directory under the main DIB folder (for example, for NetWare, it is SYS:_NETWARE\NDS.RFL). With eDirectory 8.7 and higher, you can store this file in a different location. To ensure database integrity, it is recommended that you do place the RFLs on a disk other than the one that holds the eDirectory database. You accomplish this by using the eDirectory Backup eMTool utility. It is possible to delete this directory, but it is not recommended because it involves the possibility of corrupting the eDirectory database.
NOTE
See Chapter 16, "Tuning eDirectory," for information about eDirectory tuning.
When you're running DSRepair to repair the local database, one option (see Figure 3.6) is to use a temporary DS database during the repair. This allows the repair operation to be done on a copy of the database (using the NDT.* files) and not the live database.
)
Figure
3.6 Select Use Temporary NDS Database During Repair? if you do not want to
work on a live database.
Table 3.2 gives the names of the database files used by the various versions of NDS/eDirectory and summarizes their purposes. It also shows the location of each of these files.
Summary of DS File Functions
|
NDS 6 and Prior |
NDS 7 (Recman) |
NDS 8 and Above (FLAIM) |
|
Located in SYS:_NETWARE |
Located in SYS:_NETWARE |
Located in SYS:_NETWARE on NetWare servers, [drive:]\Novell\NDS\ DIBFiles on Windows, and /var/nds/dib on Unix servers |
|
ENTRY.NDS— Object information |
0.DSD—Entry information |
NDS.01—Entry, attribute, schema, and partition information; rolls over to NDS.02 and so on when file size reaches 2GB or 4GB |
|
VALUE.NDS— Attribute information |
1.DSD— Attribute information |
N/A |
|
BLOCK.NDS— Attribute (more than 16 bytes) overflow |
2.DSD Attribute overflow |
N/A |
|
PARTITO.NDS— Partition information |
3.DSD— Partition information |
N/A |
|
N/A |
0.DSB—[Lookup table of names of .DSD files (only 28 bytes in size!) |
N/A |
|
Stream files (*.000)—Login scripts and so on |
Stream files (*.000)—Login scripts and so on |
Stream files (0-9, A-F.NDS)—Login scripts, and so on (for example, 1.NDS, 4F.NDS) |
|
N/A |
N/A |
NDS.DB—Control file containing rollback information for aborted transactions |
|
N/A |
N/A |
NDS.RFL\*.LOG—RFL file to reapply transactions that have been completed but not written to disk |
|
N/A |
N/A |
_NDSDB.INI—File that keeps cache information |
|
N/A |
N/A |
NDS.LCK—File that prevents access to database when open |