DBAsupport.com Forums - Powered by vBulletin
Page 3 of 3 FirstFirst 123
Results 21 to 26 of 26

Thread: update large table

  1. #21
    Join Date
    Feb 2007
    Posts
    212
    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

  2. #22
    Join Date
    May 2000
    Location
    ATLANTA, GA, USA
    Posts
    3,135

    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.

  3. #23
    Join Date
    Sep 2002
    Location
    England
    Posts
    7,334
    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

  4. #24
    Join Date
    May 2000
    Location
    ATLANTA, GA, USA
    Posts
    3,135
    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.

  5. #25
    Join Date
    Sep 2001
    Location
    Makati, Philippines
    Posts
    857
    Quote Originally Posted by 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
    I can call it a STAGING environment, instead of TEST.
    ---------------

  6. #26
    Join Date
    Feb 2007
    Posts
    212
    thanks everyone

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  


Click Here to Expand Forum to Full Width