Export (0) Print
Expand All

Database Issues

If the domain controller cannot shut down in an orderly fashion (which usually means a power failure), the database is left out-of-date, because the most recent pages in memory were not written to the disk. Transaction logs are used to recover the database. Any change made to the database is also appended to the current log file, and its disk image is always kept up-to-date. The database change process is as follows:

  1. Lsass.exe writes the change to a database page in the memory buffer.

  2. Lsass.exe writes the change to the log file.

  3. Lsass.exe waits for the log file to be flushed to disk.

  4. Lsass.exe confirms the transaction.

If Active Directory halts, preventing the database from being successfully flushed to disk, the database performs a recovery on the next startup. Essentially, the database reads through the log files in order and reapplies changes until the database is made consistent and up-to-date.

The default log file name is Edb.log. The ESE can create a new log file when the current one fills up (noncircular logging). Or, it can overwrite the oldest file when the log reaches a specified number of files (circular logging). Noncircular logging consumes disk space until the administrator manually deletes old log files, following a backup or restart. It saves all database changes and never automatically deletes log files.

note-icon Note

The default setting for Windows 2000 is circular logging turned on.

That directory routinely contains the following files:

  • Edbxxxxx.log

  • Edb.chk

  • Res1.log

  • Res2.log

Each of the files that has a .log extension is going to be created at exactly the same size of 10 megabytes (MB). Edb.log is the "current" log file. If circular logging is turned off, when the Edb.log file is full of transactions, it is renamed to Edb00001.log. This naming convention continues to increment by using hexadecimal notation. Thus, if there is a question as to the condition of the log files, that can be determined by checking to see whether an unbroken series of log file names exist.

Res1.log and Res2.log are "placeholders" — designed to reserve (in this case) the last 20 MB of disk space on this drive or directory. This is designed to give the log files sufficient room for a graceful shutdown if all other disk space are consumed. Note that if circular logging is set to on, running out of space for log files is not an issue.

The checkpoint file, Edb.chk, is created by the Jet Database. Edb.chk stores the database checkpoint, so that it can replay logs starting with the generation containing the checkpoint, if needed. The Edb.chk file is a pointer in the log sequence that maintains the status between memory and the database file on disk. In the event of a failure, it indicates the point in the log file from which the information store needs to start the recovery. The Edb.chk file is essential for efficient recovery because if it didn't exist, the information store must attempt recovery by starting from the beginning of the oldest log file it found on disk and has to check every page in every log file to determine whether it had already been written to the database. This process, of course, is very time consuming, especially if the only goal is to make the database consistent.

Every time the database is opened, a check is performed to see if the database is up to date with the related checkpoint. For example, did the database fail before updating the checkpoint? If the database is not up to date, the log files are replayed from the point that the checkpoint file indicates. Jet logging and recovery can still recover a database without a checkpoint, but the checkpoint allows faster recovery by directing recovery to begin closer to logged operations that must be redone.

Edb.chk is updated automatically by Jet when Jet notices that it has a specific amount of changes in the log files that are not forwarded to the checkpoint. Also, it is updated at the end of a recovery process. Finally, it is updated when you successfully shut down the system, to close the database.

note-icon Note

The Directory Services Restore Mode–only restriction applies only to the functions that work directly on the database.

For more information about Active Directory Database operations, see "Active Directory Data Storage" in this book.

Ensuring File Integrity

To ensure the integrity of the database files, you might need to perform preventive procedures such as integrity check, move, repair, recovery, and defragmentation.

Using the Integrity Command to Detect Low Level Database Corruption

By using the integrity command, you can detect low level (binary level) database corruption. The integrity command invokes the esentutl command-line tool, which reads every byte of the data file. Therefore, depending upon the size of your data file, the process might take a considerable amount of time.

The integrity command also makes sure that the correct headers exist in the database itself and that all of the tables are functioning and are consistent. In short, it checks the integrity of the directory service data files. This is used while in Directory Services Restore mode. If errors are encountered, they are recorded on the log files.

The length of time for the integrity command to complete its operation depends on the type of hardware you are using and the size of your directory database. (In testing environments, the speed of two gigabytes (GB) per hour was considered to be normal.) However, when you carry out the command, an online graph displays showing the percentage completed.

important-icon Important

To run the Ntdsutil tool and the subsequent integrity command, you must be in Directory Services Restore mode.

Following is a sample run of an integrity check by using the Ntdsutil tool:

:\>ntdsutil

ntdsutil: files

file maintenance: Integrity

Opening database .

Executing Command: C:\WINNT\System32\esentutl.exe /g "C:\WINNT\NTDS\ntds.dit" /!

10240 /8 /v /x /o

Initiating INTEGRITY mode...

Database: C:\WINNT\NTDS\ntds.dit

