ontape -r from cooked to raw dbspaces?

Is there an option to ontape that will allow the restoration of an archive of cooked dbspaces to raw dbspaces by the same name (not chunk/file names)? When the spaces are created onspaces doesn't know whether a file is raw or cooked. Why does ontape care? Another anomaly with ontape: if you create a file with /dev/null attributes but name it something else, ontape does not treat it like /dev/null. That is, it does not merely reset a pointer, but it runs the archive as if it were to a file, taking as long as it would if it were doing a real archive. IDS 7.31.UC5 on AIX 4.3.2.0

"B. Dana" wrote: > > Is there an option to ontape that will allow the restoration of an > archive of > cooked dbspaces to raw dbspaces by the same name (not chunk/file names)? All Informix archive/restore utilities will do this without complaining. You should also know that if you are doing this to move your data from COOKED to RAW devices, as long as you want to use the same physical device, just shutdown and relink the symlinks you of course used to create your chunks from the block device to the cooked device of the same name. Since they point to IDENTICAL disk space when you restart the engine it will just use the chunks with no problem. Been doing that to correct typos for years. So if you have a chunk path: /usr/informix/ifmx7.31/disks/chunk_1 linked to /dev/dsk/c1t0s4d5 (or whatever!) just delete the link and recreate it to point to /dev/rdsk/c1t0s4d5 and all is well. > When the spaces are created onspaces doesn't know whether a file is raw > or > cooked. Why does ontape care? Not only doesn't ontape care the engine doesn't when the chunk is created. The engine determines the type of the file when it opens it on startup. > Another anomaly with ontape: if you create a file with /dev/null > attributes but > name it something else, ontape does not treat it like /dev/null. That > is, it does > not merely reset a pointer, but it runs the archive as if it were to a > file, taking > as long as it would if it were doing a real archive. Yup. The special behavior is restricted to the specific file /dev/null on UNIX or NUL on NT. Art S. Kagel

"Art S. Kagel" wrote: > "B. Dana" wrote: > > > > Is there an option to ontape that will allow the restoration of an > > archive of > > cooked dbspaces to raw dbspaces by the same name (not chunk/file names)? > > All Informix archive/restore utilities will do this without > complaining. You should also know that if you are doing this to move > your data from COOKED to RAW devices, as long as you want to use the > same physical device, just shutdown and relink the symlinks you of > course used to create your chunks from the block device to the cooked > device of the same name. Since they point to IDENTICAL disk space > when you restart the engine it will just use the chunks with no > problem. Been doing that to correct typos for years. So if you have > a chunk path: /usr/informix/ifmx7.31/disks/chunk_1 linked to > /dev/dsk/c1t0s4d5 (or whatever!) just delete the link and recreate > it to point to /dev/rdsk/c1t0s4d5 and all is well. > > > When the spaces are created onspaces doesn't know whether a file is raw > > or > > cooked. Why does ontape care? > > Not only doesn't ontape care the engine doesn't when the chunk is > created. The engine determines the type of the file when it opens it > on startup. It seems that ontape should restore by dbspace name, not chunk file name. That would make file consolidation convenient. > > > > Another anomaly with ontape: if you create a file with /dev/null > > attributes but > > name it something else, ontape does not treat it like /dev/null. That > > is, it does > > not merely reset a pointer, but it runs the archive as if it were to a > > file, taking > > as long as it would if it were doing a real archive. > > Yup. The special behavior is restricted to the specific file > /dev/null on UNIX or NUL on NT. > I did a strings on the ontape command and found "/dev/null" hard coded. It might be better to determine what is done with the archive by using the file type rather than the file name; or at least offer an option on the command line. > > Art S. Kagel

