HDR Replication under 11.50.FC6 - resending backed

Good morning, I have a situation where my HDR read-only secondary database server (IDS 11.50.FC6) looses communication during heavy DB processing loads on my HDR primary. My backup application (EMC Networker) backs-up Logical Logs instantaneously when the logical log completes using onbar. My problem is, my HDR read-only secondary isn't getting all of the logical logs since it lost communication with the primary. This only way I know how to recover from this is doing a full system backup on the primary and doing a physical restore on the HDR secondary. Is there a better way? Is there a way to re-send logical logs that have been backed-up? Here is what I need to resend from my HDR Pimary to the HDR read-only Secondary: IBM Informix Dynamic Server Version 11.50.FC6 -- On-Line (Prim) -- Up 7 days 14:36:19 -- 28707684 Kbytes address number flags uniqid begin size used %used 4aacbf300 64 U-B---- 21921 3:8257589 131072 131072 100.00 4aacbf368 65 U-B---- 21922 3:8388661 131072 131072 100.00 4aacbf3d0 66 U-B---- 21923 3:8519733 131072 131072 100.00 4aacbf438 67 U-B---- 21924 3:8650805 131072 131072 100.00 4aacbf4a0 68 U-B---- 21925 3:8781877 131072 131072 100.00 4aacbf508 69 U-B---- 21926 3:8912949 131072 131072 100.00 4aacbf570 70 U-B---- 21927 3:9044021 131072 131072 100.00 4aacbf5d8 71 U-B---- 21928 3:9175093 131072 131072 100.00 4aacbf640 72 U-B---- 21929 3:9306165 131072 131072 100.00 4aacbf6a8 73 U-B---- 21930 3:9437237 131072 131072 100.00 4aacbf710 74 U-B---- 21931 3:9568309 131072 131072 100.00 4aacbf778 75 U-B---- 21932 3:9699381 131072 131072 100.00 4aacbf7e0 76 U-B---- 21933 3:9830453 131072 131072 100.00 4aacbf848 77 U-B---- 21934 3:9961525 131072 131072 100.00 4aacbf8b0 78 U-B---- 21935 3:10092597 131072 131072 100.00 4aacbf918 79 U-B---- 21936 3:10223669 131072 131072 100.00 4aacbf980 80 U-B---- 21937 3:10354741 131072 131072 100.00 4aacbf9e8 81 U-B---- 21938 3:10485813 131072 131072 100.00 4aacbfa50 82 U-B---- 21939 3:10616885 131072 131072 100.00 4aacbfab8 83 U-B---- 21940 3:10747957 131072 131072 100.00 4aacbfb20 84 U-B---- 21941 3:10879029 131072 131072 100.00 4aacbfb88 85 U-B---- 21942 3:11010101 131072 131072 100.00 4aacbfbf0 86 U-B---- 21943 3:11141173 131072 131072 100.00 4aacbfc58 87 U-B---- 21944 3:11272245 131072 131072 100.00 4aacbfcc0 88 U-B---- 21945 3:11403317 131072 131072 100.00 4aacbfd28 89 U-B---- 21946 3:11534389 131072 131072 100.00 4aacbfd90 90 U-B---- 21947 3:11665461 131072 131072 100.00 4aacbfdf8 91 U-B---- 21948 3:11796533 131072 131072 100.00 4aacbfe60 92 U---C-L 21949 3:11927605 131072 69706 53.18 Any ideas? Or am I stuck with full backup and physical restore? Thanks in advance for any advice. Jonathan B. Smaby Pomona College -- "If you are not willing to risk the unusual, you will have to settle for the ordinary." - Jim Rohn ------------------------------------------------------------- This message has been scanned by Postini anti-virus software.

