Copying/Exporting to SDE causes crash

[PanGIS]

Hi guys,

I am experiencing this since long time.

Once I have to move a FC to an SDE Database:

1) if I export the FC usually takes ages, (even with FC with 20 points) sometimes I cannot even see the geoprocessing finishing.

2) if I copy the FC to the SDE, sometimes works, sometimes, like right now, the process causes a crash.

Then, if I cancell the process ArcMap takes even more time to be available again.

I am not talking about big datasets, a simple layer with 20/30 points.

Looking at the task manager the memory used at the moment is 90%.

It might be a memory shorteness?

If not, where should I look?

[JakeSkinner]

Hi Pan,

Can you provide some information about your environment?  Ex:

1. What version of ArcGIS Desktop (i.e. 10.3.1)?
2. What RDBMS are you using (i.e. SQL Server 2012)?
3. What version is your geodatabase (i.e. 10.3.1)?
4. What is the operating system the RDBMS is installed on?
5. Is Desktop and RDBMS on the same server?

[PanGIS]

Jake Skinner wrote:

Hi Pan,

Can you provide some information about your environment?  Ex:

1. What version of ArcGIS Desktop (i.e. 10.3.1)?   ---> 10.2
2. What RDBMS are you using (i.e. SQL Server 2012)? ---> SQL S 2012
3. What version is your geodatabase (i.e. 10.3.1)?   ---> 10.2
4. What is the operating system the RDBMS is installed on?  W Server 2012
5. Is Desktop and RDBMS on the same server?   Yes
6. SQL Server Enterprise GDB

[PanGIS]

I don't know whether it is the right approach but I solved by stopping a service that was consuming a lot of memory. I copied and then rerun the service.

It worked for me.

[VinceAngelo]

How long is "ages"?  The usual unit of database activity measurement is milliseconds.  Once warm, I can connect to a SQL-Server 2012 database in under 50 milliseconds, and export queries usually proceed at 30,000 features per second.  If your connect time exceeds 3000ms, there may be something wrong with your network configuration, though I have seen long Desktop connection times (5000-7000ms) with hundreds of thousands of tables and tens of thousands of feature classes.

The terminal release of ArcGIS 10.2.x was 10.2.2.  All 10.2 users are strongly advised to install 10.2.2 and all the relevant security and functionality patches.

- V

[JasonTipton]

How exactly are you measuring connect time in ms?

Our Oracle databases regularly take close to 10,000 ms starting from the point where I double click the connection in ArcMap 10.2.2 until it actually opens.

In SQL Developer the same database opens in under 2,000 ms.

We have maybe a "thousand" tables. I would still measure it in "hundreds" though.

[VinceAngelo]

The sdeping utility of se_toolkit​ has a millisecond precision timer (displayed with the -v option).

Oracle is a bit slower than SQL Server to establish a connection:

D:\Temp>sdeping -i sde:oracle11g:/#redacted#/#redacted# -u #redacted# -p ****** -v

ArcSDE 10.2 Connection Test Utility      Wed Feb 17 11:10:51 2016
------------------------------------------------------------------------
         Server: (none)
       Instance: sde:oracle11g:/#redacted#/#redacted#
       Database: (none)
       Username: #redacted#
          RDBMS: Oracle
        Version: 10.2.0
    Description: 10.2.2 geodatabase(Oracle)
        Release: 102001
  Connect Delay: 655.00 ms

The sdeping command was created from exercise 1 in the (now defunct) "Accessing SDE with 'C'" training class to evaluate connection performance issues at a client site where MapObjects connection was very slow.  Since it *only* does a connection, and doesn't perform the inventory operations of a Desktop connection, the timing is more comparable to a Server connection.  But now you have me thinking I can add a flag to do the gyrations that Desktop does, so the connection times could be compared...

- V

[JasonTipton]

>> sdeping -i sde:oracle11g -u [username] -p [password]@[tnsName] -v

ArcSDE 10.2 Connection Test Utility      Wed Feb 17 15:30:06 2016
------------------------------------------------------------------------
        Server: (none)
      Instance: sde:oracle11g
      Database: (none)
      Username: [username]
          RDBMS: Oracle
        Version: 10.2.0
    Description: 10.2.2 Patch 290200 geodatabase(Oracle)
        Release: 102002
  Connect Delay: 8.18 secs

Got  8 seconds the 1st time, but after that it dropped below 800 ms

[VinceAngelo]

That isn't uncommon, which is why I specified "once warm" in my timing reporting.  Cold databases, and cold ArcGIS clients, for that matter, rarely operate with blinding speed. Once the client and server have all the DLLs needed for the connection pipeline, then they tend to behave more consistently (the standard deviation drops significantly without the first sample of 10).

- V

[PanGIS]

Hi Vince,

thank you for your imput.

the ages, in my case is even hours. As I said most of the times I don't see the GP finish worlking. I just cancel the process and Arcmap then crashes.

Once I stopped that service that was consuming almost all memory the copying process completed in few seconds.