Data Miner Administration


The scripts described in this document are available to manage the Oracle Data Miner Repository. These scripts are also integrated with Oracle SQL Developer  to allow users to manage the repository through SQL Developer as well.

You can also perform many Data Miner Administration tasks using the GUI. See the online help for Data Miner for details.

The scripts are only available via the SQL Developer installation kit.
They are stored at the  following location: C:\<SQLDeveloper Home>\sqldeveloper\dataminer\scripts
The scripts can be run either via SQL*Plus or SQL Developer Worksheet. In all cases the user must be logged in as SYS.
The instructions below assume that SQL*Plus or SQL Developer Worksheet are defaulting to the dataminer\scripts directory when locating script files. If you invoke SQL*Plus from the scripts directory, that will set the default search directory to the scripts directory. If you use SQL Worksheet, you need to go the SQL Developer preferences and change the database/worksheet setting for the default path to look for scripts.

Summary of Administration Tasks

To make it possible for users to use Data Miner, follow these steps:

  1. Install the Repository, as described in Installing the Oracle Data Miner Repository
  2. For each user, you must grant appropriate rights, as described in Granting a User the Rights to Access the Repository.
  3. You may wish to load the sample tables, as described in Loading and Dropping Sample Tables. The sample tables provide users with tables for experiments. The sample tables include the data used in the Oracle By Example tutorials for Data Miner.

To drop the Data Miner Repository, see Dropping the Oracle Data Miner Repository.

To upgrade Data Miner to a new release, follow these steps:

  1. First back up the Repository, as described in Backup and Restore Oracle Data Miner Repository.
  2. Then follow the directions in Migrating the Oracle Data Miner Repository.

Before you upgrade the database, you should back up the Repository, as described in Backup and Restore Oracle Data Miner Repository.

Installing the Oracle Data Miner Repository

installodmr.sql installs the Oracle Data Miner Repository; use it as follows:

set serveroutput on
@installodmr.sql <default_tablespace> <temp_tablespace>

Example: @installodmr.sql USER TEMP

The initial space requirement for the Data Miner Repository can range from 200MB to 700MB depending on the tablespace setting; however, the repository will grow as metadata is added. The table space must have auto specified for segment space management on database versions 11.2.0.4 or greater.

The script will take approximately 10 minutes to run for remote database installation and 2 minutes for local database installation.

See Loading and Dropping Sample Tables to load sample data.

Granting a User the Rights to Access the Repository

usergrants.sql user account grants the specified user account the rights required by Oracle Data Miner to use the Oracle Data Miner Repository. For example,

@usergrants.sql MININGACCT

dropusergrants.sql user account revokes all of these grants. For example,

@dropusergrants.sql MININGACCT

See Loading and Dropping Sample Tables to load sample data.

Loading and Dropping Sample Tables

These scripts load and remove the sample data used in the Oracle by Example (OBE) for Oracle Data Miner:

Dropping the Oracle Data Miner Repository

dropRepositoryAndUserObjects.sql drops the Repository and the user objects.  

@dropRepositoryAndUserObjects.sql <session_disconnect>

For example:

@dropRepositoryAndUserObjects.sql DR
 

To avoid session locks that can block the drop repository process, the drop repository script has an option to disconnect sessions connected that have the ODMRUSER role privilege.  The session_disconnect parameter allows the user to disconnect such sessions automatically or to just report on any instances of such sessions. If any sessions are detected but not automatically disconnected, the drop repository process is aborted.

The session_disconnect parameter has the following options:

R = report only, do not disconnect any sessions
D = disconnect only, displays disconnect  only
DR or RD = disconnect and report

All workflows and internal tables will be dropped. Models created by Oracle Data Miner will not be dropped. Tables created by the Create Table node will not be dropped.

See Loading and Dropping Sample Tables to drop sample data.

Migrating the Oracle Data Miner Repository

Migrating a repository requires an understanding of what version of Data Miner you are migrating from. Starting with SQL Developer(Data Miner) 4.0, it is necessary to select a specific migration script that suits the type of migration required. Below are the categories of migration and the appropriate script for each.