Temp. Database: INTEG.EDB

failed to get 515126 buffers

checking database header

checking database integrity

Scanning Status ( % complete )

0 10 20 30 40 50 60 70 80 90 100

|----|----|----|----|----|----|----|----|----|----|

checking SystemRoot

SystemRoot (OE)

SystemRoot (AE)

checking system table

MSysObjectsShadow

MSysObjects

. Name

RootObjects

rebuilding and comparing indexes

checking table "datatable" (6)

checking data

....................... checking long value tree (24)

... checking index "PhantomIndex" (125)

. checking index "INDEX_000901FD" (122)

checking index "INDEX_000900DE" (121)

checking index "INDEX_00090089" (120)

checking index "INDEX_00090573" (119)

checking index "INDEX_00090073" (118)

checking index "INDEX_00090571" (117)

checking index "INDEX_0009056C" (116)

checking index "INDEX_00090553" (115)

checking index "INDEX_0009013A" (114)

checking index "INDEX_00090138" (113)

checking index "INDEX_00090330" (112)

checking index "INDEX_00090030" (111)

checking index "INDEX_00090013" (110)

checking index "INDEX_00000013" (109)

checking index "INDEX_0000000B" (108)

checking index "INDEX_00000007" (107)

checking index "INDEX_00000003" (106)

. checking index "INDEX_00150003" (105)

checking index "LCL_ABVIEW_index00000409" (104)

checking index "INDEX_00090363" (103)

checking index "INDEX_00090303" (102)

checking index "INDEX_00090290" (101)

checking index "INDEX_000901FF" (100)

checking index "INDEX_000900DD" (99)

checking index "INDEX_00090085" (98)

checking index "INDEX_00090057" (97)

checking index "INDEX_0009001C" (96)

checking index "INDEX_000201CC" (95)

. checking index "INDEX_000200D2" (94)

checking index "INDEX_0002000D" (93)

checking index "INDEX_0000002A" (92)

checking index "INDEX_00000004" (91)

checking index "NC_Acc_Type_Name" (90)

checking index "PDNT_index" (89)

.. checking index "INDEX_00090001" (88)

. checking index "INDEX_000901F6" (85)

checking index "INDEX_000902EE" (84)

checking index "INDEX_000904E1" (83)

checking index "INDEX_000201D5" (80)

checking index "INDEX_000902BB" (77)

checking index "INDEX_000903B4" (76)

checking index "INDEX_000200A9" (75)

checking index "INDEX_0009039D" (74)

checking index "INDEX_0009039A" (73)

checking index "INDEX_00090098" (72)

checking index "INDEX_00090395" (71)

checking index "INDEX_0009028F" (69)

checking index "INDEX_00090582" (66)

checking index "INDEX_00020078" (65)

. checking index "INDEX_00020073" (62)

checking index "INDEX_00090171" (60)

checking index "INDEX_00090167" (58)

checking index "INDEX_00090062" (56)

checking index "INDEX_00090261" (55)

checking index "INDEX_0009014E" (52)

checking index "INDEX_0009014D" (51)

checking index "INDEX_0009014C" (50)

checking index "INDEX_00090147" (49)

checking index "INDEX_00090141" (48)

checking index "INDEX_00090140" (47)

checking index "INDEX_0009012E" (42)

checking index "INDEX_00020013" (39)

. checking index "INDEX_0009030E" (36)

checking index "INDEX_00090008" (32)

checking index "INDEX_00090202" (25)

checking index "Ancestors_index" (13)

. checking index "DRA_USN_CREATED_index" (12)

checking index "DRA_USN_index" (11)

. checking index "del_index" (10)

checking index "INDEX_00090002" (9)

.. checking index "NC_Acc_Type_Sid" (8)

checking index "INDEX_00090092" (7)

rebuilding and comparing indexes

checking table "hiddentable" (16)

checking data

rebuilding and comparing indexes

checking table "link_table" (14)

checking data

checking index "backlink_index" (15)

rebuilding and comparing indexes

checking table "MSysDefrag1" (123)

checking data

checking index "TablesToDefrag" (124)

rebuilding and comparing indexes

checking table "sdproptable" (17)

checking data

checking index "clientid_index" (19)

checking index "trim_index" (18)

rebuilding and comparing indexes

integrity check completed.

Operation completed successfully in 13.640 seconds.

Spawned Process Exit code 0x0(0)

If integrity was successful, it is recommended

you run semantic database analysis to insure

semantic database consistency as well.

Determining the Location of Database Files and Log Files

To find out the location of the data files, log files, and working directory, you can use the info command, which is part of the ntdsutil command-line tool. This command does the following:

  • Analyzes and reports the free space for all disks installed on the computer.

  • Reads the registry keys that contact the location of the Active Directory files and reports their values.

  • Reports the sizes of the data file, working directory, and log file.

  • Following is sample output from running the info command:

