Re: Dbexport

mbaumgartner@cardhealth.com wrote: > > Apparently the issue is with Informix software and not the OS. As I stated > before we can write files using the OS larger than 2 gigs. Technical support > indicated the problem is that dbaccess (unload, etc) and dbexport links to lseek > which uses a 32 bit pointer and therefore a limit of a two gig file size. If > however, the link was to lseek64 we could then write files larger than 2 gigs. > > If you have imperical experience with writing flat files using one of the above > Informix utilities (or any for that matter) on a HP/UX 10.20 system please let > me know how. I would be greatly indebted to you. > > BTW, we do not want to consider having to break this huge table into a bunch of > small pieces. That method is cumbersome to manage and takes far more time to > complete. We cannot afford to miss a single piece of data. > > Thanks, > > Mark > Cardinal Health, Inc. > I have to concur with Mark Stock, and recommend dbexport, <IF> it has proven to work correctly on your OS. It seems to work great on NT, I've not used it in a while on HP/UX et al, so no confirmation on UNIX versions. This appears to be a dbexport bug as others have indicated. I use the NT version daily without problems--however none of my unloads have hit 2GB so I have no problems so far. :-) The product you might consider is using the high-performance loader if your UNIX version of Informix has it. It's not available on NT, again I don't know if all UNIXes are getting it. If you have the hp-loader, you can set up a "device" such as a pipe to gzip or compress, and then work-around the problem. Unfortunately, this still does not solve the error with dbexport for all the rest of your tables. It looks as if dbexport will still be a problem as you cannot (To the best of my knowledge) exclude certain tables during the dbexport. Table-level back-ups are one of the most requested features people are requesting, and if I'm not mistaken, this will be a forthcoming feature very soon. dbexport/dbimport offer one significant reason to be used: They manage the re-creation of the data base in the correct order by conducting all the alter table commands after all the tables are loaded, putting the constraints, sp's, triggers, etc. into the data base. Without this feature, dbexport/dbimport are simply table unloads/reloads. So, how could you solve this problem of yours. I would create a bogus data base, based on your current schema. Conduct a dbexport from the bogus data base, without any data in it, and save the .sql file created from the dbexport. You now have a command file that can recreate your constraints, sp's, triggers, etc. Then, as others have suggested, perform individual unloads of your tables, via a shell script. This shell script will use filenames indicated in the .sql script. You will have to add your sp's, triggers, etc. on the initial schema before doing the dbexport from the bogus data base. Take the .sql script and modify it for your re-creation scenario. The script that does the unloads should name the unload files the same names as the .unl filenames in the .sql script. The trickery will be in substituting the row-sizes, but this could easily be done with a sed or perl program, and using wc. The bogus.sql file will show all row-sizes as 0 ( zero ) for your data tables, so you should be able to find the pattern, based on the .unl, and the row-size. Should you need to recreate your data base, you can use the new .sql file created and never worry about the file limit. Just a suggestion, but it does allow a successful implementation of all the ideas suggested so far. This has never been tested but it's worth a try. Might make a nice tool... OR as suggested you could do the tape method. Cheers, Tim -- Tim Schaefer \\\\|// tschaefe@mindspring.com 6 6 -------------------------oOOo---( )---o00o---------------------- http://www.inxutil.com - My Ezine http://www.informix.com - Informix Software Inc. http://www.iiug.org - International Informix User Group/FAQ news://comp.databases.informix - Newsgroup for Informix Users ================================================================