Why DBAmp V22 SF_MirrorAll takes much more time (couple hours) than V5.1.9 SF_RefreshAll? even I skipped many tables, like %History, %Share... Also there are many error messages: Error occurred creating primary key for table.
Solved
Bad performance of DBAmp V22
Best answer by Dani Moran
That is not always a fair comparison - SF_MirrorAll can behave quite differently than SF_RefreshAll even in the same version, since SF_Mirror sometimes runs full copies instead of the delta copies that SF_Refresh always does. Is the timing difference on some runs, or all of them? The full copies should only be once every 7 days.
I would suggest sending an email to [email protected] and including the complete message output of your longer running SF_MirrorAll. There are a number of small details that can be tweaked with it, perhaps some more performant options that SF_Mirror has that SF_Refresh doesn’t, that can be far more easily addressed by going over the output. If there is some consistent performance issue there also, the support team can open a ticket to work on getting that resolved as well!
As for the error you mentioned, that particular error message is mostly a warning, also related to the difference in the stored procedure that you are using. If you had run SF_MirrorAll in v5.1.9, you likely would have gotten the same warning! That can be caused by permissions issues, or be the result of having another table by the same name in a different schema.
This topic has been closed for replies.
That is not always a fair comparison - SF_MirrorAll can behave quite differently than SF_RefreshAll even in the same version, since SF_Mirror sometimes runs full copies instead of the delta copies that SF_Refresh always does. Is the timing difference on some runs, or all of them? The full copies should only be once every 7 days.
I would suggest sending an email to [email protected] and including the complete message output of your longer running SF_MirrorAll. There are a number of small details that can be tweaked with it, perhaps some more performant options that SF_Mirror has that SF_Refresh doesn’t, that can be far more easily addressed by going over the output. If there is some consistent performance issue there also, the support team can open a ticket to work on getting that resolved as well!
As for the error you mentioned, that particular error message is mostly a warning, also related to the difference in the stored procedure that you are using. If you had run SF_MirrorAll in v5.1.9, you likely would have gotten the same warning! That can be caused by permissions issues, or be the result of having another table by the same name in a different schema.
Thanks Dani for the detailed answer, I will send an email to [email protected] with the log.
Can v22 and v5.1.9 run parallel on the same server? of course with different databases which point to different linked servers. Because so many changes on the new version, we have to test everything, mean while the project team have to use the old version.
They can run in parallel! They will need, as you say, different databases and different linked servers, but they can be installed side-by-side, precisely for those testing purposes.
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.