Migration Type
 Script Name
 Notes
Data Miner (any version) installed on DB 11.2.0.1,11.2.0.2, 11.2.0.3
migrateodmr.sql
Data Miner 3.2.2 or earlier installed on DB 11.2.0.4 and above, where the default ODMRSYS table space is not ASM based
 upgradeRepoWithNewTableSpace.sql ASM table space required as input parameter. This will be used to migrate the workflow data from XML Object Storage to XML Binary Storage
Data Miner 3.2.2 or earlier installed on 11.2.0.4 and above, where the default ODMRSYS table space is ASM based upgradeRepoFromORtoBinary.sql workflow data will be migrated from XML Object Storage to XML Binary Storage
Data Miner 4.0 installed on 11.2.0.4 and above.
 migratebinaryodmr.sql This is relevant for future releases where there is no xml conversion from Object Storage to Binary required.


The scripts will migrate the Data Miner Repository from an earlier version to the current version. All workflows created by users are preserved; only the repository software is updated.  Choose the correct script from the matrix above and review the example on how to invoke it below.


migratebinaryodmr.sql example

@migratebinaryodmr.sql <session_disconnect>

For example:

@migratebinaryodmr.sql DR
To avoid session locks that can block the migrate repository process, the migrate repository script has an option to disconnect sessions connected that have the ODMRUSER role privilege.  The session_disconnect parameter allows the user to disconnect such sessions automatically or to just report on any instances of such sessions. If any sessions are detected but not automatically disconnected, the drop repository process is aborted.

The session_disconnect parameter has the following options:

R = report only, do not disconnect any sessions
D = disconnect only, displays disconnect  only
DR or RD = disconnect and report

migrateodmr.sql example

@migrateodmr.sql <session_disconnect>

For example:

@migrateodmr.sql DR

upgradeRepoWithNewTableSpace.sql example


@upgradeRepoWithNewTableSpace.sql <ASMTablespace>  <session_disconnect>

For example:

@upgradeRepoWithNewTableSpace.sql MY_ASM_SPACE DR


upgradeRepoFromORtoBinary.sql.sql example
@ upgradeRepoFromORtoBinary.sql  <session_disconnect>

For example:

@upgradeRepoFromORtoBinary.sql  DR

Backup and Restore Oracle Data Miner Repository

Full Backup and Restore

It is important to backup the Data Miner Repository (ODMRSYS schema) prior to either upgrading the repository or performing a database upgrade. Having a backup allows an appropriate recovery operation to be conducted. Due to some database defects with the 11.2.0.1 thru 11.2.0.3 database releases which affect XMLDB OR tables, there are some restrictions on what backup strategies can be utilized specifically for the ODMRSYS schema. Please review the following details to insure that you take the appropriate steps to backup ODMRSYS and other appropriate user accounts prior to performing either a data base upgrade or a Data Miner Repository upgrade.

For DB Version 11.2.0.1 to 11.2.0.3

Performing a full database backup using RMAN will insure that there is a complete backup for ODMRSYS as well as all user account objects.. When restoring using this form of backup, the database is restored to is previous state. You can not perform a partial restore. Please review Oracle RMAN documentation on how to utilize RMAN

For DB Version 11.2.0.4 and above

Performing a ODMRSYS and user account backup using Data Pump will insure that there is a complete backup for ODMRSYS and associated user account objects. Only user accounts that are granted access to Data Miner and have created workflows are required to be part of the backup.  This approach allows for a restore that would only require reloading ODMRSYS and the selected user accounts. RMAN can still be used for a full database restore as well, with the limitation that the database must be completely restored to its prior state. Please review Oracle Data Pump documentation on how to utilize Data Pump.

Workflow Only Backup

The following script is provided to perform a "workflow only" backup; only workflow meta data is backed up but not the objects produced by the workflows. This is a simplified backup strategy that safeguards the workflow specifications. With this approach, a user who accidentally deleted their workflow, could make a request to restore that specific workflow from the backup. The user would still have to rerun the workflow to insure that all the underlying objects generated by the workflow are recreated in the user's account.

