Causes of administrative repository corruption
Some of the multiple potential causes of repository corruption are:
- Manual changes to the repository. This is not recommended
or supported.
- Deleting or adding any files under
install_root(always use administrative tools such as the
administrative console, WSCP, XMLConfig, or AAT). Manual updates are not
recommended or supported. The exceptions to this are when support
personnel asks you to modify or delete trace files.
- In a multi-node environment, applying updates such as a
PTF, Interim Fix, or Java™ SDK to one node while other nodes are running
and using the repository database.
- In a multi-node environment, having different PTF/Interim
Fix/JDK (in a single Domain all the Nodes must be at same level).
Symptoms of a corrupted administrative repository
There is no particular symptom for a corrupted repository, but here are
some indicators:
- Missing topology in the administrative console.
- Other administrative tools, such as WSCP or XMLConfig do
not work properly.
- Admindbcheck tool reports error. You can get this tool
from WebSphere Support.
Confirming administrative repository corruption
Follow the following procedure to create a new administrative
repository:
- Create a new WebSphere Application Server administrative repository
database.
- Edit the admin.config file in the $WAS_HOME\bin directory to include
the following changes:
install.initial.config=true
com.ibm.ejs.sm.adminServer.createTables=true
com.ibm.ejs.sm.adminServer.dbdatabaseName=<New Administrative
Database>
com.ibm.ejs.sm.adminServer.dbuser=<UserName>
com.ibm.ejs.sm.adminServer.dbpassword=<UserPassword>
#URL is only valid for Oracle
com.ibm.ejs.sm.adminServer.dbURL=
If you do not want the new repository to contain the default
configuration, such as the Default Application, then leave the
install.initial configuration set to false as follows:
install.initial.config=false
- Save the changes to the admin.config file.
- Start the WebSphere Application Server services (adminserver).
- If the problem is not present with the new repository, it is likely
that the repository is corrupted.
- If the problem is still present with the repository, it is likely that
the repository is not corrupted.
Recovering from a corrupted repository using database backup
This option assumes you have a backup procedure in place for the
administrative repository.
- Stop WebSphere Application Server.
- Restore the WebSphere Application Server database from backup.
- Start WebSphere Application Server and the Administrative
Console.
Recovering from a corrupted repository using XMLConfig export and
import
This takes more time than using the database backup method and assumes
that you have used XMLConfig export to backup your latest
configuration.
- Create a new WebSphere administrative repository database.
- Start WebSphere Application Server with the new repository. See
Confirming administrative repository corruption.
- Make sure all the administrative tools are working with the new
repository.
- Import your most recent XML configuration.
Suggestions
- Take the same precautions with the WebSphere
administrative repository database as you would for any other application
database.
- Always back up the database.
- Make sure the database backup is up-to-date.
|