We currently updated to SQL Server 2012 and now we are encountering a slower performance when connecting to the geodatabase on SQL Server 2012.

Here are the things that we tried to fix the issue: - Re-indexed all the tables. - Installed the support patch from ESRI.(http://support.esri.com/en/downloads/patches-servicepacks/view/productid/160/metaid/1954).

But none of those fixed the performance issue. The machine hosting the SQL Server 2012 is a VM but it is running with 24 gb of ram. So it shouldnt be under resourced.

I found a similar problem and one of the post was saying to use the SDE Binary Storage type. I didn't do that yet because he did mention that its not recommended.

  • Which ArcGIS product are you using? Is it perhaps ArcGIS for Server including its ArcSDE component? – PolyGeo Nov 27 '13 at 0:10
  • 2
    RAM is hardly the only resource used by databases. In fact, disk access is the most-impacted resource, which is why most folks steer away from VMs for databases. Do you have any benchmarks you can run, using just SQL-Server tools, to measure the system throughput on various queries, so you can determine whether the new VM is providing the same performance you've been experiencing on the older database server? – Vince Nov 27 '13 at 0:49
  • i will check to see if i can run some benchmarks on the VM's SQL server. The weird thing is we didnt encounter this performance issue when we were still using SQL Server 2008. After we updated was the time we encountered the issue. – Juno Nov 27 '13 at 16:02
  • 1
    @Juno: we've seen some bad SQL Server 2012 performance as well and it has come down to SQL Server not using a spatial index (we can force it from SSMS, but that doesn't help the Arc clients). And using SDE Binary was the solution suggested by Esri Support. Here's a link from a co-worker of mine of what he's tried: social.msdn.microsoft.com/Forums/sqlserver/en-US/… – Jay Cummins Nov 27 '13 at 16:52
  • @Jay: Unfortunately the SQL server is not installed with a SQL profiler so we can't really make a benchmark on this. I did try to edit MAXDOP as what you have suggested but it didn't really impact the performance issue. Might also good to note that the performance issue happens on the initial load where most of the layers are stored in SDE. I'm thinking that the SDE binary is my last resort on this issue. Thanks. – Juno Nov 28 '13 at 17:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.