Latest Contributions by anthonysanchez

‎03-07-2013

Hi, A level 12 trace of about 5-10 minutes of the action may prove useful in seeing exactly where all the time is being spent. I'd start there and post a tkprof of the trace (keep the raw a available just in case). Anthony

‎01-17-2013

Hi, I too have seen this issue before long ago. Please post your environment info along with a sdelayer -o describe_long of the feature class and spatial view. In my situation, i believe my problem was passing the wrong srid to view creation command that prevented the use of the spatial index. good luck, Anthony

‎01-10-2013

Can you please post the execution plans as well?

‎09-26-2012

Hi Kim, That's exactly the workflow that's causing Dori's ghost conflict problem to begin with. Anthony

‎09-26-2012

Hi Dori, while not supported, this can be done. I've done it before for other bulletin board folks. 1) test this! 2) take good backups 3) the trick is to get bulletin board and sde.default to be at the exact same state prior to re-parenting. This is achieved by posting and reconciling the in the appropriate order. 4) once they are at the same state (query sde.versions), you can update the attributes in sde.versions for the version which you'd like to reparent. UPDATE sde.versions SET parent_name = 'DEFAULT', parent_owner = 'SDE', parent_version_id = 1 WHERE owner = 'CHILD OWNER' AND name ='CHILD VERSION NAME'; commit;

‎09-18-2012

Hi, You could try a spatial view - do the work on the db side*. You would use the sde command line tools for this and the result would be a view (actually, multiple under the hood) joining your data that is registered with arcsde. Sdeview -o create ... The one caveat to this is that spatial views don't look at A and D tables (unless something has changed recently). Anthony

‎09-10-2012

Hi Craig, The source and target Datum have to be the same for st_transform. You'll have to convert the coordinates to something based on nad83 first. You may be able to find a service to do this for you or you can do it from arcmap. Can you imagine how useful this tool would be if this restriction did not exist? Anthony

Re: ArcSDE User(s) Auditing in Oracle · ‎05-03-2012

Hi Mohammad, I've been out of the ArcSDE game for a year but miss it dearly and therefore lurk in these forums. 🙂 I've got some ideas that may get you started down the right path but hopefully some of the brilliant folks that participate in these forums can chime in and get you what you need. ArcSDE will only allow the owner of a feature class to recalculate the spatial index so you won't really know who did it if many people have the schema owner password. As for when, this is an interesting challenge. What is your geometry type? sdelob, st_geometry, or SDO? It may be as simple as auditing the gsize1,gsize2,and gsize3 columns in the sde.layers table assuming that a rebuild that yields the same grid size(s) as before the rebuild still update this table. If sde.layers is not an option: If using sdelob/sdebinary you may able to audit the spatial index table for a feature class S<registration_id>. Not sure if a rebuild issues a truncate against this table, a delete from, or a drop and recreate, but truncate would be ideal for auditing a spatial index rebuild since deletes will happen all the time from this table during editing (non versioned) and sde compress (versioned). Also, if you are frequently dropping and recreating feature classes this will become tedious to maintain as the S tables will get renamed each time. If you are using ST_GEOMETRY or SDO there is no S<registration_id> table for a feature class. Not sure if you'll be able to audit a procedure in these cases or if you'll somehow be able to monitor the shape column or respective domain indexes for these that represent the spatial index. There is a SDE table that lists information about all the st_geometry spatial indexes (can't remember the name but it does have "ST_" in the name and its owned by SDE). You may be able to monitor this table for changes as well to determine when a spatial index for a st_geometry feature class was rebuilt. I'd recommend conducting a level 12 trace of a spatial index rebuild for each of your geometry types in use to learn exactly what happens under the hood during a rebuild. Then you should be able to determine exactly what you need to audit and how to audit in such a way that you are not bombarded with erroneous audit activities that you need to filter through. Anthony

‎04-20-2012

Oops. I meant multi versioned view which is just an oracle view. Anthony

‎04-20-2012

Hi rob, If you migrated your storage from sdelob to stgeometry you'll need to recreate your materialized view because the structure is different. There are no longer F or S tables in stgeometry, and these tables are likely still being referenced in your materialized view and giving you the errors. Anthony

