You trusted Migrator to do all that? I'm a pretty religious man, but that is beyond the limits of my faith. Part of using Migrator is knowing what it can and cannot be trusted to do well. It's like driving an old car you've owned for a while - you know it's weaknesses and limits, and you learn to work around them to get where you're going without incident.
I have run Migrator on systems with similar or less system resources, so I don't think that's the problem. My first guess was that either the person using Migrator didn't fully understand exactly what it would do (who does?) or didn't have it configured exactly as it should have been, which is pretty common. But then you said that the Migration took 25 hours? I have never seen Migrator take anywhere near that much time to do what it does, even with massive changes to migrate. What version of Migrator are you using? The newest one is supposed to address some performance issues, but that doesn't address the data corruption issue, which is the more serious one, IMO. Rick On 8/23/07, Koyb P. Liabt <[EMAIL PROTECTED]> wrote: > > ** > > We have 3 environments and a SANDBOX. Code tested successfully in QA and > was imported into Production and broke workflow. > > To fix, we ported code from Prod to a SANDBOX, then to QA, then to Prod > again. The technical staff took 25 hours for our OOB applications with > minor customizations (AR System 7, Change, Asset, and SLA). > > To prepare we did the following: > > 1. Prod database has been restored into QA and Dev for synchronized > environments. > 2. Generated .def files from QA for all objects prior to every > migration. > 3. Loaded the "new code" to development > > It took over 25 hours for the following: > > a) migrate new objects from .def files into QA > > b) restore the QA database with "new objects" into Dev > > c) restore the QA backup to QA (to undo the build that failed > changes in QA). > > > Our environment: > > The Prod database increased from 4GB to 17GB and after restoring it into > Dev, where the Migrator Utility lives, it looks like Migrator cannot handle > the workload when it targets the development server (itself). The Dev server > is a virtual machine with 2 CPUs and 4GB of RAM > > Total this took 50 hours. > > When the code was restored to productions - it was to be restored to the > previous state. However, we found code was wiped out again in production. > Apparently we went a few versions back, and the code we are now viewing is > from months ago.. The person migrating said that code could be missed and > introduce new bugs - that is the risk we take. Migrator has a report that > shows failure or dropped code. Validating the results of the migration - > shouldn't this protect us and prevent this from happening? > > Also are we doing something wrong here? I have never had migrations take > so long. Nor have I ever seen code wiped out all the time. With each > migration things seem to go wrong. > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
