So let me repeat in short to realize what you've done:
- you had a TSM server with lot of data (45 GB DB, 1000 desktops and
unknown number of servers, etc.);
- you had "vario(u)s errors" and intentionally ignored them;
- you preferred to abandon the supported export/import and step deeply in
unexplored lands of cross-system restore;
- you have done some intuitive "performance improvement" but system still
does not perform according to the expectations.
Now the questions I have after all:
- how much your company values the data stored in that server?
- who was the bright guy "inventing" this migration plan?
- why you did not asked someone *before* migration?
- have you ever tested the performance of same Sun server with clean and
correct install of TSM server?
- if yes, what was the performance and how it compares to current one?
- what kind of errors did you had?
- and why you did not attempted to resolve them first?
Zlatko Krastev
IT Consultant
Douglas Currell <dlcurrell AT YAHOO DOT COM>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
23.02.2003 00:00
Please respond to "ADSM: Dist Stor Manager"
To: ADSM-L AT VM.MARIST DOT EDU
cc:
Subject: Slow client sessions
My organization recently migrated a 45GB TSM 5.1.5
database from an old AIX platform to a Sun V880
running Solaris 8. The migration of the database was
done by using "dsmserv restore db" as the export
failed on varios errors. A db audit was never
performed because of the downtime involved - days,
weeks, who knows?
The server has 4*900MHz Sparcs, 8GB RAM, one
functional Gb ethernet card, and 6*73 internal FC
disks. Externally, a JBOD was used, Sun's D2, 12*36GB
SCSI-3 disks. It was all configured with Disksuite in
this way. /, /usr, /opt were mirrored using two of the
internal disks. The other disks were configued as RAID
and had filesystems that contained primary db and log
volumes as well as a storage pool for Domino. The
external array was also configured as RAID 5 and had
filesystems that would contain the db and log copies
as well as other storage pools -Backuppool, etc.
When the system came up, performance was incredibly
poor and it became apparent that the bottleneck was
the D2 array which had problems migrating and backing
up simultaneously.
At that point or shortly thereafter, stgpool volumes
were spread between the internal disk and external
disk and the the db/log copies were deleted.
The current situation is that, after inspecting the
output from "q sessions", the client make contact with
the server and then sits in queue for a very long
time. Once the actual backup/restore starts, it runs
like greased lightning, however. Incidentally, there
are over 1000 desktop clients runiing 95, 98 and XP.
Any ideas, suggestions? Thank you...
______________________________________________________________________
Post your free ad now! http://personals.yahoo.ca
|
