On this page:

Your Rating:
Results:
PatheticBadOKGoodOutstanding!
18 rates
To monitor Oracle with Database Visibility, you must be running Oracle 10g or newer. 

If you are configuring a collector for Oracle RAC, you only need to configure one collector for the entire cluster. You can choose any node in the cluster to connect to, and the entire cluster will automatically be detected.

Connection Details

FieldDescription
Database TypeThe database type that you want to monitor.
Database AgentThe Database Agent that manages the collector.
NameThe name you want to identify the collector by.
Hostname or IP AddressThe hostname or IP address of the machine that your database is running on.
Listener PortThe TCP/IP address of the port on which your database communicates with the Database Agent
Custom JDBC Connection StringThe JDBC connection string generated by the database agent, for example, jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS=(PROTOCOL=. You can also specify a custom connection string, which is useful for setting custom authentication options.
Use Service NameSelect if the field that follows is the service name.
SID or SERVICE_NAMEThe SID or service name of the Oracle instance you want to monitor.
Connect as a sysdbaClick if you want to connect to the database as a sysdba user and enable password files. Running the collector with a sysdba account allows the collector to monitor an Oracle instance that is on standby.
UsernameThe name of the user who is connecting to and monitoring the database through the Database Agent. The user should have the permissions described in User Permissions for Oracle.
PasswordThe password of the user who is connecting to and monitoring the database through the Database Agent.
Sub-Collectors

Click to monitor multiple database instances in a consolidated view, and aggregate metrics of multiple databases. To monitor a custom cluster, you can add additional hostname or IP address, and port details for each sub-collector. You can add up to a total of 29 sub-collectors. Thereby, 30 databases can be monitored in a custom cluster. In addition to the licenses consumed by the main collector, each sub-collector consumes one or more licenses, depending on the database type.

Note

  • All connection parameters other than the hostname or IP address, and port details of the sub-collector are the same as the main collector. If you want to specify different parameters for the sub–collectors, while creating or editing the collector configuration, you can do that only via the Create Collector API.

  • You cannot convert a custom cluster collector to a standalone collector. If you want to monitor a standalone database, delete the entire custom cluster collector and create a fresh standalone collector. However, note that deleting the custom cluster collector will delete all its historical data.
Connection PropertiesClick to add a new JDBC connection property or edit an existing property for relational databases.
CyberArkClick to enable CyberArk for database username and password. When CyberArk is enabled, information about Application, Safe, Folder, and Object is required to fetch the username and password for your database. To use CyberArk with Database Visibility, you must download the JavaPasswordSDK.jar file from the CyberArk web site and rename the file to cyberark-sdk-9.5.jar. Then, you must copy the JAR file to the lib directory of the database agent zip file. 
Exclude SchemasThe schemas that you want to exclude, separated by commas
Oracle Wallet

Click to enable Oracle Wallet.

  • Truststore Location: location of the e-wallet file on the DB Agent host
  • Truststore Type: type of Oracle Wallet. There are two truststore types:
    PKCS12 (default)
    SSO: enables auto-login. If you use SSO, you only need to provide the truststore location and truststore type. 
  • Truststore Password: password for Oracle Wallet

If the SSL_CLIENT_AUTHENTICATION parameter is set to true in listener.ora and sqlnet.ora, then click the Enable SSL Client Authentication box. 

  • Keystore Location: location of the e-wallet file on the DB Agent host
  • Keystore Type: type of Oracle Wallet
  • Keystore Password: password for Oracle Wallet
Logging EnabledClick to enable verbose mode logging, which logs all communications between the Controller and the Collector. Enable only during troubleshooting because logging consumes a lot of disk space. If you have enabled logging, you can click the logging icon in the Log column of the Collector Administration window to view the log file. The log files are located in the <db_agent_home>\agent directory and have the format <CollectorName>_out.log and <CollectorName>_err.log.

User Permissions for Oracle

For versions of Oracle 10g and later

The following permissions are required for the Oracle user:

  • CREATE SESSION
  • SELECT_CATALOG_ROLE

To create a user with these permissions, you can run the following SQL. In this SQL, change "password" to a safe and secure password, and change the tablespace names, "users" and "temp" to those available in your Oracle instance. 

CREATE USER DBMon_Agent_User IDENTIFIED BY password
default tablespace users
temporary tablespace temp;
 
GRANT CREATE SESSION, SELECT_CATALOG_ROLE TO DBMon_Agent_User;

where DBMon_Agent_User is the user name under which you run the Database Visibility Agent.

For versions of Oracle 12c and later with Multitenant Container Database Option enabled

The following permissions are required for the Oracle user:

  • CREATE SESSION
  • SELECT_CATALOG_ROLE

To create a user with these permissions, you can run the following SQL. In this SQL, change "password" to a safe and secure password, and change the tablespace names, "users" and "temp" to those available in your Oracle instance. 

CREATE USER C##DBMon_Agent_User IDENTIFIED BY password default tablespace users temporary tablespace temp CONTAINER=ALL;  
GRANT CREATE SESSION, SELECT_CATALOG_ROLE TO C##DBMon_Agent_User CONTAINER=ALL;
ALTER USER C##DBMon_Agent_User QUOTA 100M ON USERS;
alter user C##DBMON_AGENT_USER set container_data=all container=current;

Permissions Required for Oracle Explain Plans

To generate an execution plan for a specified query, paste the query text into the Explain another query boxy. You must provide a plan table in the AppDynamics monitoring user's schema. You can find a sample output table named PLAN_TABLE in the UTLXPLAN.SQL script. To update or view the plan table, you need INSERT and SELECT privileges. To explain a query, you need access privileges for the tables and views included in that query.

AppDynamics Database Visibility can generate explain plans within its SQL drill-down window. To enable this functionality, you must have a plan table accessible to the AppDynamics Database Visibility schema user. You can create this plan table with the following command from sqlplus when logged on as the AppDynamics Database Visibility user:

Windows:

@?\rdbms\admin\utlxplan.sql

Linux:

@?/rdbms/admin/utlxplan.sql

Permissions for individual views and tables

You can grant permission to individual views and tables even if the SELECT_CATALOG_ROLE permission is not available to your organization.

  1. Execute permissions on dbms_application_info.set_module.
  2. Select permissions on the following privileges:
    dba_data_files
    dba_ind_columns
    dba_indexes
    dba_objects
    dba_segments
    dba_sequences
    dba_synonyms
    dba_tab_columns
    dba_tables
    dba_users
    dba_views
    gv$instance
    v$archive_dest
    v$archive_dest_status

    v$database
    v$datafile
    v$event_name
    v$instance
    v$license
    v$log
    v$parameter
    v$process
    v$session
    v$sesstat
    v$session_wait
    v$sga
    v$sql
    v$sql_plan
    v$sqlstats
    v$sqltext
    v$statname
    v$sysmetric
    v$sysstat
    v$system_event

When you are granting access to v$ views, you must grant SELECT on the underlying objects, which are named using the v_$ format, e.g. GRANT SELECT on v_$archive_dest.

  • No labels