POST
|
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
... View more
03-07-2013
04:31 AM
|
0
|
0
|
315
|
POST
|
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
... View more
01-17-2013
05:51 PM
|
0
|
4
|
2334
|
POST
|
Hi Kim, That's exactly the workflow that's causing Dori's ghost conflict problem to begin with. Anthony
... View more
09-26-2012
08:19 PM
|
0
|
0
|
575
|
POST
|
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;
... View more
09-26-2012
07:45 AM
|
0
|
0
|
575
|
POST
|
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
... View more
09-18-2012
05:02 AM
|
0
|
0
|
469
|
POST
|
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
... View more
09-10-2012
04:18 AM
|
0
|
0
|
480
|
POST
|
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
... View more
05-03-2012
04:45 AM
|
0
|
0
|
412
|
POST
|
Oops. I meant multi versioned view which is just an oracle view. Anthony
... View more
04-20-2012
08:48 AM
|
0
|
0
|
1438
|
POST
|
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
... View more
04-20-2012
05:23 AM
|
0
|
0
|
1438
|
POST
|
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
... View more
04-12-2012
11:49 AM
|
0
|
0
|
205
|
POST
|
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
... View more
01-25-2012
10:30 AM
|
0
|
0
|
176
|
POST
|
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
... View more
12-22-2011
04:00 AM
|
0
|
0
|
993
|
POST
|
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
... View more
11-04-2011
05:39 AM
|
0
|
0
|
461
|
POST
|
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
... View more
09-16-2011
10:57 AM
|
0
|
0
|
312
|
Online Status |
Offline
|
Date Last Visited |
11-11-2020
02:23 AM
|