ADSM-L

Re: [ADSM-L] Objects Assigned vs. Your Database.

2012-04-17 01:15:35
Subject: Re: [ADSM-L] Objects Assigned vs. Your Database.
From: Roger Deschner <rogerd AT UIC DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Tue, 17 Apr 2012 00:12:27 -0500
We do not allow Windows Vista/2008/7 System State backups to our
remaining V5.5 servers, and are reluctant to allow them on our new
V6.2.3 server. We enforce this with client option sets. Ever since Vista
landed, we have had extreme problems with the System State, and we
decided to simply prohibit backing it up. For even a V6.2 server,
backing up the Vista/2008/7 System State is like a snake swallowing a
whole pig.

OTOH, I too am seeing much faster overall DB operations on the V6.2
server, as Paul and Wanda have reported. But we've got a lot of V5.5
clients left, which means I have a lot of visits to reluctant faculty
members' offices ahead, who are still scared off by the abyssmal
performance of the Windows Java GUI client. Couldn't something be done
about this, such as bring back the native Windows dsmmfc client which
was an order of magnitude faster at V6.1?

(I do wish that systemstate and systemobject were aliases to one another
on the DOMAIN statement, because I have to constantly watch for people
who upgrade from Win XP (which has System Object) to Win 7 (which has
System State), and change their cloptset.)

Roger Deschner      University of Illinois at Chicago     rogerd AT uic DOT edu
======================= Java is a 4-letter word ========================



On Mon, 16 Apr 2012, Paul Zarnowski wrote:

>At 05:08 PM 4/16/2012, Prather, Wanda wrote:
>>But from experience at a customer where we had similar problems (Win2K8 
>>clients were taking 8 hours for the incremental systemstate backup), the 
>>long-term solution is to get your clients to a V6.2+ TSM server.
>
>
>I'll echo Wanda's observations.  We've been at 6.2 for awhile now, and it has 
>solved a lot of these kinds of issues.  Expiration and DB backups fly now.  
>System State backups (and expirations) are no longer the problem that they 
>were.  I should mention that we did more than just upgrade to 6.2 - we also 
>upgraded our server at the same time, so that might have helped a bit too.
>
>..Paul
>
>
>
>--
>Paul Zarnowski                            Ph: 607-255-4757
>CIT Infrastructure / Storage Services     Fx: 607-255-8521
>719 Rhodes Hall, Ithaca, NY 14853-3801    Em: psz1 AT cornell DOT edu
>

<Prev in Thread] Current Thread [Next in Thread>