Another thing that you should do is go into tsmjbbd.ini and set NotifyBufferSize to be a fairly large number. The default is 0x00100000, or 1MB. That probably is not going to be large enough for your server.
David McClelland <[EMAIL PROTECTED]> wrote: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 [EMAIL PROTECTED] Reuters Messaging [EMAIL PROTECTED] --------------------------------------------------------------- - 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. Joe Howell Shelter Insurance Companies Columbia, MO --------------------------------- Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software
