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.
|
