Tuesday, 9 February 2010

SQL5043N when starting DB2 UDB 9.5 on Windows

Had a strange error today, where DB2 UDB would not start on a Windows 2003 box, having created and set up a new instance.

In essence, we'd created a new instance owner/admin ID under the Windows OS ( Start > Administrative Tools > Computer Management > Local Users and Groups > Users > Action > New User ) - this user was DB2ADMIN2 and was assigned membership of the DB2ADMNS group.

Having done this, we logged into Windows as this new user ( DB2ADMIN2 ), and created a new database instance: -

db2icrt DB2_2 -s ese -u db2admin2 -r 60010,60013

which assigns a port range of 60010-60013 to the new instance, of type Enterprise Server Edition.

Having done this, we added the line: -

db2c_DB2_2 50001/tcp

to C:\Windows\system32\drivers\etc\services.

This sets up port 50001 as the JDBC listener, which makes sense given that the first instance ( DB2 ) is listening on 50000.

We then attempted to start the instance: -

set DB2INSTANCE=DB2_2
db2 update database manager configuration using SVCENAME db2c_DB2_2
db2set DB2COMM=npipe,tcpip
db2stop
db2start

Sadly, the latter command failed with: -

02/09/2010 17:32:34     0   0   SQL5043N  Support for one or more communications protocols failed to start successfully. However, core database manager functionality started successfully.

A quick check with the command: -

netstat -aon | find "5000"

showed that the first instance was listening away happily on 50000, but that the second instance just did not want to start up on 50001.

After much faffing about, my instructor/colleague, Stephen Hardison, asked me to re-edit the C:\Windows\system32\drivers\etc\services file, using Notepad ( of course ), and add an extra Carriage Return (CR/LF) to the end of the file.

Having done this, and saved the file, we ran the commands: -

db2stop
db2start

and, c'est voila, the same netstat command showed that both 50000 *AND* 500001 were listening away merrily.

The moral of the story - don't use Notepad to edit files and ensure that there is an extra CR/LF at the end of the services file.

Simple when you know how :-)

1 comment:

Jason Moore said...

Dave - I hit this problem today. Your blog post saved me! Thanks.

Note to self - use kubectl to query images in a pod or deployment

In both cases, we use JSON ... For a deployment, we can do this: - kubectl get deployment foobar --namespace snafu --output jsonpath="{...