Hi Andy! It depends... If you are using OS or adapter mirroring: yes. If you are using TSM mirroring: not necessarily. About a week ago (http://msgs.adsm.org/cgi-bin/get/adsm0204/1043.html) Stuart Ward received the following message in his activity log:
04/18/2002 08:03:15 ANR0207E Page address mismatch detected on database volume F:\ADSM_SERVER\DB\DB5.DSM, logical page 821282 (physical page 3378466); actual: -1. 04/18/2002 08:03:15 ANR0247I Database page 821280 successfully read from an alternate copy on volume E:\ADSM_SERVER\DB\DB5COPY.DSM. So, in this case, a corruption in one database files did not lead to corruption on the mirror. Kindest regards, Eric van Loon KLM Royal Dutch Airlines -----Original Message----- From: Andrew Carlson [mailto:[EMAIL PROTECTED]] Sent: Thursday, April 25, 2002 21:04 To: [EMAIL PROTECTED] 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:[EMAIL PROTECTED]] > Sent: Wednesday, April 24, 2002 5:00 PM > To: [EMAIL PROTECTED] > 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:[EMAIL PROTECTED]] > Verzonden: woensdag 24 april 2002 17:03 > Aan: [EMAIL PROTECTED] > 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 : [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > > 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:[EMAIL PROTECTED]] > > Verzonden: woensdag 24 april 2002 13:37 > > Aan: [EMAIL PROTECTED] > > 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 > [EMAIL PROTECTED] Penn State University > 814-865-5840 University Park, Pa 16802 > ********************************************************************** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. **********************************************************************
