[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference rocks::dec_edi

Title:DEC/EDI
Notice:DEC/EDI V2.1 - see note 2002
Moderator:METSYS::BABER
Created:Wed Jun 06 1990
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:3150
Total number of notes:13466

3036.0. "Secondary archive is very slow" by UTRTSC::SMEETS (Workgroup support) Mon Mar 03 1997 15:22

Hi,

Customer running DEC/EDI VAX/VMS V6.2 with Oracle RDB V6.1-ECO4 on a VAX 7830
with 512 MB memory and 8 Gb raid disk.

The Audit database is sized for 50,000 documents and the Archived database is
sized for 100,000 documents. there are 400 store directories

Secondary archive with default options (so to back up everything !) takes 1�
hours to backup up 6000 documents and 500 Transmission files. So to back up the
daily load of 40,000 document would take some 6 hours or even more.

Is there a way to increase the backup speed. ?

As secondary archiving is just used to empty the Archive database and the store
directories I thought of a dirty workaround.

i.e. use SQL to delete the records from the Archive database (delete from 
TLF_TABLE where credate_q <= 'date time'; the same also applies to the other 
tables THF_TABLE, CHF_TABLE and CLF_TABLE).

and also delete everything from the store directories (delete/before=date time)

Are there other options ?

Martin
T.RTitleUserPersonal
Name		DateLines
3036.1I/Os, always I/OsFXSTC::M_BEACHMike, USCSCTue Mar 04 1997 20:0032
.0> As secondary archiving is just used to empty the Archive database and the 
.0> store directories I thought of a dirty workaround.
.0> i.e. use SQL to delete the records from the Archive database (delete from 
.0> TLF_TABLE where credate_q <= 'date time'; the same also applies to the 
.0> other tables THF_TABLE, CHF_TABLE and CLF_TABLE).
.0> and also delete everything from the store directories 
.0> (delete/before=date time)

Experience has shown that this method, as described, will inevitably cause
problems, e.g., orphan files, too may files deleted, orphan history records, 
too many history rcds deleted.  A modified version of this method, 
selecting tlf/clf by date/time, but deleteing tlf/thf/clf/chf/store_files by 
selected ids, does work much faster, and has less "weird failures/recoveries" 
known to secondary archive processes.

.0> Is there a way to increase the backup speed. ?

- Insure queue lengths, for physical and logical disk devices, do not 
exceed 0.5 (there are many, many methods for achieving this).

- Insure there is always >25% free bytes in each storage area, for both
audit and archive databases (due to poor design and index placement).

- No edi version listed, however if <v2.0, optimized arch_data .dat's thru
optimized fdls help tremendously.

- INTERCHANGE ARCHIVE user's UAF account with large biolm, diolm, wsextent 
(not exceeding sysgen's wsmax), helps.

I can talk tuning/timing-n-sizing all day, but it's always a config-by-config
decision. 
...Mike
3036.2It's V2.1CUTRTSC::SMEETSWorkgroup supportWed Mar 05 1997 07:5321
Hello Mike,

thanks for your answer. 

It's V2.1C of DEC/EDI. 

Imagine that the system is tuned as stated by you, how long would it take to
archive 40,000 documents using INTER ARCHIVE ? 

.1> Experience has shown that this method, as described, will inevitably cause
.1> problems, e.g., orphan files, too may files deleted, orphan history records, 
.1> too many history rcds deleted.  A modified version of this method, 
.1> selecting tlf/clf by date/time, but deleteing tlf/thf/clf/chf/store_files by 
.1> selected ids, does work much faster, and has less "weird failures/recoveries" 
.1> known to secondary archive processes.

Do you have any examples ?

Thanks,

Martin