On the DPF environment, performing the "db2start DBPARTITIONNUM
<partition_num> ADD DBPARTITIONNUM hostname <host_name> port
<port#>" will always return -6048, if for any reason, it fails
to get the db cfg from the catalog node.
This defect fix will return the actual error why it failed to
get the db cfg from the catalog node
For example:
On the DPF environment, if the database X was removed/dropped on
the catalog node ONLY, then catalog-node's volume database
directory (local) will NOT have the entry of this database X
anymore. However this entry of database X still remains on other
partitions/nodes. In addition, this database X still remains in
the system database directory.
If user perform ADD DBPARTITIONNUM, e.g.
db2start DBPARTITIONNUM <partition_num> ADD DBPARTITIONNUM
hostname <host_name> port <port#>
then it will get the SQLCODE "-6048" (which is the communication
error) message:
03/10/2011 16:50:26 3 0 SQL1483N Add database partition
server processing for database partition server "3" failed.
Information returned for the error includes SQLCODE "-6048",
SQLSTATE " ", and message tokens "".
SQL1483N Add database partition server processing for database
partition server "3" failed. Information returned for the error
includes SQLCODE "-6048", SQLSTATE " ", and message tokens
"". SQLSTATE=5UA02
Note that: - ADD DBPARTITIONNUM picks up db entry from the
system database directory.
With this defect fix, it will return the following error
instead:
03/10/2011 16:50:26 3 0 SQL1483N Add database partition
server processing for database partition server "3" failed.
Information returned for the error includes SQLCODE "-1013",
SQLSTATE "4270", and message tokens "".
SQL1483N Add database partition server processing for database
partition server "5" failed. Information returned for the error
includes SQLCODE "-1013", SQLSTATE "4270", and message tokens
"". SQLSTATE=5UA02
In this example it is failing with -1013, which is:
SQL1013N The database alias name or database name "<name>"
could not be found. |
