An Oracle White Paper

Updated November 2009

Upgrading Siebel CRM with Zero Downtime

 Upgrading Siebel CRM with Zero Downtime

Executive Overview............................................................................. 1
Introduction ......................................................................................... 1
A Robust Solution for Zero-Downtime Siebel CRM Upgrades ............ 3
Oracle GoldenGate Application Architecture ...................................... 4
Key Features................................................................................... 5
Deployment Models for Zero-Downtime Siebel CRM Upgrades ......... 6
Unidirectional Deployment Model ................................................... 6
Active-Passive Deployment Model.................................................. 7
Active-Active Deployment Model .................................................... 8
Implementing a Zero-Downtime Siebel CRM Upgrade Solution ......... 9
Scope Phase................................................................................. 10
Design Phase................................................................................ 12
Build Phase ................................................................................... 16
Test Phase .................................................................................... 16
Deploy Phase................................................................................ 16
Ongoing Data Analysis.................................................................. 17
Conclusion ........................................................................................ 20
Appendix: Frequently Asked Questions ............................................ 21
 Upgrading Siebel CRM with Zero Downtime

Executive Overview
To take advantage of the latest features and functionality, many organizations are
interested in upgrading to the most recent version of Oracle’s Siebel Customer
Relationship Management (CRM). However, the upgrade process typically requires
downtime, which can disrupt business operations. This white paper discusses how
organizations can upgrade their Siebel CRM solutions with zero downtime using Oracle
GoldenGate. It further highlights the best practices for implementing Oracle GoldenGate
to overcome common upgrade challenges.

Introduction
Siebel CRM helps organizations across the globe differentiate themselves from their
competition for maximum growth. The application delivers comprehensive transactional,
analytical, and engagement CRM capabilities; tailored industry solutions; role-based
customer intelligence; and prebuilt integration. The latest version, Siebel CRM 8.1.1,
offers industry-specific solutions for self-service and customer loyalty management as
well as cost savings through the use of open standards.

Today, many organizations structure their Siebel CRM upgrade processes around batch-
oriented techniques. The upgrade process generally includes three major tasks: mass
data definition language (DDL) changes, bulk data loading or mass data manipulation
language (DML) operations, and reinstalling or changing the application executables.
Normally, such upgrades are performed in place, which requires the entire Siebel CRM
production enterprise to be unavailable for extended periods of time. As Siebel CRM
implementations have evolved from simple CRM systems to mission-critical, operational
business processes that must operate 24/7, more companies are finding it hard to justify
upgrading using an in-place upgrade method. This is especially true of companies with
very large databases, because downtime increases in proportion to database size.

1
 Upgrading Siebel CRM with Zero Downtime

As businesses compete globally for customers and revenue, the tolerance for any type of
system outage is approaching zero. Companies can no longer afford to perform long-
running operations such as upgrades, patches, maintenance, or even recovery. No
longer are three-day weekends available, because somewhere in the world, business
users will be affected. For this reason, companies with large Siebel CRM
implementations are hesitant to upgrade to the latest release. This is typically not due to
a lack of desire for the new features and functions but rather to avoid the potential lost
revenue caused by the downtime. Unfortunately, this means companies are increasingly
missing out on valuable new Siebel CRM capabilities that can drive business growth.
Fortunately, there is an alternative—Oracle GoldenGate.

2
 Upgrading Siebel CRM with Zero Downtime

A Robust Solution for Zero-Downtime Siebel CRM Upgrades

Oracle GoldenGate enables zero-downtime upgrades for mission-critical Siebel CRM
implementations. The solution allows companies to maximize revenue-generating activities with
the least amount of impact to business users by eliminating the need to take the Siebel
application instance down during an upgrade. Designed for reliability and flexibility, Oracle
GoldenGate is
 Noninvasive. The software uses a nonintrusive, low-overhead capture process that reads
changed data from database transaction logs and does not burden the source system.
 Fast. As changes are recorded, they are sent in real time to the target system being warmed up
for production. Changed data can be transformed for upgrade “in flight” and is continuously
applied until the customer switches over to the new application.
 Deployable in multiple models. Oracle GoldenGate components are loosely coupled and
preserve transaction integrity across a complete set of topologies: unidirectional, with data
flowing one way; active-passive, which provides a fail-back mechanism to the prior version;
and active-active, in which data freely flows between two application versions and users are
able to move between versions at any time.
Today, organizations need a Siebel CRM upgrade solution that is compact and nonintrusive—
one that runs in the background while users continue to access the old application to generate
revenue. Oracle GoldenGate’s unique software platform requires only 1 to 3 percent CPU usage
to operate and does not require any changes to the source schema. This is particularly important
for Siebel CRM applications because the physical data model is never out of sync with the logical
data model, as defined in the Oracle Database repository. The asynchronous, decoupled
architecture provides lightweight processes that capture changes made in the prior Siebel CRM
release and move them in real time to any number or type of target databases.
Deploying Oracle GoldenGate for zero-downtime Siebel CRM upgrades enables businesses to
 Reduce implementation time and cost. By removing the need to make invasive changes to
