Actually this isn't really true, The process address space on any 32-bit operating system (Windows or not) is limited for 4 gigabytes for obvious reasons, and the amount of usable virtual memory depends on the specific platform (for Windows it is 2 gig, on some Unix platforms it is as little as 1 gig).
Since there is a finite amount of addressable virtual memory, a TSM incremental backup is limited in number of files which can be processed. TSM 5.4 is introducing a new variation of incremental backup which utilizes disk caching which should allow backing up file systems of any size at the expense of being somewhat slower and requireing disk space for the cache file. This new backup method should allow the initial backup to complete which is required to enable journal backup. Hope this helps..... Pete Tanenhaus Tivoli Storage Manager Client Development email: [EMAIL PROTECTED] 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 12/12/2006 03:02 PM --------------------------- Please respond to "ADSM: Dist Stor Manager" <ADSM-L@VM.MARIST.EDU> Sent by: "ADSM: Dist Stor Manager" <ADSM-L@VM.MARIST.EDU> To: ADSM-L@VM.MARIST.EDU cc: Subject: Re: JBB Question(s) From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Otto Chvosta >After that dbviewb reports that the journal state is 'not valid'. So we >tried a further inremental backup (scheduled) to get a valid state of >the journal database. >This incremental was stopped with > >ANS1999E Incremental processing of '\\fileserver\q$' stopped. >ANS1030E The operating system refused a TSM request for memory >allocation. > >We tried it again and again ... same result :-((( From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Schaub, Steve >Add this to the dsm.opt file and run the incremental again: >*====================================================================== * > >* Reduce memory usage by processing a directory at a time (slower) * > >*====================================================================== * >memoryefficientbackup yes > >Large windows fileservers with deep directory structures often exhaust >memory trying to traverse the entire filesystem during the initial scan. >This option scans the filesystem in chunks. To add a bit of detail: All modern Windows versions (except possibly Vista) have a hard-set limit of total memory that can be dedicated to a single process thread. (I believe it's 192MB, but don't quote me on that.) It is a hard limit that cannot be gotten around. Steve's workaround is an option. The other option is to use two nodenames for the same machine, with two option files/sets of TSM services/etc. One node backs up half the machine (by using include/exclude lines in the option files), and the other node backs up the other half. The real fix? Use a real server OS. -- Mark Stapleton ([EMAIL PROTECTED]) Senior TSM consultant
