hi,
omnidbceck -extended????
I found other notes:
- The most likely cause is that the Data Protector database service (rds.exe) has died. Sometimes simply stopping and restarting the Data Protector services will rectify this.
- The system may have crashed during a backup and this error is reported on a reboot.
- A backup session may have hung and the Data Protector processes and services were killed due to the inability to stop the session/services normally.
- A check of the RDS.* log files under %OMNIBACK_HOME%\server\db40\datafiles\catalog can be useful in identifying the cause of the problem.
High CPU for RDS and RDS crashing is usually caused by memory allocation problems. To avoid the problem in the future check the kernel for maxdsiz and add the omnirc variable _M_ARENA_OPTS=1:32.
1) Is there enough memory and shared memory on the system?
The DP Release Notes state the minimum kernel parms for:
- maxdsiz (Max Data Segment Size) to at least 134217728 bytes (128 MB). <<<< If problems persist with RDS then increase higher.
- semmnu (Number of Semaphore Undo Structures) to at least 256.
2) Add environmental variable to the .omnirc file on the cell manger. Rename /opt/omni/.omnirc.TMPL to /opt/omni/.omnirc and add the uncommented statement:
_M_ARENA_OPTS=1:32
Then restart the DP daemons.
Explanation:
On HP-UX memory usage by process is limited to approximately 960 Mb (if MAXDSIZE variable is set lower than limit is even lower) multithreaded processes by default because of some memory locking optimizations use 4 arenas per process. This means that each of 4 threads in process has its own memory arena. This can cause processes to use 4 times more memory as it should (each thread has its own block of same data). _M_ARENA_OPTS environmental variable is used to set the number of arenas.
Get reports from "omnidbuitl -info" and "omnidbutil -extendinfo" ,and post, looks like some corruption on you IDB.
Also , the space on hard drive is fine??
Regards