| Oracle® Clinical Installation Guide Release 4.6.2 E18817-04 |
|
|
PDF · Mobi · ePub |
| Oracle® Clinical Installation Guide Release 4.6.2 E18817-04 |
|
|
PDF · Mobi · ePub |
This chapter describes the recommended approach to upgrading an existing Oracle Clinical installation to Release 4.6.2. You can use the instructions in this chapter to upgrade from any of the following releases:
Release 4.5.1
Release 4.5.2
Release 4.5.3
Release 4.6.0
Note:
If you are upgrading from Oracle Clinical Release 4.5 or earlier, you must upgrade to Release 4.5.1 first. Download the software and the Oracle Clinical Release 4.5.1 Installation Guide from the Oracle Life Sciences 4.5 media pack for your operating system on
http://edelivery.oracle.com. (Although the media pack is labeled "4.5" it contains Release 4.5.1.)This chapter includes the following topics:
Section 12.1, "Determining Whether You Need to Prepare and Migrate Data"
Section 12.3, "Create a New Oracle Database 11g Release 2 (11.2.0.2) Patch Set 1 Oracle Home"
Section 12.4, "Installing Oracle Clinical 4.6.2 on the Database Server"
Section 12.5, "Upgrading Oracle Clinical to the New Oracle 11gR2 Home"
Section 12.6, "Upgrading Database Objects to Oracle Clinical 4.6.2"
Section 12.12, "Upgrading Installations that Use Replication"
Review Chapter 1, "Preparing to Install Oracle Clinical" for system requirements and planning information. Ensure that your operating system and environment meet the requirements.
Check the Health Sciences Clinical documentation page at http://www.oracle.com/technetwork/documentation/hsgbu-clinical-407519.html to be sure you have the latest version of this guide.
Companion patches OC_4.5.3.11 and OC_4.5.3.12 introduced enhancements that expect approval and verification data to be represented in a new format in the database. Oracle Clinical 4.6.2 includes all these enhancements.
In addition, patches OC_4.5.3.11 and OC_4.5.3.12 included a Preparation script and a Data Migration script to migrate existing data from the old format to the new format. Oracle Clinical 4.6.2 includes these scripts.
Before you start to upgrade to Oracle Clinical 4.6.2, you must determine if the Preparation and Data Migration scripts have been run on your databases. Then take the appropriate action as outlined below to prevent data corruption:
If you are upgrading from 4.5.1 or 4.5.2 (or 4.5.3 without having applied 4.5.3.11 or its successor), you must run the Preparation and Data Migration scripts after you complete the 4.6.2 upgrade and before you open the Oracle Clinical 4.6.2 database for user access. Opening the Oracle Clinical 4.6.2 database for user access without migrating your data to the new data model will cause problems maintaining and reporting the correct approval and verification status for patient CRFs.
If you are upgrading from 4.5.3 and are unsure if you have applied patch 4.5.3.11 or its successor, perform the checks in Section 12.1.1, "Methods to Identify If Scripts Were Already Run". Otherwise, proceed with the instructions in Section 12.2, "Completing Other Pre-Upgrade Tasks". You will migrate your data later; see Section 12.10, "Preparing and Migrating Data If Necessary".
Note:
Preparing and migrating data is a lengthy process, so you should calculate the required downtime BEFORE you start the upgrade process; see Appendix A for guidelines.If you are upgrading from 4.5.3.11 (or a successor patch) or 4.6, you have probably already migrated your data. However it is important that you follow the instructions in Section 12.1.1, "Methods to Identify If Scripts Were Already Run" to be sure you run the migration once and only once.
If you are upgrading from 4.5.3.11 or a successor patch, or 4.6, and you determine that you have NOT run the Preparation and Data Migration scripts, or you are not sure, contact Oracle Support for assistance. DO NOT CONTINUE with the upgrade.
If you determine that you have already migrated your data, DO NOT prepare and migrate the data again. Re-running the scripts will cause problems maintaining and reporting the correct approval and verification status for patient CRFs. Proceed with the instructions in Section 12.2, "Completing Other Pre-Upgrade Tasks".
To determine if the Preparation script and the Data Migration script have been run against a database already:
Execute the following query against the database:
select table_name from all_tables where table_name like 'APPVER_RDCIH%'
If this query returns a record, it indicates that the Preparation script has been run. However, it does not indicate that the Data Migration script was run.
Navigate to the INSTALL directory on the database server. Look for a file with the following name:
oclupg45311migrate-database_name-timestamp.lis
If the file exists, it indicates that the Data Migration script has been run against the specified database (database_name).
Open and review the file to verify that the Data Migration script completed without any errors.
Caution:
If you are on 4.5.3.11 or later and have not run the Preparation and Data Migration scripts, or you are not sure, contact Oracle Support for assistance. DO NOT CONTINUE with the upgrade.Before you start to upgrade your system to Oracle Clinical 4.6.2, complete the preliminary tasks described in this section:
Oracle recommends backing up your database(s) at this point.
If you have a distributed environment in which you replicate data and metadata among multiple databases, stop all replication before continuing the upgrade.
Note:
Oracle Clinical 4.6 does not support replication. If you are upgrading from Oracle Clinical 4.6, you can skip this section.This section includes the following topics:
Tip:
You must upgrade all databases in your Oracle Clinical installation to Oracle Clinical 4.6.2 before setting up, or resuming, replication in any of them.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.
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:
Perform either an incremental or a full replication so that all sites are consistent.
Suspend replication.
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.
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:
Log in as the REPSYS user.
Check the replication queue for all pending jobs.
List the pending jobs in the queue:
select * from DEFTRAN;
Push these pending transactions:
dbms_defer_sys.execute(destination=>'other sites.WORLD', execute-as-user=>TRUE);
Disable the replication queues until the upgrade is complete.
List the jobs in the queue:
select * from USER_JOBS;
Locate all the job ID numbers for all push transactions (dbms_defer_sys.execute transactions)
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.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.
Quiesce the databases by executing this command against the master database:
execute dbms_repcat.suspend_master_activity ('RXA_DES');
Drop the replication group from both databases:
execute dbms_repcat.drop_master_repgroup ('RXA_DES');
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.
Stop PSUB on the database.
Log in to the operating system of the local computer in the RXCPROD account.
Set the environment variables for the database and code environment.
Enter the following command:
rxcpstop.sh rxc/password
Navigate to the Services control panel.
Highlight the PSUB service.
Click Stop.
Create a new Oracle home by following these operating system-specific tasks.
To install Oracle Database 11g Release 2 (11.2.0.2) Patch Set 1 in a new UNIX Oracle home, follow the instructions in these sections in Chapter 2:
Section 2.2, "Installing Oracle Database 11g Release 2 (11.2.0.2) Patch Set 1"
Section 2.3, "Setting Permissions and Write Access to Oracle-Owned Directories"
If necessary, perform the tasks in Section 2.4, "Setting Up User Groups and Accounts."
On a Windows 2008 R2 Server, follow the instructions in Section 3.1, "Installing and Patching Oracle Database 11g Release 2 (11.2.0.2) Patch Set 1" in Chapter 3.
If necessary, perform the tasks in Section 3.2, "Setting Up User Accounts and User Groups".
To install the Database Server component, you log in to the server, run Oracle Universal Installer from the appropriate download location, and select the OC Server product. Follow instructions for your operating system:
Section 12.4.1, "Install Oracle Clinical 4.6.2 on a UNIX Database Server"
Section 12.4.2, "Install Oracle Clinical 4.6.2 on a Windows Database Server"
This section describes the tasks that you complete to install Oracle Clinical 4.6.2 on UNIX Database Servers.
Perform the UNIX-specific installation instructions in Chapter 2, Section 2.5, "Installing the Oracle Clinical Database Server."
Installing Oracle Clinical creates the OPA_HOME/bin/opa_settings file. This file contains global environment setting defaults that you can now, if necessary, modify for this computer. See Section 2.6.3, "Review the opa_settings File" for more information.
Note:
The default settings for all databases or the specific settings for a particular database, such as NLS_LANG, must be correct in the opa_settings file.To install Oracle Clinical 4.6.2 on Windows Database Servers:
Perform the installation instructions in Section 3.3, "Installing the Oracle Clinical 4.6.2 Database Server."
Grant write access to the ORACLE_HOME directory and its contents.
Table 12-1 shows which versions of the Oracle database and which operating systems are required by different releases of Oracle Clinical. If you are upgrading from an Oracle Clinical release that runs on an earlier operating system version than is supported for Oracle Clinical 4.6.2, you must install Oracle Database 11.2.0.2 and Oracle Clinical 4.6.2 on a computer with the newer operating system and then export/import your Oracle Clinical database(s).
If you are using Oracle Clinical 4.5.x you must first upgrade your Oracle Database to 9.2.0.8 by installing the April 2010 or later CPU, if you have not already done so, before exporting your database(s).
Table 12-1 Oracle Clinical Releases and Supported Database Operating Systems
| Oracle Clinical | Oracle Database | UNIX | Windows |
|---|---|---|---|
|
4.5.1, 4.5.2, 4.5.3 |
9.2.0.8 (after the April 2010 CPU) |
HP-UX PA-RISC 11iV1 or 11iV2 (64-bit) Solaris SPARC 8, 9, or 10 (64-bit) |
Windows NT, 2000 or 2003 |
|
4.6 |
11.1.0.7 |
HP-UX Itanium 11.31 (64-bit) Solaris SPARC 9 or 10 (64-bit) Oracle Enterprise Linux 5 x86-64 |
Windows 2003 (32-bit) |
|
4.6.2 |
11.2.0.2 |
HP-UX Itanium 11.31 (64-bit) Solaris SPARC 10 (64-bit) Oracle Enterprise Linux 5 Update 5 x86-64 (64-bit) |
Windows 2008 R2, SP 1 (64-bit) |
Review the topics in this section, which might impact your upgrade strategy.
If you chose not to partition your databases in earlier implementations, take this opportunity to reconsider.
Oracle Clinical partitioning requires the Partitioning Option to Oracle Database 11g Release 2 (11.2.0.2) Patch Set 1. If you plan to implement Oracle Clinical partitioning, install this option just after you upgrade Oracle Database 11g Release 2 (11.2.0.2) Patch Set 1.
For further information, see the Oracle Clinical Administrator's Guide and the Oracle Database VLDB and Partitioning Guide at http://st-doc.us.oracle.com/11/112/server.112/e25523.pdf
Oracle recommends that you create all tablespaces with the Autoextend On option on to avoid running out of storage space.
However, depending on your upgrade path, the upgrade process can be shortened, and the application's performance may be improved by modifying and manually running the ocl452indexchg.sql script. This operation can improve running queries from RDC.
Review the default values in the ocl452indexchg.sql script, which is located in the RXC_INSTALL folder. Adjust the values to fit your installation's data.
Note:
During the database upgrade operation, the Installer creates default tablespace sizes contained in these upgrade scripts. Modify the scripts before you run the Installer.In addition, review the following document on My Oracle Support for the latest information about tablespace sizes:
Configuring Oracle Clinical Remote Data Capture Onsite 4.6.2 for Performance and ScalabilityArticle ID: 1300850.1
If upgrading from Oracle Clinical 4.5.1, the indexes are recreated automatically. This process could take a long time, depending on the amount of data in the application. Consider modifying ocl452indexchg.sql in resizing (redefining) the storage clause for the indexes being created there.
If upgrading from Oracle Clinical 4.5.2 or 4.5.3 — and the indexes were not created during the upgrade to 4.5.3 — consider modifying ocl452indexchg.sql in resizing (redefining) the storage clause for the indexes and executing this script standalone.
To run the ocl452indexchg.sql script on UNIX:
Log in to the UNIX Database Server.
Set the environment variables for the database and code environment.
Change to the installation directory:
cd $RXC_INSTALL
Run the ocl452indexchg.sql script:
sqlplus /nolog @ocl452indexchg.sql
To run the ocl452indexchg.sql script on Windows:
Log in to the Windows Database Server.
Enter the following commands:
set p1=database set p2=462 opa_setup cd %RXC_INSTALL%sqlplus /nolog @ocl452indexchg.sql
Depending on your current Oracle Clinical installation, you may be able to upgrade in place or do an export/import of your database(s).
Note:
If you are using Oracle Clinical 4.5.x, you must first upgrade your database to 9.2.0.8, if you have not already done so, by applying the April 2010 or later CPU.Oracle recommends that you create all tablespaces with the Autoextend On option on to avoid running out of storage space; see Section 12.5.2, "Review Tablespace Sizes".
Upgrading in Place If your current Oracle Clinical installation is on an operating system that is also supported for Oracle Clinical 4.6.2 (see Table 12-1, "Oracle Clinical Releases and Supported Database Operating Systems") and you choose to use the same hardware for OC 4.6.2, you can upgrade in place using the Oracle Database Upgrade Assistant (DBUA).
For performing an in-place upgrade using the Oracle DBUA, see the following documents:
Complete Checklist to Upgrade the Database to 11gR2 using DBUAMy Oracle Support article ID 870814.1; see "Finding Information on My Oracle Support"
Oracle Database Upgrade Guide 11g Release 2 (11.2), Chapter 3, "Upgrading to the New Release"; see "Finding Other Oracle Documentation"
Using New Hardware If your current Oracle Clinical installation is on an operating system version that is not supported for 4.6.2, or if you prefer to use new hardware, you must perform an export/import.
For export/import instructions see Cloning Oracle Clinical 4.6 and TMS 4.6.1 Databases; My Oracle Support Article ID: 883213.1.
Note:
Be sure to follow all the instructions in the document, including running the chown.sql script, the opachown.sql script, and if you are using TMS with Oracle Clinical, the tmschown.sql script. Use the Oracle Clinical 4.6.2 server code for cloning.This section describes how to run Oracle Universal Installer to upgrade your database to Oracle Clinical 4.6.2.
To begin the installation:
Log in using an account with Windows system administrator privileges.
Insert the Oracle Clinical and Oracle Thesaurus Management System 4.6.2 disk from the media pack.
Locate and execute file:
oc\server_code\win\install\setup.exe
The Installer opens to the Welcome screen.
Follow the instructions for each screen in the following section.
To start the upgrade of an Oracle Clinical database on a UNIX Database Server:
Log in to the server computer as the opapps user.
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 11g Release 2 (11.2.0.2) Patch Set 1 installation. Typically, this user group is oinstall.
This temporary change is necessary so that the Installer can update the Oracle Inventory.
Set the X Window display output to the IP address of your local computer. Use the standard format for IP addresses, and add ":0" to the end of the address. For example:
setenv DISPLAY 123.45.67.89:0
Navigate to this location in the folder where you extracted the server code:
server_code_platform\Disk1\install
Change protections on files to 755.
chmod 755 *
Start the Oracle Universal Installer:
./runInstaller
Follow the instructions on the installation screens. For additional information about each screen, see Section 12.6.3, "Attend to the Oracle Clinical Database Upgrade Installation Screens."
The Oracle Universal Installer guides you through installing and upgrading an Oracle Clinical database.
Click Next to continue the installation.
Select Oracle Clinical Database Upgrade 4.6.2.0.XX (where XX is the build number).
Click Next.
Select Installation Type Oracle Clinical Database Upgrade 4.6.2.0.XX (Note: XX is the build number.)
Select Upgrade and Configure (0 KB), and then click Next.
Specify Home Details Destination
Accept the default values, and then click Next.
Check that the displayed value is the correct location of the Oracle Clinical Database Server installation. If not, click Browse and locate the Oracle Clinical Database Server installation. Click Next.
Choose Database Connect string for database to be upgraded
Enter the Oracle SID for the database; for example, prod.
Click Next.
Choose Directory For new tablespaces
Specify the directory for these tablespaces:
BC4J_INTERNAL_TSPA: (Internal use only)
DX_TABLE_DATA: (Locally-managed tablespace for DX table data)
DX_INDEX_DATA: (Locally-managed tablespace for DX indexes)
Enter Database Configuration Parameters
Accept the default values for the full name of the host where the database is located, and the SQL*Net port used to connect to this database. The port number is specified in the tnsnames.ora file for this database. Click Next.
In successive screens, the Installer prompts you to enter passwords for the following DBA or subsystem schemas:
| SYS | SYSTEM | RXC | RXA_DES |
| RXA_LR | OPA | RXC_REP | RXC_PD |
| RXC_DISC_REP | RXC_MAA | TMS | RXC_SERVLETSP |
| RXC_SERVLETST | RXA_WS |
For a description of each password, see Section 4.2.4, "Attend to the Oracle Clinical Database Installation Screens."
Yes/No Ignore tablespace creation errors?
This setting controls whether the Installer ignores errors that occur when creating the tablespaces. Tablespace creation can fail for several reasons.
The default value is No. In general, you do not want the Installer to ignore tablespace creation errors. For example, you want the Installer to report an error if there is not enough space to create the tablespace.
On the other hand, if you are reinstalling into an existing Oracle Clinical database, the tablespace creation fails because the tablespace already exists. In this case, you do not need to know about the error.
Click Next.
The Information screen reports that the Installer will start a SQL*Plus session to complete the database upgrade. The screen confirms the name of the database installation, the location of the scripts used for the installation, and the location of the log file that you can view for the progress of the installation. Click Next.
Summary Oracle Clinical Database Upgrade 4.6.2.0.XX (Note: XX is the build number.)
The Summary screen provides information about this installation.
Click Install.
The Installer starts a SQL*Plus session in the background that updates the database. To monitor the progress, review the log file from the upgrade:
install/oclupg_database.log
This screen displays whether the installation succeeded. Click Exit.
Recall that before you started this installation on UNIX, you changed the primary group of the opapps account to the group that owns the Oracle Inventory (see Section 12.6.2, "UNIX Installer Starting Instructions"). This temporary change was necessary so that the Installer could update the Oracle Inventory.
To reset the privileges for the opapps account, enter the following command:
newgrp group
where group is the name of your original primary group for the opapps account.
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.
See the Oracle Clinical 4.6.2 Release Notes for Known Installation Issues for a description of any error messages.
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 by using set_pwd command.
To simplify reviewing upgrade results, run these commands for each of the database upgrade log files:
Oracle Enterprise Linux x86-64. From the command line, enter:
opa_setup database 462cd $RXC_INSTALL/bin/grep -n -E '^ORA-|^PLS-|^SP2-' logfile | more
Oracle Solaris SPARC. From the command line, enter:
opa_setup database 462cd $RXC_INSTALL/usr/xpg4/bin/grep -E '^ORA-|^PLS-|^SP2-' logfile | more
HP-UX Itanium. From the command line, enter:
opa_setup database 462cd $RXC_INSTALL/usr/bin/grep -n -E '^ORA-|^PLS-|^SP2-' logfile | more
Windows. From the command line, enter:
set p1=databaseset p2=462opa_setupcd %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.
When upgrading the Oracle Clinical database, the Oracle Universal 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 12-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.
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
Follow the instructions appopriate for your operating system.
To run the compile_schema_invalid.sql script on UNIX:
Log in to the UNIX database server computer as the opapps user.
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 4.6.2, the default value is 462.
Change to the RXC_INSTALL directory:
cd $RXC_INSTALL
Start an SQL*Plus session, and connect to the database as sys:
sqlplus sys/sys_password as sysdba
Run the script. Table 12-2 lists the options you can use to run the script depending on which invalid objects you want to compile.
Table 12-2 SQL Commands for Compiling Specific Types of Invalid Objects
| To… | Enter this SQL Command… |
|---|---|
|
Compile any invalid objects in RXC_PD |
|
|
Compile any invalid objects for the Data Extract views that belong to a study |
|
|
Compile any invalid objects in OPS$ accounts |
|
|
Compile any invalid objects in any account that has the dollar symbol ($) in the account name |
|
|
Compile all invalid objects in all schemas |
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 Oracle Universal Installer automatically runs after upgrading the Oracle Clinical database already compiles the invalid objects for those schemas. |
Check the log file to verify that the script compiled the invalid objects successfully:
$RXC_INSTALL\compile_schema_invalid_database.log
To run the compile_schema_invalid.sql script on Windows:
From the command line, enter:
set p1=database
set p2=462
opa_setup
cd %RXC_INSTALL%
Start an SQL*Plus session, and connect to the database as sys:
sqlplus sys/sys_password as sysdba
Run the script. Table 12-3 lists the options you can use to run the script depending on which invalid objects you want to compile.
Table 12-3 SQL Commands for Compiling Specific Types of Invalid Objects
| To… | Enter this SQL Command… |
|---|---|
|
Compile any invalid objects in RXC_PD |
|
|
Compile any invalid objects for the Data Extract views that belong to a study |
|
|
Compile any invalid objects in OPS$ accounts |
|
|
Compile any invalid objects in any account that has the dollar symbol ($) in the account name |
|
|
Compile all invalid objects in all schemas |
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 Oracle Universal Installer automatically runs after upgrading the Oracle Clinical database already compiles the invalid objects for those schemas. |
Check the log file to verify that the script compiled the invalid objects successfully:
%RXC_INSTALL%/compile_schema_invalid_database.log
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.
Do each of the following tasks.
After the upgrade completes, set the init.ora parameters according to the instructions in Section 4.1.8, "Set Initialization Parameters."
Review the Performance Tuning White Paper
In addition, review the following document on My Oracle Support for the latest information about setting the init.ora parameters:
Configuring Oracle Clinical Remote Data Capture Onsite 4.6.2 for Performance and ScalabilityArticle ID: 1300850.1
Stop, and then start the database to activate the changed init.ora parameters.
To improve security and to protect system access:
Change the default passwords of all schemas and roles
Use the set_pwd utility to encrypt the passwords in the database
See the Oracle Clinical Administrator's Guide for details about setting up user accounts and roles, changing passwords, and encrypting passwords.
See the Oracle Clinical Administrator's Guide for information about enrolling users.
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.
Oracle Clinical provides scripts that analyze the storage characteristics of tables and indexes of computed statistics. Run these scripts after the installation in the RXC_ INSTALL directory:
Run anarxctab.sql as RXC.
Run anadestab.sql as RXA_DES.
Run analrtab.sql as RXA_LR.
Run anaopatab.sql as OPA.
As you accumulate statistics for this database, run these scripts periodically. See the Oracle Clinical Administrator's Guide, Appendix E, "Collecting Statistics for Optimization" for more information.
Because Oracle Clinical 4.6.2 uses a different technology stack than earlier releases of Oracle Clinical, you must install new Application Servers, Forms Servers, and Reports Servers.
In addition, beginning with Oracle Clinical 4.6.2, PSUB uses a Secure Shell (ssh) execution service and Oracle Clinical uses SFTP for file viewing. You need to set up PSUB and configure SFTP before using Oracle Clinical.
Optionally, you may want to set up additional clients or configure the SAS statistical software application to function with Oracle Clinical Data Extract.
For information about installing and configuring:
Application Servers — See Chapter 5, "Installing and Configuring Oracle Application Server."
Forms Servers — See Chapter 6, "Installing Oracle Clinical Front End."
Reports Server — See Chapter 7, "Installing Reports Servers."
PSUB — See Chapter 8, "Setting Up the Parameterized Submission Process."
SFTP — See Chapter 9, "Implementing Secure FTP for File Viewing (UNIX Only)."
Clients — See Chapter 10, "Setting Up Clients."
SAS — See Chapter 11, "Setting Up SAS."
If you customized any of the following scripts in Oracle Clinical 4.5.1, 4.5.2, or 4.5.3, you may need to reapply your customizations after upgrading to 4.6.2. They are located in the RXC_INSTALL directory.
rxcptdxvb.sql: No changes in Oracle Clinical. If you customized this file in Release 4.5.1, 4.5.2, or 4.5.3, you can copy the file from that release.
rdcpb_client.sql: Changed in Oracle Clinical 4.5.3. If you customized before Release 4.5.3, you must reapply your customizations.
ocl_client_pb.sql: No changes in Oracle Clinical. If you customized this file in Release 4.5.1, 4.5.2, or 4.5.3, you can copy the file from that release.
rxasravw.sql or rxasravw_custom.sql: Replication setup script. If you customized this file in Release 4.5.1, 4.5.2, or 4.5.3, you can copy the file from that release.
Ensure that you applied the following data diagnostic and repair patches (or their successors) on your Oracle Clinical data.
The code fixes from the following patches are included in the Oracle Clinical 4.6.2. You do not need to apply the patches. However, if you have not already done so, you must run the Find and Fix scripts for each patch; see the patch release notes for instructions. The Find and Fix scripts are also shipped with Oracle Clinical 4.6.2.
Patch OC_4.5.3.21 (or its successor). Includes scripts to find and fix the data affected by Bug 8908711. The Find script in this patch identifies received DCM's (CRF sections) with an invalid status of PASS 1 COMPLETE and Blank flag = Y. (When Blank flag = Y, the status should be RECEIVED.) Once you run the script, you can open and update the affected CRFs without encountering the following error message:
300500 ERROR WHILE TRYING TO ADD A DISCREPANCY
Patch OC_4.5.3.14 (or its successor). Provides a Find script to address data issues that may have been introduced with the use of group activities (for example, Approve or Verify) from the Activity list in RDC Classic only. (Note that the problem does not occur in RDC Onsite). For more information, see Bug 8271954.
The code fixes from the following patches are included in the Oracle Clinical 4.6.2. You do not need to apply the patches. However, if you have not already done so, you must run the Find and Fix scripts for each patch; see the patch release notes for instructions. The Find and Fix scripts are also shipped with Oracle Clinical 4.6.2.
Patch OC_4.5.1.58: Finds the data affected by bugs 5186346 and 5766849.
Patch OC_4.5.1.67: Includes repairs in discrepancy management, soft-deleting documents in a study with enabled CRF page-tracking, replication problems, and modifications to the DCF report.
Patch OC_4.5.1.68: Finds and fixes the data affected by bug 7515931.
Patch OC_4.5.1.76: Finds and fixes the data affected by bug 8925493.
If you determined in Section 12.1, "Determining Whether You Need to Prepare and Migrate Data" that you have not yet migrated data for the approval and verification enhancement introduced in 4.5.3.11, prepare and migrate your data now; see Appendix A, "Migrating Data for Approvals and Verifications Enhancements".
Note:
It is very important to migrate your data once and only once. If you are in doubt, contact Oracle Support.Follow instructions below for your operating system. For additional information see the Oracle Clinical Administrator's Guide.
To start the PSUB process on UNIX:
Log in as rxcprod, or as any other account that has OPA_HOME/bin in its path.
Enter:
start_psub database_name code_environment
where database_name is the connect string for the database instance to which the PSUB process connects.
If you are not logged on as rxcprod, you are prompted to provide the password for the rxcprod account. If the PSUB process is already running, the system displays an error message.
Tip:
By default, the PSUB service does not start automatically when you restart a Server computer. However, you can configure the PSUB service to start automatically. See the Oracle Clinical Administrator's Guide for details.To change the startup of the PSUB service on Windows:
Log in as Administrator.
Set the PSUB service parameters:
In the Start menu, navigate to Administrative Tools, then Services.
From the list of services in the Services dialog box, double-click the name of the database for this service. It is in this form:
PSUB Service database
For Startup type, select Manual.
Click the Log On tab.
For Log On As, select This account and then enter RXCPROD in the field.
(The task of creating the RXCPROD account occurs during the installation of the Database Server. See Section 3.2.1, "Create the RXCPROD Account" for more information.)
In the Password and Confirm Password fields, enter the RXCPROD password.
Click OK to close the dialog box.
Exit from the Services dialog box.
Log off this Administrator session.
To start PSUB as a Windows process:
Log in to the computer as user RXCPROD. (You set up the PSUB service to start as the RXCPROD user, but in Windows you can start the service when logged on as another user.)
Set the PSUB service parameters:
In the Start menu, navigate to Administrative Tools, then Services.
From the list of services in the Services dialog box, double-click the name of the database for this service. It is in this form:
PSUB Service database
Enter values for the Log On parameters:
database code_environment [verbose | noverbose] value-of-RXC_ROOT
For example: prod 462 verbose c:\\opapps\\oc\\462
Note:
If your entry requires a backslash (\), you must enter two (\\). Alternatively, you can enter the path using single forward slashes, for example, c:/OPA_HOME/oc/462.Click Start.
Exit from the Services dialog box.
If you have difficulty starting PSUB on a Windows database after upgrading to or installing Oracle Clinical:
Open the sqlnet.ora file and confirm that following line is not commented (that is, there is no '#' at the beginning of the line). If there is, uncomment the line (remove the #):
sqlnet.authentication_service=(NTS)
Attempt to start PSUB.
If PSUB fails to start:
Open the init.ora file. Ensure that the following lines are not commented out and have the values specified. If not, uncomment and/or change the values.
remote_os_authen=FALSE os_authent_prefix="OPS$"
Shut down any databases on the Windows server, then start the databases.
If you are using replication to conduct Oracle Clinical studies in a distributed environment, you may need to:
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—standard or symmetric replication.
The oclupg45311replicate.sql script replicates the approval and verification system tracking records in the RDCI_HISTORY table from the source location to the target location for the data replicated studies. See Section A.4.6, "Replicate Approval and Verification Tracking Records" for instructions.
If all the following conditions apply to you, follow instructions in this section:
You have a replicated environment.
You are upgrading from a release prior to Oracle Clinical 4.5.1.60 and you have not executed full replication since then.
You have Page Tracking-enabled studies or you want to replicate discrepancy and DCF information.
Patch OC_4.5.1.60 introduced replication of page tracking information, DCFs, and discrepancies. If you never applied patch OC_4.5.1.60 or its successor 4.5.1.75, you should perform an initial replication of this data.
You have two choices:
Use full replication
Use incremental replication and run a script
To do a full replication following the upgrade:
Complete the upgrade to Oracle Clinical 4.6.2.
Set the value of ALLOW_DISC_REPL in the OCL_INSTALLATION reference codelist to Y.
Run Full Study Data replication for all current studies.
If you do not want to run full replication, follow the instructions in "Option 2: Do an Incremental Replication and Run a Script".
If you choose to use incremental replication to upgrade your replicated environment, you must also run the replicate_rpages_disc_dcf_tables.sql script. This script replicates existing received pages, discrepancy entries, and DCF related tables for all studies or for a given study. Running these two processes is likely to take less time than running full replication.
You run this script:
From the RXC_REP account.
On each target database that you want received pages, discrepancies, and DCFs data migrated.
Once for each source data location either for all studies or for one study at a time.
To do an incremental replication following the upgrade and run the replicate script:
Complete the upgrade to Oracle Clinical 4.6.2.
Run Incremental Study Data replication for studies that you want received pages, discrepancies, and DCFs data migrated. (The script will not pick up the study unless you execute this step.)
Note:
You need to run Incremental Study Data from all locations against all remote locations.Set the value of ALLOW_DISC_REPL in the OCL_INSTALLATION reference codelist to Y at the Global Library-owning location.
Run Full Global Library replication at all non-Global-Library-owning locations.
UNIX To run replicate_rpages_disc_dcf_tables.sql on UNIX:
Log in to the database server as the opapps user.
Set up the environment variables:
opa_setup database_name code_environment
Change to the installation directory:
cd $RXC_INSTALL
Connect to SQL*Plus as the RXC_REP user.
Run the replicate_rpages_disc_dcf_tables.sql script:
start replicate_rpages_disc_dcf_tables.sql
The script prompts for the following information:
Name of the source data location.
Name of the database link for the source data location.
Name of the study. You can enter % for all studies, or you can enter the name of one study.
The script commits the data for each study after it has successfully replicated the data. If an error occurs while processing a study, the script records the error message in the log file and then starts processing the next study.
Review the following generated log file after the script completes processing:
replicate_rpages_disc_dcf_tables-timestamp.lis
where timestamp is the date and time (yyyymmddhhmiss).
Windows To run replicate_rpages_disc_dcf_tables.sql on Windows:
From the command line, enter:
set p1=database
set p2=462
opa_setup
cd %RXC_INSTALL%
Start an SQL*Plus session and connect to the database as the RXC_REP user:
sqlplus RXC_REP/RXC_REP_password
Run the script.
start replicate_rpages_disc_dcf_tables.sql
Verify that the script ran successfully.
Review the following generated log file after the script completes processing:
replicate_rpages_disc_dcf_tables-timestamp.lis
where timestamp is the date and time (yyyymmddhhmiss).
Check My Oracle Support article Oracle Clinical Versions 4.6.2, 4.6, 4.5 and 4.0 Summary of Patches Available (article ID 121863.1) for the latest patch set (4.6.4 or its successor) and apply it. This will provide you with the latest bug fixes and validate the data migration status of all your studies.
If you are installing your database on Windows, you must apply the latest patch set. Oracle Clinical 4.6.2 is not supported on Windows without Patch Set 4.6.4 or later.
|
 Copyright © 1996, 2013, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|