the source and target systems and by seamlessly moving data in real time, phased upgrades can
be implemented in a dramatically reduced timeframe.
 Leverage new Siebel CRM features. By removing downtimethe most significant upgrade
hurdleIT organizations can migrate users to new versions of Siebel CRM to take advantage
of more up-to-date features, such as integration with Oracle Fusion Middleware and the ability
to leverage more energy efficient hardware platforms.
 Remove the barriers of a single vendor operating platform. Oracle GoldenGate is
heterogeneous, so it provides the option to migrate to different operating systems and database

3
 Upgrading Siebel CRM with Zero Downtime

platforms. As with the application upgrade, from the perspective of the business user, there is
no downtime or penalty for making such a move.
 Maximize revenue-generating activities. By upgrading without downtime, organizations
can continue revenue-generating business operations without interruption.

Oracle GoldenGate Application Architecture

Oracle GoldenGate moves high volumes of changed data between heterogeneous databases with
subsecond latency while preserving transaction integrity. Leveraging decoupled components, the
software platform can be configured to enable a variety of solutions for continuous availability
and disaster tolerance as well as real-time data integration. The application is designed to allow
each component to perform its tasks independently of the others, which eliminates bottlenecks,
optimizes data transfer, and maximizes reliability.
Oracle GoldenGate consists of three modules: Capture, Trail Files, and Delivery (Figure 1).

Figure 1. Oracle GoldenGate leverages a decoupled architecture to optimize real-time data capture and transfer.

Capture Module

The Capture module resides on the source database and looks for new transactional activity.
Capture reads the result of insert, update, and delete operations by directly accessing the
database’s transaction (redo) logs, and then immediately captures that new data for distribution.
The Capture module supports a wide range of database versions, including Oracle Database,
Microsoft SQL Server, IBM DB2 mainframe and LUW, Ingres, Sybase, Enscribe, SQL/MP,
SQL/MX, and Teradata running on Linux, UNIX, Windows, z/OS, and HP NonStop
platforms.
To reduce infrastructure load and eliminate data inconsistencies, the Capture module moves only
committed transactions (intermediate activities and rolled-back operations are filtered out).
Further optimization can be achieved through transaction grouping and compression.

4
 Upgrading Siebel CRM with Zero Downtime

Trail Files Module

Trail Files are part of the Oracle GoldenGate queuing mechanism and store the captured
changed data in a transportable, platform-independent universal data format. Trail Files reside on
the source and target server but exist outside the databases to ensure heterogeneity, improved
reliability, and minimal data loss. This architecture minimizes any impact on the source system
because no additional tables or multiple queries to the database are required to support the
capture processes. The Capture module reads once, then immediately moves the captured data to
the external Trail Files for delivery to the target(s).
If there is an outage at the source or the target, Trail Files contain the most recently changed data
up to the point of the outage, which are applied once the systems are back online.

Delivery Module

The Delivery module takes the data transactions from the latest Trail File and applies that data to
the target using the native SQL for the relevant database management system—delivery can be
made to any Open Database Connectivitycompliant database. The Delivery module applies
each transaction in the same order as it was committed and within the same transactional context
as at the source, to ensure consistency and referential integrity at the target. Delivery uses a
number of techniques to optimize the application of data to the target, and changed data can be
provided as a flat file to integrate with third-party extract, transform, and load products. Oracle
GoldenGate can format text in any way, including but not limited to XML and delimited format
to be published to enterprise messaging systems.

Key Features
The following Oracle GoldenGate features facilitate and streamline the upgrade process.
 Transformations and mappings. Oracle GoldenGate can flexibly accommodate
transformations and mappings within either its Capture or Delivery moduleswithout
requiring a middle-tier server. The application supports table and row filtering based on user-
defined criteria, and explicit mapping and transformation rules can be applied via native
functions, user-supplied code, and stored procedures. These rules can range from simple
column assignments to more-complex transformations, for which the application provides a
suite of date, math, string, and utility functions.
 Flexible topology support. Oracle GoldenGate’s architecture allows customers to support a
variety of topologies, including one source to one target, one-to-many, many-to-one, many-to-
many, cascading, and bidirectional configurations. For example, Oracle GoldenGate allows a
configuration in which a second Capture component, called a Pump, continuously pushes the
Trail Files from the source system to multiple target systems.
 Conflict detection and resolution. Bidirectional implementations with more than one active
