Re.archive
Hi, My plan is to keep the production database 3 hours old from the production, so that we can roll-back in case of problem. Option of ER is not possible because our apps doesn't support and roll forward of logical log is not advisable to us because it will take time and we need instance switch over to the other copy database. HDR is already in place to different location, but by the time we know the problems the production database will immediately get replicated to the seconday server so we cannot rely on this option. Need your suggestion/guidance on my following thought. 1) Take the archive and copy it on the same server with different instance name, (but the problem is: it will have the same chunk path) and apply the logical logs of original database to copy database so that we have min. production downtime : any suggestion here ?????. 2) Other options of UNLOAD/HPL/ONUNLOAD etc are not advisable due to time constraints. -------------------------------------------------------------------------------- ----------------------------------------------- Thanks in advance. Sushil... _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail
Sushil Your first sentence doesn't make sense! " ... the production database 3 hours old from the production, so .... " ^^^^^^^^^^ ^^^^^^^^^^ What is the anticipated problem you want to roll back from? Do you need to roll back the whole server or just the problem transaction? ER is independent of the application, it is an engine function and (if you have enough space configured) it can be set up to pass changes over every 3 hours. Again, what are the problems that you think may occur? This seems to be more an application solution than an engine solution. Keith -> -----Original Message----- -> From: Sushil Shir.... [mailto:sushilps@hotmail.com] -> Sent: Sunday, May 11, 2003 2:12 PM -> To: ids@iiug.org -> Subject: Re.archive[1112] -> -> -> Hi, -> -> My plan is to keep the production database 3 hours old from -> the production, -> so that we can roll-back in case of problem. Option of ER -> is not possible -> because our apps doesn't support and roll forward of logical -> log is not -> advisable to us because it will take time and we need -> instance switch over -> to the other copy database. HDR is already in place to -> different location, -> but by the time we know the problems -> the production database will immediately get replicated to -> the seconday -> server so we cannot rely on this option. -> -> Need your suggestion/guidance on my following thought. -> -> 1) Take the archive and copy it on the same server with -> different instance -> name, (but the problem is: it will have the same chunk -> path) and apply the -> logical logs of original database to copy database so that -> we have min. -> production downtime : any suggestion here ?????. -> -> 2) Other options of UNLOAD/HPL/ONUNLOAD etc are not -> advisable due to time -> constraints. -> ------------------------------------------------------------- -> ------------------------------------------------------------------ -> Thanks in advance. -> Sushil... -> -> _________________________________________________________________ -> Add photos to your messages with MSN 8. Get 2 months FREE*. -> http://join.msn.com/?page=features/featuredemail -> -> ******************************************************************************** ** This message is sent in strict confidence for the addressee only. It may contain legally privileged information. The contents are not to be disclosed to anyone other than the addressee. Unauthorised recipients are requested to preserve this confidentiality and to advise the sender immediately of any error in transmission. This footnote also confirms that this email message has been swept for the presence of computer viruses, however we cannot guarantee that this message is free from such problems. ******************************************************************************** **
Keith, 3 hours duration is the time we think so that we can be aware of the problem which might occur due to the application or any user related mistakes on the database. (this is due to some development test which is directly done on production machine due to some environment issues). And if you think ER is independent of application then I would definetly try it, what will the adverse impact if for some reason it doesn't work, these are some of the reason which I got from the rel.notes related to ER.. 1) All tables should have primary keys. 2) Issued with cascading deletes. 3) Should avoid placing a NOTNull constraint on any replicated column that includes out-of-row data. 4) Advisable to use SERIAL8. 5) Creating or altering a cluster index on a replicated table is not allowed. 6) Cannot change the structure when the table is replicated and cannot run "drop table","rename table" & "alter fragment". 7) ER does not support replication of simple large objects stored on optical devices. -------------------------------------------------------------------------------- ------------------------------------------ Sushil... >From: "Simmons, Keith" <keith.simmons@bbslimited.co.uk> >To: "'Sushil Shir....'" <sushilps@hotmail.com> >CC: "'ids@iiug.org'" <ids@iiug.org> >Subject: RE: Re.archive[1112] Date: Mon, 12 May 2003 10:49:18 +0100 >MIME-Version: 1.0 >Received: from ntstso13.theso.co.uk ([194.128.65.252]) by >mc1-f15.law16.hotmail.com with Microsoft SMTPSVC(5.0.2195.5600); Mon, 12 >May 2003 02:49:32 -0700 >Received: from [10.16.5.50] by ntstso13.theso.co.uk (NTMail >7.00.0022/NY1817.00.35e8284e) with ESMTP id cmxrqaaa for >sushilps@hotmail.com; Mon, 12 May 2003 10:49:30 +0100 >Received: by tsoexc01.theso.co.uk with Internet Mail Service >(5.5.2653.19)id <KRY1R50P>; Mon, 12 May 2003 10:49:27 +0100 >X-Message-Info: JGTYoYF78jEHjJx36Oi8+Q1OJDRSDidP >Message-ID: <70C8E4409F6DD411899500805FFE967C0EC5DF05@tsoexc01.theso.co.uk> >Return-Receipt-To: "Simmons, Keith" <keith.simmons@bbslimited.co.uk> >X-Mailer: Internet Mail Service (5.5.2653.19) >Return-Path: keith.simmons@bbslimited.co.uk >X-OriginalArrivalTime: 12 May 2003 09:49:32.0426 (UTC) >FILETIME=[C9E45EA0:01C3186B] > >Sushil > >Your first sentence doesn't make sense! " ... the production database 3 >hours >old from the production, so .... " ^^^^^^^^^^ > ^^^^^^^^^^ >What is the anticipated problem you want to roll back from? Do you need to >roll back the whole server or just the problem transaction? >ER is independent of the application, it is an engine function and (if you >have enough space configured) it can be set up to pass changes over every 3 >hours. >Again, what are the problems that you think may occur? This seems to be >more >an application solution than an engine solution. > >Keith > >-> -----Original Message----- >-> From: Sushil Shir.... [mailto:sushilps@hotmail.com] >-> Sent: Sunday, May 11, 2003 2:12 PM >-> To: ids@iiug.org >-> Subject: Re.archive[1112] >-> >-> >-> Hi, >-> >-> My plan is to keep the production database 3 hours old from >-> the production, >-> so that we can roll-back in case of problem. Option of ER >-> is not possible >-> because our apps doesn't support and roll forward of logical >-> log is not >-> advisable to us because it will take time and we need >-> instance switch over >-> to the other copy database. HDR is already in place to >-> different location, >-> but by the time we know the problems >-> the production database will immediately get replicated to >-> the seconday >-> server so we cannot rely on this option. >-> >-> Need your suggestion/guidance on my following thought. >-> >-> 1) Take the archive and copy it on the same server with >-> different instance >-> name, (but the problem is: it will have the same chunk >-> path) and apply the >-> logical logs of original database to copy database so that >-> we have min. >-> production downtime : any suggestion here ?????. >-> >-> 2) Other options of UNLOAD/HPL/ONUNLOAD etc are not >-> advisable due to time >-> constraints. >-> ------------------------------------------------------------- >-> ------------------------------------------------------------------ >-> Thanks in advance. >-> Sushil... >-> >-> _________________________________________________________________ >-> Add photos to your messages with MSN 8. Get 2 months FREE*. >-> http://join.msn.com/?page=features/featuredemail >-> >-> > >******************************************************************************* *** >This message is sent in strict confidence for the addressee only. It may >contain legally privileged information. The contents are not to be >disclosed >to anyone other than the addressee. Unauthorised recipients are requested >to preserve this confidentiality and to advise the sender immediately of >any >error in transmission. >This footnote also confirms that this email message has been swept for the >presence of computer viruses, however we cannot guarantee that this message >is free from such problems. >******************************************************************************* *** _________________________________________________________________ Tired of spam? Get advanced junk mail protection with MSN 8. http://join.msn.com/?page=features/junkmail