Latest Contributions by VinceAngelo

You should not EVER use the SYS user to connect from ArcGIS clients.  It is a very dangerous practice, and Oracle tries to prevent it by making SYS-privilege users add the WITH SYSDBA modifier in the connection (which ArcGIS doesn't provide). If you follow best practice by creating one or more tablespaces to contain your data, and one or more users to own the data (with appropriate default tablespaces), and one or more roles to manage access to your tables, and additional users to access the data (through the roles), then you won't get tangled in knots trying to use administrative accounts for non-administrative purposes. - V ... View more

I've been working with PostgreSQL since 8.1, but not in a production environment, so I'll pass on most of your questions.  PostgreSQL is a "grown up" database, not a toy. My pet peeve is with the frequency of the release schedule -- if you upgrade with every minor release, you'll spend your days doing nothing but upgrades.  This update frequency also manifests in a compatibility issue with ArcGIS -- Esri supports three major revs (e.g. 9.1, 9.2, and 9.3 at ArcGIS 10.3.1), but PG has moved on to 9.5.  For the most part, it doesn't matter that Esri ships a 9.3.5 client when the production release is at 9.3.11, but it's always wise to test for compatibility, since there was an incident way back at 8.3.something where the underlying structure of date types changed in a minor rev, making all older binaries obsolete.  Following industry-standard best practices (dev, test, and prod environments) should be enough to keep you safe. PostGIS is not required, but it's not incompatible with ArcGIS.  I think you can use any PostGIS with Query Layers, but if you plan to enable a geodatabase then you should use the supported PostGIS implementation for the release of PostgreSQL in use.  As with other native geometry implementations, it's probably advisable to review client support for SDE.ST_GEOMETRY, and if that isn't an issue, evaluate performance using both storage options with your own data before making a final decision on which geometry storage to use. - V ... View more

The SDO_GEOMETRY type is provided by Locator, which is part of the Intermedia bundle, and bundled into the base cost of Oracle. Esri does not use any Spatial-restricted functions anywhere in the utilization of the SDO_GEOMETRY type (unless users explicity add one in a WHERE clause or a view). - V ... View more

What exact version(s) of ArcGIS Desktop and Server are you using? What user is the ArcGIS Server service running as? Is your ArcGIS Server host a member of the domain?  Is the database host a member of the domain? - V ... View more

You need to specify the lineage of ST_Geometry on Oracle, because there are two of them -- MDSYS.ST_GEOMETRY and SDE.ST_GEOMETRY.  ArcGIS only supports MDSYS.SDO_GEOMETRY and SDE.ST_GEOMETRY native types (The MDSYS.ST_GEOMETRY is a wrapper around SDO_GEOMETRY). The biggest difference is that SDO_GEOMETRY does not use a compression algorithm on the vertex stream the way SDE.ST_GEOMETRY does, so lines and polygons stored in SDE.ST_GEOMETRY will be smaller (with a corresponding throughput performance gain).  I once had a customer complain that SDO_GEOMETRY was twice as slow as the Esri type in a full table scan query,  and when I had him measure the storage of the tables, the SDO layer used twice the space. If you have 3rd-party applications reading the database, and they don't support SDE.ST_GEOMETRY, then your decision tree is simple.  If it's just a storage decision, then I'd encourage you to benchmark performance with your data using Python (for the millisecond resolution timer). Please do not tag me in questions.  I review most new GeoNet content, and answer questions based on my ability to help, as my schedule permits. If I start getting tagged on a regular basis, I'll need to start avoiding questions where I've been tagged, just to discourage the practice. - V ... View more

That isn't uncommon, which is why I specified "once warm" in my timing reporting.  Cold databases, and cold ArcGIS clients, for that matter, rarely operate with blinding speed. Once the client and server have all the DLLs needed for the connection pipeline, then they tend to behave more consistently (the standard deviation drops significantly without the first sample of 10). - V ... View more

Try: sdeping -i sde:oracle11g -u [username] -p [password]@[tnsname] -v If that doesn't work, I recommend using Instant Client. - V ... View more

What client are you using?  I've not had an issue with this syntax while using either a full Client or an Instant Client. - V ... View more

With Direct Connect to Oracle, I find it easiest to use the Instant Client connection syntax,  which would include slashes sdeping -i sde:oracle11g😕[dbserver]:[port]/[servicename] -u [username] -p [password] -v                          -                 - You can also use environment variables (SDEINSTANCE, SDEUSER, SDEPASSWORD) to avoid needing to place the parameters on the command-line, and wiithout a switch or environment variable, the toolkit utilities will no-echo prompt for the password. Note that se_toolkit utilities were deprecated at 10.2.x because the 'C' API was deprecated.  They seem to continue to work against 10.3.x but the combination of unsupported and deprecated does make discovering them at this point a mixed blessing. - V ... View more

The layout of the LOGFILES / LOGFILE_DATA tables are documented​, and have been with every release since SDE 3.0. ArcPy doesn't require SYSDBA access to create a logfiles, just the normal user access with CREATE TABLE before it's revoked (I'm not aware of a tool, but scripting it probably wouldn't be more than 10-15 lines of code).  Even that isn't necessary if you choose to use session logfiles. - V ... View more

The sdeping utility of se_toolkit​ has a millisecond precision timer (displayed with the -v option). Oracle is a bit slower than SQL Server to establish a connection: D:\Temp>sdeping -i sde:oracle11g:/#redacted#/#redacted# -u #redacted# -p ****** -v ArcSDE 10.2 Connection Test Utility      Wed Feb 17 11:10:51 2016 ------------------------------------------------------------------------          Server: (none)        Instance: sde:oracle11g:/#redacted#/#redacted#        Database: (none)        Username: #redacted#           RDBMS: Oracle         Version: 10.2.0     Description: 10.2.2 geodatabase(Oracle)         Release: 102001   Connect Delay: 655.00 ms The sdeping command was created from exercise 1 in the (now defunct) "Accessing SDE with 'C'" training class to evaluate connection performance issues at a client site where MapObjects connection was very slow.  Since it *only* does a connection, and doesn't perform the inventory operations of a Desktop connection, the timing is more comparable to a Server connection.  But now you have me thinking I can add a flag to do the gyrations that Desktop does, so the connection times could be compared... - V ... View more

The optimizer can choose not to trust indexes for any reason, including for being "too old".  Updating the statistics on tables not being regularly updated is still a necessary maintenance step. - V ... View more

You can also look at the table from Management Studio.  If the database reports the geometry column as an integer, then it's using SDEBINARY geometry storage. - V ... View more

Two million features is quite large, especially in a temporally sequenced table which is likely to be spatially fragmented.  Generally, the advice is to organize like data in a single table, but the exception is when the data won't ever be used together (especially when it just increases spatial fragmentation).  Not only would your application benefit from having the data split into tables, but the tables should probably be spatially sorted during the split process, to optimize spatial selection performance. - V ... View more