On Feb 10, 2005, at 12:06 PM, Sandra wrote:
Dear All, TSM 5.2.3 on windows 2000 server. My server has space triggers for DB and Recovery log. As I now see the files there are 8 DB Files and 3 Recovery log files spanned on 2 partitions.
Kindly enlighten me on these !
Question 1: How do i get all these files merged into 1?
Why do you necessarily want to? TSM spreads disk activity over the volumes made available to it, which is advantageous where multiple disks and/or adapters and/or physical paths confer load distribution advantages. In the days of individual disks, spreading TSM volumes over them gained a lot of performance. In these days of disk arrays and storage units and SANs, the advantages are more elusive, but may still exist. It all depends upon how your site's storage is served. But, in general, there is nothing at all wrong with having multiple volumes.
Question 2: If I am taking full backups of Database daily, do i need to keep large recovery logs with me?
Read up on the role of the Recovery Log. It keeps track of db changes since the last backup, such that you can recover up to the point of failure. Without that, you can only recover up to the time of the backup. The size necessary for your Recovery Log depends upon what you see for a high water mark just before the next day's backup. I would not reduce RL space unless there were a very compelling reason. The reasons not to reduce size are embodied in all the past postings of customers in dire straits as their Recovery Log filled.
Question 3: If I have to restore DB using DRM, (This DB spanning multiple partitions and files which is backed up) would it restore all DB Files as single file or there will be multiple files like before? and additionally would there be any issue since previously i had DB files located on 2 different partitions?
In general. a DB restoral will spread over all the volumes made available to it at the time of restoral. In a DR situation, or a same-platform-type migration scenario, you would be allocating new volumes on that system, which need not look like the old system: the new system needs only to have at least as much space. However, in a DR replacement scenario, you would of course lose the Recovery Log, so could only restore to the point in time of the last full or full+incremental db backup. In a non-disaster scenario, you would probably have the RL, so would be that much better off. Just as an example: I used db restoral to migrate my db from an older AIX system to a modern one, with completely different disk layouts, and it was simply a matter of providing at least as much db space as had before.
hope that helps, Richard Sims
