SQL5043N
Lennart Jonsson
We have setup a new physical server, with a number of virtual servers on
top of it. When we run db2start on any of the virtual servers we get:
~]$ db2start
SQL5043N Support for one or more communications protocols failed to
start successfully. However, core database manager functionality started
successfully.
]$ echo $?
6
Everything seems to be working fine, and it is possible to do both local
and remote connections to databases. Both db2tcpcm and db2ipccm appears
to be running:
~]$ db2pd -edus | grep cm
15 47018219137344 16577 db2tcpcm
0.000000 0.000000
14 47018223331648 16576 db2ipccm
0.000000 0.000000
The only protocol specified is tcpip:
# db2set | grep DB2COMM
DB2COMM=tcpip
and /etc/services seems ok:
~]$ grep db2 /etc/services
db2c_db2inst1 50000/tcp # DB2 related
Any ideas what might cause the error message?
/Lennart
Ian
wrote:
What messages do you get in db2diag.log ?
globomike
wrote:
Hi Lennart,
besides looking into db2diag.log - which is alwaysa good idea - I
think the problem could be in the one part of the communication
definition which you did not show us:
DBM CFG - SVCENAME
You have to configure SVCENAME - set it to the portname and restart
the instance....
best regards
Michael
Lennart Jonsson
[...]
> Hi Lennart,
>
> besides looking into db2diag.log - which is alwaysa good idea - I
> think the problem could be in the one part of the communication
> definition which you did not show us:
> DBM CFG - SVCENAME
> You have to configure SVCENAME - set it to the portname and restart
> the instance....
>
The dbm cfg is the same as on the machines where it is working:
~]$ db2 get dbm cfg | grep SVCENAME
TCP/IP Service name (SVCENAME) = db2c_db2inst1
~]$ grep db2 /etc/services
db2c_db2inst1 50000/tcp # DB2 related
db2diag.contains some info, but I can't make much out of it. There are a
number of entries looking like:
2010-11-29-14.50.53.979641+060 I14015590E430 LEVEL: Severe
PID : 14474 TID : 47769024719168PROC : db2sysc
INSTANCE: db2inst1 NODE : 000
APPHDL : 0-6
EDUID : 17 EDUNAME: db2spmrsy
FUNCTION: DB2 UDB, syncpoint manager, sqlcspl_pgrlg, probe:140
DATA #1 : Dumped object of size 2123480 bytes at offset 0, 60 bytes
/opt/nya/users/db2inst1/sqllib/db2dump/14474.17.000.dump.bin
Looking at a server where the problem does not appear, I see two edus:
db2spmlw
db2spmrsy
according to my friend google they are related to the syncpoint manager,
so perhaps that is a clue. I also found a warning message on one of the
restored databases regarding syncpoint manager, so I will see whether
dropping this db solves the problem.
Thanks for your post
/Lennart
Lennart Jonsson
[...]
> What messages do you get in db2diag.log ?
>
Hi Ian, see my response to globomike in this thread
/Lennart
Ian
wrote:
OK. I have seen an error in the past where there's SPM log
corruption, but I don't remember what the db2diag.log entries look
like. Is the SPM_NAME dbm cfg parameter set for your instance? This
enables the SPM protocol.
IFF this is the case, then the solution is basically to ensure that
there aren't any indoubt transactions (using LIST DRDA INDOUBT
TRANSACTIONS), and if there aren't, then shut down the instance,
remove the SPM log files (see SPM_LOG_PATH dbm cfg for location) and
restart the instance. DB2 will automatically generate new SPM log
files. This procedure is described (kind of) for the error SPM0439N
in the documentation.
Ian
Lennart Jonsson
> On Nov 29, 11:57 am, Lennart Jonsson <erik.lennart.jons...@gmail.com>
> wrote:
>> On 2010-11-29 18:20, Ian wrote:
>> [...]
>>
>> > What messages do you get in db2diag.log ?
>>
>> Hi Ian, see my response to globomike in this thread
>>
>
> OK. I have seen an error in the past where there's SPM log
> corruption, but I don't remember what the db2diag.log entries look
> like.
Found one:
2010-11-30-05.40.35.168591+060 I14212428E364 LEVEL: Severe
PID : 3058 TID : 47146329958720PROC : db2sysc
INSTANCE: db2inst1 NODE : 000
APPHDL : 0-6
EDUID : 17 EDUNAME: db2spmrsy
FUNCTION: DB2 UDB, syncpoint manager, sqlcspm_readlog, probe:10
MESSAGE : SPM0438 The Sync point manager recovery log is bad.
> Is the SPM_NAME dbm cfg parameter set for your instance? This
> enables the SPM protocol.
It is indeed set (but as far as I can tell to a dummy value). It is set
on all instances in this environment that I have looked at. I tried to
read up om SPM but I couldn't find much ( I haven't heard of it before :-).
I'm pretty sure we can remove the setting ( guess someone used it to
something at some point in history ), since we don't use any
functionality provided by it.
>
> IFF this is the case, then the solution is basically to ensure that
> there aren't any indoubt transactions (using LIST DRDA INDOUBT
> TRANSACTIONS), and if there aren't, then shut down the instance,
> remove the SPM log files (see SPM_LOG_PATH dbm cfg for location) and
> restart the instance. DB2 will automatically generate new SPM log
> files. This procedure is described (kind of) for the error SPM0439N
> in the documentation.
>
I guess the files won't have to deleted if the cfg is changed, but it's
probably a good idea anyhow.
Thanks for your suggestions, much appreciated
/Lennart
Lennart Jonsson
[...]
>
> I guess the files won't have to deleted if the cfg is changed, but it's
> probably a good idea anyhow.
>
Hmm, not sure how to turn off SPM. Any idea? I checked another instance
and there it is empty:
SPM name (SPM_NAME) =
according to the docs it is defaulted to the hostname.
Anyhow, stopping the instance and removing SPMLOG.LCF and the files in
SPMLOGSD solved the problem.
/Lennart