| Oracle® Beehive Installation Guide Release 2 (2.0.1.8) for Linux x86 Part Number E16641-07 |
|
|
PDF · Mobi · ePub |
| Oracle® Beehive Installation Guide Release 2 (2.0.1.8) for Linux x86 Part Number E16641-07 |
|
|
PDF · Mobi · ePub |
This chapter describes steps to perform before upgrading your Oracle Beehive deployment to Oracle Beehive Release 2 (2.0), the order in which you should upgrade Oracle Beehive products, and other procedures to perform after upgrading.
This section covers the following topics:
Oracle Beehive 2.0.1.8.0 is available as upgrade, using the Oracle Universal Installer; or, as the 2.0.1.8.0 Cumulative Patch Set, which applies updates to pre-existing version installation as shown in the Table 11-1, "Oracle Beehive Upgrade Options for 2.0.1.8.0".
For information about installing the 2.0.1.8.0 Cumulative Patch Set, refer to the Oracle Beehive 2.0.1.8.0 Cumulative Patch Set Readme at the following location:
http://www.oracle.com/pls/bee2/homepage
For the full install/upgrade, you can use the Oracle Beehive Installation Guide Release 2.0 for your platform, as well as the installer integrated help.
The following table shows the possible upgrade and patch options that are available:
Table 11-1 Oracle Beehive Upgrade Options for 2.0.1.8.0
| Your current Oracle Beehive deployed version | Upgrade path option(s) |
|---|---|
|
1.5.1.0.0, 1.5.1.2.0, 1.5.1.3.0, 1.5.1.4.0 |
|
|
1.5.1.5.0, 1.5.1.5.1, or 1.5.1.5.2 |
|
|
2.0.1.0.0, 2.0.1.1.0, 2.0.1.2.0, 2.0.1.2.1, 2.0.1.3.0, 2.0.1.4.0, 2.0.1.5.0, 2.0.1.6, and 2.0.1.7 |
Apply 2.0.1.8.0 Cumulative Patch Set. |
Note:
You can determine your Oracle Beehive version number by running the beectl version command from any Oracle Beehive Oracle home.Perform or ensure the following before upgrading to Oracle Beehive Release 2 (2.0):
If your Oracle Beehive deployment uses an Oracle Database version earlier than 11.1.0.7, then upgrade it to a version that Oracle Beehive Release 2 (2.0) supports. Refer to "Oracle Beehive Database Requirements" for more information.
Ensure that the passwords for the active Code and Data schemas are the same. If not, change the 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. After that, 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.5.x) to Oracle Beehive Release 2 (2.0), 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.5.x) application tiers, follow the steps described in My Oracle Support 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.5.x) 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.5.x) 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.5.x) to Oracle Beehive Release 2 (2.0), export configuration data of your Oracle Beehive Release 1 (1.5.x) 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 2 (2.0) 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.
Depending on which version and where you installed Oracle Beehive Integration for Zimbra, follow the steps in these sections:
Upgrading Oracle Beehive Release 1 (1.5.x) with Oracle Beehive Integration for Zimbra Version 1.5.x
Upgrading Previously Upgraded Oracle Beehive Integration for Zimbra Instance
If you are upgrading Oracle Beehive Release 1 (1.5.x) with Oracle Beehive Integration for Zimbra version 1.5.x registered in the same Oracle Inventory location, follow these steps before upgrading Oracle Beehive and Oracle Beekeeper to version 2.0. (Note that these steps still apply if you previously upgraded your Oracle Beehive or Oracle Beehive Integration for Zimbra instances to version 1.5.x):
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 line that begins with InstallType= and perform one of the following actions depending on your Oracle Beehive deployment:
If you chose the Basic Server or Basic Server and Client template when installing Oracle Beehive (only Oracle Beehive or Oracle Beehive and Oracle Beehive Integration for Zimbra reside in the computer), ensure the line is InstallType=Beehive.
If you chose the Client Only template when installing Oracle Beehive, ensure the line is InstallType=Client.
Perform any other required tasks before upgrading Oracle Beehive as described in this module, then upgrade Oracle Beehive to version 2.0.
After upgrading Oracle Beehive to version 2.0 but before upgrading Oracle Beehive Integration for Zimbra to version 2.0, 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 2.0.
If you are upgrading Oracle Beehive Integration for Zimbra version 1.5.x to version 2.0, perform the following steps before upgrading:
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();
Note:
This section only applies to patches for Oracle Beehive Release 2 (2.0).Oracle Beehive Release 2 (2.0) comes with Zero Downtime Upgrade (ZDU), which minimizes the amount of downtime required for upgrading or applying patches to Oracle Beehive.
After upgrading to Oracle Beehive Release 2 (2.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.
Note:
If your environment uses the OCFS2 file system, and that file system is shared between all Oracle RAC nodes, then follow the steps described in "Defining Oracle Data Pump Directories for Non-Oracle RAC Deployments". Ensure that you create the Oracle Data Pump data and log directories in the same OCFS2 file system that your Oracle RAC nodes can access.You do not need a special connection string as described in the following steps for Oracle RAC deployments since all Oracle RAC nodes can access the data and log directories in an OCFS2 file system.
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 Linux and UNIX 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".
If you previously upgraded or patched Oracle Beehive, backup and delete Oracle Data Pump data and log files.
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
Shut down 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 shut down 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 deployment, upgrade the following Oracle Beehive products in the indicated order:
Oracle Beehive. Refer to "Oracle Beehive Upgrade Process Sequence of Screens".
Note:
You must shut down all Oracle Beehive application tiers as described in "Shut down 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.
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 shut down 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".
Note:
Before upgrading Oracle Beekeeper, refer to the section "Upgrading Oracle Beekeeper Version 1.5.x to Version 2.0".Refer to "Upgrading Oracle Beehive" 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:
Shut down all your Oracle Beehive application tiers as described in "Shut down All Oracle Beehive Instances".
Upgrade an Oracle Beehive application tier.
Wait until the upgrade process is complete.
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 shut down any upgraded application tiers.
Repeat step 4 until all application tiers are upgraded.
To upgrade Oracle Beekeeper version 1.5.x to version 2.0, 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 default-web-site.xml with secure-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.5.x to Oracle Beekeeper 2.0; refer to "Upgrading Oracle Beekeeper".
If it is ldap, then perform steps 3-6.
Save a copy of the following files:
<Oracle Beekeeper version 1.5 home>/j2ee/home/application-deployments/javasso/jps-config.xml
<Oracle Beekeeper version 1.5 home>/j2ee/home/application-deployments/beehivecontrol/jps-config.xml
Upgrade Oracle Beekeeper version 1.5.x to version 2.0; refer to "Upgrading Oracle Beekeeper".
To configure LDAP-based authentication for your upgraded Oracle Beekeeper version 2.0 instance, modify the following files with the data contained in the files you saved in step 3:
<Oracle Beekeeper version 2.0 home>/j2ee/home/application-deployments/javasso/jps-config.xml
<Oracle Beekeeper version 2.0 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
The following topics are covered in this section:
Gathering Statistics About Oracle Beehive Data and Code Schemas After Upgrading
Upgrading Mobile Device Management Service After Oracle Beehive Upgrade
Note:
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 2 (2.0) or later.
The patch you are applying involves schema cloning.
In particular, run this script if you did not specify the option -no_schema_cloning when you applied the patch.
The -no_schema_cloning option of the opatch command line tool enables you to apply a patch without schema cloning, which may potentially reduce the time required to apply the patch. Only use this option if you can fully shut down processes in all your Oracle Beehive application tiers, including Oracle Beekeeper instances. Note that this option is not recommended because it disables ZDU.
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
Note:
The database connect string cannot contain any new line characters (\n, \r, or \n\r); the connect string must be a single-line value.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.
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: 2.0.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: 2.0.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: 2.0.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: 2.0.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: 2.0.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: 2.0.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 2 (2.0) 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 2 (2.0) 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 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 customization 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 customization in your Oracle Beehive deployment.After upgrading to Oracle Beehive Release 2 (2.0) and before your users access your upgrade Oracle Beehive deployment, you must gather statistics about the Oracle Beehive data and code schemas. Otherwise, you may experience serious performance degradation or service interruptions.
This section contains the following topics:
Refer to "Gathering Statistics with DBMS_STATS Procedures" in the chapter "Managing Optimized Statistics" in Oracle Database Performance Tuning Guide for more information.
Run the following SQL*Plus command as the SYS user to gather statistics about the Oracle Beehive data schema:
SQL> exec DBMS_STATS.GATHER_SCHEMA_STATS('BEE_DATA');
BEE_DATA is the name of the Oracle Beehive data schema.
Run the following SQL*Plus commands as the SYS user to gather statistics about the Oracle Beehive code schema:
SQL> exec DBMS_STATS.GATHER_SCHEMA_STATS('<CODE_SCHEMA>');
<CODE_SCHEMA> is the name of the code schema user. To retrieve the name of the code schema, run the beectl list_schemas command as follows:
beectl list_schemas --schema_type 1 --status 4 schema_name: BEE_CODE_05042009_1 schema_id: 135 version_id: 2.0.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.
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, 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 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.
Note:
If you upgrading from 1.5.x to 2.0.x, comment out the vm_purge.sql before executing the script vm_seed.sql.Note:
This section only applies to patches for Oracle Beehive Release 2 (2.0).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 --activate_configuration
After upgrading Oracle Beehive to version 2.0, run the following SQL scripts:
Note:
The system should not be made accessible to users until all the following scripts have been completed successfully.Run the following script as the code schema user of your upgraded Oracle Beehive instance.
Select count(*) from user_scheduler_jobs where job_name like 'PATCH_UDS_CON_GUARD_UPD_%';
To retrieve the name of the code schema, refer to "Gathering Statistics About Oracle Beehive Code Schema". If you see a count greater than 0, this means that the contact sensitivity upgrade process is still running. Rerun this script to check if the contact sensitivity fixing dbms jobs have completed. If you see a count equal to 0, this means that the contact sensitivity upgrade process is over. Please execute the next script.
Run the following SQL as the code schema user of your upgraded Oracle Beehive instance.
Select job_name, status, additional_info from user_scheduler_job_run_details where job_name like 'PATCH_UDS_CON_GUARD_UPD_%';
If the status of any of the job is not 'SUCCEEDED', that means the contact sensitivity fixing dbms jobs have not successfully completed. Please contact support. If the status for all the jobs is 'SUCCEEDED', it means that the contact sensitivity fixing dbms jobs have successfully completed. Please execute the next script.
Apply the patch for defect 9854302 before proceeding to the next step. If this patch is not applied, then the post upgrade step may delete E-mail preferences which may result in users losing their Zimbra e-mail preferences.
Run the following script as the BEE_DATA user, which is the name of the Oracle Beehive data schema.
<Oracle Beehive home>/beehive/tmp/patch/7685703/db/uds_post_upgrade_data.sql;
Run this script only after the previous script has been successfully executed. On successful execution of this script, run the next script.
Run this script as the code schema user of your upgraded Oracle Beehive instance:
<Oracle Beehive home>/beehive/tmp/patch/7685703/db/uds_post_upgrade_seed.sql;
If you see the message "Contact sensitivity fixing dbms jobs are running. Please execute the script after some time" this means that the contact sensitivity upgrade process is still running. Rerun the script at a later time. Run this script only after the previous scripts have been successfully completed.
This script will start a job to cleanup entries. You can now proceed with the execution of the subsequent steps. However no further patch should be applied till the clean job has been completed.
To check the status of the job, run the following query:
SQL> SELECT COUNT(*) FROM user_scheduler_jobs WHERE job_name LIKE 'PATCH_UDS_POST_UPG_2_0_JOB%';
Run this script as the code schema user of your upgraded Oracle Beehive instance. If you see a count greater then 0, this means that the cleanup process is still running. No further patches should be applied. Rerun this script at a later time to check if the cleanup dbms jobs have completed. If you see a count equal to 0, it means that the cleanup dbms job is over.
Execute the next script.
SQL> SELECT job_name, status, additional_info FROM user_scheduler_job_run_details WHERE job_name LIKE 'PATCH_UDS_POST_UPG_2_0_JOB%';
Run this script as the code schema user of your upgraded Oracle Beehive instance. If the status of the job is not 'SUCCEEDED', it means that the cleanup dbms job has not successfully completed.
If the status for all the jobs is 'SUCCEEDED', it means that the cleanup dbms jobs have successfully completed.
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 configured Oracle Application Server Single Sign-On for your Oracle Beehive Release 1 (1.5.x) deployment, and you upgraded it to Oracle Beehive Release 2 (2.0), follow these steps to upgrade the Mobile Device Management Service:
List all service instances of type MobileDmServiceInstance:
beectl list_components --type MobileDmServiceInstance -------------------------+-------------------------------------------------- Component type | Component identifier -------------------------+-------------------------------------------------- MobileDmServiceInstance | <instance_####1> MobileDmServiceInstance | <instance_####2> -------------------------+--------------------------------------------------
Upgrade each service instance of type MobileDmServiceInstance. For example:
beectl> upgrade_service_instance --service_instance_id <instance_####1> beectl> upgrade_service_instance --service_instance_id <instance_####2>
Restart all BEEAPP and HTTP_Server components:
beectl status -------------------------------+----------------+-------- Component identifier | Component type | Status -------------------------------+----------------+-------- BTI_instance1.example.com | BTI | RUNNING -------------------------------+----------------+-------- BEEAPP_instance1.example.com | ManagedOc4j | RUNNING -------------------------------+----------------+-------- BEEMGMT_instance1.example.com | ManagedOc4j | RUNNING -------------------------------+----------------+-------- BEECORE_instance1.example.com | ManagedOc4j | RUNNING -------------------------------+----------------+-------- oc4j_soa_instance1.example.com | ManagedOc4j | RUNNING ------------------------------------------------+-------- ohs_instance1.example.com | HttpServer | RUNNING -------------------------------+----------------+-------- beectl restart --component BEEAPP_instance1.example.com beectl restart --component ohs_instance1.example.com
Clone patching is an alternative way to upgrade an Oracle Beehive application tier. It involves cloning an already upgraded application tier, then replacing an old application tier with the clone. Clone patching is recommended if you have many application tiers to upgrade.
Refer to "Oracle Beehive By Clone Patching" for more information.
After upgrading to Beehive versions later than 2.0, use the following steps to identify and create batches for use with the add_search_recovery_scope command to build a new search index.
Recovery with the add_search_recovery_scope command should be run during off-hours and with limited sets of data. Ensure that recovery is not being done when there is a scheduled service bounce as having BEEAPP bounce while running recovery will cause recovery to hang. Ensure that there is no loss of connectivity to the database and recovery is not run during scheduled maintenance.
The add_search_recovery_scope command only needs to be run to index old content. New e-mails and new/modified calendar events will automatically be indexed if the CaptureChanges value is set to true for the _SearchService component. This can be verified with the following command:
beectl list_properties --component _SearchService --name CaptureChanges
and, if found to be false, can be set back to true with the following command:
beectl modify_property --component _SearchService --name CaptureChanges --value true --activate_configuration
Follow the instructions below to separate workspaces into batches, recover the workspaces in each batch, and check statuses:
Getting workspaces:
beectl list_workspaces --scope enpr=EnterpriseName --recurse --entity_format id --format tiled --countLimit 100000
The above command returns an entry for each workspace with the following data:
Name of workspace| type of workspace | Workspace ID | Enterprise ID
For example:
test2|TEAM|0B69:7BD3:wstm:6F933CCBA840488E9C3BCE8318260F1F000000000010|0B69:7BD3:enpr:82170304C0F3F514E040940A832C31CD000000018895|user1.test's Personal Workspace|PERSONAL|0B69:7BD3:wspr:9027544241E4497EA90D8F7DBD5896D5000000000001|0B69:7BD3:enpr:82170304C0F3F514E040940A832C31CD000000018895|
Column 3 contains the workspace collab IDs to be used in the next step.
Compiling beectl commands to recover workspaces:
From output of step 1, create a file called batch.txt to contain the add_search_recovery_scope command defined for the workspaces and date range as shown in the following example. The number of workspaces and/or date range will depend on the average content size of your workspaces, the batch size can be modified. The recommended batch size is 10,000 - 20,000 items, it is further recommended that no more than 50,000 items are submitted and/or are processed at any given time.
add_search_recovery_scope --scope 0B69:7BD3:wstm:6F933CCBA840488E9C3BCE8318260F1F000000000010 --start_date 2009-03-01T00:00:00 --end_date 2010-10-31T00:00:00
add_search_recovery_scope --scope 0B69:7BD3:wspr:9027544241E4497EA90D8F7DBD5896D5000000000001 --start_date 2009-03-01T00:00:00 --end_date 2010-10-31T00:00:00
Note:
Ifstart_date and end_date are not specified, by default only past 30 days content will be recovered.Running recovery commands: The command will recover the workspaces in the batch file.
beectl --batchfile batch.txt
For example:
*******************************************************************************Batch file execution outputBatch file name : /home/test1/batch.txtExecution time : 10/6/10 7:51 AM*******************************************************************************Command number : 1Command line : add_search_recovery_scope --scope 0B69:7BD3:wstm:6F933CCBA840488E9C3BCE8318260F1F000000000010Command output is shown below :Search index recovery started. Please use the following beectl command to monitor its progress.list_operation_statuses --operation_status 12A6:2F23:opst:91BB7AE87FEDE688E040E80A5E4B368900000004E1BACommand exit code : 0###############################################################################Command number : 2Command line : add_search_recovery_scope --scope 0B69:7BD3:wspr:9027544241E4497EA90D8F7DBD5896D5000000000001Command output is shown below :Search index recovery started. Please use the following beectl command to monitor its progress.list_operation_statuses --operation_status 12A6:2F23:opst:91BB7AE87FEDE688E040E80A5E4B368900000004E24BCommand exit code : 0
Monitoring operation status:
Use list_operation_statuses to monitor each recovery submission (as in step 3).Similarly, monitoring operation status can be done in a batch as follows. Create batch_status.txt to contain the list_operations_statuses commands:
list_operation_statuses --operation_status 12A6:2F23:opst:91BB7AE87FEDE688E040E80A5E4B368900000004E1BA --format tiled
list_operation_statuses --operation_status 12A6:2F23:opst:91BB7AE87FEDE688E040E80A5E4B368900000004E24B --format tiled
Then run the following command to check the statuses:
beectl --batchfile batch_status.txt
If certain workspace recovery status is not completed and is not changing for a long time, record those workspaces and continue.
Monitoring database
The add_search_recovery_scope command adds feeds to the database. After a while the number of feeds should be stable. Some database jobs consume feeds to produce crawled entities. When is_indexed is 1, the entry is indexed.
The following two methods can be used to check feeds and crawled entities:
use ss_utils_pkg
login to database as active BEE_CODE user (BEE_CODE_XXXX):
set serveroutput on;declarebeginss_utils_pkg.searchstate();end;/
query ss_feeds, and ss_crawled_entities directly
login to the database as active BEE_CODE user (BEE_CODE_XXXX):
SQL> select count(*) from ss_feeds;
this will tell the number of feeds. The value should be stable.
SQL> select count(*) from ss_crawled_entities where is_indexed in (0, -1, 2);
this will tell the number of crawled entities under indexing.
Wait for a while until both the numbers of feeds and of ss_crawled_entities are stable before handling the next batch.
Continue from step 2 to handle the next batch.
|
 Copyright © 2008, 2013, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|