Tuesday, April 23, 2013

Clustered IDM:I can access ODSM , how come my wls_ods1 shows down in EM?

I can access ODSM,
Oid1 and Oid2 shows up and running.
Admin Server shows up and running.
But my wls_ods1 shows down in Admin Server EM:    http://oidhost:7003/em


The reason:

The wls_ods1 was up and running but the Admin Server or the EM did not see it .

We did a startManagedServer and sent the info to the administrator with 

 startManagedWebLogic.cmd wls_ods1 http://oidhost:7003

After that, the WLS_ODS1 shows up in the EM.

Wednesday, April 17, 2013

Oracle 10G RepCA (Universial Installer) error and resolution

The following is from:

http://erpbasic.blogspot.ca/2012/03/checking-operating-system-version-must_31.html
We ran into the same issue today in our clustered environment. The solution worked.


Today i got error while installing oracle on Windows server 2008 R2
When i clicked on "setup.exe" file, it throws an error as below:





Starting Oracle Universal Installer...

Checking installer requirements...

Checking operating system version: must be 5.0, 5.1, 5.2 or 6.0 . Actual 6.1

Failed <<<<

Exiting Oracle Universal Installer, log for this session can be found at C:\Prog
ram Files\Oracle\Inventory\logs\installActions2012-03-30_09-25-48AM.log

Please press Enter to exit...





After too much research i came to know that I need to modify the "oraparam.ini" file which
is placed with Oracle setup files.


I modify the Oraparam.ini file located here
"database\install\oraparam.ini"


Just add those words which are bold as below in the oraparam.ini file.

[Certified Versions]
# You can customise error message shown for failure, provide value for
CERTIFIED_VERSION_FAILURE_MESSAGE
Windows = 5.0,5.1,5.2,6.0
,6.1



[Windows-6.1-required]
# Minimum display colours for OUI to run
MIN_DISPLAY_COLORS = 256
# Minimum CPU speed required for OUI
# CPU = 300



Save the oraparam.ini file & then run setup again. Now all goes fine & got the oracle installed.

Tuesday, April 16, 2013

Admin Server Cold Restore in Clustered environment

In our clustered environment, we have 2 nodes,
node1 has admin server running + managed server + node manager;
node 2 has managed server+ node manager running.

LBR sit on top of both nodes.
In the case when node1 fails and could not be brought up quickly, we need to have admin server running on Node 2 so that we can use the Enterprise Manager, and monitor traffic and etc.
This blog describes how that can be achieved easily.


 Back  Back Up IDM Domain Configuration Directory
By default, an Administration Server stores the domain configuration data in the domain_name\config directory, where domain_name is the root directory of the domain.
Back up the config directory to a secure location in case a failure of the Administration Server renders the original copy unavailable. If an Administration Server fails, you can copy the backup version to a different machine and restart the Administration Server on the new machine.
Each time a Managed Server starts up, it contacts the Administration Server and if there are changes in to the domain configuration, the Managed Server updates its local copy of the domain config directory.
During operation, if changes are made to the domain configuration, the Administration Server notifies the Managed Servers which update their local /config directory. So, each Managed Server always has an current copy of its configuration data cached locally.

1.1.2   Restarting an Administration Server on Another Machine
If a machine crash prevents you from restarting the Administration Server on the same machine, you can recover management of the running Managed Servers as follows:
  1. Install the WebLogic Server software on the new administration machine (if this has not already been done).
  2. Make your application files available to the new Administration Server by restoring them from backups or by using a shared disk. Your application files should be available in the same relative location on the new file system as on the file system of the original Administration Server.
  3. Make your configuration and security data available to the new administration machine by restoring them from backups or by using a shared disk. For more information, refer to Directory and File Backups for Failure Recovery.
·        Update the config.xml with the IP address of the new host machine. If the listen address was set to blank, you do not need to change it. For example:
·        <server>
·           <name>AdminServer</name>
·           ...
·           <listen-address></listen-address>
·        </server>
·        You can edit config.xml manually or use WLST offline to update the listen address.
  1. Restart the Administration Server on the new machine.

Friday, April 12, 2013

Create WLS Clustered Domain

Refer here:
http://www.oracle-base.com/articles/11g/weblogic-11g-clustered-domains.php


Create the Clustered Domain

Below is an example of a clustered domain:
Machines        : wls11g-1.localdomain,
                  wls11g-2.localdomain

Domain Name     : clusterDomain


Managed Servers : AdminServer     - Running on wls11g-1.localdomain
                  clusterServer_1 - Running on wls11g-1.localdomain
                  clusterServer_2 - Running on wls11g-2.localdomain

Cluster         : cluster_1

WLS Node Manager

Refer to:
http://docs.oracle.com/cd/E15051_01/wls/docs103/nodemgr/overview.html#wp1074880

Node Manager Versions

WebLogic Server provides two versions of Node Manager, Java-based and script-based, with similar functionality. However, each version has different configuration and security considerations.

Java-based Node Manager

Java-based Node Manager runs within a Java Virtual Machine (JVM) process. It is recommended that you run it as a Windows service on Windows platforms and as an operating system service on UNIX platforms, allowing it to restart automatically when the system is rebooted.
Oracle provides native Node Manager libraries for Windows, Solaris, HP UX, Linux on Intel, Linux on Z-Series, and AIX operating systems.


This version of Node Manager determines its configuration from the nodemanager.properties file. See Reviewing nodemanager.properties.
Java-based Node Manager provides more security than the script-based version. See Configuring Java-based Node Manager Security.

Script-based Node Manager

For UNIX and Linux systems, WebLogic Server provides a script-based version of Node Manager. This script is based on UNIX shell scripts, but uses SSH for increased security.



Accessing Node Manager

