Re: Ang: Re: [ADSM-L] Ang: Re: [ADSM-L] vtl versus file systems for pirmary pool
"ADSM: Dist Stor Manager" wrote on 09/29/2011 01:34:23 PM: > The elephants in the room: > > It is tempting, once DD gets in the door, to move all database > backups (the typical TDP/RMAN and SQLLiteSpeed stuff) to go directly > to DD. (No TSM involved, so save money on licenses?) > This is exactly our big discussion. Our DD's are currently on TSM servers that are scheduled to go away next year. At that point we will re-purpose the DD's for other duty. Our big discussion is what would make best use of them. We've come up with two options: 1) Use for the file pool for windows nodes. This is the simplest and most straight forward use since it's just a swap out of tape for a file pool. We think this would really help in a DR situation with many concurrent restores running since file pool volumes can have multiple readers. We would have to put 10g ethernet cards in our TSM servers, but that's about it. 2) Use for our BIG Oracle systems that use lanfree storage agents and TDPO. We have a bunch of big SAP systems (in two tsm instances) that would be really good use of the DD. It's highly dedupable/compressable data and is a very large part of our total TSM occupancy. But, how to use the DD with this environment (31 lanfree/storageagents for big Oracle/Rman systems). The only supported method lanfree would be VTL, and we REALLY want to get rid of all the tape setup and stuff. We also don't have the VTL license for the DD. As we started to think about it, we realized that TDPO/lanfree is simply providing a container for Oracle/RMAN. The value add by TSM is handling tape and creating offsite copy. Oracle/RMAN is capable of writing straight to disk by itself. If we were to directly NFS mount the DD to the Oracle servers and have RMAN back them up directly to the DD, we could bypass TSM completely. No more lanfree/tdpo licensing, setup, rmt devices. It would really simplify the environment. But, it would require much new work. We've discussed putting a 10g ethernet card in each AIX chassis and sharing it among the lpars. In other words, this option would be a lot of work and cost, but could be a huge gain in simplifying the environment and eliminating TSM licensing costs. Oh what to do . . . we have some time to think about it . . . Rick - The information contained in this message is intended only for the personal and confidential use of the recipient(s) named above. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately, and delete the original message.
Re: Ang: Re: [ADSM-L] Ang: Re: [ADSM-L] vtl versus file systems for pirmary pool
Rick, For certain situations we are looking at this too (clients living on DD), you may be aware but DD has an additional licensable feature called Retention Lock that allows history retention of data which provides version like restorability. Haven't used it yet, but for the discussion thought it was worth mentioning. ~Rick Jax, FL. -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Richard Rhodes Sent: Friday, September 30, 2011 8:25 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Ang: Re: [ADSM-L] Ang: Re: [ADSM-L] vtl versus file systems for pirmary pool "ADSM: Dist Stor Manager" wrote on 09/29/2011 01:34:23 PM: > The elephants in the room: > > It is tempting, once DD gets in the door, to move all database > backups (the typical TDP/RMAN and SQLLiteSpeed stuff) to go directly > to DD. (No TSM involved, so save money on licenses?) > This is exactly our big discussion. Our DD's are currently on TSM servers that are scheduled to go away next year. At that point we will re-purpose the DD's for other duty. Our big discussion is what would make best use of them. We've come up with two options: 1) Use for the file pool for windows nodes. This is the simplest and most straight forward use since it's just a swap out of tape for a file pool. We think this would really help in a DR situation with many concurrent restores running since file pool volumes can have multiple readers. We would have to put 10g ethernet cards in our TSM servers, but that's about it. 2) Use for our BIG Oracle systems that use lanfree storage agents and TDPO. We have a bunch of big SAP systems (in two tsm instances) that would be really good use of the DD. It's highly dedupable/compressable data and is a very large part of our total TSM occupancy. But, how to use the DD with this environment (31 lanfree/storageagents for big Oracle/Rman systems). The only supported method lanfree would be VTL, and we REALLY want to get rid of all the tape setup and stuff. We also don't have the VTL license for the DD. As we started to think about it, we realized that TDPO/lanfree is simply providing a container for Oracle/RMAN. The value add by TSM is handling tape and creating offsite copy. Oracle/RMAN is capable of writing straight to disk by itself. If we were to directly NFS mount the DD to the Oracle servers and have RMAN back them up directly to the DD, we could bypass TSM completely. No more lanfree/tdpo licensing, setup, rmt devices. It would really simplify the environment. But, it would require much new work. We've discussed putting a 10g ethernet card in each AIX chassis and sharing it among the lpars. In other words, this option would be a lot of work and cost, but could be a huge gain in simplifying the environment and eliminating TSM licensing costs. Oh what to do . . . we have some time to think about it . . . Rick - The information contained in this message is intended only for the personal and confidential use of the recipient(s) named above. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately, and delete the original message.
Reducing/Reclaiming tsmlog space
I recently expanded the log size from 60GB to 120GB to allow for an expected increase in transactions (was deleted 190M objects). Now that this is over, I need to shrink it back down to 60GB since the filespace it is using is shared by the DB and now I get a daily messages that the DB is running low on space (89.40% utilized. So what does it take to do this? I am guessing that simply changing the logsize to 60GB won't just magically reclaim the space Server is Linux 6.1.5.10 Zoltan Forray TSM Software & Hardware Administrator Virginia Commonwealth University UCC/Office of Technology Services zfor...@vcu.edu - 804-828-4807 Don't be a phishing victim - VCU and other reputable organizations will never use email to request that you reply with your password, social security number or confidential personal information. For more details visit http://infosecurity.vcu.edu/phishing.html
Unable to load library libTdpDOM.so
Fresh RHEL 5 install 64-bit Linux86. TSM client 6.1.3.0 and API TDP Domino 5.5.2.0 Installed successfully. Ran the dominstall as outlined and made the changes to the .bash_profile. Logged in as the domino user and when i run domdsmc I just keep getting the (title) error message and no further. Tried uninstall and reinstall with same results. Checked APAR IC59484 and I'm not receiving the indicated error messages. [root@dem ~]# su - dominodemo [dominodemo@dem ~]$ domdsmc Unable to load library libTdpDOM.so [dominodemo@dem ~]$ Any help would be GREATLY appreciated. Bill Boyer "There are seldom good technological solutions to behavioral problems." -??