A closer inspection of Monitor debug logs helped us figure out what was going on. We found we had to connect using the SDE account. The three errors below occurred while we were trying to connect our Oracle instance with an account we created that we thought had the proper permissions based on reviewing the Monitor documentation.
- ” An Enterprise Geodatabase schema could not be found. Some metrics will not be returned.”
- Likely an error that we need to use the SDE account which is our enterprise geodatabase schema account
- “SELECT major || '.' || minor || '.' || bugfix "gdb_version" FROM VERSION WHERE EXISTS (SELECT * FROM all_tables WHERE table_name = 'VERSION') - ORA-00942: table or view does not exist”
- This query is likely looking to query the table, SDE.VERSION. Being the table in the query isn’t fully qualified as SDE.VERSION, the Oracle account used wouldn’t be able to query it as it is not the VERSION table owner.
- “SELECT SUM(a.value) "open_cursors" FROM v$sesstat a INNER JOIN v$statname b ON a.statistic# = b.statistic# AND a.con_id = b.con_id WHERE b.name = 'opened cursors current' - ORA-00942: table or view does not exist”
- This was because the Oracle account was not granted read access to the view used in the INNER JOIN, v$statname.
- Our SDE account could read the v$statname view in the database
So something from the Monitor documentation (https://doc.arcgis.com/en/monitor/2023.2/get-started/windows/register-oracle-databases.htm) that tripped us up:
- The Oracle user account that you use to register the database for monitoring must have the following read permissions to collect attribute and metric data:
- SDE system tables (if applicable)
- v$instance
- v$session
- v$sesstat
- v$sga
- v$sysmetric
- DUAL
*What we found is that we needed to be connected as SDE due to errors 1 and 2 above. That wasn’t clear in this step as we read it as any user account with proper privileges to those listed objects provided*
*With error 3 above, perhaps one more grant to add to this list is v$statname
