Make it faster!!!! Improve Performance!!!
Oog, each commit is like five minutes. Neither standard commits of source code (same SVN server) nor redgate SQL Compare actions (same local database server) take that long!
Keywords: Performance, Speed, Fast
We have been doing a lot of work on SQL Source Control lately. We’ve recently improved performance when you link a database, go to the commit and get latest tabs (especially subsequent visits where we can rely on data being cached), and when selecting/deselecting all on the commit and get latest tabs.
If you are still experiencing performance problems, please make a new suggestion that is very specific to what you would like us to work on. Is it a specific step in the commit process that is taking a long time? Is it viewing history that is taking a long time?
We’ve also started to work on this suggestion, Don’t refresh the commit/get latest automatically, https://redgate.uservoice.com/forums/39019-sql-source-control/suggestions/462220-don-t-refresh-the-commit-get-latest-automatically, which will also help with performance.
Contact firstname.lastname@example.org if you can share your database schema with us for performance testing purposes.
If you are experiencing problems with server load, please see http://documentation.red-gate.com/display/SOC33/Changing+or+disabling+the+database+polling+interval. Contact email@example.com if you have any questions about this.
SQL Source Control Product Manager
Jon Baggaley commented
This is still an issue when switching back and forward between databases even though they are (local). Please can you delay the refresh or just show the previous version and then refresh the update in the background to give a better perceived performance if nothing else? As it is clicking back and forward between databases can be quite a slow process
I just made a separate post for my proposal to use all cores for "registering database", so please vote if you observed the same behaviour and long for better performance:
When SOC says "registering database" only 1 CPU on the dev-machine is used. This step takes the longest amount of time, so optimizing SOC to use all CPUs (in my case 8!!) for that operation should speed up the whole thing
This would be great for us. Our database is not small. The operations for "Commit changes" and "Get latest" take somewhere between 20 and 30 seconds to complete. Otherwise great software. Thank you!
I would like the ability to 'Refresh Selected' or similar. Imagine I refresh the 'Commit Changes' window and get a bunch of differences. Following the principal of atomic commits, I really want to select different changes and group them into single commits... and then having committed those changes with one comment, I would like to go on and do the same for a different set of changes. It would be nice if I could just clear the selected items, or 'refresh' them, just to confirm that they had no further changes. That would leave the list a little clearer for the next commit.
You guys would probably like all our devs to use Source Control, but I am afraid it is not quite ready to be used by devs yet (performance being a key issue).
join free commented
Trial version Data Compare 10 error: system.outofMemory.exception even though the RGTEMP system variable set to a large external disk folder. No success even after following these steps: http://documentation.red-gate.com/display/SDC10/Troubleshooting+System.OutOfMemoryException+during+comparison
We have exactly same issue. we are using sql 2008r2 and 2012.
We have one database with 500 tables and step 'Registering a database takes' more then 30 minutes !!! This is ridiculous. How I can use it on larger dbs.
I experienced the same problem
Dathan Liblik commented
We love this product theoretically, but the performance is spectacularly bad in not one, but all of: speed (5-6 minutes per sync), memory consumption (GBs), TFS traffic (high), reliability (crashes SSMS all the time), data integrity (at least once a month we have to manually do a file-based check-in to rectify some confusion in the sync that then leaves the product unusable until the check-in is manually resolved).
I don't want to be negative, but this is such an outlier to normal red gate quality, and your premium prices mean you should have a stellar tool with maybe an occasional bug. This is two years running now. What could be more important?
Red gate - get on this. It's a major blemish to your otherwise excellent standards. Please.
184.108.40.206 Resolved the issue for me.
Just tried 220.127.116.11 and the initial syncing issues are still there. I outlined two observations the following forum post:
I'm going back to 18.104.22.16829 again. =/
@Nicholas: Yeah, I also tried the latest and experienced the same issue. So I'm staying with 22.214.171.12429 for now.
Nicholas Orlando commented
So the issue does still seem to be in 126.96.36.199, but only when you first connect the database.
Nicholas Orlando commented
Still seem to have the issue in 188.8.131.52
Update: Downgrading to 184.108.40.20629 resolves the issue for me. It's a work around. I hope they make that installer available for others to download while they work on this.
Interesting, my Step 4 has greatly increased in time but I thought it was all related to this duplicate trigger error that Red Gate is working on. Apparently not. So I'm adding a vote for this one.
Coders are not very patient to sit there and listen to a disk spin and spit.
it appears that connection logic is broken and is ignoring the enabled transport settings. I consistently receive the "Named Pipes Provider" error during step 4. Why is red-gate trying to use Named Pipes when it is disable on both the client and server machines? Makes the tool completely unusable
So, true. It's now taking 5 minutes or more to complete step 4. Not sure how this is "A more reliable and less resource-intensive method for giving the username for changes in the shared model." per the release notes. I've been using RG tools for nearly 10 yrs now and have taken them into numerous shops. But over the last several releases of SQL Source Control it seems like the product is moving backwards.
I'm running on the "dedicated" configuration. Step 4 does take a very long time, however, it does complete for me. It has completed on two of my smallest databases. The larger databases are still running after ~20 minutes.
In order to improve performance, you need to change the base algorithm. If you stick with current logic and compare everything every time - this product will never work as expected and will even be unusable on db's with fair amount of objects. You should compare only what is changed since the last sync. modify_date in sys.objects is your friend!