By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
432,483 Members | 1,039 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 432,483 IT Pros & Developers. It's quick & easy.

re-configuring db2 server for client operation? [comparison to oracle]

P: n/a
z
To reconfigure oracle9i from server to client operation,
two files need to be modified:

listener.ora (for the server IP address), and tnsnames.ora
(for user permissions).

What are the analogous files to be modified for db2?
I looked at a couple of manuals, but only got the instruction
to re-install db2 specifying client. For various reasons,
that is impractical for my situation.

Thanks...

Apr 6 '06 #1
Share this Question
Share on Google+
4 Replies


P: n/a
DB2 has a client by default. To access remote databases, you need to
catalog the remote tcpip node, and then catalog the (remote) db to the
node. See the Command Reference manual for details.

Apr 6 '06 #2

P: n/a

z wrote:
To reconfigure oracle9i from server to client operation,
two files need to be modified:

listener.ora (for the server IP address), and tnsnames.ora
(for user permissions).

What are the analogous files to be modified for db2?
I looked at a couple of manuals, but only got the instruction
to re-install db2 specifying client. For various reasons,
that is impractical for my situation.

Thanks...


In addition to what's already been replied, your question implies that
a machine is *either* a client *or* a server. I don't think this is
true anywhere, certainly not in Oracle. All of my oracle servers
(machines) act as both oracle database servers (running one or more
oracle databases) AND as database clients (accessing databases on other
boxes). The two are not mutually exclusive and no "reconfiguration" is
required. As for the files you mentioned, the listener.ora is used by
the server-side process ONLY, and the tnsnames.ora is used by the
client-side process ONLY. Oh, and tnsnames.ora has NOTHING to do with
user permissions. It is only a names resolution mechanism, used to
resolve a name to a specific IP address (possibly with the help of DNS
name resolution), port, and service name. It is actually possible for
the client process to connect to a remote database without a tnsnames
file. It requires a cumbersomly long connect string, but is quite
possible.

Apr 6 '06 #3

P: n/a
z
I'm sorry I do not know very much about DB2 at all, just
a very superficial amount from running QuickInstall
once.

Would the following be correct [DB2 V 8.2]?
starting from systemA on which DB2 has been installed monolithically
[using the defaults from the Quick Installation Guide wherever possible]
and systemB on which DB2 has not yet been installed:
copy:

systemA /home/dasusr1 to systemB /home/dasusr1
systemA /home/db2fenc1 to systemB /home/db2fenc1
systemA /home/db2inst1 to systemB /home/db2inst1
systemA /opt/IBM to systemB /opt/IBM
systemA /opt/IBMJava2-141 to systemB /opt/IBMJava2-141

[Please let all of the above be a given. Thanks.]

Then, issue the following commands on systemB:

as user db2inst1:

db2 catalog tcpip node systemA remote tcphost server db2c_db2inst1
db2 catalog database sample at node systemA

After this, issuing db2 commands on database sample should not
matter whether the commands are being issues on systemA or systemB.

Correct?

If not, what can be done to the above procedure to make it correct?

[Alternatively, are there files that can be tweaked a la Oracle9i
to achieve the equivalent of the above two db2 administrative commands?]

Thanks...

<m0****@yahoo.com> wrote in message
news:11*********************@t31g2000cwb.googlegro ups.com...
DB2 has a client by default. To access remote databases, you need to
catalog the remote tcpip node, and then catalog the (remote) db to the
node. See the Command Reference manual for details.

Apr 7 '06 #4

P: n/a
"z" <z@y.x.invalid> wrote in message
news:zz******************@newssvr27.news.prodigy.n et...
I'm sorry I do not know very much about DB2 at all, just
a very superficial amount from running QuickInstall
once.

Would the following be correct [DB2 V 8.2]?
starting from systemA on which DB2 has been installed monolithically
[using the defaults from the Quick Installation Guide wherever possible]
and systemB on which DB2 has not yet been installed:
copy:

systemA /home/dasusr1 to systemB /home/dasusr1
systemA /home/db2fenc1 to systemB /home/db2fenc1
systemA /home/db2inst1 to systemB /home/db2inst1
systemA /opt/IBM to systemB /opt/IBM
systemA /opt/IBMJava2-141 to systemB /opt/IBMJava2-141

[Please let all of the above be a given. Thanks.]

Then, issue the following commands on systemB:

as user db2inst1:

db2 catalog tcpip node systemA remote tcphost server db2c_db2inst1
db2 catalog database sample at node systemA

After this, issuing db2 commands on database sample should not
matter whether the commands are being issues on systemA or systemB.

Correct?

If not, what can be done to the above procedure to make it correct?

[Alternatively, are there files that can be tweaked a la Oracle9i
to achieve the equivalent of the above two db2 administrative commands?]

Thanks...


I don't understand what all the copy commands are for. But you cannot
install DB2 or copy a database by copy files. You should do install of DB2,
backup of the database in question, and restore of database on the new
server. Backup and restore are DB2 commands documented in the Command
Reference.

On your first catalog statement: tcphost is the hostname or IP address of
the remote server. db2c_db2inst1 is the port number or service name (as
specified in /etc/services).

On the second catalog statement, you need a database name and an alias name
that the database will be called on the local machine. So it would be
something like:

db2 catalog database sample as sample_r at node systemA authentication
server

sample_r is the alias with a different name in case you have a local
database named sample. But both the database name and alias name can be the
same if it does not already exist.
Apr 7 '06 #5

This discussion thread is closed

Replies have been disabled for this discussion.