‎04-12-2012

Hi Vaibhav, Are you using direct connect or application connections (2 or 3 tier)? If you are using 3 tier check your sde logs. Also - Check with your your sys admin/dba for that linux box and see if any errors were thrown in the system logs or in the alert log for the database. Anthony

‎01-25-2012

Hi Brandon, An edit can only be compressed to the base tables if ALL versions have that edit in common (and there are no locks). This means that a single un-reconciled version can pin your edits like you are currently seeing. This also means that your nightly process of rec/post to the QA version followed by rec/post to default needs one more reconcile of all versions a second time at the very end to get everybody "equal". Do you have any GDB replicas or disconnected editing versions? Perhaps private versions exist that you are unaware of? There is a free ESRI tool called Geodatabase Toolset (GDBT) that will allow you to visualize your state tree and possibly identify your offending version(s). You could also figure out the offending versions via straight sql if you were so inclined, and the output would be a nice report for you to monitor on a daily basis. I do not have the sql to list here, however I'm sure you could find it if you scour around. More info on GDBT: http://blogs.esri.com/dev/blogs/geodatabase/archive/2011/01/27/geodatabase-toolset-_2800_gdbt_2900_-for-arccatalog-_2d00_-now-available-for-10.0_2100_.aspx Good luck, Anthony

‎12-22-2011

Hi, we had the same problem with ArcSDE 10.0 SP3 after Oracle (11.2) export/import. Granting execute privileges to sde.st_spatial_index fixed the problem. I don't know how the privilege got lost, though. Martin Hi folks, Ive come across the before. When you install the sde repository initially, many grants are made against sde objects to PUBLIC. During a data pump schema level import, these public grants are not made and I don't know why. My solution was to scrape all the public grants and synonym ddl for sde objects out of a "virgin" sde schema and save them into a script. I would then run the script after every data pump import of the sde schema to restore all the public grants and synonyms. Hope this helps. Anthony

‎11-04-2011

Hi, Feature data sets are not folders. Using them for organization will add administrative limitations, especially when it comes to permissions. For data in a feature data set: Read/Editing permissions are all or nothing. No granularity. Register as versioned are all or nothing. No granularity. If one feature class is opened in a fds, they are all "locked" from an administrative perspective. Feature data sets should only be used for data that will participate in geometric networks,topologies, etc. If you want to organize your data for users I'd suggest using layer files and folders. Good luck! Anthony

‎09-16-2011

Hi Dana, if you are using 10g or later you should be able to use this: DBMS_MONITOR.SERV_MOD_ACT_TRACE_ENABLE(...) according to the oracle documentation: The SERV_MOD_ACT_TRACE_ENABLE procedure enables SQL tracing for a given combination of service name, module, and action globally for a database, unless an instance name is specified in the procedure. After tracing information is written to files, the information can be consolidated by the trcsess utility and diagnosed with an analysis utility such as TKPROF. All the information was found here You'll probably end up having to trace all sessions of a given module and/or service then filter through and format with trcsess and tkprof. Don't forget to turn it off when you are done! Anthony

Online Status	Offline
Date Last Visited	‎11-11-2020 02:23 AM

My Ideas

Latest Contributions by anthonysanchez

Re: Very slow performance on adding global ID

Re: SDE Spatial Views and Spatial Indexes

Re: Performance issues arcsde 10.1 on ST_GEOMETRY selects

Re: Changing a version's parent

Re: Changing a version's parent

Re: Nested Table Joins Work-around

Re: Create new point in feature class with st_geometry based on latitude and longitud

Re: ArcSDE User(s) Auditing in Oracle

Re: PL/SQL: ORA-21700 object does not exist. . . Oracle10g to SDE 10/Oracle11G

Re: PL/SQL: ORA-21700 object does not exist. . . Oracle10g to SDE 10/Oracle11G

Re: Error while posting child version to default "Out of server memory"

Re: Unable to push SDE edits from the ADD/DELETE tables to the base database

Re: Issues with spatial index and featuer display problem.

Re: How to organize data in SDE (feature datasets or not)

Re: How to perform an Oracle trace when ArcSOC.exe-generated sessions are shared serv