Steven,
Shared Dynamic will retry a number of times, depending on the value of
changingretries you have in the dsm.opt file.
You need to find out what is holding the locks on the files.
Lotus Notes Mail consists of lots of databases, particularly onr for each user.
Unless you are using the notes connect agent which can incrementally backup
changed documents within the database, the normal backup client will backup the
whole database even if the only change is one new mail item received/sent.
regards,
John
Steven Chaba <Steven_Chaba AT RGE DOT COM> on 02/12/99 21:48:24
Please respond to "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
cc: (bcc: John Naylor/HAV/SSE)
Subject: Retries, Migrations and Statistics - How Does It Work?
Server: 3.1.1.5 running over AIX 4.2.1
Clients: Various AIX, NT, DB, etc mostly version 3.1.0.x, a handful of v2
Serialization: Almost universally shared dynamic
I'm trying to understand the concept of retries as it applies to use of a disk
storage pool, migrations from that storage pool to a tape pool as well as to the
statistics that are reported in the activity log.
We currently have all nightly backups going to a common disk pool which is ~43
Gb. I did some analysis of last night's run, and it claimed that over 160 Gb of
data was sent to the server, dropped on this disk pool (yes, several migrations
ran during the night, blocking backups for up to 2+ hours), and was eventually
migrated off to tape.
Our top client in terms of data sent weighed in at over 73 Gb of data. The only
problem is, this machine only has about 52 Gb of actual disk space, and that's
only about 80-85% utilized. In reviewing its DSMSCHED.LOG, I see a situation
where after about 1:00 AM virtually every file is retrying at least once, and
most often twice before being sent successfully. This machine is our main Lotus
Notes mail hub, serving around 2200 people. I'm working with our Notes people to
try to find out what is causing all these files to appear to ADSM to be changed
(multiple times?), but in the mean time I'm trying to understand what's
happening to all the extra copies of these files which are sent to the ADSM
server. When a file is marked as changed during a backup sequence, is it kept on
the server along with the ultimate good copy (the last one sent when the file is
no longer flagged as changed, or when the max retries are exceeded), and
migrated to tape along with the final backup copy? If so, how are these managed,
expired, etc?
I would think if a retry is sent and is successful, that retry would be kept but
the file it's replacing would be immediately discarded at the ADSM server, but
the bytes transferred statistics in both my disk-to-tape migrations and the
client session reports sent don't seem to indicate this.
Our ADSM world has grown dramatically over the last year or so. My predecessor
told me (shortly before escaping into blissful retirement) that in the good old
days we had plenty more disk pool than a night's run required. I know disk is
cheap, but this is in SSA drawers (which is a lot less cheap) and the drawers
themselves are almost out of slots, so additional growth there is constrained.
Can anyone enlighten me here? Pretty please?
Thanks in advance.
Steven
Steven J. Chaba, (confused, perplexed, unsettled and inexperienced) ADSM Admin
Rochester Gas & Electric Corporation
<chaba AT rge DOT com>
**********************************************************************
The information in this E-Mail is confidential and may be legally
privileged. It may not represent the views of Scottish and Southern
Energy plc.
It is intended solely for the addressees. Access to this E-Mail by
anyone else is unauthorised. If you are not the intended recipient,
any disclosure, copying, distribution or any action taken or omitted
to be taken in reliance on it, is prohibited and may be unlawful.
Any unauthorised recipient should advise the sender immediately of
the error in transmission.
Scottish Hydro-Electric and Southern Electric are trading names of
Scottish and Southern Energy Group
**********************************************************************
|
