Re: dbexport failed with "Disk space full" message.

Item Subject: dbexport failed with "Disk space full" message. IMHO You should use mixture of onunload and dbexport. Take a backup before doing any of these. 1) Onunload -- Tables which are really huge ,it is otherwise also wise to use onunload as it is much faster. 2) Generate schema for the tables used in step (1). 3) Drop these unloaded big tables. 4) Dbexport. Vivek ______________________________ Reply Separator _________________________________ Subject: dbexport failed with "Disk space full" message. Author: JSalomon (JSalomon@bn.com) at internet-shar Date: 7/18/00 9:16 AM Hi Family. I just tried a dbexport on a database with some enormous tables. The dbexport failed with the message: Disk space full. Clearly, the dbspaces and the file system I am unloading from and to are far from full. Only at the second failure did it occur to me to look at the .unl files. ls -lt indicated the most recently written .unl file to have just hit the 2-GB boundary. My expletives at this revolting develpoment aside, I went looking for a similar victim in this newsgroup and I found a long thread, started by one CHENUS Thierry, that lamented over it. The only way around this stupid restriction in dbexport was to export to tape. And, according to the info in the thread, there is still a 2- GB restriction on the amount of data dbexport will write to a tape, even a 40-GB tape. I am still using 7.2 (don't worry! We're upgrading soon to 9.2! ;-) but it seems that 7.3 is no smarter. I don't know if it improves in 9.2 either. Next straw to clutch at: Does anyone out there know of a utility to replace dbexport and gets around the 2-GB constraint? Has anyone (i.e. Jonathan? Art?) written one? Thanks much, folks. -- +----- Jacob Salomon - DBA JSalomon@bn.com - --------------------------+ |------------------- Bulletin Board Announcement ----------------------| | Congregants will please note that the bowl at the back of the church | | bearing the sign "For the Sick" is for monetary contributions only. | +----------------------------------------------------------------------+ Sent via Deja.com http://www.deja.com/ Before you buy.

I think that you can also export to a named pipe and gzip the pipe contents to a file which is (hopefully) < 2gb. Bill Border Agilent Technologies bill_border@agilent.com Effective, Affordable DB Monitor: http://dbamon.com vivek.chaudhary@st.com wrote in message <8l4ija$9e6$1@news.xmission.com>... > >Item Subject: dbexport failed with "Disk space full" message. > IMHO You should use mixture of onunload and dbexport. > > Take a backup before doing any of these. > > 1) Onunload -- Tables which are really huge ,it is otherwise also wise > to use onunload as it is much faster. > > 2) Generate schema for the tables used in step (1). > > 3) Drop these unloaded big tables. > > 4) Dbexport. > > > Vivek >______________________________ Reply Separator _________________________________ >Subject: dbexport failed with "Disk space full" message. >Author: JSalomon (JSalomon@bn.com) at internet-shar >Date: 7/18/00 9:16 AM > > >Hi Family. > >I just tried a dbexport on a database with some enormous tables. The >dbexport failed with the message: Disk space full. > >Clearly, the dbspaces and the file system I am unloading from and to >are far from full. Only at the second failure did it occur to me to >look at the .unl files. ls -lt indicated the most recently written .unl >file to have just hit the 2-GB boundary. > >My expletives at this revolting develpoment aside, I went looking for a >similar victim in this newsgroup and I found a long thread, started by >one CHENUS Thierry, that lamented over it. > >The only way around this stupid restriction in dbexport was to export >to tape. And, according to the info in the thread, there is still a 2- >GB restriction on the amount of data dbexport will write to a tape, >even a 40-GB tape. > >I am still using 7.2 (don't worry! We're upgrading soon to 9.2! ;-) but >it seems that 7.3 is no smarter. I don't know if it improves in 9.2 >either. > >Next straw to clutch at: Does anyone out there know of a utility to >replace dbexport and gets around the 2-GB constraint? Has anyone (i.e. >Jonathan? Art?) written one? > >Thanks much, folks. >-- >+----- Jacob Salomon - DBA JSalomon@bn.com - --------------------------+ >|------------------- Bulletin Board Announcement ----------------------| >| Congregants will please note that the bowl at the back of the church | >| bearing the sign "For the Sick" is for monetary contributions only. | >+----------------------------------------------------------------------+ > > >Sent via Deja.com http://www.deja.com/ >Before you buy.

