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
The source control is super good but is to slow can you improve that?
Everytime I go to the Commit changes window the source control plug in takes a long time to refresh the changes. The step that takes the longest is step 3 out of 4 "Registering database". Using SQL Server 2008 / SSMS 2008 and SVN. We were using TFS but moved to SVN hoping the performance would be better.
My gut feel is that that the change detection algorithm is too slow or inefficient. Perhaps you can use timestamps to improve performance buy not having to check all of the objects every time.
This is making the product unusable for my team.
Seems that since the release of SQL Source Control 220.127.116.1108 step 4 has been taking a very long time. I don't know if this is just my set up or is happening for everyone. Also, if I try to do a dedicated database development then step 4 never finishes.
Improve the speed and reliability. Use the same engine as your compare tools, which are very fast. TFS integration is very slow. Your last version was faster too. The new and fancy animation on the logo is nice, but I would trade it for a rollback.
Calculating changes for large databases is very slow
600+ tables (270+ static) and 2600+ procs means that "Determining latest version" takes longer than allowable to resolve. I literally let this run and went for a 15 minute walk and it did not finish. Please work on scalability for large databases or I cannot recommend this for purchase.
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
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.
18.104.22.168 Resolved the issue for me.
Just tried 22.214.171.124 and the initial syncing issues are still there. I outlined two observations the following forum post:
I'm going back to 126.96.36.19929 again. =/
@Nicholas: Yeah, I also tried the latest and experienced the same issue. So I'm staying with 188.8.131.5229 for now.
Nicholas Orlando commented
So the issue does still seem to be in 184.108.40.206, but only when you first connect the database.
Nicholas Orlando commented
Still seem to have the issue in 220.127.116.11
Update: Downgrading to 18.104.22.16829 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!
Ben Sproat commented
How about an update on this? 3.1 is out and the product is still unusable for one of our primary databases. The commit tab takes upwards of 20 minutes to come up if it doesn't time out first. It only ever works once or twice and only if that is the only database we have linked. After the 1st or second refresh we run out of memory. If i have to work in that database i load it up on a separate machine click the commit tab and go do something else for a while on my normal machine and hope it actually gives me results. If it fails reboot and try again.