I was using the 5.2.? Client......
---------------------------------------
Bruce Kamp
Midrange Systems Analyst II
Memorial Healthcare System
E-mail: bkamp AT mhs DOT net
Phone: (954) 987-2020 x4597
Fax: (954) 985-1404
---------------------------------------
-----Original Message-----
From: Pete Tanenhaus [mailto:tanenhau AT US.IBM DOT COM]
Sent: Wednesday, September 24, 2003 9:24 AM
To: ADSM-L AT VM.MARIST DOT EDU
Importance: Low
>>> I went through this not to long ago. My server is not quit as big
>>> as
yours
>>> about 1.7 million files. My problem was that I was using
>>> resourceutilization=3. When I dropped it to 2 the backups started
working
>>> again.
Currently multiple journal based backup sessions aren't supported, so a
client session which attempts to contact the journal service while another
jbb session is in progress will timeout.
APAR IC36261 has been opened against this problem and will be addressed in a
future release.
I circumvention to this problem was included in client version 5.16.2.
The following is problem/circumvention description in the 5.16.2 readme
file:
----------------------------------------------------------------------------
---------------------
Problem Description:
An attempt to contact Journal Service by a client backup times out because
another client JBB session is being processed by the journal service.
This may be due to multiple backup client processes (cmd line client, GUI,
Web Client, Scheduler client) running concurrently.
It may also be due to multiple client backup session threads being started
via the client ResourceUtilization option.
Currently the journal service is only capable of accepting one client
connection at a time.
If another client attempts to connect to the journal service while a Journal
Based Backup is in progress, the backup client will wait up to 50 seconds
for the connection to be established (that is, for the current Jbb session
to complete).
If the connection can't be obtained in 50 seconds the client times out.
Development is aware of this limitation and is working on implementing
multi-session Journal Based Backup in a future release.
This release does provide a circumvention to this problem to allow a client
to wait for a specified or indefinite amount of time for Journal Service
connection to be established (see problem circumvention section).
Problem Symptoms:
Journal Based Backup fails, backup reverts to normal incremental backup.
The following message is written to the client errorlog:
NpOpen: Named pipe error connecting to server WaitOnPipe failed.
NpOpen: call failed with return code:121 pipe name \\.\pipe\jnl
Problem Circumvention:
The new timeout default is 120 seconds.
The problem won't occur if Journal Based Backup's don't overlap, and if the
ResourceUtilization option is set to 1.
A testflag has been implemented to allow the backup client to wait a
specified or indefinite amount of time for a connection with the journal
service.
This has the effect of queuing pending Journal Based Backups.
Note that if an indefinite amount of time is specified (i.e wait forever)
that there is no feedback to the user (other than a message being written to
the client errorlog) that the client is waiting for the connection.
Syntax of testflag (as specified in dsm.opt):
Test JNLOUTBNPTIMEOUT:nnn
where nnn is the timeout value in seconds.
If the timeout value is 0 (Test JNLOUTBNPTIMEOUT:0) the client will wait
indefinitely for a connection with the journal service.
----------------------------------------------------------------------------
--
Pete Tanenhaus
Tivoli Storage Solutions Software Development
email: tanenhau AT us.ibm DOT com
tieline: 320.8778, external: 607.754.4213
"Those who refuse to challenge authority are condemned to conform to it"
---------------------- Forwarded by Pete Tanenhaus/San Jose/IBM on
09/24/2003 09:17 AM --------------------------- Please respond to "ADSM:
Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
cc:
Subject: Re: TSM Journalling Engine - experiences and
MEMORYEFFICENTBACKUP needed?
I went through this not to long ago. My server is not quit as big as yours
about 1.7 million files. My problem was that I was using
resourceutilization=3. When I dropped it to 2 the backups started working
again.
---------------------------------------
Bruce Kamp
Midrange Systems Analyst II
Memorial Healthcare System
E-mail: bkamp AT mhs DOT net
Phone: (954) 987-2020 x4597
Fax: (954) 985-1404
---------------------------------------
-----Original Message-----
From: David McClelland [mailto:David.McClelland AT REUTERS DOT COM]
Sent: Wednesday, September 24, 2003 7:00 AM
To: ADSM-L AT VM.MARIST DOT EDU
Hi Guys,
I've been tinkering with the TSM Journaling engine for a few weeks now, and
wonder if anyone has come across this before:
TSM Server - Win2K Advanced Server SP3 - 2xPIII 1GB RAM - TSM Server
5.1.6.2
TSM Client - Win 2K Advanced Server SP3 - 4xPIV 4GB RAM - TSM Client 5.1.5.0
My TSM client is a file server, on its first full incremental backup (with
journaling turned on) stowed away nearly 9 million files on the TSM server
-
a perfect candidate for the TSM journaling engine I thought. However, the
tsmjbbd.exe process bombed just before the end with a 'DB Access Critical
Thread Return code 215' type error, although the backup continued.
Anyway, I net started the `TSM Journal Service` (I have preserveDB on exit
switched on and observed by journal files to be around 1.5GB) and kicked off
another incremental backup. The TSM server now begins sending its inventory
for this node to the TSM client dsmc.exe process. I started watching it grow
in Task Manager on the client in line with how much data was being sent from
the server.
Now, 9 million files, at an average of maybe 500K per TSM database entry
equals roughly 4.5GB. Was TSM trying to send the *whole* 4.5GB inventory for
this node to the dsmc.exe process on the client? Needless to say, at 2GB (I
believe the limit that Win2K places on a single process) the TSM client had
had enough and ended with an 'ANS1030E System ran out of memory. Process
ended'.
So, what shall I do - is MEMORYEFFICIENTBACKUP YES my only get out of jail
card here, and exactly what does this do differently? Is my understanding
above what is actually happening?
I'd be most grateful to hear of anyone else's positive or negative
experiences of using the Journaling Engine, as it seems just so *ideal* for
some of our file servers, yet my experiences so far suggest it might not be
as easy and robust as I would ideally like it to be (i.e.
cancelled backups forcing restart of journal, process bombing out midway
through backup etc.), especially as a full or normal incremental backup can
run into days to complete...
Many thanks,
David McClelland
Management Systems Integrator
Global Management Systems
Reuters
85 Fleet Street
London EC4P 4AJ
E-mail david.mcclelland AT reuters DOT com
Reuters Messaging david.mcclelland.reuters.com AT reuters DOT net
--------------------------------------------------------------- - Visit our
Internet site at http://www.reuters.com
Get closer to the financial markets with Reuters Messaging - for more
information and to register, visit http://www.reuters.com/messaging
Any views expressed in this message are those of the individual sender,
except where the sender specifically states them to be the views of
Reuters Ltd.
|