database require conflict detection and resolution capabilities, because both systems are

5
 Upgrading Siebel CRM with Zero Downtime

actively processing and sharing database transactions. Oracle GoldenGate provides conflict
detection and resolution options that can be implemented globally, object by object, based on
data values, complex filters, and event-driven criteria.
 Routing and compression. Oracle GoldenGate uses TCP/IP for sending data, so no
geographical distance constraints are imposed between the source and target systems. An
additional compression process can be applied to the data as it is routed.
 Data encryption. Oracle GoldenGate offers encryption to ensure secure, confidential data
transmissions both domestically and internationally.

Deployment Models for Zero-Downtime Siebel CRM Upgrades

Oracle GoldenGate uses three well-established deployment models for zero-downtime upgrades.
 Unidirectional. Changed data flows in one direction with a static fail-back environment.
 Active-passive. Changed data flows in one direction with a dynamic fail-back environment.
 Active-active. Changed data flows freely in both directions.
Each of these deployment models is presented in the following subsections in order of
complexity and risk-reduction capability.

Unidirectional Deployment Model

For a unidirectional deployment, changed data flows in one direction and is transformed for the
new Siebel CRM version in flight. To accomplish this, the Oracle GoldenGate Capture module is
enabled on the source (prior version of Siebel CRM) to capture any changes as they are made in
the Siebel CRM database. A parallel, target environment is established with a copy of the source
database, which is then upgraded to the new target version. Depending on the Siebel CRM
version being used, a database upgrade might need to take place.
Once the Siebel CRM upgrade is complete, the changes captured in the source database are sent
to the target and transformed in flight using the upgrade logic derived from the in-place version
of the Siebel CRM upgrade. At this point, the model is complete and ready for the customer to
cut over to the new version (Figure 2). Users are moved en masse to the new version of Siebel
CRM simply by shutting down and restarting their browser and pointing to the new URL.

6
 Upgrading Siebel CRM with Zero Downtime

Figure 2. In a unidirectional deployment model, data flows in one direction from the source to the target.

During the cut-over process, the Capture module and the prior Siebel CRM version are shut
down. The old Siebel CRM environment is left intact and remains at a specific point in time, until
the business decides the risk of removing the old system is zero. If the customer is forced to
cease using the new Siebel CRM version, the prior environment is available, but the data would
be current as of the cut-over time. Any subsequent changes made in the new version would not
be present.

Active-Passive Deployment Model

For customers that want the ability to fail back and retain any changed data, the option is
available to deploy an active-passive model. This model is based on the unidirectional model but
extended to provide customers the ability to switch back from the new Siebel CRM version to
the prior version in a worst-case scenario. This would be accomplished by implementing the
Oracle GoldenGate processes in reverse to flow changed data from the new version back to the
prior version and “downgrading” the changes in flight. Downgrading is the process by which the
schema of the new Siebel CRM version is mapped to the prior version, and changed data is
transformed using logic that has been reverse engineered from the upgrade logic.
This active-passive model enables customers to go back to the prior version of Siebel CRM,
without the loss of data. All users are required to be active on one version of Siebel CRM at any
time; the user community would not be able to be split between the two application versions
(Figure 3).

7
 Upgrading Siebel CRM with Zero Downtime

Figure 3. In an active-passive deployment model, data is captured on the target and replicated on the source to provide a backup instance.

Active-Active Deployment Model

The third deployment model, which is the most complex, is the active-active model. The key
feature of this model is that changed data moves freely from the prior version of Siebel CRM to
the new version and vice versa in a bidirectional manner. Depending on the source of the
change, data is either transformed for upgrade or downgrade in flight to meet the requirements
of the target version. Users have the option to log in to either of the two environments as
needed, without any data loss. Conflict detection and resolution are used to avoid any referential
integrity issues.
The active-active deployment model is typically used to move users in phases from a prior
version of Siebel CRM to a new version. The environment used for the prior Siebel CRM version
is be left intact and synchronized until it is no longer needed (Figure 4).

8
 Upgrading Siebel CRM with Zero Downtime

Figure 4. In an active-active deployment, changes on the source and target are replicated to keep two instances in sync for real-time use.

Implementing a Zero-Downtime Siebel CRM Upgrade Solution

Deploying Oracle GoldenGate for zero-downtime Siebel CRM upgrades requires a specific
configuration for each deployment model. The implementation of the solution follows a standard
methodology consisting of five phasesscope, design, build, test, and deploy (Figure 5).

Figure 5. Oracle GoldenGate supports a robust and flexible methodology for zero-downtime upgrades.

