Eddie C wrote: > I ran > DB ERROR: db_verify: Page 30: out-of-order key at entry 498 > DB ERROR: db_verify: DB->verify: db/o_com/channelcontentowner.db4: > DB_VERIFY_BAD: Database verification failed I'm assuming that you are running the correct version of db_verify (it should perform a version check on the magic number in the region files, so I think it has to be the right one). My best guess here is that the process by which a new file is added to a running DB environment went wrong somehow. The details have changed a few times over the years and it is just possible that the current FDS code is not up to date. Potentially the 'problem' would be fixed by simply stopping and re-starting the server (because the environment would see all the files closed and then re-opened). I do know that the process for adding a new file to the environment is correctly followed in the newer code that deals with individual back-end restore from archive. Perhaps the online index code is not using the same underlying function. I haven't taken the time to examine the code though. The problem I'm thinking about arises when a file that was created using one db environment (a temporary one, such as is used when building an index), is opened within another environment, 'bad stuff' can happen along the lines of what you are seeing. There is state in the file that references the old environment, which is now stale vs. the new one. db_verify sees that and barfs. It is possible to avoid this happening but one has to be careful to make the right calls in the correct order (the details of which I forget now). As Rich and Noriko said, if you just re-import after creating the indices this issue (if it is indeed the one I'm thinking of) will be avoided because all the files are created at the same time under the same db environment.
