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
| 