When issuing a CREATE MATERIALIZED VIEW statement for a different schema (as DBA), one might encounter the following error:

dba@KDB01:SQL> CREATE MATERIALIZED VIEW simon.simon_mv AS SELECT * FROM dual;
CREATE MATERIALIZED VIEW simon.simon_mv AS SELECT * FROM dual
                                                         *
ERROR at line 1:
ORA-01031: insufficient privileges

For our setup let’s assume we have two users:

• User SIMONDBA (has the DBA privilege and is used to setup the DB server)
• User SIMON (schema owner)

We want to use the SIMONDBA user to create the objects for the schema SIMON. This is a standard approach to seperate the deployment user from the actual schema owner. So let’s create these two users and grant the privileges (DBA for the deployment user, CONNECT and RESOURCE for the schema owner):

masterdba@KDB01:SQL> CREATE USER simondba IDENTIFIED BY tiger;

User created.

masterdba@KDB01:SQL> GRANT DBA TO simondba;

Grant succeeded.

masterdba@KDB01:SQL> CREATE USER simon IDENTIFIED BY tiger;

User created.

masterdba@KDB01:SQL> GRANT RESOURCE, CONNECT TO simon;

Grant succeeded.

masterdba@KDB01:SQL> ALTER USER simon QUOTA 100M ON users;

User altered.

masterdba@KDB01:SQL> GRANT CREATE MATERIALIZED VIEW TO simon;

Grant succeeded.

So far, so good. The user SIMONDBA has all the privileges that come with the DBA role and the user SIMON has a limited set of privileges due to the RESOURCE and CONNECT roles. In addition to those roles, we want to grant CREATE MATERIALIZED VIEW to our schema owner.

Now let’s see what happens when we try to issue the statement as the deployment user (SIMONDBA):

masterdba@KDB01:SQL> connect simondba@KDB01
Enter password:
Connected.
simondba@KDB01:SQL> CREATE MATERIALIZED VIEW simon.simon_mv AS SELECT * FROM dual;
CREATE MATERIALIZED VIEW simon.simon_mv AS SELECT * FROM dual
                                                         *
ERROR at line 1:
ORA-01031: insufficient privileges

Err, what? I have the DBA privileges, so the problem must be that SIMON does not have the correct privileges! So let’s try with the user SIMON:

simondba@KDB01:SQL> connect simon@KDB01
Enter password:
Connected.
simon@KDB01:SQL> CREATE MATERIALIZED VIEW simon_mv AS SELECT * FROM dual;

Materialized view created.

Now the confusion is complete. Why can I create the materialized view while connected as SIMON, but not create the same view when connected as SIMONDBA? The user SIMONDBA has higher privileges than the user SIMON, so that should not happen! It turns out that this is a feature (at least according to Oracle).

To solve the mystery, grant the CREATE TABLE privilege directly to SIMON:

masterdba@KDB01:SQL> GRANT CREATE TABLE TO simon;

Grant succeeded.

Now the CREATE MATERIALIZED VIEW statement works as expected:

simondba@KDB01:SQL> CREATE MATERIALIZED VIEW simon.simon_mv AS SELECT * FROM dual;

Materialized view created.

Now you might say: “But the RESOURCE role contains the CREATE TABLE privilege, why do I have to grant that privilege explicitly?”. That is correct and I have no answer for that…

The Oracle website has the answer:

Always set the TNS_ADMIN environment variable or registry to the location of the tnsnames.ora file (full directory path only, do not include the file name). This practice will ensure that you are using the appropriate tnsnames.ora for your application when running with Instant Client.

So, for UNIX and Linux systems set the variable TNS_ADMIN like so in your .profile or .bash_profile:
export TNS_ADMIN=/opt/oracle/instantclient_11_2/

On Windows systems, set the environment variables via the Advanced System properties:

• Open CMD, enter sysdm.cpl
• In the Advanced tab, select Environment Variables
• Under “System Variables”, click on New… and enter “TNS_ADMIN” as the name and the path where your TNSNAMES.ORA resides as your value.

Now, you can use your TNS names for your InstantClient, for example for SQL*Plus:
$ sqlplus simon@KDB01
For more information on SQL*Plus configuration, please refer to the Oracle documentation for SQL*Plus.

In this post, I will provide an example on how to move data via a Oracle Datapump and a database link. This post is based on the excellent entry in Oracle FAQ and basically comments all the steps mentioned in the article.

Preparation

Before we can export and import via a database link, we need to prepare the target database. First of all, on the new database, create a user with which you want to import a schema from another database. This step is optional if you want to move multiple schemas or use your DBA user to perform the import.

SQL> create user new_scott identified by tiger;
User created.

SQL> grant connect, resource to new_scott;
Grant succeeded.

SQL> grant read, write on directory MY_DMP_DIR to new_scott;
Grant succeeded.

SQL> grant create database link to new_scott;
Grant succeeded.

