RE: Ontape restore to another server

Thanks Art, That simplifies some of the stuff we've posted on this thread, and I haven't had time for more digging. Your way sounds the simplest. I am not very experienced with archecker (last time I played with it was years ago).... I have a couple questions for my own clarification.... IDS 10 archecker would do that for v9.4? .......if using v10 archecker to extract data from v9.4 ontape backup into an IDS10 instance.... Would the v10 instance need to take into consideration chunk paths and other things discussed when thinking of doing the ontape restore to second instance? Or can the IDS10 instance be set up pretty much any old way not in consideration of the v9.4 instance or ontape data...... and still receive the v10 archecker data extract from v9.4 ontape backup? Thanks for your thoughts, Norma Jean Sebastian ERP Support Administration IT - Enterprise Technical Services -----Original Message----- From: informix-list-bounces@iiug.org [mailto:informix-list-bounces@iiug.org] On Behalf Of Art S. Kagel Sent: Friday, December 29, 2006 10:41 AM To: informix-list@iiug.org Subject: Re: Ontape restore to another server Gary Quiring wrote: > I have a need to restore our production DB (9.4) to a junk box to > salvage a table that recently lost some data. I am not very familiar > with the steps required. The production server is running Solaris 9 > with raw devices. I was hoping to restore to a Red Hat box using > cooked files. Is that possible? > > I also need to remotely restore the data from the tape drive as my RH > box has no tape device. I assume just changing the TAPEDEV to > server:/dev/rmt/0 will work. Will issuing the ontape -r from the red > hat server restore the data to the local drives? I obviously don't > want to restore the data over the production server. Gary, go with the IDS 10 version of archecker to extract the data from the tape and recreate the table in a small IDS 10 instance on the Sun box. Then you could extract and reload to the production server, or copy directly from one to the other using dbaccess or my dbcopy utility as long as there are no special columns (and you could upgrade the dbcopy source to support your data types as well). Art S. Kagel _______________________________________________ Informix-list mailing list Informix-list@iiug.org http://www.iiug.org/mailman/listinfo/informix-list ============================================================ The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reproduction, dissemination or distribution of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Tellabs ============================================================

Sebastian, Norma J. wrote: > Thanks Art, Norma: > That simplifies some of the stuff we've posted on this thread, and I > haven't had time for more digging. Your way sounds the simplest. > > I am not very experienced with archecker (last time I played with it was > years ago).... > I have a couple questions for my own clarification.... OK. > IDS 10 archecker would do that for v9.4? Yes. The actual format of ontape archives hasn't changed in a very long time. Ontape just refuses to restore when it reads the header page and finds that the version that was archived was different because of possible IDS changes. Archecker is more forgiving and IB that it doesn't even check the tape version. > .......if using v10 archecker to extract data from v9.4 ontape backup > into an IDS10 instance.... > Would the v10 instance need to take into consideration chunk paths and > other things discussed when thinking of doing the ontape restore to > second instance? Or can the IDS10 instance be set up pretty much any > old way not in consideration of the v9.4 instance or ontape data...... > and still receive the v10 archecker data extract from v9.4 ontape > backup? The nice thing about the way table restore was implemented in archecker is that it extracts the raw data from the tape then uses SQL to insert the rows into an existing table and/or creates a table for the restore. They also implemented SQL filtering and projection clauses for the data on tape so you can restore selected rows and even subsets of the table's columns. Art S. Kagel > Thanks for your thoughts, > > Norma Jean Sebastian > ERP Support Administration > IT - Enterprise Technical Services > > -----Original Message----- > From: informix-list-bounces@iiug.org > [mailto:informix-list-bounces@iiug.org] On Behalf Of Art S. Kagel > Sent: Friday, December 29, 2006 10:41 AM > To: informix-list@iiug.org > Subject: Re: Ontape restore to another server > > Gary Quiring wrote: > >>I have a need to restore our production DB (9.4) to a junk box to >>salvage a table that recently lost some data. I am not very familiar >>with the steps required. The production server is running Solaris 9 >>with raw devices. I was hoping to restore to a Red Hat box using >>cooked files. Is that possible? >> >>I also need to remotely restore the data from the tape drive as my RH >>box has no tape device. I assume just changing the TAPEDEV to >>server:/dev/rmt/0 will work. Will issuing the ontape -r from the red >>hat server restore the data to the local drives? I obviously don't >>want to restore the data over the production server. > > > Gary, go with the IDS 10 version of archecker to extract the data from > the > tape and recreate the table in a small IDS 10 instance on the Sun box. > Then > you could extract and reload to the production server, or copy directly > from > one to the other using dbaccess or my dbcopy utility as long as there > are no > special columns (and you could upgrade the dbcopy source to support your > > data types as well). > > Art S. Kagel > _______________________________________________ > Informix-list mailing list > Informix-list@iiug.org > http://www.iiug.org/mailman/listinfo/informix-list > ============================================================ > The information contained in this message may be privileged > and confidential and protected from disclosure. If the reader > of this message is not the intended recipient, or an employee > or agent responsible for delivering this message to the > intended recipient, you are hereby notified that any reproduction, > dissemination or distribution of this communication is strictly > prohibited. If you have received this communication in error, > please notify us immediately by replying to the message and > deleting it from your computer. Thank you. Tellabs > ============================================================

