ontape restore and page writes

We are running an ontape -r restore for a system, and it seems to be taking 5x as long to restore as it took to make the ontape. We know the Disk I/O seems to be slower, but right now, we are trying to figure out how far the restore has gotten and how much longer it will take. What can you tell me on how to read the information in the onstat -D to be able to understand where the restore is at, and how much longer it has to go? The restore of the chunks so far: size free used page writes root_dbs 184,000 162,251 21,749 1,291 data1_dbs 20,000,000 400,986 19,599,014 11,369,918 what we have left: data2_dbs 10,000,000 98,200 9,901,800 root2_dbs 500,000 457,477 42,523 data3_dbs 10,000,000 259,420 9,740,580 data4_dbs 15,360,000 563,850 14,796,150 data5_dbs 7,168,000 367,317 6,800,683 data6_dbs 5,242,880 568,624 4,674,256 data7_dbs 5,242,880 802,557 4,440,323 Any help or guidance you can give me would be greatly appreciated. Thank you!

Hi, you can see the page writes in onstat -g iof There is also shown the writing speed in io/s. I don't know any other way how to see the progress in restore of ontape. Of course, writing always takes longer than reading ... Hope this helps. Marcus Haarmann ----- Ursprüngliche Mail ----- Von: "TRACY MICKEY" <tracy.mickey@sungardps.com> An: ids@iiug.org Gesendet: Dienstag, 9. Juli 2013 16:28:29 Betreff: ontape restore and page writes [30798] We are running an ontape -r restore for a system, and it seems to be taking 5x as long to restore as it took to make the ontape. We know the Disk I/O seems to be slower, but right now, we are trying to figure out how far the restore has gotten and how much longer it will take. What can you tell me on how to read the information in the onstat -D to be able to understand where the restore is at, and how much longer it has to go? The restore of the chunks so far: size free used page writes root_dbs 184,000 162,251 21,749 1,291 data1_dbs 20,000,000 400,986 19,599,014 11,369,918 what we have left: data2_dbs 10,000,000 98,200 9,901,800 root2_dbs 500,000 457,477 42,523 data3_dbs 10,000,000 259,420 9,740,580 data4_dbs 15,360,000 563,850 14,796,150 data5_dbs 7,168,000 367,317 6,800,683 data6_dbs 5,242,880 568,624 4,674,256 data7_dbs 5,242,880 802,557 4,440,323 Any help or guidance you can give me would be greatly appreciated. Thank you! ******************************************************************************* Forum Note: Use "Reply" to post a response in the discussion forum.

So, here's what you can expect to see: Look at the onstat -d to see how much of each chunk is used. Run onstat -D and look at the writes column for each chunk. The chunks will be written to in dbspace order (not chunk order), so all chunks for the root dbspace, then each of the others. Temp dbspaces are not archived and so are not written to by the restore except for the first few reserved pages in each temp dbspace chunk. Logical log chunks are only written to if an logical log that wasn't backed up is contained in it and only for the pages of that log. Usually that is only the 'current' log. When all chunks in a dbspace have been written to for roughly the number of used pages (from the onstat -d report) there will some additional writing of the physical log pages captured for that dbspace during the archive to undo any page modifications that were written to disk while the archive was copying out that dbspace then the restore will move on to the next dbspace. When they are all done, there is some brief overhead processing and the restore finishes. 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 Tue, Jul 9, 2013 at 10:28 AM, TRACY MICKEY <tracy.mickey@sungardps.com>wrote: > We are running an ontape -r restore for a system, and it seems to be > taking 5x > as long to restore as it took to make the ontape. > We know the Disk I/O seems to be slower, but right now, we are trying to > figure out how far the restore has gotten and how much longer it will take. > > What can you tell me on how to read the information in the onstat -D to be > able to understand where the restore is at, and how much longer it has to > go? > > The restore of the chunks so far: > > size free used page writes > root_dbs 184,000 162,251 21,749 1,291 > data1_dbs 20,000,000 400,986 19,599,014 11,369,918 > > what we have left: > data2_dbs 10,000,000 98,200 9,901,800 > root2_dbs 500,000 457,477 42,523 > data3_dbs 10,000,000 259,420 9,740,580 > data4_dbs 15,360,000 563,850 14,796,150 > data5_dbs 7,168,000 367,317 6,800,683 > data6_dbs 5,242,880 568,624 4,674,256 > data7_dbs 5,242,880 802,557 4,440,323 > > Any help or guidance you can give me would be greatly appreciated. > Thank you! > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --001a1133e4148d54ac04e11530f9

