logical log size
A DBA with 30 x 32MB logical logs filling 2-3 logs every 5 minutes asked whether to double the number of logs (60 x 32MB) or double their size (30 x 64MB), since his slow-to-spin-up tape library struggled to keep up. Replies noted the real trade-off is how much transaction data is at risk between backups (larger logs = more exposure); one poster said larger logs solved a similar backup-throughput problem, others suggested a faster drive or backing up logs to disk (LTAPEDEV/ISM) and copying to tape later. The poster concluded he'd keep 32MB logs but increase the count to 60, and also test a disk-to-disk-to-tape setup.
Auto-generated by DrWatson from the posts below — may be imperfect; read the full thread.
Hello, The logical logs on my system are configured as 30 32MB logs. The system has been growing rapidly and currently cuts 2-3 logs every 5 minutes. Backup is to a spectralogic tape unit, which is fairly slow to spin up. In order to not run out of logs due to backup issues, I was going to either double my logs to 60 32MB logs or double the log size making them 30 64MB logs. The latter would help aleviate spinup time since twice as much log is be written per backup. I would appreciate your opinion! Thanks Mike
The real decision is whether you want 5 minutes worth of transactions at risk or 10 minutes worth in case of catastrophic failure. Art ----- Original Message ----- From: Michael Favole <ids@iiug.org> At: 3/14 11:38 Hello, The logical logs on my system are configured as 30 32MB logs. The system has been growing rapidly and currently cuts 2-3 logs every 5 minutes. Backup is to a spectralogic tape unit, which is fairly slow to spin up. In order to not run out of logs due to backup issues, I was going to either double my logs to 60 32MB logs or double the log size making them 30 64MB logs. The latter would help aleviate spinup time since twice as much log is be written per backup. I would appreciate your opinion! Thanks Mike ******************************************************************************* Forum Note: Use "Reply" to post a response in the discussion forum.
Michael, At my old Informix shop, we had 800 10Mb logs that would fill about once per minute during peak periods. The tape device unit (I forget the manufacturer) also had a long spin up time. Slow enough, that during some very heavy peak activity periods, it couldn't keep up. Eventually, it would catch up when the activity would go down in the evening. The only way around this was to make the individual logs larger. We went to 50 Mb logs, and the problem was alleviated while still getting fairly fine granularity (time-wise) in logical log backups. --John Bejarano. --- MICHAEL FAVOLE <mike.favole@ngc.com> wrote: > > Hello, > > The logical logs on my system are configured as 30 > 32MB logs. The system has > been growing rapidly and currently cuts 2-3 logs > every 5 minutes. Backup is to > a spectralogic tape unit, which is fairly slow to > spin up. In order to not run > out of logs due to backup issues, I was going to > either double my logs to 60 > 32MB logs or double the log size making them 30 64MB > logs. The latter would > help aleviate spinup time since twice as much log is > be written per backup. I > would appreciate your opinion! Thanks > > Mike > > > ******************************************************************************* > > Forum Note: Use "Reply" to post a response in the > discussion forum. > >
> MICHAEL FAVOLE wrote ... > The logical logs on my system are configured as 30 32MB logs. > The system has > been growing rapidly and currently cuts 2-3 logs every 5 > minutes. Backup is to > a spectralogic tape unit, which is fairly slow to spin up. In > order to not run > out of logs due to backup issues, I was going to either > double my logs to 60 > 32MB logs or double the log size making them 30 64MB logs. > The latter would > help aleviate spinup time since twice as much log is be > written per backup. I > would appreciate your opinion! Thanks > > Mike - Maybe a faster tape device - or create a file on disk, use it as LTAPEDEV and save the logical log files (numbered) to tape or somewhere else. I have not used any of them, but to my knowledge there are some pretty sophisticated scripts out there which do this automated.
We are in a test stage, making onbar backups on disk then to tape.
Database is on external Fiber channel boxes and bacup directories are=
on
internal disks, so backups go to disk then, after some days making
incremental and logical logs backups, all of the backup files go to t=
ape
together with important administrative files like oncfg* ism/ etc.
Backup jobs are quite fast and no time consuming.=20
At least this is the aproach but we are stil trying to find odds and
posible problems.
--Nestor
El mi=C3=A9, 15-03-2006 a las 09:04 -0500, Model-Bosch.... escribi=
=C3=B3:
> > MICHAEL FAVOLE wrote=20
> ....=20
> > The logical logs on my system are configured as 30 32MB logs.=
=20
> > The system has=20
> > been growing rapidly and currently cuts 2-3 logs every 5=20
> > minutes. Backup is to=20
> > a spectralogic tape unit, which is fairly slow to spin up. In=
=20
> > order to not run=20
> > out of logs due to backup issues, I was going to either=20
> > double my logs to 60=20
> > 32MB logs or double the log size making them 30 64MB logs.=20
> > The latter would=20
> > help aleviate spinup time since twice as much log is be=20
> > written per backup. I=20
> > would appreciate your opinion! Thanks=20
> >=20
> > Mike=20
>=20
> - Maybe a faster tape device=20
> - or create a file on disk, use it as LTAPEDEV and save the logical=
log=20
> files (numbered) to tape or somewhere else.=20
> I have not used any of them, but to my knowledge there are some pre=
tty=20
> sophisticated=20
> scripts out there which do this automated.=20
>=20
>=20
> *******************************************************************=
************=20
> Forum Note: Use "Reply" to post a response in the discussion foru=
m.=20
>=20
That was my feeling also, so I guess the best choice for us would be to increase the number of logs but leave the size as is. That would mean that we would have 60 32MB logical logs. Thanks .... Mike
We are testing a similar disk to disk to tape architecture. We are going to use ISM to take backups to disk, then use CA's Brightstor to copy the disk backup files to tape (spectralogics library). We are incrementally backing up our log directioty to tape, so each time a log completes writing to disk, it will then be backed up to tape. This seems to offer the best protectiopn in a disaster situation. We are working on a government contract and are stuck with the same older tape and network, so we have to make the best with what we have. Thank s.... Mike