topic Optimal Strategy for upgrading to 10.x geodatabases in Data Management Questions

Optimal Strategy for upgrading to 10.x geodatabases

MarcNakleh — Fri, 14 Dec 2012 17:35:27 GMT

Hey everyone,

What is the best way of upgrading 9.2/9.3 geodatabases to 10.x?

In my mind, I can either:

Use the built-in "Upgrade Geodatabase" tool

Create a new 10.x geodatabase and use FC to GDB to copy from one GDB to the other.

Take the original shapefiles (where available) and use FC to GDB to convert everything to FC's

My gut would be to simply use the Upgrade Geodatabase tool, but I was wondering if this would always be the case.

Thanks a bunch!

Re: Optimal Strategy for upgrading to 10.x geodatabases

JakeSkinner — Fri, 14 Dec 2012 18:24:08 GMT

Hi Marc,

The Upgrade Geodatabase too will be the best approach. This tool allows you to maintain all of your geodatabase objects such as domains, subtypes, relationship classes, etc. Also, if you are using an SDE geodatabse, the Upgrade Geodatabase tool will maintain all of your database users, groups, privileges, etc.

Re: Optimal Strategy for upgrading to 10.x geodatabases

VinceAngelo — Fri, 14 Dec 2012 20:45:23 GMT

You *NEVER* want to use shapefiles to pass geodatabase information between instances --
you'd lose numeric nulls, wide character strings, dates, column names, versions, and all
geodatabase functionality. Plain ASCII files would be more reliable and easier to use.

One of the potential approaches you missed was to use database tools to transfer the
entire database to the new server, and *then* use upgrade tools.

Keep in mind that ancient instances (older than three revs) are usually not supported for
direct upgrade (e.g. 9.2 to 10.1) so you may need to use an intermediate release to
upgrade the old geodatabase before upgrading again to a recent build (e.g 9.2 sp6 ->
9.3.1 sp2 -> 10.1 sp1).

The main drawback to in-situ database upgrade is missing the opportunity to defragment
and/or spatially defragment your unversioned and/or base tables. Even simple reloading
of frequently updated tables could result in significant performance improvement.

If you plan to change geometry storage type, you'd be better off doing that in the
source instance (if possible, otherwise in an intermediate transition database), so that
the fragmentation which occurs with storage change doesn't embed slower performance
into your new instance.

- V

Re: Optimal Strategy for upgrading to 10.x geodatabases

MarcNakleh — Mon, 17 Dec 2012 14:49:10 GMT

Thank you very much for your answers!

Vince: I meant that the source is sometimes shapefiles, which I export into a GDB, and not using the shapefile as some kind of weird interchange format. But it's understood that there's no need to start back from shapefile.

I'm also not very aware of the proper processes for spatial defragmentation. If I am using ArcGIS for Desktop, would this involve recreating the Spatial Index of individual FC's one by one? Is there a means of managing this by way of scripting / automation?

Thanks in advance!
Marc