Skip Headers
Oracle® Clinical Installation Guide
Release 5.1
E53553-02
Go to Documentation Home
Home		 Go to Book List
Book List		 Go to Table of Contents
Contents		 Go to Index
Index		 Go to Feedback page
Contact Us
Go to previous page
Previous		 Go to next page
Next
PDF · Mobi · ePub

11 Upgrading an Oracle Clinical Installation to Release 5.1

This chapter describes the recommended approach to upgrading an existing Oracle Clinical installation to Release 5.1. Supported upgrade paths include:

Be sure you are using the latest documentation:

Review Chapter 1, "Preparing to Install Oracle Clinical" for system requirements and planning information.

This chapter includes:

Oracle Database 12.1.0.1  includes many new features including multitenancy, which allows you to create one or more pluggable databases (PDBs) contained in a single root or container database (CDB). You can install Oracle Clinical on either a pluggable database or a non-CDB database (as in 11g). For more information on multitenancy, see http://docs.oracle.com/database/121/CNCPT/cdbovrvw.htm.

For information about upgrading and migrating your existing database, see "Upgrading to Oracle Database 12c (12.1.0.2)" at http://www.oracle.com/technetwork/database/upgrade/upgrading-oracle-database-wp-12c-1896123.pdf.

For more information about new features see Oracle White Paper Plug into the Cloud with Oracle Database 12c at http://www.oracle.com/technetwork/database/plug-into-cloud-wp-12c-1896100.pdf and, for more details, the Oracle® Database New Features Guide 12c Release 1 (12.1) at http://docs.oracle.com/database/121/NEWFT/toc.htm.

11.1 Changes Introduced in Oracle Clinical 5.0

Release 5.0 included the following important changes that affect the way you set up Oracle Clinical:

11.1.1 Changes to Parameterized Submission (PSUB)

PSUB was re-architected in Release 5.0 to support an Oracle Real Application Cluster (RAC) installation across multiple nodes. Instead of using dbms_pipes, which can be used only within a single database instance, to communicate between the user session and the PSUB service, Release 5.0 and later use Oracle Advanced Queuing.

Changes include:

  • the RXCPROD account formerly responsible for starting and stopping PSUB (RXCPSDPS) has been eliminated. The PSUB start and stop privilege is now held by the opapps account, which continues to be responsible for the installation. If your company has previously allocated these responsibilities to separate individuals, be aware that your PSUB administrator now requires access to the opapps account.

  • The opapps account will not only execute the RXCPSDPS (PSUB) process, but all of the batch jobs launched by that process, such as batch validation and batch data load, using the ocpsub proxy database account. These jobs will no longer be executed by individual users' operating system accounts.

  • The connection information for the proxy account is securely stored in Oracle Wallet, with information you provide when you run the Oracle Clinical Installer. Oracle Wallet replaces the Secure Shell which replaced Remote Shell (rsh, remsh, and rlogin) used in earlier Oracle Clinical releases.

  • Users who need to submit PSUB jobs no longer need:

    • a user account beginning with OPS$

    • an individual operating system account

    Instead, a new property identifies users as PSUB users and grants them access to the new ocpsub proxy database account account. To grant this access to existing user accounts, run the migration script oclupg50migrateusers.sql provided with Oracle Clinical 5.1 and described in the Oracle Clinical Administrator's Guide.

  • PSUB log files are no longer stored on the server but on the database. You need to create a directory to temporarily hold PSUB output files on the PSUB server, but you no longer need to set up a directory for each user. The system does this automatically the first time a user runs a PSUB job on the database.

  • Some PSUB jobs require input files and/or produce special output files that are still stored on the file server, not in the database. You can choose to have user-specific directories to store these or to store them all together. If you choose to have user-specific directories, you must create them yourself.

  • The local reference codelist OCL_STATE has new settings to configure the changed PSUB implementation.

See Chapter 8, "Setting Up the Parameterized Submission Process" for more information.

11.1.2 Changes in SAS Data Extract Implementation

SAS Data Extract jobs are run by PSUB, so the PSUB changes in 5.0 and later affect SAS as well. Users no longer have individual operating system accounts and are no longer members of the oclsascr user's group.

  • Like other PSUB users, SAS Data Extract users no longer need individual operating system accounts, and therefore these accounts do not need to belong to the oclsascr user group. Only opapps needs to belong to oclsascr.

  • Since Oracle Clinical no longer uses individual operating system accounts to run SAS jobs, the authentication method must change. You can set up SAS authentication two different ways:

    • Using Oracle Wallet

    • Using SAS proxy encryption file

    New OCL_STATE settings also support these options; see Section 9.1.4, "Set Up SAS User Authentication and Set OCL_STATE Reference Codelist Values" for more information.

  • Four Data Extract processes require input and output files in addition to the usual output files (.log and .out) that in Oracle Clinical 5.0 are stored in the database. Three of the four processes are very similar in structure in that they each require the execution of two jobs. The first job creates files that are executed by SAS in the second job. New settings in the OCL_STATE local reference codelist allow you to execute these two jobs separately. This can be useful when SAS resides on a separate server from the PSUB server; see Chapter 9, "  Setting Up SAS."

    Note:

    SAS files generated in earlier releases of Oracle Clinical cannot be re-used in Release 5.0 because they contain a database connection string that is no longer usable. You can regenerate all your SAS view files to include the correct database connection string using the existing gen_views utility; see the Oracle Clinical Administrator's Guide.

11.1.3 Changes to File and Image Viewing

Release 5.0 included a few changes related to file viewing:

  • You no longer need to specify or set up SFTP or FTP as the method of transferring PSUB log and output files because they are read directly from the database. You no longer need to edit formsweb.cfg for this purpose.

  • HTTP(S) set up is done during installation of Oracle HTTP Server; see Section 5.6, "Enable SSL Between a Browser and Oracle HTTP Server".

  • The location for the crfimages folder used to display images during RDC Onsite data entry has changed. Additional information is available in the Oracle Clinical Administrator's Guide.

    Pre-5.0 Location: ORACLE_AS10gR3_HOME\j2ee\rdc\applications\olsardc\rdconsite\de

    Location in 5.0 and Later: OPA_HOME\html\rdc\dcif_images

    For example: opapps51\html\rdc\dcif_images

  • The setup required for viewing PSUB log and output files has changed; see Section 11.1.1, "Changes to Parameterized Submission (PSUB)." In addition, see the Oracle Clinical Administrator's Guide.

