Kbase P70435: An idxbuild SOME builds all indexes after a previous index rebuild has terminated or been cancelled.
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
21/06/2007 |
|
Status: Verified
FACT(s) (Environment):
Progress 8.x
Progress 9.x
All Supported Operating Systems
SYMPTOM(s):
An idxbuild SOME sometimes builds all indexes after a previous index rebuild has terminated or been cancelled
An index rebuild (idxbuild) with SOME builds all indexes after an index rebuild failure.
Index reconstruction utility was aborted. Rerun it to completion.(651)
Can't find selected index list file .xb; assuming ALL. (2786)
CAUSE:
Bug# OE00096944
CAUSE:
The <dbname>.xb file may not exist in the working directory after a previous idxbuild command terminated. Because the <dbname>.xb file does not exist, all subsequent idxbuilds will be considered as an index rebuild against all tables.
FIX:
1. Upgrade to OpenEdge 10.0B or later to avoid this bug.
2. If problem occurs in a Progress 9 and you cannot upgrade use the following workaround:
Progress Technical Support recommends you backup your database before attempting any repair routine. If you cannot complete an index rebuild against your database, you will need to resort to the backup.
The idxbuild qualifier to the proutil command, accomplishes most of its work without displaying messages, unless it encounters an error condition.
If an idxbuild is interrupted while rebuilding a selected subset of indexes, the list of selected indexes is usually retained in a file named <dbname>.xb. The <dbname>.xb file is used by the proutil command when the idxbuild utility is restarted so that only the original listing of indexes are rebuilt when the
idxbuild utility is reran.
If the idxbuild utility is unable to locate the <dbname>.xb file, then it will assume ALL on the subsequent idxbuild command and will deactivate all indexes for the database. This action results in the user having to rebuild all indexes for a database instead of the original selected subset. This can be a painful experience depending upon the size and # of indexes in your database.
It is encouraged that if an idxbuild terminates for any reason, the DBA should ensure that the <dbname>.xb file exists in the current working directory where the idxbuild command is being issued. If the file does not exist, then you will want to create a <dbname>.xb file. This file must contain an exact listing of all tables/indexes that were being rebuilt prior to the failure. Failure to adhere to this recommendation could be potentially dangerous and result in index corruption. Especially if a user made a mistake in the <dbname>.xb, for example, put wrong tables/indexes or miss some tables/indexes in <dbname>.xb file. If this happens, in most cases, idxbuild will finish without reporting errors, however, the database might be damaged and the user wouldn't realize it until the database makes use of these damaged indexes.
Format of the dbname.xb file:
The file needs to have the <dbname>.xb for the file name. Example: sports2000.xb This file must exist in the working directory where the idxbuild command is going to be issued. When the idxbuild utility is ran, it looks in the current directory for the <dbname.xb> file. The contents of the <dbname>.xb file has the format of:
tableowner
tablename
indexname
This format needs to be repeated for all tables and indexes associated with the failed idxbuild. The file also needs to have an "!" exclamation point for the final entry. Example <dbname>.xb file below:
PUB
customer
name
PUB
customer
custnum
PUB
order
custorder
PUB
order
orderdate
!
When the idxbuild utility is reran, it will locate the <dbname>.xb file and display to the screen all tables and indexes which need to be rebuilt and will prompt for your approval prior to starting the idxbuild. It will then ask for information regarding sort space and then proceed with the rebuild.
Upon successful completion of an idxbuild command the <dbname>.xb file is deleted.