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.
10  9563 
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.
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.
"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.
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
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.
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.
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.
>
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.
>
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.
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.
This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Adam Ryan |
last post by:
Hi,
I am seeing very slow connections from some client enterprise managers
to server. Even at server level it takes 1 minute or less to open a
database. I have adjusted some of the memory...
|
by: DotNetIsHorrible |
last post by:
I write CRUD database applications for a living for an audience of
about 100 users per application using classic ASP. I maintain and
frequently change on user's request 22 different applications...
|
by: john.livermore |
last post by:
When I login using QA to my SQL Server database, it takes 15-20 seconds
to establish a connection and open a query window. Drilling into a
database via Enterprise Manager is similar. Once the...
|
by: Rafi Kfir |
last post by:
HI,
I use vb6 to access database. I can select between "local" data base
and "remote" data base. Both connection calls the same Access 2000
Mdb.
The Mdb contains local tables (on the hard...
|
by: pradeep_TP |
last post by:
Hi all,
I have a few questions that I have been wanting to ask for long. These are
all related to ADO.net and specifically to conenction to database.
1) If I have opened a connection to a...
|
by: Tommy Martin |
last post by:
I have just started on a new web project. When I make the first connection
to sql server it takes about 10 to 30 seconds (varies each time) to make the
connection to the server. I am using the...
|
by: Varangian |
last post by:
Hello there people,
I'm having some kind of problem. I have a function that returns a
datareader. At some point using the application I get an error
"Unspecified error" (ssssoooo helpful) :). I...
|
by: rich |
last post by:
I have a PHP5 application that accepts external messages, and inserts
them into a database. It's rather high traffic.. the server could be
receiving thousands at a time, and recently mysql has...
|
by: Cintury |
last post by:
Hi all,
I've developed a mobile application for windows mobile 5.0 that has been in use for a while (1 year and a couple of months). It was developed in visual studios 2005 with a back-end sql...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
| |
