前两天有一个用户咨询一个性能的问题：
用户的环境：ArcGIS Desktop10、SQL Server2008 SP1、ArcSDE10（SP5补丁），数据为只读数据。
1：都是以MXD形式打开，有相关的符号（简单符号），同一个数据库中不同的数据集，一个数据集的浏览速度快，另一个数据集的浏览速度慢。
2：另一个比较慢的MXD，在1：5W以上浏览速度快，在1：5W以下浏览速度慢。
猛的一块，感觉非常蹊跷，但是可以得出相关结论：
1：同一个数据库，有性能差别，肯定不是数据库本身的问题
2：不同的MXD有性能区别，重点检查MXD的问题。
一般情况下，已有性能的问题，我们首先需要查看的是空间索引。
但是观察了两个性能不同要素类的空间索引，发现有所不同
1：性能比较好的
上面的数据使用ArcSDE for SQL Server的BLOB存储，也就是直接使用Default关键字
以二进制格式存储在 SQL Server 数据库中的要素类
SQL Server 内地理数据库中以二进制格式（ArcSDE 压缩二进制或 OGC 熟知二进制几何表示）存储的要素类由基表和相关联的要素表和空间索引表（如下所述）组成。
http://resources.arcgis.com/zh-cn/help/main/10.1/002q/pdf/ss_fc_tables.pdf
2：性能比较差的
上面的数据是使用SQLServer2008的GEOMETRY进行存储。
使用 Microsoft 几何或地理类型存储在 SQL Server 数据库中的要素类
默认情况下，存储在 SQL Server 数据库中的地理数据库使用 Microsoft 几何存储类型来存储要素。还可以使用 Microsoft 地理存储类型。使用这些存储类型之一的要素类具有基表。基表中包含类型为 GEOMETRY 或 GEOGRAPHY 的列，用于存储要素类几何；不存在关联的要素表。
基表是用于存储属性的 DBMS 表，而且可通过添加空间列的方式实现空间化。基表名称为要素类的名称。
使用几何存储或地理存储的要素类表还具有关联的系统表（GDB_ITEMS、SDE_spatial_references、SDE_table_registry、SDE_column_registry、SDE_geometry_columns 和 SDE_layers）及关联的视图。
View a diagram of a feature class using SQL Server geometry or geography storage..
最后了解到，用户需要使用SQL直接操作要素类。所以采用Geometry存储。
ArcSDE for SQLServer的GEOMETRY和GEOGRAPHY存储介绍 - ArcGIS技术研究 - 博客频道 - CSDN.NET http://t.cn/zOac8Dy
然后在针对性能比较差的MXD，已经排除了符合问题，标注问题，发现有一个将近470000记录的线要素类导致速度比较慢。
47W要素类BLOB存储：浏览速度1s左右
47W要素类GEOMETRY存储：浏览速度5s左右，而且服务器的sqlserver.exe的CPU占用率猛增到99%，而且在大比例下浏览效率依然非常低。
而且用户的MXD设置了可见比例尺，在1：50000比例尺下显示该图层，所以出现上面所述，大于1：5W比例尺就慢，反之就快。
而且重建了使用Geometry存储的要素类的索引，依然没有什么效果。感觉是在进行全图的扫描，而且建立索引和删除索引的效果基本一样。
SQL Server 支持空间数据（Geometry和Geography）的空间索引概述 - ArcGIS技术研究 - 博客频道 - CSDN.NET http://t.cn/zjylzBN
得出结论：
SQL Server 2008 SP1在使用BLOB存储和使用SQL Server默认存储方法有性能差别。
如果用户选择了SQL Server 2008 SP1数据库，如果存储ArcSDE10里面的要素类有大数据量的线数据或者面数据，建议使用ArcSDE默认的BLOB存储。
但是ArcSDE10.1没有这个问题。
如果使用SQL Server2008 R2没有这个问题（其实ArcSDE10的系统需求，只支持SQL Server2008 R2）
解决方案：
但是如果，用户希望使用SQL Server的默认空间存储，该怎么解决呢？
我们可以使用ArcMap自带的要素缓存（feature cache)工具来解决，先全图构建要素缓存，这样的话就可以进行高效的浏览了。
相关帮助参考：http://resources.arcgis.com/zh-CN/help/main/10.1/#/na/00660000043n000000/
如果用户需要使用SQLServer 2008 SP1默认存储，而且不想使用要素缓存，另外一种解决方法：修改max degree of parallelism值
参考Esri的技术文章，也有可能是多核CPU导致的该问题
Reduced spatial query performance on multiprocessor servers running SQL Server 2008
http://support.esri.com/en/knowledgebase/techarticles/detail/38871
Bug ID: 625896
https://connect.microsoft.com/SQLServer/feedback/details/625896/spatial-index-not-used-on-multiproc-machine-unless-maxdop-set-downward
分析以上问题，有可能是使用SQL Server2008 SP1的Geography存储之所以慢就是没有走空间索引，尽管使用桌面查看Index信息是有的。
那么可以使用以下方法来修改。（修改完毕之后，在SQL Server2008 Sp1的Geography存储浏览速度没有任何问题）
此选项是一个高级选项，仅应由有经验的数据库管理员或认证的 SQL Server 技术人员更改。
若要使服务器能够确定最大并行度，请将此选项设置为默认值 0。 若将 maximum degree of parallelism 设置为 0，SQL Server 将能够使用至多 64 个可用的处理器。 若要取消生成并行计划，请将 max degree of parallelism 设置为 1。 将该值设置为 1 到 32,767 之间的数值来指定执行单个查询所使用的最大处理器核数。 如果指定的值比可用的处理器数大，则使用实际可用数量的处理器。 如果计算机只有一个处理器，将忽略max degree of parallelism 值。
您可以通过在查询语句中指定 MAXDOP 查询提示来覆盖查询中的 max degree of parallelism 值。 有关详细信息，请参阅 查询提示 (Transact-SQL)。
索引操作（如创建或重新生成索引、或删除聚集索引）可能会大量占用资源。 您可以通过在索引语句中指定 MAXDOP 索引选项来覆盖索引操作的 max degree of parallelism 值。 MAXDOP 值在执行时应用于语句，但不存储在索引元数据中。 有关详细信息，请参阅 配置并行索引操作。
除了查询和索引操作之外，此选项还控制 DBCC CHECKTABLE、DBCC CHECKDB 和 DBCC CHECKFILEGROUP 的并行。 使用跟踪标志 2528，可以禁用为这些语句所做的并行执行计划。 有关详细信息，请参阅 跟踪标志 (Transact-SQL)。
配置 max degree of parallelism 选项
在“对象资源管理器”中，右键单击服务器并选择“属性”。
单击“高级”节点。
在“最大并行度”框中，选择执行并行计划时所使用的最大处理器数。
话题延伸：
使用SQL Server数据库还是有不少Bug和问题的，大家可以参考一下：
Bug NIM-082298
Nimbus ID NIM082298 Submitted Jun 29, 2012 9:55 AM Severity Medium Applies To ArcGIS Version Found 10.1 Prog Language N/A Server Platform All Windows Client Platform Windows Database SQL Server 2008 R2 Locale N/A Status Duplicate Version Fixed N/A SP Fixed N/A Synopsis
For certain feature classes, GEOMETRY spatial type takes longer to draw in arcmap compared to SDEBINARY spatial type.
Additional Status Information
Duplicate of NIM082657
Alternate Solution
N/A
________________________________________________________________________________________-
Bug NIM-082657
| Nimbus ID | NIM082657 |
|---|---|
| Submitted | Jul 11, 2012 2:46 PM |
| Severity | Medium |
| Applies To | ArcGIS |
| Version Found | 10.1 |
| Prog Language | N/A |
| Server Platform | All Windows |
| Client Platform | All Windows |
| Database | SQL Server |
| Locale | N/A |
| Status | Resolved |
| Version Fixed | 10.2 |
| SP Fixed | 10.2 |
Synopsis
When working with an SQL Server 2012 geodatabase and Geometry or Geography type data, ArcMap drawing performance is slower than it was using SQL Server 2008. This affects all rendering and editing operations.
Additional Status Information
N/A
Alternate Solution
N/A
-------------------------------------------------------------------------------------------------------
版权所有，文章允许转载，但必须以链接方式注明源地址，否则追究法律责任!
4419
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
