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

the first connection to the database takes a long time....

P: n/a
mjf
Hello,
We made a backup image file for a database on one machine (A), and
we restored the database on another machine (B), using the backup image
file. Everything went fine. But when we try to connect to the database
on B, it's taking forever (about 1 minute) if it's the first connection
to the database. Any following connections have no problem. If we close
all the connections, and do a connection again, it will take about 1
minute again. The database on B did not exist before. It was created
directly from that "db2 restore db db-name" command.
Did we do anything wrong in duplicate a database like that? Do we
need to tune any configuration parameters?
Thanks for any help.

Dec 1 '05 #1
Share this Question
Share on Google+
10 Replies


P: n/a
mjf
mjf wrote:
Hello,
We made a backup image file for a database on one machine (A), and
we restored the database on another machine (B), using the backup image
file. Everything went fine. But when we try to connect to the database
on B, it's taking forever (about 1 minute) if it's the first connection
to the database. Any following connections have no problem. If we close
all the connections, and do a connection again, it will take about 1
minute again. The database on B did not exist before. It was created
directly from that "db2 restore db db-name" command.
Did we do anything wrong in duplicate a database like that? Do we
need to tune any configuration parameters?
Thanks for any help.


By the way, the database we use is DB2 UDB V8.2 for Linux.

Dec 1 '05 #2

P: n/a
First connect costs are usually encurred by db global shared memory
allocations and log file allocations.
Is the new system the same in respect to memory size and disk sub system
structure?
Did you change the log path on the new system to a file system that may not
be as efficient as the one for the "old" system?
Are things really equal from one system to the other?

Once the first connect is "paid for" subsequent connections should always be
minimum time unless you are memory constrained.
HTH, Pierre.

--
Pierre Saint-Jacques
SES Consultants Inc.
514-737-4515
"mjf" <mi****@excite.com> a écrit dans le message de news:
11**********************@g49g2000cwa.googlegroups. com...
mjf wrote:
Hello,
We made a backup image file for a database on one machine (A), and
we restored the database on another machine (B), using the backup image
file. Everything went fine. But when we try to connect to the database
on B, it's taking forever (about 1 minute) if it's the first connection
to the database. Any following connections have no problem. If we close
all the connections, and do a connection again, it will take about 1
minute again. The database on B did not exist before. It was created
directly from that "db2 restore db db-name" command.
Did we do anything wrong in duplicate a database like that? Do we
need to tune any configuration parameters?
Thanks for any help.


By the way, the database we use is DB2 UDB V8.2 for Linux.


Dec 1 '05 #3

P: n/a
"Pierre Saint-Jacques" <se*****@invalid.net> wrote in message
news:RO*******************@weber.videotron.net...
First connect costs are usually encurred by db global shared memory
allocations and log file allocations.
Is the new system the same in respect to memory size and disk sub system
structure?
Did you change the log path on the new system to a file system that may
not be as efficient as the one for the "old" system?
Are things really equal from one system to the other?

Once the first connect is "paid for" subsequent connections should always
be minimum time unless you are memory constrained.
HTH, Pierre.

If the connection delay is with a remote type 2 driver, then make sure the
db is catalogued with "authentication server" option.

If the connection delay is also when a local connection is made from Linux
as the instance owner, then it is probably because of the memory
initialization as mentioned by Pierre, but 1 minute sounds too long.
Dec 1 '05 #4

P: n/a
Mark A wrote:
"Pierre Saint-Jacques" <se*****@invalid.net> wrote in message
news:RO*******************@weber.videotron.net...
First connect costs are usually encurred by db global shared memory
allocations and log file allocations.
Is the new system the same in respect to memory size and disk sub system
structure?
Did you change the log path on the new system to a file system that may
not be as efficient as the one for the "old" system?
Are things really equal from one system to the other?

Once the first connect is "paid for" subsequent connections should always
be minimum time unless you are memory constrained.
HTH, Pierre.

If the connection delay is with a remote type 2 driver, then make sure the
db is catalogued with "authentication server" option.

If the connection delay is also when a local connection is made from Linux
as the instance owner, then it is probably because of the memory
initialization as mentioned by Pierre, but 1 minute sounds too long.


Maybe there is some crash recovery going on?

I guess I would explicitly activate the database to have the initial setup
costs before the first connection is made.

--
Knut Stolze
DB2 Information Integration Development
IBM Germany
Dec 2 '05 #5

P: n/a
If system A is your production box and B is a (new) development, test or
production box then your might discover the same problem exists on A but
is masked by the database always having a connection to it.

Try using an "ACTIVATE DATABASE" command on B before your first
connection. This will also keep the database open and eliminate
initialization for the first connection. You should also read about the
"DEACTIVATE DATABASE" command.

Phil Sherman
mjf wrote:
Hello,
We made a backup image file for a database on one machine (A), and
we restored the database on another machine (B), using the backup image
file. Everything went fine. But when we try to connect to the database
on B, it's taking forever (about 1 minute) if it's the first connection
to the database. Any following connections have no problem. If we close
all the connections, and do a connection again, it will take about 1
minute again. The database on B did not exist before. It was created
directly from that "db2 restore db db-name" command.
Did we do anything wrong in duplicate a database like that? Do we
need to tune any configuration parameters?
Thanks for any help.

