update large table

[jennifer2007]

yeah....precisely dear

Its just an ETL table and I can afford to redo it in case of error
coz i got a backup copy.
I am converting a Foxpro database to Oracle. Its a Loans Payment table.
I got 180million plus Loans Payment foxpro table,
the tables reside on different branches(decentralized),
and its branches have different structure of that table ( what a
delimma) because each branch has its own programmer,
with different style to maintain the apps.
I have to merged it in the central office.
I built a common structure table that fits for all the branches.
Then I extract using HS connectivity.
I start cleaning it up ...updates...updates...updates...
yeah the parallel mention by tamil may help.
I also partitioned it with the loan_date per year.

One of my delimma is there are lots of erroneous loan_date. So
I cannot load it into the partitioned table now. But the management
tell me that all the records must be accounted for ...that all of it must
be inquired (seen in a inquiry form) even if errorneous as it is.
How can I merged this erroneous date rows to the main partitioned table?

I am loading the erroneous loan_date rows to another table then make
a VIEW to join the two. Is this the right way hunnies?


Thanks

[tamilselvan]

In 10g there is one underscore parameter, _disable_logging whose default value is FALSE, that enables logging the transaction details in the redo.

It is not advisable to change the value in any environment.

In your test environment, you can set it to TRUE, and run the load process. See that helps.

As I said, do not change the parameter in production database.

[davey23uk]

if not to do it in a production database, then why should you ever so it in a TEST database, you know the place where you test what goes into production. Thats just crap advice

[tamilselvan]

Jennifer2007,

I think you are building the database for the first time and the big update is going to be one time job. And you wanted to update the table in a shorter time.

1 Take DB backup.
2 Change the underscore parameter, _disable_logging to TRUE.
3 Drop indexes on the table and Update the table using parallel options.
4 Verify the updated columns in the tables.
5 Shutdown the DB and change the parameter, _disable_logging to FALSE.
6 Startup the DB. Verify integrity of the DB (all the tables and indexes).
7 Take a backup now.

In case some thing goes wrong during the update, restore the backup copy taken in step-1.

[reydp]

if not to do it in a production database, then why should you ever so it in a TEST database, you know the place where you test what goes into production. Thats just crap advice

I can call it a STAGING environment, instead of TEST.

[jennifer2007]

thanks everyone