Solution: gsrvr.exe error, memory cannot be read, map white screen, I/O error.

Data Server Environment:

4-core, 4 GB memory

Windows server2003

Arcsde9.3

Oracle10.2.0.1

There is a large amount of space data. The data volume of each layer can contain hundreds of thousands of records (up to 100,000 records for one layer)

Symptoms:

When you use ArcMap to Load Layers and perform frequent data operations (zoom in, zoom out, and query), an error is reported on the server. The gsrvr.exe dialog box is displayed.ProgramError. The memory cannot be read or the like. A network I/O error occurs on the client.

View SDE error logs

Sde-esri-sde.log

Db_array_fetch_attrs OCI fetch Error

Load_buffer error-51

Giomgr-esri-sde.log

SDE server went down on system exception 0xc0000005

Solution:

Contact ESRI for technical support and consultation in China and get several solutions:

1. Patch arcsde9.3 with SP1

2. Upgrade Oracle to 10.2.0.3 (this version is stable in combination with sde93. It is said that each version of ArcSDE has a corresponding Oracle version and is relatively stable in combination. For specific versions, contact ESRI China)

3. Use arcsde9.2 in combination with a stable Oracle version.

After trying to get a conclusion

Solution 1 does not solve the problem

Solution 2 solved the problem, though load_buffer error-51 still exists in the sde-esri-sde.log log, but none of the other symptoms.

Solution:

After repeated attempts, we finally successfully upgraded oracle10.2.0.1 to 10.2.0.3. The following describes how to Upgrade Oracle.

1) To download the update package, you must download the correct update package. It was a waste of time because the update package failed several times. P5337014_10203_winnt.zip is verified by me.

2) reinstall oracle10.2.0.1 to ensure that the original Oracle has been uninstalled before installation, and all Oracle services have been deleted. How to clean and uninstall oracle is described on the Internet,Do not install databases during installation.

3)install and upgrade the package p5337014_10203_winnt.zip,Select the path to db1 of oracle10.2.0.1.

4) use oracle tools to create databases

5) create a listener using Oracle tools

OK! Arcsde9.3 is now working! This is the joy of trying various methods!

 

 

 

 

Error messageafter making several connections to an ArcSDE service, the connection hangs and a gsrvr.exe crash appears on the ArcSDE server. querying the ArcSDE service with sdemon-o status hangs. existing connections continue to function and new connections made by way of direct connect work. any new application server connections hang and more gsrvr.exe application errors may appear on the server.

"Gsrvr.exe-application error: the application failed to initialize properly"

Causewindows has exhausted its 'non-interactive desktop heap '.

The ArcSDE application server, the giomgr, runs as a service on Windows and spawns windows child processes, called gsrvrs. all Windows processes run within a desktop, a logical display and container for icons, windows, and threads.

There are two kinds of dynamic tops: Interactive and non-interactive. when tops operate within window stations. windows Services, depending on how they start, usually allocate from the non-interactive desktop heap. the maximum amount of heap memory allocated to noninteractive tables tops is limited by a Windows initialization parameter called sharedsection. if you receive the above error message, you may need to change the sharedsection parameter.

A service cannot use more memory than allocated from its non-interactive desktop. When a service exhausts its non-interactive desktop heap, it is unable to create new threads or processes.

When an ArcSDE client connects to an ArcSDE server, that server spawns a gsrvr.exe process. This gsrvr.exe process consumes a small amount of the desktop heap allocated to the ArcSDE service.

If the ArcSDE service starts as a domain account, the gsrvr.exe allocates from the desktop, a non-interactive desktop heap of 512 KB, created for the ArcSDE service.

If the ArcSDE service starts as the LocalSystem account, the gsrvr.exe allocates from the shared desktop, a non-interactive desktop heap of 512 KB, pertaining to all services running as LocalSystem.

If the ArcSDE service starts as the LocalSystem account with 'Allow service to interact with the desktop 'enabled', gsrvr.exe allocates from the default desktop an interactive desktop heap of 3 MB.

The size of the interactive and non-interactive desktop heaps is determined by a registry setting under \ HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ Session Manager \ subsystems.

Within the 'windows' string value, there is a 'sharedsection 'parameter that by default shoshould read:

Sharedsection = 512

The second and third parameters represent the size of the interactive and non-interactive desktop heaps. if Terminal Services are enabled, a fourth value may be present in this string. windows enforces a 48 MB maximum desktop memory limit for all instances tops. windows also uses some of this 48 MB pool for its default window station, screensaver, and logon screen. the size of either of these two parameters can be changed to influence the size of the interactive and non-interactive desktop heaps.