Note:

The location and handling of Reports Server log and output files has not changed. They are still located on the on Report Server Windows machine and are accessed using UNC; see Section 7.5, "Set Up the Reports Server for Access and File Viewing". In addition, see the Oracle Clinical Administrator's Guide.

11.1.4 Reset Application Account Passwords Proactively

Beginning with Oracle Database 11gR2, the DEFAULT profile, which applies to all users by default, including internal users/schemas, enforces password requirements including an expiration period, which is 180 days by default. You must proactively change the passwords before they expire or parts of the system may stop working.

For a list of internal accounts, see Section 4.2.2, "Gather Required Information."

For more information see the Oracle Clinical Administrator's Guide, Chapter 1, and http://docs.oracle.com/cd/E16655_01/network.121/e17607/authentication.htm#CHDCGJED">> in the Oracle® Database Security Guide.

11.2 Changes Introduced in Oracle Clinical and RDC 5.1

For a description of all enhancements in Release 5.1, see the release notes or the "What's New" section of Oracle Clinical Getting Started. The enhancements do not require changes to the installation process, but new administrative tasks are required:

11.2.1 Grant Users Access to New and Changed Oracle Clinical Menu Items

Several new menu items support audited study data deletion and partial source data verification. Grant access to them to the appropriate users following instructions in the chapter on menu-based security in the Oracle Clinical Administrator's Guide. Menu items are listed below with recommended access.

11.2.1.1 Audited Study Data Deletion Menu Items

  • Delete Study Information with Audit under Conduct, Security. Oracle recommends giving access to the same users who have access to the pre-5.1 menu item Delete Study Information. This job always audits data deletion.

  • Delete Study Information under Conduct, Security. This menu item has the same name as before, but Oracle recommends that access to it should be changed to only a few users. It now has a parameter allowing users to audit study data deletion or not. With the introduction of the feature allowing audit, Oracle recommends that auditing should be the norm and only a few users allowed to delete data without an audit.

11.2.1.2 Partial Source Data Verification Menu Items

Users with access to any of these jobs must have an account configured to run batch jobs: granted the OCPSUB proxy database account (see Section 11.1.1, "Changes to Parameterized Submission (PSUB).").

You may simply grant access to a user who already has privileges to execute a job like Batch Validation. However, to take a more task-specific approach:

  • Publish SDV Plans for All Sites under Conduct, Security. Grant access to users who have responsibility for initiating a Source Data Verification plan for a study.

  • Load Patient SDV Attributes under Design, Patient Positions, Patients. Grant access to users who define and initiate the source data verification plan for a study or to users who otherwise work in the Maintain Patient Positions window.

  • Execute Pending Patient Updates under Conduct, Security. Same as Load Patient SDV Attributes.

  • Schedule Pending Patient Updates Job under Admin, DE Admin. Grant access to the system administrator.

    Note:

    For documentation of the Partial Source Data Verification feature, start with the section "Setting Up Partial Source Data Verification" in Oracle Clinical Creating a Study.

11.2.2 Grant RDC Onsite Users New Verify Privileges

There are new privileges in RDC Onsite required to view and update Source Data Verification Plans. See the Oracle Clinical Remote Data Capture Onsite Administrator's Guide for information.

In addition, a new privilege, BROWSE_VERIFY, is now required to view CRF verification status and history, even if you are not using partial source data verification. Before release 5.1, all users with BROWSE or UPDATE privileges could view this information. For studies using partial source data verification, users with the BROWSE_VERIFY privilege will also be able to see the verification requirement for individual CRFs.

Users with the VERIFY privilege can still see this information and update the verification status of a CRF.

11.2.3 Set Up Custom Review Types and Assign Custom Review Privileges

Create custom review types and their corresponding privileges in the CUSTOM REVIEW TYPE installation codelist in Oracle Clinical. See the Oracle Clinical Remote Data Capture Onsite Administrator's Guide for more information about this feature.

11.3 Database Server

11.3.1 Install Oracle Database Server 12.1.0.1

You must install Oracle Database Server Oracle Database 12c Release 1 (12.1.0.1). You cannot upgrade your existing Oracle Database installation.

11.3.1.1 Installing the Oracle Database Server on UNIX

For information on using a RAC installation across multiple databases, see Section 2.1, "Installing Oracle Clinical on a Real Applications Cluster (RAC) Database Configuration (Optional)."

To install on UNIX, follow these instructions:

  1. Section 2.2, "Perform Prerequisite Tasks for Installing Oracle Database"

  2. Section 2.3, "Install Oracle Database"

  3. Section 2.4, "Set Permissions"

11.3.1.2 Installing the Oracle Database Server on Windows

To install on Windows, follow these instructions:

  1. Section 3.1, "Set Up the opapps User Account and the oclsascr User Group"

  2. Section 3.2, "Set Up Local Policy Security Options"

  3. Section 3.3, "Install Oracle Database"

    Note:

    If you are upgrading a the Oracle Database Server on Windows, be sure there is only one Oracle Home, and that the path points to the 12.1.0.1 home. Otherwise, you will not be able to start PSUB.

11.3.2 Install the Oracle Clinical Database Server

To upgrade the Oracle Clinical Database Server component, you log in to the server, run Installer from the download location, and select OC Server. Follow instructions for your operating system:

Then follow instructions in Section 11.4.4, "Set Initialization Parameters".

11.3.2.1 Installing the Oracle Clinical 5.1 Database Server on UNIX

This section describes the tasks that you complete to install Oracle Clinical 5.1 on UNIX database servers.

Note:

See "Using the Silent Installer" for instructions for running the Installer as a file with pre-entered parameter values.

  1. Grant write access for the opapps account to the ORACLE_HOME directory and its contents.

  2. Follow instructions in Section 2.5, "Install the Oracle Clinical Database Server."

    Note:

    When you run the Installer, choose the Upgrade option.

  3. Follow instructions in Section 2.6, "Perform Post-installation Tasks."

11.3.2.2 Installing the Oracle Clinical 5.1 Database Server on Windows