Dec 2 '05 #6

P: n/a
mjf
Hello guys, thank you very much for your responses. I used the
"ACTIVATE DATABASE..." command it worked. The 1st connection got
established in a second or two. Now I have another question: I figure I
can always do an explicit activation of the database in the
application, before the first connection. But is there a better way?
Such as as soon as the database is started after the machine restarts?
Why the DB2 administration server doesn't do this as soon as it's
automatically started (I have the AUTO START on)?
Phil Sherman wrote:
If system A is your production box and B is a (new) development, test or
production box then your might discover the same problem exists on A but
is masked by the database always having a connection to it.

Try using an "ACTIVATE DATABASE" command on B before your first
connection. This will also keep the database open and eliminate
initialization for the first connection. You should also read about the
"DEACTIVATE DATABASE" command.

Phil Sherman
mjf wrote:
Hello,
We made a backup image file for a database on one machine (A), and
we restored the database on another machine (B), using the backup image
file. Everything went fine. But when we try to connect to the database
on B, it's taking forever (about 1 minute) if it's the first connection
to the database. Any following connections have no problem. If we close
all the connections, and do a connection again, it will take about 1
minute again. The database on B did not exist before. It was created
directly from that "db2 restore db db-name" command.
Did we do anything wrong in duplicate a database like that? Do we
need to tune any configuration parameters?
Thanks for any help.


Dec 2 '05 #7

P: n/a
As (I think) one of the other responders suggested, I would suggest you
verify that your original database definitely does not behave that way. If
it does not, then find out why this one does.

The things that can cause long activation times are usually:

- allocation of bufferpool memory or
- initialization of log files.

While the activation is occurring you can "dir" or "ls -l" the directory
with your log files and see if they are growing or still being created while
the activation occurs. If that's the problem, then why is your original db
not acting that way? Compare the DB CFG between the 2 databases.

Also check db2diag.log for messages about things like crash recovery or
bufferpool allocation.

--
--------------------
Larry Menard
"Defender of Geese and of All Things Natural"
"mjf" <mi****@excite.com> wrote in message
news:11*********************@g14g2000cwa.googlegro ups.com...
Hello guys, thank you very much for your responses. I used the
"ACTIVATE DATABASE..." command it worked. The 1st connection got
established in a second or two. Now I have another question: I figure I
can always do an explicit activation of the database in the
application, before the first connection. But is there a better way?
Such as as soon as the database is started after the machine restarts?
Why the DB2 administration server doesn't do this as soon as it's
automatically started (I have the AUTO START on)?
Phil Sherman wrote:
If system A is your production box and B is a (new) development, test or
production box then your might discover the same problem exists on A but
is masked by the database always having a connection to it.

Try using an "ACTIVATE DATABASE" command on B before your first
connection. This will also keep the database open and eliminate
initialization for the first connection. You should also read about the
"DEACTIVATE DATABASE" command.

Phil Sherman
mjf wrote:
> Hello,
> We made a backup image file for a database on one machine (A), and
> we restored the database on another machine (B), using the backup image
> file. Everything went fine. But when we try to connect to the database
> on B, it's taking forever (about 1 minute) if it's the first connection
> to the database. Any following connections have no problem. If we close
> all the connections, and do a connection again, it will take about 1
> minute again. The database on B did not exist before. It was created
> directly from that "db2 restore db db-name" command.
> Did we do anything wrong in duplicate a database like that? Do we
> need to tune any configuration parameters?
> Thanks for any help.
>

Dec 2 '05 #8

P: n/a
That is not the DAS's responsibility.
Under that DAS, you could have multiple instances, each with multiple
databases and have a need to start only some instances and in those only
some db's. Because of this, the db'x are always "manually" activated.
What you can do is have a start u^p script that's fairly simple.
Here's an example based on the DAS and instances not being services
automatically started by the OS.
db2admin start
set db2instance=db2
db2start
set db2instance=ses
db2start
db2cc
exit
Choose whatever fits, but as said in previous answer, get the db activated
before the first connection. the ACTIVATE command isreserved to DBADM and
SYSADM authority, so the appl. should not attempt to issue it.

HTH, Pierre.
--
Pierre Saint-Jacques
SES Consultants Inc.
514-737-4515
"mjf" <mi****@excite.com> a écrit dans le message de news:
11*********************@g14g2000cwa.googlegroups.c om...
Hello guys, thank you very much for your responses. I used the
"ACTIVATE DATABASE..." command it worked. The 1st connection got
established in a second or two. Now I have another question: I figure I
can always do an explicit activation of the database in the
application, before the first connection. But is there a better way?
Such as as soon as the database is started after the machine restarts?
Why the DB2 administration server doesn't do this as soon as it's
automatically started (I have the AUTO START on)?
Phil Sherman wrote:
If system A is your production box and B is a (new) development, test or
production box then your might discover the same problem exists on A but
is masked by the database always having a connection to it.

