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

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

mjf - 01 Dec 2005 21:05 GMT

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.

Reply to this Message

mjf - 01 Dec 2005 21:17 GMT

> Hello,
> We made a backup image file for a database on one machine (A), and
[quoted text clipped - 8 lines]
> need to tune any configuration parameters?
> Thanks for any help.

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

Reply to this Message

Pierre Saint-Jacques - 01 Dec 2005 22:29 GMT

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.

Signature

Pierre Saint-Jacques
SES Consultants Inc.
514-737-4515

>> Hello,
>> We made a backup image file for a database on one machine (A), and
[quoted text clipped - 10 lines]
>
> By the way, the database we use is DB2 UDB V8.2 for Linux.

Reply to this Message

Mark A - 01 Dec 2005 23:36 GMT

> First connect costs are usually encurred by db global shared memory
> allocations and log file allocations.
[quoted text clipped - 7 lines]
> 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.

Reply to this Message

Knut Stolze - 02 Dec 2005 10:17 GMT

>> First connect costs are usually encurred by db global shared memory
>> allocations and log file allocations.
[quoted text clipped - 14 lines]
> 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.

Signature

Knut Stolze
DB2 Information Integration Development
IBM Germany

Reply to this Message

Phil Sherman - 02 Dec 2005 15:37 GMT

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

> Hello,
> We made a backup image file for a database on one machine (A), and
[quoted text clipped - 8 lines]
> need to tune any configuration parameters?
> Thanks for any help.

Reply to this Message

mjf - 02 Dec 2005 16:23 GMT

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)?

> 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
[quoted text clipped - 19 lines]
> > need to tune any configuration parameters?
> > Thanks for any help.

Reply to this Message

Larry Menard - 02 Dec 2005 17:20 GMT

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.

Signature

--------------------
Larry Menard
"Defender of Geese and of All Things Natural"

> Hello guys, thank you very much for your responses. I used the
> "ACTIVATE DATABASE..." command it worked. The 1st connection got
[quoted text clipped - 28 lines]
>> > need to tune any configuration parameters?
>> > Thanks for any help.

Reply to this Message

Pierre Saint-Jacques - 03 Dec 2005 03:00 GMT

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.

Signature

Pierre Saint-Jacques
SES Consultants Inc.
514-737-4515

Reply to this Message

Phil Sherman - 03 Dec 2005 13:10 GMT

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

> Hello guys, thank you very much for your responses. I used the
> "ACTIVATE DATABASE..." command it worked. The 1st connection got
[quoted text clipped - 28 lines]
>>>need to tune any configuration parameters?
>>> Thanks for any help.

Reply to this Message

mjf - 05 Dec 2005 15:30 GMT

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

> 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,
[quoted text clipped - 44 lines]
> >>>need to tune any configuration parameters?
> >>> Thanks for any help.

Reply to this Message