Dataset not registering as versioned

[KevinReeves]

Hello all,

I upgraded our Oracle db software this weekend to 11.2.0.3.  In doing so I created a new gdb on our production server.  Prior to this, I copied all of our datasets to a backup db.  Once the new production db was ready, I copied the datasets into the new db.  I haven't had any problem registering the datasets except for 2 of them.  Not sure what the problem is.  I am able to see the data just fine, but when I try to register them as versioned, it just hangs up.  The last time I tried it, it ran for 2 hours before I decided to kill it. Any thoughts or ideas?  The 2 datasets are assessor information with large feature classes. One of these is a parcel fabric.  When I copied them to the backup db, I had no problem registering them as versioned.  So I am not sure if the problem lies within the data or within the db.  Any help would be greatly appreciated.  I am running Oracle 11g R2 and ArcGIS 10.2 on a Windows 2008 Server.

Thanks,
Kevin

[WilliamCraft]

Can you give some background on your backup database?  Is it Oracle 11g R2 with 10.2 SDE as well?  What spatial geometry type are you using for your backup database and for the one which you're trying to populate?

I have experienced very similar behavior to what you're describing, where a small handful of our datasets took forever to register as versioned compared to the rest.  One of those datasets contained a geometric network, and the other had a lot of data compared to all of the others.  Our method involved copying and pasting from a 9.3.1 SP2 geodatabase to a 10.2.1 geodatabase, both on Oracle 11g R2.  However, our 9.3.1 SP2 geodatabase used SDELOB and our 10.2.1 geodatabase used ST_Geometry.  We discovered that the register as versioned process was much faster if we stuck with SDELOB at 10.2.1 instead of accepting the default keywords for ST_Geometry when copying and pasting.  I can't tell yet if this is what might be affecting you, but I wanted to share my experiences thus far.

[KevinReeves]

Yes, the backup database is the same as the production database.  I needed to upgrade our Oracle from a 32 bit 11g R2 to a 64 bit 11g R2.  To make sure that this process went smoothly, I first installed it on my desktop machine (windows 7 professional) and copied all my data from the 32 bit Oracle to this new backup 64 bit database.  Then this weekend I upgraded the Oracle on our production database, and copied the data back into it from the database on my machine.  I was looking at it earlier and noticed something odd....Whenever I go to register a dataset, the 'register as versioned' dialog box pops up.  There is a check box with 'Register the selected objects with the option to move edits to base'.  In all the datasets that versioned properly, this was an option that could be checked.  In the datasets that won't version, this is greyed out with the statement 'One or more of the selected objects does not support moving edits to base. This option is not available'.  So it sounds like there is something up with the data.  The really odd thing is that 2 of the 3 datasets that won't version in the production database WILL version on my machine.  The only one that won't is a parcel fabric dataset that was sent to me from our ESRI rep.  I know that these datasets have large amounts of data in them, but the last time I tried to register one of them as versioned, I let it run for over 2 hours and it never completed.  All other datasets usually take less than 15-20 seconds.  Hope all of this is clear enough to understand!  Thanks!

Kevin

[WilliamCraft]

Despite being a bit older of an article, this might explain the behavior you just described for why some of your datasets may not register as versioned or why they have the 'move edits to base' option unavailable:

http://support.esri.com/en/knowledgebase/techarticles/detail/32632

You're using a 10.2 desktop client and a 10.2 geodatabase, right?  It was not abundantly clear when I read your last post.

[EmadAl-Mousa]

as William mentioned, what Geodatabase Version are you in, and what ArcCatalog Version are you using ?

the backup/restore process was through RMAN or you used expdp/impdp process ?

[KevinReeves]

Yes, sorry.  Both the ArcGIS desktop and the geodatabase are 10.2.  My backup process was using exp/imp.

[WilliamCraft]

Registering object classes as versioned will run an Analyze on each table during the process in order to update statistics if none are present.  In these cases, running Analyze or dbms_stats.gather_schema_stats prior to registration using Oracle DBMS tools can remedy the issue you are seeing and drastically improve the time it takes to complete.  As such, my recommendation is that you give these methods a try in your new database before attempting to register the culprit dataset(s) again.  Please post back to let me know if this suggestion helps.

[KevinReeves]

Is that something that can be done in Oracle Database Control?  Sorry, I am not too familiar with all of Oracles tools & functionality.

[WilliamCraft]

The best method is to do this using SQL*Plus.  From a command prompt on a machine which can connect to your database, open a Windows CMD prompt.  Follow the steps below:

Type sqlplus user/pw@DATABASE  (the user and password could be your SDE account, or you could use SYS or SYSTEM depending on what access you have; if using SYS, then you will need to type sqlplus user/pw@DATABASE as sysdba instead). 

At the SQLPLUS prompt, type EXECUTE DBMS_STATS.GATHER_SCHEMA_STATS(ownname => 'schemaname');  (replace "schemaname" with the actual schema name under which your spatial data exists; you may need to run this once for each schema that has spatial data).

Edit: The SDE account may not have all of the privileges it needs to do this, so you may need to use an account with more privileges such as SYS or SYSTEM.

[KevinReeves]

I was able to fix it today.  A friend had asked me if I had any erroneous A & D tables.  I found some and deleted them, and now everything is registered as versioned.  Thank you both for your help and input.  I hope you have a great week!

Kevin