Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Mailing Lists -> Oracle-L -> Re: arclog destination size

Re: arclog destination size

From: karl craven <>
Date: Mon, 31 Jul 2000 16:43:31 -0700 (PDT)
Message-Id: <>

saw your thread re the size of the archive log dir size and had another possible angle for you to look at.

not knowing your architecture or tape archiving method and make a very large generalisation, looking at the amount of data that you are trying to put to tape, 11gb in 4hrs seems fairly slow by modern streaming devices. ie dlt dds3 units etc.

maybe get your sysadmin to look at the method that you are putting the files to tape and see if there could be any possible benefits to changing block size.

as an eg, we were taking approx 13hrs to put 80gb+ to a dlt7000 via the following command

tar cvpf /dev/rst13 -I <file containing list of files>

utilising iostat and playing with the block size that was being used to put the data to tape, we found that

tar cvpbf 80 /dev/rst13 -I <file containing list of files>

was completing in under 4hrs.

what we did was utilise iostat to review the amount of kilobytes read/written etc from the various devices until we found a 'best fit' solution.

another major thing that we found was to ensure that the tape device that your using is using the most uptodate driver to ensure maximum throughput.

also, don't know the size of your archive log files, but within that 4hrs you could also look at setting up background jobs at very low priortiy to compress the archive logs and then only put those that have been compressed to tape.

this again impacts the amount of time that it takes to recover, but its another possible option to ensure that your archive window is not exceeded.

if you would like any help, feel free to ask any q's. the work that we did approx took some 2-3 hrs to evaluate best block size fit but when you look at the reduction from 13 to 4 hrs to complete backups it seemed very worthwhile.

sorry if this is completely off beam,

Received on Mon Jul 31 2000 - 18:43:31 CDT

Original text of this message