RE: data migration

Praful,

This is a bit of a shot from the hip, but..... the gap shouldn't make much of a difference in the end.

I'd be more concerned about allocating space for all your stuff initially, not just the first 10%. The gaps should be handled seamlessly by indexes (the way a b*tree works...) and anything that seems to act much differently you can always do select activation of histograms to account for data skew if you come to think that's a problem. (You *are* in cost-mode, yes?)

Of course, there's always the "design" solution. Put another field in there that tells the app whether it's "phase I" or "phase II" data. Then you could overlap primary keys, which from your description i gather are sequence-based. (But i think that's weird and sloppy somehow, and I wouldn't do it.)

hth,

• Ross

|| -----Original Message-----
|| From: Praful Thakkar [mailto:thakkar_praful_at_yahoo.com]
|| Sent: Thursday, May 17, 2001 5:46 PM
|| To: Multiple recipients of list ORACLE-L
|| Subject: data migration
||
||
|| Hi,
||
|| We are planning to do two-phase data migration - split by data.
|| In first phase, about 10% of the data will be moved as is -
|| without changing the primary keys (generated from sequences).
|| Once we start using the database with phase 1 data, sequences
|| will generate new primary keys and add to this data - which
|| could be same as primary key for the remaining data, which is
|| not yet migrated. In phase 2, to avoid unique constraint
|| problems, we'll add 1,000,000 to primary keys before we migrate
|| remaining data. This will lead to imbalance of primary keys.
|| After complete migration, we'll have about 10% of the keys with
|| low values and remaining with very high values. What is the
|| impact of this huge gap in primary keys? How will be the
|| performance affected? Is there a way in which we can avoid this
|| huge gap in primary keys (We do not have an option of going for
|| single migration. Business needs force us to test the
|| application with partial data. ) One option I thought of is to
|| use high value keys in first migration itself - but when
|| sequences reach these high values, we'll have same problems of
|| unique constraint being violated.
||
|| Thanks.
||
|| - Praful
||
||
|| __________________________________________________
|| Do You Yahoo!?
|| Yahoo! Auctions - buy the things you want at great prices
|| http://auctions.yahoo.com/
|| --
|| Please see the official ORACLE-L FAQ: http://www.orafaq.com
|| --
|| Author: Praful Thakkar
|| INET: thakkar_praful_at_yahoo.com
||
|| Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
|| San Diego, California -- Public Internet access /
|| Mailing Lists
|| --------------------------------------------------------------------
|| To REMOVE yourself from this mailing list, send an E-Mail message
|| to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
|| the message BODY, include a line containing: UNSUB ORACLE-L
|| (or the name of mailing list you want to be removed from). You may
|| also send the HELP command for other information (like subscribing).
||

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Mohan, Ross
  INET: MohanR_at_STARS-SMI.com

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).