I have architected this extensively in one vendor's environment.  With a 
well-designed architecture, all of the issues that you mention  (except not 
having secondary servers to mount the images on to do the backup) can be 
mitigated.  For example. You can check the state of the tablespaces before 
doing the split to determine if a script already put them in hot backup mode.  
It mostly just take working through all the issues one by one.

Mark


----------------------------------------------------------------------

Message: 1
Date: Wed, 20 Jun 2012 18:37:29 -0700
From: dy018 <nbu-forum AT backupcentral DOT com>
Subject: [Veritas-bu]  Backup using Storage Level Flash for DB
        (FC,BC,SI)
To: VERITAS-BU AT MAILMAN.ENG.AUBURN DOT EDU
Message-ID: <1340242649.m2f.374058 AT www.backupcentral DOT com>

Hi Jeff,

Thanks for sharing your experience on your enviornment.

I might need to clarify further, this method of backup does work but i guess it 
varies from different environment setup.
>>From your main reason that you stated, i've no doubt about what benefit it 
>>brings but i'm not convince this method applies to all DB backup in one 
>>enviornment. Imagine for one enviornment do not have a share SAN infra and 
>>each project had it dedicated SAN switch and SAN media server or SAN client 
>>to perform the backup for the DB servers. This is reason i feel from the 
>>backup team, the member needs to know all these different DB servers backup 
>>(something like network NAT), what is that particular SAN media or client is 
>>mounting the split mirror disk for its backup because the DBA will submit the 
>>restore request of the actual DB server.

The 2nd problem my enviornment face will be each project might purchase 
differnet type of storage, IBM, EMC, HDS and the list goes on, the splitting 
script which we deploy needs to be consistant, each time a new storage was 
introduced, new script needs to be written and tested before release to 
production. And to deploy such backup in my enviornment requires afew teams 
effort to make the backup work as explain in my first post. 

As for the single point of failure i describe is actually referring to backup 
and not restore. The point is each project might only purchase 1 dedicated SAN 
media or client to mount the mirror disk as they do not plan to buy redundancy 
for this and they also feel its a waste of the SAN switch port as well. We had 
a setup of 10 different DB server using 1 SAN client for it mirror LUN backup 
as it comes from the same project and my concern is that if that SAN client 
went down, all DB servers backup will be affected.

Running multiple stream, we are using bpstart notify script on the SAN client 
to ssh into the DB server into put the DB into backup mode and split the mirror 
before putting the DB into end backup mode prior to mounting up for backup. We 
may need to use parent start notify to ensure we only run the DB script once 
per backup job as the bpstart notify will trigger more than once depend how 
many streams we set on the backup policy.

+----------------------------------------------------------------------
|This was sent by dy_lan018 AT yahoo DOT com via Backup Central.
|Forward SPAM to abuse AT backupcentral DOT com.
+----------------------------------------------------------------------




------------------------------

Message: 2
Date: Thu, 21 Jun 2012 08:01:53 +0530
From: Abhishek Dhingra1 <abhishek.dhingra AT in.ibm DOT com>
Subject: [Veritas-bu] Out of office
To: VERITAS-BU AT mailman.eng.auburn DOT edu
Message-ID:
        <OFC046A45C.C383201F-ON65257A24.000DE825-65257A24.000DE825 AT in.ibm 
DOT com>
Content-Type: text/plain; charset=US-ASCII


I will be out of the office starting  06/21/2012 and will not return until
06/23/2012.

I will be out of office starting from 06/21/2012 to 06/23/2012. I will have
no access to email . For any  escalation kindly contact Akhil Mehrotra
(9958000151)



------------------------------

_______________________________________________
Veritas-bu maillist  -  Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu


End of Veritas-bu Digest, Vol 74, Issue 12
******************************************
_______________________________________________
Veritas-bu maillist  -  Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu