Yet another DBEXPORT question.

There must be a better way to solve my problem than the way I have solved it, so I am looking for some advice/guidance. Pardon me if this sounds like a lot of whining! I have Informix 7.3.X running on two AIX 4.3.3 boxes. I want to do a dbexport from the "localbox" to the "farbox," and I would like to do it without having the 5gig or so of .unl and .sql files appear on the local box. I see no reason to create 5 gigs "local" and move those same 5 gigs "far." What I wound up doing was creating/exporting an NFS file system on the farbox, making it visible as a local directory on the localbox, doing a cd to it, and running dbexport -c -q mydatabase Works fine, except I do not want the NFS connectivity all the time, so I have to go through the issues exporting, making the connections at both ends, whine, whine, whine. What I *want* to do is something like dbexport -c -q mydatabase | tar -cf - | rsh farbox "cd /home/myhome/exports/ ; tar -xf -" which, of course, doesn't work, since tar doesn't use both STDIN and STDOUT simultaneously, and perhaps can't parse the data stream either. Clearly, I don't understand how things actually work. dbexport seems bound and determined to create the mydatabase.exp directory whether I want it or not. Someone suggested that I try dbexport -c -q mydatabase | xargs tar -cf - | rsh farbox "cd /home/myhome/exports/ ; tar -xf -" which produces nothing either, since dbexport isn't producing a list of filenames to be tar'ed, but (so I naively presume) a filename and its data. Please, someone tell me that this is possible, and tell me how I actually do this. I will even accept a little abuse, if it is intelligent abuse. -- Cheers-- Charles, Machine Whisperer (but, alas, not today)

You can get dbexport to write to a tape drive. Another option is to use a utility that will copy the tables directly from one live database to the other. You will need my utils2_ak package to get by dbcopy utility and my package utils4_ak to get the awk scripts (optionally you can use my dbschema replacement myschema which comes in utils2_ak instead of dbschema). Then: Once the database has been created on the target machine... dbschema -d <database> <database>.sql awk -f mk_dbcopy.awk database.sql >copy_database.kshksh copy_database.ksh target_server Art S. Kagel charles.johnson@news.accessllc.net wrote: > > There must be a better way to solve my problem than the way I have solved > it, so I am looking for some advice/guidance. Pardon me if this sounds like > a lot of whining! > > I have Informix 7.3.X running on two AIX 4.3.3 boxes. I want to do a > dbexport from the "localbox" to the "farbox," and I would like to do it > without having the 5gig or so of .unl and .sql files appear on the local > box. I see no reason to create 5 gigs "local" and move those same 5 gigs > "far." What I wound up doing was creating/exporting an NFS file system on > the farbox, making it visible as a local directory on the localbox, doing a > cd to it, and running > > dbexport -c -q mydatabase> > Works fine, except I do not want the NFS connectivity all the time, so I > have to go through the issues exporting, making the connections at both > ends, whine, whine, whine. > > What I *want* to do is something like > > dbexport -c -q mydatabase | tar -cf - | rsh farbox "cd > /home/myhome/exports/ ; tar -xf -"> > which, of course, doesn't work, since tar doesn't use both STDIN and STDOUT > simultaneously, and perhaps can't parse the data stream either. > > Clearly, I don't understand how things actually work. dbexport seems bound > and determined to create the mydatabase.exp directory whether I want it or > not. Someone suggested that I try > > dbexport -c -q mydatabase | xargs tar -cf - | rsh farbox "cd > /home/myhome/exports/ ; tar -xf -"> > which produces nothing either, since dbexport isn't producing a list of > filenames to be tar'ed, but (so I naively presume) a filename and its > data. > > Please, someone tell me that this is possible, and tell me how I actually > do this. I will even accept a little abuse, if it is intelligent abuse. > > -- > Cheers-- > Charles, Machine Whisperer (but, alas, not today)

charles.johnson@news.accessllc.net wrote in message <01c074fd$dfcd5e60$2f0a020a@pc0333>... >There must be a better way to solve my problem than the way I have solved >it, so I am looking for some advice/guidance. Pardon me if this sounds like >a lot of whining! > >I have Informix 7.3.X running on two AIX 4.3.3 boxes. I want to do a >dbexport from the "localbox" to the "farbox," and I would like to do it >without having the 5gig or so of .unl and .sql files appear on the local >box. I see no reason to create 5 gigs "local" and move those same 5 gigs >"far." What I wound up doing was creating/exporting an NFS file system on >the farbox, making it visible as a local directory on the localbox, doing a >cd to it, and running Apart from Mladen Jovanovski's excellent response, I was (ok, and still am) going to suggest that you look into the use of the automount or autofs utility. It's a real beauty. Basically, the normal NFS exports are set up or the server, which I'm sure you realise can be all boxes. Don't be afraid to put all the necessary security options in there if that's an issue for you. At the client end, instead of permanently mounting the remote drives, let automout do the work. It is given a small set of specification files, and then pretends to be an NFS mount. When a program actually tries to "decend" into the NFS mount, it jumps in, actually mounts the remote drive, sets up all sorts of secret symbolic links etc and then yields the request to NFS. Subsequent accesses go thru NFS at full speed with bugger-all interference. The real magic is, if automount detects that a mount has been quiet for (default 300 seconds) then it quietly unmounts the remote drive until it is tickled again. With this methodology, you can have all the benefits of NFS without the associated dangers of many hard remote mounts hanging round just waiting for a machine to crash. Here's my automount control files from HP-UX as a sample. Unfortunately I don't know if it's exactly the same as on AIX, but I'm sure you can RTFM. <FILE name="/etc/auto_master"> /stage /etc/auto_stage -rw,intr </FILE> <FILE name="/etc/auto_stage"> box1 \\ / &:/ \\ /box1 &:/box1a \\ box2 \\ / &:/ \\ /var &:/var \\ /usr &:/usr \\ /tmp &:/tmp \\ /opt &:/opt \\ /home &:/home \\ /box2a &:/box2a \\ /box2b &:/box2b \\ /box2c &:/box3c </FILE> You may notice that I've named all "user" file systems in a regular way - ${machine}[abc...] This makes them unique within the building, and I can then setup symbolic links from the top of all machines so that no matter what box I am on, I can cd /box2a and land in the proper place. This would be an impossible dream if all machines had /u /usr /users /usr1 etc etc etc. My symbolic links look like: ln -s /stage/box2/box2a /box2a As an extra convenience, I also set up: ln -s /stage/box2 /box2 so that I may drop into the top of the machine itself and get into the /opt /var filesystems that cannot be shared from the root directories due to name conflicts.