SCD2 mapping following the "scdwhitepaper", but my sequences are skipping

Question

All,
I have created a mapping that follows the guidelines set in Oracle's "scdwhitepaper"
http://www.oracle.com/technology/sample_code/products/warehouse/files/SCDWhitePaper.zip
I have got the mapping to work but I am experiencing a problem where my Surrogate IDs, which are populated by a Sequence, are skipping. I would like the IDs to be sequential like 1,2,3,4,5 etc. But instead I get 1,2,3,4,8,12,etc.
I look at the generated code and here is the relevant part:
WHEN NOT MATCHED THEN
INSERT
("DIM_PROD_TEST"."TGT_OWB_SURROGATE_ID",
"DIM_PROD_TEST"."TGT_OWB_BUSINESS_ID",
"DIM_PROD_TEST"."TGT_PRODUCT_CODE",
"DIM_PROD_TEST"."TGT_PRODUCT_TYPE",
"DIM_PROD_TEST"."TGT_EFFECTIVE_DATE",
"DIM_PROD_TEST"."TGT_EXPIRATION_DATE")
VALUES
("DIM_PROD_TEST_SEQ".NEXTVAL,
"MERGE_SUBQUERY"."EXP_PRODUCT_ID",
"MERGE_SUBQUERY"."EXP_PRODUCT_CODE",
"MERGE_SUBQUERY"."EXP_PRODUCT_TYPE",
"MERGE_SUBQUERY"."EXP_EFFECTIVE_DATE",
"MERGE_SUBQUERY"."EXP_EXPIRATION_DATE")
I suspect Sequences are being generated for all records in the "open set" (inserts and updates of live records), even though I only need Sequences for records which are truly new/inserts.
Anyway ... has anyone experienced this behavior or know how to troubleshoot / fix?
Thanks!
Sammi

Answer 1

Yes, this is because of where the sequence is generated. No, there is no real fix. Well, unless you want to break up the mapping into two completely separate where you first identify all of the inserts and do them, then do all the updates as a totally separate path (or do it in the other order). Of course, then you are trading off efficiency for your sequence. Also, you will have to manage correlated commits or have some other strategy for how you deal with one of the two discrete operations failing.
Or, I suppose you could simply not load the surrogate key in the mapping but do it in a row-level insert trigger. That will definitely impact performance too!
Oracle has never intended sequences to be used to create a dense key. The simple nature of OLTP systems, for example, assumes that sometimes data will be deleted thus putting holes in a sequence even if you had managed to load it perfectly.
Frankly, you should take a hard look at why you think you need a perfect, gap-free surrogate key. In my experience, attempting such a thing is far more trouble than it ever would be worth as ensuring order implies that you are attaching some meaning to the surrogate key, and by definition they are supposed to be meaningless.
Mike