The database engine used by Exchange Server is Extensible Storage Engine (ESE). It is a client-server based system that is quite relational in nature and is a single-user database model. In addition to this, the DB is quite stable for storing hierarchal data like mailboxes, folders, mails, attachments etc.
Exchange Server is generally termed as a transaction-based mailing system. To understand what a transaction is, simply consider it as a set of operations that are processed against a database. It can be change in an email state (read/unread), sending or receiving a mail, moving or deleting message from a folder etc. A transaction is committed to the ESE database only when it satisfied the following test:
Atomic: All operations involved in completing a transaction should take place successfully or none of them should be processed.
Consistent: When a transaction is committed to the database, it converts the database into a consistent state.
Isolated: Changes done to a transaction will be reflected in a database only when it is committed to the database.
Durable: A committed transaction will make the database safe even in case of system crash.
Further, a transaction should reach the database after being written to the memory. Just consider an example: You want to move a message from one folder to another. In this case, following operations will take place at the backend to complete the transaction:
Now, if any of the operation will not get executed, the message will not be moved from one folder to another successfully. This means a transaction will not be complete until it satisfies the atomicity test. Further, if everything happens to take place accordingly, the transaction will be committed to the DB making it consistent. After this the changes will be visible to the end user and then no matter what happens the database is durable.
The word Recovery and Restore is generally considered to be same which they have different meaning. Restore means the database and the log files are brought back to operational state while Recovery means replaying the log files against the restored database. The act of replaying the logs helps to make the database updated, i.e. uncommitted transactions will be written to the database. Therefore, i order to perform recovery operation, it is important to have log files available.
However, if you need log files or not completely depends upon the fact if the restored database is in dirty or clean state. Let us discuss the situation that requires log files availability to bring back the database into functional state.
Soft Recovery: It is automated process. When an Exchange Server is started after an unexpected stop, all transaction logs will automatically rollback to bring the database into consistent state as it was before erroneous operation. In this case, the logs files to be replayed are decided by the checkpoint file that keeps a track of all uncommitted transactions.
Hard Recovery: Here, transaction logs are replayed against the database that restored from backup. This recovery has to be processed manually and only those logs will be replayed that are stored in restored.env. When a backup is restored, the restore.env file gets saved in temporary folders that works like a checkpoint file, i.e. defines a range for transaction logs to be replayed. Any log file after restore.env range will not be replayed.
If a database is mounted on Server, it will definitely be in dirty/inconsistent state because a number of transactions take place continuously. If a database is in dirty state, then it is mandatory to have log files available. In case of hard recovery, the requirement of log files for recovery depends upon what kind of backup is created. Let us understand this with example:
#1: If an online backup of Exchange database is created, then in that case the backup will definitely be in dirty state. If the database is active and its backup is being created, then obviously some of the transactions must be taking place at the backend and most probably are not written to the database. In that case the backup thus created will be inconsistent in spite of the type of backup.
If the backup is in dirty state but log files are unavailable, all transactions that are still uncommitted will be rolled back. However, if the restored database is dirty and log files are missing, then in that case the only solution is to repair database using ESEutil /p command.
#2: If an offline backup is created, it means the database is brought down from the Server before the process actually starts. In an offline state, the DB does not have pending transactions to be written to the database which means the backup thus created is in consistent state. Therefore, you have the option to recover Exchange database missing log files.
From the above information, we can conclude the following factors regarding Exchange database recovery without log files:
#1: If the database against which the log files are to be replayed is consistent in state, then there is no requirement for log files for recovery.
#2: If the restored database is inconsistent, then log files are required for bringing back it into consistent state.
#3: If the database is inconsistent and no log files are available, then the only option is to repair the database using ESEutil.
As it is a known fact that repairing database leads to loss of some data, another option that can adopted as an alternative to repair Exchange database with missing log files is to use a third party EDB recovery solution. These tools aim at recovering inconsistent Exchange database without log files.