file maintenance: Info

Drive Information:

C:\ NTFS (Fixed Drive ) free(2.9 Gb) total(3.9 Gb)

DS Path Information:

Database : C:\WINNT\NTDS\ntds.dit - 12.1 Mb

Backup dir : C:\WINNT\NTDS\dsadata.bak

Working dir: C:\WINNT\NTDS

Log dir : C:\WINNT\NTDS - 40.0 Mb total

res2.log - 10.0 Mb

res1.log - 10.0 Mb

REPAIR.TXT - 0.0 Kb

edb00001.log - 10.0 Mb

edb.log - 10.0 Mb

Moving the Database

When you move the database from one location to another location on the disk, you can use the Ntdsutil command-line tool in Directory Services Restore mode. For example, you might need to move a log file or the Ntds.dit file to another drive if corruption occurs on the previously assigned drive or directory. Specifically, the move db to % s command moves the Ntds.dit data file to the new directory specified by the "%s" and updates the registry keys so that the directory service restarts by using the new location.

To move the Active Directory database

  1. Back up Active Directory. Windows 2000 Backup natively supports backing up Active Directory while online. This occurs automatically when you select the option to back up everything on the computer in the Backup Wizard, or independently by selecting to back up the "System State" in the wizard.

  2. Restart the domain controller, select the appropriate installation from the startup menu, and then press F8 to display the Windows   2000 Advanced Options Menu .

  3. Select Directory Services Restore Mode , and then press ENTER. To start the boot process again, press ENTER.

  4. Log on by using the Administrator account by using the password defined for the Local Administrator account in the offline SAM.

  5. From the Start menu, point to Programs and Accessories , and then click Command Prompt .

  6. At the command prompt, type ntdsutil , and then press ENTER.

  7. Type files , and then press ENTER.

  8. Type info , and then press ENTER. This displays current information about the path and size of the Active Directory database and its log files. Note the path.

  9. Establish a location that has enough drive space for the move database to be stored.

  10. Type the following, and then press ENTER:
    move DB to < drive >:\< directory >
    where < drive > and < directory > is the path to the location that you established in the previous step.

    note-icon Note
    You must specify a directory path. If the path contains any spaces, the entire path must be surrounded by quotation marks (for example, move DB to "c:\new folder").
    The database named Ntds.dit is moved to the location that you specified.


  11. Type quit , and then press ENTER. To return to the command prompt, type quit again.

    note-icon
    Note
    It is highly recommended that you make a backup immediately or else the restore operation does not retain the new file location.

  12. Restart the computer normally.

You can also move the log files from location to another. Specifically, the Move logs to % s command moves the directory service log files to the new directory specified by % s and updates the registry keys so that the directory service restarts by using the new location.

Offline Defragmentation

Active Directory automatically performs online defragmentation of the database at certain intervals (by default, every 12 hours) as part of the Garbage Collection process. Online defragmentation does not reduce the size of the database file (Ntds.dit), but instead optimizes data storage in the database and reclaims space in the directory for new objects. It prevents data storage problems. Performing offline defragmentation creates a new, compacted version of the database file. Depending on how fragmented the original database file was, the new file might be considerably smaller.

To perform offline defragmentation of the Active Directory database

  1. Back up Active Directory. Windows 2000 Backup natively supports backing up Active Directory while online. This occurs automatically when you select the option to back up everything on the computer in the Backup Wizard, or independently by selecting to back up the "System State" in the wizard.

  2. Restart the domain controller, select the appropriate installation from the startup menu, and press F8 to display the Windows   2000 Advanced Options Menu .

  3. Select Directory Services Restore Mode , and then press ENTER. To start the boot process again, press ENTER.

  4. Log on by using the Administrator account with the password defined for the Local Administrator account in the offline SAM.

  5. Click Start , point to Programs and then to Accessories , and then click Command Prompt .

  6. At the command prompt, type ntdsutil , and then press ENTER.

  7. Type files , and then press ENTER.

  8. Type info , and then press ENTER. This displays current information about the path and size of the Active Directory database and its log files. Note the path.

  9. Establish a location that has enough drive space for the compacted database to be stored.

  10. Type the following, and then press ENTER:
    compact to < drive >:\< directory >
    where < drive > and < directory > is the path to the location that you established in the previous step.

    note-icon Note
    You must specify a directory path. If the path contains any spaces, the entire path must be surrounded by quotation marks (for example, compact to "c:\new folder").
    A new database named Ntds.dit is created in the path that you specified.

  11. Type quit , and then press ENTER. To return to the command prompt, type quit again.

  12. Copy the new Ntds.dit file over the old Ntds.dit file in the current Active Directory database path that you noted in step 8.

  13. Restart the computer normally.