Most implementations follow a typical systems development lifecycle. To aid you in developing a
complete picture of the implementation process for Oracle GoldenGate in a zero-downtime
Siebel CRM upgrade environment, the following subsections describe the types of tasks
associated with each phase of the above methodology, as well as best practice recommendations.

9
 Upgrading Siebel CRM with Zero Downtime

Scope Phase
In the scope phase, the boundaries of the project are set. The goal of this phase is to capture as
much detail as possible for all the individual components of the solution and to determine the
most appropriate deployment model to meet the business requirements.

Requirements Gathering

The following list summarizes key information that must be collected from each environment.
 Source (prior version of Siebel CRM)
 Physical location
 Relational database management system (RDBMS) vendor and version
 RDBMS host operating system, version, hardware vendor, and number of CPUs or cores
 Data model of the source Siebel CRM system, including base tables, base columns, custom
extension columns, and tables to be replicated to the target (new version of Siebel CRM)
 Usage of the Siebel Remote module in Siebel CRM
 Timing and frequency of Siebel CRM’s Enterprise Integration Manager batch jobs
 Note: Identify volume of changes because these could affect future performance tuning
 Target (new version of Siebel CRM)
 Physical location
 Note: If source and target are remote, determine whether network will support real-time replication
 RDBMS vendor and version
 Note: Determine need for a database upgrade or migration at this time
 RDBMS host operating system, version, hardware vendor, and number of CPUs or cores
 Data model for the target Siebel CRM system, including base tables, base columns, custom
extension columns, and tables to be used in the new configuration
 Siebel CRM Upgrade SQL
 Note: Identify statements in Siebel CRM upgrade scripts that affect or use target base tables or columns in
the new Siebel CRM configuration

Best Practices for Choosing a Deployment Model

As previously discussed, the deployment models (unidirectional, active-passive, active-active)

have progressively more-complex scopes, and the scope greatly affects the level of effort. Below
are the key factors and decision steps that help with choosing the best deployment model.

10
 Upgrading Siebel CRM with Zero Downtime

Determine the Transition Method Requirements When Switching Application Versions

Understanding how the business wants to conduct the transition to the new application version
impacts the deployment method. If business continuity is a primary concern, the company might
choose to do a phased migration to the new application, instead of moving all the users to the
new application at once. A gradual migration, which is provided by the active-active deployment
model, might be the most feasible method especially if there are many users and asking them all
to switch versions of the application is going to significantly impact business operations.

Determine the Duration of Retention for the Prior Siebel CRM Version

As a general guideline, retain the prior Siebel CRM implementation until the business determines
that there is no risk in decommissioning the hardware. This is particularly important with
implementations that use the Siebel Remote module, because there are regulatory compliance
issues mandating that absolutely no data can be lost during an upgradeas is often the case with
Siebel CRM implementations in the pharmaceutical and life sciences industries.
In a typical Siebel CRM implementation in pharmaceuticals, for example, company
representatives use Siebel Remote to work with customers in the field with a local database
containing a subset of data. The compliance issue comes into effect when planning an upgrade,
because every Siebel Remote user will need to check in their changes before the upgrade. If any
of the representatives fail to do so for any reason, then any unchecked-in data on remote users’
local databases will not be included in the upgrade. In this situation, the representative would
have to re-enter the data, or IT would have to manually recover it from the local database;
otherwise, the data would be lost. This problem is amplified with very large Siebel Remote
implementations involving thousands of users due to the difficulty in coordinating a large
number of users to check in changes.
The Oracle GoldenGate zero-downtime upgrade process for Siebel CRM allows the prior Siebel
CRM implementation to be left intact while the majority of the user population moves to the
new Siebel CRM version. By having the prior implementation available in an active-active
configuration, Siebel Remote users gain an extended check-in period. When the prior and new
applications run in parallel, Siebel Remote users can check in their changes to the prior version.
Oracle GoldenGate allows those changes to flow to the new version seamlessly, enabling Siebel
Remote users to immediately start using the new version without any data loss.
In this configuration, the prior system is retained until all the Siebel Remote users check in their
changes, which could take a day or a few weeks. Oracle GoldenGate imposes no artificial time
constraints that would force the shutdown of the prior Siebel CRM implementation.

11
 Upgrading Siebel CRM with Zero Downtime

Determine the Level of Risk Tolerance

It is critical to determine the level of risk the company is willing to bear.

 High risk. In this case, the business does not require that the prior Siebel CRM release be
kept in sync with the new Siebel CRM version after cut-over to be able to use it for fail-back.
Due to its relative simplicity for deployment, a unidirectional model should be considered.
 Medium risk. To be able to fail back in case of a problem with the new application version,
the business can require that the prior Siebel CRM release be available and up to date with
Siebel CRM 8, but users are only on one version at a time. An active-passive deployment
model will meet the needs for this business environment.
 Low risk. The business requires that both the new and prior release of Siebel CRM be