Sebastian, Norma J. wrote: > Thanks Art, Norma: > That simplifies some of the stuff we've posted on this thread, and I > haven't had time for more digging. Your way sounds the simplest. > > I am not very experienced with archecker (last time I played with it was > years ago).... > I have a couple questions for my own clarification.... OK. > IDS 10 archecker would do that for v9.4? Yes. The actual format of ontape archives hasn't changed in a very long time. Ontape just refuses to restore when it reads the header page and finds that the version that was archived was different because of possible IDS changes. Archecker is more forgiving and IB that it doesn't even check the tape version. > .......if using v10 archecker to extract data from v9.4 ontape backup > into an IDS10 instance.... > Would the v10 instance need to take into consideration chunk paths and > other things discussed when thinking of doing the ontape restore to > second instance? Or can the IDS10 instance be set up pretty much any > old way not in consideration of the v9.4 instance or ontape data...... > and still receive the v10 archecker data extract from v9.4 ontape > backup? The nice thing about the way table restore was implemented in archecker is that it extracts the raw data from the tape then uses SQL to insert the rows into an existing table and/or creates a table for the restore. They also implemented SQL filtering and projection clauses for the data on tape so you can restore selected rows and even subsets of the table's columns. Art S. Kagel > Thanks for your thoughts, > > Norma Jean Sebastian > ERP Support Administration > IT - Enterprise Technical Services > > -----Original Message----- > From: informix-list-bounces@iiug.org > [mailto:informix-list-bounces@iiug.org] On Behalf Of Art S. Kagel > Sent: Friday, December 29, 2006 10:41 AM > To: informix-list@iiug.org > Subject: Re: Ontape restore to another server > > Gary Quiring wrote: > >>I have a need to restore our production DB (9.4) to a junk box to >>salvage a table that recently lost some data. I am not very familiar >>with the steps required. The production server is running Solaris 9 >>with raw devices. I was hoping to restore to a Red Hat box using >>cooked files. Is that possible? >> >>I also need to remotely restore the data from the tape drive as my RH >>box has no tape device. I assume just changing the TAPEDEV to >>server:/dev/rmt/0 will work. Will issuing the ontape -r from the red >>hat server restore the data to the local drives? I obviously don't >>want to restore the data over the production server. > > > Gary, go with the IDS 10 version of archecker to extract the data from > the > tape and recreate the table in a small IDS 10 instance on the Sun box. > Then > you could extract and reload to the production server, or copy directly > from > one to the other using dbaccess or my dbcopy utility as long as there > are no > special columns (and you could upgrade the dbcopy source to support your > > data types as well). > > Art S. Kagel > _______________________________________________ > Informix-list mailing list > Informix-list@iiug.org > http://www.iiug.org/mailman/listinfo/informix-list > ============================================================ > The information contained in this message may be privileged > and confidential and protected from disclosure. If the reader > of this message is not the intended recipient, or an employee > or agent responsible for delivering this message to the > intended recipient, you are hereby notified that any reproduction, > dissemination or distribution of this communication is strictly > prohibited. If you have received this communication in error, > please notify us immediately by replying to the message and > deleting it from your computer. Thank you. Tellabs > ============================================================