Re: Migration question

On Thu, 14 Apr 2005 16:01:24 -0800, "David E. Grove" <david_grove@correct.state.ak.us> wrote: >We would like to migrate from 9.21 to 10.0 on a new machine. We are also >changing the storage regime. > >In testing, dbexport (without -ss) followed by dbimport on the new machine >works just fine, but it does mean the system will be unavailable for about 5 >hours when we do it for real. (In our test sessions, we do the dbexport >from a research machine, as described below.) We can live with this, but >I'm wondering if there is a way to reduce the downtime. > >In the past, I have been able to reduce or eliminate downtime when portions >of the data needed to be exported by creating an archive (no downtime) and >then restoring the archive on a twin research machine. From the research >machine I could dbexport or onunload to my heart's content. No impact on >users. > >I'm wondering if there is some clever way to reduce downtime for the Great >Migration mentioned in first sentence. I can still create an archive and >restore it on the research machine, and then dbexport/dbimport from research >machine to the new machine. But, that leaves the final product on the new >machine several hours out of sync with the production box (it would have >continued to operate). > >Is there an alternative to the "brute force" way of just downing the system, >dbexport/dbimport from old to new system (with the new dbspaces that are >unrelated to the current production system). As I said, the downtime is >feasible, just not desirable. > You could probably use HPL to handle the data movement, say, in express mode . . . . JWC