Oracle® Fusion Applications Enterprise Deployment Guide 11g Release 1 (11.1.1.5) Part Number E16684-02 |
|
|
View PDF |
This chapter describes some operations that you can perform after you have set up the topology, including monitoring, scaling, and backing up your topology.
This chapter includes the following topics:
Note:
For Oracle Universal Content Management scale out only, use the procedure described in Section 8.4, "Scaling Out Oracle Universal Content Management."You can scale out and or scale up the enterprise topology. When you scale up the topology, you add new managed servers to nodes that are already running on one or more managed servers. When you scale out the topology, you add new managed servers to new nodes.
This section includes the topics:
When scaling out the topology, you add new managed servers configured to new nodes.
Note:
The steps provided in this section also can be used to scale out additional hosts, such asCRMHOST4
, CRMHOST5
, and so on.Before you begin, ensure the following:
Node Manager has been started in the Secure Sockets Layer (SSL) mode by following the instructions in Chapter 6, "Configuring Node Manager"
You are starting with a clean machine if it is the first time it is being used for a scale out
The /etc/hosts
file has proper entries. To verify, ping this machine with the fully qualified name of the machine
The user created on CRMHOST3
should the same as the user on CRMHOST1
The directory structure /u01/oracle
is mounted to same shared file system as CRMHOST1
The directory structure /u02/local/oracle/config
on CRMHOST3
has been created
The initial Oracle Fusion Customer Relationship Management deployment on CRMHOST1
has already been done and verified by provisioning
To add a new machine:
Log in to the Administration Server: http://
commoninternal
.mycompany.com:7777/console
.
Navigate to CommonDomain > Environment > Machines.
LocalMachine is located in the right-hand pane.
In the left-hand pane, click Lock & Edit.
In the right-hand pane, first click New to add the remote machine, and then specify the following:
Name - enter CRMHOST3
Machine operating system - Unix
Click Next.
In the window that opens, set the following attributes:
Type - SSL
Listen Address - <CRMHOST3
>
Note:
The "localhost" default value here is wrong.Listen port - 5556
Click Finish and activate the changes.
Note:
If you get an error when activating the changes, see Section 18.8.18, "Administration Console Redirects from Internal URL to Container URL after Activation" for the temporary solution.Since the CRMHOST1
domain directory file system is also available from CRMHOST3
, both the pack
and unpack
commands can be executed from the CRMHOST3
.
Do the following:
Change directory to ORACLE_BASE
/products/fusionapps/oracle_common/common/bin
.
Run the pack
command. For CommonDomain
, for example:
CRMHOST3> ./pack.sh -managed=true -domain=ORACLE_BASE/config/domains/ CRMHOST1/CommonDomain -template=ORACLE_BASE/user_templates/ CommonDomain_managed.jar -template_name="Common_Managed_Server_Domain"
Ensure that /u02/local/oracle/config/domains/
CRMHOST3/CommonDomain
is empty, and then run the unpack
command:
CRMHOST3> ./unpack.sh -domain=/u02/local/oracle/config/domains/ CRMHOST3/CommonDomain -template=ORACLE_BASE/user_templates/ CommonDomain_managed.jar
Here, ORACLE_BASE
is shared, and /u02/local
is local to CRMHOST3
.
To add a managed server and assign it to CRMHOST3
:
Log in to the Administration Server: http://
commoninternal
.mycompany.com:7777/console
.
Navigate to CommonDomain > Environment > Servers.
Switch to Lock & Edit mode.
Select the Managed_Servers checkbox (for example, HomePageServer_1) and then click Clone.
Specify the following Server Identity attributes:
Server Name - HomePageServer_3
Note:
To ensure consistency in naming, copy the name of the server shown in Server Identity and paste it into the Server Name field. Then change the number to "_3"Server Listen Address - <CRMHOST3
>
Server Listen Port - leave "as is"
Click OK.
You now should see the newly cloned server, HomePageServer_3
.
Click HomePageServer_3 and change the following attributes:
Machine - <CRMHOST3
>
Cluster Name - Default, HomePageCluster
Click Save and then Activate Changes.
From the Name column, click the HomePageServer_3 scaled-out server link.
Click Lock & Edit, and then choose the Keystores tab.
Ensure that the keystores value is Custom Identity and Custom Trust.
Do the following:
Change the Custom Identity Keystore path to point to the ORACLE_BASE
/products/fusionapps/wlserver_10.3/server/lib/
CRMHOST3
_fusion_identity.jks
file.
Leave the Custom Identity Keystore type blank.
Change the Custom Identity Keystore Passphrase entry. This should be the same as the keystorepassword field described in the first bullet in Step 4 in Section 6.2, "Creating the Identity Keystore on CRMHOST2."
Re-enter the Confirm Custom Identity Keystore Passphrase.
Ensure that the Confirm Custom Trust Keystore path is pointing to the ORACLE_BASE
/products/fusionapps/wlserver_10.3/server/lib/fusion_trust.jks
file.
Leave the Custom Trust Keystore type blank.
Change the Custom Trust Keystore Passphrase entry. This should be the same as the keystorepassword field described in the first bullet in Step 4 in Section 6.2, "Creating the Identity Keystore on CRMHOST2."
Re-enter the Custom Trust Keystore Passphrase.
Click Save.
Choose the SSL tab.
Make sure that Identity and Trust Locations is set to Keystores.
Change the Private Key Alias to CRMHOST3
_fusion
.
Change the Private Key Passphrase to the keypassword, as described in the second bullet in Step 4 in Section 6.2, "Creating the Identity Keystore on CRMHOST2."
Re-enter the keypassword from Step c for the Confirm Private Key Passphrase.
Click Save.
Click Activate Changes.
Repeat Steps 2 to 14 for all the newly cloned managed servers on this domain.
Set the following environment variable on CRMHOST3
:
WLST_PROPERTIES="-Dweblogic.security.SSL.trustedCAKeyStore=ORACLE_BASE/
products/fusionapps/wlserver_10.3/server/lib/fusion_trust.jks"
Restart the domain's Administration Server:
CRMHOST3> ORACLE_BASE/products/fusionapps/wlserver_10.3/common/bin/wlst.sh CRMHOST3> nmConnect(username='<username>', password='<password>', domainName='CommonDomain', host='CRMHOST1',port='5556', nmType='ssl', domainDir='ORACLE_BASE/config/domains/CRMHOST1/CommonDomain') CRMHOST3> nmStart('AdminServer')
Note:
The username and password used in thenmConnect
are the Node Manager credentials (username and password) specified when creating the provisioning plan. This is shown in Figure 4-3 in "Using the Provisioning Process to Install Components for an Enterprise Deployment".Run the newly created managed server:
Navigate to CommonDomain > Environment > Servers > Control.
Check the newly created managed server and click Start.
Navigate to CommonDomain > Environment > Servers and check the State to verify that the newly created managed servers are running.
Log in to the Administration Server once again (http://
commoninternal
.mycompany.com:7777/console
) and verify that all the managed servers, including scaled-out servers, are running.
Note:
For all the scaled-up and scaled-out servers, change the Arguments in the/u02/local/oracle/config/domains/
HOSTNAME
/
DomainName
/servers/
ManagedServer
/data/nodemanager/startup.properties
file to the following:
Arguments=-DJDBCProgramName\=DS/CommonDomain/HomePageServer_3 -Dserver.group\=HomePageCluster
Note:
For all the scaled-up and scaled-out managed servers, do the following:Access the Oracle WebLogic Server Administration Console for the CommonlDomain:
http://
commoninternal
.mycompany.com:7777/console
Navigate to Environment > Servers and click the "Managed Server" link.
First select the Logging tab and then the HTTP tab.
Update the following parameters:
– Log file name: logs/access.log.%yyyyMMdd%
– Rotation Type: By Time
– Limit number of retained files: leave this option unchecked
– Rotate log file on startup: leave this option unchecked
Click Save.
Expand Advanced Node and set the following:
– Format: Extended
– Extended Logging Format Fields:
date time time-taken cs-method cs-uri sc-status sc(X-ORACLE-DMS-ECID) cs(ECID-Context) cs(Proxy-Remote-User) cs(Proxy-Client-IP)
Click Save and Activate Changes.
Restart the Managed Server for the changes to take affect.
You should verify URLs to ensure that the appropriate routing and failover are working.
To verify the URLs:
Log in to the CommonDomain
Oracle WebLogic Server Administration Console and stop all the managed servers on the CRMHOST1
while the managed servers on CRMHOST3
are running.
Access the following URL to verify that routing and failover are functioning properly. (Ensure the log in prompt is visible.)
https://commonexternal.mycompany.com/homePage/faces/AtkHomePageWelcome
Log in to the CommonDomain
Oracle WebLogic Server Administration Console and stop all the managed servers on CRMHOST3
.
Start the managed servers on CRMHOST1
.
Repeat Step 2. (Ensure the log in prompt is visible.)
Start all the managed servers on CRMHOST3
and verify that they are running on CRMHOST1
.
Before performing the procedures in this section, ensure that CommonDomain
and its managed servers are running.
To add a managed server and assign it to CRMHOST3
:
Log in to the Administration Server: http://
commoninternal
.mycompany.com:7777/console
.
Navigate to CommonDomain > Environment > Servers.
Switch to Lock & Edit mode.
Select the Managed_Servers checkbox (for example, HomePageServer_1) and then click Clone.
Specify the following Server Identity attributes:
Server Name - HomePageServer_4
Note:
To ensure consistency in naming, copy the name of the server shown in Server Identity and paste it into the Server Name field. Then change the number to "_4".Server Listen Address - <CRMHOST3
>
Server Listen Port - leave "Give an unused port on the machine CRMHOST3
"
Click OK.
Navigate back to CommonDomain > Environment > Servers. You now should see the newly cloned server, HomePageServer_4
.
Click HomePageServer_4 and change the following attributes:
Machine - <CRMHOST3
>
Cluster Name - Default, HomePageCluster
From HomePageServer_4, click Advanced and then select the WebLogic Plug-In Enabled checkbox.
Run the newly created managed server:
Navigate to CommonDomain > Environment.
From the Navigation pane on the Oracle WebLogic Server console, select Activate Changes.
Navigate to CommonDomain > Environment > Servers > Control.
Check the newly created managed server and click Start.
Navigate to CommonDomain > Environment > Servers and check the State to verify that the newly created managed servers are running.
Log in to the Administration Server once again (http://
commoninternal
.mycompany.com:7777/console
) and verify that all the managed servers, including scaled-up servers, are running.
Note:
For all the scaled-up and scaled-out servers, change the Arguments in the/u02/local/oracle/config/domains/
HOSTNAME
/
DomainName
/servers/
ManagedServer
/data/nodemanager/startup.properties
file to the following:
Arguments=-DJDBCProgramName\=DS/CommonDomain/HomePageServer_4 -Dserver.group\=HomePageCluster
Note:
For all the scaled-up and scaled-out managed servers, do the following:Access the Oracle WebLogic Server Administration Console for the CommonDomain:
http://
commoninternal
.mycompany.com:7777/console
Navigate to Environment > Servers and click the "Managed Server" link.
First select the Logging tab and then the HTTP tab.
Update the following parameters:
– Log file name: logs/access.log.%yyyyMMdd%
– Rotation Type: By Time
– Limit number of retained files: leave this option unchecked
– Rotate log file on startup: leave this option unchecked
Click Save.
Expand Advanced Node and set the following:
– Format: Extended
– Extended Logging Format Fields:
date time time-taken cs-method cs-uri sc-status sc(X-ORACLE-DMS-ECID) cs(ECID-Context) cs(Proxy-Remote-User) cs(Proxy-Client-IP)
Click Save and Activate Changes.
Restart the Managed Server for the changes to take affect.
You should verify URLs to ensure that the appropriate routing and failover are working.
To verify the URLs:
Log in to the CommonDomain
Oracle WebLogic Server Administration Console and stop the HomePageServer_1
, HomePageServer_2
, and HomePageServer_3
scaled-up managed servers on CRMHOST1
, CRMHOST2
, and CRMHOST3
.
Access the following URL to verify that routing and failover are functioning properly. (Ensure the log in prompt is visible.)
https://commonexternal.mycompany.com/homePage/faces/AtkHomePageWelcome
Log in to the CommonDomain
Oracle WebLogic Server Administration Console and stop the HomePageServer_4
managed server on CRMHOST3
.
Start the HomePageServer_1
managed server on CRMHOST1
.
Repeat Step 2. (Ensure the log in prompt is visible.)
Start all the managed servers on CRMHOST3
and verify that they are running on CRMHOST1
.
When scaling out the topology, you add new managed servers configured to new nodes.
Before you begin, ensure the following:
Node Manager has been started in the Secure Sockets Layer (SSL) mode by following the instructions in Chapter 6, "Configuring Node Manager"
You are starting with a clean machine if it is the first time it is being used for a scale out
The /etc/hosts
file has proper entries. To verify, ping this machine with the fully qualified name of the machine
The user created on CRMHOST3
should the same as the user on CRMHOST1
The directory structure /u01/oracle
is mounted to same shared file system as CRMHOST1
The directory structure /u02/local/oracle/config
on CRMHOST3
has been created
The initial Oracle Fusion Customer Relationship Management deployment on CRMHOST1
has already been done and verified by provisioning
If you have not already added CRMHOST3
, follow these steps:
Log in to the Administration Server: http://
crminternal
.mycompany.com:7777/console
.
Navigate to CRMDomain > Environment > Machines.
LocalMachine is located in the right-hand pane.
In the left-hand pane, click Lock & Edit.
In the right-hand pane, first click New to add the remote machine, and then specify the following:
Name - enter CRMHOST3
Machine operating system - Unix
Click Next.
In the window that opens, set the following attributes:
Type - SSL
Listen Address - <CRMHOST3
>
Note:
The "localhost" default value here is wrong.Listen port - 5556
Click Finish and activate the changes.
Note:
If you get an error when activating the changes, see Section 18.8.18, "Administration Console Redirects from Internal URL to Container URL after Activation" for the temporary solution.Since the CRMHOST1
domain directory file system is also available from CRMHOST3
, both the pack
and unpack
commands can be executed from the CRMHOST3
.
Do the following:
Change directory to ORACLE_BASE
/products/fusionapps/oracle_common/common/bin
.
Run the pack
command. For example, for CRMDomain
:
CRMHOST3> ./pack.sh -managed=true -domain=ORACLE_BASE/config/domains/ CRMHOST1/CRMDomain -template=ORACLE_BASE/user_templates/ CRMDomain_managed.jar -template_name="CRM_Managed_Server_Domain"
Run the unpack
command:
CRMHOST3> ./unpack.sh -domain=/u02/local/oracle/config/domains/ CRMHOST3/CRMDomain -template=ORACLE_BASE/user_templates/CRMDomain_managed.jar
Here, ORACLE_BASE
is shared, and /u02/local
is local to CRMHOST3
.
To add a managed server and assign it to CRMHOST3
:
Log in to the Administration Server: http://
crminternal
.mycompany.com:7777/console
.
Navigate to CRMDomain > Environment > Servers.
Switch to Lock & Edit mode.
Select the Managed_Servers checkbox (for example, soa_server1) and then click Clone.
Specify the following Server Identity attributes:
Server Name - soa_server3
Note:
To ensure consistency in naming, copy the name of the server shown in Server Identity and paste it into the Server Name field. Then change the number to "_3".Server Listen Address - <CRMHOST3
>
Server Listen Port - leave "as is"
Click OK.
Navigate back to CRMDomain > Environment > Servers. You now should see the newly cloned sales server, soa_server3
.
Click soa_server3 and change the following attributes:
Machine - <CRMHOST3
>
Cluster Name - Default, SOACluster
From soa_server3, click Advanced and then select the WebLogic Plug-In Enabled checkbox.
Run the newly created managed server:
Navigate to CRMDomain > Environment.
From the Navigation pane on the Oracle WebLogic Server console, select Activate Changes.
Navigate to CRMDomain > Environment > Servers > Control.
Check the newly created managed server and click Start.
Navigate to CRMDomain > Environment > Servers and check the State to verify that the newly created managed servers are running.
From the Name column, select the scaled-out server, soa_server3
.
Click Lock & Edit, and then choose the Keystores tab.
Change the Keystores dropdown list value to the Custom Identity and Custom Trust setting.
Do the following:
Change the Custom Identity Keystore path to point to the ORACLE_BASE
/products/fusionapps/wlserver_10.3/server/lib/
CRMHOST3
_fusion_identity.jks
file.
Leave the Custom Identity Keystore type blank.
Change the Custom Identity Keystore Passphrase entry. This should be the same as the keystorepassword field described in the first bullet in Step 4 in Section 6.2, "Creating the Identity Keystore on CRMHOST2."
Re-enter the Confirm Custom Identity Keystore Passphrase.
Ensure that the Confirm Custom Trust Keystore path is pointing to the ORACLE_BASE
/products/fusionapps/wlserver_10.3/server/lib/fusion_trust.jks
file.
Leave the Custom Trust Keystore type blank.
Change the Custom Trust Keystore Passphrase entry. This should be the same as the keystorepassword field described in the first bullet in Step 4 in Section 6.2, "Creating the Identity Keystore on CRMHOST2."
Re-enter the Custom Trust Keystore Passphrase.
Click Save.
Choose the SSL tab.
Make sure that Identity and Trust Locations is set to Keystores.
Change the Private Key Alias to CRMHOST3
_fusion
.
Change the Private Key Passphrase to the keypassword, as described in the second bullet in Step 4 in Section 6.2, "Creating the Identity Keystore on CRMHOST2."
Re-enter the keypassword from Step c for the Confirm Private Key Passphrase.
Click Save.
Click Activate Changes.
Set the following variable:
WLST_PROPERTIES="-Dweblogic.security.SSL.trustedCAKeyStore=ORACLE_BASE/
products/fusionapps/wlserver_10.3/server/lib/fusion_trust.jks"
Restart the domain's Administration Server:
CRMHOST3> ORACLE_BASE/products/fusionapps/wlserver_10.3/common/bin/wlst.sh CRMHOST3> nmConnect(username='username', password='password', domainName='CRMDomain', host='CRMHOST1',port='5556', nmType='ssl', domainDir='/u01/oracle/config/domains/CRMHOST1/CRMDomain') CRMHOST3> nmStart('AdminServer')
Note:
The username and password used in thenmConnect
are the Node Manager credentials (username and password) specified when creating the provisioning plan. This is shown in Figure 4-3 in "Using the Provisioning Process to Install Components for an Enterprise Deployment".Log in to the Administration Server once again (http://
crminternal
.mycompany.com:7777/console
) and verify that all the managed servers, including scaled-out servers, are running.
Note:
For all the scaled-up and scaled-out servers, change the Arguments in the/u02/local/oracle/config/domains/HOSTNAME/DomainName/servers/ManagedServer/data/nodemanager/startup.properties
file to the following:
Arguments=-DJDBCProgramName\=DS/CRMDomain/ManagedServer_2 -Dserver.group\=HelpPortalCluster
Note:
For all the scaled-up and scaled-out managed servers, do the following:Access the Oracle WebLogic Server Administration Console for the CRMDomain:
http://
crminternal
.mycompany.com:7777/console
Navigate to Environment > Servers and click the "Managed Server" link.
First select the Logging tab and then the HTTP tab.
Update the following parameters:
– Log file name: logs/access.log.%yyyyMMdd%
– Rotation Type: By Time
– Limit number of retained files: leave this option unchecked
– Rotate log file on startup: leave this option unchecked
Click Save.
Expand Advanced Node and set the following:
– Format: Extended
– Extended Logging Format Fields:
date time time-taken cs-method cs-uri sc-status sc(X-ORACLE-DMS-ECID) cs(ECID-Context) cs(Proxy-Remote-User) cs(Proxy-Client-IP)
Click Save and Activate Changes.
Restart the Managed Server for the changes to take affect.
You should verify URLs to ensure that the appropriate routing and failover is working from Oracle HTTP Server to the SalesCluster.
To verify the URLs:
Log in to the CRMDomain
Oracle WebLogic Server Administration Console and stop all the managed servers on the CRMHOST1
while the managed servers on CRMHOST3
are running.
Access the following URLs to verify that routing and failover are functioning properly. (Ensure the log in prompt is visible.)
http://CRMHOST1:9024/soa-infra
http://crminternal.mycompany.com:7777/soa-infra
Log in to the CRMDomain
Oracle WebLogic Server Administration Console and stop all the managed servers on CRMHOST3
.
Start the managed servers on CRMHOST1
.
Repeat Step 2. (Ensure the log in prompt is visible.)
Start all the managed servers on CRMHOST3
and verify that they are running on CRMHOST1
.
At this point, soa_server1
and soa_server3
are running on CRMHOST1
and CRMHOST3
.
Note:
For Oracle Fusion Customer Relationship Management, the Oracle SOA Suite virtual IPs forCRMHOST1
and CRMHOST3
are called CRMSOAVH1
and CRMSOAVH3
.This section includes the following topics:
Do the following to enable the virtual IPs on Linux:
Note:
In this exampleethX
is the ethernet interface (eth0
or eth1
) and Y
is the index (0, 1, 2, and so on).Run the ifconfig
command as root:
/sbin/ifconfig interface:index IPAddress netmask netmask
For example:
/sbin/ifconfig ethX:Y 100.200.140.206 netmask 255.255.255.0
Enable your network to register the new location of the virtual IP:
/sbin/arping -q -U -c 3 -I interface IPAddress
For example:
/sbin/arping -q -U -c 3 -I ethX 100.200.140.206
Validate that the address is available by pinging it from another node.
For example:
/bin/ping 100.200.140.206
Ensure that you have performed the steps described in Section 14.1 before setting the soa_server3
listen address.
Perform these steps to set the listen address for the Managed Server:
Log in to the Administration Console.
In the Change Center, click Lock & Edit.
Expand the Environment node in the Domain Structure window.
Click Servers. The Summary of Servers page is displayed.
Select soa_server3 in the column of the table. The Settings page for soa_server3
is displayed.
Set the Listen Address to CRMSOAVH3
.
Click Save.
Click Activate Changes.
The changes will not take effect until the soa_server3
Managed Server is restarted (ensure that Node Manager is up and running):
On the Summary of Servers page, select the Control tab.
Select soa_server3 in the table and then click Shutdown.
After the server has shut down, select soa_server3 in the table and then click Start.
For information, see Section 14.4, "Updating the FusionVirtualHost_crm.conf Configuration File."
After CRMHOST1
has been provisioned, the JMS server and file store are set up and configured for CRMHOST1
. You now must configure the file store for CRMHOST3
. Configure the location for all persistence stores to a directory visible from both nodes.
To configure the file store for CRMHOST3
:
Log in to the Oracle WebLogic ServerAdministration Console.
In the Domain Structure window, expand the Services node and then click the Persistence Stores node.
The Summary of Persistence Stores page appears.
Click Lock & Edit.
Click New, and then Create File Store.
Enter a name (for example, SOAJMSFileStore_auto_3
), and a target, soa_server3
:
ORACLE_BASE/config/domains/CRMHOST1/CRMDomain
Click OK and activate the changes.
In the Domain Structure window, expand the Services node and then click the Messaging > JMS Servers node.
The Summary of JMS Servers page appears.
Click Lock & Edit.
Click New.
Enter a name (for example, SOAJMSServer_3
), then select SOAJMSFileStore_auto_3 in the Persistence Store dropdown list.
Click Next.
Select soa_server3 as the target.
Click Finish and Activate Changes.
In the Domain Structure window, expand the Services node and then click the Messaging > JMS Modules node.
The JMS Modules page appears.
In the Change Center, click Lock & Edit.
Click SOAJMSModule and then click the Subdeployments tab.
Select SOAJMSServer under Subdeployments.
Add the new SOAJMSServer_3
as additional targets for the subdeployment.
Click Save and Activate Changes.
Although deploying composites uses multicast communication by default, Oracle recommends using unicast communication instead in SOA enterprise deployments. Use unicast if you disable multicast communication for security reasons.
Note:
An incorrect configuration of the Oracle Coherence framework that is used for deployment may prevent the SOA system from starting. The deployment framework must be properly customized for the network environment on which the SOA system runs. Oracle recommends the configuration described in this section.Multicast communication enables Oracle Fusion Middleware SOA to discover all of the members of a cluster to which it deploys composites dynamically. However, unicast communication does not enable nodes to discover other cluster members in this way. Consequently, you must specify the nodes that belong to the cluster. You do not need to specify all of the nodes of a cluster, however. You need only specify enough nodes so that a new node added to the cluster can discover one of the existing nodes. As a result, when a new node has joined the cluster, it is able to discover all of the other nodes in the cluster. Additionally, in configurations such as SOA enterprise deployments, where multiple IPs are available in the same box, you must configure Oracle Coherence to use a specific host name to create the Oracle Coherence cluster.
Tip:
To guarantee high availability during deployments of SOA composites, specify enough nodes so that at least one of them is running at any given time.Specify the nodes using the tangosol.coherence.wka
n
system property, where n
is the number for each Oracle HTTP Server. The numbering starts at 1. This numbering must be sequential and must not contain gaps. In addition, specify the host name used by Oracle Coherence to create a cluster through the tangosol.coherence.localhost
system property. This local host name should be the virtual host name used by the SOA server as the listener addresses. Set this property by adding the -Dtangosol.coherence.localhost
parameters to the Arguments field of the Oracle WebLogic Server Administration Console's Server Start tab, shown in Figure 18-1.
Note:
CRMSOAVH1
is the virtual host name that maps to the virtual IP where soa_server1
is listening (in CRMHOST1
). CRMSOAVH3
is the virtual host name that maps to the virtual IP where soa_server3
is listening (in CRMHOST3
).To add the host name used by Oracle Coherence:
Log in to the Oracle WebLogic Server Administration Console.
In the Domain Structure window, expand the Environment node.
Click Servers.
The Summary of Servers page appears.
Select soa_server1 (represented as a hyperlink) from the column of the table.
The Settings page appears.
Click Lock & Edit.
Click the Server Start tab (shown in Figure 18-1).
Enter the following for soa_server1
and soa_server3
into the Arguments field.
For soa_server1
, enter the following:
-Dtangosol.coherence.wka1=CRMSOAVH1 -Dtangosol.coherence.wka2=CRMSOAVH3 -Dtangosol.coherence.localhost=CRMSOAVH1 -Dtangosol.coherence.localport=8089 -Dtangosol.coherence.wka1.port=8089 -Dtangosol.coherence.wka2.port=8089
For soa_server3
, enter the following:
-Dtangosol.coherence.wka1=CRMSOAVH3 -Dtangosol.coherence.wka2=CRMSOAVH1 -Dtangosol.coherence.localhost=CRMSOAVH3 -Dtangosol.coherence.localport=8089 -Dtangosol.coherence.wka1.port=8089 -Dtangosol.coherence.wka2.port=8089
Note:
There should be no breaks in lines between the different-D
parameters. Do not copy or paste the code from above to your Administration Console's Arguments text field. This may result in HTML tags being inserted in the Java arguments. The code should not contain other characters than those included in the example above.Click Save and Activate Changes.
Note:
You must ensure that these variables are passed to the managed server correctly. (They should be reflected in the server's output log.) Failure of the Oracle Coherence framework can prevent the soa-infra application from starting.Note:
The multicast and unicast addresses are different from the ones used by the Oracle WebLogic Server cluster for cluster communication. Oracle SOA Suite guarantees that composites are deployed to members of a single Oracle WebLogic Server cluster even though the communication protocol for the two entities (the Oracle WebLogic Server cluster and the groups to which composites are deployed) are different.Note:
The Oracle Coherence cluster used for deployment uses port 8088 by default. This port can be changed by specifying the-Dtangosol.coherence.wkaX.port
startup parameter.This step is required if you have not set up the appropriate certificates to authenticate the different nodes with the Administration Server. By default, Host Name Verification should be set to None
. If it is not, follow the steps below.
If you have not configured the server certificates, you will receive errors when managing the different WebLogic servers. To avoid these errors, disable host name verification while setting up and validating the topology, and enable it again once the enterprise deployment topology configuration is complete.
To disable Host Name Verification:
Log in to Oracle WebLogic Server Administration Console. For example, http://crminternal.mycompany.com:777/console
.
Click Lock & Edit.
Expand the Environment node in the Domain Structure window.
Click Servers.
The Summary of Servers page appears.
Select soa_server3 (represented as a hyperlink) from the column of the table.
The Settings page appears.
Select the SSL tab.
Expand the Advanced section of the page.
Set Hostname Verification to None.
Click Save and activate the changes.
To restart Node Manager on CRMHOST3
, follow the steps in Section 14.9, "Restarting Node Manager on CRMHOST1."
To start the soa_server3
managed server on CRMHOST3
and ensure that it is configured correctly:
From the Administration Console, start the soa_server3
managed server.
Verify that the server status is reported as "Running" in the Administration Console. If the server is shown as "Starting" or "Resuming," wait for the server status to change to "Started." If another status is reported (such as "Admin" or "Failed"), check the server output log files for errors.
Access http://
CRMSOAVH3
:9024/soa-infra
and http://
crminternal
.mycompany.com:7777/soa-infra
.
Before performing the procedures in this section, ensure that CommonDomain
and its managed servers are running.
To add a managed server and assign it to CRMHOST3
:
Log in to the Administration Server: http://
crminternal
.mycompany.com:7777/console
.
Navigate to CRMDomain > Environment > Servers.
Switch to Lock & Edit mode.
Select the Managed_Servers checkbox (for example, soa_server3) and then click Clone.
Specify the following Server Identity attributes:
Server Name - soa_server4
Note:
To ensure consistency in naming, copy the name of the server shown in Server Identity and paste it into the Server Name field. Then change the number to "_4".Server Listen Address - <CRMHOST3
>
Server Listen Port - leave "Give an unused port on the machine CRMHOST3
"
Click OK.
Navigate back to CRMDomain > Environment > Servers. You now should see the newly cloned SOA server, soa_server4
.
Click soa_server4 and change the following attributes:
Machine - <CRMHOST3
>
Cluster Name - Default, SOACluster
From soa_server4, click Advanced and then select the WebLogic Plug-In Enabled checkbox.
Run the newly created managed server:
Navigate to CRMDomain > Environment.
From the Navigation pane on the Oracle WebLogic Server console, select Activate Changes.
Navigate to CRMDomain > Environment > Servers > Control.
Check the newly created managed server and click Start.
Navigate to CRMDomain > Environment > Servers and check the State to verify that the newly created managed servers are running.
Log in to the Administration Server once again (http://
crminternal
.mycompany.com:7777/console
) and verify that all the managed servers, including scaled-up servers, are running.
You should verify URLs to ensure that the appropriate routing and failover is working from Oracle HTTP Server to the SalesCluster.
To verify the URLs:
Log in to the CRMDomain
Oracle WebLogic Server Administration Console and stop the soa_server1
, soa_server2
, and soa_server3
scaled-up managed servers on CRMHOST1
, CRMHOST2
, and CRMHOST3
.
Access the following URLs to verify that routing and failover are functioning properly. (Ensure the log in prompt is visible.)
http://CRMHOST1:9024/soa-infra
http://crminternal.mycompany.com:7777/soa-infra
Log in to the CRMDomain
Oracle WebLogic Server Administration Console and stop all the soa_server4
managed servers on CRMHOST3
.
Start the managed servers on CRMHOST1
.
Repeat Step 2. (Ensure the log in prompt is visible.)
Start all the managed servers on CRMHOST2
and verify that they are running on CRMHOST1
.
When scaling out the topology, you add a new Managed Server and set of system components to a new node in your topology (CRMHOST3). This procedure assumes that you already have an enterprise topology that includes two nodes, with a Managed Server and a full set of system components on each node.
Before performing the steps in this section, ensure that you meet these requirements:
There must be existing nodes running OOracle Business Intelligence Managed Servers within the topology.
The new node (CRMHOST3
) can access the existing home directories for Oracle WebLogic Server and Oracle Business Intelligence.
When an FA_MW_HOME
or WL_HOME
is shared by multiple servers in different nodes, it is recommended that you keep the Oracle Inventory and Middleware home list in those nodes updated for consistency in the installations and application of patches. To update the oraInventory
in a node and "attach" an installation in a shared storage to it, use ORACLE_BASE
/products/fusionapps/bi/oui/bin/attachHome.sh
. To update the Middleware home list to add or remove a WL_HOME
, edit the ORACLE_BASE
/products/fusionapps/.home file
. See the steps below.
You must ensure that all shared storage directories are available on the new node. Ensure that all shared directories are available on all nodes, except for the ORACLE_INSTANCE
directory and the domain directory for the scaled-out Managed Server.
Also, if you are using shared storage for the identity keystore and trust keystore that hold your host name verification certificates, make sure that the shared storage directory is accessible from the scaled-out node (CRMHOST3
). If you are using local directories for your keystores, follow the steps in Section 6.2, "Creating the Identity Keystore on CRMHOST2" to create and configure a local identity keystore for the scaled-out node.
For example, mount the following directories:
Transaction Log directory
JMS Persistence Store
Global Cache
BI Presentation Catalog
BI Repository Publishing directory
BI Publisher Catalog
BI Publisher Configuration Keystore (certs)
MW_HOME
Perform these steps to scale out Oracle Business Intelligence on CRMHOST3
:
On CRMHOST3
, mount the existing Middleware home, which should include the Oracle Business Intelligence installation and (optionally, if the domain directory for Managed Servers in other nodes resides on shared storage) the domain directory, and ensure that the new node has access to this directory, just like the rest of the nodes in the domain.
Run the following command to attach ORACLE_BASE
/products/fusionapps/oracle_common
in shared storage to the local Oracle Inventory:
CRMHOST3> cd ORACLE_BASE/products/fusionapps/oracle_common/oui/bin/ CRMHOST3> ./attachHome.sh -jreLoc ORACLE_BASE/products/fusionapps/jdk6
To update the Middleware home list, create (or edit, if another WebLogic installation exists in the node) the ORACLE_BASE
/products/fusionapps/.home
file and add ORACLE_BASE
/products/fusionapps
to it.
Start Node Manager:
Stop any Node Manager running on CRMHOST3
.
Change directory to ORACLE_BASE
/products/fusionapps/wlserver_10.3/common/nodemanager
and edit the nodemanager.properties
file with the following:
SecureListener=false
Change directory to ORACLE_BASE
/products/fusionapps/oracle_common/common/bin
and run the following script:
./setNMProps.sh
Change directory to ORACLE_BASE
/products/fusionapps/wlserver_10.3/server/bin
and run the following script:
./startNodeManager.sh
Node Manager starts on CRMHOST3
.
Run the Configuration Assistant from one of the shared Oracle homes, using the steps in Section 13.5.1, "Scaling Out the BI System on CRMHOST2" as a guide.
Scale out the system components on CRMHOST3
, using the steps in Section 13.5.3, "Scaling Out the System Components" as a guide.
Configure the bi_server3
Managed Server by setting the Listen Address and disabling host name verification, using the steps in Section 13.5.5, "Configuring the bi_server2 Managed Server" as a guide.
Configure JMS for Oracle BI Publisher, as described in Section 13.5.6.3.3, "Configuring JMS for BI Publisher."
Configure Oracle BI for Microsoft Office on CRMHOST3
, as described in Section 13.5.6.4, "Additional Configuration Tasks for Oracle BI for Microsoft Office."
Set the location of the default persistence store for bi_server3
, as described in Section 13.5.7, "Configuring a Default Persistence Store for Transaction Recovery."
Configure Oracle HTTP Server for BIVH3
using the steps in Section 13.4.3, "Updating the FusionVirtualHost_bi.conf Configuration File" as a guide.
Start the bi_server3
Managed Server and the system components running on CRMHOST3
. See Section 13.5.8, "Starting and Validating Oracle Business Intelligence on CRMHOST2"for details.
Set up server migration for the new node, as described in the following sections:
Access the following URLS to validate the configuration:
http://BIVH3:10217/analytics
to verify the status of bi_server3
.
http://BIVH3:10217/wsm-pm
to verify the status of Web Services Manager. Click Validate Policy Manager. A list of policies and assertion templates available in the data is displayed.
Note:
The configuration is incorrect if no policies or assertion templates appear.http://BIVH3:10217/xmlpserver
to verify the status of the Oracle BI Publisher application.
http://BIVH3:10217/ui
to verify the status of the Oracle Real-Time Decisions application.
http://BIVH3:10217:/mapviewer
to verify the status of the map view functionality in Oracle BI EE.
http://BIVH3:10217/hr
to verify Financial Reporting.
http://BIVH3:10217/calcmgr/index.htm
to verify Calculation Manager.
http://BIVH3:10217/aps/Test
to verify APS.
http://BIVH3:10217/workspace
to verify workspace
Oracle recommends using host name verification for the communication between Node Manager and the servers in the domain. This requires the use of certificates for the different addresses communicating with the Administration Server and other servers. See Chapter 6, "Configuring Node Manager" for further details.
This procedure assumes that you already have an enterprise topology that includes two nodes, with a Managed Server and a full set of system components on each node. To scale up the topology, you increase the number of system components running on one of your existing nodes.
Note that it is not necessary to run multiple Managed Servers on a given node.
Perform these steps to scale up Oracle Business Intelligence on CRMHOST3
:
Log in to Fusion Middleware Control.
Expand the Business Intelligence node in the Farm_BIDomain window.
Click coreapplication.
Click Capacity Management, then click Scalability.
Change the number of BI Servers, Presentation Servers, or JavaHosts using the arrow keys.
Click Apply, then click Activate Changes.
Click Restart to apply recent changes.
Click Restart under Manage System.
Click Yes in the confirmation dialog.
Table 18-1 lists the static artifacts to back up in the 11g Oracle Fusion Customer Relationship Management enterprise deployment.
Table 18-1 Static Artifacts to Back Up in the 11g CRM Enterprise Deployment
Type | Host | Location | Tier |
---|---|---|---|
ORACLE HOME (DB) |
|
The location is user-defined. Generally, |
Data tier |
MW HOME (OHS) |
|
|
Web tier |
MW HOME |
|
|
Application tier |
Installation-related files |
|
N/A |
Table 18-2 lists the run-time artifacts to back up in the 11g Oracle Fusion Customer Relationship Management enterprise deployment.
Table 18-2 Run-Time Artifacts to Back Up in the 11g CRM Enterprise Deployment
Type | Host | Location | Tier |
---|---|---|---|
DOMAIN HOME |
|
|
Application tier |
Application artifacts (EAR and WAR files) |
|
Find the application artifacts by viewing all of the deployments through the administration console. |
Application tier |
Oracle HTTP Server instance home |
|
|
Web tier |
Oracle RAC databases |
|
The location is user-defined. |
Data tier |
For more information on backup and recovery of Oracle Fusion Middleware components, see Oracle Fusion Middleware Administrator's Guide.
For information on monitoring the Oracle Fusion Customer Relationship Management topology, see the following documents:
For information, see "Moving Components for Oracle Fusion Applications Across Environments" in the Oracle Fusion Applications Administrator's Guide.
An ODL log is a set of log files that includes the current ODL log file and zero or more ODL Archives (segment files) that contain older messages. As the log file grows, new information is added to the end of the log file, server_name-diagnostic.log. When the log file reaches the rotation point, it is renamed and a new log file, server_name-diagnostic.log is created. You specify the rotation point, by specifying the maximum ODL segment size, or, for the log files of some components, the rotation time and rotation frequency.
Segment files are created when the ODL log file server_name-diagnostic.log reaches the rotation point. That is, the server_name-diagnostic.log is renamed to server_name-diagnostic-n.log, where n
is an integer, and a new server_name-diagnostic.log file is created when the component generates new diagnostic messages.
To limit the size of the ODL log, you can specify:
The maximum size of the logging directory. Whenever the sum of the sizes of all of the files in the directory reaches the maximum, the oldest archive is deleted to keep the total size under the specified limit.
By default, the log files are rotated when they reach 10 MB. The maximum size of all log files for a particular component is 100 MB.
The maximum size of the log file. You specify that a new log file be created when a specific time or frequency is reached.
Note:
After you change the log file rotation, the configuration is reloaded dynamically. It may take 1 or 2 seconds to reload the configuration.The following topics describe how to change the rotation:
To configure log file rotation using Fusion Middleware Control for a component:
From the navigation pane, select the component.
From the dynamic target menu, choose Logs, then Log Configuration.
The Log Configuration page is displayed.
Select the Log Files tab.
In the table, select the logger and click Edit Configuration.
The Edit Log File dialog box is displayed.
In the Rotation Policy section, you can select one of the following:
Size Based: If you select this, enter the following:
For Maximum Log File Size, enter the size in MB, for example, 15.
For Maximum Size of All Log Files, enter the size in MB, for example, 150.
Time Based: If you select this, enter the following:
For Start Time, enter the date when you want the rotation to start. For example, enter 10-SEP-2009.
For Frequency, you can select Minutes and enter the number of minutes, or you can select Hourly, Daily, or Weekly.
For Retention Period, you can specify how long the log files are kept. You can select Minutes and enter the number of minutes, or you can specify Day, Week, Month, or Year.
Specifying a shorter period means that you use less disk space, but are not able to retrieve older information.
Click OK.
In the confirmation window, click Close.
To specify log file rotation using WLST, use the configureLogHandler
command. You can specify size-based rotation or time-based rotation.
For example, to specify that the log files rotate daily and that they are retained for a week, use the following command:
configureLogHandler(name='odl-handler', rotationFrequency='daily', retentionPeriod='week')
To specify that the size of a log file does not exceed 5MB and rotates when it reaches that size, use the following command:
configureLogHandler(name='odl-handler', maxFileSize='5M')
For information, see the Oracle Fusion Applications Patching Guide.
Oracle Fusion Middleware Audit Framework is a new service in Oracle Fusion Middleware 11g, designed to provide a centralized audit framework for the middleware family of products. The framework provides audit service for platform components such as Oracle Platform Security Services (OPSS) and Oracle Web Services. It also provides a framework for JavaEE applications, starting with Oracle's own JavaEE components. JavaEE applications will be able to create application-specific audit events. For non-JavaEE Oracle components in the middleware, such as C or JavaSE components, the audit framework also provides an end-to-end structure similar to that for JavaEE applications.
Figure 18-2 is a high-level architectural diagram of the Oracle Fusion Middleware Audit Framework.
The Oracle Fusion Middleware Audit Framework consists of the following key components:
Audit APIs: These are APIs provided by the audit framework for any audit-aware components integrating with the Oracle Fusion Middleware Audit Framework. During run time, applications may call these APIs, where appropriate, to audit the necessary information about a particular event happening in the application code. The interface allows applications to specify event details such as user name and other attributes needed to provide the context of the event being audited.
Audit Events and Configuration: The Oracle Fusion Middleware Audit Framework provides a set of generic events for convenient mapping to application audit events. Some of these include common events such as authentication. The framework also allows applications to define application-specific events.
These event definitions and configurations are implemented as part of the audit service in Oracle Platform Security Services. Configurations can be updated through Enterprise Manager (UI) and WebLogic Scripting Tool (WLST) command-line tool.
Audit Bus-stop: Bus-stops are local files containing audit data before they are pushed to the audit repository. In the event where no database repository is configured, these bus-stop files can be used as a file-based audit repository. The bus-stop files are simple text files that can be queried easily to look up specific audit events. When a DB-based repository is in place, the bus-stop acts as an intermediary between the component and the audit repository. The local files are periodically uploaded to the audit repository based on a configurable time interval.
Audit Loader: As the name implies, the audit loader loads the files from the audit bus-stop into the audit repository. In the case of platform and JavaEE application audit, the audit loader is started as part of the JavaEE container start-up. In the case of system components, the audit loader is a periodically spawned process.
Audit Repository: The audit repository contains a predefined Oracle Fusion Middleware Audit Framework schema, created by Repository Creation Utility (RCU). Once configured, all the audit loaders are aware of the repository and upload data to it periodically. The audit data in the audit repository is expected to be cumulative and will grow over time. Ideally, this should not be an operational database used by any other applications; rather, it should be a standalone RDBMS used for audit purposes only. In a highly available configuration, Oracle recommends that you use an Oracle Real Application Clusters (RAC) database as the audit data store.
Oracle Business Intelligence Publisher: The data in the audit repository is exposed through predefined reports in Oracle Business Intelligence Publisher. The reports allow users to drill down the audit data based on various criteria. For example:
User name
Time range
Application type
Execution context identifier (ECID)
For more introductory information for the Oracle Fusion Middleware Audit Framework, see the "Introduction to Oracle Fusion Middleware Audit Framework" chapter in the Oracle Containers for J2EE Security Guide.
For information on how to configure the repository for Oracle Fusion Middleware Audit Framework, see the "Configuring and Managing Auditing" chapter in the Oracle Containers for J2EE Security Guide.
The enterprise deployment topology does not include Oracle Fusion Middleware Audit Framework configuration. The ability to generate audit data to the bus-stop files and the configuration of the audit loader will be available once the products are installed. The main consideration is the audit database repository where the audit data is stored. Because of the volume and the historical nature of the audit data, it is strongly recommended that customers use a separate database from the operational store or stores being used for other middleware components.
This section covers the following topics:
Section 18.8.1, "Page Not Found When Accessing soa-infra Application Through Load Balancer"
Section 18.8.3, "Incomplete Policy Migration After Failed Restart of SOA Server"
Section 18.8.5, "Administration Server Fails to Start After a Manual Failover"
Section 18.8.6, "Error While Activating Changes in Administration Console"
Section 18.8.7, "SOA Server Not Failed Over After Server Migration"
Section 18.8.8, "SOA Server Not Reachable From Browser After Server Migration"
Section 18.8.9, "Oracle Access Manager Configuration Tool Does Not Remove URLs"
Section 18.8.14, "JDBC Connection Reset Appears When on OEL 5.4"
Section 18.8.15, "Missing JMS Instances on Oracle BI Publisher Scheduler Diagnostics Page"
Section 18.8.16, "Oracle BI Publisher Jobs in Inconsistent State After Managed Server Shutdown"
Problem: A 404 "page not found" message is displayed in the web browser when you try to access the soa-infra application using the load balancer address. The error is intermittent and Oracle SOA Suite servers appear as "Running" in the WLS Administration Console.
Solution: Even when the Oracle SOA Suite managed servers may be up and running, some of the applications contained in them may be in Admin, Prepared or other states different from Active. The soa-infra application may be unavailable while the Oracle SOA Suite server is running. Check the Deployments page in the Administration Console to verify the status of the soa-infra application. It should be in "Active" state. Check the Oracle SOA Suite server's output log for errors pertaining to the soa-infra application and try to start it from the Deployments page in the Administration Console.
Problem: The soa-infra application fails to start after changes to the Coherence configuration for deployment have been applied. The Oracle SOA Suite server output log reports the following:
Cluster communication initialization failed. If you are using multicast, Please make sure multicast is enabled on your network and that there is no interference on the address in use. Please see the documentation for more details.
Solutions:
When using multicast instead of unicast for cluster deployments of Oracle SOA Suite composites, a message similar to the above may appear if a multicast conflict arises when starting the soa-infra application (that is, starting the managed server on which Oracle SOA Suite runs). These messages, which occur when Oracle Coherence throws a run-time exception, also include the details of the exception itself. If such a message appears, check the multicast configuration in your network. Verify that you can ping multicast addresses. In addition, check for other clusters that may have the same multicast address but have a different cluster name in your network, as this may cause a conflict that prevents soa-infra from starting. If multicast is not enabled in your network, you can change the deployment framework to use unicast as described in Oracle Coherence Developer's Guide.
When entering well-known address list for unicast (in server start parameters), make sure that the node's addresses entered for the localhost and clustered servers are correct. Error messages like the following are reported in the server's output log if any of the addresses is not resolved correctly:
oracle.integration.platform.blocks.deploy.CompositeDeploymentCoordinatorMessages errorUnableToStartCoherence
Problem: The SOA server fails to start through the administration console before setting Node Manager property startScriptEnabled=true
. The server does not come up after the property is set either. The SOA Server output log reports the following:
SEVERE: <.> Unable to Encrypt data Unable to Encrypt data. Check installation/post-installation steps for errors. Check for errors during SOA server startup. ORABPEL-35010 . Unable to Encrypt data. Unable to Encrypt data. Check installation/post-installation steps for errors. Check for errors during SOA server startup. . at oracle.bpel.services.common.util.EncryptionService.encrypt(EncryptionService.java:56) ...
Solution: Incomplete policy migration results from an unsuccessful start of the first SOA server in a cluster. To enable full migration, edit the <jazn-policy>
element the system-jazn-data.xml file to grant permission to bpm-services.jar:
<grant> <grantee> <codesource> <url>file:${oracle.home}/soa/modules/oracle.soa.workflow_11.1.1/bpm-services.jar </url> </codesource> </grantee> <permissions> <permission> <class>java.security.AllPermission</class> </permission> </permissions> </grant>
Problem: A Oracle SOA Suite server fails to start. The domain has been extended for new types of managed server or the system has been scaled up (added new servers of the same type). The Oracle SOA Suite server output log reports the following:
<Warning> <JDBC> <BEA-001129> <Received exception while creating connection for pool "SOADataSource-rac0": Listener refused the connection with the following error: ORA-12516, TNS:listener could not find available handler with matching protocol stack >
Solution: Verify the number of processes in the database and adjust accordingly. As the SYS user, issue the SHOW PARAMETER
command:
SQL> SHOW PARAMETER processes
Set the initialization parameter using the following command:
SQL> ALTER SYSTEM SET processes=greater than 2500 SCOPE=SPFILE
Restart the database.
Note:
The method that you use to change a parameter's value depends on whether the parameter is static or dynamic, and on whether your database uses a parameter file or a server parameter file. See the Oracle Database Administrator's Guide for details on parameter files, server parameter files, and how to change parameter values.Problem: Administration Server fails to start after the Administration Server node failed and manual failover to another nodes is performed. The Administration Server output log reports the following:
<Feb 19, 2009 3:43:05 AM PST> <Warning> <EmbeddedLDAP> <BEA-171520> <Could not obtain an exclusive lock for directory: ORACLE_BASE/admin/edg_domain/aserver/edg_domain/servers/AdminServer/data/ldap/ldapfiles. Waiting for 10 seconds and then retrying in case existing WebLogic Server is still shutting down.>
Solution: When restoring a node after a node crash and using shared storage for the domain directory, you may see this error in the log for the Administration Server due to unsuccessful lock cleanup. To resolve this error, remove the file ORACLE_HOME
/config/domains/CRMHOST1/DomainName/servers/AdminServer/data/ldap/ldapfiles/EmbeddedLDAP.lok
.
Problem: Activation of changes in Administration Console fails after changes to a server's start configuration have been performed. The Administration Console reports the following when clicking Activate Changes:
An error occurred during activation of changes, please see the log for details. [Management:141190]The commit phase of the configuration update failed with an exception: In production mode, it's not allowed to set a clear text value to the property: PasswordEncrypted of ServerStartMBean
Solution: This may happen when start parameters are changed for a server in the Administration Console. In this case, provide user name/password information in the server start configuration in the Administration Console for the specific server whose configuration was being changed.
Problem: After reaching the maximum restart attempts by local Node Manager, Node Manager in the failover node tries to restart it, but the server does not come up. The server seems to be failed over as reported by Node Manager's output information. The VIP used by the SOA server is not enabled in the failover node after Node Manager tries to migrate it (if config in the failover node does not report the VIP in any interface). Executing the command "sudo ifconfig $INTERFACE $ADDRESS $NETMASK" does not enable the IP in the failover node.
Solution: The rights and configuration for sudo
execution should not prompt for a password. Verify the configuration of sudo
with your system administrator so that sudo
works without a password prompt.
Problem: Server migration is working (SOA server is restarted in the failed over node), but the Virtual_Hostname:8001/soa-infra
URL cannot be accessed in the web browser. The server has been "killed" in its original host and Node Manager in the failover node reports that the VIP has been migrated and the server started. The VIP used by the SOA server cannot be pinged from the client's node (that is, the node where the browser is being used).
Solution: The arping
command executed by Node Manager to update ARP caches did not broadcast the update properly. In this case, the node is not reachable to external nodes. Either update the nodemanager.properties file to include the MACBroadcast or execute a manual arping:
/sbin/arping -b -q -c 3 -A -I INTERFACE ADDRESS > $NullDevice 2>&1
Where INTERFACE is the network interface where the virtual IP is enabled and ADDRESS is the virtual IP address.
Problem: The Oracle Access Manager Configuration Tool has been used and a set of URLs was added to the policies in Oracle Access Manager. One of multiple URLs had a typo. Executing the Oracle Access Manager Configuration Tool again with the correct URLs completes successfully; however, when accessing Policy Manager, the incorrect URL is still there.
Solution: The Oracle Access Manager Configuration Tool only adds new URLs to existing policies when executed with the same app_domain
name. To remove a URL, use the Policy Manager Console in Oracle Access Manager. Log on to the Access Administration site for Oracle Access Manager, click on My Policy Domains, click on the created policy domain (SOA_EDG), then on the Resources tab, and remove the incorrect URLs.
Problem: After configuring Oracle HTTP Server and LBR to access the Oracle WebLogic Administration Console, some activation changes cause the redirection to the login screen for the Administration Console.
Solution: This is the result of the console attempting to follow changes to port, channel, and security settings as a user makes these changes. For certain changes, the console may redirect to the Administration Server's listen address. Activation is completed regardless of the redirection. It is not required to log in again; users can simply update the URL to crm.mycompany.com/console/console.portal
and directly access the home page for the Administration Console.
Note:
This problem will not occur if you have disabled tracking of the changes described in this section.Problem: After configuring OAM, some activation changes cause the redirection to the Administration Console's home page (instead of the context menu where the activation was performed).
Solution: This is expected when OAM SSO is configured and the Administration Console is set to follow configuration changes (redirections are performed by the Administration Server when activating some changes). Activations should complete regardless of this redirection. For successive changes not to redirect, access the Administration Console, choose Preferences, then Shared Preferences, and unselect the "Follow Configuration Changes" check box.
Problem: Attempts to start a managed server that uses the Java Object Cache (JOC), such as OWSM managed servers, fail. The following errors appear in the logs:
J2EE JOC-058 distributed cache initialization failure J2EE JOC-043 base exception: J2EE JOC-803 unexpected EOF during read.
Solution: Another process is using the same port that JOC is attempting to obtain. Either stop that process, or reconfigure JOC for this cluster to use another port in the recommended port range.
Problem: You are experiencing out-of-memory issues on managed servers.
Solution: Increase the size of the memory heap allocated for the Java VM to at least one gigabyte:
Log in to the Oracle WebLogic Administration Console.
Click Environment, then Servers.
Click on a managed server name.
Open the Configuration tab.
Open the Server Start tab in the second row of tabs.
Include the memory parameters in the Arguments box, for example:
-Xms3072m -Xmx1024m -XX:CompileThreshold=8000 -XX:PermSize=128m -XX:MaxPermSize=1024m
Note:
Please note that the memory parameter requirements may differ between various JVMs (Sun, JRockit, or others). See "Increasing the Java VM Heap Size for Managed Servers" in the Oracle Fusion Middleware Installation Guide for Oracle Enterprise Content Management Suite for further details.Save the configuration changes.
Restart all running managed servers.
Problem: When you are on Oracle Enterprise Linux (OEL) 5.4, a Java Database Connectivity (JBDC) connection reset appears.
Solutions:
Upgrade to OEL 5.6.
As root, do the following:
Download and install the rngd
tool.
Execute the following commands (in order):
rngd -r /dev/urandom -o /dev/random cat /proc/sys/kernel/random/entropy_avail
Ensure that entropy returns a number greater than 1000.
In some cases, only one JMS instance is visible on the Oracle BI Publisher Scheduler diagnostics page, rather than all instances in the cluster. This issue is most likely caused by clocks being out of sync. For more information on the importance of synchronizing clocks on all nodes in the cluster, see "Clock Synchronization" in the chapter "Database and Environment Preconfiguration" in Oracle Fusion Middleware Enterprise Deployment Guide for Oracle Business Intelligence.
Before shutting down the Managed Server on which Oracle BI Publisher is running, it is a best practice (but not mandatory) to wait for all running Oracle BI Publisher jobs to complete, or to cancel any unfinished jobs using the Report Job History page. Otherwise, the shutdown might cause some jobs to incorrectly stay in a running state.
On rare occasions, a JMS instance is missing from an Oracle BI Publisher Scheduler cluster. To resolve this issue, restart the Oracle BI Publisher application from the Oracle WebLogic Server Administration Console.
To restart Oracle BI Publisher:
Log in to the Administration Console.
Click Deployments in the Domain Structure window.
Select bipublisher(11.1.1).
Click Stop.
After the application stops, click Start.
Log in to the Administration Console and do the following:
Click Preferences in the top navigation bar.
Select the Shared Preferences tab.
De-select Follow Configuration Changes.
Click Save and then Activate Changes.