available and users be able to seamlessly use either application version without loss of data.
The active-active deployment will be needed to meet these requirements by enabling two
environments to be in production at the same time.

Design Phase
Using the information gathered in the scope phase, the design phase is primarily focused around
four main tasks:
 Source-to-target data mapping. This involves mapping Siebel CRM base tables, custom
extension tables, and columns from the prior version of Siebel CRM to the new version, and
vice versa depending on the deployment model.
 Upgrade and downgrade transformations. Identify those Siebel CRM upgrade SQL
statements that will need to be included either as an upgrade transformation (for changed data
from the prior Siebel CRM version flowing to the new version) or as a downgrade
transformation to support a passive fail-back or active-active implementation.
 Target (new Siebel CRM version) initialization method. There are many different
methods for instantiating a target environment, but the goal is always the same: to establish a
copy of the existing production Siebel CRM database in the target Siebel CRM environment
for a known date and time.
 Performance. Identifying potential performance bottlenecks (such as heavily hit base tables or
very large volume changes from Siebel CRM’s Enterprise Integration Manager) and planning
for them early on in the process will significantly streamline the roll-out process.
In addition to these four tasks, the design phase should include a more-detailed analysis of the
time required to build the final solution.

12
 Upgrading Siebel CRM with Zero Downtime

Best Practices for Data Mapping: Determine the Source Tables for Data Capture

Different methods exist to determine what Siebel CRM base tables and columns in the source
database need to be captured. Ideally, the Siebel CRM architect can identify those tables used in
the configuration. Also, depending on the new version of Siebel CRM, the business could choose
to abandon or archive some information in lieu of a new feature or option. Ultimately, the best
method for determining which tables to capture should include both business users and
application developers.
Determining which source Siebel CRM base tables and columns to capture from is also key to
understanding which statements of the in-place Siebel CRM upgrade process need to be
reviewed. Comparing the upgrade logs, which include statement execution times, to the list of
source tables helps to determine the number and extent of transformations needed.
In general, the process entails starting with one-to-one mapping of tables and columns,
identifying target columns that are not in the source, and identifying columns that need
transformation.

Source and Target Schema Review

Source and target schemas must be analyzed to find items that will impact the upgrade, including
 Primary keys and unique identifiers
 Cascade update and cascade delete constraints
 DML triggers
 Indexes
 Secondary unique indexes and constraints on target database
 Unsupported database object names

Mapping Source Tables/Columns to Target Tables/Columns

Many application vendors, including Oracle, have adopted the additive schema approach,
whereby new versions of the application only add tables, columns, and indexes, and nothing is
dropped. These particular types of upgrades might seem simpler when creating mappings from
one version to another, but keep in mind that even though a source column is mapped to a like
column in the target, the following guidelines should be taken into account:
 Source and target datatypes need to be compatible.
 Application vendors could abandon tables and move the data to other tables to support new
features and functions. Although the tables are retained, it will remain empty. Subsequent
transformations could be required to handle data movement.
 Column data values could be changed to support new functionality.

13
 Upgrading Siebel CRM with Zero Downtime

Best Practice for Data Transformations

To accommodate the newly introduced and modified functionalities in the newer version of
Siebel CRM, upgrades could involve not only data movement between different Siebel CRM base
tables, but also schema changes. In a traditional Siebel CRM in-place upgrade, changes to the
schema are performed as a series of batch operations while the system is down. To support a
zero-downtime upgrade, the target system is upgraded to the new version and incorporates the
schema changes. The changed data flows from the prior version to the new version of the
application, and potentially from the new version back to the prior version, in the case of an
active-passive or an active-active implementation. To work between two different application
versions, changed data has to be upgraded or downgraded in flight. For that purpose, the
upgrade statements used in the in-place batch upgrade needs to be converted or reverse
engineered. These statements need to be included in the Oracle GoldenGate Capture module or
Delivery module processes so that after each transaction is captured, it goes through the
applicable transformations as if it were going through the in-place upgrade.
In the design phase, there are multiple implementation techniques for embedding the upgrade or
downgrade transformation logic into Oracle GoldenGate. Such techniques include using Oracle
GoldenGate functions or using an SQLEXEC with a modified SQL statement, a procedural
SQL block, or a stored procedure.
The following options, provided by Oracle GoldenGate, are typically implemented for data
manipulation purposes:
 Built-in functions. Explicit mapping and transformation rules can be applied via a suite of
built-in Oracle GoldenGate functions that perform manipulations such as converting strings
and numbers, extracting portions of strings or concatenating columns, comparing strings and
numbers, and performing a variety of date mappings. Upgrade SQL statements can be
converted using these functions to streamline the transaction and improve performance.
 SQL procedures and queries through SQLEXEC. This technique allows you to execute a