To install Oracle Clinical 5.1 on a Windows Database Server, follow instructions in:

  1. Section 3.4, "Install the Oracle Clinical Database Server."

  2. Section 3.5, "Perform Post-installation Tasks."

11.3.3 Preserving Your Database Customizations

Since the 12.1.0.1 database server code will be in a different directory from the 11g code, you do not have to copy customized files to save your changes. When you have finished your database installation, copy the customized portions of the files into the 5.1 version of the file.

All customizable scripts are located in the same directories in Release 5.1 as in Release 4.6.2. For information about customizing them, see the Oracle Clinical Administrator's Guide.

Table 11-1 Customizable Database Scripts and Packages

File Name Location Purpose of Customization Changed?

ocl_add_user.sql

$RXC_TOOLS

Create new user accounts.

Changed in 5.0 and 5.1

ocstats.sql

$RXC_INSTALL

Gather statistics; see "Run Scripts to Gather Schema Statistics for the Oracle Database Optimizer".

New in 5.0, unchanged in 5.1

opastats.sql

$RXC_INSTALL

Gather statistics; see "Run Scripts to Gather Schema Statistics for the Oracle Database Optimizer".

New in 5.0, unchanged in 5.1

rxcptdxvb.sql

$RXC_INSTALL

Customize data extract views.

Not changed

pop_vb_static_views.sql

$RXC_INSTALL

Customize data extract views.

Not changed

ocl_client_pb.sql

$RXC_INSTALL

Customize to add PLSQL code to be invoked from various parts of the application.

Not changed

rxasravw.sql/rxasravw_custom.sql

$RXC_INSTALL

Customize Study Design replication.

Not changed

rdcpb_client.sql

$RXC_INSTALL

Customize flex fields for DCI Forms.

Not changed

OCL_UTILS

$RXC_INSTALL

See Oracle Clinical Creating a Study for information on customizing this package for making patients eligible for a PSDV plan and the Oracle Clinical Remote Data Capture Onsite Administrator's Guide for other uses.

Changed in 5.1

11.4 Database

11.4.1 Stop Processes

Before you start to upgrade your system to Oracle Clinical 5.1, complete the preliminary tasks described in this section:

11.4.1.1 Stop PSUB

Stop PSUB on the database.

To stop PSUB on UNIX:

The preferred way to stop the PSUB service is with a utility, from the opapps account, after setting the correct environment. The TNS_ADMIN environment variable must be set to the location of the sqlnet.ora file. The Installer puts sqlnet.ora in the opapps Home directory; see "Setting TNS_ADMIN on UNIX" in the Oracle Clinical Administrator's Guide.

If you are upgrading from a release lower than 5.0 

  1. Log in to the operating system of the local computer with the rxcprod account.

  2. Set the environment variables for the database and code environment.

  3. Enter the following command:

    stop_psub database_name code_environment rxc_password

If you are upgrading from Release 5.0.x Use the echo command to check the setting, then stop PSUB.

  1. Log in to the operating system of the local computer in the opapps account.

  2. Set the environment variables for the database and code environment.

  3. Enter the following command:

    echo $TNS_ADMIN
setenv TNS_ADMIN $HOME
stop_psub database_name code_environment Wallet_alias

To stop PSUB on Windows:

  1. Navigate to the Services control panel.

  2. Highlight the PSUB service.

  3. Click Stop.

11.4.1.2 Prevent Access to Oracle Clinical Databases

You must ensure that no data entry is performed, and no jobs that update data (such as batch validation) run during the upgrade process.

To prevent users from accessing the data, place the database in restricted mode. Provide restricted session access to the following accounts:

  • OPA

  • RXC

  • RXA_DES

  • RXC_SERVLETST

  • SYSTEM

After you complete the upgrade, remove the restricted access from the databases and user accounts.

11.4.1.3 Stop Replication (If Applicable)

If you have a distributed environment in which you replicate data and metadata among multiple databases using one of Oracle Clinical's replication features, stop all replication before continuing the upgrade.

This section includes:

Tip:

You must upgrade all databases in your Oracle Clinical installation to Oracle Clinical 5.1 before setting up, or resuming, replication in any of them.
11.4.1.3.1 Prepare All Replication Environments

When upgrading a database, you must either ensure that all incremental replications are up-to-date or perform full definition replications for each study and Global Library after you complete the upgrade. New Mandatory columns do not have values in the journal tables the system uses for both incremental replication and auditing. It would violate the audit trail to back-populate the journal tables with values for the new Mandatory fields, which are left null. An incremental replication that draws upon journal records created prior to the upgrade fails with the following error:

Mandatory column is null. Use caution when applying the percent symbol (%) wildcard to specify which studies to bring across when doing a full study replication. The % wildcard pulls over all studies that are available for replication from all owning locations. (A study is available for replication if its Ready to Repl check box is selected.) If your company has many studies at multiple locations, consider specifying studies uniquely.

11.4.1.3.2 Stop Standard Replication

To stop standard replication activities in your installation:

  • Cease the initiation of any new standard replication activities.

  • Ensure that no replication commands are issued, and no replication batch jobs are executed, until all database upgrades are complete.

In a distributed environment:

  1. Perform either an incremental or a full replication so that all sites are consistent.

  2. Suspend replication.

  3. Upgrade all databases in a replicated set. Do not restart replication until you finish upgrading all databases in a replicated set.

If you follow these instructions, you need only perform incremental replication after the upgrade. If you do not make all sites consistent before the upgrade, you must perform full replication after the upgrade.

11.4.1.3.3 Stop Symmetric Replication

Because symmetric replication operates independently of Oracle Clinical, you must stop the database activities that control the symmetric replication activities. In addition, you must stop the symmetric replication activities for each database in your installation.

To stop symmetric replication for one database in your installation:

  1. Log in as the REPSYS user.

  2. Check the replication queue for all pending jobs.

    1. List the pending jobs in the queue:

      select * from DEFTRAN;

    2. Push these pending transactions:

      dbms_defer_sys.execute(destination=>'other sites.WORLD',
      execute-as-user=>TRUE);

  3. Disable the replication queues until the upgrade is complete.

    1. List the jobs in the queue:

      select * from USER_JOBS;

    2. Locate all the job ID numbers for all push transactions (dbms_defer_sys.execute transactions)

    3. Stop each of these jobs by running:

      dbms_jobs.broken(job_id,TRUE);

      Note:

      This command halts all symmetric replication operations in and out of the affected database, including non-Oracle Clinical replication.

  4. Stop all modifications to the database.

    As much as possible, avoid making changes to programs, projects, organization units, regions, planned studies, factors, strata, active substances, drugs, or treatment regimens.

  5. Quiesce the databases by executing this command against the master database:

    execute dbms_repcat.suspend_master_activity ('RXA_DES');

  6. Drop the replication group from both databases:

    execute dbms_repcat.drop_master_repgroup ('RXA_DES');