As long as the last log that the secondary saw is still online on the primary (ie the ordinal log hasn't been overwritten with a new uniqid) then the secondary should just catch up on its own as soon as communications is restored. At worst, sometimes you have to run onmode -d on the two servers again to force them to begin syncing. Whether the logs were archived or not doesn't matter, only if the log is still online. So, for example below, the oldest log file still online is uniqid 21921. If the last log that the secondary saw was 21921 or later then you should be OK. If the last log the secondary saw was 21920 or earlier (see onstat -g dri) then, yes, you have to start replication over using a physical restore. So, the way to avoid having to restore during such communication outages is to make sure that there are enough logical logs online that they will not wrap before communications can be restored. If you follow my rule-of-thumb on this and try to have three to four days of logs online, you should rarely have a problem. Art Art S. Kagel Advanced DataTools (www.advancedatatools.com) Blog: http://informix-myview.blogspot.com/ Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on my employer, Advanced DataTools, the IIUG, nor any other organization with which I am associated either explicitly, implicitly, or by inference. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves. On Mon, Apr 2, 2012 at 1:50 PM, Jonathan Smaby <Jonathan.Smaby@pomona.edu>wrote: > Good morning, > > I have a situation where my HDR read-only secondary database server (IDS > 11.50.FC6) looses communication during heavy DB processing loads on my HDR > primary. My backup application (EMC Networker) backs-up Logical Logs > instantaneously when the logical log completes using onbar. My problem is, > my > HDR read-only secondary isn't getting all of the logical logs since it lost > communication with the primary. This only way I know how to recover from > this > is doing a full system backup on the primary and doing a physical restore > on > the HDR secondary. Is there a better way? Is there a way to re-send logical > logs that have been backed-up? > > Here is what I need to resend from my HDR Pimary to the HDR read-only > Secondary: > > IBM Informix Dynamic Server Version 11.50.FC6 -- On-Line (Prim) -- Up 7> days > 14:36:19 -- 28707684 Kbytes > > address number flags uniqid begin size used %used > 4aacbf300 64 U-B---- 21921 3:8257589 131072 131072 100.00 > 4aacbf368 65 U-B---- 21922 3:8388661 131072 131072 100.00 > 4aacbf3d0 66 U-B---- 21923 3:8519733 131072 131072 100.00 > 4aacbf438 67 U-B---- 21924 3:8650805 131072 131072 100.00 > 4aacbf4a0 68 U-B---- 21925 3:8781877 131072 131072 100.00 > 4aacbf508 69 U-B---- 21926 3:8912949 131072 131072 100.00 > 4aacbf570 70 U-B---- 21927 3:9044021 131072 131072 100.00 > 4aacbf5d8 71 U-B---- 21928 3:9175093 131072 131072 100.00 > 4aacbf640 72 U-B---- 21929 3:9306165 131072 131072 100.00 > 4aacbf6a8 73 U-B---- 21930 3:9437237 131072 131072 100.00 > 4aacbf710 74 U-B---- 21931 3:9568309 131072 131072 100.00 > 4aacbf778 75 U-B---- 21932 3:9699381 131072 131072 100.00 > 4aacbf7e0 76 U-B---- 21933 3:9830453 131072 131072 100.00 > 4aacbf848 77 U-B---- 21934 3:9961525 131072 131072 100.00 > 4aacbf8b0 78 U-B---- 21935 3:10092597 131072 131072 100.00 > 4aacbf918 79 U-B---- 21936 3:10223669 131072 131072 100.00 > 4aacbf980 80 U-B---- 21937 3:10354741 131072 131072 100.00 > 4aacbf9e8 81 U-B---- 21938 3:10485813 131072 131072 100.00 > 4aacbfa50 82 U-B---- 21939 3:10616885 131072 131072 100.00 > 4aacbfab8 83 U-B---- 21940 3:10747957 131072 131072 100.00 > 4aacbfb20 84 U-B---- 21941 3:10879029 131072 131072 100.00 > 4aacbfb88 85 U-B---- 21942 3:11010101 131072 131072 100.00 > 4aacbfbf0 86 U-B---- 21943 3:11141173 131072 131072 100.00 > 4aacbfc58 87 U-B---- 21944 3:11272245 131072 131072 100.00 > 4aacbfcc0 88 U-B---- 21945 3:11403317 131072 131072 100.00 > 4aacbfd28 89 U-B---- 21946 3:11534389 131072 131072 100.00 > 4aacbfd90 90 U-B---- 21947 3:11665461 131072 131072 100.00 > 4aacbfdf8 91 U-B---- 21948 3:11796533 131072 131072 100.00 > 4aacbfe60 92 U---C-L 21949 3:11927605 131072 69706 53.18 > > Any ideas? Or am I stuck with full backup and physical restore? > > Thanks in advance for any advice. > > Jonathan B. Smaby > Pomona College > -- > "If you are not willing to risk the unusual, you will have to settle for > the > ordinary." - Jim Rohn > > ------------------------------------------------------------- > This message has been scanned by Postini anti-virus software. > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --14dae9340815a9e84304bcb5f0d0