Stop Processes
Before you start to upgrade your system to Oracle Clinical 5.2.2, complete the preliminary tasks described in this section:
Parent topic: Upgrade Oracle Database Server Code and Databases
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
- Log in to the operating system of the local computer with the rxcprod account.
- Set the environment variables for the database and code environment.
- Enter the following command:
stop_psub database_name code_environment rxcprod_password
If you are upgrading from Release 5.0.x
Use the echo command to check the setting, then stop PSUB.
- Log in to the operating system of the local computer in the opapps account.
- Set the environment variables for the database and code environment.
- Enter the following command:
echo $TNS_ADMIN setenv TNS_ADMIN $OPA_HOME stop_psub database_name code_environment Wallet_alias
To stop PSUB on Windows:
- Navigate to the Services control panel.
- Highlight the PSUB service.
- Click Stop.
Parent topic: Stop Processes
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:
Parent topic: Stop Processes
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.
Tip:
You must upgrade all databases in your Oracle Clinical installation to Oracle Clinical 5.2.2 before setting up, or resuming, replication in any of them.For more information, see:
Parent topic: Stop Processes
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.
Parent topic: Stop Replication (If Applicable)
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:
- 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.
Parent topic: Stop Replication (If Applicable)
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:
- 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);
- List the pending jobs in the queue:
- 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.
- List the jobs in the queue:
- 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');
Parent topic: Stop Replication (If Applicable)