"B. Dana" wrote: > > "Art S. Kagel" wrote: > > > "B. Dana" wrote: > > > > > > Is there an option to ontape that will allow the restoration of an > > > archive of > > > cooked dbspaces to raw dbspaces by the same name (not chunk/file names)? > > > > All Informix archive/restore utilities will do this without > > complaining. You should also know that if you are doing this to move > > your data from COOKED to RAW devices, as long as you want to use the > > same physical device, just shutdown and relink the symlinks you of > > course used to create your chunks from the block device to the cooked > > device of the same name. Since they point to IDENTICAL disk space > > when you restart the engine it will just use the chunks with no > > problem. Been doing that to correct typos for years. So if you have > > a chunk path: /usr/informix/ifmx7.31/disks/chunk_1 linked to > > /dev/dsk/c1t0s4d5 (or whatever!) just delete the link and recreate > > it to point to /dev/rdsk/c1t0s4d5 and all is well. > > > > > When the spaces are created onspaces doesn't know whether a file is raw > > > or > > > cooked. Why does ontape care? > > > > Not only doesn't ontape care the engine doesn't when the chunk is > > created. The engine determines the type of the file when it opens it > > on startup. > > It seems that ontape should restore by dbspace name, not chunk > file name. That would make file consolidation convenient. Think of the Informix backups as a physical backup. All of the page numbers which include chunk number are fixed on each page. In addition ontape/onarchive/onbar first restore the reserved pages which contain the dbspace and chunk tables as they existed when the archive was begun. Informix has several logical backup tools, dbexport/dbimport, onunload/onload, dbaccess(UNLOAD)/dbload to name the obvious ones. The physical archive utilities do the job they were intended for, to save a physical image of your server as of a point in time so you can restore it to sanity if the worst should happen. All the other things that we DBAs use them for, like migrating and copying instances from one host to another and for moving our chunks from one disk structure to another are just gravy! I'm not the first to back the folk in Menlo Park without question, but if you use a hammer to drive machine screws you cannot complain when the nuts will not screw on because the threads have been trashed! > > > > > > > Another anomaly with ontape: if you create a file with /dev/null > > > attributes but > > > name it something else, ontape does not treat it like /dev/null. That > > > is, it does > > > not merely reset a pointer, but it runs the archive as if it were to a > > > file, taking > > > as long as it would if it were doing a real archive. > > > > Yup. The special behavior is restricted to the specific file > > /dev/null on UNIX or NUL on NT. > > > > I did a strings on the ontape command and found "/dev/null" hard coded. > It might be better to determine what is done with the archive by using > the file type rather than the file name; or at least offer an option on the > command line. [Micro-Flame on] Well the filetype will only tell the engine that /dev/my_informix_null_archive_device is a device special file, just like a tape driver device file or a RAW disk device file both of which are valid backup devices for real archives. Informix would have to track down the major/minor device numbers and look them up in a table for each platform to determine that your file has the same driver address as /dev/null on that system and that does not allow for links yet! Come on just use /dev/null, is that so hard to type and it's purpose is obvious and well known to anyone who may come after you while the purpose of /dev/my_informix_null_archive_device is not, even if I made the name yet longer. [Micro-Flame off] Art S. Kagel That's two flames this year.

"Art S. Kagel" wrote: [other crap removed] > > > > > > > > > > > Another anomaly with ontape: if you create a file with /dev/null > > > > attributes but > > > > name it something else, ontape does not treat it like /dev/null. That > > > > is, it does > > > > not merely reset a pointer, but it runs the archive as if it were to a > > > > file, taking > > > > as long as it would if it were doing a real archive. > > > > > > Yup. The special behavior is restricted to the specific file > > > /dev/null on UNIX or NUL on NT. > > > > > > > I did a strings on the ontape command and found "/dev/null" hard coded. > > It might be better to determine what is done with the archive by using > > the file type rather than the file name; or at least offer an option on the > > command line. > > [Micro-Flame on] > Well the filetype will only tell the engine that > /dev/my_informix_null_archive_device is a device special file, just > like a tape driver device file or a RAW disk device file both of > which are valid backup devices for real archives. Informix would > have to track down the major/minor device numbers and look them up > in a table for each platform to determine that your file has the > same driver address as /dev/null on that system and that does not > allow for links yet! Come on just use /dev/null, is that so hard > to type and it's purpose is obvious and well known to anyone who may > come after you while the purpose of > /dev/my_informix_null_archive_device is not, even if I made the name > yet longer. > [Micro-Flame off] > > Art S. Kagel > > That's two flames this year. Well #*@% me! I guess I wasn't aware that it is unnecessary to bounce the database to change the TAPEDEV parameter.