createxmlworkflowsbackup2.sql backs up all workflows in the Data Miner Repository (ODMRSYS schema); use it as follows:

set serveroutput on

@createxmlworkflowsbackup2.sql [<backup account>]

Example: @createxmlworkflowsbackup2.sql BACKUPACCT

The script creates a backup table ODMR$WORKFLOWS_BACKUP in the backup account (account must exist) and copies over all workflows from the Data Miner Repository to the backup table.  If no backup account is specified, the backup table will be created in the Data Miner Repository (ODMRSYS schema).  Notice that if the Data Miner Repository is dropped, the backup table will be dropped as well.  Therefore, all backup workflows will be lost.

Each time createxmlworkflowsbackup2.sql is run, a full set of workflows are added to the backup table. The backup script will maintain 30 distinct backups within the backup table. Older backups are automatically deleted. For example, if the backup was run each day, then a user has up to 30 days to request a restore of a workflow.  If you wish to preserve more than 30 backups then a simple script modification is all that is needed. Just change the DEFINE MAX_VERSIONS = 30 to a your desired number.

Workflow Only Restore

The following script is provided to restore workflows from the above backup.  There are four options that determine how workflows are restored.  In addition, a table or view can be used to specify what workflows are restored from the backup.

restorexmlworkflowfrombackup2.sql restore workflows from the backup table to the Data Miner Repository (ODMRSYS schema); use it as follows:

set serveroutput on

@restorexmlworkflowfrombackup2.sql [<option>] [<backup account>] [<workflow definition>]

Example: @restorexmlworkflowfrombackup2.sql DROP_AND_ADD BACKUPACCT

The <option> is an optional parameter that can have one of the following values:

ADD_ONLY - default option, restore workflows from the backup that do not exist in the Repository (create missing projects if necessary)

DROP_AND_ADD = drop all existing workflows and projects in the Repository, then restore all workflows from the backup (create missing projects if necessary)

OVERRIDE_ONLY = restore workflows from the backup that do exist in the Repository

OVERRIDE_AND_ADD - applies both the OVERRIDE_ONLY and ADD_ONLY options

The <backup account> is optional. If no backup account is specified, workflows will be restored from the backup table in the Repository.  An exception will be raised if the backup table does not exist in the Repository.  This parameter must be specified if the <workflow definition> is used.

The <workflow definition> is optional.  A table or view that specifies what workflows to restore from the backup.  This table or view must contain these four columns: USER_NAME, PROJECT_NAME, and WORKFLOW_NAME, VERSION which are used to qualify the workflows to restore. If the VERSION number is null, then the latest version number is used for the restore. When no workflow definition is provided, then the latest backup version is the default.

Selective Workflow Restore Example

Lets assume the user SCOTT had accidentally deleted all his workflows last week. You can use the ADD_ONLY to add his workflows back. You will have to query the backup table to determine which version of backups contain his missing workflows. In this case lets assume it is 12. Then the following script example, run as SYS will reload only those workflows.

Example: @restorexmlworkflowfrombackup2.sql ADD_ONLY BACKUPACCT BACKUPACCT.WORKFLOW_V

The WORKFLOW_V View defined below, will select all the workflows present for the user SCOTT from a specified version backup number. 

CREATE VIEW BACKUPACCT.WORKFLOW_V AS SELECT USER_NAME, PROJECT_NAME, WORKFLOW_NAME, VERSION FROM BACKUPACCT.ODMR$WORKFLOWS_BACKUP WHERE USER_NAME='SCOTT' AND VERSION = 12


Full Workflow Restore Example

Lets assume that there was some critical repository failure that requires a full reload of all workflows from the latest backup. You can use the DROP_AND_ADD option to insure that all the old workflows are dropped and all the workflows on the backup are reloaded. In this case, the backup table is located in another account separate from the ODMRSYS account.  The latest backup version will be used for the recovery, so no workflow definition parameter is required.

Example: @restorexmlworkflowfrombackup2.sql DROP_AND_ADD BACKUPACCT