Re: Migration question

David E. Grove wrote: > We would like to migrate from 9.21 to 10.0 on a new machine. We are also > changing the storage regime. Any reason not to just shutdown 9.21, point 10.0 at the same disk space and bring up IDS 10.0 and let it convert the disk pages in-place? Then you only have to run some update statistics and you're done! Art S. Kagel > 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. > > DG > > >

> > We would like to migrate from 9.21 to 10.0 on a new machine. We are also > > changing the storage regime. > > Any reason not to just shutdown 9.21, point 10.0 at the same disk space and > bring up IDS 10.0 and let it convert the disk pages in-place? Then you only > have to run some update statistics and you're done! > The existing storage is an A1000 attached to an E3500. The new is 3310 attached to V480. Would you be suggesting attaching the A1000 to the new IDS server on the new V480? Wouldn't that mean retaining the existing dbspaces on the A1000? We're running out of space on the A1000, and will have plenty on the 3310, so would like to migrate to new storage. We're also simplifying our storage and administration (at the possible expense of some performance) by following the Oracle S.A.M.E. (Stripe And Mirror Everything) strategy by making one big dbspace that is on the new 3310, configured as RAID10. In other words, instead of about 15 dbspaces carved out of A1000 and internal drives, we're putting everything in a single 60GB rootdbs, that's striped across 6 mirrored pairs in our new 3310. I can't quite connect the dots in your suggestion to get from where we are to where we want to be, but if we can accomplish it with only the need to do an UPDATE STATISTICS, that would be phenomenal. Thank you. DG

David E. Grove wrote: >>>We would like to migrate from 9.21 to 10.0 on a new machine. We are > > also > >>>changing the storage regime. >> >>Any reason not to just shutdown 9.21, point 10.0 at the same disk space > > and > >>bring up IDS 10.0 and let it convert the disk pages in-place? Then you > > only > >>have to run some update statistics and you're done! >> > > > > The existing storage is an A1000 attached to an E3500. The new is 3310 > attached to V480. Would you be suggesting attaching the A1000 to the new > IDS server on the new V480? Wouldn't that mean retaining the existing > dbspaces on the A1000? We're running out of space on the A1000, and will OK, I missed where you said the migration included moving to another machine. You can use multiple copies of my dbcopy utility to copy the data directly from the old server to the new one once the DB is setup. The utils4_ak package has awk scripts that post-process dbschema/myschema output to produce a dbcopy script (among others). > have plenty on the 3310, so would like to migrate to new storage. We're > also simplifying our storage and administration (at the possible expense of > some performance) by following the Oracle S.A.M.E. (Stripe And Mirror > Everything) strategy by making one big dbspace that is on the new 3310, > configured as RAID10. In other words, instead of about 15 dbspaces carved > out of A1000 and internal drives, we're putting everything in a single 60GB > rootdbs, that's striped across 6 mirrored pairs in our new 3310. I'd still carve that up and make multiple dbspaces. The engine parallelizes dirty page flushes by dbspace during checkpoints, archives can be restored for a single dbspace, and other reasons mostly having to do with ease of managing things later on. > I can't quite connect the dots in your suggestion to get from where we are > to where we want to be, but if we can accomplish it with only the need to do > an UPDATE STATISTICS, that would be phenomenal. IFF you want to keep the current disk configuration, set up the same chunks on the new machine, and install 9.21 there. Take an archive on the old machine, restore it using 9.21 on the new machine, then perform the update in-place on the new machine. If you have your heart set on a simpler (or at least different) disk setup then you cannot do this. Art S. Kagel > Thank you. > > > DG > > >

>You can use multiple copies of my dbcopy utility to copy the data > directly from the old server to the new one once the DB is setup. The > utils4_ak package has awk scripts that post-process dbschema/myschema output > to produce a dbcopy script (among others). > Thank you, Art. I will check out dbcopy. I'm inferring from your suggestion that dbcopy would facilitate getting a consistent copy of an online database from one server to another. That sure would be what the doctor ordered. DG