Latest Contributions by MartinAmeskamp

Hi, a number of our customers use Microsoft SCOM for monitoring. Is anyone aware of specific ArcGIS management packs for SCOM or any other resources that help integrating ArcGIS (mainly Server) into SCOM? Thanks, Martin ... View more

Hi, we (and our customers) have been using versioned databases, mainly on Oracle, for a long time now, and we used to employ and recommend a pattern of analyze - compress - analyze, with a heavy emphasis on the benefits of a full compress. The pattern of version usage varies, some sites use work order versions that are created and edited by one person, and then checked and posted by another, so there's typically a backlog of versions (e.g. 100-200) around to prevent a full compress. Other sites use "personal" versions that are frequently reconciled, posted and reused, and then deleted on a Friday afternoon to achieve a "clean" database for the weekend. In many cases, SDE administrators check the number of states after compress, and if it is significantly greater than 1, they get rather nervous. Lately, replication has become more common, and the hidden replica versions make admins anxious because achieving a full compress gets increasingly difficult (there's that very helpful white paper "Compressing ArcSDE Geodatabases That Contain Replicas" that describes the situation and what to do about it). Now, I find that a full compress, followed by updating statistics, may be harmful rather than helpful: Oracle believes that the delta tables are empty, and while they are indeed empty, this is fine, but in the course of an editing day, they start to accumulate data, and while statistics don't reflect this, access to delta tables may well be suboptimal. A typical example is the SDE_STATE_ID index being used rather than the SDE_STATE_ID, OBJECTID one, even though both values are available for use. Yes, Oracle will detect bad execution plans eventually and realize that the tables aren't empty any more, but that may take some time. So, my recommendation would be to go one of two ways: If you want to achieve full compresses, make sure your statistics lie and reflect populated delta tables: Populated statistics for empty table are a lot less harmful than empty statistics for populated tables. The easiest way of doing this is to analyze delta tables in a populated phase and then lock statistics. The other way is to forget about full compress and to strive for a "stationary" database where there's always a reasonable number of versions around, and delta tables always have some data in them. Of course, the usual maintenance operations, such as soft reconcile scripts and most of the best practices of the white paper mentioned above still apply - you don't want "old versions" around that haven't been reconciled for a long time and prevent a lot of edits from being compressed. Any thoughts or experiences about this? Thanks a lot, Matin ... View more

Hi, I'm trying to create a 1-way replica into a FileGDB from an Oracle Enterprise SDE and keep hitting rather unspecific error messages. Here are some details: Client: ArcGIS Desktop 10.0 SP5 with QIP on WS 2008 R2 and ArcGIS Desktop 10.2.1 with Update 1 on Windows 8 64 bit. Database: ArcSDE 10.0 SP5 on Oracle 11.2.0.3 on WS 2008 R2, using direct connect. Database contents: 4 feature datasets with some geometric networks, a handful of relationship classes and some object tables, no class extensions. Almost all tables and feature classes are empty, except for one feature class that has around 4 million rows (building footprints, no network involved). I've tried to make sure that all feature classes and tables are versioned, all have global IDs, database connection for replication is database owner. I'm using python script that basically creates an empty FileGDB and then creates a replica using CreateReplica_management. The script is OK since I've managed to create one or two replicas with it. Now, the test environment is a bit of a moving target, and frequently, I run into errors. Typical problems include class extensions, non-versioned feature classes, unexpected locks, missing global IDs, geometry problems in network data. I basically know how to locate and fix those issues, my problem is that I don't know which one it is this time, and checking everything is a lot of work. A typical error message looks like this: arcgisscripting.ExecuteError: ERROR 000582: Error occurred during execution. Failed to execute (CreateReplica). It's a bit too early for a ReplicaLog.dat, there is no Build.txt, documentation for 582 basically says: "An error occurred". I had hoped that 10.2.1 would provide  a bit more information on replication problems than 10.0, but if it does, I haven't come across the information. Does anyone have suggestions on where to look for details of what happened? Thanks, Martin ... View more