Performing a Soft Recovery of the Log Files

In the event that the power source failed unexpectedly, you can perform a "soft" recovery of the log files. Because transaction data is written to the log files before it is written to the data files, you can re-run the log files to reproduce the effects the transactions would have had if they were made to the data file. The Recover command in the Ntdsutil command line tool invokes the Esentutl command-line tool to perform this "soft" recovery. All of the log files are scanned to ensure that all committed transactions are made to the data file.

note-icon Note

Soft recovery is performed automatically when the DSA starts if the previous shutdown was not clean.

Following is sample output of running the Recover command:

File maintenance: Recover

Executing Command: C:\WINNT\System32\esentutl.exe /r /8 /o /l"C:\WINNT\NTDS" /s"

C:\WINNT\NTDS" /!10240

Initiating RECOVERY mode...

Log files: C:\WINNT\NTDS

System files: C:\WINNT\NTDS

Performing soft recovery...

Operation completed successfully in 4.717 seconds.

Spawned Process Exit code 0x0(0)

If recovery was successful, it is recommended

you run semantic database analysis to insure

semantic database consistency as well.

Repairing the Database

The database might need to be repaired due to a power outage. To repair the database, use the Ntdsutil command-line utility. Specifically, the repair command invokes the Esentutl tool, which performs a low level (binary level) of repair to the data file. This means that it repairs the database information of which the ESENT is aware.

caution-icon Caution

Caution must be exercised when using the Repair command because you can experience the random loss of data. The exact type of data that can be lost is not known. This loss can occur when there is data necessary for the safe operation of Active Directory that is not identified in the ESE.

Ensuring Database Integrity

Because Active Directory is implemented on a transacted database system, the ESE historically called Jet, log files are used to support rollback semantics to ensure that transactions are committed to the database.

The Ntdsutil tool includes a semantics checker that can be invoked by selecting the Semantic database analysis option. The role of the semantic checker is to check the integrity of the contents of the Active Directory database.

The tool is run during Directory Service Restore mode. Errors are written into dsdit.dmp .xx log files. A progress indicator indicates the status of the check.

The following are examples of the functions that can be performed:

  • Reference count check. Counts all of the references from the data table and the link table to ensure they match the listed counts for the record. (For more information about data and link tables, see "Active Directory Data Storage" in this book.) It also ensures that each object has a GUID, distinguished name and nonzero reference count. If it is a deleted object, it ensures that it has a deleted time and date, but does not have a GUID or a distinguished name.

  • Deleted object check. Ensures that it has a deleted time and date, and a special relative distinguished name.

  • Ancestor check. Checks to determine if the current Distinguished Name Tag (DNT) is equal to the ancestor list of the parent and the current DNT.

  • Security descriptor check. Checks for a valid descriptor, ensuring that it has a control field, and that the discretionary access control list is not empty. If there are deleted objects without a discretionary control access list, a warning is printed.

  • Replication check. Checks the UpToDate vector in the directory partition head to ensure that the correct number of cursors exist. It also checks to see that every object has property metadata vector. For the instance type of the object, it checks the metadata, the up-to-dateness vectors, the sub references, and partial attribute.

To perform Semantic database analysis

  1. Back up Active Directory. Windows 2000 Backup natively supports backing up Active Directory while online. This occurs automatically when you select the option to back up everything on the computer in the Backup wizard, or independently by selecting to back up the "System State" in the wizard.

  2. Restart the domain controller, select the appropriate installation from the startup menu, and press F8 to display the Windows   2000 Advanced Option Menu .

  3. Select Directory Services Restore Mode , and then press ENTER. To start the boot process again, press ENTER.

  4. Log on by using the Administrator account with the password defined for the Local Administrator account in the offline SAM.

  5. From the Start menu, point to Programs and Accessories , and then click Command Prompt .

  6. At the command prompt, type ntdsutil and then press ENTER.

  7. Type Semantic database analysis , and then press ENTER.

  8. Type Verbose on , and then press ENTER. This displays the Semantic Checker.

  9. Type go, and then press ENTER. The Semantic Checker is started without repairing any errors it encounters.

    note-icon Note
    To repair the errors encountered, select the Go Fixup option.

  10. Type quit , and then press ENTER. To return to the command prompt, type quit again.

Following is a sample of running the Semantic database analysis option with verbose mode turned on:

ntdsutil: Semantic database analysis

semantic checker: Verbose on

Verbose mode enabled.

semantic checker: Go

Opening database .

....Done.

Getting record count...2371 records

Writing summary into log file dsdit.dmp.0

Records scanned: 2300

Processing records..Done.

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft