> somebody must have thought about this already:
>
> we are in the process of migrating our production databases to our
> IngresII host from our Ingres1.0 host. i want to be able to have both
> copies of the database around until i'm sure the move was successful.
> but i need to deny access to the old. destroydb is too scary because
> the copy.out script generated by unloaddb had errors and had to be
> edited by hand.
>
> we found that "sql -l db" will lock the database, but only for the life
> of that process. is there a better way?
>
> thanks
> marg
Marge,
Ingres 1.0 ... hmmm ... I assume you mean OpenIngres 1.x ...
You could do one of many things:
1) Make the database private via accessdb, allowing only super users
access.
2) Mark the database closed via iimonitor, but a reboot will open it
up again
3) Don't run a server for it. This implies you need to quit running
server that server "any" database (you know the, servers that put
* entries into iinamu)
Hope that helps,
Michael Leo mleo@cariboulake.com mal@visi.com
Caribou Lake Software http://www.cariboulake.com Java, Oracle, Ingres
Minneapolis, Minnesota (612) 323-9713
>Rename the directory containing the data by using the 'mv' command.
>
>Hope this helps.
>
>Anuj.
Anuj's suggestion will work, as well as the other person who
suggested renaming the .CNF file.
HOWEVER, be sure Ingres is completely down when you do this, as
it caches various information and may cause problems for you.
Cheers,
Michael Leo mleo@cariboulake.com mal@visi.com
Caribou Lake Software http://www.cariboulake.com Java, Oracle, Ingres
Minneapolis, Minnesota (612) 323-9713
Hello Marg,
You could shutdown Ingres and then rename the data directory
(for example, from "proddb" to "save_proddb"). The database
will not be accessible and will remain unchanged. Recovery
is also very quick (simply rename the directory back to the
original name). This is a simple trick but works well.
The database *will* be marked inconsistent if anyone tries to
access it (and the data directory is missing), but this is one
case where using verifydb to force the DB consistent is not a
bad thing to do.
Chip Nickolett ChipN@Comp-Soln.com
Comprehensive Consulting Solutions, Inc. (www.Comp-Soln.com)
Phone: 262-544-9954 Fax: 262-544-1236
Ingres Q & A
Back to William's Home Page
© William Yuan 2000
Email William