Migrate storage issue

[AnastasiaAourik]

Have you used the arc catalog migrate storage tool (found at data management tool - geodatabase administration)
I tried to run in on my featureclass and get error message

Messages
Executing: MigrateStorage 'Database Connections\Connection to SIIHARDYDEV31.net.smith.com as gismaster.sde\WELLSGIS.GIS_MASTER.WG_BITREC' SDEBINARY
Start Time: Wed Jan 30 15:01:20 2013
ERROR 000955: Error encountered migrating the database storage of Database Connections\Connection to SIIHARDYDEV31.net.smith.com as gismaster.sde\WELLSGIS.GIS_MASTER.WG_BITREC..
Function or option not implemented yet [WELLSGIS.GIS_MASTER.WG_BITREC]
Failed to execute (MigrateStorage).
Failed at Wed Jan 30 15:01:20 2013 (Elapsed Time: 0.00 seconds)

Can someone help!
PLEASE!!

[ShannonShields]

It looks like you are trying to migrate to SDE Binary format. This is not supported. Migration is only supported from SDE Binary to other storage types, not the other way around.

Here is a full list of which migrations are supported: http://resources.arcgis.com/en/help/main/10.1/index.html#//002n00000076000000

-Shannon

[AnastasiaAourik]

Hmm. That seems strange given that (at 10.1) default GEOMETRY_STORAGE is GEOMETRY.
Anyway, I was able to get my featureclasses to use SDEBINARY simply by
(1) Changing the DEFAULTS GEOMETRY_STORAGE config parameter to SDEBINARY
(2) Re-running my Python script that creates the feature class(es) from our 3rd party data providers [In my case, I am lucky because my workflow includes this step to RECREATE all my feature classes]. 

Note: If what you are saying is true (Not sure why our ESRI technical guy did not alert me when I told him I was planning to run MIGRATE STORAGE to go from GEOMETRY to SDEBINARY) that migrate storage does not support migrating TO SDEBINARY,
then folks should (a) Export data to some temporary file geodatabase, (b) Change DEFAULTS GEOMETRY_STORAGTE config param to SDEBINARY, then (c) copy all your data back to your geodatabase from the temporary file geodatabase.

Just also thought I should SHARE with this community that I have found performance to improve by about 100% when I moved to SDEBINARY.  My performance test was on a point featureclass of > 650,000 points drawn at full extent using the
arcgis share as (wizard) to publish a map service, using the PREVIEW tool to indicate how many seconds it takes to load the map
with this single feature class.

Perhaps some ESRI geodatabase person can reply and tell us why this is the case.
Curious why ESRI has decided to make default GEOMETRY_STORAGE = GEOMETRY for SQL SERVER when SDEBINARY is faster.

Thanks,
Anastasia

[VinceAngelo]

I have no idea why the DEFAULTS keyword is set to "GEOMETRY", but I can say
that I avoid use of DEFAULTS keyword, and always maintain proactive control
over the keywords I do use (with an explicit GEOMETRY_STORAGE key).

- V

[AnastasiaAourik]

I hear you but I just don't mind using DEFAULTS (infact I prefer to use this so I won't have to change all my python scripts)
Regardless, here is the blurb about the change in GEOMETRY_STORAGE starting in 10.1...

http://resources.arcgis.com/en/help/main/10.1/index.html#/SQL_Server_DBTUNE_configuration_parameters...

�?�Microsoft SQL Server Geometry type�??This is Microsoft's spatial type for managing spatial data defined by coordinates on an arbitrary plane and for which the curvature of the Earth is not a consideration. This is the default spatial storage method of geodatabases in SQL Server beginning with ArcGIS 10.1. Keep the GEOMETRY_STORAGE parameter set to GEOMETRY if you want to store your spatial data in this format. If the GEOMETRY_STORAGE parameter is not set, the GEOMETRY type is assumed.


So, I am really trying to get some discussion going about performance using this default.
I have found that it is much slower than SDEBINARY.  Perhaps, I am missing something that must be set or configured so that
my performance using GEOMETRY storage is faster.

[VinceAngelo]

A large point table is going to have a very different performance characteristic
than a small polygon or medium line table.  I always recommend benchmarking
all storage options before implementing in production, especially since the
differences can also manifest from server to server (tuning options can also
make a big difference, as can spatial defragmentation and coordinate reference).

I will say that the "draw all features" benchmark is not the best way to gauge
which storage format will perform best when zoomed in.

- V