POST
|
Our service request with Oracle is not providing workarounds, tips or solutions for working with SDE to avoid the data dictionary corruption or avoiding the breakage of Data Pump. We have just rebuilt SDE manually in another database so have a good export to try importing into another working instance, hopefully not breaking Data Pump and keeping the d.d. intact and no missing ST_GEOMETRY data types. I have just completed a support call to ESRI for their help. I will keep you updated. Jane Thanks for the update Jane. If and when our downstream customer opens a support ticket with Esri I will also report any findings.
... View more
03-20-2012
08:30 AM
|
0
|
0
|
631
|
POST
|
We have come to the conclusion that our problems of Data PUmp not working are related to Oracle Note, Ora-21700 Object Does Not Exist Or Is Marked For Delete When Dropping a User With ST_GEOMETRY Dependencies [ID 1385929.1]. Dictionary gets corrupted when tables using a specific object type (SDE.ST_GEOMETRY) are tried to be dropped after the type was tried to get dropped. This corruption in the dictionary may have affected the DBMS_DATAPUMP package. I have tried re-installing the package with no success. ESRI has a note on the subject of dropping the user SDE and/or other users who use the ST_GEOMETRY datatype, http://support.esri.com/en/knowledgebase/techarticles/detail/34483. Drop the users using the ST_GEOMETRY, before dropping the SDE user, not the other way around. Yes, we use the SDE for business. We are in the midst of moving the instance to a new server and have been pulling our hair out trying to move SDE. On our source database, Data Pump is broken with no solution from Oracle Support to fix it. Now the new destination database has a broken Data Pump as well with some schemas up and running in production. We are working towards re-building the instance, re-build SDE from scratch and bring in the other schemas again. And be very clear which user schemas use the ST_GEOMETRY datatype and never drop them! Hi Jane, Thanks for posting your findings. Sorry you're having so much trouble. We may ask our customer to open a ticket with Esri. Although the support forums are terrific, they aren't intended to be a replacement for Esri Support. Many problems can be solved here but this issue is particularly stubborn / tricky. I cannot open a ticket myself so I can only suggest it as an option. Incidentally, at a class this week on Oracle Enterprise Manager (Grid Control) I mentioned the datapump issue to an instructor. His take was that many 3rd party UDTs have trouble with datapump. My (over-?)interpretation: Esri may be the victim here, not the culprit. Still, it would be nice to have official guidance. I'll post an update if we open a ticket or have success in some other way. What about using a file geodatabase as an intermediate medium for versioned feature classes? There's no ST_GEOMETRY for Oracle spatial data type in a file GDB (naturally). But I wonder if the customer could run a Python geoprocessing task to recreate things as ST_GEOMETRY from a FGDB source to the desired Oracle target. Anyone done this? It's not entirely clear to me if the customer needs versioned edits and state trees preserved during the migration process. Will ask for clarification. Likely overthinking this? Happy Friday. 🙂 Best, Dana
... View more
03-16-2012
03:05 AM
|
0
|
0
|
879
|
POST
|
I can replicate your missing SDE types. There is 1 missing subobject: OBJECT_NAME SUBOBJECT_NAME STATUS ------------------------------ ------------------------------ ---------- ST_DOMAIN_METHODS $VSN_1 VALID No progress here. Jane, are you using ST_GEOMETRY because it's the default spatial data type for SDE on Oracle, because you have a business requirement for spatial SQL functions, or another reason? For us, SQL functions were a "nice to have." Don't know that anyone is currently using them. And what's very much not nice to have: limited options for moving data around. I believe we also chose it because of a belief that ST_GEOMETRY being the default spatial data type means it would be the focus of future development.
... View more
03-13-2012
01:00 AM
|
0
|
0
|
879
|
POST
|
I did not assert that the combinarion was unsupported -- I started the sentence with "If". Please do not over-interpret what I write; I might be discouraged from writing at all. - V Ok. Your conditional statement is duly noted.
... View more
03-12-2012
08:49 AM
|
0
|
0
|
502
|
POST
|
I'm running on 32-bit RHEL 5.4 at home, and haven't had problems that couldn't be attributed to running on a six year old P4 host with only 2Gb RAM, but I'm not using 11.2.0.3. If both Oracle and Esri don't support 5.4, then that should be a source of real concern. - V Thanks Vince. Didn't realize 64 bit RHEL Server 5.4 / Oracle 11.2.0.3.X was now an unsupported platform. For new Oracle hosts, we wanted to go with RHEL Server 6.X. But Oracle has not certified that for 11.2.0.3.X. So I believe we're going with 5.8. OS version is a decision made by our sysadmins here and not the DBAs (me and my colleagues).
... View more
03-12-2012
05:33 AM
|
0
|
0
|
502
|
POST
|
SDE.ST_GEOMETRY has consistently better performance than SDE_LOB. You should evaluate the cost of moving to LOBs before deciding to do so. - V Thanks Vince. I have also heard the opposite. In principle ST_GEOMETRY should be consistently faster. But I don't know if that's the result for every customer on every sub-platform. Seems reasonable to test in one's own environment to see what is actually the case. That said, what to do about migrating feature classes with the ST_GEOMETRY User Defined Type? Is there a current Best Practice? Is datapump no longer recommended (if it ever was), etc? It's also been recommended to me to use RMAN to clone a DB instance as a means of moving ST_GEOMETRY-based data from instance to instance. Dana
... View more
03-12-2012
04:42 AM
|
0
|
0
|
879
|