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: 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
12/12/2006 03:02 PM ---------------------------
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: JBB Question(s)


From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] 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:ADSM-L AT VM.MARIST DOT EDU] 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 (mark.s AT evolvingsol DOT com)
Senior TSM consultant