The AppServer has become an integral part of Data Protector. When it fails neither user authentication, scheduling or reporting will work. A critical issue has been identified that may cause upgrades to fail and/or run-time issues caused by invalid data stored in the jce_service_description and jce_service_property tables in the Data Protector JCE database.
Symptoms
During or after the upgrade from 8.1x or 9.x to 10.x you notice some or all of the following:
- AppServer is unresponsive or slowly responding when running omnidbutil -migrate_schedules
- Java process is causing very high CPU load on Cell Manager
- The progress is slow and only returns errors (e.g. pausing quartz scheduler…failed)
- Java Exceptions and stack overflow getting logged in AppServer server.log
- Backup sessions not getting executed while scheduler is active and jobs are scheduled
- Data Protector JCE database (part of IDB, used by Advanced and Consolidated Scheduler) is very large
- Check the file size of dpjce-data.idb generated by omnidbutil -writedb prior to the upgrade
Workaround
- Perform an IDB backup (e.g. IDB online backup or omnidbutil -writedb)
- Stop the Data Protector services, but leave the IDB up by executing
omnisv -stop -noidb
- (Optional) Remove old logfiles from the log/AppServer directory
- On Linux/HP-UX Cell Managers execute:
cd /opt/omni/sbin/dbscripts/CPE omnidbutil -run_script QCCR2A65778_jce_purge_expired_records.sql -jce -detail
- On Windows Cell Managers execute:
cd "%DP_HOME_DIR%\bin\dbscripts\CPE" omnidbutil -run_script QCCR2A65778_jce_purge_expired_records.sql -jce -detail
- Start the remaining services by executing
omnisv -start
- Run whatever command previously failed (e.g. omnidbutil -migrate_schedules, perl userMigrate.pl, etc.)
Notes
The procedure above can be executed prior or after the upgrade. Just make sure to restart the AppServer after executing the SQL script.