11.4.2 Back Up Your Database(s)

Oracle recommends backing up your database(s) at this point.

11.4.3 Upgrade the Database to Oracle Database 12c Release 1 (12.1.0.1)

Do one of the following:

Note:

Choose to configure the database to accept connections as a service instead of a SID. Service name requirements for Oracle Clinical include:

  • The service name must be less than 15 characters long.

  • It must not include the domain.

  • It must be all lowercase.

The Oracle Clinical Installer no longer works if you set up connections using the SID.

Note:

If you are installing the Oracle Clinical database on a pluggable Oracle 12.1.0.1 database (PDB), see My Oracle Support article ID 1910177.1, How To Configure TNS / SQLNET using the local_listener parameter for Pluggable Database In Oracle 12c, Allowing a SQLNET Connection to the PDB. See "Finding Information on My Oracle Support."

11.4.3.1 Upgrade in Place

  1. Create an Oracle Database Container Database (CDB) to use one or more pluggable databases. (If you are upgrading multiple databases, you still need only one CDB.) OR create one non-CDB (11g-style) database.

    Update the listener and tnsnames.ora either before or after the next step.

  2. Upgrade your database to Oracle Database 12.1.0.1 using the Database Upgrade Assistant (DBUA) following Method 1 described in "Upgrading to Oracle Database 12c (12.1.0.2)" at http://www.oracle.com/technetwork/database/upgrade/upgrading-oracle-database-wp-12c-1896123.pdf.

11.4.3.2 Clone Your Database

  1. Create an Oracle Database Container Database (CDB) to use one or more pluggable databases. (If you are upgrading multiple databases, you still need only one CDB.) OR create one non-CDB (11g-style) database.

    Update the listener and tnsnames.ora either before or after the next step.

  2. Clone your database. See Oracle White Paper Cloning Oracle Clinical and TMS Databases, article ID 883213.1 on My Oracle Support. See "Finding Information on My Oracle Support."

11.4.4 Set Initialization Parameters

After the upgrade completes, set the init.ora parameters according to the instructions in Section 4.1.8, "Set Initialization Parameters."

You must stop and then start the database to activate the changed init.ora parameters.

Notes:

Do NOT SET the DB_DOMAIN parameter. In Release 5.1 and above this causes problems.

If you set up the EVENT parameter in the init.ora file to trace unique key constraints before upgrading, you should set the event parameter back to its required value. See Section 4.1.8, "Set Initialization Parameters" for details.

If your init.ora file includes the REMOTE_OS_AUTHENT parameter, make sure that it is not set to TRUE. It can be set to FALSE or be absent.

11.4.5 Create a Secret Store Directory

Create a directory that is accessible to the opapps user and different from the Oracle Wallet location. The Installer fails if this directory is not created before running the Installer.

Example location: /home/opapps/sec_store/db_name

11.4.6 Upgrade Databases to Oracle Clinical 5.1

This section describes how to run Installer to upgrade each database.

Note:

If you are upgrading to a RAC environment, you must import your database(s) to a single RAC node before running the Installer to upgrade it.

11.4.6.1 Gather the Required Information

See Section 4.2.2, "Gather Required Information" before you start the Installer. The information is not in quite the same order as displayed in the Installer for upgrading databases but it is the same information.

You also have the option to skip the upgrade but rerun all recreatable object scripts (views, packages, functions, and so on) against the database.

11.4.6.2 Running the Installer in UNIX

To start the upgrade of an Oracle Clinical database on a UNIX Database Server:

  1. Log in to the server computer as the opapps user.

  2. Change the primary group of the opapps account to the group that owns the Oracle Inventory:

    newgrp inst_group

    where inst_group is the name of the group that owns the Oracle Inventory. You specified the name during the Oracle Database 12c Release 1 (12.1.0.1) installation. Typically, this user group is oinstall.

    This temporary change is necessary so that the Installer can update the Oracle Inventory.

  3. Set the X Window display output to the IP address of your local computer. Use the standard format for IP addresses, for example:

    setenv DISPLAY 123.45.67.89

  4. Navigate to this location in the folder where you extracted the server code; see Section 1.5, "Downloading and Extracting the Software":

    server_code_platform\Disk1\install

  5. Change protections on files to 755.

    chmod 755 *

  6. Start the Installer:

    • For a non-RAC installation:

      ./runInstaller

      Or, if the database server has multiple Oracle Homes, then enter:

      ./runInstaller -invPtrLoc ORACLE_HOME/oraInst.loc

      For example:

      ./runInstaller -invPtrLoc /u01/app/oracle/product/121010_qa/oraInst.loc

    • For a RAC installation:

      ./runInstaller

      Or, if the database server has multiple Oracle Homes, then enter:

      ./runInstaller -local -invPtrLoc ORACLE_HOME/oraInst.loc

      For example:

      ./runInstaller -invPtrLoc /u01/app/oracle/product/121010_qa/oraInst.loc

      This ensures that the installation is performed only on the local node.

    The Installer opens to the Welcome screen. Click Next.

  7. In the Select a Product to Install screen, select OC Database Upgrade 5.1.0.0.x. Follow instructions on screen, entering the information indicated in Section 4.2.2, "Gather Required Information".

  8. Reset the privileges for the opapps account:

    newgrp group

    where group is the name of your original primary group for the opapps account.

11.4.6.3 Running the Installer in Windows

To begin the installation:

  1. Log in using an account with Windows system administrator privileges.

  2. Navigate to this location in the folder where you extracted the server code; see Section 1.5, "Downloading and Extracting the Software".

  3. Execute the following file as an administrator:

    Disk1\install\setup.exe

    The Installer opens to the Welcome screen. Click Next.

  4. In the Select a Product to Install screen, select OC Database Upgrade 5.1.0.0.x. Follow instructions on screen, entering the information indicated in Section 4.2.2, "Gather Required Information".

