<font color="navy" face="Arial" size="2"><span style="font-size: 10pt; font-family: Arial; color: navy;">CSAM is transaction based.  We are looking
at log shipping however the recovery process would be manual (ie replay logs
and reinitialize app and domain settings) and in the event of a disaster (given
the client has little *nix skills) are seeking a more 'automated'
process (off the shelf might be better term).</span></font><br><br><div><span class="gmail_quote">On 1/24/07, <b class="gmail_sendername">Bernd Felsche</b> <<a href="mailto:bernie@innovative.iinet.net.au">bernie@innovative.iinet.net.au
</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">"Anne Busby" <<a href="mailto:anne.busby@gmail.com">anne.busby@gmail.com
</a>> writes:<br><br>>I have been asked the following :<br><br>>Has anyone come across a Business Continuity Solution for CSAM (ie Pronto).<br>>We need to minimize both down time and potential data loss that might occur
<br>>during a time of 'disaster'  We are looking at VM'ing and snap shot copying<br>>across dark fibre however are under the impression that the platform we have<br>>(P-Series IBM) wont support VM.  Is there a native unix/linux DR mechanism
<br>>we can use?<br><br>>What do people use ???<br><br>On a transaction-based system; transaction log transfers (or<br>mirrors) for the database(s). This can usually be done as often as<br>once a minute. Using something like rsync makes it possible to
<br>have the backup at a remote location; connected at low bandwidth.<br>128kbps has historically been used successfully on other RDBMS with<br>about 100 users on the MRP/DRP application. There was ample residual<br>bandwidth to have about 20 of those 100 users interact with the
<br>(ChUI) application over the same link.<br><br>You need to find out if CSAM is transaction-based, and if so, how to<br>transfer/backup the logs.<br><br>If it's not transaction-based, then there are much bigger problems
<br>lurking within a business database environment. It won't be a<br>cataclysmic disaster; but more like an insidious cancer on the data.<br>--<br>/"\ Bernd Felsche - Innovative Reckoning, Perth, Western Australia
<br>\ /  ASCII ribbon campaign | "If we let things terrify us,<br> X   against HTML mail     |  life will not be worth living."<br>/ \  and postings          | Lucius Annaeus Seneca, c. 4BC - 65AD.<br><br>_______________________________________________
<br>PLUG discussion list: <a href="mailto:plug@plug.org.au">plug@plug.org.au</a><br><a href="http://www.plug.org.au/mailman/listinfo/plug">http://www.plug.org.au/mailman/listinfo/plug</a><br>Committee e-mail: <a href="mailto:committee@plug.linux.org.au">
committee@plug.linux.org.au</a><br></blockquote></div><br>