About this blog...

The people of Esri UK sharing what we do, what inspires us and how we get the most out of Esri technology.

Entries on this blog are the views of the individual authors and do not necessarily represent the views of Esri UK.

Follow us

LVF Blog Page
Schools Blog Page
Technical Support Blog Journal
Think Location
« Speed up your tiled map services | Main | OSTN02 supported in ArcGIS desktop »

Time to upgrade

I guess it's coming around to the time when customers who jumped to ArcGIS 9 or 9.1 are again thinking about moving up to the latest releases. Combined with that, the DBMS of choice back then - maybe 6 years ago now, may be out of support now so a new DBMS release is part of the plan too. Hence I get emails dropping in along the lines of "we are on ArcGIS 9.1 Oracle 9i and want too move to ArcGIS 10 Oracle 11g, what is the best upgrade path".

Now these questions are being asked because they will have discovered the conundrum, ArcGIS 10 doesn't support their 9i, ArcGIS 9.1 doesn't support 11g so which way to jump.

My response to this is, hang on let's step back a bit and look at the bigger picture.

Firstly the hardware, presumably this is now 6 years old also and server perfromance has moved on and prices come down so you get more for your money than you did when the old system was installed.

Secondly, is the geodatabase which you want to move really that clean? What "mistakes" have happened over the 6 years which have been recovered from, what versioned editing/compress horrors are lurking and what classes where created in a rush of enthusiasm and have never been referenced since. Are there flaws in the permission model which should be rectified. Also if the original system used shared logfiles how much space is wasted in logfiles, maybe belonging to people long gone from the project.

Thirdly is upgrading the database completely transparent? Reading the SQL Server 2005 documentation soon shows that an upgraded database from 2000 somehow isn't quite as clean as a fresh 2005 db - and of couse we are now on 2008.

I'd therefore suggest that it is really worth considering starting again, Get a new server, install the latest db, Oracle 11g, SQL Server 2008, PostgreSQL;  bear in mind that you could change dbms at this stage. Create a new geodatabase and use the ArcGIS tools (maybe with the backward compatible direct connect drivers) to copy the data into the new database. This will doubtless throw up new questions like how to tidy up the versioning model etc but in the long run will be worth it. The result should be a clean database automatically created with high precision coordinates. Versioning can then be added and a permissions model. The logfile settings can use session logfiles possibly with temporary tables.

This may also be an opportunity to consider the spatial type. If the existing database is SDE Binary consider changing to ST_Geometry (Oracle) or Geometry (SQL server). Also review any Raster data in the old database and consider whether the new Mosaic datasets offer improved performance and maintainability.

If archiving of edits is of interest now is the time to switch it on, plus if geodatabase replication is on the horizon, add GUIDs to the classes which will be involved.

Whilst it may seem to be a lot of work in the short term, and may involve making decisions that it would be easier to sweep under the carpet, I think for many sites this is the only realistic way forward and will ensure a future-proofed ArcGIS 10 solution.

So, go on then, pick up the phone and order that server. It'll make sense in the long run!

PrintView Printer Friendly Version

EmailEmail Article to Friend

Reader Comments (2)


Intrigued as to consider other db spatial geometry over SDE binary - have I missed something with 10 that gives you benefits other than the obvious w.r.t. opening up the native db language?

June 9, 2011 | Unregistered CommenterB. Fisher

On the one hand, if it ain't broke don't fix it! However I guess my point was that it is something else to consider as an option if you are starting from a clean slate. If you have an "old" oracle geodatabase using long raw for SDEBinary, Raster etc you definitely need to move on but SDEBinary with blob storage would do. As you suggest the only other thing that a spatial type gives is access using native DB tools. Depending on the choice however this may also open up access by other GIS products. Interestingly if you need to use multiversioned views and your data is sdebinary the view is attribute only, if a spatial type is used the geometry is also exposed. So to answer your question - no you haven't missed anything, maybe its just a chance for some housekeeping!


June 13, 2011 | Registered CommenterRob McPherson

PostPost a New Comment

Enter your information below to add a new comment.

My response is on my own website »
Author Email (optional):
Author URL (optional):
All HTML will be escaped. Hyperlinks will be created for URLs automatically.