optimize for restore

Hi, We have a standby database here for backup purpose. Taking a backup from production db using onunload, and restoring on standby system with onload.(using IDS 7.31 on HP/UX) how can i make the restore operation go faster? i have read something about modifying onconfig parameters such as increasing BUFFERS, CKPTINTVL values and decrease LRUS. Actually tried some, but no gain. i would like to hear your suggestions about this topic. Thanks Abdullah AKOGLU Bu e-posta mesaji kisiye ozel olup, gizli bilgiler iceriyor olabilir. Eger Bu e-posta mesaji size yanlislikla ulasmissa, icerigini hic bir sekilde kullanmayiniz ve ekli dosyalari acmayiniz. Bu durumda lutfen e-posta mesajini kullaniciya geri gonderiniz ve tum kopyalarini mesaj kutunuzdan siliniz. Bu e-posta mesaji, hicbir sekilde, herhangi bir amac icin cogaltilamaz, yayinlanamaz, para karsiligi satilamaz . Bu e-posta mesaji virus koruma sistemleri ile kontrol ediliyor olsa bile virus icermedigini garanti etmez ve meydana gelebilecek zararlardan dogacak hicbir sorumlulugu kabul etmez.Bu e-posta mesajindaki gorusler Vadeli Islem ve Opsiyon Borsasi A.S.'nin goruslerini yansitmayabilir ve kurumu baglayici degildir.

Abdullah Akoglu wrote: > Hi, Part of the problem is that you are trying to use the wrong tool to get the job done. Why not just set up High Availability Data Replication (HDR) between the two machines and have a live server that's always up to date and ready to take over instantly if the primary server or its host go down? If that's not an option you like, then how about using ontape or onbar to take a server level archive on the primary and restore that to the backup? You can also save logical logs constantly either using the ontape/onbar continuous log archive or using the ALARMPROGRAM to archive each log as it is completed using either ontape or onbar. Then you can leave the restore waiting for logical logs and restore them also either immediately after they have been archived or at failover time. Art S. Kagel > We have a standby database here for backup purpose. Taking a backup from > production db using onunload, and restoring on standby system with > onload.(using IDS 7.31 on HP/UX) how can i make the restore operation go > faster? i have read something about modifying onconfig parameters such > as increasing BUFFERS, CKPTINTVL values and decrease LRUS. Actually > tried some, but no gain. > > i would like to hear your suggestions about this topic. > > Thanks > > Abdullah AKOGLU

Abdullah Akoglu wrote: > Hi, Part of the problem is that you are trying to use the wrong tool to get the job done. Why not just set up High Availability Data Replication (HDR) between the two machines and have a live server that's always up to date and ready to take over instantly if the primary server or its host go down? If that's not an option you like, then how about using ontape or onbar to take a server level archive on the primary and restore that to the backup? You can also save logical logs constantly either using the ontape/onbar continuous log archive or using the ALARMPROGRAM to archive each log as it is completed using either ontape or onbar. Then you can leave the restore waiting for logical logs and restore them also either immediately after they have been archived or at failover time. Art S. Kagel > We have a standby database here for backup purpose. Taking a backup from > production db using onunload, and restoring on standby system with > onload.(using IDS 7.31 on HP/UX) how can i make the restore operation go > faster? i have read something about modifying onconfig parameters such > as increasing BUFFERS, CKPTINTVL values and decrease LRUS. Actually > tried some, but no gain. > > i would like to hear your suggestions about this topic. > > Thanks > > Abdullah AKOGLU

Hi, HDR is not an option for us because of our application, but i will try the ontape and share the results with you. thanks -----Original Message----- From: Art S. Kagel [mailto:kagel@BLOOMBERG.NET] Sent: Wednesday, July 26, 2006 4:45 PM To: Abdullah Akoglu Cc: informix-list@iiug.org Subject: Re: optimize for restore Abdullah Akoglu wrote: > Hi, Part of the problem is that you are trying to use the wrong tool to get the job done. Why not just set up High Availability Data Replication (HDR) between the two machines and have a live server that's always up to date and ready to take over instantly if the primary server or its host go down? If that's not an option you like, then how about using ontape or onbar to take a server level archive on the primary and restore that to the backup? You can also save logical logs constantly either using the ontape/onbar continuous log archive or using the ALARMPROGRAM to archive each log as it is completed using either ontape or onbar. Then you can leave the restore waiting for logical logs and restore them also either immediately after they have been archived or at failover time. Art S. Kagel > We have a standby database here for backup purpose. Taking a backup from > production db using onunload, and restoring on standby system with > onload.(using IDS 7.31 on HP/UX) how can i make the restore operation go > faster? i have read something about modifying onconfig parameters such > as increasing BUFFERS, CKPTINTVL values and decrease LRUS. Actually > tried some, but no gain. > > i would like to hear your suggestions about this topic. > > Thanks > > Abdullah AKOGLU Bu e-posta mesaji kisiye ozel olup, gizli bilgiler iceriyor olabilir. Eger Bu e-posta mesaji size yanlislikla ulasmissa, icerigini hic bir sekilde kullanmayiniz ve ekli dosyalari acmayiniz. Bu durumda lutfen e-posta mesajini kullaniciya geri gonderiniz ve tum kopyalarini mesaj kutunuzdan siliniz. Bu e-posta mesaji, hicbir sekilde, herhangi bir amac icin cogaltilamaz, yayinlanamaz, para karsiligi satilamaz . Bu e-posta mesaji virus koruma sistemleri ile kontrol ediliyor olsa bile virus icermedigini garanti etmez ve meydana gelebilecek zararlardan dogacak hicbir sorumlulugu kabul etmez.Bu e-posta mesajindaki gorusler Vadeli Islem ve Opsiyon Borsasi A.S.'nin goruslerini yansitmayabilir ve kurumu baglayici degildir.

Abdullah Akoglu wrote: > Hi, > HDR is not an option for us because of our application, > but i will try the ontape and share the results with you. > thanks Why, is this because of your logging mode? Ben.