database command, a stored procedure, or a SQL query to return results (select statements),
perform a DML operation, or run a database-specific function. Error handling is available
when using SQLEXEC. For example, one or more SQL select statements that involve multiple
tables are executed first to identify the records that satisfy the transformation requirements
before running a DML statement. If no records meet the requirement, the DML is skipped.
Typically this option is sufficient to handle most data transformation requirements.
 Macros. For any repetitive transformation logic, Oracle GoldenGate macros can be used
within the Capture and Delivery processes to simplify the configuration files.
 User exits (such as custom routines written in C). This option could be used in
conjunction with functions provided by Oracle GoldenGate or as an alternative. User exits can
provide performance advantages because data is only processed once when they are extracted.
User exits are typically used only in the most complex transformations.

14
 Upgrading Siebel CRM with Zero Downtime

Note that if a table was modified multiple times during the upgrade process, it is best to consider
consolidating these statements so they appear together under one mapping statement. If that is
not feasible, then simply configure one mapping for each modification, and Oracle GoldenGate’s
processes will run them in sequence to guarantee upgrade integrity. Also, DML SQL statements
that always end up modifying the same set of database records, regardless of when the underlying
production data set is captured, do not need to be included in the replication process because
they have been executed during the plain vanilla application upgrade run during the initial target
setup.

Target Initialization

There are several methods and tools for instantiating the target Siebel CRM database, including
bulk data export utilities; bulk data import utilities; disk mirroring, where a mirrored set of drives
is mounted on the target database server; and simple backup and restore procedures. For Oracle
Database, Oracle’s transportable tablespace feature can be used as well.

Best Practice for Designing for Performance

It is best to design an upgrade solution with a focus on performance from the beginning. Leading
metrics, specifically DML operations per table, from the production database server will aid in
determining the best approach.
To collect DML (insert, update, delete) statistics over a period of time, the individual RDBMS
vendors provide a number of methods. (A discussion of each of the methods is beyond the
scope of this document.) Use the DML statistics and focus on the top 20 percent of the tables
generating the highest volume of transactions to develop a short list of entities that might cause
lag to the Capture, Pump, or Delivery processes. Along with tuning of the Oracle GoldenGate
processes, potential design considerations for the deployment include
 Multiple Capture processes on the source. Oracle GoldenGate’s modular approach enables
multiple Capture processes to run on the source system to keep up with high volumes.
 Multiple Pump processes on the source. Introducing Oracle GoldenGate’s Pump processes
helps with routing larger volumes of changed data, if the network capacity is insufficient for
the volume of data being sent to the target. Another option is to compress the Trail Files.
 Multiple Delivery processes on the target with array apply. There are no limits on the
number of Delivery processes to be used on the target. Further, Oracle GoldenGate enables
fast performance via its ability to perform smart transaction grouping and to apply data in
arrays in a single database operation.

15
 Upgrading Siebel CRM with Zero Downtime

Build Phase
Otherwise known as the development phase, the build phase for a zero-downtime upgrade
involves creating Oracle GoldenGate parameter files, translating and developing the required
transformations, and configuring Oracle GoldenGate for performance and unit testing.

Test Phase
Testing of the upgrade solution is multifaceted.
 Throughput testing. Determine the need for performance tuning under a production-size
load.
 Data quality analysis. Make sure mappings are correct and the transformations yielded the
correct result, as compared to a standard out-of-the-box upgrade.
 Application regression testing. Work in conjunction with the application development team
to ensure the new version of the application (target) works as expected.

Deploy Phase
The process of deploying the zero-downtime upgrade solution into production varies by
deployment model; the complexity of the model will dictate the number of steps involved. Each
step of the deployment process establishes a particular flow of changed data, such as from the
prior version to the new version or from the new version to the prior version. Regardless, the
deployment process always begins in the same manner: the creation and initialization of the
target environment. The advanced deployment models are built in succession, starting with the
unidirectional model.

Unidirectional Model

At a high-level, the deployment process for a unidirectional model entails the following:
 Establish the target environment, including application, Web, and database servers.
 Start the Oracle GoldenGate Capture process in the source environment.
 Copy the source database to the target database server and instantiate the database.
 Upgrade the copy.
 Enable the Delivery process on the target and synchronize the target with the source.
 Execute quality assurance (QA) processes.
If this were the final goal of the deployment, after QA, a cut-over would be scheduled whereby
users would be moved to the new Siebel CRM version en masse.

16
 Upgrading Siebel CRM with Zero Downtime

Active-Passive Model

The implementation of a passive fail-back feature is deployed as an addition to a unidirectional

