Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

sql>
spool box_processing-349.log
 
set timing on
set serveroutput on
 
call cleanout_new_tables(); -- (1)
call asman_catalog_delete('EXP346'); -- (2) Last expedition
call lime_audit_delete(###);    -- (4)
call lims_expedition_delete('346');  -- (3) Last expedition
call lims_cleanup();
call lims_defrag(); -- (5)
spool off
exit

NOTE - participants_remove.sql found in SVN under - C:\develop\wapps\Tools\DbScript\https://build.ship.iodp.tamu.edu/svn/wapps/Tools/DbScript/participants needs to be run to remove all the old JRS_ scientist user id's.  Need to be run under a DBA Privileged account in SQL Developer.  The process will remove user ID's and will also remove dependent user configuration from the X_AUTH_ACCOUNT table as well.

...

  1. VARIANCE: If you need to keep some data from the previous expedition for the next expedition, skip this step. Then Even if you forget, you can still copy what you need from TRANSFER.NEW_tables without having to resort to the data pump import tool.
  2. VARIANCE: If you need to keep some data from the previous expedition for reference on the next expedition, then custom SQL is required to preserve what you need. And you must communicate with the MCS to ensure what you need is preserved on the ASMAN file system--their routine is to expunge the previous expedition.
  3. VARIANCE: If multiple expeditions need to be cleaned, repeat the command for each expedition.
  4. You must look up and specify ###. The script as written deletes all audit keys <= ### from x_lime_audit_main. The deletion cascades to linked audit detail.
  5. Defragmentation of the space used by SAMPLE, TEST, RESULT is recommended, but not required if you are pressed for time. "Coalescing" of the RESULT table alone typically takes 9 hours in the shipboard environment. Doing so on a warehouse does take days with spinning disk.

...

  • BOX lims_expedition_delete() for
    • 362: 4 hr 49 min 50 sec. One archive log stuck excursion. Fixed by the backup window we happened to overlap.
    • 367: 2 hrs 22 min. No archive log stuck excursion.
    • 372: 5 hr 30 min. No archive log stuck excursion.
    • 374: about 10 minutes, as 372 was light. No issues.
    • 382: 6 HOURS.  Only issue was Dev laptop rebooted from and Update but process was on Build Box so no problems.  
    • 385 & 378T: 07:24:06.09 for 285 385 and only  only a couple of minutes for 378T
  • BOX lims_cleanup() for
    • 372: 15 sec
    • 374: < 1 sec
    • 382: 17 seconds.
    • 385 & 378T: 24 seconds
  • BOX lims_defrag() for:
    • 362: 9 hrs 32 min. Two archive log stuck excursions. Even with archive log allocation bumped to 1T on the second time.
    • 372: ???
    • 374: about 36 minutes.
    • 382: 4:31:59.73 total run time.  Longer than normal.
    • 375 & 378T: 05:18:51.12

...