A Node Manager client can be local or remote to the Node Managers with which it communicates. You access either version of Node Manager—the Java version or the script-based (SSH) version—from the following clients:
  • Administration Server
    • Administration Console, from the EnvironmentsArrow symbolMachinesArrow symbolConfigurationArrow symbolNode Manager page.
    • JMX utilities
    •   you can create JMX utilities that talk to the Administration Server and perform operations on the ServerLifeCycleRuntimeMBean which in turn uses Node Manager internally to perform operations.  
  • WLST commands and scripts—WLST offline serves as a Node Manager command-line interface that can run in the absence of a running Administration Server. You can use WLST commands to start, stop, and monitor a server instance without connecting to an Administration Server. Starting the Administration Server is the main purpose of the stand-alone client. However, you can also use WLST to:
    • Stop a server instance that was started by Node Manager.
    • Start a Managed Server.
    • Access the contents of a Node Manager log file.
    • Obtain server status for a server that was started with Node Manager.
    • Retrieve the contents of server output log.

What You Can Do with Node Manager

The following sections describe basic Node Manager functionality.

Start, Shut Down, and Restart an Administration Server

Using the WebLogic Scripting Tool (or SSH client for Script-based Node Manager only), you connect to the Node Manager process on the machine that hosts the Administration Server and issue commands to start, shut down, or restart an Administration Server. The relationship of an Administration Server to Node Manager varies for different scenarios.
  • An Administration Server can be under Node Manager control—You can start it, monitor it, and restart it using Node Manager.
  • An Administration Server can be a Node Manager client—When you start or stop Managed Servers from the Administration Console, you are accessing Node Manager using the Administration Server.
  • An Administration Server supports the process of starting up a Managed Server with Node Manager—When you start a Managed Server with Node Manager, the Managed Server contacts the Administration Server to obtain outstanding configuration updates.

Start, Shut Down, Suspend, and Restart Managed Servers

From the WebLogic Server Scripting Tool (WLST) command line or scripts, you can issue commands to Node Manager to start, shut down, suspend, and restart Managed Server instances and clusters.
Node Manager can restart a Managed Server after failure even when the Administration Server is unavailable if Managed Server Independence (MSI) mode is enabled for that Managed Server instance. This is enabled by default.
Note: Node Manager cannot start a Managed Server for the first time in MSI mode, because at the Administration Server for the domain must be available so the Managed Server can obtain its configuration settings.
Note: Node Manager uses the same command arguments that you supply when starting a Managed Server with a script or at the command line. For information about startup arguments, see “weblogic.Server Command-Line Reference” in WebLogic Server Command Reference.

Restart Administration and Managed Servers

If a server instance that was started using Node Manager fails, Node Manager automatically restarts it.
Note: Node Manager can only restart a server that was started using Node Manager.
The restart feature is configurable. Node Manager’s default behavior is to:
  • Automatically restart server instances under its control that fail. You can disable this feature.
  • Restart failed server instances no more than a specific number of times. You define the number of restarts by setting the RestartMax property in the Node Manager startup.properties file.
If Node Manager fails or is explicitly shut down, upon restart, it determines the server instances that were under its control when it exited. Node Manager can restart any failed server instances as needed.
Note: It is advisable to run Node Manager as an operating system service, so that it restarts automatically if its host machine is restarted.

Monitor Servers and View Log Data

Node Manager creates a log file for the Node Manager process and a log file of server output for each server instance it controls. You can view these log files, as well as log files for a server instance using the Administration Console or WLST commands.


How Node Manager Works in the WebLogic Server Environment

The following sections provide a “big picture” diagram of Node Manager’s role in the WebLogic Server environment, as well as illustrations and descriptions of the processes Node Manager uses to communicate with servers:

Diagram of Node Manager and Servers

Figure 2-1 illustrates the relationship between Node Manager, its clients, and the server instances it controls.
Figure 2-1 Node Manager in the WebLogic Server Environment
Node Manager in the WebLogic Server Environment


 

Clustering Oracle Portal 11g


Refer to:
http://docs.oracle.com/cd/E25178_01/core.1111/e10106/classic.htm#CIHCFHBJ
for Oracle Portal High Availability Concept.
Oracle Portal High Availability Deployment
Basic Strategy 








Oracle Web Cache instances are clustered. Once a configuration change is made through the Oracle Fusion Middleware Console or through the Oracle Web Cache Administration utility, these changes are propagated to other cluster members. Propagation is done manually using these tools.

Oracle HTTP Servers are not clustered. The Oracle HTTP server configuration is file-based. As a result, changes made to one Oracle HTTP Server must be manually copied to other Oracle HTTP Servers in the configuration. This also applies to static HTML files stored in the htdocs directory.

Configure Oracle Portal, Forms, Reports and Discoverer using a series of configuration files. Any changes to these files must be manually applied to all members in the architecture.

WebLogic Managed Servers are clustered and share resources at the cluster level. Changes to these resources can be made once without the need for propagation. These resources include:
  • Data sources
  • Application redeployments
  • State replication












WLS Node Manager, Domain, Admin Server once again


  • Oracle Node Manager is used to start, stop, and monitor Oracle WebLogic Managed Servers including the Administration Server. It periodically polls the WebLogic Managed Servers to ensure that they are functioning. If they are not functioning, the Oracle Node Manager takes appropriate action to restart the failed component to ensure that service is maintained.

    The Oracle WebLogic Administration Server contains both the WebLogic Administration Console and the Oracle Fusion Middleware Enterprise Manager. It is active only once within a WebLogic domain. If the server hosting the Administration Server fails, it must be manually restarted elsewhere.
Oracle WebLogic Managed Servers are the Java EE runtime containers for Oracle Portal, Forms, Reports and Discoverer Applications.