How to stop or block a database??? 
Author Message
 How to stop or block a database???
Hi Forum,
Is there any command to disconnect users or block the database while I am
changing its structure or backing it up?  When I try to back-up a database
and users are connected to it, the backup database command returns "database
in use ...." and cannot backup the database.
Thanks in advance for your response


Wed, 04 Aug 2004 02:48:57 GMT
 How to stop or block a database???

If it's the only db in the instance then:

db2 force applications all
This command is at the instance level and therefore affects all db's of
the instance.
And then issue the following immediately after:

db2 connect to <dbname> in exclusive mode
This will stop everybody from being able to connect.
You can then issue:
db2 connect reset
db2 backup <dbname> ....

If you don't want to backup but need to work on the db alone then do not
disconnect.

HTH,  Pierre.

Quote:

> Hi Forum,
> Is there any command to disconnect users or block the database while I am
> changing its structure or backing it up?  When I try to back-up a database
> and users are connected to it, the backup database command returns "database
> in use ...." and cannot backup the database.
> Thanks in advance for your response



Wed, 04 Aug 2004 04:54:22 GMT
 How to stop or block a database???

Quote:

> If it's the only db in the instance then:

> db2 force applications all
> This command is at the instance level and therefore affects all db's of
> the instance.
> And then issue the following immediately after:

> db2 connect to <dbname> in exclusive mode
> This will stop everybody from being able to connect.
> You can then issue:
> db2 connect reset
> db2 backup <dbname> ....

> If you don't want to backup but need to work on the db alone then do not
> disconnect.

But if you *want* to backup then *do not disconnect*; backup can be started from
the same session of exclusive connect. If you do disconnect you are opening a
window of opportunity for client to connect in the mean time and your backup will
fail with "database in use" message.

Jan M. Nelken



Wed, 04 Aug 2004 13:45:15 GMT
 How to stop or block a database???
JAn, thanks for this.  I really thought that offline meant offline and
not even a connection on the id that backs up would be acceptable.
Merci,  Pierre.
Quote:


>>If it's the only db in the instance then:

>>db2 force applications all
>>This command is at the instance level and therefore affects all db's of
>>the instance.
>>And then issue the following immediately after:

>>db2 connect to <dbname> in exclusive mode
>>This will stop everybody from being able to connect.
>>You can then issue:
>>db2 connect reset
>>db2 backup <dbname> ....

>>If you don't want to backup but need to work on the db alone then do not
>>disconnect.

> But if you *want* to backup then *do not disconnect*; backup can be started from
> the same session of exclusive connect. If you do disconnect you are opening a
> window of opportunity for client to connect in the mean time and your backup will
> fail with "database in use" message.

> Jan M. Nelken



Thu, 05 Aug 2004 01:49:43 GMT
 How to stop or block a database???
Quote:

> JAn, thanks for this.  I really thought that offline meant offline and
> not even a connection on the id that backs up would be acceptable.
> Merci,  Pierre.



> >>If it's the only db in the instance then:

> >>db2 force applications all
> >>This command is at the instance level and therefore affects all db's of
> >>the instance.
> >>And then issue the following immediately after:

> >>db2 connect to <dbname> in exclusive mode
> >>This will stop everybody from being able to connect.
> >>You can then issue:
> >>db2 connect reset
> >>db2 backup <dbname> ....

> >>If you don't want to backup but need to work on the db alone then do not
> >>disconnect.

> > But if you *want* to backup then *do not disconnect*; backup can be started from
> > the same session of exclusive connect. If you do disconnect you are opening a
> > window of opportunity for client to connect in the mean time and your backup will
> > fail with "database in use" message.

> > Jan M. Nelken

The trick I'm using when I want to get an offline-backup.
My physical database is called fysdb.
I have created an alias (db2 catalog db fysdb as aliasdb on ...)
All users and applications use the ALIAS-name, not the physical database name.
When I want to have an offline backup, I just issue the following commands:
- db2 uncatalog db aliasdb
- db2 force application all
- db2 backup db fysdb to ...       see, that I'm using the physical db-name!
- and when the backup is finished
- db2 catalog db fysdb as aliasdb on ...    and now all users can connect again.
This trick works IF I have just one database. Please remember that 'db2 force
application all' will kill all users/connects to OTHER databases too!

Regards,
Kari



Sat, 07 Aug 2004 20:46:04 GMT
 How to stop or block a database???
Thank you very much for your help.  These solutions should work in my case.


