4 Next Steps After Configuring the WebLogic Server Domain

This section describes common tasks you might want to perform on the newly created WebLogic Server domain.

This section includes the following topics:

Performing Basic Administrative Tasks

Review the administrative tasks you will likely want to perform on a new domain.

Table 4-1 Basic Administration Tasks for a New Domain

Task Description More Information

Getting familiar with WebLogic Server administration tools

Get familiar with various tools that you can use to manage your environment.

See High Availability in Understanding Oracle WebLogic Server.

Starting and stopping products and servers

Learn how to start and stop Administration Server, Managed Servers, and components.

See Starting and Stopping Servers in Administering Server Startup and Shutdown for Oracle WebLogic Server.

Configuring Secure Sockets Layer (SSL)

Learn how to set up secure communications for Oracle WebLogic Server using SSL.

See Configuring SSL for Oracle WebLogic Server in Administering Oracle Fusion Middleware.

Monitoring Oracle WebLogic Server

Learn how to keep track of the status of Oracle WebLogic Server.

See Monitoring, Diagnosing, and Troubleshooting in Understanding Oracle WebLogic Server.

Understanding Backup and Recovery Procedures

Learn the recommended backup and recovery procedures for OracleWebLogic Server.

See Recovering Oracle WebLogic Server with Whole Server Migration and Backup and Recovery Considerations for Oracle WebLogic Server JMS in Administering Oracle Fusion Middleware.

Performing Additional Domain Configuration Tasks

Review additional configuration tasks you will likely want to perform on a new domain.

Table 4-2 Additional Domain Configuration Tasks

Task Description More Information

Deploying Applications

Learn how to deploy your applications to Oracle Fusion Middleware.

See Deploying Applications in Administering Oracle Fusion Middleware.

Adding a Web Tier front-end to your domain

Oracle Web Tier hosts Web pages (static and dynamic), provides security and high performance along with built-in clustering, load balancing, and failover features. In particular, the Web Tier contains Oracle HTTP Server.

To install and configure Oracle HTTP Server in the WebLogic Server domain, see Configuring Oracle HTTP Server in a WebLogic Server Domain in Installing and Configuring Oracle HTTP Server.

Tuning and configuring Coherence for your topology

The standard installation topology includes a Coherence cluster that contains storage-enabled Managed Coherence Servers. This configuration is a good starting point for using Coherence, but depending upon your specific requirements, consider tuning and reconfiguring Coherence to improve performance in a production environment.

For more about Coherence clusters, see Configuring and Managing Coherence Clusters in Administering Clusters for Oracle WebLogic Server.

For information on tuning Coherence, see Performance Tuning in Administering Oracle Coherence.

For information on storing HTTP session data in Coherence, see Using Coherence*Web with WebLogic Server in Administering HTTP Session Management with Oracle Coherence*Web.

For more about creating and deploying Coherence applications, see Getting Started in Developing Oracle Coherence Applications for Oracle WebLogic Server.

Preparing Your Environment for High Availability

Scaling out for high availability requires additional steps.

Table 4-3 provides a list of tasks to perform if you want to scale out your standard installation environment for high availability.

Table 4-3 Tasks Required to Prepare Your Environment for High Availability

Task Description More Information

Scaling out to multiple host computers

To enable high availability, it is important to provide failover capabilities to another host computer. That way, if one computer goes down, your environment can continue to serve the consumers of your deployed applications.

See Scaling Out a Topology (Machine Scale Out) in the High Availability Guide.

Configuring high availability for your Web Tier components.

If you have added a Web tier front-end, then you must configure the Web Tier for high availability, as well as the WebLogic Server software.

See Configuring High Availability for Web Tier Components in High Availability Guide.

Setting up a front-end load balancer

A load balancer can be used to distribute requests across servers more evenly.

See Server Load Balancing in a High Availability Environment and Configuring Load Balancer Virtual Server Names and Ports in High Availability Guide.

