Installing the Oracle WebLogic Server Component
November 24, 2010
Two major prerequisites for installing Oracle Enterprise Manager (OEM) are having an existing, certified Oracle Database and an installation of Oracle WebLogic Server. Steve Callan shows you the steps performed for database preparation and for installation of Oracle WebLogic Server.
Two major prerequisites for installing Oracle Enterprise Manager (OEM) are having an existing, certified Oracle Database and an installation of Oracle WebLogic Server. For the purposes of this article, let’s assume you already have an existing database (11g) with Database Control configured. That’s pretty much what you get anyway as a result of a normal or regular installation of Oracle on a server (including your own PC or laptop).
This article looks at the steps performed for database preparation and for installation of Oracle WebLogic Server.
All steps involve create or install, with the exception of one component on the existing Oracle database. Given that Database Control was configured, then its repository must be deconfigured and the existing SYSMAN schema must be dropped. The installation and configuration of OEM creates its own SYSMAN user. Along with the new SYSMAN (and SYSMAN_MDS) user comes a MGMT tablespace with several data files.
For a “real” installation of OEM, as in what you would do in a workplace, you’d definitely want to comply with all requirements listed in the Oracle Enterprise Manager Grid Control Basic Installation Guide. The table below is a collection of various links, patch numbers and support notes from My Oracle Support.
Given that we’re starting with an already installed/created database using Database Control, let’s start with getting the database side of things ready to go. The version of OEM is 126.96.36.199, and it will be installed on a Windows 2003 SP2/R2 server, and will use an Oracle 188.8.131.52 database. The certification checker note (412431.1) shows this to be a valid combination.
Deconfigure the existing Database Control
This is simply a matter of running the emca command using (from the docs):
$<ORACLE_HOME>/bin/emca -deconfig dbcontrol db -repos drop -SYS_PWD <sys pasword> -SYSMAN_PWD <sysman password>
For the Windows 2003 environment/path/etc setup, the following can be used:
C:\Documents and Settings\Administrator>echo %oracle_sid% ORCL2 C:\Documents and Settings\Administrator>emca -deconfig dbcontrol db -repos drop STARTED EMCA at Nov 11, 2010 9:52:11 AM EM Configuration Assistant, Version 184.108.40.206.2 Production Copyright (c) 2003, 2005, Oracle. All rights reserved. Enter the following information: Database SID: orcl2 Listener port number: 1526 Password for SYS user: Password for SYSMAN user: Do you wish to continue? [yes(Y)/no(N)]: y Nov 11, 2010 9:54:16 AM oracle.sysman.emcp.EMConfig perform INFO: This operation is being logged at C:\app\oracle\cfgtoollogs\emca\orcl2\emca<path info><date info>.log. <some output not shown> Nov 11, 2010 9:54:21 AM oracle.sysman.emcp.EMReposConfig invoke INFO: Dropping the EM repository (this may take a while) ... Nov 11, 2010 9:57:35 AM oracle.sysman.emcp.EMReposConfig invoke INFO: Repository successfully dropped Enterprise Manager configuration completed successfully FINISHED EMCA at Nov 11, 2010 9:57:42 AM
Drop the SYSMAN (and SYSMAN_MDS) schema
More than likely, you will not have the SYSMAN_MDS schema, so this is just a matter of dropping the SYSMAN schema. Under Windows, take advantage of a supplied script/batch file named RepManager.bat, found in
$ORACLE_HOME\sysman\admin\emdrep\bin. The SYSMAN schema may already be dropped, and to check this ahead of time, look for SYSMAN in DBA_USERS. Running the RepManager.bat file is benign if SYSMAN is no longer present.
With respect to running the RepManager batch file, you cannot use the example shown in the OEM installation guide. The batch file calls a Perl script, which in turn is looking for a host of other environment variables. Hunting down the usage details (either within the called Perl script or Oracle documentation), a format such as this will work (run within the bin folder at the command prompt):
RepManager win2003 1526 orcl2 -sys_password oracle -action drop
The format is (all on one line, line return shown here for formatting):
RepManager <server> <port> <SID> -sys_password <my sys password> -action drop
To avoid some other screen output/feedback, you can set some environment variables in the commenenv.bat file found in the bin folder under ORACLE_HOME.
set EM_REPOS_DBSYSPWD=oracle set EM_REPOS_USER=sysman set EM_REPOS_PWD=oracle set METALINK_USERNAME="" set METALINK_PASSWORD=""
The next easy (no really, this part is) thing to do is check if the UNDO tablespace is at least 200MB in size and autoextensible. A seed database comes with 200MB for UNDO, so this is trivial, and even more so if the tablespace is autoextensible (autoexend on plus maxsize unlimited).
Checking initialization parameters
Some are fixed, some are dynamic. Given prior assumptions (not RAC, out of the box seed database), the fixed parameters to check are:
The dynamic parameters are:
It’s always interesting to see how different groups with Oracle Corp. manage things within their perspective. For example, MOSC note 30753.1 states that setting the value above 1MB is “unlikely to yield significant benefit.” Then in note 351857.1, we’re told that Oracle sets the buffer to the next granule, which may be around 14MB. So what is the point of setting log_buffer to 10MB when at least two other technical notes say otherwise?
Aside from some other prerequisites such as having a fixed IP address (which you would have configured via the installation of a loopback adapter before installing Oracle) and not running the database is QUIESCE mode (this is just you on your computer), and maybe installing a database patch or two, this completes the database prep phase.
Installing Oracle WebLogic Server
The next (major) step is to install Oracle WebLogic Server, followed by installing the WDJ7 patch. Once WLS is installed/configured/patched, then OEM itself is ready to be installed.
A link to download the WDJ7 patch for WLS is available at the bottom of the page on note 1072763.1. The unzipped file contains several jar and XML files, not a lot to it overall. To get Oracle WebLogic Server, drill down through the main page at OTN, and in the downloads section, continue on to the deployment downloads as opposed to the development downloads. The final page should be here.
Within the master note for installing OEM, there is a link to a Windows WLS installation note (1088223.1). Within this note is some good news: you don’t have to install/upgrade Java because the Windows version of WLS comes pre-bundled with its own Java resources. As far as which specific download to select, if you select the 10.3.2 Package Installer version, you’ll be able to follow along step by step with note 1088223.1 as it uses the wls1032_win32.exe file from that download option. You may encounter installer crashes if installing from a network drive. If so, copy the exe file to a local drive and re-try.
The actual installation of WLS is pretty simple. Be sure to choose the “Typical” option (screen shot is not shown below, but it’s pretty obvious what to do when that step appears).
Once WLS is installed, access to the welcome page is based on the loopback adapter IP address and port 7001.
Username and password
Start the Administration Console (button is to the right on the index page shown above) and use weblogic/welcome1 as the username/password.
With proof/confirmation that WLS was successfully installed, we’re now ready to apply the WDJ7 patch. To install the patch, use the Oracle Smart Update Utility. The utility can be started in the <path to Middleware>\utils\bsu folder. The bsu.cmd simply runs the client-patch.jar file, so if you need to, you can execute the jar file via the command line using:
C:\WLS\Middleware\utils\bsu> java –jar client-patch.jar
At this point in the process, if you don’t have access to a Customer Support Identifier (CSI), going forward will be at risk in terms of not installing the patch.
After downloading and validating for conflicts, the WDJ7 patch (and several others by default) becomes available for installation. Click on Apply and the patch (or patches) is applied.
At this point (not quite finally though) we’re ready to install OEM itself, which will be covered in the next article.