Select to view content in your preferred language

Data Load Issue

4831
10
04-08-2013 08:02 PM
User35489
Frequent Contributor
Dear Admins,

We installed new server with RHEL 6, Oracle 11.2.0.3.0, ArcSDE 10.1. Our old server is on RHEL 5, Oracle 10.2.0.3, ArcSDE 9.3.
When i tried to import the feature class to new server or copy the feature class from old to new one, migrate storage etc. I faced errors given below. I donot know whether it is because of the change of Geometry type, as in 9.3 we used to have SDEBINARY and in 10.1 we have ST_BINARY.
Please look into this issue.


1. Error 000210: Cannot create output Database Connections\ ...
2. Failed to paste [FeatureClassName]
    Underlying DBMS error [ORA-00604: error occurred at recursive SQL level 1
    ORA- 04063 ...
    ORA- 06508 ...
3.  ERROR 000955: Error encountered migrating the database storage ...




Thanks
Abdullah
0 Kudos
10 Replies
VinceAngelo
Esri Esteemed Contributor
You should really include the full error message cascade.  Without it, there
isn't much we can do to help you.  (Note: the alternative of SDEBINARY is
ST_GEOMETRY, not ST_BINARY).

- V
0 Kudos
User35489
Frequent Contributor
Yup, Vince
It was a typo. It is ST_GEOMETRY.
Please find the errors attached.

Thanks
-AS
0 Kudos
VinceAngelo
Esri Esteemed Contributor
I won't open .doc files.  ASCII text is best; images are tolerable if they're
in an image format (but I'm less likely to look at them).

- V
0 Kudos
User35489
Frequent Contributor
Vince,
FYR,

Error 1:

Paste Failed

Failed to paste NAMEOFLAYER
Underlying DBMS error [ORA-29876: failed in the execution of the
ODCIINDEXDELETE routine
ORA-00942: table or view does not exist
ORA-06512: at "SYS.DBMS_SQL", line 1199
ORA-06512: at "SDE.SPX_UTL", line 1860
ORA-06512: at "SDE.ST_DOMAIN_METHODS", line 2237
][SDE.GDB_Items][STATE_ID=0]
Underlying DBMS error [ORA-29877: failed in the execution of the
ODCIINDEXUPDATE routine
ORA-00942: table or view does not exist
ORA-06512: at "SYS.DBMS_SQL", line 1199
ORA-06512: at "SDE.SPX_UTL", line 1860
ORA-06512: at "SDE.ST_DOMAIN_METHODS", line 2237
ORA-06512: at "SDE.ST_DOMAIN_METHODS", line 2371
][SDE.GDB_Items]



Another thing i want to make sure about is the size of the tables in SDE user after "Enable Enterprise Geodatabase" is successful. I alloted 1GB for SDE tablespace. It is filled 3.5%. i.e. 35MB only. Is it normal ?


Thanks for you interest
-AS
0 Kudos
VinceAngelo
Esri Esteemed Contributor
You should probably contact Tech Support, since I don't think your install
procedure succeeded.  Your alternative is to reinstall from scratch, then
if it fails again, contact Tech Support.  DO NOT UNDER ANY CIRCUMSTANCES
DROP THE SDE USER WHILE GIS DATA OWNERS HAVE TABLES WITH
ST_GEOMETRY TYPE COLUMNS -- THIS WILL CORRUPT YOUR ORACLE
INSTANCE.

- V
0 Kudos
User35489
Frequent Contributor
You should probably contact Tech Support, since I don't think your install
procedure succeeded.  Your alternative is to reinstall from scratch, then
if it fails again, contact Tech Support.  DO NOT UNDER ANY CIRCUMSTANCES
DROP THE SDE USER WHILE GIS DATA OWNERS HAVE TABLES WITH
ST_GEOMETRY TYPE COLUMNS -- THIS WILL CORRUPT YOUR ORACLE
INSTANCE.

- V


Even i doubt that the SDE tablespaces are not as less as 35MB. I will cross check the space SDE System tables aquires, if anyone else has the ArcSDE 10.1 installed.
Anyways thank you so much for the guidence. Will share the updates with you.

Thanks
-AS
0 Kudos
User35489
Frequent Contributor
Update:

The above error is resolved by fixing the privilege. i.e. granting the privilege execute on DBMS_SQL to the Schema account. But unfortunately, the paste once again failed as it gives out below error,

"Failed to paste "LayerName"
Underlying DBMS error [ORA-04020: deadlock detected while trying to lock object SDE.ST_DOMAIN_METHODS]


Trying to resolve this issue .....


Thanks
-AS
0 Kudos
EmadAl-Mousa
Deactivated User
you need to kill one of the oralce sessions to elminate the "dead lock".

also, the packages are granted seperatly to eache schema user for the geodatabase, or you are granting them to public ? (DBMS_SQL,UTIL,..etc) ?

also, you need to increase the tablespace of your schema not the sde tablespace while migrating to a different storage, if i am mistaken the conversion is done within tablespace, unless you want to create a new fresh schema (duplicate) from the original one with "st_geoemtry"  storage then you need to create also another dbtune conifugration keyword.....

please clarify to us your steps to help you.

Regards,
0 Kudos
User35489
Frequent Contributor
Good Day,

Removing SDE Administrator account and recreating it, fixed the problem.

Thanks all for support.
With Best Regards

-Abdullah
0 Kudos