11.4.6.4 Review the Log Files for Upgrade Results and Errors

The Installer generates numerous log files and saves the files to the following location:

UNIX OPA_HOME/oc/51/install

Windows OPA_HOME\oc\51\install

After running the Installer, check the log files to confirm that the upgrade succeeded. Upgrading the Oracle Clinical database produces the following log files:

  • compile_all_invalid_database.log

  • html_blob_seeddata_database_timestamp.log

  • html_dialg_templ_database_timestamp.log

  • load_olsardcstatemachine_jar_database.log

  • oclconfig_database.log

  • oclupg_database.log

  • opaconnectcheck_system_database.log

  • upgrade_database_timestamp.log

  • xmlp_clob_seeddata_database_timestamp.log

  • xml_clob_seeddata_database_timestamp.log

The rest of this section describes finding errors in the log files (as logfile), and descriptions of known errors.

11.4.6.4.1 Finding Errors

To simplify reviewing upgrade results, run these commands for each of the database upgrade log files:

Oracle Linux From the command line, enter:


opa_setup database 51
cd $RXC_INSTALL
/bin/grep -n -E '^ORA-|^PLS-|^SP2-' logfile | more

Oracle Solaris SPARC From the command line, enter:


opa_setup database 51
cd $RXC_INSTALL
/usr/xpg4/bin/grep -E '^ORA-|^PLS-|^SP2-' logfile | more

HP-UX Itanium. From the command line, enter:


opa_setup database 51
cd $RXC_INSTALL
/usr/bin/grep -n -E '^ORA-|^PLS-|^SP2-' logfile | more

Windows Open a DOS window as an administrator and enter:


set p1=database
set p2=51
opa_setup
cd %RXC_INSTALL%
find /i "error" logfile | find /v "No error"

This section describes known error messages and possible actions you can take to resolve them.

11.4.6.4.2 Known Error Messages

See My Oracle Support Article ID 386941.1, OLSA 4.6.x and 4.7.x Known Install and Configuration Issues, for a description of any error messages.

11.4.6.4.3 Reencrypt Account Passwords

If the installation fails to reencrypt any password, it does not list them as errors. Instead, it lists them in the log files in a section titled, "Passwords for the following schema accounts were not converted." Check if this section exists and if it lists any accounts. If there are any accounts, you must reencrypt them using the set_pwd command; instructions are in the Oracle Clinical Administrator's Guide.

Normally if you are upgrading from 5.0.x and have not changed the location of the Secret Store directory, you do not need to rerun set_pwd.

11.4.6.4.4 Check If You Need to Prepare and Migrate Data

When you upgrade a database from Oracle Clinical 4.6.2 to Patch Set 4.6.3 or later, the Installer runs a validation script to ensure that all studies have been migrated to the enhanced approval and verification data model that was introduced in Oracle Clinical 4.5.3.11 and 4.5.3.12. If the database is in a replicated environment, within each study the Installer validates only patients that are owned by the current location.

Check the Installer log file:

  • If the validation succeeds, the log file includes the message "Validation succeeded, database has been migrated to the new approval/verification data model. No further action is required." and the database upgrade process continues. However, if in the future you need to unfreeze a currently frozen study, you may need to migrate its data first.

  • If the validation fails, the database upgrade process is terminated. The log file includes the error message that the migration has not been run on the database. Contact Oracle Support for further instructions.

11.4.6.5 Compile Invalid Objects

When upgrading the Oracle Clinical database, the Installer automatically calls and runs the following script to compile invalid objects:

compile_all_invalid.sql

However, to reduce the time required to run the script and to ensure that the installation completes in a timely manner, the compile_all_invalid.sql script does not compile these invalid objects:

  • Packages owned by RXC_PD (that is, the validation and derivation procedures that you have created). The package name starts with RXC_PD.

  • Data Extract views that belong to a study. In the database, these views are owned by an internal user whose name starts with study_name$.

  • Objects owned by any ops$ account. The compile_all_invalid.sql script ignores objects if the owner has a dollar symbol ($) in the name.

The log file generated by the compile_all_invalid.sql script lists the objects that could not be compiled.

To view the list of invalid objects, open the following log file:

$RXC_INSTALL\compile_all_invalid_database.log

To compile the remaining invalid objects (see Table 11-2), run the script compile_schema_invalid.sql.

You can run the compile_schema_invalid.sql script at a suitable time after the Installer finishes upgrading the Oracle Clinical database. You can recompile the invalid objects for a given schema by connecting to the schema and then running the compile_schema_invalid.sql script.

11.4.6.5.1 Compile PL/SQL Code Before Running the Script

If you have any PL/SQL code referenced from your generated procedures, ensure that these objects are valid before running the compile_schema_invalid.sql script.

For example, if you created a schema named X that contains all the PL/SQL code referenced from your generated procedures, you would first run:

compile_schema_invalid.sql X

Then, you would run:

compile_schema_invalid.sql RXC_PD

11.4.6.5.2 Run the compile_schema_invalid.sql Script

Follow the instructions appopriate for your operating system.

11.4.6.5.3 UNIX

To run the compile_schema_invalid.sql script on UNIX:

  1. Log in to the UNIX database server computer as the opapps user.

  2. Set the UNIX environment:

    opa_setup database_name code_environment

    where:

    • database is the name of this database instance.

    • code_environment is the value in the opa_settings file for this code environment. For Oracle Clinical 5.1, the default value is 51.

  3. Change to the RXC_INSTALL directory:

    cd $RXC_INSTALL

  4. Start an SQL*Plus session, and connect to the database as sys:

    sqlplus sys/sys_password as sysdba

  5. Run the script. Table 11-2 lists the options you can use to run the script depending on which invalid objects you want to compile.

    Table 11-2 SQL Commands for Compiling Specific Types of Invalid Objects

    To… Enter this SQL Command…

    Compile any invalid objects in RXC_PD

    start compile_schema_invalid RXC_PD

    Compile any invalid objects for the Data Extract views that belong to a study

    start compile_schema_invalid study_name$%

    Compile any invalid objects in OPS$ accounts

    start compile_schema_invalid OPS$%

    Compile any invalid objects in any account that has the dollar symbol ($) in the account name

    start compile_schema_invalid %$%

    Compile all invalid objects in all schemas

    start compile_schema_invalid %

    Note that this command compiles all invalid objects, including those in other schemas such as RXC and RXA_DES. However, the compile_all_invalid.sql script that the Installer automatically runs after upgrading the Oracle Clinical database already compiles the invalid objects for those schemas.

  6. Check the log file to verify that the script compiled the invalid objects successfully:

    $RXC_INSTALL\compile_schema_invalid_database.log

