Friends, before anything, thank you all for so many ideas... Let´s go :

mike, yes, it will be partitioned. In truth, the table have 5 columns, and the PK is made by all the 5 columns, so I´m thinking about make it an IOT - and no, none of the PK columns will be a sequence, I have a date, 2 varchars, 2 number, all of them user-data, no artificial values here. Of the 5 columns, the first one (the date/time of processing) is more significative (and the volume what I will process each day is roughly the same), so this column can be a good partition key.
I´m considering make it a range partitioned IOT by this first column - of course, IOT means some degrading in insert (due to the fact that I will be inserting into an index, a complex structure), BUT I will save a whole lot of space(see, dozens of millions, with IOT I will have only the index extents, while for a heap table + PK Index I will use a lot of space for table blocks, and another lot for index blocks.

Jeff, I will test triggers, but besides it requires more work, I have some doubts about the performance of triggers in this kind of volumes of data.


Dave : yes, the exceptions clause when enabling PK is a close possibility, but I never used it . My fear is : see, today I have (say) 20 millions of rows, validate. Tomorrow I disable PK, load , say, 15 millions of rows more , when I re-enable the PK the database will re-check/read the old 20 millions PLUS the new 15 millions ?
And about option c) , really I´m correct about merge not being capable of producing a list of exceptions in another table or file ?

regards,

Chiappa