Tracy onstat -g arc will show where you are with a restore, and also approx howfar you have to go. Generally I've found a restore - to the same machine - takes about 10% longer, to a different machine will depend entirely on the io sub-systems, disk speed/layout etc. Keith On 9 July 2013 15:28, TRACY MICKEY <tracy.mickey@sungardps.com> wrote: > We are running an ontape -r restore for a system, and it seems to be > taking 5x > as long to restore as it took to make the ontape. > We know the Disk I/O seems to be slower, but right now, we are trying to > figure out how far the restore has gotten and how much longer it will take. > > What can you tell me on how to read the information in the onstat -D to be > able to understand where the restore is at, and how much longer it has to > go? > > The restore of the chunks so far: > > size free used page writes > root_dbs 184,000 162,251 21,749 1,291 > data1_dbs 20,000,000 400,986 19,599,014 11,369,918 > > what we have left: > data2_dbs 10,000,000 98,200 9,901,800 > root2_dbs 500,000 457,477 42,523 > data3_dbs 10,000,000 259,420 9,740,580 > data4_dbs 15,360,000 563,850 14,796,150 > data5_dbs 7,168,000 367,317 6,800,683 > data6_dbs 5,242,880 568,624 4,674,256 > data7_dbs 5,242,880 802,557 4,440,323 > > Any help or guidance you can give me would be greatly appreciated. > Thank you! > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --bcaec5015ffd961d7704e11537b0

If you look at the dbspaces flags columns in an onstat -d they will tell you which recovery state each dbspaces is in. The two most common flags for recovery are P is physically recovered, waiting for logical recovery L Being logically recovered At the end of recovery the physical and logical logs need to be disk cleared. If you have lots of log space then this can take some time. In newer versions we create a separate thread for each chunk contain logs and clear them in parallel, if all the logs are in the same chunk then this will be done serially. Lastly if you are restoring to filesystem files which have new file for chunks, these files need to be fully expanded which also takes time, this issue only for file system chunks and not for raw devices. John F. Miller III STSM, Lead Architect miller3@us.ibm.com 503-747-1366 IBM Informix Dynamic Server (IDS) ids-bounces@iiug.org wrote on 07/09/2013 07:28:29 AM: > From: "TRACY MICKEY" <tracy.mickey@sungardps.com> > To: ids@iiug.org, > Date: 07/09/2013 07:43 AM > Subject: ontape restore and page writes [30798] > Sent by: ids-bounces@iiug.org > > We are running an ontape -r restore for a system, and it seems to betaking 5x > as long to restore as it took to make the ontape. > We know the Disk I/O seems to be slower, but right now, we are trying to > figure out how far the restore has gotten and how much longer it will take. > > What can you tell me on how to read the information in the onstat -D to be > able to understand where the restore is at, and how much longer it has to go? > > The restore of the chunks so far: > > size free used page writes > root_dbs 184,000 162,251 21,749 1,291 > data1_dbs 20,000,000 400,986 19,599,014 11,369,918 > > what we have left: > data2_dbs 10,000,000 98,200 9,901,800 > root2_dbs 500,000 457,477 42,523 > data3_dbs 10,000,000 259,420 9,740,580 > data4_dbs 15,360,000 563,850 14,796,150 > data5_dbs 7,168,000 367,317 6,800,683 > data6_dbs 5,242,880 568,624 4,674,256 > data7_dbs 5,242,880 802,557 4,440,323 > > Any help or guidance you can give me would be greatly appreciated. > Thank you! > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. >

