there are no 'best practices'. you do exactly what you did - new install on a new box.
what kind of performance issues are they experiencing ?
Theyre having several issues,
- Reports stopped working and ETL runs are generating errors
- when upgrading BSA app server they had to reinstall the server completely, due to errors
- When jobs (any type) are running, the application server resources (e.g. CPU) become saturated and eventually become a run-away process requiring an admin to kill the process thread to release CPU utilization from 100% back to normal.
- When adding a new server object or modifying an existing objects properties, the object dictionary forces them to answer a lot of fields that have no default value for new required fields.
- they are running 2 app servers on 2 RHEL5x64 VMs (with 3 server instances on each app server- 2 Job and 1 Config) with Oracle 11g DB.
Is there anything in the DB that could be pointing to an old x86 arch setting or needs updating via script?
As part of health check recommendations to the customer Im asking them to check the following,
1. check java version on RHEL, if its still referencing 32 bit java installation (check JAVA_HOME path), check what version and arch type of java is installed
2. did they upgrade RSCD agent on the Application server, File server and Reports server to be a 64 bit agent
3. check min hardware requirements for BSA app server
4. Did they install BSA AppServer x86 or x64 installer on the new RHEL5x64 hosts?
trying to see if I missed any other areas for them to check on.
yeah - so i'd start w/ the 32bit install on a 64bit host. you may need to re-install if that is the case.
how much memory and CPU is allocated to the VMs, and what is the max heap size setting for the appserver instances ?