Export/Import error while using gzip

[Brian_274]

Hello All,
I'm trying to set up my export with gzip as I had it at my last company. I had hp-10 and/or RHAS. The export script was the following that worked fine.

cat pipe_file_name.dmp | gzip -c > gziped_file.dmp.gz &

exp / direct=y buffer=5000000 compress=y log=log_name.log file=pipe_filename.dmp full=y

I run this and it works fine. I go to import and get errors.

imp / file=pipe_file_name.dmp buffer=5000000 fromuser=owner touser=owner log=log_name.log &

gunzip -c gziped_file.dmp.gz > pipe_file_name.dmp

Export file created by EXPORT:V08.01.07 via direct path
import done in US7ASCII character set and AL16UTF16 NCHAR character set
import server uses WE8ISO8859P1 character set (possible charset conversion)
export server uses US7ASCII NCHAR character set (possible ncharset conversion)
. importing TM's objects into TM
. . importing table "T_ACTCAT_TOS_SPREAD"
IMP-00051: Direct path exported dump file contains illegal column length
IMP-00008: unrecognized statement in the export file:

I tried changing the buffer to be a smaller number but still get an error. Any suggestions? Is there something wrong with gzip no HP-11i on 64bit system? Should I be using a different compress tool then gzip?

thanks.

[Jeff Schussele]

Hi,

Yep, gzip could be a problem if the file(s) being accessed are +2GB. The OS bundled gzip is v1.2.4 & to reliably handle +2GB files takes v1.3.1 or higher.

Gzip 1.3.5 is available here:

http://hpux.cs.utah.edu/hppd/hpux/Gnu/gzip-1.3.5/

Note that the OS included ver is installed in /usr/contrib/bin & this ver will install in /usr/local/bin by default - but can be redirected.

HTH,
Jeff

[Steven E. Protter]

It also appears the character set of the export is different than the import. Oracle might have trouble with that. You might want to normalize this between the two databases.

SEP

[Hein van den Heuvel]

Sorry for the silly question, but you only implied you created a pipe and did not show how. You did do a 'mknod pipe_file_name.dmp p' right?

fwiw, the 'cat' step is often not needed, you can make gzip/compress read the input directly (using -c modifier).

An other thread in this space:
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=57337

hth,
Hein.

[Brian_274]

Yes I am creating the pipe file the following way:

mknod file_name.dmp p

[Indira Aramandla]

Hi Brian,

If after successfully completing a direct path export of your database, importing the file into gives the following errors:

IMP-00051: Direct path exported dump file contains illegal column length
IMP-00018: partial import of previous table completed: %lu rows imported
IMP-00008: unrecognized statement in the export file: n %s
IMP-00009: abnormal end of export file

This could be related to bug 809477. The solution to this bug was to try direct path export with RECORDLENGTH 64000.

Oracle says the solution to this bug is to try direct path export with RECORDLENGTH 64000. However, if this does not fix the problem, the export should be run with the conventional export path. And then retry to import from the comventional export dump.

I hope this helps.

Indira A

[Brian Crabtree · Accepted solution]

Brian,

I tend to do things a little different, but they work as far as I know:

mknod exp_pipe p
gzip < exp_pipe > expfile.dmp.gz &
exp file=exp_pipe ...

mknod imp_pipe p
gunzip < expfile.dmp.gz > imp_pipe &
imp file=imp_pipe ...

I seem to remember having alot of bad experiances with the "gzip -c" command.

Brian

[T G Manikandan]

Jeff is right

you should have gzip 1.2.4a or higher for largefiles.

check the version using
#gzip -V

you can get the recent version from the link given above

[Yogeeraj_1]

hi brian,

First of all, it is always recommended that you always export with compress=N.

Because "compress=y" generates a create table statement that has an INITIAL extent equal to the sum of all allocated extents during an Import.

Also, bare in mind the speed factor!
Don't use a simple exp owner=, imp owner=. Export table by table (in parallel, just fire off export more then once). Import table by table (in parallel, just fire off import more then once).

As IA mentioned above, i also think that the problem is related to the direct path export. You should note that Direct path Export exports in the database server character set only. If the character set of the export session is not the same as the database character set when an export is initiated, Export displays a warning and aborts. Using the NLS_LANG parameter, specify the session character set to be the same as that of the database before retrying the export.

Is the problem associated with gzip? NOT Really!

Hope this help!
regards
Yogeeraj

[Brian_274]

Thanks everyone for your responses. Brian's way worked for me. Yogeeraj, regarding compress=Y, it all depends on what you are using compress for. I use it to help defrag the database. And yes this was a gzip problem. The os admin hasn't installed the latest version yet so I can't test that. I just used the current gzip version, 1.2.4 and brian's way of doing it and got it to work.