In article <8l4191$a5q$1@nonews.col.hp.com>, Bill Border <bill_border@agilent.com> writes > I think that you can also export to a named pipe and gzip >the pipe contents to a file which is (hopefully) < 2gb. > Why run 1. dbexport .. -t file1.. 2. When it prompts for a tape - run sync to flush everything to disk - rename file1 to file2 - touch file1; chmod 666 file1; - continue the export (which starts writing to buffer cache in memory) - Begin dbimport... -t file2 (which reads from disk). For a while the import reads from disk whilst the export writes to the buffer cache in memory. Hence the only process doing disk i/o is the import. Works great if you have lots of memory. Also the sync does all the i/o in one go (like a checkpoint) and hence uses large sequential writes and there is no contention for the final xMb written. 3. When dbexport prompts for another tape AND dbimport prompts for another tape 4. rename file1 to file2 5. sync;touch file1; chmod 666 file 6. continue the import and the export. i.e. have both running at the same time? The dbexport read from one set of disks (the old database) and dbimport writes to another set of disks (the new database). The only contention is the shared disk but since dbexport has to wait for reads from the old database and dbimport has to wait for writes to the new database there is not as much contention for the shared disk as you might expect. Plus they are both doing sequential i/o which helps. >Bill Border >Agilent Technologies >bill_border@agilent.com >Effective, Affordable DB Monitor: http://dbamon.com > >vivek.chaudhary@st.com wrote in message <8l4ija$9e6$1@news.xmission.com>... >> >>Item Subject: dbexport failed with "Disk space full" message. >> IMHO You should use mixture of onunload and dbexport. >> >> Take a backup before doing any of these. >> >> 1) Onunload -- Tables which are really huge ,it is otherwise also wise >> to use onunload as it is much faster. >> >> 2) Generate schema for the tables used in step (1). >> >> 3) Drop these unloaded big tables. >> >> 4) Dbexport. >> >> >> Vivek >>______________________________ Reply Separator >_________________________________ >>Subject: dbexport failed with "Disk space full" message. >>Author: JSalomon (JSalomon@bn.com) at internet-shar >>Date: 7/18/00 9:16 AM >> >> >>Hi Family. >> >>I just tried a dbexport on a database with some enormous tables. The >>dbexport failed with the message: Disk space full. >> >>Clearly, the dbspaces and the file system I am unloading from and to >>are far from full. Only at the second failure did it occur to me to >>look at the .unl files. ls -lt indicated the most recently written .unl >>file to have just hit the 2-GB boundary. >> >>My expletives at this revolting develpoment aside, I went looking for a >>similar victim in this newsgroup and I found a long thread, started by >>one CHENUS Thierry, that lamented over it. >> >>The only way around this stupid restriction in dbexport was to export >>to tape. And, according to the info in the thread, there is still a 2- >>GB restriction on the amount of data dbexport will write to a tape, >>even a 40-GB tape. >> >>I am still using 7.2 (don't worry! We're upgrading soon to 9.2! ;-) but >>it seems that 7.3 is no smarter. I don't know if it improves in 9.2 >>either. >> >>Next straw to clutch at: Does anyone out there know of a utility to >>replace dbexport and gets around the 2-GB constraint? Has anyone (i.e. >>Jonathan? Art?) written one? >> >>Thanks much, folks. >>-- >>+----- Jacob Salomon - DBA JSalomon@bn.com - --------------------------+ >>|------------------- Bulletin Board Announcement ----------------------| >>| Congregants will please note that the bowl at the back of the church | >>| bearing the sign "For the Sick" is for monetary contributions only. | >>+----------------------------------------------------------------------+ >> >> >>Sent via Deja.com http://www.deja.com/ >>Before you buy. > > -- David Williams