Hello,

I have a 24 GB dump file that was created with Oracle 8.1.7 on AIX,
which I want to proof-read with 10.2 on Windows, so I did:

imp system/xxx file=export.dmp fromuser=name touser=name show=y

It runs fine for a while but then prints the following errors:

illegal lob length marker 49408
bytesread = 00000000000
TABLE = MYTABLENAME
IMP-00098: INTERNAL ERROR: impgst2
IMP-00008: unrecognized statement in the export file:
<07><1e>
....
IMP-00032: SQL statement exceeded buffer length

These occur several times until IMP-00008 repeats forever (until I
aborted the import 16 hours later). Importing with a larger buffer
("buffer=2000000") made no difference.

The dump file can be imported without errors and warnings on the
source machine (8.1.7 on AIX). The original dump file and my copy of
it have identical CRCs so it's not a corruption issue. I'm running imp
directly on the DB server so it's not a client/server compatibility
issue either.

The export parameters are nothing special:

exp system/xxx file=export.dmp owner=name consistent=y

Any idea what's going wrong? Is the dump file ok, and if so, how can I
import it?

Thanks for any help
W. Rösler

On Jul 5, 5:31*pm, Wolfram Rösler <wolfram.roes... (AT) gmail (DOT) com> wrote:
Most probably 10.2 is not fully backwards-compatible with 8.1.7
(clients surely aren't.) Metalink note #132904.1 says that direct
export from 8.1.7 and import into 10.2 is not supported. One way to
import I can think of is to import the dump into an intermediate
9.2.0.8 database, export from there with 9.2 exp utility and then
import this new dump into 10.2. 9.2 is compatible with 8.1.7 and 10.2
is compatible with 9.2 as far as imp/exp are concerned.

Also, make sure both source and target databases (and tools) are at
the latest respective patchset levels (8.1.7.4 and 10.2.0.5 or
10.2.0.4, whichever is available for your platform.)

Hth,
Vladimir M. Zakharychev

Make sure you transfer your dump file in BINARY mode from the AIX
server to the Windows server. I've been bitten a couple times in the
past by not enabling BINARY prior to an FTP when dealing with two very
different machines.

On Jul 5, 9:31*am, Wolfram Rösler <wolfram.roes... (AT) gmail (DOT) com> wrote:
According to my reading of Vlad's reference:
Compatibility Matrix for Export And Import Between Different Oracle
Versions [Video] #132904.1

An 8.1.7.4 export can be read by 10.2 imp.

I would think the fact you are running this with show=y indicates the
dmp file is corrupted. At least that is what the error means per
note:

IMP-00098: INTERNAL ERROR: impgst2Segmentation Fault - core dumped
#578616.1

zero length lobs are also a possible issue
Bug 3890213 - IMP-98 possible importing zero length Lobs with
CHUNKSIZE > 32767 #3890213.8

So you could have a zero length LOB to fix before exporting or perhaps
as mentioned the copy of the export dmp file was not done using a
binary FTP but there is a very good chance the export is corrupted.

HTH -- Mark D Powell --

On Jul 5, 6:31*am, Wolfram Rösler <wolfram.roes... (AT) gmail (DOT) com> wrote:
The others probably have it right, especially given your CRC comment,
but you might want to transfer it back to AIX and diff them, just to
be sure. In the distant past, I saw windows silently truncate NFS
transferred dump files, the only clue being to look at the end of the
file for a couple of EXIT statements, IIRC. This would start
happening on my configuration (hpux) at around 20G.

jg
--
@home.com is bogus.
http://www.signonsandiego.com/news/2...-the-red-card/

On Jul 6, 7:51*pm, Mark D Powell <Mark.Powe... (AT) hp (DOT) com> wrote:
My bad indeed, I read the matrix incorrectly. Direct import from 8.1.7
to 10.2 seems to be officially supported.

Strange thing is that according to the OP this same export dump is
processed without errors on 8.1.7, so this must be either a bug, an
incompatibility or a corruption. Since 8.1.7 to 10.2 import is
supported and mentioned zero length LOB bug is fixed in 10.2.0.1 base
release, we are left with corruption, but the OP says file checksums
match. I don't know how the file was checksummed, but I'd recommend to
zip it on source host and transfer compressed dump in binary mode to
the target - if unzip will not throw any errors, you can be sure the
file is not corrupted.

Regards,
Vladimir M. Zakharychev

Hello,

The problem is solved, it wa a corruption issue after all (as most
have guessed). The 24 GB dump file was on a Unix server which I
accessed from a Windows PC via a Samba share. Samba and/or Windows
obviously corrupted the file (damaging its contents while leaving the
file size intact) when I computed the CRC as well as when I zipped and
copied it, which is why I got identical CRCs before and after zipping/
copying/burning to CD/unzipping.

I copied the file again with ftp, and now it imports fine.

Thanks for all who helped.

Best regards
W. Rösler