Transcript
Welcome to the Oracle Training Module for Oracle Permissions Heirs. In today's module, we will discuss some common Oracle job failures relating to improper permissions and how to address them. In simplest terms, Oracle permissions control what users can do within an Oracle database. When a call is made from Commvault to the Oracle client and account specified by the user, is leveraged to make the call. If the user has the expected permissions, then Oracle will allow the operation to continue. However, if there are insufficient permissions for the user, the job activity will result in a failure. Let's review a common error seen in Commvault regarding incorrect permissions. When starting any Oracle job, the following error may be returned during the initial job phase. Examining the error, the database being called is returning an unknown status. As implied by the name, an unknown database state occurs when Oracle's database management system is unable to determine the state of the database. The suggestion from Commvault is to have the database administrator check the database status manually and to check the Oracle Connect string, which is a user-provided string that works to authenticate the account in Oracle. At this point, the check readiness should be run against the Oracle client. Let's review this process. Let's run through a check readiness demo in Commvault Command Center. Begin by expanding the selection menu using the ellipses in the upper left-hand corner. Then navigate down to Protect followed by Databases. In the Database Information window, select the Instances tab. Find the instance to test, then hit the ellipses button on the far right and select Check Readiness. The check readiness will run confirming both the general client network connectivity and the Commvault services, in this case the Oracle agent. The check has returned successfully in this instance. For a client with no connectivity, the check will fail. Please note in this instance the check will report that no communication is possible and that you should check the client's connectivity and try again. Running a check readiness against the same Oracle client from the initial error has returned this output. While each line contains information that can be used to troubleshoot this, notice the initial failure to read or write to the Oracle database, coupled with the error citing that the user for this job is invalid. At this point, the Oracle Database Administrator should be engaged to confirm the permissions for the account being used, but first let's determine what account that is. In Command Center, when reviewing either an Oracle database or instance, the default display shows the Overview tab. In the General Information box, the Oracle account being used for the client will be displayed here. In this case, the user account for this database is Oracle. This information will now be used for further investigation into the Oracle user permissions. In this example, an Oracle database hosted on a Unix server will be used. Please note the commands will be different for Oracle hosted on Windows. On the host machine, the following command can be run by the DBA to determine the Oracle username running the instance service. Reviewing each part of the command, PS displays information about active processes on the system. The E and F switches show every process and provide the full listing of the process information. GREP searches for specific patterns within the input received and PMON is the pattern GREP is searching for the process monitor results. This command will return a result like this showing the user and the associated database name for the Oracle instance. To attempt a database connection via the account presented by the previous command, log in to the account presented via the command. The SU command switches uses from root to a new session for the designated account. The Oracle account is used based on the previously collected information. Once logged in as Oracle, run the RMAN command to log in to the local database. The RMAN command calls the Oracle Recovery Manager. The target and forward slash indicate the connection is to a local database. The result shows that the account Oracle was successful in connecting to the local database. If this process fails, the database administrator will need to set the appropriate permissions. After logging in as the database user, general information about the database can be collected via the following command. This command shows environmental variables for the machine being used. Here is a truncated output. Note in this output there are numerous pieces of information about the database such as the Oracle system identifier and base directory, the Oracle home directory and hostname, and the user for the database. If any of this information does not match the entries in Command Center, it will need to be appended in order to match. Commvault provides a full list of account permissions for all supported versions of Oracle on the documentation website at documentation.comvault.com. Once there, search for the term configuring user accounts for Oracle applications and select the top page. This page will review the account permissions as well as additional caveats that may be related to the installed Oracle version being used. Thank you for your time and attention on this module and have a wonderful rest of your day.
