Taken from page 390 of TSM for AIX handbook.
2 sides to the coin...........................
The Advantages of Using Journal File System Files
TSM supports both journaled file system (JFS) files and raw logical volumes
as database,
recovery log, and disk storage pool volumes. JFS files have the following
advantages:
¶ When TSM has JFS files open, they are locked by JFS and other
applications cannot
write to them. However, raw volumes are not locked and any application can
write to
them. TSM tries to prevent starting more than one instance of the same
server from the
same directory, but it can be done. If you are using raw volumes, both
servers' instances
can simultaneously update the same information. This could cause errors in
the database,
recovery log, or storage pool raw volumes.
¶ After a database, recovery log, or storage pool volume is defined to TSM,
you cannot
change its size. TSM uses size information to determine where data is
placed and
whether volumes have been modified by other applications or utilities.
However, if you
use raw volumes, smit lets you increase their sizes. If the volume is
defined to TSM
before its size is increased, TSM cannot use the volume or its data.
¶ You should use TSM mirroring rather than AIX mirroring. If you use AIX
mirroring,
you may have a problem with raw volumes, but not with JFS files. AIX tracks
mirroring
activity by writing control information to the first 512 bytes of USER area
in a raw
volume. This is not a problem for database and recovery log volumes, but
TSM control
information is also written in this area. If AIX overwrites TSM control
information when
raw volumes are mirrored, TSM may not be able to vary the volume online.
The use of JFS files for database, recovery log, and storage pool volumes
requires slightly
more CPU than is required for raw volumes. However, JFS read-ahead caching
improves
performance.
Gabriel C. Wiley
ADSM/TSM Administrator
AIX Support
Phone 1-614-308-6709
Pager 1-877-489-2867
Fax 1-614-308-6637
Cell 1-740-972-6441
Siempre Hay Esperanza
Dale Jolliff
<dale.jolliff.b@B To: ADSM-L AT VM.MARIST
DOT EDU
AYER.COM> cc:
Sent by: "ADSM: Subject: Re: A Question to IBM
NSM Customers
Dist Stor
Manager"
<[email protected]
.EDU>
03/07/2002 09:54
AM
Please respond to
"ADSM: Dist Stor
Manager"
I found that moving the DB volumes off JFS to raw logical improved our
performance tremendously - our full DB backups took less than half the
previous
time to complete. It was a small system though, one L32 cabinet and a
single
frame LTO SCSI attached.
Unfortuneately, I haven't had the opportunity to be in an environment to
compare
different server hardware on the TSM server performance...
Is the NSM the only IBM box you have?
"Sutch, Ian
(London)" To:
ADSM-L AT VM.MARIST DOT EDU
<SutchIan@EXCHANGE cc:
.UK.ML.COM> Subject: Re: A Question to
IBM NSM Customers
Sent by: "ADSM:
Dist Stor Manager"
<[email protected].
EDU>
03/07/2002 08:50
AM
Please respond to
"ADSM: Dist Stor
Manager"
Dale,
Thanks for the info. Its good to know we are not alone!
We too have serious performance issues with the NSM'S and are also
frustrated by their lack of scalability.
We also have Sun TSM Servers using raw logical volumes that fly along
by comparison, we will go forward with TSM on Solaris as the platform of
choice.
Thanks for your response
> -----Original Message-----
> From: Dale Jolliff
> Sent: Thursday, March 07, 2002 12:38 PM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: A Question to IBM NSM Customers
>
> I had an NSM setup - we had performance issues that forced us to use raw
> logical
> volumes for storage and db, and that breaks the "supported"
> configuration.
> (try dealing with the NSM bunch in that situation!)
> I simply dealt with the OS and TSM support teams separately - calling
into
> the
> NSM support line was always a drawn out affair, and usually got me routed
> to one
> of the two groups anyway.
> Just my 2 pennies worth...
>
>
>
>
>
>
>
>
> "Sutch, Ian
> (London)" To:
> ADSM-L AT VM.MARIST DOT EDU
> <SutchIan@EXCHANGE cc:
> .UK.ML.COM> Subject: A Question to
> IBM NSM Customers
> Sent by: "ADSM:
> Dist Stor Manager"
> <[email protected].
> EDU>
>
>
> 03/07/2002 06:50
> AM
> Please respond to
> "ADSM: Dist Stor
> Manager"
>
>
>
>
>
>
> Hi,
>
> I would be interested in hearing from any Users/Organisations that
utilise
> IBM 3466 NSM's
> and struggle to navigate through the necessary IBM support Teams.
>
> As a user of NSM's I would expect, when raising a pmr, to have a single
> point of ownership
> of the problem, be it OS, hardware or TSM related.
> It has been common practice to be passed to one team who may say that the
> fault cannot be resolved by their
> team and thensuggest we raise another pmr with a different team!! Very
> frustrating
>
> I would be very interested to hear form anyone who has the same problem
or
> has managed to find a solution.
>
> Many thanks
|
