...
The intent of these processes is to establish required database configurations for a new expedition. Only a small portion of this content is needed for any one expedition. Additional scenarios and combinations of data handling are described and consideredconsidered.
SEPARATE INTO 3 DOCUMENTS - detail procedure, checklist, explanatory notes.
Process ----> DO THIS ON
...
THE DEV BOX via a shared account like SHIP\DAQ
- Because it may take a long time and you don't want to tie up your laptop.
- Because your opposite may need to check in on progress if it runs longer than your shift.
...
Log into operating system oracle user first; then conduct database user logins.
- Open a PuTTY SQL Developer session.
- Connect to
oracle@k1.ship.iodp.tamu.edu. - From the prompt k1
$run the commands shown. - Supply the appropriate credentials.
...
|
...
Logging the effort quantifies the experience for future improvements. Please place the log file in an expedition folder under r:\ad\support\###...\box\
- The
box_lims_expedition_delete()step is the longest. Monitoring is required. - If material from another expedition was analyzed on this expedition, it may be necessary to delete that content too, e.g.
call box_lims_expedition_delete('344(312)');
- VARIANCE: If you need to keep some data from the previous expedition for the next expedition, skip this step. 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.
- 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.
- VARIANCE: If multiple expeditions need to be cleaned, repeat the command for each expedition.
- 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.
- 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.
Statistics
REMOVE THESE.
- 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.
- 385 & 378T: 07:24:06.09 for 385 and 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
...
- DESCINFO2. Records configuration of parameters, templates, value lists, and users for the descriptive information eco-system.
- LIMS. The sample catalog and repository of experimental results against those samples. Includes a catalog of files (ASMAN) associated with those samples.
- OPS. Repository of drilling operations information. Bathymetry and navigation content was removed from here as of Subic Bay Tie-up 353P Oct 23, 2014. The content is time and activity based, not sample based. Other workflows manage the bulk of this data outside Oracle. What is recorded here is a small subset of the total operational content we keep.
- TRANSFER. Contains the scripts and tables for data transfer and cleanup processes you will be running.
- GEODCAT, GEODP###
Cleaning Process Architecture
...