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

Activate db - command changed in 8.x?

P: n/a
In version 7.x

connect to db
activate db db
SQL1494W Activate database is successful, however, there is already a
connection to the database.

works fine - db activated.

In 8.x - No! WHY??? :-(

activate db db
SQL1493N The application is already connected to an active database.

DB was not activated. I have no idea why this changed. I no idea how to
activate db without force connections.

Andy

Nov 12 '05 #1
Share this Question
Share on Google+
4 Replies


P: n/a
bughunter@ru wrote:
In version 7.x

connect to db
activate db db
SQL1494W Activate database is successful, however, there is already a
connection to the database.

works fine - db activated.

In 8.x - No! WHY??? :-(

activate db db
SQL1493N The application is already connected to an active database.

DB was not activated. I have no idea why this changed. I no idea how to
activate db without force connections.

Andy


Whole purpose of ACTIVATing database is to perform necessarily initialization
and buffer pool(s) allocations so the first and next connections are comparable.
Without ACTIVATing database all initialization and memory allocations is
performed while processing first connection.

For example (note that NO CONNECTIONS were made to database SAMPLE):

[host]/home/instance $ time db2 activate db sample
DB20000I The ACTIVATE DATABASE command completed successfully.

real 0m1.59s
user 0m0.01s
sys 0m0.18s
[host]/home/instance $ time db2 connect to sample

Database Connection Information

Database server = DB2/6000 8.2.0
SQL authorization ID = INSTANCE
Local database alias = SAMPLE
real 0m0.28s
user 0m0.00s
sys 0m0.17s
While the first connect to db sample without activation looks like this:

[host]/home/instance $ time db2 connect to sample

Database Connection Information

Database server = DB2/6000 8.2.0
SQL authorization ID = INSTANCE
Local database alias = SAMPLE
real 0m1.60s
user 0m0.02s
sys 0m0.17s
Jan M. Nelken
Nov 12 '05 #2

P: n/a
"Jan M. Nelken" <Un**********@Invalid.Domain> wrote in message
news:RO********************@rogers.com...


Whole purpose of ACTIVATing database is to perform necessarily
initialization and buffer pool(s) allocations so the first and next
connections are comparable.
Without ACTIVATing database all initialization and memory allocations is
performed while processing first connection.

For example (note that NO CONNECTIONS were made to database SAMPLE):

[host]/home/instance $ time db2 activate db sample
DB20000I The ACTIVATE DATABASE command completed successfully.


I think Andy understands what the purpose of activate database is. But it
may sometimes be desirable to activate a database without having to
disconnect all currently connected users. This is especially true since
there are some application severs (Tomcat for example) that automatically
connect to the database as soon as the instance is started, so it hard to
sneak the activate in before there are any connections. Seems like it should
only be a warning message, like in version 7.
Nov 12 '05 #3

P: n/a
Mark A wrote:
"Jan M. Nelken" <Un**********@Invalid.Domain> wrote in message
news:RO********************@rogers.com...

Whole purpose of ACTIVATing database is to perform necessarily
initialization and buffer pool(s) allocations so the first and next
connections are comparable.
Without ACTIVATing database all initialization and memory allocations is
performed while processing first connection.

For example (note that NO CONNECTIONS were made to database SAMPLE):

[host]/home/instance $ time db2 activate db sample
DB20000I The ACTIVATE DATABASE command completed successfully.


I think Andy understands what the purpose of activate database is. But it
may sometimes be desirable to activate a database without having to
disconnect all currently connected users.


You don't have to do that at all. The only condition is that the current
application (shell or program) is not connected to a database when it tries
to activate a db:

Shell 1:
--------
$ db2 connect to test

Database Connection Information

Database server = DB2/LINUX 8.2.2
SQL authorization ID = STOLZE
Local database alias = TEST

Shell 2:
--------
$ db2 activate db test
SQL1494W Activate database is successful, however, there is already a
connection to the database.

This is especially true since
there are some application severs (Tomcat for example) that automatically
connect to the database as soon as the instance is started, so it hard to
sneak the activate in before there are any connections. Seems like it
should only be a warning message, like in version 7.


See above: this is easily possible.

--
Knut Stolze
Information Integration
IBM Germany / University of Jena
Nov 12 '05 #4

P: n/a
thx! I'm stupid today...

Nov 12 '05 #5

This discussion thread is closed

Replies have been disabled for this discussion.