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:[EMAIL PROTECTED] Im Auftrag von Laurent Bendavid Gesendet: Mittwoch, 13. Dezember 2006 20:06 An: ADSM-L@VM.MARIST.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:[EMAIL PROTECTED] Im Auftrag > von Pete Tanenhaus > Gesendet: Dienstag, 12. Dezember 2006 21:09 > An: ADSM-L@VM.MARIST.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: [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 > > > > 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.
