Browse Prior Art Database

Migrating Siebel Database Using a Delta Approach

IP.com Disclosure Number: IPCOM000051264D
Original Publication Date: 2005-Feb-10
Included in the Prior Art Database: 2005-Feb-10
Document File: 3 page(s) / 72K

Publishing Venue

IBM

Abstract

Reducing the downtime for an Application by Migrating database using a delta Approach.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 56% of the total text.

Page 1 of 3

Migrating Siebel Database Using a Delta Approach

Disclosed is a method of migrating from one version of an application to another (v7.0.x to v7.5.x) with the least amount of downtime by providing a way to migrate only the data that has been changed (delta data) from one version to another. The ability to migrate delta data enables the source system to remain available to users during the time consuming initial migration.

Assumptions:
a) facilities to stage migrated database, while users actively continue to work on the primary database, exist
b) a downtime of 1-2 hours is available on the primary server during the first weekend

This process will migrate the database over 2 weekends.

Definitions:

Machine a = Source database server
Machine b = Target database server
Machine c = Failover database Server

Process Flowchart/Diagram (with sample days and times):

The following outlines how the conversion is conducted.

A) First weekend - begin initial (bulk) migration and staging of processes to capture deltas over the next week.

1

[This page contains 1 picture or other non-text object]

Page 2 of 3

(1) A backup of the database was taken from Machine a to Machine b.

- an on-line backup was used from the previous day and logs applied all the way up to start of the maintenance window (2) 2 columns (one 1 character each) were added to every table to track the insert and update flags.

(3) 1 delete table was generated for each table to be tracked.

(4) DB2 triggers were created on each table to be tracked . The triggers set the update/insert flags 'on' for all updated/inserted rows. For deletes, the trigger placed a row in the delete table with the time and row_id of the deleted row. (5) Increase the current prefix/next prefix in table s_ssa_id by 1.

(6) The database on Machine b is then migrated to your deployment version of DB2 and Siebel using the standard migration process as defined in the Siebel bookshelf**.

     - depending on version you are migrating from/to and the size of your database, you may want to drop base indexes in tables or add statements to add indexes during Upgrep in different phases.

(7) When the migration is complete, conduct your normal system health check and maintenance activities. We executed reorgs and runstats on all primary Siebel tables as part of this post migration processing and conducted extensive testing/...