Migrating MD iMap to ArcGIS Server 10 – Testing Results
The past few weeks have been devoted to testing the migration of MD iMap to ArcGIS Server 10. It is important to limit potential issues and ensure all services and applications function appropriately after the upgrade. If you have ever successfully done an upgrade, you know how important it is to test, test, and do more testing.
Because ArcGIS Desktop, ArcSDE and ArcGIS Server are spread out among multiple machines within the MD iMap infrastructure, we can upgrade the different components at different times. So, we are only upgrading ArcGIS Server at this time. And, MD iMap has seven instances of ArcGIS Server: 2 staging, 1 pre-release and 4 production servers. We upgraded one of the two staging instances to ArcGIS Server 10 so we could test away. The Center for GIS’ goal is have all instances upgraded by the end of November.
Please note that ArcSDE is still at 9.3.1 until we do a domain migration at the end of November. Once the migration is complete, we will upgrade ArcSDE to 10.0 as well.
While I understand that every environment is different, I wanted to share two problems we have discovered in our upgrade testing.
1. No special characters in WMS-enabled services
Issue: Several map services would not draw in ArcCatalog and we received the following error when adding them to ArcMap: “Could not add the specified data object to the map.”
Workaround: After speaking with Esri Technical support, they confirmed this is a known bug – #NIM066837 Need to support additional special characters when using WMS. The bug states that a WMS enabled map service that contains a comma (,), tilde (~), parenthesis (()), ² , ° , ? , and ` in the layer name won’t start.
At this point the only workaround is to either disable the WMS capability in the affected map services, or to rename the layers in the MXD.
2. Address Locators in 9.3.X ArcSDE Database do not work with a Geocode Service at 10.0
Issue: When trying to create or start a geocode service at ArcGIS Server 10 that utilizes an address locater in a 9.3.1 ArcSDE database, the following error appears: “Configuration GeocodeServices/MD.State.MDStatewideTest.GeocodeServer can not be started. Server Object instance creation failed on machine mdimap-XXX-X. The connection property set was missing a required property or the property value was unrecognized.”
Workaround: Publish the address locator from a file geodatabase. We did this and the ArcGIS Server 10 geocode service now starts and works appropriately. I posed my question to Esri’s technical support and they said that they have seen other cases where a new address locator was needed to work past the error. They also said that sometimes a locator built with 9.3.1 will publish to server 10, but practically speaking is finding that more often than not, they don’t. This is especially the case with customized address locator.
Tech support concluded that there are 2 options.
1. Publish the locator from a file geodatabase. There has been some unusual behavior with older address locators stored in SDE geodatabases. **Honestly, at ArcGIS 10, you’ll get better performance with file-based locators anyway.
2. Create a brand new address locator in ArcGIS 10. For best practices, it is recommended that you re-create the address locators using the current version of ArcGIS.
This brings me to my last point. I inquired again to the Esri technical support person to expand on his comment “…at ArcGIS 10, you’ll get better performance with file-based locators” so I could fully understand what he meant. His response indicated that prior to 9.3.1, ArcSDE would be faster, however, at 9.3.1 and later, benchmark testing has indicated that file geodatabases are actually faster for not just geocoding services, but also for serving vector data! He said that Oracle CAN be faster with Vector data, but only if the database is tuned very well. This has more to do with I/O against the database – and I/O is relatively limited with a file geodatabase. He stated he would use ArcSDE when editing, with versions, etc. and he suggested a presentation on ArcGIS Server Performance and Scalability–Performance Factors and Optimization.
For those of you like me, who don’t understand what I/O is, here is how the Esri technical support person explained – “Basically, it has to do with how the bus (the part of the computer that connects the motherboard to the hard drive) sends and receives data back and forth to the database software. Fewer paging operations have to be performed against a file geodatabase because pages can be cached ‘in memory’ as opposed to accessing the database. Fewer resources are being used to achieve the same goal.” Very cool!
While we did run in to these two issues during our testing, there are workarounds that we will put into place. These two issues will not hinder us from pushing forward with the migration of the remaining six instances to ArcGIS Server 10. Next steps you may ask? More testing, more research and more fun!