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.)

REAL WORLD: 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.

Table 3.1. 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.

Figure 3.6. Select Use Temporary NDS Database During Repair? if you do not want to work on a live database.

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.

  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.

  
  

• 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.

  NOTE

  See Chapter 16, "Tuning eDirectory," for information about eDirectory tuning.

  
  

• *.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 .

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.

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.

Table 3.2. 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