deployment, once the flow of changed data from the prior Siebel CRM version to the new
version is established and tested. The passive fail-back option establishes the flow of changed
data from the new version to the prior, which includes downgrade transformations, before any
users are active on the new version of Siebel CRM. Test cases can be injected into the new
version, which will then flow back to the prior version, providing the means to QA the
downgrade transformations.
For the active-passive deployment model, add the following steps to the steps outlined in the
unidirectional deployment model:
 Enable the Capture process on the new Siebel CRM version.
 Enable the Delivery process on the prior version.
 Perform QA testing.
Once the QA process is complete, the business can schedule a cut-over whereby users are moved
to the new Siebel CRM version en masse. The passive fail-back option would be used only in the
worst-case scenario when the business needs to go back to the prior application version.

Active-Active Model

Building on the active-passive model, in the active-active deployment model, data flows in both
directions simultaneously because both prior and new versions of the Siebel CRM application
would be open for transaction processing. In this configuration, it is possible that the same row
in a table is changed by both versions of the applications; therefore, the active-active model
needs to incorporate conflict detection and resolution steps.
The additional step for active-active deployments is simply to
 Enable conflict detection and resolution process
With this model, end users can gradually, typically in groups, switch from the prior version of
Siebel CRM to the new version. The completion time for switchover is flexible and can be
determined by the business requirements.

Ongoing Data Analysis

Data quality analysis is not a one-time event, and throughout the production rollout, data must
be checked regularly to ensure correctness as it moves from one application version to another.
Typically, this process coincides with application regression testing, in which users spot-check the
data while testing the application.
In addition to counting the rows in the source and target databases and making visual
comparisons, the following two options can aid in the data analysis process. The first is a method

17
 Upgrading Siebel CRM with Zero Downtime

to check referential integrity within the Siebel CRM data model, and the second is a data
validation method using Oracle GoldenGate Veridata, a high-speed data comparison tool.

Best Practice for Validating Referential Integrity

Siebel CRM supplies a dbcheck utility that is used to identify any gaps in referential integrity for
the Siebel CRM tables involved in the data movement process. Dbcheck reads the foreign key
relationships from the Siebel CRM metadata repository, and then compares those relationships
to the physical data stored within the Siebel CRM database schema. Rows that fail to meet the
requirements of the foreign key constraint are logged for examination.
Be aware that running dbcheck can be time consuming, depending on the number of rows and
foreign key relationships, and it can tax server resources. The recommended method is to use the
“/to” option, without the “/dict /all” modes, which limits the referential integrity check to a
target set of tables rather than the entire dictionary.

Best Practice for Validating Data Consistency

As previously discussed, deploying Oracle GoldenGate for zero-downtime Siebel CRM upgrades
involves creating a live parallel copy of the production database, upgrading the copy, and keeping
it in sync with the prior version using Oracle GoldenGate before switchover. During the data
movement, discrepancies can arise as result of infrastructure problems, application errors,
configuration errors, and unexpected user behavior. It is important to identify and eliminate
these inconsistencies before switchover to avoid operational, financial, or regulatory risk.
Oracle GoldenGate Veridata is a high-speed data comparison solution that identifies and reports
data discrepancies between databases without interrupting ongoing business processes. Using this
application, users can quickly compare the contents of the source and target databases.
To set up the comparison in a test environment, the first step is to create a target by upgrading
one of the database copies to a new version of Siebel CRM; the source database is left at the
prior version. Oracle GoldenGate is then configured to apply changed data captured between the
source and target environments. Once Oracle GoldenGate processes are configured and running,
a series of test scenarios are run against the source to generate a known set of data changes and
applied to the target using Oracle GoldenGate’s transformation logic. After the test data is
applied to the target, Oracle GoldenGate processes are shut down on both the source and target,
resulting in a common point in time for data comparison.
The source (prior version of Siebel CRM) is then upgraded to the new version of Siebel CRM
using the in-place Siebel CRM upgrade scripts. Once the upgrade is complete, the key base tables
on the source and target should have identical data, which can be verified using Oracle
GoldenGate Veridata.
Oracle GoldenGate Veridata is able to compare the data contents of the key Siebel CRM base
tables used in the replication process to determine if any data differences exist, as shown in

18
 Upgrading Siebel CRM with Zero Downtime

Figure 6. Differences between key tables would indicate that the transformation logic embedded
in Oracle GoldenGate was not correctly coded. If the two schemas are identical, this would
indicate that the transformation results were coded correctly and yielded the same values for the
changed data as compared to the in-place upgrade logic.

Figure 6. Oracle GoldenGate Veridata compares the results of data replication to ensure accuracy across databases.

19
 Upgrading Siebel CRM with Zero Downtime

