|
Problem IC60202
|
Status: Closed |
WHEN NSE GET WINDOWS ACCESS VIOLATION, TEXT INDEXES BECOME CORRUPT. |
| product: |
DB2 NET SEARCH / 5765F3802 / 910 - DB2 |
| Problem description: |
Text Indexes become corrupt if any program pervent NSE write
operation from completeing during index update operation. |
| Problem Summary: |
PROBLEM DESCRIPTION:
Text Indexes become corrupt if any program prevent NSE write
operation from completing during index update operation.
The reason for corrupt indexes is File access violation.
Anti virus scan or any other user application can request
exclusive access to files in the index or work directory
during a text index update or index reorganization operation
resulting in a program termination due to access violation
(this condition has only been observed on Windows). |
| Local Fix: |
Make Sure the windows indexing servives, anti virus programs and
back up programm do not access the text index or working
directories, during an update operation. |
| available fix packs: |
DB2 Version 9.1 Fix Pack 8 for Linux, UNIX and Windows
DB2 Version 9.1 Fix Pack 9 for Linux, UNIX and Windows
DB2 Version 9.1 Fix Pack 10 for Linux, UNIX and Windows
DB2 Version 9.1 Fix Pack 11 for Linux, UNIX and Windows
DB2 Version 9.1 Fix Pack 12 for Linux, UNIX and Windows
|
| Solution |
Fixed in V91 Fix Pack 8
Retry logic for the index file access
The existing implementation for GTR/GT9 libraries for NSE will
terminate with an error if an index file is not accessible
during an index update operation. The index file may not be
accessible if any other application has locked the file. This
causes NSE to terminate the index update and the index may get
corrupted.
To avoid index corruption in such cases, retry logic is
implemented for the windows platform, in order to protect files
against locking violations/sharing issues. With this
implementation, if a file is not accessible i.e. failed to
open/rename/remove file by GTR/GT9 during an index update
operation, the file access operation will be retried. This
number of retry and delay of each retry are defined by macro and
not configurable during runtime. The retry time for any failed
file access would be approximately 10 minutes.
If the file cannot be accessed even after the 10 minutes
interval, the index update could still terminate and leave the
index corrupted. Kindly refer the following Technote to handle
this situation.
http://www-01.ibm.com/support/docview.wss?rs=71&uid=swg21323089 |
| Workaround |
not known / see Local fix |
| Timestamps |
Date - problem reported :
Date - problem closed :
Date - last modified :
| 03.03.2009
27.10.2009
27.10.2009 |
| Problem solved at the following versions (IBM BugInfos) |
9.1.FP8
|
| Problem solved according to the fixlist(s) of the following version(s) |
| 9.1.0.8
|
 |
