Hey Sandra,

I do not think myself to be an expert at this, but I have recently been
working on some flashcopy situations.  Here is how I handle my DB's.  (Note
these are backups using the R3 tdp (backint).  Perhaps someone can advise
me on a better method.

On the primary database server:
1. The database in question is not in archive log mode.  If it were, I
would need to first place all tablespaces in backup mode.
2. Trigger the flashcopy via the Command Line Interface. Currently, we are
using the copy option, but I am reviewing the nocopy option.
3. At this point I would be able to take the tablespaces out of backup
mode, but I do not because I an not in archive log mode.

On the flashcopy server:
4. Activate the volume groups, and filesystems using the flashcopied disks.
5. Correct the dsm.sys, dsm.opt, and tdp configuration files to specify
that this is the primary database node name.
6. Trigger an offline database backup using brbackup (SAP routine).  The
brbackup process opens the database as the first step.  This reads the redo
logs and stabilizes the database.  It then shuts down the database and
proceeds to backup the database files (offline).
7. Copy all log files from the backup directory onto the primary database
server (so we have a proper backup history).
8. De-activate the filesystems and volume groups.

On the primary database server:
9. If this were a nocopy flash, the flashcopy relationship would need to be
withdrawn here.
10. Trigger a normal "dsmc i" process.  Since the database directories are
excluded, this takes all of two minutes and does not require downtime.

Because I change the configuration files to reflect the primary database
node name, there is no problem keeping track of which node this came from.
Also, when the time of disaster hits, I am able to restore the files
directly back to the primary node.  I do not need to restore it the copy
server first.

Timing is a very important issue as only one database can be active at any
time, but backups can occur 24/7 using the copy server scenario.

Of course, backups are nothing without the ability to restore.  Always test
your ability to restore the data to the primary server and/or a DR server.




                      Sandra
                      <sadi AT SUPER DOT NET.P        To:       ADSM-L AT 
VM.MARIST DOT EDU
                      K>                       cc:
                      Sent by: "ADSM:          Subject:  FlashCopy backups
                      Dist Stor
                      Manager"
                      <[email protected]
                      .EDU>


                      10/08/2004 09:29
                      AM
                      Please respond to
                      "ADSM: Dist Stor
                      Manager"






Dear All,
The mechanism for FlashCopy is that one production host, which has a)TSM
B/A
Client b)TDP for DB installed, initiates the backup and only the flasCopy
is
created.

The other host then initiates the backup process and actually copies this
flashcopy.

On the implementation side: how do we actually track this backup if we have
to
take backup of say 5 servers?

Is this supported on Linux, AIX, etc?

Kindest Regards
 Sandra