This content has been marked as final. Show 5 replies
If the index daemon hits an error while trying to build the index data, it will stop and create a lock file so it doesn't try again. You can then investigate the problem and try to import the index data again.
It's possible the index files will just import if you try again, so you can just remove the lockfile and let the import process (obixd) run itself.
The indexes are in /usr/local/oracle/backup/admin/history/host, and the lockfile will be in the hostname folder and is NOUPDATE. Just remove this file and then obixd will process it. You'll then need to check the index log file for problems.
Thanks for this. Some time back we had an issue with our root file system filling up, which contains the backup catalogue. It's fairly clear that this was the cause of the NOUPDATE files being created. I'd already gone ahead and removed these files and everything is working OK now, but thanks for the insight.
I'd always intended to move the catalogue from the root file system, but have not got around to it as yet - I guess this will raise the priority a bit!
Glad I could help. To move the catalog I would suggest using a symlink /usr/local/oracle/backup and have that point to another disk such as /disk1/backup. That way all the links to /usr/local/oracle/backup still work. I've done that several times.
it would be useful to see the index daemon behaviour re. the creation of the NOUPDATE file documented somewhere in the OSB Admin Guide, since we went for a few weeks with these files in the catalogue preventing updates, and only stumbled across them when I tried to do a file restore.
Yes, I agree, I'll contact the doc team and see what we can do for the 10.3 release. I think we do need some kind of troubleshooting guide.