Quote:
> > JAn, thanks for this.  I really thought that offline meant offline and
> > not even a connection on the id that backs up would be acceptable.
> > Merci,  Pierre.



> > >>If it's the only db in the instance then:

> > >>db2 force applications all
> > >>This command is at the instance level and therefore affects all db's
of
> > >>the instance.
> > >>And then issue the following immediately after:

> > >>db2 connect to <dbname> in exclusive mode
> > >>This will stop everybody from being able to connect.
> > >>You can then issue:
> > >>db2 connect reset
> > >>db2 backup <dbname> ....

> > >>If you don't want to backup but need to work on the db alone then do
not
> > >>disconnect.

> > > But if you *want* to backup then *do not disconnect*; backup can be
started from
> > > the same session of exclusive connect. If you do disconnect you are
opening a
> > > window of opportunity for client to connect in the mean time and your
backup will
> > > fail with "database in use" message.

> > > Jan M. Nelken

> The trick I'm using when I want to get an offline-backup.
> My physical database is called fysdb.
> I have created an alias (db2 catalog db fysdb as aliasdb on ...)
> All users and applications use the ALIAS-name, not the physical database
name.
> When I want to have an offline backup, I just issue the following
commands:
> - db2 uncatalog db aliasdb
> - db2 force application all
> - db2 backup db fysdb to ...       see, that I'm using the physical
db-name!
> - and when the backup is finished
> - db2 catalog db fysdb as aliasdb on ...    and now all users can connect
again.
> This trick works IF I have just one database. Please remember that 'db2
force
> application all' will kill all users/connects to OTHER databases too!

> Regards,
> Kari



Sat, 07 Aug 2004 21:11:41 GMT
 How to stop or block a database???
In regard to Kari's post:

