FWIW, I had a problem the other year where the TSM server was in SENDW
for 30-40 seconds for every minute during a restore and it had to do with the
filesystem attempting to check quotas for the 125k users in the filesystem.
Disabling quota checks helped that one go much faster.
-Jonat
David Longo wrote:
How big is that DB? This thing really works still?
tsm: DATAKEEP.CAC.PSU.EDU>q db
Available Assigned Maximum MaximumPage Total Used Pct Max.
Space Capacity Extension ReductionSizeUsable Pages Util Pct
(MB) (MB) (MB) (MB
It took 4 days to finish.
fred johanson wrote:
How long did it take?
At 10:52 AM 8/31/2006 -0400, you wrote:
John Bremer said the following on 8/31/06 10:35 AM:
[TSM database reorganization]
> recommended. Problem is there is another dba up there, who has some
TSM
> experience, who
Roger Deschner said the following on 05/10/06 17:51:
When this thread was last active, I had discovered, thanks to a tip on
this list, that MEMORYEFFICIENTBACKUP YES was the default, and set it to
NO. That did help some.
But all our Mac clients still run extremely slowly. A WinXP box and a
Mac G
Roger Deschner wrote:
I have been getting complaints of slow backups from Mac client nodes.
I wanted to examine the possibility that this was not simply the whining
of a population already prone to whine, so I got a Mac OSX 10.3 G4 box
and put it on my desk, and installed TSM 5.3.2 client on i
Zoltan,
I had a similar problem on a Windows box with 5.4 million files. Tivoli
said that I couldn't do the backup/restore with a 32 bit client because
each file in the catalog takes 1k and the 32 bit program could only
address 4 GB of memory. Here is a link they gave me:
http://www-1.ibm.c
Lisa,
I go through this as well. It doesn't seem to matter how many you
order either. I have ordered shipments of 30 and 750 and both take the
same amount of time. I wonder if more than one company will be making the
3590 tapes with 384 tracks.
Jonathan
On Tue, 1 May 2001, Lisa Cabanas
