Secundary server - fast recovery mode

Hello, everyone. After an immediate shutdown of the servers and a subsequent startup, informix on the secondary server stopped working. Primary server is working, but the secondary server is on recovery mode. What should i do? Primary server: IBM Informix Dynamic Server Version 14.10.FC4W1WE -- On-Line (Prim) -- Up 03:07:53 -- 1182144 Kbytes Message Log File: C:\\informix\\ol_unifato.log11:13:08 DR: Cannot connect to secondary server 11:13:08 DR: Turned off on primary server 11:14:08 DR: Cannot connect to secondary server 11:14:08 DR: Turned off on primary server 11:15:08 DR: Cannot connect to secondary server 11:15:08 DR: Turned off on primary server 11:15:09 Checkpoint Completed: duration was 0 seconds. Secundary server: C:\\Windows\\system32>onstat -m IBM Informix Dynamic Server Version 14.10.FC4W1WE -- Fast Recovery (Sec) -- Up 00:14:11 -- 596032 Kbytes Message Log File: C:\\informix\\ol_unifato_sec.log 09:58:58 Warning: stat() failed for chunk file E:\\IFXDATA\\ol_unifato\\unifato_vndmngdbs.000 09:58:58 Warning: stat() failed for chunk file E:\\IFXDATA\\ol_unifato\\unifato_pagamentosdbs.000 09:58:58 Warning: stat() failed for chunk file E:\\IFXDATA\\ol_unifato\\unifato_fchhistoricodbs.000 09:58:58 Warning: stat() failed for chunk file E:\\IFXDATA\\ol_unifato\\unifato_vndolsdbs.000 09:58:58 Warning: stat() failed for chunk file E:\\IFXDATA\\ol_unifato\\unifato_idxsLargeTablesDbs.000 09:58:58 Warning: stat() failed for chunk file E:\\IFXDATA\\ol_unifato\\unifato_idxsDbs.00009:58:58 IBM Informix Dynamic Server Initialized -- Shared Memory Initialized. 09:58:58 Started 1 B-tree scanners. 09:58:58 B-tree scanner threshold set at 5000. 09:58:58 B-tree scanner range scan size set to -1. 09:58:58 B-tree scanner ALICE mode set to 6. 09:58:58 B-tree scanner index compression level set to med. 09:58:58 Physical Recovery Started at Page (2:679589). 09:58:58 Physical Recovery Complete: 4 Pages Examined, 1 Pages Restored. 09:58:58 DR: Trying to connect to primary server = ol_unifato 09:58:58 smx creates 1 transports to server ol_unifato 09:59:00 Dataskip is now OFF for all dbspaces 09:59:00 Restartable Restore has been ENABLED 09:59:00 Recovery Mode Thanks. Cheers, Tiago Santos ------------------------------ Tiago Santos ------------------------------ #Informix

Try shutting the HDR secondary down and restarting it (or reboot the host). Art ------------------------------ Art S. Kagel, President and Principal Consultant ASK Database Management Corp. www.askdbmgt.com ------------------------------

Hi, looks like the secondary tries to connect to primary but somehow the primary does not accept the connection. 09:58:58 DR: Trying to connect to primary server = ol_unifato 09:58:58 smx creates 1 transports to server ol_unifato Check the connectivity (telnet to the ip/port of primary from secondary server). The connection is possibly not realized. The state of the secondary is expected to be in fast recovery, unless you modify the role. If the tcp connection can be established low-level, try to restart the secondary and see if it connects successfully. Good luck, Marcus Haarmann

Another point: in the log of your secondary instance, there are some warnings about non-accessible database chunk files. Pls make sure all the necessary dbspace files are present and can be accessed by the user the DB is running on. Best, Marcus Haarmann

Hi Art. Is now working. Only after restart de Primary, and then the secondary, stars working the HDR secondary. May be because the primary stay to mutch time waiting for the secondary server to be ON on first time i turned on (some minutes after)? Thanks a lot Cheers, Tiago Santos ------------------------------ Tiago Santos ------------------------------

Hi Marcus, Is now working. Only after restart de Primary, and then the secondary, stars working the HDR secondary. May be because the primary stay to mutch time waiting for the secondary server to be ON on first time i turned on (some minutes after)? Thanks a lot Cheers, Tiago Santos ------------------------------ Tiago Santos ------------------------------

Tiago, as Marcus said, the likely root cause of your problem is the chunk errors on the secondary that prevents it from restarting correctly. As per 'staying too much time waiting for the secondary to be ON': the secondary will synchronize just after it can reach the primary AND as long as the logical log of the primary has not been filled (i.e all the logical logs on disk written). If the primary starts writing 'at the beginning' of its logical logs, you'll have to do restart the sync (i.e restore the primary backup on the secondary) from scratch. Reading between the lines: the bigger your logical log, the longer your can do transactions on the primary without having to restart the sync from scratch. So: having a big logical log is good ------------------------------ [eric] [Vercelletto] [] [Founder] [kandooerp.org] [Pont l'Abbé] [France] [+33 626 52 50 68] Disclaimer: My own opinions are my own opinions and do not reflect on 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. ------------------------------

This looks, to me, like this secondary had been started in recovery mode rather than simply using oninit without any option ... and then left in this state. How exactly did you start it, and how did you restart it later when things went back to normal? ------------------------------ Andreas Legner ------------------------------