No start database manager command was issued

[DB Lover]

Hi All:

I'm encountering the below error in DB2 9.7 FP 3a (Enterprise Edition)
on a Windows 2008 64 bit server:

"SQL1032N No start database manager command was issued.
SQLSTATE=57019"

This happens locally on the DB2 server whenever a connection is
attempted to an instance or a database node, whether if I use db2clp
or DB2 Control Center. However, remote connections are not affected.
Saying this, all our client applications are still able to operate
normally. When I tried changing the cataloging type from LOCAL to
REMOTE on the server for an instance, I was able to access to that
particular instance/database without any issue. Here are what I've
tried as a part of root cause identifications:

- Checked on the instance/ Windows service and make sure DB2 instances
are started
- Checked on the license status. All license info is correct and valid
- Removed and reapplied the license file, restarted the license
Windows service

I've also tried other basic troubleshooting stuff, but still not able
to make the error disappeared. I would appreciate if any of you can
give me a hand or provide sugguestions to a resolution for the
problem.

Thanks in advance.

[MarkB]

Hi,

do you see the same when you run your commands from local
db2cmdadmin.exe (which is run from user with sysadm authority and with
full administrative privileges)?

Sincerely,
Mark B.

[DB Lover]

> Mark B.- Hide quoted text -
>
> - Show quoted text -

Hi Mark,
I got the same thing with db2cmdadmin command line window.

Thanks

[mike]

Is your Windows userid-account a member of local administrators group
on this Windows server?

In the db2cmdadmin.exe window - what's the value of DB2INSTANCE ? is
it the same as the instance to which you want to ATTACH ?

[DB Lover]

Mike,

I'm a member of domain admins group which is also a member of local
administrators group.

Yes, the instance is the same as the one I try to attach. Here are
what I got:


C:\Program Files\IBM\SQLLIB_01\BIN>db2 get instance

The current database manager instance is: DB2_01


C:\Program Files\IBM\SQLLIB_01\BIN>db2 attach to db2_01

SQL1032N No start database manager command was issued.
SQLSTATE=57019

C:\Program Files\IBM\SQLLIB_01\BIN>set db2instance=test

C:\Program Files\IBM\SQLLIB_01\BIN>db2 get instance

The current database manager instance is: TEST


C:\Program Files\IBM\SQLLIB_01\BIN>db2 attach to test

SQL1032N No start database manager command was issued.
SQLSTATE=57019

** Btw, we run two DB2 copies on the server ( 9.7.3a & 9.5.5). The 9.5
copy has no issues at all.

[Ian]

Maybe these are silly suggestions, but:

What do you get from the db2level command? Hopefully it matches
the version you expect for the particular instance you're having
issues
with.

What happens if you try to start the instance?

Also, make sure that you do "db2 terminate" before trying to
switch between instances – especially if they are on different
code levels.

[DB Lover]

> code levels.- Hide quoted text -

>
> - Show quoted text -

Ian,

They're basic stuff that I've done. Everything shows correctly. I
always go to the correct DB2 command tools to get to the DB2 copy
interface/environment I want to manage, so should be no mixing nodes
between the two copies.

When it happened the first time, we had a chance to reboot the server.
Everything was back to normal after that. However, days later, the
issue popped up again. I'm a bit confused over this, honestly. Perhaps
it's a bug with DB2 9.7.3a?

To your curiosity:

C:\Program Files\IBM\SQLLIB_01\BIN>db2level
DB21085I Instance "DB2_01" uses "64" bits and DB2 code release
"SQL09073" with
level identifier "08040107".
Informational tokens are "DB2 v9.7.301.326", "s101006", "IP23214", and
Fix Pack
"3a".
Product is installed at "C:\PROGRA~1\IBM\SQLLIB~1" with DB2 Copy Name
"DB2COPY2".

C:\Program Files\IBM\SQLLIB_01\BIN>db2 attach to test
SQL1032N No start database manager command was issued.
SQLSTATE=57019

C:\Program Files\IBM\SQLLIB_01\BIN>set db2instance=test

C:\Program Files\IBM\SQLLIB_01\BIN>db2 get instance

The current database manager instance is: TEST

C:\Program Files\IBM\SQLLIB_01\BIN>db2start
02/07/2012 10:50:14 0 0 SQL1026N The database manager is
already active.
SQL1026N The database manager is already active.

[mor]

Sounds like possible buggy behaviour but things are sometimes not what
they appear...

If it worked after a reboot, and then stopped working, do you know
what changed before it stopped working? (I know it's an obvious
question that you probably considered carefully
but some sites have strong change control that can help here).

In particular were there any changes to the node directory (or node
directories)?

Are the nodes cataloged as local nodes or as TCPIP nodes?

Does it make a difference if you try the other type of node?

Does the symptom change if you ensure there are no 9.5 local CLP
sessions *and* no locally originated instance-attachments running
before you try attaching in a local 9.7.x CLP session?


If there is a maintenance window, does the symptom change if the other
instances are stopped?

[mor]

One other question: which DAS is running? Is it the one from 9.5 or
9.7? Has the DAS config changed between the time it worked and when
it stopped working?

[DB Lover]

I tried it yesterday with the test instance. It works after the
restart of the instance as well. Talking about changes, we recently
created a new 9.7 instance and set it to run as a Local System Account
(the other instances are running under different domain user
accounts). However, we have two identical servers that have the same
number of databases/instances/DB2 coppies. The other server has no
issue.

As mentioned earlier, the error is gone if the node is catalogged as
TCPIP. I also have a test server with the same setup but I could
reproduce the error there.

The DAS is currently running on 9.5, but we have been running 9.5 and
9.7 for over 6 months without issues.

I'm trying to narrow down to exactly the way you suggested, the
instance level, or individual components. The challenge here is that
the test instance is now back to normal after the restart, and I can't
interrupt the production instances.