| Oracle® Beehive Installation Guide Release 1 (1.5) for Linux x86 Part Number E14830-05 |
|
|
View PDF |
| Oracle® Beehive Installation Guide Release 1 (1.5) for Linux x86 Part Number E14830-05 |
|
|
View PDF |
This module describes steps to perform before upgrading your Oracle Beehive deployment to Oracle Beehive Release 1 (1.5), the order in which you should upgrade Oracle Beehive products, and other procedures to perform after upgrading.
Note:
You may only upgrade an Oracle Beehive Release 1 (1.4.3) deployment to Oracle Beehive Release 1 (1.5). You must upgrade an Oracle Beehive Release 1 (1.4.1) deployment to Oracle Beehive Release 1 (1.4.3) before upgrading it to Oracle Beehive Release 1 (1.5).This section covers the following topics:
Perform or ensure the following before upgrading Oracle Beehive Release 1 (1.4.3) to Oracle Beehive Release 1 (1.5):
Ensure Passwords for ORAWSM and BEE_CODE Schemas Are the Same
Prepare System for Partitioning of Time Management Database Tables
If your Oracle Beehive deployment uses an Oracle Database version earlier than 10.2.0.4, then upgrade it to a version that Oracle Beehive Release 1 (1.5) supports. Refer to "Oracle Beehive Database Requirements" for more information.
Ensure that the password for the ORAWSM schema is the same as the one for the BEE_CODE schema. If not, change the ORAWSM password before proceeding with the upgrade.
Ensure the value of the configuration parameter XmppTimerKeepAliveTime is 10 or less. Run the following command to obtain the value of XmppTimerKeepAliveTime:
beectl list_properties --component _xmppservice --name XmppTimerKeepAliveTime
-------------------------+------------------------------------------------------
Property name | Property value
-------------------------+------------------------------------------------------
XmppTimerKeepAliveTime | 5
-------------------------+------------------------------------------------------
If the value of XmppTimerKeepAliveTime is greater than 10, set it to 5 (the default value) with the beectl modify_property command. Afterwards, run the command beectl activate_configuration to commit changes to the configuration.
Note:
You do not have to perform this step in the following situations:You have installed (but not upgraded to) Oracle Beehive Release 1 (1.4)
You have installed Oracle Beehive Release 1 (1.2) or Release 1 (1.3) and have never cloned any application tiers or sites
You have cloned an application tier or site only after upgrading to Oracle Beehive Release 1 (1.4)
Before upgrading Oracle Beehive Release 1 (1.4.3) to Oracle Beehive Release 1 (1.5), analyze each of your Oracle Beehive application tiers by running the command beectl clone_preparation on each of them. For more information about running this command, refer to "Step 4: Call beectl clone_preparation Command" in "Cloning Oracle Beehive Application Tiers and Sites". This command creates a text file that contains the names of files in the source Oracle home to be copied for cloning to the target location. You will not need this file to upgrade Oracle Beehive. However, if the beectl clone_preparation command fails for a particular application tier, you will not be able to upgrade it. You must uninstall any application tier where the beectl clone_preparation command fails before upgrading your Oracle Beehive deployment.
If you applied an Oracle Application Server Critical Patch Update (CPU) patch to any of your Oracle Beehive Release 1 (1.4.3) application tiers, follow the steps described in OracleMetaLink Note 735631.1, "Symbol Referencing Error on nzospRandNum When AS Patchset Applies Patch 4601861 (CPU Patch Previously Applied)." These steps involve rolling back previously applied CPU patches and applying the latest CPU patch for the new patchset version.
If you are upgrading an Oracle Beehive Release 1 (1.4.3) application tier that has been upgraded from an Oracle Beehive Release 1 (1.3.1) application tier or earlier, ensure the file <Oracle Beehive home>/network/admin/tnsnames.ora exists before upgrading your Oracle Beehive Release 1 (1.4.3) application tier.
The tnsnames.ora file must contain an entry that specifies the TNS (Transport Network Substrate) identifier of BEEDB and the connection information of the database used by your Oracle Beehive deployment.
The following is an example of this entry (line breaks have been inserted for clarity):
BEEDB = (DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=mydb.example.com) (PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=myservice.example.com)))
Use one of the following methods to obtain the TNS identifier of BEEDB:
Run the command beectl list_bootstrap_configuration and look for the ConnectString property (the --format option is optional):
beectl list_bootstrap_configuration --format xml <?xml version="1.1" encoding="UTF-8"?> <beectl-output resultset="table"> <row> <column name="Property Name">ConnectString</column> <column name="Property Value"> (DESCRIPTION=(ADDRESS_LIST= (ADDRESS=(PROTOCOL=TCP) (HOST=mydb.example.com)(PORT=1521))) (CONNECT_DATA=(SERVICE_NAME=beedb.example.com))) </column> </row>
Run the command beectl list_properties --component _CURRENT_SITE:Database and look for the ConnectDescriptor property (the --format option is optional):
beectl list_properties --component _CURRENT_SITE:Database --format xml ... <row> <column name="Property name">ConnectDescriptor</column> <column name="Property value"> (DESCRIPTION=(ADDRESS_LIST= (ADDRESS=(PROTOCOL=TCP) (HOST=mydb.example.com)(PORT=1521))) (CONNECT_DATA=(SERVICE_NAME=beedb.example.com))) </column> </row>
Before upgrading Oracle Beehive Release 1 (1.4.3) to Oracle Beehive Release 1 (1.5), export configuration data of your Oracle Beehive Release 1 (1.4.3) deployment that you want to preserve for future reference. In particular, you may want to preserve the configuration data of your Oracle Beehive deployment before you upgrade it.
Use the beectl export_configuration_data command to export configuration data.
Although the upgrade process does not remove or delete configuration data, it does not upgrade it to the new configuration data structure that Oracle Beehive Release 1 (1.5) uses. Consequently, you cannot access configuration data of previous versions of Oracle Beehive with the beectl command; contact your Oracle representative if you require access to this data.
In Oracle Beehive Release 1 (1.5), some Time Management Oracle Database tables have been partitioned. When you upgrade from Oracle Beehive Release 1 (1.4.3) to Oracle Beehive Release 1 (1.5), the upgrade process will partition this tables.
To estimate the time the upgrade process will take to partition the Time Management tables, determine the total number of invitations and assignments by running the queries described in "Determine Number of Invitations" and "Determine Number of Assignments". Partitioning the tables will take about 60 minutes for every million invitations and assignments.
Before upgrading from Oracle Beehive Release 1 (1.4.3) to Oracle Beehive Release 1 (1.5), you must perform the following steps to avoid any potential issues during the partitioning process:
Ensure that there is enough disk space for the partitioning process. During this process, the size of the Time Management tables will temporarily double. As a simple guideline, determine the current amount of space used by the tables and indexes whose names begin with TM_. This is the minimum amount of free space required to partition the Time Management tables. However, since other phases of the upgrade process may require additional space, ensure that you also have enough space for these phases.
Determine the number of invitations in your database as described in "Determine Number of Invitations". Do this just before you upgrade Oracle Beehive while Oracle Beehive is down. If your database contains more than 900,000 invitations, perform the following steps. If not, ignore the following steps and proceed with the rest of the upgrade.
Install the Oracle Beehive Release 1 (1.5) binaries but do not perform the upgrade by running the Install Wizard with the -noConfig option:
runInstaller -noConfig
Refer to "Starting Oracle Beehive Install Wizard" for more information.
Open the following script in a text editor:
<Oracle Beehive home>/beehive/tmp/patch/7387847/db/tm_partition_chki.sql
Locate the following line:
:cont := CASE WHEN l_count <= 1000000 THEN 'tm_partition.sql' ELSE '^^skip' END;
Change the value 1000000 to twice the number of invitations in your database. For example, suppose the query described in "Determine Number of Invitations" returned the following:
COUNT(*) ---------- 30000000
You would modify tm_partition_chki.sql as follows:
:cont := CASE WHEN l_count <= 60000000 THEN 'tm_partition.sql' ELSE '^^skip' END;
Save the changes you made to the script.
Upgrade Oracle Beehive by running the Config Wizard, <Oracle Beehive home>/beehive/oobwiz/configWizard. Ensure that you have performed the steps described in the section "Before Upgrading" and are following the upgrade sequence as described in "Upgrade Sequence". For more information about the Config Wizard, refer to the section "Oracle Beehive Config Wizard" in "Oracle Beehive Install and Config Wizard Command-Line Options".
In SQL*Plus as the bee_data user, run the following query to determine the number of invitations:
SQL> CONNECT BEE_DATA Enter password: ******** Connected. SQL> SELECT COUNT(*) FROM TM_INVS;
In SQL*Plus as the bee_data user, run the following query to determine the number of assignments:
SQL> CONNECT BEE_DATA Enter password: ******** Connected. SQL> SELECT COUNT(*) FROM TM_ASSIGNMENTS;
Depending on which version and where you installed Oracle Beehive Integration for Zimbra, follow the steps in these sections:
If your Oracle Beehive Release 1 (1.4.3) instance and Oracle Beehive Integration for Zimbra version 1.4.3 instance reside in the same computer and are registered in the same Oracle inventory location, follow these steps before upgrading Oracle Beehive and Oracle Beekeeper to version 1.5.1. (Note that these steps still apply if you previously upgraded your Oracle Beehive or Oracle Beehive Integration for Zimbra instances to version 1.4.3):
Backup the file <Oracle Beehive Integration for Zimbra home>/beehive/oobwiz/configWizard.properties.
Edit the file <Oracle Beehive Integration for Zimbra home>/beehive/oobwiz/configWizard.properties as follows:
Find the following line:
InstallType=Client
Change this line to the following:
InstallType=
Perform any other required tasks before upgrading Oracle Beehive as described in this module, then upgrade Oracle Beehive to version 1.5.1.
After upgrading Oracle Beehive to version 1.5.1 but before upgrading Oracle Beehive Integration for Zimbra to version 1.5.1, copy the version of configWizard.properties you backed up to <Oracle Beehive Integration for Zimbra home>/beehive/oobwiz.
Alternatively, edit the file <Oracle Beehive Integration for Zimbra home>/beehive/oobwiz/configWizard.properties and change the line InstallType= to InstallType=Client.
Upgrade Oracle Beehive Integration for Zimbra to version 1.5.1.
If you are upgrading Oracle Beehive Integration for Zimbra version 1.4.3 to version 1.5.1, and you previously upgraded it from version 1.3.1 or 1.4.1, perform the following steps before upgrading it to version 1.5.1:
Backup the contents of the directory <Oracle Beehive Integration for Zimbra home>/inventory/contentsXML/configXML.
Retrieve a list of all the XML files that begin with Beehive from the directory <Oracle Beehive Integration for Zimbra home>/inventory/contentsXML/configXML:
ls -l Beehive* BeehiveAggregate.<version number>.xml BeehiveConfig.<version number>.xml BeehiveDeconfig.<version number>.xml
From this list, delete all files except those whose <version number> is 1_5_1_0_0.
For example, the folder configXML may contain the following files on your system:
ls -l Beehive*
BeehiveAggregate.1_4_1_0_0.xml
BeehiveAggregate.1_4_3_0_0.xml
BeehiveAggregate.1_5_1_0_0.xml
BeehiveConfig.1_4_1_0_0.xml
BeehiveConfig.1_4_3_0_0.xml
BeehiveConfig.1_5_1_0_0.xml
BeehiveDeconfig.1_4_1_0_0.xml
BeehiveDeconfig.1_4_3_0_0.xml
BeehiveDeconfig.1_5_1_0_0.xml
After deleting the files that do not contain the version number 1_5_1_0_0, the folder configXML should contain the following files:
ls -l Beehive*
BeehiveAggregate.1_5_1_0_0.xml
BeehiveConfig.1_5_1_0_0.xml
BeehiveDeconfig.1_5_1_0_0.xml
Edit the file <Oracle Beehive Integration for Zimbra home>/beehive/install/beeStart.pl and comment out the line that launches the owsmInstallProperties subroutine.
Search for the following lines in the file beeStart.pl:
# prepare owsm properties file &owsmInstallProperties();
Add the number sign (#) to the beginning of the line &owsmInstallProperties();:
# prepare owsm properties file
# &owsmInstallProperties();
Oracle Beehive Release 1 (1.5.1.1.0) Patch comes with Zero Downtime Upgrade (ZDU), which minimizes the amount of downtime required for upgrading or applying patches to Oracle Beehive.
After installing the Oracle Beehive Release 1 (1.5.1.1.0) Patch and before upgrading or applying a newer patch to Oracle Beehive, perform the following steps:
Part of the upgrade or patching process involves updating code objects, which are stored in its own code schema in the Oracle Beehive database. The ZDU process first clones the code schema, then updates the cloned schema. This allows users in a multi-application tier environment to continue using Oracle Beehive during the upgrade or patching process; updated application tiers would use the cloned, updated code schema while those tiers that have not been updated would use the original code schema.
The code schema cloning process uses Oracle Data Pump technology, which enables very high-speed movement of data and metadata from one database to another. You must configure Oracle Data Pump before upgrading or patching Oracle Beehive.
During the upgrade or patching process, Oracle Beehive uses two database directory objects named BEEHIVE_DATA_PUMP and BEEHIVE_DATA_PUMP_LOG, which Oracle Beehive uses as the Oracle Data Pump data directory and log file directory, respectively. Depending on whether your Oracle Beehive deployment uses Oracle RAC nodes or not, either perform "Defining Oracle Data Pump Directories for Non-Oracle RAC Deployments" or "Defining Oracle Data Pump Directories for Oracle RAC Deployments". Afterwards, perform "Backing up and Deleting Oracle Data Pump Log Files".
If your Oracle Beehive deployment does not use Oracle RAC, follow these steps to define the Oracle Data Pump directories BEEHIVE_DATA_PUMP and BEEHIVE_DATA_PUMP_LOG:
Create two directories on the computer that is hosting your database, one that will store Oracle Data Pump data and another Oracle Data Pump log files. Use regular file system commands, like mkdir, to create these directories.
ASM Note:
If your database is using Oracle Automatic Storage Management (ASM), you must create the data directory in a new or existing disk group. Use the ASMCMD command-line utility as follows:ASMCMD> mkdir +DISKGROUP1/beehive_data_pump_directory
DISKGROUP1 is either an existing or new disk group. beehive_data_pump_directory is the name of the data directory you are creating.
You must not create the log file directory in ASM; it must be a regular directory in the file system of the computer that is hosting your database.
Refer to "ASM Command-Line Utility" in Oracle Database Storage Administrator's Guide for more information about ASMCMD.
Run the following SQL*Plus commands from the computer hosting your database or from any Oracle RAC node as a DBA user or a user with the CREATE ANY DIRECTORY privilege:
SQL> CREATE OR REPLACE DIRECTORY BEEHIVE_DATA_PUMP AS '<Oracle Data Pump data directory>'; SQL> GRANT READ, WRITE ON DIRECTORY beehive_data_pump TO bee_code; SQL> GRANT READ, WRITE ON DIRECTORY beehive_data_pump TO bee_data; SQL> CREATE OR REPLACE DIRECTORY BEEHIVE_DATA_PUMP_LOG AS '<Oracle Data Pump log directory>'; SQL> GRANT READ, WRITE ON DIRECTORY beehive_data_pump_log TO bee_code; SQL> GRANT READ, WRITE ON DIRECTORY beehive_data_pump_log TO bee_data;
bee_code and bee_data are the names of the Oracle Beehive code schema and data schema, respectively. To retrieve the names of these schemas, run the command beectl list_schemas.
Refer to "CREATE DIRECTORY" in Oracle Database SQL Language Reference for more information.
If your Oracle Beehive deployment uses Oracle RAC, then ensure that all your Oracle RAC nodes can access both Oracle Data Pump directories. Follow one of the followings steps to create and specify these directories:
Follow the steps as described in "Defining Oracle Data Pump Directories for Non-Oracle RAC Deployments".
If you are using ASM, then ensure that all your Oracle RAC nodes can access BEEHIVE_DATA_PUMP_LOG.
Use regular file system commands, like mkdir, to create the same directory (you must use the same directory path) on the local disk of each Oracle RAC node.
If you are not using ASM, the Oracle Beehive patch requires the connect string of the database instance that is hosted on the computer that contains the Oracle Data Pump directories. In this connect string, use the INSTANCE_NAME parameter to specify which database instance contains the Oracle Data Pump directories. For example, the following specifies the database instance afserv1 on node host1.example.com:
(DESCRIPTION=
(ADDRESS_LIST=
(ADDRESS=(PROTOCOL=TCP)(HOST=host1.example.com)(PORT=1521)))
(CONNECT_DATA=
(SERVER=DEDICATED)
(SERVICE_NAME=afserv1.example.com)
(INSTANCE_NAME=afserv1))
Refer to the documentation of the Oracle Beehive patch for directions on how to specify the connect string. Refer to "Local Naming Parameters (tnsnames.ora)" in Oracle Database Net Services Reference and "Understanding the Oracle Real Application Clusters Installed Configuration" in Oracle Real Application Clusters Installation Guide for more information about the INSTANCE_NAME parameter.
Create the Oracle Data Pump directories in a Direct Network File System (NFS), then perform step 2 as described in "Defining Oracle Data Pump Directories for Non-Oracle RAC Deployments". Refer to "Configuring Direct NFS Storage for Data Files" in the chapter "Configuring Oracle Real Application Clusters Storage" in Oracle Clusterware Installation Guide for more information.
If you previously upgraded or patched Oracle Beehive, backup and delete Oracle Data Pump data and log files.
ASM Note:
If your Oracle Beehive deployment uses Oracle Database 10g with Oracle Automatic Storage Management (ASM), and you previously created a clone of your deployment, old dump files (from the Data Pump Export utility) are not deleted automatically. You must delete them manually before installing a patch.Use the ASMCMD command-line utility as follows:
ASMCMD> rm +DISKGROUP1/beehive_data_pump_directory/dump_file.dmp
DISKGROUP1 is an existing disk group. beehive_data_pump_directory is the name of your ASM data directory. dump_file.dmp is the name of your dump file.
Refer to "ASM Command-Line Utility" in Oracle Database Storage Administrator's Guide for more information about ASMCMD.
These steps are not required if you are using Oracle Database 11g.
This is a recommended but not mandatory step.
From any application tier, run the following command, preferably several hours before you upgrade Oracle Beehive to allow any existing jobs to completely stop:
beectl modify_property --component _SearchService --name CrawlDocumentsEnabled --value false --activate_configuration
This is a recommended but not mandatory step.
From any application tier, run the following command to disable User Directory Services (UDS) synchronization:
beectl modify_property --component OID_Profile --name ProfileState --value DISABLE --activate_configuration
Shutdown all your Oracle Beehive application tiers by following these steps for each application tier:
Ensure that all Oracle Beehive processes are running with the following command:
beectl start --all
Run the following command repeatedly until the output indicates that all Oracle Beehive processes are running:
beectl status
Stop the application tier with the following command:
beectl stop --all
Note:
Ensuring that all Oracle Beehive processes are running before shutting down the application tier ensures that any processes managed by OPMN remain stopped during upgrade.If a computer goes down while OPMN is running, upon restart, OPMN will attempt to automatically restart all processes that were running at the time the system went down.
Consequently, upgrading an Oracle Beehive application tier that was shutdown unexpectedly (for example, by rebooting the computer without first shutting down Oracle Beehive) may fail. When the upgrade process starts OPMN, OPMN will attempt to restart any of processes that were running, which in turn will cause the upgrade process to fail.
To upgrade an Oracle Beehive Release 1 deployment, upgrade the following Oracle Beehive products in the indicated order:
Oracle Beehive Release 1. Refer to "Oracle Beehive Upgrade Process Sequence of Screens".
Note:
You must shutdown all Oracle Beehive application tiers as described in "Shutdown All Oracle Beehive Instances" before upgrading them.Ensure that the upgrade process has started your newly upgraded Oracle Beehive application tiers before proceeding to upgrade other Oracle Beehive products.
Refer to "Upgrading Multiple Oracle Beehive Application Tiers" if you are upgrading more than one Oracle Beehive application tier.
User directory data. Follow the steps described in "Upgrading User Directory Data".
Any standalone Oracle Beehive Integration for Zimbra, Oracle Beehive Provisioning Application, or Oracle Collaboration Coexistence Gateway (Windows only).
Any Oracle Beehive for DMZ instances. Refer to "Oracle Beehive for DMZ Upgrade Process Sequence of Screens".
Note:
You must shutdown all Oracle Beehive for DMZ instances before upgrading them.Ensure that the upgrade process has started your newly upgraded Oracle Beehive DMZ instances before proceeding to upgrade other Oracle Beehive products.
Any Oracle Beekeeper Release instances. Refer to "Upgrading Oracle Beekeeper Version 1.4.3".
Note:
Before upgrading Oracle Beekeeper, refer to the section "Upgrading Oracle Beekeeper Version 1.4.3 to Version 1.5".Refer to "Upgrading Oracle Beehive Release 1 (1.4.3)" for information about upgrading Oracle Beehive products.
Refer to "Upgrading Oracle Beehive in Silent Mode" in "Installing Oracle Beehive in Silent Mode (Non-Interactive)" for more information about upgrading Oracle Beehive products in silent mode.
Follow these steps to upgrade multiple Oracle Beehive application tiers:
Shutdown all your Oracle Beehive application tiers as described in "Shutdown All Oracle Beehive Instances".
Upgrade an Oracle Beehive application tier.
Wait until the upgrade process is complete.
Run the SQL scripts described in "Upgrading User Directory Data".
Upgrade a subsequent Oracle Beehive application tier. Do not start upgrading this tier until the previous tier's upgrade process is complete. You do not have to shutdown any upgraded application tiers.
Repeat step 5 until all application tiers are upgraded.
To upgrade Oracle Beekeeper version 1.4.3 to version 1.5, follow these steps:
If you have configured Oracle Beekeeper for SSL access, follow these steps. Otherwise, proceed to the next step.
These steps involve reconfiguring Oracle Beekeeper for SSL with the default-web-site.xml file:
Copy <Oracle Beekeeper home>/j2ee/home/config/secure-web-site.xml as <Oracle Beekeeper home>/j2ee/home/config/default-web-site.xml (replacing secure-web-site.xml with default-web-site.xml.)
Edit the file <Oracle Beekeeper home>/j2ee/home/config/server.xml and replace secure-web-site.xml with default-web-site.xml.
Restart Oracle Beekeeper with the following commands and verify that SSL is working properly:
<Oracle Beekeeper home>/opmn/bin/opmnctl stopall <Oracle Beekeeper home>/opmn/bin/opmnctl startall
Determine if Oracle Beekeeper is using the database or your LDAP server for authentication. Open the file <Oracle Beekeeper home>/j2ee/home/applications/javasso/jps-config.xml. Search for the element <jpsContexts>. The value of the default attribute may be either ldap or db:
If it is db, then no further action is required; do not proceed with the following steps. Upgrade Oracle Beekeeper version 1.4.3 to Oracle Beekeeper 1.5; refer to "Upgrading Oracle Beekeeper Version 1.4.3".
If it is ldap, then perform steps 3-6.
Save a copy of the following files:
<Oracle Beekeeper version 1.4.3 home>/j2ee/home/application-deployments/javasso/jps-config.xml
<Oracle Beekeeper version 1.4.3 home>/j2ee/home/application-deployments/beehivecontrol/jps-config.xml
Upgrade Oracle Beekeeper version 1.4.3 to version 1.5; refer to "Upgrading Oracle Beekeeper Version 1.4.3".
To configure LDAP-based authentication for your upgraded Oracle Beekeeper version 1.5 instance, modify the following files with the data contained in the files you saved in step 3:
<Oracle Beekeeper version 1.5 home>/j2ee/home/application-deployments/javasso/jps-config.xml
<Oracle Beekeeper version 1.5 home>/j2ee/home/application-deployments/beekeeper/jps-config.xml
Refer to the section "Configuring Oracle Beekeeper for LDAP-Based Authentication" in "Oracle Beekeeper Post-Installation Procedures" for more information about which attribute values you must modify in these files to configure LDAP-based authentication.
Restart the Oracle Beekeeper unmanaged OC4J instance with the following commands:
<Oracle Beekeeper home>/opmn/bin/opmnctl stopall <Oracle Beekeeper home>/opmn/bin/opmnctl startall
Depending on your Oracle Beehive deployment, follow the steps described in these sections after you have upgraded Oracle Beehive:
After upgrading Oracle Beehive Release 1 (1.4.3) to Oracle Beehive Release 1 (1.5), upgrade user directory data by running the following scripts as the BEE_CODE user in the specified order. You do not need to shut down Oracle Beehive to run these scripts:
<Oracle Beehive home>/beehive/tmp/patch/7387847/db/update_display_names.sql
<Oracle Beehive home>/beehive/tmp/patch/7387847/db/update_default_email_address.sql
<Oracle Beehive home>/beehive/tmp/patch/7387847/db/delete_dangling_contacts.sql
It is highly recommended that you apply a deployment template to your upgraded Oracle Beehive Release 1 (1.5) deployment provided that it is not already applied; the upgrade process does not automatically do this for you. Note that a new Oracle Beehive Release 1 (1.5) installation already has a deployment template associated with it.
A deployment template is an XML file that represents the formally defined structure of an Oracle Beehive application tier and its components such as OC4J instances, services, Oracle Beehive Transport Infrastructure (BTI), and the HTTP server.
If your upgraded Oracle Beehive Release 1 (1.4) deployment does not have a deployment template associated with it, those beectl commands that change the deployment structure (such as those that add and delete OC4J and service instances) will succeed. However, you will receive a message indicating that you should apply a deployment template.
In addition, future upgrades (for example, from Oracle Beehive Release 1 (1.5) to Oracle Beehive Release 1 (1.6)) will fail if your deployment does not have a deployment template associated with it.
Follow these steps to apply a deployment template to an Oracle Beehive deployment:
Retrieve a list of available deployment templates with the command beectl list_deployment_templates. This command will output the identifier of each deployment template and a short description.
Select an appropriate deployment template and apply it with the beectl modify_deployment_structure. The following example applies the deployment template SERVER_AND_CLIENT to the local Oracle Beehive application tier:
modify_deployment_structure --primary_template SERVER_AND_CLIENT
Note:
Any customizations to the deployment structure (such as extra OC4J or service instances) or start/stop parameters (such as the maximum heap size of an OC4J instance) will be lost when you apply a deployment template with the commandbeectl modify_deployment_structure. The deployment template specified by this command will overwrite any customizations in your Oracle Beehive deployment.Run the script <Oracle Beehive home>/beehive/db/post_upgrade_db_actions.pl only if the following conditions are true:
You are applying a patch to Oracle Beehive Release 1 (1.5.1.1.0) or later
The patch you are applying involves schema cloning.
Run the script post_upgrade_db_actions.pl as follows:
perl post_upgrade_db_actions.pl <BEE_DATA> <OLD_BEE_CODE> <NEW_BEE_CODE> <BEE_CODE_PASSWORD> <CONNECT_STRING>
<BEE_DATA>: Name of the Oracle Beehive data schema
<OLD_BEE_CODE>: Name of the old Oracle Beehive code schema
<NEW_BEE_CODE>: Name of the cloned and upgraded Oracle Beehive code schema
<BEE_CODE_PASSWORD>: Password for the Oracle Beehive schemas (all Oracle Beehive schemas have the same password)
<CONNECT_STRING>: Oracle Beehive database connect string
To retrieve the names of these schemas, run the following command:
beectl list_schemas --schema_type <schema type> --status <schema status> --sort_by <sort condition>
<schema type>: Type of schema to retrieve; it may have one of the following values:
1: Code schema
2: Data schema
3: Search-related Change Data Capture publisher (CDCPUB) schema
<schema status>: Status of the schema. For purposes of running the script post_upgrade_db_actions.pl, you use only statuses 4, 5, and 6:
1: Created; the code schema has been newly created
2: Upgrade ready; the code schema has been cloned and is ready to be upgraded
3: Activation ready; the code schema has been upgraded and is ready to be activated
4: Active; the schema is active
5: Legacy; the original schema that was cloned is set to this status. During a multi-application tier upgrade, application tiers that have not been upgraded will use this schema.
6: Deactivated; when all application tiers have been upgraded, the original schema is set to this status
7: Deinstalled; the schema has been deinstalled
Running beectl list_schemas without any options lists all schemas.
Examples
The following examples show you how to retrieve the names of schemas required for the post_upgrade_db_actions.pl script.
The following example lists all data schemas:
beectl list_schemas --schema_type 2 schema_name: BEE_DATA schema_id: 131 version_id: 1.5.1.0.0 schema_type: 2 status: 4 creation_time: 2009-05-02 11:29:54.0 activation_time: 2009-05-02 11:29:54.0 description: BEE_DATA schema
The following example lists all code schemas:
beectl list_schemas --schema_type 1 schema_name: BEE_CODE schema_id: 132 version_id: 1.5.1.1.0 schema_type: 1 status: 6 creation_time: 2009-05-02 11:29:54.0 activation_time: 2009-05-02 11:29:54.0 legacy_time: 2009-05-04 09:30:07.0 deactivation_time: 2009-05-04 10:14:57.0 description: BEE_CODE schema schema_name: BEE_CODE_05042009 schema_id: 134 version_id: 1.5.1.1.0 schema_type: 1 status: 6 creation_time: 2009-05-04 09:00:30.0 activationready_time: 2009-05-04 09:29:20.0 upgradeready_time: 2009-05-04 09:28:43.0 activation_time: 2009-05-04 09:30:07.0 legacy_time: 2009-05-04 13:11:42.0 deactivation_time: 2009-05-11 12:06:02.0 description: insert description here schema_name: BEE_CODE_05042009_1 schema_id: 135 version_id: 1.5.1.1.0 schema_type: 1 status: 4 creation_time: 2009-05-04 12:26:03.0 activationready_time: 2009-05-04 12:52:50.0 activation_time: 2009-05-04 13:11:42.0 description: insert description here schema_name: BEE_CODE_05112009 schema_id: 136 version_id: 1.5.1.1.0 schema_type: 1 status: 2 creation_time: 2009-05-11 12:13:43.0 upgradeready_time: 2009-05-11 12:48:14.0 description: insert description here
The following example lists the active code schema. At the end of an upgrade involving schema cloning, the active code schema should be the cloned schema:
beectl list_schemas --schema_type 1 --status 4 schema_name: BEE_CODE_05042009_1 schema_id: 135 version_id: 1.5.1.1.0 schema_type: 1 status: 4 creation_time: 2009-05-04 12:26:03.0 activationready_time: 2009-05-04 12:52:50.0 activation_time: 2009-05-04 13:11:42.0 description: insert description here
The following example lists all code schemas that are marked "LEGACY" and the sorts them by the time they were marked this status. The newest schema in this list is the old code schema:
beectl list_schemas --schema_type 1 --status 5 --sort_by LEGACY_TIME
The following example lists call deactivated code schemas. After running the post_upgrade_db_actions.pl script, the old code schema will be marked as deactivated.
beectl list_schemas --schema_type 1 --status 6
It is highly recommended that you apply a deployment template to your upgraded Oracle Beehive Release 1 (1.5) deployment provided that it is not already applied; the upgrade process does not automatically do this for you. Note that a new Oracle Beehive Release 1 (1.5) installation already has a deployment template associated with it.
A deployment template is an XML file that represents the formally defined structure of an Oracle Beehive application tier and its components such as OC4J instances, services, Oracle Beehive Transport Infrastructure (BTI), and the HTTP server.
If your upgraded Oracle Beehive Release 1 (1.4) deployment does not have a deployment template associated with it, those beectl commands that change the deployment structure (such as those that add and delete OC4J and service instances) will succeed. However, you will receive a message indicating that you should apply a deployment template.
In addition, future upgrades (for example, from Oracle Beehive Release 1 (1.5) to Oracle Beehive Release 1 (1.6)) will fail if your deployment does not have a deployment template associated with it.
Follow these steps to apply a deployment template to an Oracle Beehive deployment:
Retrieve a list of available deployment templates with the command beectl list_deployment_templates. This command will output the identifier of each deployment template and a short description.
Select an appropriate deployment template and apply it with the beectl modify_deployment_structure. The following example applies the deployment template SERVER_AND_CLIENT to the local Oracle Beehive application tier:
modify_deployment_structure --primary_template SERVER_AND_CLIENT
Note:
Any customizations to the deployment structure (such as extra OC4J or service instances) or start/stop parameters (such as the maximum heap size of an OC4J instance) will be lost when you apply a deployment template with the commandbeectl modify_deployment_structure. The deployment template specified by this command will overwrite any customizations in your Oracle Beehive deployment.After upgrading to Oracle Beehive Release 1 (1.5) and before your users access your upgrade Oracle Beehive deployment, you must gather statistics about the BEE_DATA and BEE_CODE schemas. Otherwise, you may experience serious performance degradation or service interruptions.
Run the following SQL*Plus commands as the SYS user to gather statistics about the Oracle Beehive data and code schemas:
SQL> exec DBMS_STATS.GATHER_SCHEMA_STATS('BEE_DATA'); SQL> exec DBMS_STATS.GATHER_SCHEMA_STATS('<CLONED_CODE_SCHEMA>');
BEE_DATA is the name of the Oracle Beehive data schema. <CLONED_CODE_SCHEMA> is the name of the code schema of your upgraded Oracle Beehive instance. To retrieve the name of the code schema for your upgraded Oracle Beehive instance, run the beectl list_schemas command as follows:
beectl list_schemas --schema_type 1 --schema_status 4 schema_name: BEE_CODE_05042009_1 schema_id: 135 version_id: 1.5.1.1.0 schema_type: 1 status: 4 creation_time: 2009-05-04 12:26:03.0 activationready_time: 2009-05-04 12:52:50.0 activation_time: 2009-05-04 13:11:42.0 description: insert description here
Refer to "Running Perl Script post_upgrade_db_actions.pl" for more information about the beectl list_schemas command.
Refer to "Gathering Statistics with DBMS_STATS Procedures" in the chapter "Managing Optimized Statistics" in Oracle Database Performance Tuning Guide for more information.
After you have upgraded Oracle Beehive from an earlier version to version 1.4, you must re-create your voicemail facilities using the new method, and remove facilities that you created in earlier version with the beectl add_config_object command.
You can list facilities and groups created using the earlier method by using the following command (from the operating system shell, so you can make use of the grep utility):
beectl list_components | grep -i voice
Locate all the voice components defined with a voicemail DNIS alias. Then, check which group is associated to each voicemail DNIS by using the beectl list_properties command:
beectl list_properties --component <voicemail DNIS>
Run this command for each identified component, and make a note of the group associated with each voicemail DNIS.
Once you have this information, you can assign the groups and phone numbers using the new facility configuration method, by using the new beectl add_voice_facility command. The following example demonstrates briefly how to use the command:
beectl add_voice_facility
--group_collabid <GROUP_COLLAB_ID>
--include "18885551111|18885552???"
--exclude "188855529??"
See Also:
For complete information on creating voicemail facilities in Oracle Beehive Release 1 (1.4) and later, see "Managing Oracle Beehive Voicemail and Fax" in the Oracle Beehive Administrator's Guide.The --include statement associates phone number 18885551111 and phone number range 18885552000-18885552999.
The --exclude statement associates the phone number range 18885552900-18885552999 not to be included in the broader include range.
The value of --group_collabid is a the CollabID of a group. You can find this value for any group by using the beectl list_groups command with the global option --entity_format id:
beectl list_groups --group <group identifier> --show ALL --entity_format id
Use this command with the group that was defined for voicemail. If you followed the upgrade procedure described earlier to gather all the information, then the value for the <GROUP_COLLAB_ID> was listed when you used the beectl list_properties command.
If you have changed the permissions of hasbind as described in the section "Changing Other Ports" in "Upgrading Oracle Beehive Overview", then you must change the permissions of hasbind again after you have upgraded Oracle Beehive.
If you disabled document crawling for search as described in "Disable Document Crawling for Search", run the following command from any application tier to enable it:
beectl modify_property --component SearchService --name CrawlDocumentsEnabled --value True
If you disabled UDS synchronization as described in "Disable User Directory Services Synchronization", run the following command from any application tier to enable it:
beectl modify_property --component OID_Profile --name ProfileState --value ENABLE
|
 Copyright © 2008, 2009, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|