Now, create the database link which we will be using to perform the datapump import. If you are not sure about the syntax or how to create a database link, refer to the Oracle documentation for “CREATE DATABASE LINK”.

SQL> connect new_scott/tiger
Connected.

SQL> create database link OLD_DB connect to scott identified by tiger  using 'olddb.krenger.ch';
Database link created.

Import one schema

After creating the database link, you can then start the transfer using the standard “impdp” tools:
impdp new_scott/tiger directory=MY_DMP_DIR LOGFILE=dblink_transfer.log network_link=OLD_DB remap_schema=scott:new_scott

Whereas I specified the following options:

Import multiple schemas

To import multiple schemas, I like to work with a user that has the DBA privilege:
impdp simondba@kdb01 directory=ADMIN_DUMP_DIR LOGFILE=dblink_transfer.log network_link=OLD_DB schemas=simon,scott,hr


For more information on the datapump import tool and its options, please refer to the Oracle documentation. When importing data via a database link, the datapump import job is started on the target system (see DBA_DATAPUMP_JOBS)

All work is performed on the target system. The only reference to the source systems is via the database link.

It turns out you can connect to your server by adding “/console” to the end of the server name or IP. Thanks to Christian for his post on the subject!

So if you want to COMPUTE the statistics (which means to actually consider every row and not just estimate the statistics), use the following syntax:

EXECUTE DBMS_STATS.GATHER_SCHEMA_STATS(ownname => 'SIMON', estimate_percent => NULL);

However, you can also just specify the name of the schema:

EXECUTE DBMS_STATS.GATHER_SCHEMA_STATS(ownname => 'SIMON');

This will use the constant DBMS_STATS.AUTO_SAMPLE_SIZE to have Oracle determine the appropriate sample size for good statistics. Find all other information (available parameters, usage) in the Oracle documentation.

The Oracle Concepts guide states that the NUMBER datatype stores fixed and floating-point numbers. A column with the NUMBER datatype can be defined as follows:

column_name NUMBER (precision, scale)

The precision defines the total number of digits.
The scale defines the number of digits to the right of the decimal point.

If you specify a negative scale, Oracle Database rounds the actual data to the specified number of places to the left of the decimal point. For example, specifying (7,-2) means Oracle Database rounds to the nearest hundredths (source).

In the Oracle Database Security Guide, Oracle notes:

This feature enhances security for network connections because it restricts the external network hosts that a database user can connect to using the PL/SQL network utility packages such as UTL_TCP, UTL_SMTP, UTL_MAIL, UTL_HTTP, and UTL_INADDR. Otherwise, an intruder who gained access to the database could maliciously attack the network, because, by default, the PL/SQL utility packages are created with the EXECUTE privilege granted to PUBLIC users.

So how to fix ORA-31001?

So why did you get an ORA-31001 error? The reason for this error is that the ACL you try to modify does not yet exist. To create such an ACL, use the DBMS_NETWORK_ACL_ADMIN package and call the CREATE_ACL procedure:

BEGIN
  DBMS_NETWORK_ACL_ADMIN.CREATE_ACL (
    acl => 'myacl.xml',
    description => 'Network Access Control for SIMON',
    principal => 'SIMON',
    is_grant => TRUE,
    privilege => 'connect');
END;
/

You can then check what ACLs you have already defined for your database using the following query:
SELECT any_path FROM resource_view WHERE any_path like '/sys/acls/%.xml';
Since security is often a complicated matter, please make sure to read through the Oracle documentation before making any changes. You don’t want to have someone messing around with your database just because you mistakenly assigned a privilege to an unsecured schema owwner!

As always, I don’t guarantee anything, so please note:

Use this package at your own risk, I provide no support or guarantee that this software works as advertised.

This software is provided “AS IS” and any expressed or implied warranties, including, but not limited to, the implied warranties of merchantability and fitness for a particular purpose are disclaimed.

The following package includes the sources, the build log and all binary files for the Tanuki Java Service Wrapper 3.5.17 for Windows x64. To run the wrapper, the following three files from the archive are needed:

• bin/wrapper.exe
• lib/wrapper.dll
• lib/wrapper.jar

For more information on the wrapper, please refer to the documentation provided by Tanuki Software.

Download: wrapper-windows-x86-64-3.5.17.zip

There are a few reasons to use a response file:

• The installation is reproducible (the most important point)
• No X server is necessary when using a response file with the Oracle Universal Installer (OUI)
• The installation is easily scriptable
• Strictly enforcing the OFA or other policies on all hosts is much easier

So after extracting the archive with the software downloaded from the Oracle website, we usually find an example response file in the “response/” folder of the software package. So here is an example of a response file:
oracle.install.option=INSTALL_DB_SWONLY
UNIX_GROUP_NAME=oinstall
INVENTORY_LOCATION=/home/oracle/oraInventory
SELECTED_LANGUAGES=en
ORACLE_HOME=/u01/app/oracle/product/11.2.0/db_1
ORACLE_BASE=/u01/app/oracle
oracle.install.db.InstallEdition=EE
oracle.install.db.DBA_GROUP=dba
oracle.install.db.OPER_GROUP=dba
SECURITY_UPDATES_VIA_MYORACLESUPPORT=false
DECLINE_SECURITY_UPDATES=true

