数据服务器环境：
4核，内存 4G
Windows Server2003
ArcSDE9.3
Oracle10.2.0.1
空间数据量大，每个图层的数据量可以有几十万条记录（最多的一个图层有90万条）
症状：
当使用ArcMap加载图层，进行数据的频繁操作（放大、缩小、查询），服务器端即报错，弹出对话框 gsrvr.exe程序错误，内存不能为 read 之类的。客户端会出现Network I/O error
查看sde错误日志
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
解决方案：
打esri中国技术支持和咨询朋友，得到几个方案：
1、给ArcSDE9.3打sp1补丁
2、给Oracle升级到10.2.0.3（这个版本配合sde93比较稳定，据说每个版本的ArcSDE都有对应的Oracle版本，配合使用比较稳定，具体什么版本可以咨询esri中国）
3、使用ArcSDE9.2，配合稳定的Oracle版本。
经过尝试得到结论
方案1没有解决问题
方案2解决问题，虽然sde-esri-sde.log日志中仍然有 load_buffer error -51，但是其他的症状都没有了。
解决步骤：
经过反复尝试，终于成功的将Oracle10.2.0.1升级到10.2.0.3，下面介绍一下Oracle升级的步骤
1）下载升级包，一定要下载的正确的升级包，之前就是因为错误的升级包几次没成功，浪费了很多时间。p5337014_10203_WINNT.zip是经过我验证的。
2）重新安装Oracle10.2.0.1，确保安装前已经卸载干净原来的Oracle，所有的Oracle服务已经删除干净，如何干净的卸载Oracle在网上有介绍，在安装时不安装数据库。
3）安装升级包p5337014_10203_WINNT.zip，选择路径是要选择Oracle10.2.0.1的 db1 的路径 。
4）使用Oracle的工具建立数据库
5）使用Oracle的工具建立监听
OK了！ArcSDE9.3终于可以正常工作了！这是尝试了各种办法后的喜悦！
Error Message
After 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"
"gsrvr.exe - Application Error: The application failed to initialize properly"
Cause
Windows 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 desktops: interactive and non-interactive. Desktops 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 desktops 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 should read:
SharedSection=1024,3072,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 desktops. 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 desktops 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 desktops 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 receives 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.
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 desktops: interactive and non-interactive. Desktops 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 desktops 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 should read:
SharedSection=1024,3072,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 desktops. 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 desktops 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 desktops 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 receives 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 Workaround
The 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 desktops are in use.
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 desktops 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,3072,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 receives 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 desktops. If operating exclusively in Windows authentication mode, more ArcSDE connections may be serviced by reducing the size of 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 desktops 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.