Re: interrupted external restore and data availabi

Hi, (SOLVED) we finally solved this in a different way, actually quite fast. We didn't us archecker but onbar, yet restoring only the critical dbspaces + the dbspace containing the requested database:table. The point was to launch the external restore omitting the symbolic links to the dbspaces we didn't need (we improvised an instance on the same server just to perform the restore), so that onbar doesn't find them. Of course we got some errors/warnings, but you just say 'yes' and the restore goes on putting those dbspaces with missing symlinks off-line after the restore. One very important thing here is that at the end of the restore, when the instance is still in 'quiescent' mode, and after issuing the onmode -m, the system seems to freeze for quite a while, but don't worry, that's normal: it's really cleaning the physical log (as is says in online.log) and this step can take about 10 minutes to finish: 12:02:56 No logical log restore will be performed. 12:02:56 Preparing Physical Log for Fast Recovery ... 12:02:56 Clearing the physical and logical logs has started 12:13:53 Cleared 514 MB of the physical and logical logs in 657 seconds 12:13:53 Physical Recovery Started at Page (4:35837). 12:13:53 The chunk path (chunk number 2 of temp dbspace number 2) is renamed to new chunk path (/opt/informix/db1_restore/temp_01:0). 12:14:40 The chunk path (chunk number 43 of temp dbspace number 2) is renamed to new chunk path (/opt/informix/db1_restore/temp_01_02:0). 12:15:10 The chunk path (chunk number 3 of temp dbspace number 3) is renamed to new chunk path (/opt/informix/db1_restore/temp_02:0). 12:15:41 The chunk path (chunk number 44 of temp dbspace number 3) is renamed to new chunk path (/opt/informix/db1_restore/temp_02_02:0). 12:16:11 Physical Recovery Complete: 0 Pages Examined, 0 Pages Restored. 12:16:11 Logical Recovery Started. 12:16:11 10 recovery worker threads will be started. 12:16:12 Checkpoint Completed: duration was 138 seconds. 12:16:12 Checkpoint loguniq 4105, logpos 0x1b5018, timestamp: 0x621ff34b 12:16:12 Maximum server connections 0 12:16:14 Logical Recovery has reached the transaction cleanup phase. 12:16:14 Logical Recovery Complete. 0 Committed, 0 Rolled Back, 0 Open, 0 Bad Locks 12:16:15 Bringing system to On-Line Mode with no Logical Restore. 12:16:16 On-Line Mode Than it still takes a while restoring the temporal dbspaces and yet a log checkpoint, and finally the instance is up and running and you can access the database(s) in the restored dbspace(s). Of course this method is only suitable for accessing the data temporarily; you cannot drop the dbspaces that are down, so it isn't a suited method for having a permanent partial restore, e.g. to split an instance. Just to point it out again and summarize a little: our main problem here was that: · we have a big instance with several databases, of whom one is really big (about 400GB), which we actually don't need to restore · we only need a table-level restore, but can't use archecker since we're still working with 9.40.FC6 · we have to do an external restore (to not interfere whith the production system), but we cannot afford the very long time of a whole system external restore (it would take us a minimum of 40 - 50 hours because of this very big database we don't need) Again, thanks for your suggestions. Gerardo