11.4.6.5.4 Windows

To run the compile_schema_invalid.sql script on Windows:

  1. Open a DOS window as an administrator and enter:

    set p1=database
set p2=51
opa_setup
cd %RXC_INSTALL%

  2. Start an SQL*Plus session, and connect to the database as sys:

    sqlplus sys/sys_password as sysdba

  3. Run the script. Table 11-3 lists the options you can use to run the script depending on which invalid objects you want to compile.

    Table 11-3 SQL Commands for Compiling Specific Types of Invalid Objects

    To… Enter this SQL Command…

    Compile any invalid objects in RXC_PD

    start compile_schema_invalid RXC_PD

    Compile any invalid objects for the Data Extract views that belong to a study

    start compile_schema_invalid study_name$%

    Compile any invalid objects in OPS$ accounts

    start compile_schema_invalid OPS$%

    Compile any invalid objects in any account that has the dollar symbol ($) in the account name

    start compile_schema_invalid %$%

    Compile all invalid objects in all schemas

    start compile_schema_invalid %

    Note that this command compiles all invalid objects, including those in other schemas such as RXC and RXA_DES. However, the compile_all_invalid.sql script that the Installer automatically runs after upgrading the Oracle Clinical database already compiles the invalid objects for those schemas.

  4. Check the log file to verify that the script compiled the invalid objects successfully:

    %RXC_INSTALL%/compile_schema_invalid_database.log

11.4.6.6 Perform Post-Upgrade Database Tasks

Do each of the following tasks.

11.4.6.6.1 Set the Database Time Zone

The Oracle Clinical Remote Data Capture Onsite (RDC Onsite) application uses the dbtimezone value for internal calculations when the Display timestamps in local timezone preference is set. See Section 4.4.1, "Set the Database Time Zone" for instructions.

11.4.6.6.2 Pin Database Packages

To improve performance, some of Oracle Clinical's packages are pin-able packages; Pinning allocates a stable memory location so that a package cannot be subjected to being swapped out of memory. Oracle Clinical provides the rxcdbinit.sql script in the rxc_install directory to pin the database packages.

Run the script rxcdbinit.sql as RXC. For details, see Section 4.4.2.1, "Pin UNIX Database Packages" or Section 4.4.2.2, "Pin Windows Database Packages".

11.4.6.6.3 Migrate Users

The requirements for users who need to run PSUB jobs changed in Release 5.0 and you must run a script to migrate their accounts to the new model, if you have not already done so. See the Oracle Clinical Administrator's Guide for information.

11.4.6.6.4 Run Scripts to Gather Schema Statistics for the Oracle Database Optimizer

After upgrading to Oracle Clinical 5.1 and setting initialization parameter optimizer_features_enable to 11.2.0.4 (see Section 4.1.8, "Set Initialization Parameters"), you must manually run scripts—ocstats.sql and opastats.sql—to gather statistics required for the Oracle Database Optimizer to be effective for accounts used internally by Oracle Clinical, RDC Onsite, and TMS. Failure to execute these scripts can negatively impact performance.

Note:

Oracle Clinical 5.1 is certified on the 11g Optimizer.

For more information on gathering statistics and using dynamic sampling to improve performance, see the Oracle Clinical Administrator's Guide.

11.4.7 Check Internal Sequence Numbers

Upgrading from 4.5.x If you are upgrading from Oracle Clinical 4.0.3 or 4.5.x, follow instructions in the Oracle Clinical Administrator's Guide "Troubleshooting" chapter, "Managing High Sequence Numbers" section, to assess the current value of internally generated IDs, reseed the sequence(s) if necessary, and ensure that the maximum value is properly set to avoid severe referential integrity bug 3718908. The affected sequences are the internal identifiers for:

  • Received DCMs (RDCMs)

  • Received DCIs (RDCIs)

  • Discrepancies

  • Responses

Upgrading from 4.6.x If you are upgrading from Oracle Clinical 4.6.x you may want to proactively determine whether you need to reseed any of these sequences. If the value of any of these internal IDs gets too close to the maximum, the system gives a warning message to a user attempting to use the relevant subsystem and exits the current screen. To avoid this, you can assess how close the highest current value is to the maximum and reseed the sequence in advance if necessary. For more information see the Oracle Clinical Administrator's Guide "Troubleshooting" chapter, "Managing High Sequence Numbers" section.

11.4.8 Upgrade Installations that Use Replication

If you use replication and have upgraded all databases in this distributed environment, follow instructions in the Oracle Clinical Administrator's Guide to enable the type(s) of replication you use.

11.5 Application Tier

This section includes:

11.5.1 Copy Any Customized Application Tier Files

If you have customized any application tier files, copy them into a location where they will not be overwritten by the new software. See Section 11.5.5, "Preserve Your Customizations" for a list of customizable files and their locations.

11.5.2 Install the Application Tier Technology Stack





11.5.2.1 Upgrading from a Release Earlier than 5.0


If you are upgrading from a release prior to 5.0, you cannot upgrade the application tier, you must install it fresh because Release 5.0 and later use a different technology stack:


    

  • 

    Oracle Application Server 11gR2, which includes the Oracle Forms Server and the Oracle Reports Server. Both are required for Oracle Clinical.
    

    • 

  • 

    WebLogic Server 11gR1 (10.3.6) and Oracle Application Developer Framework 11g R1. These are required for RDC Onsite.
    

    • 



You can install all components on the same machine, or install on multiple machines, but you must install all components on all machines and then disable services on the machine(s) where they are not needed.


To ensure high availability of the Reports Server, you can set up and use more than one Reports Server on a subnet and they can access each other. For more information see the Oracle Clinical Administrator's Guide.


Follow all instructions in Chapter 5, "Installing and Configuring the Application Tier."







11.5.2.2 Upgrading from Release 5.0.x