Configuring Node Manager

Node Manager enables you to start, shut down, and restart the Administration Server and Managed Server instances from a remote location. This document assumes you have configured a per-domain Node Manager. Review the Node Manager documentation, for information on advanced Node Manager configuration options and features.

See Advanced Node Manager Configuration in Administering Node Manager for Oracle WebLogic Server.

Enabling Edition-based Redefinition for Standalone WebLogic Server Installations (Optional)

Edition-based redefinition (EBR) provides standalone Oracle WebLogic Server users with online upgrade support with uninterrupted availability.

If you want to perform a zero downtime upgrade when upgrading to a future standalone release of Oracle WebLogic Server, you must perform the following tasks after installing and configuring the WebLogic domain.


For information about using EBR to perform an online application upgrade, see Using EBR to Upgrade an Application.

Before you begin, review the following prerequisites and pertinent information:

  • Oracle database is the only EBR-supported database.
  • In order to EBR-enable Weblogic Server for zero downtime upgrades, you must use the following database tables for storing system schemas: diagnostic logs, timers, leasing tables, servlet sessions, persistent stores, WAN persistent stores, LLR tables, and batch data tables.
  • The steps in this guide apply to Oracle WebLogic Server standalone installations.
  • In cases where the Oracle WebLogic Server administrator is not able to perform privileged database operations, a database administrator must execute SQL statements or provide an environment for the Oracle WebLogic Server administrator to use.
  • The Oracle WebLogic Server administrator or database administrator must create all editions.
  • Enabling EBR requires downtime during the initial setup, but once the environment is EBR-enabled, additional downtime is unlikely.

Stop the WebLogic Server Domain

Before you begin EBR-enabling your environment, you must first stop the WebLogic Server domain.

See Starting and Stopping Servers in Administering Server Startup and Shutdown for Oracle WebLogic Server.

Create an Edition-enabled User and the Edition

Create an edition-enabled user before creating the edition on the database.

The WebLogic Server administrator or the database administrator must complete the following:
  1. Connect to SQL*Plus and execute the following commands to create an edition-enabled user:
    $ sqlplus <sysdba-connection-string>
    SQL> CREATE USER <username> identified by <password>
  2. While still connected to SQL*Plus, execute the following commands to create the edition:
    SQL> CREATE EDITION sample_ed;
    SQL> GRANT USE ON sample_ed TO <username>;
  3. If the edition-enabled user is going to rename tables and create views, then the following permissions must be granted:

Run the Create Table Scripts

Use SQL*Plus to run the packaged EBR scripts from the WebLogic Services directory. These scripts will create the required tables and EBR-enable them automatically.

The WebLogic Server administrator or the database administrator must run the scripts. If you created these tables in a previous release, run the scripts again to ensure you have the latest changes. The scripts will rename the exisiting tables, or, if needed, create new tables with an underscore, and then create the editioning views.
  1. Connect to SQL*Plus and execute the following commands to create the tables. Note that the scripts are located in multiple directores.
    Make sure that you are connecting as the edition-enabled user.

    $ sqlplus <user-connection-string> 
    SQL> @<WLS_HOME>/oracle_common/common/sql/wlsservices/oracle_ebr/crejstbs.sql -- creates WEBLOGIC_TIMERS
    SQL> @<WLS_HOME>/oracle_common/common/sql/wlsservices/oracle_ebr/crelstbs.sql -- creates ACTIVE
    SQL> @<WLS_HOME>/oracle_common/common/sql/wlsservices/diagnostics/oracle_ebr/wls_events_ddl.sql -- creates WLS_EVENTS
    SQL> @<WLS_HOME>/oracle_common/common/sql/wlsservices/diagnostics/oracle_ebr/wls_hvst_ddl.sql -- creates WLS_HVST
    SQL> @<WLS_HOME>/oracle_common/common/sql/wlsservices/servletsess/oracle_ebr/create.sql -- creates WL_SERVLET_SESSIONS
    SQL> @<WLS_HOME>/oracle_common/common/sql/wlsservices/wanpersist/oracle_ebr/create.sql -- creates WLS_WAN_PERSISTENCE_TABLE
  2. Verify that all of the tables have been created before continuing to the next step.

