I believe there is still a reason to mirror at the TSM level. If you mirror at the hardware level only and TSM writes a corrupt entry to the DB or log, you are hosed since the hardware mirror will write it to both copies. If TSM is doing the mirror, it can see that it had a problem writing to one copy and not write the corrupt data to the second copy. TSM can then use the good copy to fix the corrupt mirror. Now I do not know how or when this case can come up but that is the reason I was told to mirror at the TSM level. We use EMC for the storage. All our EMC storage is mirrored or raided. We then also mirror at the TSM level. This is over kill but we do not have any unprotected disks to use so we double do it. Have not had a problem but we may be wasting disks.
-- Phillip 320-4462 -----Original Message----- From: David Longo [mailto:[EMAIL PROTECTED] Sent: Friday, January 20, 2006 1:02 PM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] DB & LOG Volume layout - new I've just done a reconfig of my DB and LOG volumes that flies in the face of conventional wisdom - but it works! First, the essential parts of my environment: TSM Server 5.2.6.0 on AIX 5.2. Disk is an IBM FASTT 600 Turbo with the main drawer and (3) EXP-710 drawers (switched disk drawers). All 4 drawers are filled with (14) 73GB 15K FC drives. I have all Disk pools on here. RAID arrays are built with ONE disk from each drawer (max redundancy). I had moved from older disk system to this one about 9 months ago. For layout of DB and LOG at that time I had used standard method, layout out over many disks. So, I had about 8 GB LOG and 80GB DB at that time. I used RAID 0, one disk for each. So had 2 disks for log, one main and one mirrored. I used 8 disks for DB, 4 primary and 4 mirror. On the FAST Array, I carved out 10GB LUNS. At AIX level these 10GB LUNS were separate disks and I setup simple jfs filesystems on them. All mirroring was done at TSM level. I then at TSM level defined 1GB LOG vols and mirrored. I defined 5GB DB vols, two per filesystem and therefore had 16 DB vols and then 16 mirrors. (Also I have about 400 clients of all types and backup about 1.5 TB per day.) WHAT I CHANGED (and why): My 80 GB DB had crept up to 83% utilized on me. We had a slightly flaky disk on the FASTT that was one of my LOG disks. I had realized from the start that if one of these disks went, would take AIX and TSM work to rebuild. As this entire system was working well for me, I wanted to eliminate that problem in case of disk failure and also conserve disk space. So I created a 10GB LUN in extra space on one Disk pools Raid 5 Array and mirrored my LOG over to it and deleted the old volumes at TSM level. I noticed no problem running this way! My 8 GB log normally only hits 10% max, with occasional hits or 25-50% with client problems, and I also knew that log activity is not heavy I/O. So with this down, I created a RAID 5 array across 4 FASTT disks. Then for apples to apples comparison, I created 10 GB LUNS on FASTT like current DB uses. And created on AIX the same way also. I then at TSM level defined, mirrored over to the new DB vols and deleted all old mirrors to RAID 0 disks for half my DB. Ran 24 hours with no problem. Then I moved the rest of the DB over the next day. I then ran about a week with this and had no problems. Backups ran normal and easiest to measure is FULL DB Backup and Expiration. No increase in time! I then in same fashion increased my DB from 80GB to 100GB to get utilization down to 67%. That is, used same RAID 5 array and same LUN and DB vol size. I still get no increase in time for DB backup (well one minute now!) and expiration. No noticeable change in backups either. CONCLUSION? So, I have saved disks and made disk failure transparent, our guy that handles replacements can do this in minutes and I don't have to get involved. Maybe old philosophy has been overcome by newer/faster disks and disk systems? I now have no TSM mirror for LOG or DB. Old philosophy was that TSM mirror had "some slight extra protection" for TSM. Wonder if this is still true or not these days? Would basically have to use more disks for this and am on RAID 5 for both now. Comments anyone? David B. Longo System Administrator Health First, Inc. 3300 Fiske Blvd. Rockledge, FL 32955-4305 PH 321.434.5536 Pager 321.634.8230 Fax: 321.434.5509 [EMAIL PROTECTED] ############################################################## This message is for the named person's use only. It may contain confidential, proprietary, or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it, and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. Health First reserves the right to monitor all e-mail communications through its networks. Any views or opinions expressed in this message are solely those of the individual sender, except (1) where the message states such views or opinions are on behalf of a particular entity; and (2) the sender is authorized by the entity to give such views or opinions. ############################################################## ********************************************************************* This message and any attachments are solely for the intended recipient. If you are not the intended recipient, disclosure, copying, use or distribution of the information included in this message is prohibited -- Please immediately and permanently delete.
