1 Automatic Service Migration in WebLogic Server An Oracle White Paper July 2008
2 NOTE: The following is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described for Oracle s products remains at the sole discretion of Oracle. Automatic Service Migration in WebLogic Server Page 2
3 Automatic Service Migration in Weblogic Server INTRODUCTION Today s mission critical applications require highly available services. WebLogic Server offers messaging, transaction, and other system services to facilitate building enterprise grade applications. These services can operate in a clustered environment to help build scalable and highly available applications. Previous releases of Oracle WebLogic Server provided support for administrators to manually migrate highly available services from a failed cluster server to a healthy server. Oracle WebLogic Server 10.3 adds support to the WLS Clustering infrastructure to automatically migrate the services for high availability without any administrative intervention. The authors present various elements of the automatic service migration framework in general, followed by detailed explanations and best practices for this feature in the WebLogic Server 10.3 release. TERMS AND DEFINITIONS Term WebLogic Domain WebLogic Cluster Node Manager Definition A WebLogic Server domain is a logical grouping of WebLogic Server resources for administration purpose. Each domain has a special WebLogic Server instance called the Administration Server. It is the central point to configure and manage all resources in the domain. Usually, a domain also includes additional WebLogic Server instances called Managed Servers. A WebLogic Server Cluster is a set of WebLogic Server instances that work together to provide increased scalability and reliability. All the servers in the cluster belong to the same WebLogic domain. A cluster appears to clients as a single WebLogic Server instance. Node Manager is a WebLogic Server utility that allows controlling the lifecycle of an Administration Server and Managed Server instances from a remote Automatic Service Migration in WebLogic Server Page 3
4 location. A Node Manager process is associated with a specific machine. It can be used to control server instances in any WebLogic Server domain, as long as the server instances reside on the same machine as the Node Manager process. Target Server Target Cluster Target Migratable Target Candidate Servers User Preferred Server Source Server Destination Server SAN WebLogic Server s administration entity that can host and act as a container for various J2EE subsystem services. For example, a Server, Cluster or Migratable Target A single WebLogic Server instance as a Target. One or more servers clustered together to act as one entity providing cluster services by replicating and sharing the common resources, like JNDI, etc. A virtual target that contains one or more candidate servers, with only one active server at any given time. A list of servers that can act as standby for the user preferred server in the migration process. The server instance that the user wants the hosted services to be running at the time of the migratable/system startup. The server instance where the services are migrated "from". The server instance where the services are migrated "to". Storage Area Network OVERVIEW OF WEBLOGIC SERVER SERVICES WebLogic Server offers both clustered as well as singleton services. Clustered services are generally available on all nodes in a cluster. For example, a web application deployed to the cluster will have an instance of the application on each server in the cluster. If the application is configured for session replication, the cluster replication service, which runs on all the nodes in the cluster, will replicate sessions to another node in the cluster. Automatic Service Migration in WebLogic Server Page 4
5 Singleton services, are services that exist only on one node of the cluster at any given point of time, so as to offer specific qualities of service (QOS), but most importantly, to preserve data consistency. One such example is the JMS (Java Messaging Service) service, where the service must ensure that only one copy of the application message gets persisted to storage for every persistent send operation from the producer. But this high QOS has a cost. It is obvious that any problems or issues with the node that hosts the singleton service would render the service unusable or make it unavailable until the problem is corrected. This is a concern in an enterprise application environment. Before we delve into detail about how this concern is addressed in WebLogic Server, we would like to provide a brief summary of various singleton services that are currently offered by WebLogic Server. The current set of singleton services can be grouped into the following broad categories: Persistent Store Service JMS-related Services JTA-related Services User-defined singleton services Persistent Store Service WebLogic Server provides a Persistent Store service that can be shared by many subsystems to store various persistent data. A particular persistent store and the subsystems that use it must all run on the same WebLogic Server instance. Every WebLogic Server comes with a default file-based persistent store. You can configure additional custom stores and associate them with one or more subsystem services. WebLogic Server supports both file based as well as database table based custom stores. Custom stores are migratable, while the default store is migratable only implicitly as part of JTA service migration (the default store cannot be used by migratable services other than JTA). For more information on the store see . JMS Related Services JMS Service The WebLogic JMS Service offers publish-subscribe and point-to-point messaging functionality in WebLogic Server. This service is managed through the configuration entity called JMSServer that acts as a container hosting JMS physical destinations (queues and topics) and is typically targeted onto a WLS Server instance. To support the persistent messaging and preserve the data consistency, all Automatic Service Migration in WebLogic Server Page 5
6 the persistent states (both messages and internal states such as transaction, acknowledgement, and so forth) of a given JMSServer are stored in only one place in the cluster, which is an associated persistent store hosted on the same WebLogic Server instance. For more information on JMS see . SAF Service The Store-And-Forward (SAF) service was introduced as another messaging service in WebLogic Server 9.0. As the name implies, the SAF service stores messages in a local cluster or domain and forwards them to their final destinations in a remote cluster or domain when the destinations are available. This service is exposed and managed through the configuration entity named SAFAgent, which is similar to JMSServer but acts as the container hosting the SAF imported destinations. The difference between the JMSServer and the SAFAgent in terms of the targeting is that the SAFAgent can be targeted to a cluster or a list of WebLogic Server instances as opposed to a single WebLogic Server instance for the JMSServer. As with JMS Servers, SAF Agents also uses an associated persistent store for storing persistent state information and hence face similar problems with unhealthy server and store issues leading to service downtime. Note that, the SAF agents can be configured to support Web-Service Reliable Messaging (WS-RM). In these scenarios, the system will only choose the nonmigratable SAFAgents for hosting the imported destinations to use with WS-RM. For more information on the SAF service, see . Path Service The Path Service is an optional persistent map singleton service that is used to store the mapping of a named sequence of messages (a JMS Message Unit-of-Order ) to a particular JMS Server or SAF Agent in a cluster. It provides a way to enforce ordering by pinning messages with same sequence name to the same physical location. This service is exposed and managed through the configuration entity named Path Service. There can only be one Path Service entity configured per Cluster, and again similar to the JMSServer and SAFAgent, the Path Service uses an associated persistent store to persist its data. For more information, see . Message Driven Beans (MDB) Message driven beans when configured to listen on a destination which is hosted by a migratable JMS server, would migrate along with the destination whenever the hosting JMSServer gets migrated. For more information, see . JTA Related Services The JTA Transaction Recovery Service (TRS) is designed to gracefully handle transaction recovery after a crash. Automatic migration of the Transaction Recovery Service leverages the Health Monitoring subsystem to monitor the health of the service hosted by a migratable target. When the primary server fails, the Automatic Service Migration in WebLogic Server Page 6
7 migratable service framework automatically migrates the Transaction Recovery Service to a backup server. The migration framework selects a backup server from the configured candidate servers. If a backup server fails before completing the migration actions, then you must attempt to manually re-migrate the Transaction Recovery Service to another backup server. For manual or automatic service migration, you must configure the default persistent store so that it stores records in a shared storage system that is accessible by any potential machine to which a failed migratable server might be migrated. In other words, you must restrict the potential servers to which you can migrate the Transaction Recovery Service to only those that have access to the default store files of the original server. For more information on TRS, see . User defined Singleton Services WebLogic Server also allows developers to create custom services that can act as Singleton services in the cluster. To act as a Singleton, the class must implement the weblogic.cluster.singleton.singletonservice interface. The SingletonService interface contains the following methods: public void activate() This method is called when the service is activated on any node in the cluster. public void deactivate() This method is called when the service gets deactivated on any node in the cluster. For more information on user defined singleton services, see  MIGRATION PROCESS As mentioned in the previous section, singleton services offer one of the highest qualities of service but are very susceptible to single point of failure. To address this issue, WebLogic server offers a solution called migration. Migration in WebLogic Server is the process of moving a clustered WebLogic Server instance or a subsystem component running on a clustered instance elsewhere in the event of failure. The process of moving the entire server instance from one physical machine to another upon failure is called Whole Server Migration (WSM). On the other hand, moving only the affected subsystem services from one server instance to another running server instance is called Service Migration. The whole server migration process was introduced in WebLogic Server 9.0 release. In this process, when a migratable server becomes unavailable for any reason, for example, if it hangs, loses network connectivity, or its host machine fails the Automatic Service Migration in WebLogic Server Page 7
8 server instance is automatically migrated. Upon server instance failure, a migratable server is automatically restarted on the same machine if possible. If the migratable server cannot be restarted on the machine where it failed, it is migrated to another machine. In addition, an administrator can manually initiate migration of a server instance. Please see section 0 for more details. Service Migration was added in WebLogic server 7.0. This technique provides the necessary infrastructure to manually migrate only the failed subsystem services from an unhealthy server instance to an available healthy server instance. However, manual migration needs human intervention (to detect the server/service failure and initiate the migration), which increases overall administration and ownership costs for WLS customers, as well as potentially leads to unpredictable service unavailability. In WebLogic Server 10.3, the entire process of service failure detection and recovery is fully automated with an improved migration framework. The Automatic Service Migration (ASM) framework now proactively monitors the health of the Singleton services and automatically migrates failing services to a healthy and available server instance in a cluster, thus greatly reducing the time taken to perform the migration and increasing the overall availability of these services. In rest of this paper, we talk about various infrastructure, framework, utilities, and tools that are in place to make the singleton services highly available in a clustered environment. SERVICE MIGRATION FRAMEWORK The service migration framework includes migratable targets, health monitoring service, leasing service, and node manager processes. Automatic Service Migration in WebLogic Server Page 8
9 SINGLETON LEASING SERVICE MIGRATION SERVICE MIGRATABLE TARGET MESSAGING JMS SERVER SERVICE MIGRATABLE TARGET SAF AGENT MIGRATABLE TARGET PATH SERVICE HEALTH MONITORING SERVICE PERSISTENT SERVICE FILE STORE JDBC STORE FILE STORE SAN JDBC Multipool Dual Ported SCSI Figure 1. High Level Architecture of JMS ASM Migratable Target A Migratable Target is a logical target that can host many migratable services. It serves as a grouping of services that you want to run together and migrate together. A migratable target in turn is associated with the cluster. A Migratable Target is hosted at any point in time by only one node in the cluster called the current hosting server. All of the migratable services targeted to the Migratable Target run on the cluster node hosting the Migratable Target. When the Migratable Target is migrated, all services hosted by that target are also migrated. Subsystem Health Monitoring Services The Server subsystem health monitoring service detects various adverse conditions which would affect a server s normal operations or performance (such as low memory, and IO errors that prevent data persistence), and then takes appropriate action to reduce service disruptions. Leasing Services Leasing services grant leases to server instances in a cluster to host migratable targets. These leases guarantee exclusive ownership of the migratable target. A migratable service is hosted on the server which holds the migratable target s lease. Each server renews their leases periodically so as to continue to host the migratable Automatic Service Migration in WebLogic Server Page 9
10 services. If a server crashes or is unable to renew its lease due to some other failure like a network partition, then the failed server s migratable services are migrated to a healthy server which acquires the lease. In the leasing services framework, one managed server instance in a cluster acts as Singleton Master, which is responsible for monitoring the health of all the Singleton and Migratable Services in that cluster, for migrating these services to a different WebLogic server instance within the cluster in case of failures, and for ensuring that a migratable target set of migratable services never runs on more than one server within the cluster. There are two options available to a WebLogic Cluster for handling leasing information. Database Leasing Leasing information is stored in a database. The database however must be highly available. Also each cluster node must be able to connect to the database in order to access leasing information. If the database is not available then automatic service migration framework will not work and all the migratable targets and singleton services will be deactivated in the cluster. Consensus Leasing information is stored in-memory of the cluster nodes. It does not require a highly available database, but it does require all cluster servers be started by a Node Manager process. The Node Manager process must always be running for consensus leasing to work properly. The node manager is explained in the next section. For more information on leasing services, see  Node Manager The Service Migration Framework depends upon the Node Manager to execute optional pre and post migration scripts, which are explained later in this paper. Also consensus leasing requires that servers be started and monitored by the Node Manager . CONFIGURING THE SERVICE MIGRATION FRAMEWORK Migration Basis (Leasing options) on a Cluster The Migration Basis determines the leasing service type database or consensus used by the migration service framework. See the previous section for guidance. The setting applies to the entire cluster. A Migratable Target provides the following configurable properties Note that the JTA transaction recovery service does not have an explicit MT. Automatic Service Migration in WebLogic Server Page 10
11 User Preferred Server (UPS) on MigratableTarget By default, every WebLogic Server instance comes with the migration counterpart which is named WLS Server instance name (migratable). Every Migratable Target requires that the administrator select one node in the cluster as its User Preferred Server (UPS). The migration service framework always tries to start the service first on its UPS, if it is available. Candidate Servers on MigratableTarget Candidate Servers define the set of servers where the Migratable Target could be migrated. It is a subset of the nodes in the cluster. If no candidate servers are defined for a Migratable Target, then all the nodes in the cluster become candidate servers and the Migratable Target could be migrated to any node in the cluster. Migration Policies A Migratable Target s Migration Policy controls whether migration automatically occurs in the event of a health failure or administrative shutdown. There are two automatic migration policies, Exactly-Once and Failure-Recovery, as well as a Manual policy for disabling automatic migration. The default policy is Manual. Exactly-Once The Exactly Once policy indicates that the service must always be active if at least one server in the candidate list is running. The Service is first tried to be started on its User-Preferred Server (UPS). But if the UPS is unavailable, then the service will be activated on some other candidate server in the cluster. If the server hosting the service fails or is shut down (either gracefully or forcibly), then the service will be migrated to another candidate server. Failure-Recovery The Failure-Recovery policy indicates that the service will only start if its User- Preferred Server (UPS) is started normally. If an administrator manually shuts down the UPS, either gracefully or forcibly, then a failure-recovery service will not migrate. However, if the UPS fails due to an internal error, that is detected by health monitoring service or if it crashes then the service will automatically migrate to another candidate server. This policy is useful when the migratable service needs to be started on a particular server in the cluster and it shouldn t be migrated if the server is shutdown. But if the server crashes, then the service should be migrated. Manual The Manual policy indicates that the service will not automatically migrate when the User-Preferred Server (UPS) for the service fails or is shutdown (either gracefully or forcibly). The administrator needs to manually migrate the migratable target from a failed node to a healthy node. Automatic Service Migration in WebLogic Server Page 11
12 Pre-Activation/Post-Deactivation Migration Scripts These optional scripts are executed by the migration framework just after the migratable services are deactivated on the original machine and just before migratable services are activated on the target machine. The migration framework asks the original and target WebLogic Servers Node Managers to execute these scripts. These scripts provides a mechanism to do any pre or post migration clean up tasks like mounting and un-mounting of shared partitions/file systems that needs to be available to the migratable services Post-deactivation script failure could be marked as fatal to block migration of migratable services if the script fails. In such a case, the administrator needs to manually migrate the migratable target after taking corrective actions for the script failure. Restart-In Place Migratable targets provide a restart-in-place option that attempts to deactivate and reactivate a failed service on the same cluster node instead of migrating it to another cluster node. The migration framework only attempts to restart a service if the services Migratable Target is unhealthy but the server's health is satisfactory (i.e., in a RUNNING state). If the server is not healthy, then the framework immediately proceeds to the migration stage, skipping all in-place restarts. The number of restart attempts and the time interval between attempts is configurable. If the Migratable Target fails to restart after the designated number of restart attempts, the framework will migrate the target to another server. For more information for configuring Migratable Targets, see  MIGRATION CONFIGURATION RULES AND BEST PRACTICES When using the Automatic Service Migration Feature, you must configure the "Migration Basis" for the cluster, enable automatic migration, and optionally specify whether you will be using any pre/post migration scripts. When a messaging subsystem service needs to be migrated then it cannot use the default store for its persistence and it must define a custom persistent store that is also targeted to the same Migratable Target as the service provider entity. A SAFAgent, a JMSServer, and a custom store can all share a migratable target. To preserve SAF message consistency, WebLogic Server prevents you from retargeting an existing SAF agent to a migratable target. Instead, you must delete the existing SAF agent and configure a new one with the same values and target it to a migratable target to preserve the message ordering. Automatic Service Migration in WebLogic Server Page 12
13 Targeting Rules JMS Servers When not using migratable targets, a JMS server can be targeted directly to a specific cluster member and may use either the host server s default file store or a custom store. However, when targeted to a migratable target, a JMS server must use a custom persistent store, and must be targeted to the same migratable target as the custom store. A JMS server, SAF agent, and custom store can share a migratable target. SAF Agents When not using migratable targets, a SAF agent can be targeted to an entire cluster or a list of multiple servers in a cluster, with the requirement that the SAF agent and each server in the cluster must use the default persistent store. However, when targeted to a migratable target, a SAF agent can only have one target. It must also use a custom persistent store, and, like a JMS server, must be targeted to the same migratable target used by the custom store. A SAF agent, JMS server, and custom store can share a migratable target. In addition, consider the following topics when targeting SAF agents to migratable targets. Re-targeting SAF Agents to Migratable Targets To preserve SAF message consistency, WebLogic Server prevents you from retargeting an existing SAF agent to a migratable target. Instead, you must delete the existing SAF agent and configure a new one with the same values and target it to a migratable target. Targeting Migratable SAF Agents for Increased Message Throughput When not using migratable targets, a SAF agent can be targeted to an entire cluster or multiple servers in a cluster for increased message throughput. However, When a SAF agent is targeted to a migratable target; it cannot be targeted to any other servers in the cluster, including an entire cluster. Therefore, if you want to increase throughput by importing a JMS destination to multiple SAF agents on separate servers in a cluster, then you should create migratable targets for each server in the cluster, and then create separate SAF agents that are targeted individually to each migratable target. Targeting SAF Agents for Consistent Quality-of-Service A WebLogic administrator has the freedom to configure and deploy multiple SAF agents in the same cluster or on the same server. As such, there could be situations where the same server has both migratable SAF agents and non-migratable ones. For such cases, the behavior of a JMS client application may vary depending on which SAF agent handles the messages. Automatic Service Migration in WebLogic Server Page 13
14 For example, an imported destination can be deployed to multiple SAF agents, and messages sent to the imported destination will be load-balanced among all SAF agents. If the list of the SAF agents contains non-migratable agents, the JMS client application may have a limited sense of HA (high availability). Therefore, a recommended best practice is to deploy an imported destination to one or more SAF agents that provide the same level of HA functionality. In other words, to get consistent forwarding quality and behavior, you should target the imported destination to a set of SAF agents that are all targeted to migratable targets or are all targeted to non-migratable targets. Path Service When not using migratable targets, a path service is targeted to single member of a cluster, and can use either the default file or a custom store. However, when targeted to a migratable target, a path service cannot use the default store, so a custom store must be configured and targeted to the same migratable target. As an additional best practice, the path service and its custom store should be the only users of that migratable target, whereas, a JMS server, SAF agent, and custom store can share a migratable target. Persistent Stores As mentioned previously, all JMS-related services require a custom persistent store that is also targeted to the same migratable targets as the JMS services. Migratable custom file stores can be configured on a shared disk that is available to the migratable target servers in the cluster or can be migrated to a backup server target by using pre/post-migration scripts. For highest reliability, use a shared storage solution that is itself highly available for example, a storage area network (SAN) or a dual-ported disk. JTA Transaction Recovery Service For JTA, migratable target configuration is not necessary for automatic or manual migration because a migratable target is automatically defined for JTA at the server level. The default migration policy for JTA is manual, but when configured for automatic migration, the JTA policy is internally set to failure-recovery. This means that Transaction Recovery Service will only start if its user-preferred server (UPS) is started. If an administrator shuts down the UPS either gracefully or forcefully, this service will not be migrated anywhere. However, if the UPS shuts down due to an internal error, then this service will be migrated to another candidate server. It is recommended that you attempt to restart a crashed server and allow the transaction Recovery Service to handle incomplete transactions, rather than migrate the Transaction Recovery Service to another server. However, if you anticipate that the server will be unavailable for an unacceptable length of time, you can migrate the Transaction Recovery Service to another service so that the backup server can complete transaction work for the failed server. Automatic Service Migration in WebLogic Server Page 14
15 SUBSYSTEM SERVICE MIGRATION VS WHOLE SERVER MIGRATION As described in Migration Process, in addition to automatic subsystem service migration, WebLogic Server supports the migration of the entire WebLogic Server instance, which is called as whole server migration or WSM. Whole server migration enables the transparent failover of the entire server instance from one physical machine to another thus providing the option for homogeneous service migration, or migrating everything together. As this needs to boot an entire WLS instance on new hardware, it usually takes a longer time to make the services available. Whereas, the automatic subsystem service migration (ASM) is primarily used for migrating pinned services such as JMS and JTA. Unlike, whole server migration, the automatic service migration supports both failover and failure recovery of the subsystem services and offers faster failover or recovery time compare to whole server migration. Users can choose to use either WSM or ASM or both. The decision to use which type of migration to use depends on a number factors, such as whether the user wants to migrate all the applications along with the JMS/JTA subsystem services or not. In general, the whole server migration is preferred for basic use due to its relative simplicity, but automatic service migration becomes attractive when faster fail-over times and advanced control over the service migration are desirable. When both are configured, the server will first try to first migrate the subsystem services and if that fails, then the whole server migration would take place. For more info on the whole server migration, please see [. TROUBLESHOOTING The following WebLogic debug flags would help diagnose any problems that arise in this feature area. The debug messages are logged in the appropriate server log files. Subsystem Area Information about the Singleton Monitor s actions If using Consensus Leasing To trace the JMSServer deployment/undeployment To trace the SAFAgent deployment/undeployment To trace the JMS Module deployment/undeployment To trace the Persistent Store deployment/undeployment Debug flag -Dweblogic.debug.DebugSingletonServices=true -Dweblogic.debug.DebugConsensusLeasing=true -Dweblogic.debug.DebugJMSBackEnd=true -Dweblogic.debug.DebugJMSSAF=true -Dweblogic.debug.DebugJMSModule=true -Dweblogic.debug.DebugStoreIOPhysical=true -Dweblogic.debug.DebugStoreIOLogical=true -Dweblogic.debug.DebugStoreIOLogicalBoot=true Automatic Service Migration in WebLogic Server Page 15
16 CONCLUSION WebLogic Server 10.3 delivers the fully automated service migration feature that eliminates the need for human intervention when making the singleton services highly available. Customers can now take advantage of this feature to reduce the total cost (TCO) associated with server administration. By making their enterprise applications highly available they can increase their overall return on investment (ROI) on the WebLogic Server platform. APPENDIX A: REFERENCES AND RELATED DOCUMENTS  WebLogic Persistent Store  WebLogic JMS Service  WebLogic Store and Forward Service  WebLogic Path Service  MDB Migration  WebLogic Transaction Recovery Service  Automatic Migration of User Defined Services  Leasing for Automatic Migration Services  Node Manager Administrator's Guide  Configuring Migratable Targets  Whole Server Migration Automatic Service Migration in WebLogic Server Page 16
17 Automatic Service Migration in WebLogic Server July 2008 Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA U.S.A. Worldwide Inquiries: Phone: Fax: oracle.com Copyright 2008, Oracle. All rights reserved. This document is provided for information purposes only and the contents hereof are subject to change without notice. This document is not warranted to be error-free, nor subject to any other warranties or conditions, whether expressed orally or implied in law, including implied warranties and conditions of merchantability or fitness for a particular purpose. We specifically disclaim any liability with respect to this document and no contractual obligations are formed either directly or indirectly by this document. This document may not be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose, without our prior written permission. Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners.
Backup and Recovery Scenarios for Oracle WebLogic Server: 10.3 An Oracle White Paper January, 2009 Maximum Availability Architecture Oracle Best Practices For High Availability Backup and Recovery Scenarios
An Oracle White Paper October 2011 BI Publisher 11g Scheduling & Apache ActiveMQ as JMS Provider Disclaimer The following is intended to outline our general product direction. It is intended for information
Oracle BI Publisher Enterprise Cluster Deployment An Oracle White Paper August 2007 Oracle BI Publisher Enterprise INTRODUCTION This paper covers Oracle BI Publisher cluster and high availability deployment.
An Oracle White Paper November 2010 Oracle Real Application Clusters One Node: The Always On Single-Instance Database Executive Summary... 1 Oracle Real Application Clusters One Node Overview... 1 Always
An Oracle White Paper July 2013 Accelerating Database Infrastructure Using Oracle Real Application Clusters 11g R2 and QLogic FabricCache Adapters Executive Overview Thousands of companies world-wide use
SaaS Data Architecture An Oracle White Paper Oct 2008 SaaS Data Architecture Introduction... 3 DATA ARCHITECTURE APPROACHES... 3 Separate Databases... 4 Shared Database, Separate Schemas... 4 Shared Database,
An Oracle White Paper January 2014 Managed Storage Services Designed to Meet Your Custom Needs for Availability, Reliability and Security A complete Storage Solution Oracle Managed Cloud Services (OMCS)
An Oracle White Paper February 2014 Oracle Data Integrator 12c Introduction Oracle Data Integrator (ODI) 12c is built on several components all working together around a centralized metadata repository.
An Oracle White Paper September 2011 Upgrade Methods for Upgrading to Oracle Database 11g Release 2 Introduction... 1 Database Upgrade Methods... 3 Database Upgrade Assistant (DBUA)... 3 Manual Upgrade...
Monitoring and Diagnosing Production Applications Using Oracle Application Diagnostics for Java An Oracle White Paper December 2007 Monitoring and Diagnosing Production Applications Using Oracle Application
Top Ten Reasons for Deploying Oracle Virtual Networking in Your Data Center Expect enhancements in performance, simplicity, and agility when deploying Oracle Virtual Networking in the data center. ORACLE
ORACLE VM MANAGEMENT PACK Effective use of virtualization promises to deliver significant cost savings and operational efficiencies. However, it does pose some management challenges that need to be addressed
An Oracle White Paper November 2010 Backup and Recovery with Oracle s Sun ZFS Storage Appliances and Oracle Recovery Manager Introduction...2 Oracle Backup and Recovery Solution Overview...3 Oracle Recovery
An Oracle White Paper July, 2012 Evolution from the Traditional Data Center to Exalogic: 1 Disclaimer The following is intended to outline our general product capabilities. It is intended for information
Oracle Primavera Contract Management, Business Intelligence Publisher Edition-Sizing Guide An Oracle White Paper July 2011 1 Disclaimer The following is intended to outline our general product direction.
An Oracle White Paper July 2013 Introducing the Oracle Home User Introduction Starting with Oracle Database 12c Release 1 (12.1), Oracle Database on Microsoft Windows supports the use of an Oracle Home
Code:1Z0-599 Titre: Oracle WebLogic Server 12c Essentials Version: Demo http://www.it-exams.fr/ QUESTION NO: 1 You deploy more than one application to the same WebLogic container. The security is set on
Running Oracle s PeopleSoft Human Capital Management on Oracle SuperCluster T5-8 O R A C L E W H I T E P A P E R L A S T U P D A T E D J U N E 2 0 15 Table of Contents Fully Integrated Hardware and Software
An Oracle White Paper November 2011 Upgrade Best Practices - Using the Oracle Upgrade Factory for Siebel Customer Relationship Management Executive Overview... 1 Introduction... 1 Standard Siebel CRM Upgrade
An Oracle White Paper September 2012 Oracle Database and the Oracle Database Cloud 1 Table of Contents Overview... 3 Cloud taxonomy... 4 The Cloud stack... 4 Differences between Cloud computing categories...
Oracle Primavera P6 Enterprise Project Portfolio Management Performance and Sizing Guide An Oracle White Paper October 2010 Disclaimer The following is intended to outline our general product direction.
Guide to Database as a Service (DBaaS) Part 2 Delivering Database as a Service to Your Organization Introduction There are often situations in which you need to spin up a new database. But in a traditional
Oracle Enterprise Single Sign-on Technical Guide An Oracle White Paper June 2009 EXECUTIVE OVERVIEW Enterprises these days generally have Microsoft Windows desktop users accessing diverse enterprise applications
Oracle Net Services for Oracle10g An Oracle White Paper May 2005 Oracle Net Services INTRODUCTION Oracle Database 10g is the first database designed for enterprise grid computing, the most flexible and
An Oracle White Paper November 2010 Leveraging Massively Parallel Processing in an Oracle Environment for Big Data Analytics 1 Introduction New applications such as web searches, recommendation engines,
Highmark Unifies Identity Data With Oracle Virtual Directory An Oracle White Paper January 2009 Highmark Unifies Identity Data With Oracle Virtual Directory Executive Summary... 3 The Challenge: A Single
An Oracle White Paper June 2013 Oracle Linux Management with Oracle Enterprise Manager 12c Introduction... 1 Oracle Enterprise Manager 12c Overview... 3 Managing Oracle Linux with Oracle Enterprise Manager
Oracle Primavera Gateway Disclaimer The following is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is
An Oracle White Paper May 2011 Exadata Smart Flash Cache and the Oracle Exadata Database Machine Exadata Smart Flash Cache... 2 Oracle Database 11g: The First Flash Optimized Database... 2 Exadata Smart
Manage Oracle Database Users and Roles Centrally in Active Directory or Sun Directory Overview August 2008 Introduction... 3 Centralizing DataBase Account Management using Existing Directories with OVD...
Next Generation Siebel Monitoring: A Real World Customer Experience An Oracle White Paper June 2010 Next Generation Siebel Monitoring: A Real World Customer Experience Table of Contents Introduction...
An Oracle White Paper September 2013 Oracle WebLogic Server 12c on Microsoft Windows Azure Table of Contents Introduction... 1 Getting Started: Creating a Single Virtual Machine... 2 Before You Begin...
An Oracle White Paper June 2012 High Performance Connectors for Load and Access of Data from Hadoop to Oracle Database Executive Overview... 1 Introduction... 1 Oracle Loader for Hadoop... 2 Oracle Direct
Load Balancing Oracle Web Applications An Oracle White Paper November 2004 Load Balancing Oracle Web Applications Introduction... 3 Load Balancing Implementation... 3 Architecture Overview... 3 Architecture
An Oracle White Paper July 2009 Oracle Application Development Tools Statement of Direction: Oracle Forms, Oracle Reports and Oracle Designer Disclaimer The following is intended to outline our general
An Oracle White Paper September 2012 Performance with the Oracle Database Cloud Multi-tenant architectures and resource sharing 1 Table of Contents Overview... 3 Performance and the Cloud... 4 Performance
Oracle Database Backup Service Secure Backup in the Oracle Cloud Today s organizations are increasingly adopting cloud-based IT solutions and migrating on-premises workloads to public clouds. The motivation
Configuring Oracle SDN Virtual Network Services on Netra Modular System ORACLE WHITE PAPER SEPTEMBER 2015 Introduction 1 Netra Modular System 2 Oracle SDN Virtual Network Services 3 Configuration Details
Oracle On Demand Infrastructure: Virtualization with Oracle VM An Oracle White Paper November 2007 Oracle On Demand Infrastructure: Virtualization with Oracle VM INTRODUCTION Oracle On Demand Infrastructure
An Oracle White Paper November 2012 Oracle Real-Time Scheduler Benchmark Demonstrates Superior Scalability for Large Service Organizations Introduction Large service organizations with greater than 5,000
An Oracle White Paper May 2011 BETTER INSIGHTS AND ALIGNMENT WITH BUSINESS INTELLIGENCE AND SCORECARDS 1 Introduction Business Intelligence systems have been helping organizations improve performance by
An Oracle White Paper October 2013 Oracle Data Integrator 12c (ODI12c) - Powering Big Data and Real-Time Business Analytics Introduction: The value of analytics is so widely recognized today that all mid
An Oracle White Paper June 2011 WebSphere MQ Oracle Enterprise Gateway Integration Guide 1 / 30 Disclaimer The following is intended to outline our general product direction. It is intended for information
JD Edwards EnterpriseOne 9.1 Clustering Best Practices with Oracle WebLogic Server An Oracle JD Edwards EnterpriseOne Red Paper December 2012 PURPOSE STATEMENT AND DISCLAIMER This document provides considerations
An Oracle White Paper May 2012 Oracle Database Cloud Service Executive Overview The Oracle Database Cloud Service provides a unique combination of the simplicity and ease of use promised by Cloud computing
June, 2015 Oracle s Siebel CRM Statement of Direction Client Platform Support Oracle s Siebel CRM Statement of Direction IP2016 Client Platform Support Disclaimer This document in any form, software or
An Oracle White Paper February 2009 Real-time Data Warehousing with ODI-EE Changed Data Capture Executive Overview Today s integration project teams face the daunting challenge of deploying integrations
ORACLE: Oracle Press Oracle WebLogic Server 11g Administration Handbook Sam R. Alapati Mc Graw Hill New York Chicago San Francisco Lisbon London Madrid Mexico City Milan New Delhi San Juan Seoul Singapore
An Oracle White Paper September 2013 Advanced Java Diagnostics and Monitoring Without Performance Overhead Introduction... 1 Non-Intrusive Profiling and Diagnostics... 2 JMX Console... 2 Java Flight Recorder...
Oracle Cloud Platform For Application Development Cloud computing is now broadly accepted as an economical way to share a pool of configurable computing resources. 87 percent of the businesses that participated
First Published January 2010 Updated October 2013 Oracle Data Integrator and Oracle Warehouse Builder Statement of Direction Disclaimer This document in any form, software or printed matter, contains proprietary
HA for Enterprise Clouds: Oracle Solaris Cluster & OpenStack Eve Kleinknecht / Thorsten Frueauf Oracle Keywords: OpenStack, High Availability, Solaris, Solaris Cluster, Oracle Introduction: More and more
An Oracle White Paper May 2011 Oracle Tuxedo: An Enterprise Platform for Dynamic Languages Introduction Dynamic languages, also sometimes known as scripting languages, have been in existence for a long
Oracle Recovery Manager 10g An Oracle White Paper November 2003 Oracle Recovery Manager 10g EXECUTIVE OVERVIEW A backup of the database may be the only means you have to protect the Oracle database from
Rapid Bottleneck Identification A Better Way to do Load Testing An Oracle White Paper June 2009 Rapid Bottleneck Identification A Better Way to do Load Testing. RBI combines a comprehensive understanding
Disaster Recovery for Oracle Database Zero Data Loss Recovery Appliance, Active Data Guard and Oracle GoldenGate ORACLE WHITE PAPER APRIL 2015 Overview Oracle Database provides three different approaches
Oracle VM Manager Template An Oracle White Paper February 2009 Oracle VM Manager Template Using the Oracle VM Manager Template to manage Oracle VM servers. Oracle VM is Oracle's own x86/x86-64 server virtualization
Enterprise Manager 10g Backup, Recovery and Disaster Recovery Considerations An Oracle White Paper March 2004 Enterprise Manager 10g Backup, Recovery and Disaster Recovery Considerations Introduction...
An Oracle White Paper December 2013 Advanced Network Compression Disclaimer The following is intended to outline our general product direction. It is intended for information purposes only, and may not
An Oracle White Paper June 2009 Integration Technologies for Primavera Solutions Introduction... 1 The Integration Challenge... 2 Integration Methods for Primavera Solutions... 2 Integration Application
Oracle Identity Management Concepts and Architecture An Oracle White Paper December 2003 Oracle Identity Management Concepts and Architecture Introduction... 3 Identity management... 3 What is Identity
An Oracle White Paper March 2013 Oracle s Single Server Solution for VDI Introduction The concept of running corporate desktops in virtual machines hosted on servers is a compelling proposition. In contrast
An Oracle White Paper July 2012 Oracle Identity Federation 11g R2 Frequently Asked Questions Disclaimer The following is intended to outline our general product direction. It is intended for information
An Oracle White Paper May 2011 Distributed Development Using Oracle Secure Global Desktop Introduction One of the biggest challenges software development organizations face today is how to provide software
Oracle Identity Analytics Architecture An Oracle White Paper July 2010 Disclaimer The following is intended to outline our general product direction. It is intended for information purposes only, and may
An Oracle White Paper January 2011 Using Oracle's StorageTek Search Accelerator Executive Summary...2 Introduction...2 The Problem with Searching Large Data Sets...3 The StorageTek Search Accelerator Solution...3
I. Basics 1. What is Application Server 2. The need for an Application Server 3. Java Application Solution Architecture 4. 3-tier architecture 5. Various commercial products in 3-tiers 6. The logic behind
An Oracle White Paper September 2010 Application Failover with Oracle Database 11g Summary This paper is a brief overview of high availability mechanisms built into the Oracle database server and its clients
CHAPTER 1 - JAVA EE OVERVIEW FOR ADMINISTRATORS Java EE Components Java EE Vendor Specifications Containers Java EE Blueprint Services JDBC Data Sources Java Naming and Directory Interface Java Message
Oracle Insurance General Agent Hardware and Software Requirements Version 8.0 April 2009 Table of Contents OIGA Hardware and Software Requirements... 3 OIGA Installation Configurations... 3 Oracle Insurance
Migration Best Practices for OpenSSO 8 and SAM 7.1 deployments O R A C L E W H I T E P A P E R M A R C H 2015 Disclaimer The following is intended to outline our general product direction. It is intended
Oracle Easy Connect Naming An Oracle White Paper October 2007 NOTE: The following is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated
Oracle Business Intelligence ADF Custom Visualizations and Integration An Oracle White Paper November 2012 Oracle Business Intelligence ADF Custom Visualizations and Integration OVERVIEW Business users
An Oracle Communications White Paper December 2014 Serialized Asset Lifecycle Management and Property Accountability Disclaimer The following is intended to outline our general product direction. It is
Oracle Data Guard: Disaster Recovery for Sun Oracle Database Machine Oracle Maximum Availability Architecture White Paper April 2010 Maximum Availability Architecture Oracle Best Practices For High Availability
An Oracle White Paper June, 2013 Enterprise Manager 12c Cloud Control Executive Overview... 2 Introduction... 2 Business Application Performance Monitoring... 3 Business Application... 4 User Experience
An Oracle White Paper November 2010 Oracle Business Intelligence Standard Edition One 11g Introduction Oracle Business Intelligence Standard Edition One is a complete, integrated BI system designed for
An Oracle White Paper February 2010 Rapid Bottleneck Identification - A Better Way to do Load Testing Introduction You re ready to launch a critical Web application. Ensuring good application performance
An Oracle Technical White Paper March 2014 Using Symantec NetBackup with VSS Snapshot to Perform a Backup of SAN LUNs in the Oracle ZFS Storage Appliance Introduction... 2 Overview... 3 Oracle ZFS Storage