Hi again,

Yes, i did !

That's the reason why i sent the output of dbviewb and q fi to show that the
journal was activated before the incremental forever (with option
memoryefficientbackup yes) started/finished.

Any suggestion why there activation after that ?

TIA,

Otto

-----Ursprüngliche Nachricht-----
Von: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] Im Auftrag von
Laurent Bendavid
Gesendet: Mittwoch, 13. Dezember 2006 20:06
An: ADSM-L AT VM.MARIST DOT EDU
Betreff: Re: [ADSM-L] AW: [ADSM-L] Fw: JBB Question(s)

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
>
>
>
>   
Do you use an incremental forever backup ? Only a complete incremental 
forever update the backup date of filespace backuped which is used by 
JBB to be valid.