Note that this is a very minimalistic response file, where only the software is installed (no database is created). Please refer to the Oracle documentation and the response file that Oracle provides as part of their software delivery package.

To install the software, execute the “runInstaller” script with the parameters “-silent -reponseFile “. See this post for more information on the syntax.

In an earlier post, I showed how to install SQL*Plus on Debian and based on that tutorial, I wrote a little shell script to query a database (I called it check_oracle_dual.sh):

#!/bin/bash

ORACLE_INSTANTCLIENT_FOLDER=/opt/oracle/instantclient_11_2/
ORACLE_SQLPLUS_BINARY=sqlplus

ORACLE_USERNAME=
ORACLE_PASSWORD=
HOST=
INSTANCE=test01
ASSYSDBA=0

VERBOSE=0

usage() {
cat << EOF
usage: $0 -h  -u  -p  [-i ] [-s] [-v]

This script connects to the specified Oracle instance and executes a simple
statement. If that statement succeeds, the script returns 0.

OPTIONS:
   -h      Specify the host (required)
   -u      Oracle username (required)
   -p      Oracle password for the user (required)
   -i      SID of the instance (default: test01)
   -s      Force login AS SYSDBA
   -v      Verbose
EOF
}


while getopts "u:p:i:h:vs" OPTION; do
        case $OPTION in
                u)
                        ORACLE_USERNAME=$OPTARG
                        ;;
                p)
                        ORACLE_PASSWORD=$OPTARG
                        ;;
                i)
                        INSTANCE=$OPTARG
                        ;;
                v)
                        VERBOSE=1
                        ;;
                h)
                        HOST=$OPTARG
                        ;;
                s)
                        ASSYSDBA=1
                        ;;
                ?)
                        usage
                        exit 1
                        ;;
        esac
done

if [ -z "$ORACLE_USERNAME" ]; then
        echo "You must specify a username (-u)!"
        usage
        exit 1
fi


if [ -z "$ORACLE_PASSWORD" ]; then
        echo "You must specify a password (-p)!"
        usage
        exit 1
fi


if [ -z "$HOST" ]; then
        echo "You must specify a host (-h)!"
        usage
        exit 1
fi

if [[ "$ORACLE_USERNAME" == "sys" || "$ORACLE_USERNAME" == "SYS" ]]; then
        ASSYSDBA=1
fi

export LD_LIBRARY_PATH=$ORACLE_INSTANTCLIENT_FOLDER
export ORACLE_SID=$INSTANCE

CONNECT_STRING=$(echo $ORACLE_USERNAME/$ORACLE_PASSWORD@$HOST/$INSTANCE)

if [ $ASSYSDBA -eq 1 ]; then
        CONNECT_STRING="$CONNECT_STRING AS SYSDBA"
fi

SPOUT=$($ORACLE_INSTANTCLIENT_FOLDER/$ORACLE_SQLPLUS_BINARY -S "$CONNECT_STRING" << EOF
SET ECHO OFF
SET HEADING OFF
SELECT to_char(sysdate,'yyyy-mm-dd') FROM dual;
EOF
)

if [ $? -eq 0 ]; then
        TRIMMED=$(echo $SPOUT)
        echo "OK: $ORACLE_USERNAME@$INSTANCE, sysdate='$TRIMMED'"
        if [ $VERBOSE -eq 1 ]; then
                echo "| host=$HOST, username=$ORACLE_USERNAME, instance=$INSTANCE, as_sysdba=$ASSYSDBA"
        fi
        exit 0
else
        # Remove the \n from the output of SQL*Plus
        SPOUT=$(echo $SPOUT | tr '\n' ' ')
        echo "ERROR: sqlplus returned $? : $SPOUT"
        echo " | CONNECT_STRING=$CONNECT_STRING"
        exit 2
fi

Save this script (usually, you put it in the Nagios plugin folder, /usr/lib/nagios/plugins/ in my case) and use chmod to make it executable (chmod +x check_oracle_dual.sh).

Then, define a new command in your Nagios configuration file (more information on Nagios configuration here):

define command{
        command_name    check_oracle_dual
        command_line    $USER1$/check_oracle_dual.sh -v -h $HOSTADDRESS$ -u $ARG1$ -p $ARG2$ $ARG3$
}

After adding the command definition, add the service to an existing host like this (this queries the instance "dev01" on host "mydbhost" using the credentials "scott/tiger"):

define service {
    use                     generic-service
    host_name               mydbhost
    service_description     Oracle Instance Query
    check_command           check_oracle_dual!scott!tiger!-i dev01
}