Managing the Topology 11-3
MAX_INSTANCES = MAX_INSTANCES, PURGE_PARTITIONED_DATA = PURGE_PARTITIONED_DATA
;
This deletes the first 1000 instances of the FlatStructure composite version 10 created between 2010-09-07 and 2010-09-08 that are in “UNKNOWN” state. Refer to
Chapter 8, Managing SOA Composite Applications in the Oracle Fusion Middleware Administrators Guide for Oracle SOA Suite for more details on the possible operations
included in the SQL packages provided. Always use the scripts provided for a correct purge. Deleting rows in just the composite_dn table may leave dangling references in
other tables used by the Oracle Fusion Middleware SOA Infrastructure.
11.4 Scaling the Topology
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 covers includes the topics:
■
Section 11.4.1, Scaling Up the Topology Adding Managed Servers to Existing Nodes
■
Section 11.4.2, Scaling Out the Topology Adding Managed Servers to New Nodes
11.4.1 Scaling Up the Topology Adding Managed Servers to Existing Nodes
This section describes how to scale up a topology. Scaling up the topology includes adding managed servers to already existing nodes.
11.4.1.1 Scaling up SOA and WSM
When you scale up the topology, you already have a node that runs a managed server that is configured with SOA components or a managed server with WSM-PM. The
node contains a WebLogic Server home and an Oracle Fusion Middleware SOA home in shared storage. Use existing these installations such as WebLogic Server home,
Oracle Fusion Middleware home, and domain directories, when you create the new managed servers called WLS_SOA and WLS_WSM. You do not need to install WLS or
SOA binaries at a new location or to run pack and unpack.
1.
Using the Oracle WebLogic Server Administration Console, clone WLS_SOA1 or WLS_WSM1 into a new managed server. The source managed server to clone
should be one that already exists on the node where you want to run the new managed server.
To clone a managed server, complete these steps:
a.
From the Domain Structure window of the Oracle WebLogic Server Administration Console, expand the Environment node and then Servers. The
Summary of Servers page appears.
b. Click Lock and Edit and select the managed server that you want to clone for
example, WLS_SOA1.
c. Click Clone.
11-4 Oracle Fusion Middleware Enterprise Deployment Guide for Oracle WebCenter
Name the new managed server WLS_SOAn, where n is a number that identifies the new managed server. In this case, assume that you are adding a new server to
Node 1, where WLS_SOA1 was running.
The remainder of the steps assume that you are adding a new server to SOAHOST1, which is already running WLS_SOA1.
2.
For the listen address, assign the host name or IP to use for this new managed server. If you are planning to use server migration as recommended for this server,
enter the VIP also called a floating IP to enable it to move to another node. The VIP should be different from the one used by the managed server that is already
running.
3.
For WLS_WSM servers, run the Java Object Cache configuration utility again to include the new server in the JOC distributed cache as described in
Section 4.17, Configuring the Java Object Cache for Oracle WSM.
You can use the same discover port for multiple WSM-PM servers in the same node. Repeat the steps
provided in Section 4.17
for each WSM-PM server and the server list is updated.
4.
Create JMS servers for SOA and UMS on the new managed server.
a.
Use the Oracle WebLogic Server Administration Console to create a new persistent store for the new SOAJMSServer which will be created in a later
step and name it, for example, SOAJMSFileStore_N. Specify the path for the store as recommended in
Section 2.3, Shared Storage and Recommended Directory Structure
as the directory for the JMS persistent stores: ORACLE_BASE
admindomain_namecluster_namejmsSOAJMSFileStore_N
b. Create a new JMS server for SOA: for example, SOAJMSServer_N. Use the
SOAJMSFileStore_N for this JMS server. Target the SOAJMSServer_N server to the recently created managed server WLS_SOAn.
c.
Create a new persistence store for the new UMS JMS server which will be created in a later step and name it, for example, UMSJMSFileStore_N.
Specify the path for the store as recommended in Section 2.3, Shared Storage
and Recommended Directory Structure as the directory for the JMS persistent
stores: ORACLE_BASE
admindomain_namecluster_namejmsUMSJMSFileStore_N
d. Create a new JMS Server for UMS: for example, UMSJMSServer_N. Use the
