This chapter contains the following sections:
Parent topic: Upgrading Oracle HTTP Server from 11g to 12c
Review the flowchart and roadmap for an overview of the upgrade process for Oracle HTTP Server.
Figure 3-1 shows the high-level procedures associated with a standalone Oracle HTTP Server upgrade when the starting point is 11g. The tools used for each step are also listed.
Figure 3-1 Upgrade Process Flowchart for Standalone Oracle HTTP Server from 11g to 12c
The following table describes the tasks that must be completed to upgrade a standalone Oracle HTTP Server from 11g to 12c.
Table 3-1 Tasks for Upgrading Standalone Oracle HTTP Server from 11g to 12c
Task | Description |
---|---|
Required Verify that you are upgrading a standalone Oracle HTTP Server. |
To determine which Oracle HTTP Server you have in your existing environment, see Determining whether Oracle HTTP Server is Standalone or Managed (Collocated). |
Required Complete the pre-upgrade tasks. |
The pre-upgrade tasks include cloning your production environment, verifying system requirements and certifications, purging unused data, and creating non-SYSDBA user. For a complete list of pre-upgrade tasks, see Preparing to Upgrade Oracle HTTP Server. Additionally, also complete the following tasks: Important Pre-Upgrade Considerations. |
Required Install the Standalone Oracle HTTP Server. |
Run the installation program to install the software. Select the installation type Standalone Oracle HTTP Server (managed independently of WebLogic server). This transfers the software to your system and creates a new Oracle home directory. |
Required Shut down the 11g environment. |
See Stopping Servers and Processes. |
Required Upgrade the 11g standalone system component configurations. |
|
Required Restart the servers and processes. |
See Starting Servers and Processes. |
Required Verify the upgrade. |
Your Oracle HTTP Server should continue to function as expected. If you have post-upgrade issues, you will need to troubleshoot the installation and retry the upgrade. See Troubleshooting Oracle HTTP Server in Oracle Fusion Middleware Administering Oracle HTTP Server. |
Before you begin the upgrade, it is important to make sure that your existing setup is not impacted during or after the upgrade. If you are using Oracle Web Cache or WebGate, or if you have Application-specific artifacts in your 11g domain, review the topics under this section carefully to prevent impact to your existing setup.
Oracle Web Cache is a secure reverse proxy cache and a compression engine deployed between a browser and the HTTP server or a browser and the Content Management server to improve the performance of the websites by caching frequently accessed content. Oracle has released the last version of Web Cache in 11g. Web Cache is not available in 12c.
Consider the following limitations if you are using Web Cache in your 11g environment:
Web Cache is not available in Fusion Middleware 12c. Correspondingly, there is no upgrade for Web Cache.
Web Cache 11g front-ending a 12c Oracle HTTP Server is not a certified combination.
If you are using both Web Cache and Oracle HTTP Server in your 11g setup, you can only upgrade the Oracle HTTP Server to 12c. In that case, you need to disable the 11g Web Cache and change the configuration settings to divert the traffic to Oracle HTTP Server directly.
If you are using both Web Cache and Oracle HTTP Server in your 11g setup, and you have associated them with a WebLogic Server (WLS) domain for administering them through the Enterprise Manager Fusion Middleware Control, then you must also upgrade the WLS domain to 12c. In that case, the associated Oracle HTTP Server is also upgraded to 12c. However, the Web Cache is removed from the 12c Fusion Middleware Control.
A WebGate is a web-server plug-in for Oracle Access Manager (OAM) that intercepts HTTP requests and forwards them to the Access Server for authentication and authorization. WebGate is included as part of Oracle HTTP Server 12c installation and is upgraded as part of the Oracle HTTP Server upgrade process through Upgrade Assistant.
Note:
In Oracle Fusion Middleware 12c (12.2.1.2), WebGate log file is renamed from oblog.log to webgate.log. After upgrading to the latest release of Oracle HTTP Server, you must manually update the oblog_config_wg.xml file and replace every ‘oblog.log’ occurrence with ‘webgate.log’. For a procedure to do this task, see Updating the WebGate log file-name.In Oracle Fusion Middleware 12c, WebGate log file is renamed from oblog.log to webgate.log. After upgrading to the latest release of Oracle HTTP Server, you must manually update the oblog_config_wg.xml file and replace every occurrence of ‘oblog.log’ with ‘webgate.log’.
Application artifacts include all of your web resources: JSP files, images, stylesheets, Javascript, static HTML pages in addition to your Java classes and source files and web application configuration files. The integrated development environment (IDE) uses all of these resources, and refers to them as web application artifacts.
If you have 11g application artifacts that you want to continue using in 12c, carefully review the following:
As part of upgrading Oracle HTTP Server from an 11g Oracle instance to a 12c domain, the Oracle HTTP Server configuration directory layout is being migrated from an Oracle instance to a standalone domain.
Oracle HTTP Server 11g configuration files that reside in the component configuration directory of the Oracle instance are migrated automatically.
Application artifacts that reside within the Oracle instance, including any combination of static files (such as HTML or images, CGI or FastCGI scripts or applications, or third-party modules), must be migrated manually after the upgrade to 12c.
For more information, see Migrating 11g Application Artifacts.
You need to manually migrate any 11g application artifacts that reside within the Oracle instance, including any combination of static files such as HTML or images, CGI or FastCGI scripts or applications, or third-party modules. Application artifacts that were referred to by the 11g configuration, but were stored in directories outside of the Oracle instance, will continue to be referenced by the migrated configuration used by Oracle HTTP Server 12c.
For example, if a third-party plug-in module was installed into the Oracle home with Oracle HTTP Server 11g, and the configuration referenced it by the Oracle home location using the configuration in the example below, the plug-in module must be installed manually into the Oracle home with 12c Oracle HTTP Server or the upgraded configuration must be modified to reference it elsewhere.
LoadModule example_module "ORACLE_HOME/ohs/modules/mod_example.so"
Similarly, if static files were copied into the /htdocs
directory within the 11g component configuration directory, then they too must be manually copied into the 12c instance configuration directory or the upgraded configuration must be modified to reference it elsewhere. Other types of application artifacts must be manually migrated in a similar manner.
Before beginning your upgrade, download the Oracle HTTP Server 12c (12.2.1.2) distribution on the target system and install it using the Oracle Universal Installer.
Before you run the Upgrade Assistant to upgrade your schemas and configurations, you must shut down all processes and servers, including the Administration Server and any managed servers.
An Oracle Fusion Middleware environment can consist of an Oracle WebLogic Server domain, an Administration Server, multiple managed servers, Java components, system components such as Identity Management components, and a database used as a repository for metadata. The components may be dependent on each other, so they must be stopped in the correct order.
Note:
The procedures in this section describe how to stop servers and processes using the WLST command-line utility or a script. You can also use the Oracle Fusion Middleware Control and the Oracle WebLogic Server Administration Console. See Starting and Stopping Administration and Managed Servers and Node Manager in Oracle Fusion Middleware Administering Oracle Fusion Middleware.To stop your Fusion Middleware environment, follow the steps below.
Step 1: Stop System Components
To stop system components, such as Oracle HTTP Server, use the stopComponent
script:
(UNIX) DOMAIN_HOME/bin/stopComponent.sh component_name
(Windows) DOMAIN_HOME\bin\stopComponent.cmd component_name
You can stop system components in any order.
Step 2: Stop the Managed Servers
To stop a WebLogic Server Managed Server, use the stopManagedWebLogic
script:
(UNIX) DOMAIN_HOME/bin/stopManagedWebLogic.sh managed_server_name admin_url
(Windows) DOMAIN_HOME\bin\stopManagedWebLogic.cmd managed_server_name admin_url
When prompted, enter your user name and password.
Step 3: Stop Oracle Identity Management Components
Stop any Oracle Identity Management components, such as Oracle Internet Directory:(UNIX) DOMAIN_HOME/bin/stopComponent.sh component_name
(Windows) DOMAIN_HOME\bin\stopComponent.cmd component_name
Step 4: Stop the Administration Server
When you stop the Administration Server, you also stop the processes running in the Administration Server, including the WebLogic Server Administration Console and Fusion Middleware Control.
To stop the Administration Server, use the stopWebLogic
script:
(UNIX) DOMAIN_HOME/bin/stopWebLogic.sh
(Windows) DOMAIN_HOME\bin\stopWebLogic.cmd
When prompted, enter your user name, password, and the URL of the Administration Server.
Step 5: Stop Node Manager
To stop Node Manager, close the command shell in which it is running.
Alternatively, after having set the nodemanager.properties
attribute QuitEnabled
to true
(the default is false
), you can use WLST to connect to Node Manager and shut it down. For more information, see stopNodeManager in Oracle Fusion Middleware WLST Command Reference for WebLogic Server.
After reconfiguring the domain, use the Upgrade Assistant to upgrade the domain component configurations inside the domain to match the updated domain configuration.
Run the Upgrade Assistant to upgrade product schemas, domain component configurations, or standalone system components to 12c (12.2.1.2). Oracle recommends that you run the Upgrade Assistant as a non-SYSDBA user, completing the upgrade for one domain at a time.
oracle_common/upgrade/bin
directory:
ORACLE_HOME/oracle_common/upgrade/bin
ORACLE_HOME\oracle_common\upgrade\bin
For information about other parameters that you can specify on the command line, such as logging parameters, see:
When you start the Upgrade Assistant from the command line, you can specify additional parameters.
Table 3-2 Upgrade Assistant Command-Line Parameters
Parameter | Required or Optional | Description |
---|---|---|
|
Required for readiness checks
Note: Readiness checks cannot be performed on standalone installations (those not managed by the WebLogic Server). |
Performs the upgrade readiness check without performing an actual upgrade. Schemas and configurations are checked. Do not use this parameter if you have specified the |
|
Optional |
Identifies the number of threads available for concurrent schema upgrades or readiness checks of the schemas. The value must be a positive integer in the range 1 to 8. The default is 4. |
|
Required for silent upgrades or silent readiness checks |
Runs the Upgrade Assistant using inputs saved to a response file generated from the data that is entered when the Upgrade Assistant is run in GUI mode. Using this parameter runs the Upgrade Assistant in silent mode (without displaying Upgrade Assistant screens). |
|
Optional |
Performs the examine phase but does not perform an actual upgrade. Do not specify this parameter if you have specified the |
|
Optional |
Sets the logging level, specifying one of the following attributes:
The default logging level is Consider setting the |
|
Optional |
Sets the default location of upgrade log files and temporary files. You must specify an existing, writable directory where the Upgrade Assistant will create log files and temporary files. The default locations are: UNIX:
Windows:
|
|
Optional |
Displays all of the command-line options. |
Navigate through the screens in the Upgrade Assistant to upgrade component configurations in the WebLogic domain.
To verify that the domain-specific-component configurations upgrade was successful, log in to the Administration console and the Fusion Middleware Control and verify that the version numbers for each component is 12.2.1.2.
To log into the Administration Console, go to: http://administration_server_host:administration_server_port/console
To log into the Fusion Middleware Control, go to: http://administration_server_host:administration_server_port/em
Note:
After upgrade, make sure you run the administration tools from the new 12c Oracle home and not from the previous Oracle home.
During the upgrade process, some OWSM documents, including policy sets and predefined documents such as policies and assertion templates, may need to be upgraded. If a policy set or a predefined document is upgraded, its version number is incremented by 1.
After a successful upgrade, restart all processes and servers, including the Administration Server and any Managed Servers.
The components may be dependent on each other so they must be started in the correct order.
Note:
The procedures in this section describe how to start servers and process using the WLST command line or a script. You can also use the Oracle Fusion Middleware Control and the Oracle WebLogic Server Administration Console. See Starting and Stopping Administration and Managed Servers and Node Manager in Administering Oracle Fusion Middleware.To start your Fusion Middleware environment, follow the steps below.
Step 1: Start the Administration Server
When you start the Administration Server, you also start the processes running in the Administration Server, including the WebLogic Server Administration Console and Fusion Middleware Control.
To start the Administration Server, use the startWebLogic
script:
(UNIX) DOMAIN_HOME/bin/startWebLogic.sh
(Windows) DOMAIN_HOME\bin\startWebLogic.cmd
When prompted, enter your user name, password, and the URL of the Administration Server.
Step 2: Start Node Manager
To start Node Manager, use the startNodeManager
script:
(UNIX) DOMAIN_HOME/bin/startNodeManager.sh
(Windows) DOMAIN_HOME\bin\startNodeManager.cmd
Step 3: Start Oracle Identity Management Components
Start any Oracle Identity Management components, such as Oracle Internet Directory, that form part of your environment:(UNIX) DOMAIN_HOME/bin/startComponent.sh component_name
(Windows) DOMAIN_HOME\bin\startComponent.cmd component_name
Step 4: Start the Managed Servers
To start a WebLogic Server Managed Server, use the startManagedWebLogic
script:
(UNIX) DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url
(Windows) DOMAIN_HOME\bin\startManagedWebLogic.cmd managed_server_name admin_url
When prompted, enter your user name and password.
Note:
The startup of a Managed Server will typically start the applications that are deployed to it. Therefore, it should not be necessary to manually start applications after the Managed Server startup.Step 5: Start System Components
To start system components, such as Oracle HTTP Server, use the startComponent
script:
(UNIX) DOMAIN_HOME/bin/startComponent.sh component_name
(Windows) DOMAIN_HOME\bin\startComponent.cmd component_name
You can start system components in any order.
You can verify that the upgrade is successful if you are able to start the Node Manager and the Standalone Oracle HTTP Server properly.
If you experience post-upgrade issues, you need to troubleshoot the installation and retry the upgrade. For more information, see Troubleshooting Oracle HTTP Server in Administrator's Guide for Oracle HTTP Server.
If you are not able to start the newly upgraded environment, a possible cause could be the use of MD5 certificates in your Oracle wallet. See Replacing Certificate Signed Using MD5 Algorithm with Certificate Signed Using SHA-2 Algorithm for a procedure to check whether you are using MD5 signatures and a procedure to replace them with SHA-2 certificates.