Boosting sharedsection's third parameter limits the total number of threads tops that Windows can create, as each non-interactive desktop is larger, thus using more of the global 48 MB pool. however, each service has more memory available to it. decreasing sharedsection's third parameter increases the number of parameter tops windows can create but decreases the amount of memory each desktop can consume. for example, increasing the third parameter of sharedsection to 2 MB tells windows to allocate 2 MB to each new non-interactive desktop. each service that starts up as a domain account has es a new non-interactive desktop of 2 MB. each service that starts up as the LocalSystem account allocates from the existing 2 MB system non-interactive desktop. in this case, if the server has more than 20 services configured to start up as a domain account, Service Startup problems may be experienced after the 20th service is initiated. when the 20th service starts, the global 48 MB limit is close to exhaustion.

Each ArcSDE gsrvr.exe consumes approximately 9 KB of memory from the desktop in which it starts. this figure, 9 KB, is only an approximation. it may differ by platform and load. if the default configuration of the ArcSDE instance and the ArcSDE Windows service has not been changed, approximately 55-64 gsrvrs (ArcSDE client connections) can be created before the error occurs. this number also differs If Windows Authentication with ArcSDE for ms SQL Server is used.

Solution or workaroundthe solution depends on the ArcSDE platform. step 1 is applicable to all ArcSDE RDBMS types. step 2 is applicable to SQL Server sites only. step 3 is applicable to sites using Terminal Services on their SDE server. all three of these steps pertain only to Windows platforms.

There is currently no method to determine how much memory is in use by a single desktop or how much is left within the global pool. use oh.exe, a Windows Resource Kit tool, to monitor how many tops are in use.

• Estimate the number of gsrvrs needed. for clients like ArcView, arceditor, and arcexplorer, A gsrvr is usually a single ArcSDE connection. for ArcIMS, the number of gsrvrs depends on the service type. assuming two virtual server threads per spatial server machine CPU, follow this general formula:

  (2 Image Service threads * Total CPUs) + (number of query server threads)

  For example: (2*8) + 8 = 24 gsrvrs

  This recommendation also assumes the use of an image and query service, and all axls connect as the same user and database to the ArcSDE server. if different databases or users are referenced in the axls, then the formula becomes:

  (# Databases * # mapservice threads) + (# DBS * # queryservices)

  If the number of gsrvrs exceeds 55-64, the maxconnections setting of ArcSDE, consider either changing some of these connections to direct connect or boost the 3rd sharedsection parameter in the registry. as Direct Connect runs as a thread within the client process, no desktop is allocated to it on the ArcSDE server. to change the sharedsection, find the \ HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ Session Manager \ subsystems key in the registry and edit the Windows string value. locate the 'sharedsection 'string and boost its third value from 512 to 1024. this doubles the amount of gsrvrs the ArcSDE service can spawn.

  Sharedsection = 1024

  The server must be rebooted once sharedsection is changed.

• SQL server sites using Windows authentication for their ArcSDE connections.

  users connecting to ArcSDE services with Windows authentication may experience different connection behavior. when the ArcSDE Application Server spawns a gsrvr from a Windows authenticated connection, that gsrvr does not allocate from the same desktop as the app server process, the giomgr.exe, but need es its own desktop (non-interactive) of 512 KB.

  multiple Windows authenticated connections from the same machine allocate from the same desktop, but connections from different machines allocate from new instances tops. if operating exclusively in Windows Authentication mode, more ArcSDE connections may be serviced by matching the size of the both the interactive and non-interactive desktop heap instead of boosting it as mentioned above.

  This connection behavior will change in future releases of ArcSDE for ms SQL Server.

• Sites that have terminal services or Citrix deployed on their ArcSDE server.

  Terminal Services reduce the desktop global memory pool from 48 MB to 20 mb. this means that fewer total has tops are created. if operating in this environment, the third parameter of sharedsection can be increased, but use caution with the number of different non-LocalSystem services created. remember, whenever a non-LocalSystem service starts, it allocates memory from the global memory pool to a new desktop.

  It is not recommended that SQL server sites use Terminal Services with Windows authenticated ArcSDE connections. if this configuration must be run and difficulties are experienced supporting enough ArcSDE connections, allowing the ArcSDE service to interact with the Desktop may solve the problem. in this case, do not change any of the sharedsection parameters.