Exporting lob columns...???

Question

Is there any limitation of exporting LOB columns from client machines. If the client's export version is lower/greater, then is it going to affect the export of lob columns?

Answer 1

That's a bug. And even if the structure of the version you are dealing with is compatible, the functionality isn't. I suggest you to apply a patch to the client too.
Cause
This problem during export has been introduced with the 9.2.0.5 patchset. In that patchset, a fix has been included for Bug 2948717 "Queries against DBA_SEGMENTS can be slow accessing BYTES/BLOCKS/EXTENTS columns". Note that this fix has also been implemented in Oracle10g Release 1 (10.1.0.2.0).
As a result of that fix, an export from the 9.2.0.5.0 or any higher release database (e.g. 9.2.0.6.0 or 10.1.0.4.0) with a lower release export utility, e.g. 9.2.0.4.0 or 8.1.7.4.0 will now produce the EXP-3 error. For details see:
Bug 3593227 "EXP-3 WHEN EXPORTING A TABLE WITH MORE THAN 1 EXTENT USING EXP BELOW 9.2.0.5"
Bug 3784697 "EXPORT OF LOB FROM 9205 WITH PRE-9205 EXP GIVES EXP-3 (NO STORAGE DEF FOUND)"
These bugs were closed as a duplicate of:
Bug 3291851 "EXP-3: NO STORAGE DEFINITION FOUND FOR SEGMENT" (not a public bug)
Solution
The EXP-3 error only occurs when the export from the 9.2.0.5.0 or any higher release database (e.g. 9.2.0.6.0 or 10.1.0.4.0) is done with a lower release export utility, e.g. 9.2.0.4.0. The reason to run an export from a 9.2.0.5.0
or any higher release database (e.g. 9.2.0.6.0 or 10.1.0.4.0) with a 9.2.0.4.0 export utility, is to import the export dump file later into a target database of that lower release.
Note: if your intention is to export from a 9.2.0.6.0 database in order to import (back) into a 9.2.0.6.0 target database, there is no need to use a pre-9.2.0.5 release export utility. In that situation use the 9.2.0.6.0 export utility.
Workaround 1
Rerun the export and specify the parameter COMPRESS=Y (this is the default value for COMPRESS).
If you have a table with a secondary object, e.g. a LOB column, then this workaround might not work and you will re-produce the EXP-3 error during export. In that case, use workaround 2.
Workaround 2
a. Make a note of the export definition of exu9tne from $ORACLE_HOME/rdbms/admin/catexp.sql
b. Copy this to a new file and add:
"UNION ALL select * from sys.exu9tneb"
to the end of the definition
e.g. In the 9.2.0.5.0 or any higher release source database (e.g. 9.2.0.6.0 or 10.1.0.4.0), the workaround view would be:
CREATE OR REPLACE VIEW exu9tne (
tsno, fileno, blockno, length) AS
SELECT ts#, segfile#, segblock#, length
FROM sys.uet$
WHERE ext# = 1
UNION ALL
SELECT * from sys.exu9tneb
c. Run this as the SYS user (!) against the database that needs to be exported.
d. Re-run the export as required.
e. Put back the original definition of exu9tne as obtained in step a.
Note: only use this workaround when absolutely necessary, and don't forget to put back the original definition of the view SYS.exu9tne as mentioned in step e.