nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

ArcSDE 9.3.1, MS SQL Server2005 running on Virtual Server

CraigBeech

Harddrives: 15k SAS Hard Drives
8GB RAM
CPU: Quad Core 3.0Ghz (X5440)

Virtual Software:
Microsoft HyperV R2 running on Server 2008 R2

We are experiencing slow performance times when making the initial connection to sde and also when adding data from SDE.

It takes ArcCatalog about 40+ seconds to make the SDE connection and the trace log shows that it is when setting the privileges to the data, I have a DB role which all the editors belong to.
The response times are slower than our old physical server which were running SDE, Sharepoint and CRM DB�??s and which only had 4 GB RAM.

Has anyone got any experience with SDE on virtual server?

Regards,
Stefan
ssteenekamp@ppf.org.za

Find more posts tagged with

Accepted answers

All comments

Leigh_AnnWolfe

Does ESRI suggest keeping databases on a physical server for ArcGIS 10? I'm guessing so, but I know a lot has changed as far as cloud hosting with 10 and virtualization continues to grow in popularity for IT departments.

I am being asked by my Systems Admin to answer a series of questions regarding potential virtualization of our current GIS servers. Currently, we have two physical servers running ArcServer, one running SQL & SDE and the other dedicated to webservices and cashed data. I am hesitant to virtualize given that ESRI suggests not to implement ArcServer this way.

Thanks for your input!

Databases should always be run on physical servers. ArcSDE should be run on the
same physical server as the database (unless you're using clustered database
technology). The only reason to run ArcSDE on a virtual server is if you'll only be
using Direct Connect.

- V

SheilaFinn

Has anyone had a successful vmware virtualization of a GIS SQL cluster? Our ArcSDE resides on another server but will eventually be virutalized.

We are planning to throw some pretty significant hardware at it:
________________________________________
HP ProLiant DL580 G7 Server
8-Core Intel® Xeon® Processors X7560 (2.27GHz, 24MB Cache, 130W)

HP 160GB 3G Hot Plug 2.5 SATA 7,200 rpm MDL Hard Drive
HP 160GB 3G Hot Plug 2.5 SATA 7,200 rpm MDL Hard Drive
HP 160GB 3G Hot Plug 2.5 SATA 7,200 rpm MDL Hard Drive

Has anyone used a Raw Data Lun (SAN definition) for the Database to reside. (Using EMC SAN)
Any comments?

If we can get this to behave then we are hoping to virtualize the rest of the GIS component servers. We are hoping to find others who are using beefy hardware, using vmware and have virtualized any GIS components, SQL being of greatest importance to us immediately and experience with the Raw Data Lun is of importance as well.

Thanks for your time and any contributions you might have.

MikeHargreaves

What about at version 10 - does ESRI still not recommend putting server products on virtual servers? I have a blade running Server 2003 standard, and would like to add more RAM, but it is only supported in Server 2003 Enterprise. My Server tech is suggesting we go virtual... If I stay with the blade, does anyone know an easy way to change operating systems?

AdamZiegler

Stefan,

Here are a few links to ESRI White Papers regarding virtual machines.

http://www.esri.com/library/whitepapers/pdfs/arcgis-server-virtualization.pdf
http://www.vmware.com/resources/techresources/10091

All of our servers are virtual; vmware for windows boxes and l-pars for UNIX. We run ArcGIS Server and SDE on virtual window boxes and the SDE database is hosted on a remote UNIX l-par. We use direct connect methodology, but can connect through the SDE application without any major lag time. We recently migrated from very old physical equipment and the new environment is much quicker. That could be due to the age of the old equipment, but all of our end users have been happy with the results.

Hope the paper's help.

-Adam Z

FernandoLlamasJr

From my experience we have our DBs in a dedicated physical box which has only SQL Server and AGS on a virtual server, connecting to the DB using direct connects.

From what I hear from IT folks and all the info on the interwebs, databases and even Microsoft Exchange don't do to well in virtual environments in general. The I/O is so high, especially in database servers that the performance becomes unbearable.

Hope this helps.

CraigBeech

Databases should always be run on physical servers. ArcSDE should be run on the
same physical server as the database (unless you're using clustered database
technology). The only reason to run ArcSDE on a virtual server is if you'll only be
using Direct Connect.

- V

Vince,

ArcSDE and SQL Server is running on the same (virtual Server). I have done some more tests on this and the SQL trace shows that all the time is taken when setting the permissions on the data. We have `3500 layers in SDE. Display time to draw actual data is fast, tested this on a layer with 360 000 poly's and it takes less than 15s to draw landcover for the whole of Zambia.

Where can I find more information & papers on this?
Many thanks,
Stefan
ssteenekamp@ppf.org.za

VinceAngelo

Databases should always be run on physical servers. ArcSDE should be run on the
same physical server as the database (unless you're using clustered database
technology). The only reason to run ArcSDE on a virtual server is if you'll only be
using Direct Connect.

- V

CraigBeech

Thanks Vince.

I will then swop the setup -run SDE on the Physical server and move all the other DB's to the virtual server.

regards,
Stefan

While possible, and supported, ESRI does not recommend production use of virtual servers
for any ArcGIS Server components.

I had a client who requested performance testing of physical v. virtual servers for ArcGIS
Server 9.3.1, and quickly agreed to our team's "use physical" recommendation when they
saw the results. This same client did not even consider running databases on virtual servers
(or if they did, the option was eliminated long before we got involved), which made it easier
to sell ArcGIS Server Image Extension (Image Server) as "image database software" that
needed physical servers with fibre-attached disk ("just like Oracle").

Virtual computing is a great way to configure dozens of test hosts in a single beefy machine,
but it just doesn't hold up under the disk and CPU load of database or server-side GIS use.

- V

VinceAngelo

While possible, and supported, ESRI does not recommend production use of virtual servers
for any ArcGIS Server components.

I had a client who requested performance testing of physical v. virtual servers for ArcGIS
Server 9.3.1, and quickly agreed to our team's "use physical" recommendation when they
saw the results. This same client did not even consider running databases on virtual servers
(or if they did, the option was eliminated long before we got involved), which made it easier
to sell ArcGIS Server Image Extension (Image Server) as "image database software" that
needed physical servers with fibre-attached disk ("just like Oracle").

Virtual computing is a great way to configure dozens of test hosts in a single beefy machine,
but it just doesn't hold up under the disk and CPU load of database or server-side GIS use.

- V

Join the Conversation

Signed in members can post, follow updates, and more. New here? Register a free account.

Quick Links

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.