I am in need of some help in determining why my backups are taking 10 hours.
I have our back up scheduled to start at 8 pm. I also have background
processing starting at about 12:05. Since we run 24/7 I really have a tough
time scheduling maintenance and they get nasty with me if it interrupts
production. (They dont understand how completely ruined things will be if I
DONT get a backup done!)

Our database is about 3 GB. I can fiddle around with the start time for the
backup, but the goodnite processing needs to start at midnight.

Any ideas on what I can do to figure out where the bottleneck is?

Thanks for any help!

-RaeG

It would help if you included your OS & Pick-type platform & release.

The best way to speed up the file-save is to save to compressed
pseudo-floppy instead of to tape. Afterwards, you can tar the disk
file(s) to tape for off-site storage, if necessary.

Another option for off-site storage is a removable disk drive. At less
than $1 per GB of disk, a couple of large (S)ATA disks, mounted in
hot-swap drive carriers and a single hot-swap drive bay is way less
expensive and a lot faster than a DAT or other tape device. Plus you
have room for more than 1 day's backup data.

Your file-save may be hanging on group-lock(s). Depending on your
production environment and comfort level you may want to consider
issuing a clear-locks command before the save starts.

On D3 there is a blkio command. Setting it to 64 (the max) speeds up
the save process on my systems by about 15% or so.

Then there is the old standby: files with lots of overflow, or large
pointer-items. Make sure your files are sized correctly; periodic
restores will also speed things up considerably (how long since your
last restore?).

I'm sure you'll get many other suggestions as well; good luck.

--
Scott Ballinger
Pareto Corporation
Edmonds WA USA
425-670-0831



RaeG wrote:

Let us know what hardware platform you're using and if it's an internal or
external tape drive. How many things are on the SCSI chain and what other
processes could be running to cause conflicts? Is this a problem you just
started having? What was the save time before you noticed the problem? What
processes have you (or the real culprit) implemented around the time the
problem started occurring?

If you have any large, undersized files, you could run into performance
problems which draw out the duration of your backups.

With a DDS-4 tape drive and 12GB - 13GB data, a save could be completed
within a few hours.

Good luck!

Albert

"RaeG" <rgommel (AT) accupac (DOT) com> wrote

We need to know the O/S and Platform you are running.

I have sites running Pentium IV 2000MHz machines, with 512MB of RAM
and a DDS4 4mm DAT Drive. The machine is all SCSI connections.

I have one site that has 1.5GB of DATA and it takes less than 15 mins
to FILE-SAVE. 10 Hours on your siter sound like you are running an AP
platform!!!

John

Scott -

Thanks for the reply... I think the restore is my issue. It's been since
labour day. And since we moved to a 24/7 shop they wont close down to give
me enough time to do the backup and restore. Thanksgiving I certianly dont
want to come in and run a backup then do the restore and hope it finishes by
friday morning. (not to mention who the ^*%^&$ wants to work on
Thanksgiving???)

Is there some way I can do a file resize as part of my over night processes
that wont interfere with the whole system. Like just resize a few files? I
did move some processes from every night to weekend nights....and that has
helped some.

Thanks!
-Rae


"Scott Ballinger" <scott (AT) pareto (DOT) net> wrote

Originally posted by Raeg



If you have the LIST-FILE-STATS verb, use it to develop your own list
and sort the files BY-DSND BYTES, to see which are the space hogs. Then
you might want to consider moving some of the data in those files to
"HISTORY" files, or deleting it entirely if your users don't require it.



You can also use those lists to manually resize specific files. After
your filesave has completed and you verified it, create a TEMP file of
the appropriate size.

1. Copy all the data of the file that needs resizing to the TEMP file
with the "delete" from original file option

"COPY filename * (ID".

2. Delete the data portion of the file to be resized.

"DELETE-FILE DATA filename".

3. Then recreate the data portion of the file to be the correct size

"CREATE-FILE DATA filename mod,sep"

4. Then copy the data in your TEMP file back to the resized file.



You can write a program to do this for you, but be EXTREMELY careful!!!
(I would recommend doing it in a "TEST" account first to be sure it
works the way you expect).


--
Posted via http://dbforums.com

Most platforms allow resizing individual files in real-time. On D3 the
command is 'resize filename newmodulo'. If you can identify the most
egregious under-sized offenders, this may help. However, a periodic
restore is more than just an opportunity for resizing files. The
restore process lays down all your data in contiguous blocks (the pick
equivalent of defrag); files that are undersized and pointer-items
will get all their linked overflow frames stored together, usually
appended to the end of the main filespace. I have one system (D3 7.3
Linux) with about 12GB of data where the save (to disk) takes about an
hour right after a restore. A month or two later, the save takes about
3 hours. So periodic restores really will speed up your system.

Scott Ballinger
Pareto Corporation
Edmonds WA USA
425-670-0831


"RaeG" <rgommel (AT) accupac (DOT) com> wrote

So... by doing a RESIZE I'm not really helping the situation? I'm just
making it manageable? It will just allocate more space, not gather all
together? Bummer. So complete restore is my only option to do this PICK
version of defrag?

Our data is only 3G so it isn't massive (D3 7.0 on AIX UNIX on IBM E30) and
the machine is newer and faster than our old system. But the IS manager is
leaving and just got promoted up to DBA...for all of our systems. Massive
learning curve.

Are there any sites that you recommend for good info?

-Rae


"Scott Ballinger" <scott (AT) pareto (DOT) net> wrote