Enable EBR Support for System Tables

Use SQL*Plus to execute the scripts that will EBR-enable each existing system table to be defined.

For each table to be defined, the WebLogic Server administrator or DBA must first create the EBR-enabled version.
  1. Use the following script to create EBR-enabled versions of the existing system tables before defining them in WebLogic Server.
    $ sqlplus <user-connection-string>
    SQL> @<WLS_HOME>/oracle_common/common/sql/wlsservices/oracle_ebr/upgrade_js_ddl.sql -- rename/cover WEBLOGIC_TIMERS
    SQL> @<WLS_HOME>/oracle_common/common/sql/wlsservices/diagnostics/oracle_ebr/upgrade_wls_events_ddl.sql -- rename/cover VIEW WLS_EVENTS
    SQL> @<WLS_HOME>/oracle_common/common/sql/wlsservices/diagnostics/oracle_ebr/upgrade_wls_hvst_ddl.sql -- rename/cover WLS_HVST
    SQL> @<WLS_HOME>/oracle_common/common/sql/wlsservices/oracle_ebr/upgrade_lstbs.sql -- rename/cover ACTIVE
    SQL> @<WLS_HOME>/oracle_common/common/sql/wlsservices/batch/oracle_ebr/upgrade_checkpoint_data_ddl.sql -- rename/cover CHECKPOINTDATA
    SQL> @<WLS_HOME>/oracle_common/common/sql/wlsservices/batch/oracle_ebr/upgrade_execution_instance_data_ddl.sql -- rename/cover EXECUTIONINSTANCEDATA
    SQL> @<WLS_HOME>/oracle_common/common/sql/wlsservices/batch/oracle_ebr/upgrade_job_instance_data_ddl.sql -- rename/cover JOBINSTANCEDATA
    SQL> @<WLS_HOME>/oracle_common/common/sql/wlsservices/batch/oracle_ebr/upgrade_job_status_ddl.sql -- rename/cover JOBSTATUS
    SQL> @<WLS_HOME>/oracle_common/common/sql/wlsservices/batch/oracle_ebr/upgrade_step_execution_instance_data_ddl.sql -- rename/cover STEPEXECUTIONINSTANCEDATA
    SQL> @<WLS_HOME>/oracle_common/common/sql/wlsservices/batch/oracle_ebr/upgrade_step_status_ddl.sql -- rename/cover STEPSTATUS
    SQL> @<WLS_HOME>/oracle_common/common/sql/wlsservices/servletsess/oracle_ebr/upgrade.sql -- rename/cover WL_SERVLET_SESSIONS
    SQL> @<WLS_HOME>/oracle_common/common/sql/wlsservices/wanpersist/oracle_ebr/upgrade.sql -- rename/cover WLS_WAN_PERSISTENCE_TABLE
  2. Verify that the all of the tables are now EBR-enabled.

Set the New Edition as the Default

Once you have verified that all of the tables have been created and the new edition is working as expected, set it as the default edition.

  1. The WLS administrator or DBA will then make the new edition the default.
  2. If the data source is to specify the edition explicitly, then use WLST to set it.
    $ wlst
    wlst> readDomain('/path/to/domain')
    wlst> cd('/JDBCSystemResource/my-ds/JdbcResource/my-ds/JDBCDriverParams/NO_NAME_0/Properties/NO_NAME_0/Property/oracle.jdbc.editionName')
    wlst> cmo.setValue('SAMPLE_ED')
    wlst> updateDomain()

Restart the WebLogic Server Domain

After you have created the system tables, restart the WebLogic domain.

See Starting and Stopping Servers in Administering Server Startup and Shutdown for Oracle WebLogic Server.