If you are upgrading from Oracle Clinical 5.0.x you can upgrade the application tier. You do not need to reinstall Oracle Application Server 11gR2, WebLogic Server 11gR1 (10.3.6), or Oracle Application Developer Framework 11g R1.


However, you do need to upgrade ADF and install a new version of Oracle Java Development Kit:











11.5.3 Install the Oracle Clinical Front End and Reports Server


Install the following:



If you are upgrading from 5.0.x, check that all entries that refer to opa_home refer to the correct opa_home. For example, if they say C:\opapps50, change to C:\opapps51.







11.5.4 Set Remote Method Invocation (RMI) JDBC Security to Secure


    

  1. 

    Log in to the WebLogic Server
    

    2. 

  2. 

    Go to Summary of Servers, select OpaServer1, select General, and click Advanced.
    

    3. 

  3. 

    Change the RMI JDBC Security setting to Secure.
    

    4. 

  4. 

    Click Save.
    

    5. 

  5. 

    Click Activate Changes.
    

    6. 









11.5.5 Preserve Your Customizations


You may have customized Oracle Clinical and RDC Onsite files for various purposes. Due to changes in the underlying application tier technology stack, many of these files have been changed in Release 5.0 and/or 5.1. The application tier cannot be upgraded; it must be completely reinstalled.


To preserve your customizations:


    

  1. 

    Back up each file that you have customized before you install the new application tier. The following sections provide a list of customizable files and the actions required to preserve your changes.
    

    2. 

  2. 

    From the Administration Console for the OPA domain (by default, port 7101), stop and delete the RDC Onsite application.
    

    3. 

  3. 

    Install the new application tier technology stack, following instructions in Chapter 5, "Installing and Configuring the Application Tier."
    

    4. 

  4. 

    Using information in the following sections, manually reenter your changes to the new versions of files that have changed in Release 5.0 or 5.1.
    

    5. 

  5. 

    Redeploy these files and any files you have customized that have not changed in Release 5.0 or 5.1.
    

    6. 

  6. 

    Restart the application for your changes to take effect.
    

    7. 



The following sections contain information on customizable files:






11.5.5.1 Oracle Clinical Forms


Affected Files: rxcuser.pll, rxcuser.fmb, rxcuser.mmb, rxclbcli.pll




Note:

If you have customized rxclbcli.pll to integrate OC with an external workflow or imaging system, you must change user_password arguments in getimage and getimagedcf from encrypted_passwords.password%type to varchar2.


Required Action to Preserve Customization: 


    

  • 

    Recompile rxcuser.fmb with Forms Builder 11g.
    

    • 

  • 

    Recompile rxcuser.mmb with Forms Builder 11g.
    

    • 

  • 

    Replace your recompiled rxcuser.fmb and rxcuser.mmb files on each Forms Server in your network.
    

    • 



Files marked Restored are backed up by the Installer in a location the user you specified during Oracle Clinical installation.




Table 11-4 Oracle Clinical Customizable Forms Files with 4.6.2 Locations










File Name
Location in 4.6.2
Purpose of Customization
Changed?








rxcuser.fmb


(Restored)




opapps46\oc\admin




Customizing the Users and Roles menu




Changed in 5.0 and 5.1








rxcuser.mmb


(Restored)




opapps46\oc\admin




Customizing the Users and Roles menu




Changed in 5.0 and 5.1








rxcuser.pll




opapps46\oc\admin




Customizing the Users and Roles menu




Changed in 5.0 and 5.1








rxclbcli.pll




opapps46\oc




Integration with other systems; see the Oracle Clinical Application Programming Interface Guide for information.




Changed in 5.0 and 5.1
















11.5.5.2 Oracle Clinical Reports


Affected Files: rxcdrptl.rdf, rxcdrptp.rdf


Required Action to Preserve Customization: Recompile with Oracle Reports 11g and replace in opa_home\oc folder on the Oracle Reports server.




Table 11-5 Oracle Clinical Customizable Forms Files with 4.6.2 Locations










File Name
Location in 4.6.2
Purpose of Customization
Changed?








rxcdcf.bmp


(Restored)




opapps46\oc\




Customizing the image on DCF reports.




Not changed








rxcdrptl.rdf


(Restored)




opapps46\oc\admin




Customizing DCF reports landscape template.




Changed in 5.0 and 5.1








rxcdrptp.rdf


(Restored)




opapps46\oc\admin




Customizing DCF reports portrait template.




Changed in 5.0 and 5.1








All files with extension .conf


(Not Restored)




ORACLE_AS10gR2_HOME\reports\conf




Report Server parameter configuration.




Obsolete in 5.0
















11.5.5.3 Formsweb.cfg


If you modified the DE_GRIDWIDTH and DE_GRIDHEIGHT parameters in formsweb.cfg, recreate your changes so your Data Entry screens have the correct appearance.


You may also have modified the file for file viewing purposes. These customizations are obsolete in Release 5.0; see Section 11.1.3, "Changes to File and Image Viewing".


In Release 4.6.2 this file was located at:


ORACLE_AS10gR2_HOME\forms\server.


The new version of the file is located at:


middleware_home\user_projects\domains\FRDomain\config\fmwconfig\servers\WLS_FORMS\applications\formsapp_11.1.2\config.








11.5.5.4 RDC Onsite Customizable Files


Table 11-6, "RDC Onsite Customizable Files" lists the RDC Onsite files that were customizable in Release 4.6.2 with their 4.6.2 location, the purpose of customization, and information about whether they have been changed or even made obsolete in Release 5.0 or 5.1, and their current location, if any.


Most of these files are now inside the olsardc.ear file, which contains the entire RDC Onsite application. You must reenter any customizations you have made and repackage the. ear file, then redeploy the application. Contact Oracle Support for help if necessary.


For more information on customizing these files, see the Oracle Clinical Remote Data Capture Onsite Administrator's Guide.




Table 11-6 RDC Onsite Customizable Files











File Name
Location in Release 4.6.2
Purpose of Customization
Changed?
Location in Release 5.1








bc4j.xcfg




ORACLE_AS10gR3_HOME\j2ee\rdc\applications\ olsardc\rdconsite\WEB-INF\classes\oracle\pharma\ rdc\model\services\common




Performance configuration




Changed; no longer used by launch page




