Otto Chvosta a écrit :

Hi again,

First, thanks for all of your advices in this case.

In my department the prefered server operating system is AIX but
unfortunately I've no influence on the choice of OS at our client servers
:-(

I also heard about the new disk chaching mechnism announced for TSM 5.4 and
hope that is a possible solution for this problem ...

But first I'd to find a solution in 5.3 ...

We did a successful incremental with 'MEMORYEFFICIENTBACKUP YES' last night
(processingtime ~ 18 hours) . MemEFF seems to be the right way against
ANS1030E, but dbviewb still reports an invalid journal state. So my primary
problem is to get the journal state valid.

Journal Database Information:

     Database File           q:\tsm_journal_db\tsmQ__.jdb.jbbdb
     Database File Disk Size 674 Bytes
     Journal  File System    Q:
     Journal Activation Date Tue Dec 12 16:45:39 2006
     Journal Validation Date (not set)
     Maximum Journal Size    8191 PB (9223372036854775807 Bytes)
     Journal Type            Change Journal
     Journal State           Not Valid
     Valid for Server        (not set)
     Valid for Node          (not set)
     Number of DB Entries    0

Filespace:
                  Filespace Name: \\fileserver\q$
      Hexadecimal Filespace Name: 5c5c6673316c756265635c7124
                            FSID: 8
                        Platform: WinNT
                  Filespace Type: NTFS
           Is Filespace Unicode?: Yes
                   Capacity (MB): 1,907,538.3
                        Pct Util: 35.8
     Last Backup Start Date/Time: 12/12/2006 16:55:08
  Days Since Last Backup Started: 1
Last Backup Completion Date/Time: 12/13/2006 11:25:35
Days Since Last Backup Completed: <1

Any suggestion ?

Thanks in advance

Otto

-----Ursprüngliche Nachricht-----
Von: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] Im Auftrag von
Pete Tanenhaus
Gesendet: Dienstag, 12. Dezember 2006 21:09
An: ADSM-L AT VM.MARIST DOT EDU
Betreff: [ADSM-L] Fw: JBB Question(s)

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