Re: Imported Restore with TSM and 2 engines with same DBSERVERNAME

Martin, Thanks for the reply. Can I avoid this query by object_name by instructing the restore to stop at the last known logical log in the ixbar file? onbar -p onbar -r -l -n <last logical log in ixbar> Thanks, Andrew ----- Original Message ----- From: "Martin Fuerderer" <MARTINFU@de.ibm.com> To: "Andrew Ford" <aford@networkip.net> Cc: <informix-list@iiug.org>; <informix-list-bounces@iiug.org> Sent: Friday, November 06, 2009 9:35 AM Subject: Re: Imported Restore with TSM and 2 engines with same DBSERVERNAME > Hi, > > yes, ON-Bar uses the CopyID fields (high and low) > to ask the SM for backup objects, normally. This is > why this CopyID info is diligently kept in the sysutils > database and the ixbar-file (for cold restore scenarios). > > But I say "normally", because there is an exception: > After ON-Bar has restored dbspaces and all > applicable and "known" (by ixbar-file/sysutils info) > log file backups, there can be situations where > ON-Bar asks the SM "whether there are more log > file backups to restore". This is to catch any log file > backups that were actually done but for some reason > are not listed in sysutils or ixbar-file. In this case > ON-Bar (obviously) does not know the CopyID of > such possibly existing objects. And the query to the > SM is done by "object name" ... > > You can utilize ON-Bar tracing (set BAR_DEBUG > sufficiently high, e.g. to 6, and BAR_DEBUG_LOG, > both parameters in the onconfig file) to see, which > fields ON-Bar uses to query the SM and whether > there can be any ambiguity in your specific > scenario ... > > Regards, Martin > -- > Martin Fuerderer > IBM Informix Development Munich, Germany > Information Management > > IBM Deutschland Research & Development GmbH > Chairman of the Supervisory Board: Martin Jetter > Board of Management: Erich Baier > Corporate Seat: Boeblingen, Germany > Reg.-Gericht: Amtsgericht Stuttgart, HRB 243294 > > informix-list-bounces@iiug.org wrote on 11/06/2009 04:14:06 PM: >> >> When performing a cold restore will onbar ask TSM for the unique storage > >> manager object by supplying the copyid_hi and copyid_lo fields from > columns >> 7 and 8 in the ixbar file? >> >> If so, that makes a lot of sense and would explain how onbar/TSM >> knows which >> /engine1/engine1/rootdbs/0 file is needed for the restore (because we > have >> two, the one I want to restore from production and the one from a backup > of >> the test system). >> >> Am I right on this? Also, can there still be problems backing up > objects >> from two engines with the same name to TSM? >> >> Thanks, >> >> Andrew >> >> ----- Original Message ----- >> From: "Andrew Ford" <aford@networkip.net> >> To: <informix-list@iiug.org> >> Sent: Friday, November 06, 2009 7:15 AM >> Subject: Imported Restore with TSM and 2 engines with same DBSERVERNAME >> >> >> > IDS 10.00.UC5 >> > >> > I have a production Informix engine with a DBSERVERNAME of engine1 > running >> > on server1 backing up to TSM and I have a test Informix engine with a >> > DBSERVERNAME of engine1 running on server2 backing up to TSM. Both >> > instances have SERVERNUM set to 1. >> > >> > Does anyone know if there will be any issues with performing an > imported >> > restore of the production engine1 to the test engine running on > server2? >> > >> > I'm wondering how onbar knows to ask TSM for the right restore files > if >> > the >> > rootdbs level 0 backup files for test and production both look like >> > /engine1/engine1/rootdbs/0 >> > >> > Can there be other issues with this configuration? Could running > onsmsync >> > on the test engine incorrectly expire logical log backups for the >> > production >> > engine in TSM? Would giving the test engine a different SERVERNUM fix > >> > this? >> > >> > Thanks in advance, >> > >> > Andrew >> > >> > _______________________________________________ >> > Informix-list mailing list >> > Informix-list@iiug.org >> > http://www.iiug.org/mailman/listinfo/informix-list >> >> _______________________________________________ >> Informix-list mailing list >> Informix-list@iiug.org >> http://www.iiug.org/mailman/listinfo/informix-list >