<div class="gmail_quote">On Tue, Mar 31, 2009 at 4:26 PM, Matt Amos <span dir="ltr"><<a href="mailto:zerebubuth@gmail.com">zerebubuth@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">On Tue, Mar 31, 2009 at 4:11 PM, 80n <<a href="mailto:80n80n@gmail.com">80n80n@gmail.com</a>> wrote:<br>
> Let me see if I understand correctly what you are saying.  You think that<br>
> the currently proposed migration from the old server and old schema to the<br>
> new server with a new schema that includes some referential integrity<br>
> constraints will take longer than the time that has been planned for it?<br>
<br>
</div>i think that is what stefan is saying, yes.<br>
<div class="im"><br>
> I assume that Matt and co. have done some benchmark tests on the migration<br>
> and have some idea of how long they think it will take.<br>
><br>
> Matt how long do your benchmark tests suggest the migration will take?  How<br>
> much confidence do you have in your test figures?<br>
<br>
</div>on the computer i have here (2x quad core opteron, 16Gb ram, 4x1Tb<br>
SATA raid0) the import takes 15h, changeset synthesis takes another<br>
15h and the integrity checks + FK take about 10h, so about 40h in<br>
total. of course, if something goes wrong it doesn't give us much<br>
chance to fix it.<br>
<br>
on the new db server we're 3.5h into the import with only 1 table<br>
remaining, so i'm very hopeful that will finish well before 15h.<br>
changeset synthesis and integrity checks should get a similar speedup<br>
from the faster hardware.<br>
<br>
i am confident we can do the migration in the 4-day window that we're<br>
committed to, but i can't guarantee anything.<br>
</blockquote><div><br>Matt<br>Thanks for this info.  I'm reassured.<br><br>I assume that Stefan worries are based on some different scenario for migration.<br><br>80n<br></div></div><br>