For my case, it’s as simple as updating the hostname information defined in sqllib/db2nodes.cfg configuration file!
-http://www.walkernews.net/2007/09/07/how-to-fix-db2-sql6048n-error-of-db2start/-
2011年7月20日
2011年7月17日
Problems with restarting the upgrade process after database insertion failure
Symptoms
When you try to restart the process, using either the upgrade wizard (dsmupgdx) or commands, you receive messages that the database already exists, or that directories are not empty.
Causes
The problem occurs because a database instance was already created, despite the failure. Directories that you specified in the wizard or with the DSMSERV LOADFORMAT command might no longer be empty because the failed process started to write information in these directories. To do the formatting operation again, the directories must be empty.
Resolving the problem
Try the following actions to resolve the problem.
Ensure that you are logged in with the same user ID that you were using when the insertion operation failed. This should be the user ID that you created specifically for the server instance that you were upgrading when the failure occurred.
Attention: Ensure that you are using the correct user ID. The database that is owned by the user ID that you log in with now is the database that will be destroyed in the following step. Do not perform the following steps when you are logged in with a user ID that owns a valid, working V6 server instance.
Remove the database instance that was created.
dsmserv removedb TSMDB1
Alternate method: If the DSMSERV REMOVEDB command fails for some reason, use the DB2® command to drop the database. Issue the following commands:
db2start
db2 drop db tsmdb1
To reuse the database and log directories that you specified in the failed attempt to create the server instance, verify that each directory is now empty.
Restart the upgrade wizard for the server instance that you are upgrading.
If you are using commands, restart at the step in which you issue the DSMSERV LOADFORMAT command.
--http://publib.boulder.ibm.com/infocenter/tsminfo/v6/index.jsp?topic=%2Fcom.ibm.itsm.srv.upgrd.doc%2Fts_srv_upgrd_restartupgrd.html--
When you try to restart the process, using either the upgrade wizard (dsmupgdx) or commands, you receive messages that the database already exists, or that directories are not empty.
Causes
The problem occurs because a database instance was already created, despite the failure. Directories that you specified in the wizard or with the DSMSERV LOADFORMAT command might no longer be empty because the failed process started to write information in these directories. To do the formatting operation again, the directories must be empty.
Resolving the problem
Try the following actions to resolve the problem.
Ensure that you are logged in with the same user ID that you were using when the insertion operation failed. This should be the user ID that you created specifically for the server instance that you were upgrading when the failure occurred.
Attention: Ensure that you are using the correct user ID. The database that is owned by the user ID that you log in with now is the database that will be destroyed in the following step. Do not perform the following steps when you are logged in with a user ID that owns a valid, working V6 server instance.
Remove the database instance that was created.
dsmserv removedb TSMDB1
Alternate method: If the DSMSERV REMOVEDB command fails for some reason, use the DB2® command to drop the database. Issue the following commands:
db2start
db2 drop db tsmdb1
To reuse the database and log directories that you specified in the failed attempt to create the server instance, verify that each directory is now empty.
Restart the upgrade wizard for the server instance that you are upgrading.
If you are using commands, restart at the step in which you issue the DSMSERV LOADFORMAT command.
--http://publib.boulder.ibm.com/infocenter/tsminfo/v6/index.jsp?topic=%2Fcom.ibm.itsm.srv.upgrd.doc%2Fts_srv_upgrd_restartupgrd.html--
訂閱：
文章 (Atom)