ADSM-L

Re: TSM Database Location

2002-04-26 03:51:31
Subject: Re: TSM Database Location
From: Zlatko Krastev <acit AT ATTGLOBAL DOT NET>
Date: Fri, 26 Apr 2002 00:10:44 +0300
Andy,

according to my Reference Manual regarding MIRRORWrite DB/LOG Parallel
option:
"If a system outage occurs at exactly the instant that each mirror is
partially complete in writing its page, a partial write to each mirror
could result."
If MIRRORWrite Sequential is used TSM would recover after restart.
If you do not have DB volumes' second copies and something goes wrong
(power supply failure, core dump, etc.) on DB write you can end up with
corrupted database. Yes, I know it is not so easy to achieve but is
possible. The measures you will take to prevent this from happening (or
minimize the impact) depend on the value of the backup data in your eyes
(or your management's eyes).

Zlatko Krastev
IT Consultant




Please respond to "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
Sent by:        "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
To:     ADSM-L AT VM.MARIST DOT EDU
cc:

Subject:        Re: TSM Database Location

I am a little confused here.  What kind of corruption are you talking
about?  If corrupted data gets written to one mirror, won't it get
written tothe other mirror too?


Andy Carlson                                    |\      _,,,---,,_
Senior Technical Specialist               ZZZzz /,`.-'`'    -.  ;-;;,_
BJC Health Care                                |,4-  ) )-,_. ,\ (  `'-'
St. Louis, Missouri                           '---''(_/--'  `-'\_)
Cat Pics: http://andyc.dyndns.org/animal.html


On Thu, 25 Apr 2002, Davidson, Becky wrote:

> Ilja
> We have some of our database volumes on the shark and I still mirror my
db
> volumes. You mirror not only to protect from disk errors but also to
protect
> from corruption.  I believe that there was a discussion recently of
someone
> who had a corrupted database volume.  A shark will not protect you from
that
> becky
>
> -----Original Message-----
> From: Ilja G. Coolen [mailto:ilja.coolen AT ABP DOT NL]
> Sent: Wednesday, April 24, 2002 5:00 PM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: TSM Database Location
>
>
> Well Jonathan,
>
> This is how we do it.
> We are running on an AIX box for starters.
> We have our 4 DB volumes on an separate filesystem. This is about 40GB
in
> total having 20 GB extendable. We do not mirror the DB volumes, because
the
> ESS provides all the redundancy we could need. No pain in case of disk
> crashes. No management burden. Leaves more resources to TSM. Our
database
> has a 50% mutation daily, but we manage to keep up a 98% to 99% cache
hit
> ratio. This high mutation level made us decide to do a full DB backup
twice
> a day. We also do a daily reset of all the utilization values.
>
> All our disk storage pool volumes also are on the same ESS, but in
different
> filesystems. These total to about 900 GB.
>
> We have 2 fibre channel connections directly attached to the ESS. No SAN
> yet. Both FC connections are based on redundancy and load-balancing
using
> IBM's subsystem device driver (shipped with the ESS). The ESS disks look
the
> same as local disks to an AIX box, so we simply put the ESS disks in AIX
> volume groups/logical volumes/file systems.
>
> Assumingin you know something about the ESS:
> Inside the ESS whe have defined our 4 (DB) disks on 4 different loops (2
> ranks or 8 packs) so we have 2 hot-spare disks available for each DB
volume.
> This also provides the best possible performance.
>
>
> So Jonathan. Put your primary DB volumes on an ESS, and you don't need
any
> mirrors.
> Let us know what you decide to do. Have fun.
>
> greetings,
>
> Ilja Coolen.
>
> -----Oorspronkelijk bericht-----
> Van: Jonathan Siegle [mailto:jsiegle AT PSU DOT EDU]
> Verzonden: woensdag 24 april 2002 17:03
> Aan: ADSM-L AT VM.MARIST DOT EDU
> Onderwerp: Re: TSM Database Location
>
>
> On Wed, 24 Apr 2002, Ilja G. Coolen wrote:
>
> > Hi,
> >
> > I'd suggest to move it to it's own filesystem placed on an redundant
disk
> > array, enjoying high performance and recoverability.
> > We placed our database volumes on an ESS subsystem. Where you place it
is
> > your own choice. Just try to achieve redundancy.
>
> Did you put all primary/copy db volumes on the ESS? What kind of db
cache
> hit are you getting? How are you talking to the ESS and how much other
> stuff is talking to the ESS while TSM is running? I am considering using
> the 2nd/3rd copy of the db for DRM purposes on an ESS.
>
> >
> >
> > Have fun.
> >
> >
> >
> > Ilja G. Coolen
> >
> >
> >   _____
> >
> > ABP / USZO
> > CIS / BS / TB / Storage Management
> > Telefoon         : +31(0)45  579 7938
> > Fax      : +31(0)45  579 3990
> > Email    : ilja.coolen AT abp DOT nl <mailto:ilja.coolen AT abp DOT nl>
> > Intranet
> >         : Storage Web
> > <http://intranet/cis_bstb/html_content/sm/index_sm.htm>
> >
> >   _____
> >
> > - Everybody has a photographic memory, some just don't have film. -
> >
> >
> > -----Oorspronkelijk bericht-----
> > Van: Brenda Collins [mailto:brenda.collins AT US.ING DOT COM]
> > Verzonden: woensdag 24 april 2002 13:37
> > Aan: ADSM-L AT VM.MARIST DOT EDU
> > Onderwerp: TSM Database Location
> >
> >
> > We are just setting up a new TSM server.  It appears to load the
default
> > database under /opt/tivoli/tsm/server/bin.  Is it common practice to
leave
> > it there or to move it to it's own separate location? Any
recommendations?
> >
> > Thanks,
> > Brenda
> >
>
> Jonathan Siegle                 Center for Academic Computing
> jsiegle AT psu DOT edu                 Penn State University
> 814-865-5840                    University Park, Pa 16802
>
<Prev in Thread] Current Thread [Next in Thread>