Tracy: Forgot to add, on the subject of taking 5X as long to restore as to archive, I suspect that you are using RAID5/6 or other checksum/crc based disk arrays. These are notoriously slow to write to when massive writes are needed! That's on top of not being safe for your data - and I can back that up! You should ONLY use RAID1 or RAID10 for database chunks! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! 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 Tue, Jul 9, 2013 at 11:07 AM, John Miller iii <miller3@us.ibm.com> wrote: > If you look at the dbspaces flags columns in an onstat -d they will tell > you which recovery state each dbspaces is in. > The two most common flags for recovery are > P is physically recovered, waiting for logical recovery > L Being logically recovered > > At the end of recovery the physical and logical logs need to be disk > cleared. If you have lots of log space then > this can take some time. In newer versions we create a separate thread > for each chunk contain logs and clear > them in parallel, if all the logs are in the same chunk then this will be > done serially. > > Lastly if you are restoring to filesystem files which have new file for > chunks, these files need to be fully expanded which also takes > time, this issue only for file system chunks and not for raw devices. > > John F. Miller III > STSM, Lead Architect > miller3@us.ibm.com > 503-747-1366 > IBM Informix Dynamic Server (IDS) > > ids-bounces@iiug.org wrote on 07/09/2013 07:28:29 AM: > > > From: "TRACY MICKEY" <tracy.mickey@sungardps.com> > > To: ids@iiug.org, > > Date: 07/09/2013 07:43 AM > > Subject: ontape restore and page writes [30798] > > Sent by: ids-bounces@iiug.org > > > > We are running an ontape -r restore for a system, and it seems to > betaking 5x > > as long to restore as it took to make the ontape. > > We know the Disk I/O seems to be slower, but right now, we are trying to > > figure out how far the restore has gotten and how much longer it will > take. > > > > What can you tell me on how to read the information in the onstat -D to > be > > able to understand where the restore is at, and how much longer it has to > go? > > > > The restore of the chunks so far: > > > > size free used page writes > > root_dbs 184,000 162,251 21,749 1,291 > > data1_dbs 20,000,000 400,986 19,599,014 11,369,918 > > > > what we have left: > > data2_dbs 10,000,000 98,200 9,901,800 > > root2_dbs 500,000 457,477 42,523 > > data3_dbs 10,000,000 259,420 9,740,580 > > data4_dbs 15,360,000 563,850 14,796,150 > > data5_dbs 7,168,000 367,317 6,800,683 > > data6_dbs 5,242,880 568,624 4,674,256 > > data7_dbs 5,242,880 802,557 4,440,323 > > > > Any help or guidance you can give me would be greatly appreciated. > > Thank you! > > > > > > > > > ******************************************************************************* > > > Forum Note: Use "Reply" to post a response in the discussion forum. > > > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --001a1133e414c8531904e1159778

Art: I will make sure I pass along the NO RAID 5... Well Said! John M. - it's nice to see you are still associated with IBM... last I saw you was at an Informix Conference, and you had a new baby at home, and he kept you awake all night... Probably no longer a baby.. All - We are using the combination of all the commands you have sent along. Thank you very much! We are moving from one physical location to another, and we are testing the process - we now know we have to do something with the disk layout, since it is so much slower... At this point, we're 50% into the restore (I think) so we just need to wait for it to finish. Thank you all for your guidance. We did create a PMR, and we're probably going to backup and restore using dd or something like that - hopefully, that will be faster.

Another thought: Is the new target a VM? IO is also VERY SLOW on VMs. 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 Tue, Jul 9, 2013 at 12:40 PM, TRACY MICKEY <tracy.mickey@sungardps.com>wrote: > Art: I will make sure I pass along the NO RAID 5... Well Said! > > John M. - it's nice to see you are still associated with IBM... last I saw > you > was at an Informix Conference, and you had a new baby at home, and he kept > you > awake all night... Probably no longer a baby.. > > All - We are using the combination of all the commands you have sent along. > Thank you very much! > > We are moving from one physical location to another, and we are testing the > process - we now know we have to do something with the disk layout, since > it > is so much slower... At this point, we're 50% into the restore (I think) > so we > just need to wait for it to finish. > > Thank you all for your guidance. > > We did create a PMR, and we're probably going to backup and restore using > dd > or something like that - hopefully, that will be faster. > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --001a11c356e27cc5bf04e116e181

Tracey You do not mention your O/S, hardware or IDS version. I would be wary of dd as the the engine on the target server might have issues with starting up. I would suggest that if you are suffering a performance degradation just running a restore then you will encounter a similar issue when running the database. have you bench-marked this server against a live work-load to see if it is capable of running the required tasks ? Keith On 9 July 2013 17:40, TRACY MICKEY <tracy.mickey@sungardps.com> wrote: > Art: I will make sure I pass along the NO RAID 5... Well Said! > > John M. - it's nice to see you are still associated with IBM... last I saw > you > was at an Informix Conference, and you had a new baby at home, and he kept > you > awake all night... Probably no longer a baby.. > > All - We are using the combination of all the commands you have sent along. > Thank you very much! > > We are moving from one physical location to another, and we are testing the > process - we now know we have to do something with the disk layout, since > it > is so much slower... At this point, we're 50% into the restore (I think) > so we > just need to wait for it to finish. > > Thank you all for your guidance. > > We did create a PMR, and we're probably going to backup and restore using > dd > or something like that - hopefully, that will be faster. > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --bcaec50fdfb1e457fe04e116fc28