Conclusion
Today’s organizations cannot remain competitive with outdated solutions, yet they cannot afford
to experience extended downtime. Through robust data replication and migration capabilities,
Oracle GoldenGate offers organizations the best of both worlds: the ability to leverage the latest
Siebel CRM solutions from Oracle without interrupting daily operations. The application
supports a number of topologies that allow organizations to flexibly define their upgrade
approach using a simple unidirectional model or a more advanced dual system configuration.
Regardless of the chosen approach, Oracle GoldenGate eliminates downtime and enables
continuous access to mission-critical systems, thereby removing the most common barrier to
application upgrades. Now Siebel CRM users can quickly implement the latest application
functionality to optimize their business processes and achieve more-efficient, higher value results.

20
 Upgrading Siebel CRM with Zero Downtime

Appendix: Frequently Asked Questions

Which versions of Siebel CRM are supported?

Oracle GoldenGate supports all current and past versions of Siebel CRM applications and the
RDBMS versions they support, including Oracle Database, IBM DB2, and SQL Server.

Once Siebel CRM 8 is synchronized with the prior version, how long can the systems run in parallel?

There are no time constraints with any of the deployment models. Keep in mind that once the
two systems are synchronized in production, a QA period is typical to assure the business that
the new environment is ready for users. Typically, both the new application environment and its
data are checked during this QA process before any users are allowed to log in to the system.

Can this solution be used to eliminate downtime during application upgrades (such as releasing a new
Siebel CRM repository to production within the same Siebel CRM version)? Are two separate Siebel
application environments required?

Yes. The zero-downtime solution can be used for like versions of Siebel CRM to support the
release of new Siebel CRM repositories into production. The implementation is typically less
complex than an upgrade because there are fewer or no transformations. Two separate, parallel
Siebel CRM instances would be required, and any of the three deployment models could be
implemented. At a high level, the process involves performing the repository release on the
secondary system and redirecting users to that system when the release is complete.

Are there validation techniques available to perform data consistency analysis between source and
target?

Yes. In this white paper, the validation technique is discussed using Oracle GoldenGate Veridata
to aid projects in the analysis of data between the source and target. Please see that section for
additional details.

When implementing a zero-downtime upgrade for Siebel CRM, what considerations should be made for
external interfaces?

The new implementation of Siebel CRM 8 will require its own external interfaces to support the
business requirements. The key to reusing existing interfaces, such as those available in the prior
Siebel CRM implementation, is that these interfaces need to be source-system aware. This is
most important for implementations of the active-active deployment model, because business
users will be using both systems in parallel, and responses need to be routed to the Siebel CRM
system that originated the message.

21
 Upgrading Siebel CRM with Zero Downtime

How much customization is needed to implement Oracle GoldenGate for a zero-downtime Siebel CRM
upgrade?

Oracle GoldenGate is the same across all platforms and can be used in many configurations. As
each implementation of Siebel CRM is unique, each implementation of Oracle GoldenGate for a
zero-downtime Siebel CRM upgrade will require some customization, especially for the
transformations. The process of implementing a zero-downtime upgrade solution involves
encoding the upgrade transformation logic—and potentially the downgrade transformation
logic—into the Oracle GoldenGate Delivery processes.

Can a Siebel CRM database migration, such as from IBM DB2 to Oracle Database, be incorporated into
the zero-downtime upgrade for Siebel CRM implementation?

Yes. Oracle GoldenGate provides heterogeneous data movement and can run on multiple
operating systems, which means a database migration can be included in the application upgrade
process. An additional phase, prior to upgrading the parallel Siebel CRM system, would be
required to move the data from the source database system to the target database. It is important
to point out that this additional phase of the upgrade does not introduce any downtime.

Do the source and target operating systems of the database server have to be the same?

No. Oracle GoldenGate is available for all supported Siebel CRM database server operating
systems from Oracle on the source and target systems. For instance, the source database server
operating system could be AIX and the target operating system could be Linux.

22
Upgrading Siebel CRM with Zero Downtime
Updated November 2009

Copyright © 2009, Oracle and/or its affiliates. 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
Oracle Corporation
warranties or conditions, whether expressed orally or implied in law, including implied warranties and conditions of merchantability or
World Headquarters
fitness for a particular purpose. We specifically disclaim any liability with respect to this document and no contractual obligations are
500 Oracle Parkway
formed either directly or indirectly by this document. This document may not be reproduced or transmitted in any form or by any
Redwood Shores, CA 94065
means, electronic or mechanical, for any purpose, without our prior written permission.
U.S.A.

Worldwide Inquiries: Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective
Phone: +1.650.506.7000 owners.
Fax: +1.650.506.7200
oracle.com 0109