Try using an "ACTIVATE DATABASE" command on B before your first
connection. This will also keep the database open and eliminate
initialization for the first connection. You should also read about the
"DEACTIVATE DATABASE" command.

Phil Sherman
mjf wrote:
> Hello,
> We made a backup image file for a database on one machine (A), and
> we restored the database on another machine (B), using the backup image
> file. Everything went fine. But when we try to connect to the database
> on B, it's taking forever (about 1 minute) if it's the first connection
> to the database. Any following connections have no problem. If we close
> all the connections, and do a connection again, it will take about 1
> minute again. The database on B did not exist before. It was created
> directly from that "db2 restore db db-name" command.
> Did we do anything wrong in duplicate a database like that? Do we
> need to tune any configuration parameters?
> Thanks for any help.
>


Dec 3 '05 #9

P: n/a
Talk to your system administrator about getting a command file added to
the startup procedures for the system. You can make it a two parter,
using the "at" command in the first part to introduce a couple of minute
delay to allow UDB to complete its instance startup. I prefer this to
using the "sleep" command because it allows immediate execution of the
activate portion if I need to restart the instance. A single command
file using a parameter and shell scripting can also control the
execution of an embedded "SLEEP" command.

The command file needs to be run as the instance owner (or possibly
after running db2setup in /home/instance_owner/sqllib) and should
contain the following command:
db2 activate database .......

Phil Sherman

mjf wrote:
Hello guys, thank you very much for your responses. I used the
"ACTIVATE DATABASE..." command it worked. The 1st connection got
established in a second or two. Now I have another question: I figure I
can always do an explicit activation of the database in the
application, before the first connection. But is there a better way?
Such as as soon as the database is started after the machine restarts?
Why the DB2 administration server doesn't do this as soon as it's
automatically started (I have the AUTO START on)?
Phil Sherman wrote:
If system A is your production box and B is a (new) development, test or
production box then your might discover the same problem exists on A but
is masked by the database always having a connection to it.

Try using an "ACTIVATE DATABASE" command on B before your first
connection. This will also keep the database open and eliminate
initialization for the first connection. You should also read about the
"DEACTIVATE DATABASE" command.

Phil Sherman
mjf wrote:
Hello,
We made a backup image file for a database on one machine (A), and
we restored the database on another machine (B), using the backup image
file. Everything went fine. But when we try to connect to the database
on B, it's taking forever (about 1 minute) if it's the first connection
to the database. Any following connections have no problem. If we close
all the connections, and do a connection again, it will take about 1
minute again. The database on B did not exist before. It was created
directly from that "db2 restore db db-name" command.
Did we do anything wrong in duplicate a database like that? Do we
need to tune any configuration parameters?
Thanks for any help.


Dec 3 '05 #10

P: n/a
mjf
Hi guys, thank you very much for your explanations, script and
commands. It's a BIG help for me.

Phil Sherman wrote:
Talk to your system administrator about getting a command file added to
the startup procedures for the system. You can make it a two parter,
using the "at" command in the first part to introduce a couple of minute
delay to allow UDB to complete its instance startup. I prefer this to
using the "sleep" command because it allows immediate execution of the
activate portion if I need to restart the instance. A single command
file using a parameter and shell scripting can also control the
execution of an embedded "SLEEP" command.

The command file needs to be run as the instance owner (or possibly
after running db2setup in /home/instance_owner/sqllib) and should
contain the following command:
db2 activate database .......

Phil Sherman

mjf wrote:
Hello guys, thank you very much for your responses. I used the
"ACTIVATE DATABASE..." command it worked. The 1st connection got
established in a second or two. Now I have another question: I figure I
can always do an explicit activation of the database in the
application, before the first connection. But is there a better way?
Such as as soon as the database is started after the machine restarts?
Why the DB2 administration server doesn't do this as soon as it's
automatically started (I have the AUTO START on)?
Phil Sherman wrote:
If system A is your production box and B is a (new) development, test or
production box then your might discover the same problem exists on A but
is masked by the database always having a connection to it.

Try using an "ACTIVATE DATABASE" command on B before your first
connection. This will also keep the database open and eliminate
initialization for the first connection. You should also read about the
"DEACTIVATE DATABASE" command.

Phil Sherman
mjf wrote:

Hello,
We made a backup image file for a database on one machine (A), and
we restored the database on another machine (B), using the backup image
file. Everything went fine. But when we try to connect to the database
on B, it's taking forever (about 1 minute) if it's the first connection
to the database. Any following connections have no problem. If we close
all the connections, and do a connection again, it will take about 1
minute again. The database on B did not exist before. It was created
directly from that "db2 restore db db-name" command.
Did we do anything wrong in duplicate a database like that? Do we
need to tune any configuration parameters?
Thanks for any help.



Dec 5 '05 #11

This discussion thread is closed

Replies have been disabled for this discussion.