olsardc.ear\RdcSurroundAdfWebUIWebApp.war\WEB-INF\lib\rdcmodel.jar\oracle\pharma\rdc\model\services\common








dataentry-config.xml




ORACLE_AS10gR3_HOME\j2ee\rdc\applications\ olsardc\ rdconsite\WEB-INF\




Performance configuration




Obsolete in 5.0; configurations moved to rdcConfig.properties




NA








dataentrylogger.properties


(Restored)




ORACLE_AS10gR3_HOME\j2ee\rdc\applications\ olsardc\rdconsite\WEB-INF




Specify the detail level of DE log file debug info




Changed in 5.0 and 5.1




olsardc.ear\RdcSurroundAdfWebUIWebApp.war\WEB-INF\








dcapi.properties


(Restored)




ORACLE_AS10gR3_HOME\j2ee\rdc\applications\ olsardc\ rdconsite\WEB-INF\




DCAPI log file generation, performance configuration




Changed in 5.0 and 5.1




\olsardc.ear\RdcSurroundAdfWebUIWebApp.war\WEB-INF\








de_external.properties


(Restored)




ORACLE_AS10gR3_HOME\j2ee\rdc\applications\ olsardc\ rdconsite\WEB-INF\classes\oracle\ pharma\rdc\de\resource\properties




Approval warning message, labels in data entry




Changed in 5.0 and 5.1




olsardc.ear\RdcSurroundAdfWebUIWebApp.war\WEB-INF\lib\rdcdataentry.jar\oracle\pharma\rdc\de\resource\properties








opalogger.properties




ORACLE_AS10gR3_HOME\j2ee\rdc\applications\ olsardc\ rdconsite\WEB-INF\




~




Obsolete in 5.0




NA








rdcConfig.properties




~




Multiple settings; see the Oracle Clinical Remote Data Capture Onsite Administrator's Guide for information.




New in 5.0.




OPA_CONFIG folder at the location specified in the opa51 registry under HKEY_LOCAL_MACHINE > Software > Oracle








RdcLogos.properties


(Restored)




ORACLE_AS10gR3_HOME\j2ee\rdc\applications\ olsardc\ rdconsite\WEB-INF\classes\oracle\ pharma\rdc\view




Contact Us link




Changed in 5.0 and 5.1




OPA_CONFIG folder at the location specified in the opa51 registry under HKEY_LOCAL_MACHINE > Software > Oracle








RdcTexts.properties


(Restored)




ORACLE_AS10gR3_HOME\j2ee\rdc\applications\ olsardc\rdconsite\WEB-INF\classes\oracle\pharma\rdc\view\nls




Change Password link, text and messages in the RDC Surround




Changed in 5.0 and 5.1




OPA_CONFIG folder at the location specified in the opa51 registry under HKEY_LOCAL_MACHINE > Software > Oracle








web.xml




ORACLE_AS10gR3_HOME\j2ee\rdc\applications\ olsardc\ rdconsite\WEB-INF




Timeout interval, performance configuration




Changed in 5.0 and 5.1




Most functionality moved to rdcConfig.properties.


Exists and located at: olsardc.ear\RdcSurroundAdfWebUIWebApp.war\WEB-INF\








orion-web.xml




ORACLE_AS10gR3_HOME\j2ee\rdc\application- deployments\ olsardc\rdconsite\




Used in image viewing




Obsolete in 5.0




NA








orion-web.xml




ORACLE_AS10gR3_HOME\j2ee\opa\application- deployments\ olsardc\rdcclassic\




Used in image viewing




Obsolete in 5.0




NA
















11.5.5.5 Customizable HTML Files


If you customized any of the following files, to retain your changes you must reapply your customizations after upgrading.


In Release 5.1 these files reside in the opapps51 directory, not the opapps46 directory.




Table 11-7 HTML Customizable Files with 4.6.2 Locations










File Name
Location in 4.6.2
Purpose of Customization
Changed?








launch.htm




opapps46\html




Customize the launch page




Changed in 5.0 and 5.1








ocdcitemplate.htm




opapps46\html




Customize the launch page for the batch generator for HTML Data Entry Forms and Patient Data Report Templates




Changed in 5.0 and 5.1








rdcadmin.htm




opapps46\html




Customize the RDC Admin launch page




Changed in 5.0 and 5.1








rdcadmint.htm




opapps46\html




Customize the RDC Admin test mode launch page




Changed in 5.0 and 5.1








rdclaunch.htm




opapps46\html




Customize the RDC launch page




Obsolete in 5.0








rdclauncht.htm




opapps46\html




Customize the RDC test mode launch page




Obsolete in 5.0








All files




opapps46\html\xhelp




Customize online help content




Changed in 5.0 and 5.1




















11.6 Postupgrade Steps


Set up the following:






11.6.1 Update Environment Variables (If Upgrading from 5.0.x)


If you upgrade from Release 5.0.x, the OC Front End and Reports Server Installers do not upgrade a few variables. Check these variables and update them from ...50 to ...51.


They are located on the SOFTWARE\ORACLE\KEYnumber branch of the registry on the application tier server. The unchanged variables are:


    

  • 

    OC_PDF_REPORTS_TMP
    

    • 

  • 

    OC_REPORTS_TMP
    

    • 

  • 

    OPA_XHELP_DIR
    

    • 

  • 

    OPA_XML_LOC
    

    • 









11.6.2 Manually Start the Advanced Queue Process (If You Cloned a Database)


If you cloned a database, manually restart the AQ process:


    

  1. 

    Stop PSUB, see the Oracle Clinical Administrator's Guide for instructions.
    

    2. 

  2. 

    Log in as sysdba.
    

    3. 

  3. 

    Enter:
    

    EXEC DBMS_AQADM.START_QUEUE('RXC.PSUB_REPLY_QUEUE',TRUE,TRUE); 
EXEC DBMS_AQADM.START_QUEUE('RXC.PSUB_SEND_QUEUE',TRUE,TRUE); 

    4. 

  4. 

    Start PSUB. See Section 8.2, "Starting and Stopping the PSUB Service."
    

    5. 




























Go to previous page

Previous		
Go to next page

Next		











Go to Documentation Home

Home		
Go to Book List

Book List		
Go to Table of Contents

Contents		
Go to Index

Index		
Go to Feedback page

Contact Us