XADM: How to Detect and Remove Long Values in Exchange Server Database

ID: Q195856

The information in this article applies to:

SUMMARY

This article is intended as a brief "How To" to help you investigate and correct orphaned or corrupted long values in Exchange Server 5.5 databases. Before you proceed, it is important to define what a long value is and describe how orphaned and/or corrupted long values occur.

The steps outlined in this document are to be used in conjunction with Microsoft's Knowledge Base articles Q181824 regarding Corrupted Long Values and Q185271 regarding Orphaned Long Values. These articles can be found on the Microsoft TechNet CD or on the Internet. They discuss the orphaned and corrupted long value conditions in further detail.

For more information, please see the following Microsoft Knowledge Base articles:

Q181824 XADM: Exchange Database Engine Doesn't Detect Removed Page in B-tree Split Operation

Q185271 XADM: Orphaned LV Errors When Running ESEUTIL Consistency Checker

Long-Values (LVs)

Long-Values (LVs) are created when a column is too large to store with the rest of the record. Internally, the Exchange Server database engine breaks large columns into separate parts; these are the long-values. Long-Values are stored in a separate binary tree (B-Tree) and each LV is given a table- wide unique identifier (the Long value ID [LID]).

Orphaned Long-Values

To save space, the Exchange Server database engine provides the ability for multiple records to share the same long-value (similar to, but not exactly related to the store's concept of single-instance storage for messages). To do this, a reference count is attached to each long-value. When the reference count reaches zero, the long-value will be deleted. If the Exchange Server database engine is shut down (by a crash, power cut, or blue screen error messages) after deferencing a long-value, but before expunging it from the database, the long-value will be "orphaned," that is, its reference count will be zero, but it will never be removed. Orphaned long-values are invisible to anyone using the database because they are logically deleted, but still take up space because they have not been physically removed.

Corrupted Long-Values

As mentioned above, long values are stored as chunks of data in the long- value tree of a table. Each LV is prefixed by a header ("LVROOT") that contains the length and reference count of the LV. In rare cases (such as the b-tree split problem documented in Q181824), the LVROOT of a LV could be overwritten. This corrupts the long value, but doesn't actually lose any data. An Exchange server information store (store.exe) may crash or error out trying to access this LV.

NOTE: Starting with Exchange Server Service Pack 1, ESEUTIL /P is able to examine the database to determine the correct length and refcount of the LV and re-create its LVROOT.

Detecting Long-Values

Exchange Server 5.5 Service Pack 1 contains updated code that will prevent and repair Exchange Server 5.5 long value database anomalies. However, if your Exchange Server 5.5 database already contains orphaned or corrupted long values, applying Exchange Server Service Pack 1 alone will not fix them.

To remove orphaned (product of Store.exe crashes) or corrupted long values (the product of a defective B-tree split) in Exchange Server 5.5 databases; you must detect specific long values anomalies by running the Exchange Server integrity checker utility, ESEUTIL /G (with the /V and /X parameters for detailed output). This is considered the most reliable way to verify whether or not the Exchange Server database(s) contain specific anomalies.

Using this utility is a safe approach to testing database integrity because the ESEUTIL /G utility operates in a read-only mode. It is very important to detect the specific type of long value anomalies present in the Exchange Server database(s) in order to ensure the proper steps are taken to fix the database(s).

To check Exchange 5.5 Server for long value anomalies documented in the Microsoft Knowledge Base articles above, perform the following steps.

  1. Make and verify a full online backup of your Exchange Server databases.


  2. Stop all the Microsoft Exchange Server services gracefully using the Control Panel Services tool.


  3. Use the ESEUTIL /MH utility, used to dump the Exchange Server database header information, to verify the consistency of your database(s) by running the following from an MS-DOS command prompt:
    ESEUTIL /MH {path to EDB}\{db}.edb >dbdmp.txt
    For example: ESEUTIL /MH e:\exchsrvr\mdbdata\priv.edb >privdmp.txt

    NOTE: ESEUTIL /MH is a read-only utility and should not cause any damage to the database against which it is run.


  4. Review the corresponding text file, confirm the state is equal to consistent. This means the Exchange Server database has committed all transaction log files and the data contained within the database is consistent.

    NOTE: If your database is inconsistent, follow the proper disaster recovery steps as outlined in the Exchange Server 5.5 Disaster Recovery White Paper located on the Internet at the following URL:
    http://www.microsoft.com/exchange/55/whpprs/BackupRestore.htm


  5. After your database(s) have been verified as consistent, with the Exchange Server services stopped, run the ESEUTIL /G integrity checker against the database(s).
    ESEUTIL /G /{db} /V /X >dbchk.txt
    Examples:
    G:\>eseutil /g /ispriv /v /x >e:\privchk.txt
    G:\>eseutil /g /ispub /v /x >e:\pubchk.txt
    G:\>eseutil /g /ds /v /x >e:\dirchk.txt
    Past experience has seen ESEUTIL /G performance in the range of running for one and a half hours on a 30 GB private information store database. This was on a Compaq 7000 quad processor with 512 MB of RAM.

    NOTE: ESEUTIL /G is a read-only Exchange utility and should not cause any damage to the database against which it is run


  6. After the ESEUTIL /G has finished, search the output in the corresponding text file(s) for the following words. It is helpful to use the search or find feature included in most text editors.

    If you find an error in the text file, determine if this is an orphaned LV or a corrupted LV; please contact Microsoft Product Support Services if you need help. Make sure to search for both orphaned and corrupted long values.


It is possible to have both long value anomalies inside an Exchange Server database. After you have determined if your database(s) have any long value anomalies and the specific type of the anomaly (orphaned or corrupted), follow the corresponding Knowledge Base articles listed at the beginning of this article (Q181824 regarding Corrupted LVs and Q185271 regarding Orphaned LVs). This will include applying Exchange Server 5.5 Service Pack 1 and running the proper ESEUTIL utility to correct the anomalie(s).

NOTE: If both types of long values (orphaned and corrupted) are detected, it is recommended to repair the corrupted long values first. After the repair of the corrupted long values has completed successfully, then perform an offline defrag on the database(s) that contains the orphaned long values.

Make a full online Exchange Server backup of the Directory and Information Store databases after you have removed all long values from your Exchange Server databases.


MORE INFORMATION

Below are instructions on how to remove Orphaned or Corrupted Long-Values from Exchange Server 5.5 databases

Orphaned Long Values



To remove Orphaned Long Values in Exchange Server 5.5 databases, perform the following steps:

NOTE: To verify your Exchange Server databases exhibit the Orphaned LVs, please see the following Microsoft Knowledge Base article:
Q185271 XADM: Orphaned LV Errors Running ESEUTIL Consistency Checker
IMPORTANT NOTE: Verify there is adequate disk space available for ESEUTIL's temporary database, Tempdfg.edb. You can use the /T: parameter of ESEUTIL to redirect its location

  1. Stop the Microsoft Exchange System Attendant Service to shut down Exchange Server Services. You can do this from the Control Panel Services tool or by typing the following command from an MS-DOS Command Prompt:
    net stop msexchangesa


  2. It is recommended to stop any Windows NT services related to Exchange Server or monitors running against the Exchange Server. This includes Exchange Server and link monitors, SNMP agents, and/or related services.


  3. From an MS-DOS command prompt, change to the drive letter that contains enough available disk space to perform an offline defragmentation. This drive should contain enough free disk space for the size of the database being defragmented (roughly 110 percent of the size of the EDB file).


  4. To remove the Orphaned LVs from the Exchange Server database(s), type the following command(s) at an MS-DOS command prompt.

    NOTE: Allow each command to complete successfully before proceeding to the next one. You can verify this by looking at the corresponding text file, confirm "Operation complete successfully."
    G:\>eseutil /d /ispub >e:\pub-defrag.txt
    G:\>eseutil /d /ispriv >e:\priv-defrag.txt
    G:\>eseutil /d /ds >e:\dir-defrag.txt
    If you encounter JET error -1526 reporting Corrupted Long Values running the ESEUTIL /D on an Exchange Server database, check the corresponding ESEUTIL /G /V /X text file for possible corrupted long values. This - 1526 JET error can be seen while attempting to run an offline defrag, ESEUTIL /D. If this happens, it means your database may contain corrupted long values. Please refer to the section regarding removing corrupted long values from Exchange Server databases. After you complete the repair of corrupted long values, you should be able to perform an offline defrag of your Exchange Server database(s).


  5. After the defrag commands complete, verify there are no long value errors by running the following commands on the appropriate databases:
    G:\>eseutil /g /ispub /v /x >e:\pubchk.txt
    G:\>eseutil /g /ispriv /v /x >e:\privchk.txt
    G:\>eseutil /g /ds /v /x >e:\dirchk.txt


  6. After the Exchange Server utilities complete successfully, and you've verified no further long value errors in the Exchange Server databases, restart the Exchange Server services and other Windows NT services that were stopped.


  7. Perform a full online backup immediately after performing the above steps.


Corrupted Long Values

To remove Corrupted Long Values from Exchange Server 5.5 databases, perform the following steps:

NOTE: To verify that your Exchange databases exhibit the Corrupted LVs, refer to the following Microsoft Knowledge Base article:
Q181824 XADM: Jet Doesn't Detect Removed Page in B-tree Split Operation
IMPORTANT NOTE: ESEUTIL /P should ONLY be run if Corrupted Long Values have been detected.

NOTE: It is recommended to make a backup of the database prior to running ESEUTIL with the /P switch because the use of this switch can cause data loss.

  1. Stop the Microsoft Exchange System Attendant Service to shut down Exchange Server Services. You can do this from the Control Panel Services tool or by typing the following command from an MS-DOS command prompt:
    net stop msexchangesa


  2. It is recommended to stop any Windows NT services related to Exchange Server or monitors running against the Exchange Server computer. This includes Exchange Server and link monitors, SNMP agents and/or related services.


  3. From the MS-DOS command prompt, type the following command to remove Corrupted Long Values from Exchange Server databases:
    G:\>eseutil /p /{db switch} /v /x >e:\{dbname}repair.txt
    G:\>eseutil /p /ispriv /x /v >e:\PRI-repair.txt
    G:\>eseutil /p /ispub /x /v >e:\PUB-repair.txt
    G:\>eseutil /p /ds /x /v >e:\DS-repair.txt


  4. After the repair command completes, verify there are no long values errors by running the following commands on the appropriate databases:
    G:\>eseutil /g /ispub /v /x >e:\pubchk.txt
    G:\>eseutil /g /ispriv /v /x >e:\privchk.txt
    G:\>eseutil /g /ds /v /x >e:\dirchk.txt


  5. After the Exchange Server repair utility (ESEUTIL /P) completes successfully, and you have verified no that there are no further long value errors in the Exchange Server databases, restart the Exchange Server services and other Windows NT services that were stopped. There is no need to run ISINTEG -fix after ESEUTIL /P, (as indicated in the Microsoft Knowledge Base article Q181824 listed at the beginning of this article).

    NOTE: If there are any other errors reported in the ESEUTIL /G output (that is, errors other than corrupted or orphaned long values) then it may be necessary to run the ISINTEG utility to repair information store pointers. This is only necessary in the event ESEUTIL /P made repairs other than removing corrupted long values. Please contact Microsoft Product Support Services for more information regarding the running of ISINTEG and/or ESEUTIL to repair Exchange Server databases.


  6. Perform a full online backup immediately after performing the above steps.


Additional query words: btree split 1601 1603 1206 1069 JET_errVersionStoreOutOfMemory 100% 


Keywords          : 
Version           : winnt:5.5
Platform          : winnt 
Issue type        : kbhowto

Last Reviewed: April 15, 1999