DOCUMENT:Q195856  26-MAY-2001  [exchange]
TITLE   :XADM: How to Detect and Remove Long Values in Exchange Database
PRODUCT :Microsoft Exchange
PROD/VER::5.5
OPER/SYS:
KEYWORDS:

======================================================================
-------------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft Exchange Server, version 5.5 
-------------------------------------------------------------------------------


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 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 LV (similar to, but not exactly related to
the information store concept of single-instance storage for messages). To do
this, a reference count is attached to each LV. When the reference count reaches
zero, the LV is deleted. If the Exchange Server database engine is shut down (by
a crash, power cut, or blue screen error messages) after dereferencing an LV,
but before expunging it from the database, the LV will be "orphaned," that is,
its reference count is set to zero, but it is never removed. Orphaned LVs 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, LVs 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 article Q181824), the LVROOT of an LV can be overwritten. This
corrupts the LV, but doesn't actually lose any data. An Exchange Server
information store (Store.exe) may stop responding 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 prevents and
repairs Exchange Server 5.5 LV database anomalies. However, if your Exchange
Server 5.5 database already contains orphaned or corrupted LVs, applying
Exchange Server Service Pack 1 alone will not fix them.

To remove orphaned (product of Store.exe crashes) or corrupted (the product of a
defective B-Tree split) LVs in Exchange Server 5.5 databases, you must detect
specific LV 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
databases 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
databases in order to ensure the proper steps are taken to fix the databases.

To check Exchange Server 5.5 for LV anomalies documented in the Microsoft
Knowledge Base articles above:

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 databases 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/techinfo/administration/55/BackupRestore.asp

5. After your databases have been verified as consistent, with the Exchange
   Server services stopped, run the eseutil /g integrity checker against the
   databases.

   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 Server utility and should not cause
   any damage to the database against which it is run

6. After Eseutil /g has finished, search the output in the corresponding text
   files for the following words. It is helpful to use the search or find
   feature included in most text editors.

    - Error

    - Orphaned

    - Corrupted

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

It is possible to have both LV anomalies inside an Exchange Server database.
After you have determined if your databases have any LV anomalies and the
specific type of the anomaly (orphaned or corrupted), follow the corresponding
Knowledge Base articles listed at the beginning of this article. This includes
applying Exchange Server 5.5 Service Pack 1 and running the proper Eseutil
utility to correct any anomalies.

NOTE: If both types of LVs (orphaned and corrupted) are detected, repair the
corrupted LVs first. After the repair of the corrupted long values has been
completed successfully, perform an offline defragmentation on the databases that
contain the orphaned LVs.

Make a full online Exchange Server backup of the directory and information store
databases after you have removed all LVs from your Exchange Server databases.

MORE INFORMATION
================

Below are instructions on how to remove orphaned or corrupted LVs from Exchange
Server 5.5 databases

Orphaned Long Values
--------------------

To remove orphaned LVs in Exchange Server 5.5 databases:

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 the Eseutil
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. 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, 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 databases, type the
   following commands at an MS-DOS command prompt.

   NOTE: Allow each command to finish 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 LVs running 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 defragmentation, Eseutil /d. If this
   happens, it means your database may contain corrupted LVs. Please refer to
   the section regarding removing corrupted LVs from Exchange Server databases.
   After you complete the repair of corrupted LVs, you should be able to perform
   an offline defragmentation of your Exchange Server databases.

5. After the defragmentation commands finish, verify there are no LV 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 finish successfully, and you've verified
   no further LV errors exist 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 LVs from Exchange Server 5.5 databases:

NOTE: To verify that your Exchange Server 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 LVs have been
detected.

NOTE: 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. 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 LVs 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 isinteg to repair information store pointers. This is only
   necessary in the event eseutil /p made repairs other than removing corrupted
   LVs. Please contact Microsoft Product Support Services for more information
   regarding the running of isinteg 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          :  
Technology        : kbExchangeSearch kbExchange550 kbZNotKeyword2
Version           : :5.5
Issue type        : kbhowto

=============================================================================

THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS
PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND.  MICROSOFT DISCLAIMS
ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES
OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.  IN NO
EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR
ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL,
CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF
MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE
POSSIBILITY OF SUCH DAMAGES.  SOME STATES DO NOT ALLOW THE EXCLUSION
OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES
SO THE FOREGOING LIMITATION MAY NOT APPLY.

Copyright Microsoft Corporation 2001.