> 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
© William Yuan 2000
Email William