db2 v8.1 config question.

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

Dan Cave - 12 Jul 2006 16:00 GMT

Hi all.

I have a db2 server running on solaris v8, which we have recovered from
tsm backup onto another machine which has the same hostname/ip as the
live server, but on a different lan (non connected)

When I start the db2 processes via /etc/rc.db2 i appear to get the same
processes as one would expect, however the following doesn't seem to
work correctly.

bash-2.03$ db2 connect to tec
SQL30081N A communication error has been detected. Communication
protocol
being used: "TCP/IP". Communication API being used: "SOCKETS".
Location
where the error was detected: "192.168.33.55". Communication function
detecting
the error: "connect". Protocol specific error code(s): "146", "*",
"*".
SQLSTATE=08001

192.168.33.55 is not the ip address of the db2 server which i've
restored onto. Would anyone happen to know the configuration file which
this address is stored in, or how I would go about correcting this ?

Thanks in advance.

Reply to this Message

Challenge - 12 Jul 2006 16:31 GMT

Is it in $HOME/sqllib/db2nodes.cfg?

> Hi all.
>
[quoted text clipped - 22 lines]
>
> Thanks in advance.

Reply to this Message

Dan Cave - 12 Jul 2006 16:53 GMT

> Is it in $HOME/sqllib/db2nodes.cfg?

No, that just lists the servers short hostname. should it ?

tia
dan

> > Hi all.
> >
[quoted text clipped - 22 lines]
> >
> > Thanks in advance.

Reply to this Message

Challenge - 12 Jul 2006 18:13 GMT

What's the output of 'nslookup'? What's the output of 'db2set -all'?
Have you setup 'SVCENAME' in DBM CFG?

> > Is it in $HOME/sqllib/db2nodes.cfg?
>
[quoted text clipped - 29 lines]
> > >
> > > Thanks in advance.

Reply to this Message

Ian - 12 Jul 2006 20:32 GMT

> Hi all.
>
[quoted text clipped - 16 lines]
> "*".
> SQLSTATE=08001

Look at your database directory (db2 list db directory) and see how the
alias 'TEC' is cataloged.

I suspect TEC is an entry for a Remote database, and the Node that this
database is located at is pointing to 192.168.33.55.

Reply to this Message

Dan Cave - 13 Jul 2006 10:38 GMT

thanks guys, it appears we have ibm db2 support which i forgot about.
I'm raising a call with them and they'll be assisting.

thanks for your help thus far, I'll summarise what the problem was when
it's resolved.

d.

> > Hi all.
> >
[quoted text clipped - 22 lines]
> I suspect TEC is an entry for a Remote database, and the Node that this
> database is located at is pointing to 192.168.33.55.

Reply to this Message

Dan Cave - 13 Jul 2006 14:50 GMT

Folks,

It would appear that unbeknown to me, our previous dba (i'm just an SA
with limited db/sql skills) had setup db2 backups to tsm, which
explains why our db instances are not complete. IBM have been really
helpful in helping me work this gig out.

D

> thanks guys, it appears we have ibm db2 support which i forgot about.
> I'm raising a call with them and they'll be assisting.
[quoted text clipped - 30 lines]
> > I suspect TEC is an entry for a Remote database, and the Node that this
> > database is located at is pointing to 192.168.33.55.

Reply to this Message

Dan Cave - 25 Jul 2006 10:59 GMT

Nearly 2 weeks after the initial posting, I managed to get a server
duplicated in our dev environment, luckily we had a snapshot of the
backup database which was ran via the db2backup command to a file, not
tsm like we first thought.. It was a fairly straight forward issue to
resolve.

> It would appear that unbeknown to me, our previous dba (i'm just an SA
> with limited db/sql skills) had setup db2 backups to tsm, which
[quoted text clipped - 37 lines]
> > > I suspect TEC is an entry for a Remote database, and the Node that this
> > > database is located at is pointing to 192.168.33.55.

Reply to this Message