Wouldn't you have to catalog and uncatalog (update the DB Directory)
on every client machine, in order for that method to work? How can the
uncataloging of an alias in one place (I'm assuming the server),
affect each client when they have their own copy of the db directory?
I also would find it very useful to be able to "lock out" connections
during utility processes, but if your method works, I must not be
understanding the relationships between server and client db
directories.

Quote:


> > JAn, thanks for this.  I really thought that offline meant offline and
> > not even a connection on the id that backs up would be acceptable.
> > Merci,  Pierre.



> > >>If it's the only db in the instance then:

> > >>db2 force applications all
> > >>This command is at the instance level and therefore affects all db's of
> > >>the instance.
> > >>And then issue the following immediately after:

> > >>db2 connect to <dbname> in exclusive mode
> > >>This will stop everybody from being able to connect.
> > >>You can then issue:
> > >>db2 connect reset
> > >>db2 backup <dbname> ....

> > >>If you don't want to backup but need to work on the db alone then do not
> > >>disconnect.

> > > But if you *want* to backup then *do not disconnect*; backup can be started from
> > > the same session of exclusive connect. If you do disconnect you are opening a
> > > window of opportunity for client to connect in the mean time and your backup will
> > > fail with "database in use" message.

> > > Jan M. Nelken

> The trick I'm using when I want to get an offline-backup.
> My physical database is called fysdb.
> I have created an alias (db2 catalog db fysdb as aliasdb on ...)
> All users and applications use the ALIAS-name, not the physical database name.
> When I want to have an offline backup, I just issue the following commands:
> - db2 uncatalog db aliasdb
> - db2 force application all
> - db2 backup db fysdb to ...       see, that I'm using the physical db-name!
> - and when the backup is finished
> - db2 catalog db fysdb as aliasdb on ...    and now all users can connect again.
> This trick works IF I have just one database. Please remember that 'db2 force
> application all' will kill all users/connects to OTHER databases too!

> Regards,
> Kari



Sun, 08 Aug 2004 04:03:44 GMT
 How to stop or block a database???
Kari'S approach works beautifully as the clients Never catalog the true
db name but the alias.
By uncatalogging at the server, you cut their access to the alias and
they can't connect.
It would be like the phone company delisting my phone number while they
maintain it and then relisting it once done. You wouldn't have to change
your address book, just get frustrated because you could not coneect for
a period of time.  Of course, you might exercise some language when you
finally get to phone me again!!!!

HTH'  Pierre.

Quote:

> In regard to Kari's post:

> Wouldn't you have to catalog and uncatalog (update the DB Directory)
> on every client machine, in order for that method to work? How can the
> uncataloging of an alias in one place (I'm assuming the server),
> affect each client when they have their own copy of the db directory?
> I also would find it very useful to be able to "lock out" connections
> during utility processes, but if your method works, I must not be
> understanding the relationships between server and client db
> directories.



>>>JAn, thanks for this.  I really thought that offline meant offline and
>>>not even a connection on the id that backs up would be acceptable.
>>>Merci,  Pierre.



>>>>>If it's the only db in the instance then:

>>>>>db2 force applications all
>>>>>This command is at the instance level and therefore affects all db's of
>>>>>the instance.
>>>>>And then issue the following immediately after:

>>>>>db2 connect to <dbname> in exclusive mode
>>>>>This will stop everybody from being able to connect.
>>>>>You can then issue:
>>>>>db2 connect reset
>>>>>db2 backup <dbname> ....

>>>>>If you don't want to backup but need to work on the db alone then do not
>>>>>disconnect.

>>>>But if you *want* to backup then *do not disconnect*; backup can be started from
>>>>the same session of exclusive connect. If you do disconnect you are opening a
>>>>window of opportunity for client to connect in the mean time and your backup will
>>>>fail with "database in use" message.

>>>>Jan M. Nelken

>>The trick I'm using when I want to get an offline-backup.
>>My physical database is called fysdb.
>>I have created an alias (db2 catalog db fysdb as aliasdb on ...)
>>All users and applications use the ALIAS-name, not the physical database name.
>>When I want to have an offline backup, I just issue the following commands:
>>- db2 uncatalog db aliasdb
>>- db2 force application all
>>- db2 backup db fysdb to ...       see, that I'm using the physical db-name!
>>- and when the backup is finished
>>- db2 catalog db fysdb as aliasdb on ...    and now all users can connect again.
>>This trick works IF I have just one database. Please remember that 'db2 force
>>application all' will kill all users/connects to OTHER databases too!

>>Regards,
>>Kari



Sun, 08 Aug 2004 06:59:42 GMT
 How to stop or block a database???
This should work normally but there could the a problem with system caching.
I remember that one time I changed an alias on server the clients still
could connect to the old alias for more than an hour and where not able to
connect to the new alias for this time. Local connections only worked on the
new alias.

Klemens



Quote:
> Kari'S approach works beautifully as the clients Never catalog the true
> db name but the alias.
> By uncatalogging at the server, you cut their access to the alias and
> they can't connect.
> It would be like the phone company delisting my phone number while they
> maintain it and then relisting it once done. You wouldn't have to change
> your address book, just get frustrated because you could not coneect for
> a period of time.  Of course, you might exercise some language when you
> finally get to phone me again!!!!

> HTH'  Pierre.


> > In regard to Kari's post:

> > Wouldn't you have to catalog and uncatalog (update the DB Directory)
> > on every client machine, in order for that method to work? How can the
> > uncataloging of an alias in one place (I'm assuming the server),
> > affect each client when they have their own copy of the db directory?
> > I also would find it very useful to be able to "lock out" connections
> > during utility processes, but if your method works, I must not be
> > understanding the relationships between server and client db
> > directories.




Quote:




- Show quoted text -

Quote:

> >>>JAn, thanks for this.  I really thought that offline meant offline and
> >>>not even a connection on the id that backs up would be acceptable.
> >>>Merci,  Pierre.



> >>>>>If it's the only db in the instance then:

> >>>>>db2 force applications all
> >>>>>This command is at the instance level and therefore affects all db's
of
> >>>>>the instance.
> >>>>>And then issue the following immediately after:

> >>>>>db2 connect to <dbname> in exclusive mode
> >>>>>This will stop everybody from being able to connect.
> >>>>>You can then issue:
> >>>>>db2 connect reset
> >>>>>db2 backup <dbname> ....

> >>>>>If you don't want to backup but need to work on the db alone then do
not
> >>>>>disconnect.

> >>>>But if you *want* to backup then *do not disconnect*; backup can be
started from
> >>>>the same session of exclusive connect. If you do disconnect you are
opening a
> >>>>window of opportunity for client to connect in the mean time and your
backup will
> >>>>fail with "database in use" message.

> >>>>Jan M. Nelken

> >>The trick I'm using when I want to get an offline-backup.
> >>My physical database is called fysdb.
> >>I have created an alias (db2 catalog db fysdb as aliasdb on ...)
> >>All users and applications use the ALIAS-name, not the physical database
name.
> >>When I want to have an offline backup, I just issue the following
commands:
> >>- db2 uncatalog db aliasdb
> >>- db2 force application all
> >>- db2 backup db fysdb to ...       see, that I'm using the physical
db-name!
> >>- and when the backup is finished
> >>- db2 catalog db fysdb as aliasdb on ...    and now all users can
connect again.
> >>This trick works IF I have just one database. Please remember that 'db2
force
> >>application all' will kill all users/connects to OTHER databases too!

> >>Regards,
> >>Kari



Sun, 08 Aug 2004 17:11:31 GMT
 How to stop or block a database???
The reason for this is:
In the dbm cfg there'S a parm. that specifies DIR_CACHE YES or ON which
specifies to cache the system, local database directories and the node
directory at db2start.
When you uncatalog, catalog then the files are updated but not the cache.
So, the connected users are still able to see the alias because it is
not uncatalogged in the cache.
Any new connection forces the fie to be read and they don't see the old
alias.

In order for Kari's solution to work you have to set the parm. to No or
OFF and each connection will have to pay the cost of reading the files
which should not be too expensive unless you have several hundred
connect requests per time period.
HTH'  Pierre.

Quote:

> This should work normally but there could the a problem with system caching.
> I remember that one time I changed an alias on server the clients still
> could connect to the old alias for more than an hour and where not able to
> connect to the new alias for this time. Local connections only worked on the
> new alias.

> Klemens



>>Kari'S approach works beautifully as the clients Never catalog the true
>>db name but the alias.
>>By uncatalogging at the server, you cut their access to the alias and
>>they can't connect.
>>It would be like the phone company delisting my phone number while they
>>maintain it and then relisting it once done. You wouldn't have to change
>>your address book, just get frustrated because you could not coneect for
>>a period of time.  Of course, you might exercise some language when you
>>finally get to phone me again!!!!

>>HTH'  Pierre.


>>>In regard to Kari's post:

>>>Wouldn't you have to catalog and uncatalog (update the DB Directory)
>>>on every client machine, in order for that method to work? How can the
>>>uncataloging of an alias in one place (I'm assuming the server),
>>>affect each client when they have their own copy of the db directory?
>>>I also would find it very useful to be able to "lock out" connections
>>>during utility processes, but if your method works, I must not be
>>>understanding the relationships between server and client db
>>>directories.





>>>>>JAn, thanks for this.  I really thought that offline meant offline and
>>>>>not even a connection on the id that backs up would be acceptable.
>>>>>Merci,  Pierre.



>>>>>>>If it's the only db in the instance then:

>>>>>>>db2 force applications all
>>>>>>>This command is at the instance level and therefore affects all db's

> of

>>>>>>>the instance.
>>>>>>>And then issue the following immediately after:

>>>>>>>db2 connect to <dbname> in exclusive mode
>>>>>>>This will stop everybody from being able to connect.
>>>>>>>You can then issue:
>>>>>>>db2 connect reset
>>>>>>>db2 backup <dbname> ....

>>>>>>>If you don't want to backup but need to work on the db alone then do

> not

>>>>>>>disconnect.

>>>>>>But if you *want* to backup then *do not disconnect*; backup can be

> started from

>>>>>>the same session of exclusive connect. If you do disconnect you are

> opening a

>>>>>>window of opportunity for client to connect in the mean time and your

> backup will

>>>>>>fail with "database in use" message.

>>>>>>Jan M. Nelken

>>>>The trick I'm using when I want to get an offline-backup.
>>>>My physical database is called fysdb.
>>>>I have created an alias (db2 catalog db fysdb as aliasdb on ...)
>>>>All users and applications use the ALIAS-name, not the physical database

> name.

>>>>When I want to have an offline backup, I just issue the following

> commands:

>>>>- db2 uncatalog db aliasdb
>>>>- db2 force application all
>>>>- db2 backup db fysdb to ...       see, that I'm using the physical

> db-name!

>>>>- and when the backup is finished
>>>>- db2 catalog db fysdb as aliasdb on ...    and now all users can

> connect again.

>>>>This trick works IF I have just one database. Please remember that 'db2

> force

>>>>application all' will kill all users/connects to OTHER databases too!

>>>>Regards,
>>>>Kari



Mon, 09 Aug 2004 03:52:03 GMT
 How to stop or block a database???
Is there a way to empty the catch, perhaps by issuing a terminate command or
stopping and restarting db2?

Quote:
> The reason for this is:
> In the dbm cfg there'S a parm. that specifies DIR_CACHE YES or ON which
> specifies to cache the system, local database directories and the node
> directory at db2start.
> When you uncatalog, catalog then the files are updated but not the cache.
> So, the connected users are still able to see the alias because it is
> not uncatalogged in the cache.
> Any new connection forces the fie to be read and they don't see the old
> alias.

> In order for Kari's solution to work you have to set the parm. to No or
> OFF and each connection will have to pay the cost of reading the files
> which should not be too expensive unless you have several hundred
> connect requests per time period.
> HTH'  Pierre.


> > This should work normally but there could the a problem with system
caching.
> > I remember that one time I changed an alias on server the clients still
> > could connect to the old alias for more than an hour and where not able
to
> > connect to the new alias for this time. Local connections only worked on
the
> > new alias.

> > Klemens



> >>Kari'S approach works beautifully as the clients Never catalog the true
> >>db name but the alias.
> >>By uncatalogging at the server, you cut their access to the alias and
> >>they can't connect.
> >>It would be like the phone company delisting my phone number while they
> >>maintain it and then relisting it once done. You wouldn't have to change
> >>your address book, just get frustrated because you could not coneect for
> >>a period of time.  Of course, you might exercise some language when you
> >>finally get to phone me again!!!!

> >>HTH'  Pierre.


> >>>In regard to Kari's post:

> >>>Wouldn't you have to catalog and uncatalog (update the DB Directory)
> >>>on every client machine, in order for that method to work? How can the
> >>>uncataloging of an alias in one place (I'm assuming the server),
> >>>affect each client when they have their own copy of the db directory?
> >>>I also would find it very useful to be able to "lock out" connections
> >>>during utility processes, but if your method works, I must not be
> >>>understanding the relationships between server and client db
> >>>directories.





> >>>>>JAn, thanks for this.  I really thought that offline meant offline
and
> >>>>>not even a connection on the id that backs up would be acceptable.
> >>>>>Merci,  Pierre.



> >>>>>>>If it's the only db in the instance then:

> >>>>>>>db2 force applications all
> >>>>>>>This command is at the instance level and therefore affects all
db's

> > of

> >>>>>>>the instance.
> >>>>>>>And then issue the following immediately after:

> >>>>>>>db2 connect to <dbname> in exclusive mode
> >>>>>>>This will stop everybody from being able to connect.
> >>>>>>>You can then issue:
> >>>>>>>db2 connect reset
> >>>>>>>db2 backup <dbname> ....

> >>>>>>>If you don't want to backup but need to work on the db alone then
do

> > not

> >>>>>>>disconnect.

> >>>>>>But if you *want* to backup then *do not disconnect*; backup can be

> > started from

> >>>>>>the same session of exclusive connect. If you do disconnect you are

> > opening a

> >>>>>>window of opportunity for client to connect in the mean time and
your

> > backup will

> >>>>>>fail with "database in use" message.

> >>>>>>Jan M. Nelken

> >>>>The trick I'm using when I want to get an offline-backup.
> >>>>My physical database is called fysdb.
> >>>>I have created an alias (db2 catalog db fysdb as aliasdb on ...)
> >>>>All users and applications use the ALIAS-name, not the physical
database

> > name.

> >>>>When I want to have an offline backup, I just issue the following

> > commands:

> >>>>- db2 uncatalog db aliasdb
> >>>>- db2 force application all
> >>>>- db2 backup db fysdb to ...       see, that I'm using the physical

> > db-name!

> >>>>- and when the backup is finished
> >>>>- db2 catalog db fysdb as aliasdb on ...    and now all users can

> > connect again.

> >>>>This trick works IF I have just one database. Please remember that
'db2

> > force

> >>>>application all' will kill all users/connects to OTHER databases too!

> >>>>Regards,
> >>>>Kari



Mon, 09 Aug 2004 21:43:40 GMT
 How to stop or block a database???
If you can, then you'll have to issue a db2stop with the force option
and then a db2start.  This will obviously refresh all the cached
directories and they won't find the old alias to reconnect.
The only way to recycle the cache on the server side is to stop/start
the instance.
The terminate command will "flush" the cache only for that session, not
for any other connected sessions, local or remote.
HTH,  Pierre.
Quote:

> Is there a way to empty the catch, perhaps by issuing a terminate command or
> stopping and restarting db2?


>>The reason for this is:
>>In the dbm cfg there'S a parm. that specifies DIR_CACHE YES or ON which
>>specifies to cache the system, local database directories and the node
>>directory at db2start.
>>When you uncatalog, catalog then the files are updated but not the cache.
>>So, the connected users are still able to see the alias because it is
>>not uncatalogged in the cache.
>>Any new connection forces the fie to be read and they don't see the old
>>alias.

>>In order for Kari's solution to work you have to set the parm. to No or
>>OFF and each connection will have to pay the cost of reading the files
>>which should not be too expensive unless you have several hundred
>>connect requests per time period.
>>HTH'  Pierre.


>>>This should work normally but there could the a problem with system

> caching.

>>>I remember that one time I changed an alias on server the clients still
>>>could connect to the old alias for more than an hour and where not able

> to

>>>connect to the new alias for this time. Local connections only worked on

> the

>>>new alias.

>>>Klemens



>>>>Kari'S approach works beautifully as the clients Never catalog the true
>>>>db name but the alias.
>>>>By uncatalogging at the server, you cut their access to the alias and
>>>>they can't connect.
>>>>It would be like the phone company delisting my phone number while they
>>>>maintain it and then relisting it once done. You wouldn't have to change
>>>>your address book, just get frustrated because you could not coneect for
>>>>a period of time.  Of course, you might exercise some language when you
>>>>finally get to phone me again!!!!

>>>>HTH'  Pierre.


>>>>>In regard to Kari's post:

>>>>>Wouldn't you have to catalog and uncatalog (update the DB Directory)
>>>>>on every client machine, in order for that method to work? How can the
>>>>>uncataloging of an alias in one place (I'm assuming the server),
>>>>>affect each client when they have their own copy of the db directory?
>>>>>I also would find it very useful to be able to "lock out" connections
>>>>>during utility processes, but if your method works, I must not be
>>>>>understanding the relationships between server and client db
>>>>>directories.





>>>>>>>JAn, thanks for this.  I really thought that offline meant offline

> and

>>>>>>>not even a connection on the id that backs up would be acceptable.
>>>>>>>Merci,  Pierre.



>>>>>>>>>If it's the only db in the instance then:

>>>>>>>>>db2 force applications all
>>>>>>>>>This command is at the instance level and therefore affects all

> db's

>>>of

>>>>>>>>>the instance.
>>>>>>>>>And then issue the following immediately after:

>>>>>>>>>db2 connect to <dbname> in exclusive mode
>>>>>>>>>This will stop everybody from being able to connect.
>>>>>>>>>You can then issue:
>>>>>>>>>db2 connect reset
>>>>>>>>>db2 backup <dbname> ....

>>>>>>>>>If you don't want to backup but need to work on the db alone then

> do

>>>not

>>>>>>>>>disconnect.

>>>>>>>>But if you *want* to backup then *do not disconnect*; backup can be

>>>started from

>>>>>>>>the same session of exclusive connect. If you do disconnect you are

>>>opening a

>>>>>>>>window of opportunity for client to connect in the mean time and

> your

>>>backup will

>>>>>>>>fail with "database in use" message.

>>>>>>>>Jan M. Nelken

>>>>>>The trick I'm using when I want to get an offline-backup.
>>>>>>My physical database is called fysdb.
>>>>>>I have created an alias (db2 catalog db fysdb as aliasdb on ...)
>>>>>>All users and applications use the ALIAS-name, not the physical

> database

>>>name.

>>>>>>When I want to have an offline backup, I just issue the following

>>>commands:

>>>>>>- db2 uncatalog db aliasdb
>>>>>>- db2 force application all
>>>>>>- db2 backup db fysdb to ...       see, that I'm using the physical

>>>db-name!

>>>>>>- and when the backup is finished
>>>>>>- db2 catalog db fysdb as aliasdb on ...    and now all users can

>>>connect again.

>>>>>>This trick works IF I have just one database. Please remember that

> 'db2

>>>force

>>>>>>application all' will kill all users/connects to OTHER databases too!

>>>>>>Regards,
>>>>>>Kari



Tue, 10 Aug 2004 02:27:15 GMT
 
 [ 12 post ] 

 Relevant Pages 

1. How Can we block or stop processes in T-SQL

2. Call a program or procedure without stop the current sequence in a block

3. blocking, blocking, blocking agghh!

4. blocks, blocks, and more blocks

5. ANNOUNCEMENT: Debian GNU Linux package to start/stop database(s)+listener(s) on system start/stop

6. Database/Database Server Blocking.

7. Block/Blocking/Locks Question

8. Oracle block size - OS block size

9. Discarting changes in Block without refetch whole block

10. Understanding Oracle blocks and UNIX blocks re. redos

11. ORA-01578: ORACLE data block corrupted (file # 9, block # 50)

12. OS block size vs. DB block size


 
Powered by phpBB® Forum Software