Active Directory runs its database with its own database engine. All querying, adding, deleting and making changes, protection, management, storage of the database; ESE (Extensible Storage Engine) is run by the database engine of Active Directory Domain Services. ESE architecture, which is used as a database for Active Directory Domain Services in Windows Server 8, is a popular product of Microsoft and used Exchange Server 5.5 years ago. It was developed based on.
The Active Directory database is kept on the local disk of the server (s) called Domain Controller and responsible for the management of the Active Directory Domain. The physical location of the database is %systemroot%\NTDS \ as the default installation result. The database filename, by default, is ntds.dit. However, the database system cannot only work with the database file. The file named edb.log, where all transactions take place temporarily, the changes are stored for various reasons before being written to the database, also plays a critical role in the operation of the Active Directory service. The component is the ebd.chk file, which works as a checkpoint and which we can call ESE checkpoint. is to check whether it can be written properly and consistently.
In addition, there are reserved log files that serve the database system, and in case there is no free space on the disk, they are found only to occupy the space, and in case of emergency (the disk is full), there are reserved log files that make use of the service. The name of these files, two of which are 10 MB in size, is edbres00001 and edbres00002.
Let’s examine how the Active Directory database system works and how an ordinary transaction process takes place.
When an administrator makes a change to the database, such as when a user account is created, deleted or modified; a write request (which is called write request) occurs. This write request is captured as a transaction, that is, a transaction by its technical name. This transaction consists of the relevant exchange information and the relevant metadata. The metadata version number, the date and time of the change. It consists of the time stamp and the globally unique identifier (GUID) number of the domain controller server that records the corresponding change. For example, when an attribute of an object is changed, the exchange information and version number, the time stamp that indicates the date of the change, and the globally unique identifier of the domain controller server that registered the change. A metadata that specifies (GUID) creates the transaction for this change.
A transaction begins when a request to write to Active Directory occurs. contains the relevant change information and the related metadata, and Active Directory places this transaction in the transaction buffer in memory. After that, ESE writes this transaction in the buffer to the edb.log file. It ensures that it is recorded in a healthy way. After the transaction is safely placed in the edb.log file; ESE places this transaction from the transaction buffer in memory in ndts.dit, the Active Directory database file located on the hard disk of the Domain Controller. If unprocessed transactions remain in the log file, errors may occur. Checking with the checkpoint file, edb.chk, it checks whether there are any transactions in the log file that have not yet been transferred to the database, which should be written to the database. Active Directory compares ntds.dit with edb.log files to confirm that each transaction has been successfully imported into the database. Later, the edb.chk file is updated, indicating that the relevant transaction is written to the database. After all transactions in the old log files are written to the database; Active Directory deletes old files.
Note: ntds.dit’in (New Technology Directory Service-Directory Information Tree)
Transaction’s Impact on Performance
While writing data to the disk, the sectors on the Hard Disk are constantly written, and as the data is deleted, the free space remains on the disk.
If the data is written in scattered areas, the reading performance of the data and therefore the working performance of the database decreases. In the process called Garbage Collection; By default, Active Directory performs online defragmentation every 12 hours. During this process, the fragmentation-related performance loss of the database is eliminated and the domain controller can continue to serve during the online defragmentation process.
However, while online defragmentation resolves the performance issue, the size of the database does not decrease and the size of ntds.dit continues to grow. To reduce the database size, offline defragmentation should be done. Creates a new, regular database file (Compact) .Offline defragmentation writes to the newly created compact database in all transactions that are in the transaction log and have not been transferred to the database yet. This means that during the offline defragmentation process, the domain controller will not be able to service your system. Therefore, it should be preferred to perform this operation outside office hours. Since online defragmentation already solves the performance problem, offline defragmentation should only be used to reduce the database size and a process that should be done very often. it is not.
As we mentioned in the previous sections, the transaction log and checkpoint system ensures the consistency of the information kept under a single database (data integrity). However, if we have more than one Domain Controller server keeping the same copy, we have to consider data consistency between the replicas of the database.
Database Consistency Between Domain Controllers
When we think about it, if the change is a modification or addition; data can be synchronized between servers with copies. But what if the change is a deletion? If the object is completely deleted during the deletion process, how can other servers other than replica that save the change understand this deletion and update their copies? This is why if an object is deleted, it is not actually removed from the database (purge), but instead, they are moved to a special container, deleted items container. The purpose of this process is to create enough time to ensure that other copies can update this deletion. The time between deletion and dropping from the database is to ensure that other copies, information about the deletion are transferred from source copies to other copies.