环境：Linux+Oracle 11g
今天下午应用人员在用exp导出一个表的数据的时候遇到了EXP-00002的错误，通常情况下，EXP-00002的错误原因有以下可能性：
Question: I'm running an export (expdp) on a Windows server, and I'm getting the "EXP-00002: error in writing to export file" error:
EXP-00002: error in writing to export file
EXP-00002: error in writing to export file
EXP-00000: Export terminated unsuccessfully
How do I fix the output file?
Answer: The docs note this on the ORA-0002 error, a generic file write problem:
00002, 00000, "error in writing to export file"
// *Cause: Export could not write to the export file, probably because of a
// device error. This message is usually followed by a device message
// from the operating system.
导出无法写出到导出文件,可能是因为设备错误。通常紧随其后的是一个操作系统的设备信息。
// *Action: Take appropriate action to restore the device.
This EXP-00002 error is hardware related, and you need to see the accompanying OS message to see details. This EXP-00002 error is common when the expdp writing has filled the destination output file, as defined in the parfile. Check the output file name in your export parameter file, and see the space usage.
该错误是一个硬件相关错误，你需要检查相关操作系统信息来获取细节信息。该错误常发生在expdp写文件的目的地（定义在parfile中）已经塞满了文件的情况下。检查以下export参数文件中的输出文件名，看一下空间使用情况。
This can also happen on 32-bit servers when the file size exceeds two gigabytes, requiring the use of the split command to separate the exp output onto multiple files.
这个错误同样在32位服务器上当文件大小超过2000MB的时候，这个时候就需要将输出文件拆分成多个小文件了。FAT32文件系统不支持大于4G的文件。
The EXP-00002 can also occur if the directory permissions are wrong, and do not allow writing into the diectory.
同样的，还有可能是因为目录权限错误而导致没有往其中写入文件的权限。
通过检查发现是磁盘空间不足，进而发现磁盘中有一个文件过大，这个文件是
crfclust.bdb
，达到23G之多，有两种解决办法，一是删除这些*.bdb文件，二是打补丁，直接采用了第一种办法，将这些文件删除，删除之后发现空间没释放，这个时候关闭集群服务然后再次重启，磁盘空间得到释放，可用空间31G左右。
大概一个多小时候，应用那边又打电话过来，说还是导出之前那个表，虽然没出错，但是已经导出40多分钟了还没有结束，是不是哪里出了问题，从我们这边查出的情况来看，exp导出的dmp文件已经超过7个GB，与我们之前查询的100多MB完全不符，而且dmp文件还有不断增大的趋势。问题到底在哪？既然能够导出数据而没有报错，那么命令应该是没有问题的，从应用那边发过来的命令来看也验证了这个想法。那么是不是因为schema等原因导致导出了其它表？经过验证也排除了这一可能。这个时候想起来应该看看这个表的结构，通过desc table_name发现一个关键的信息，那就是该表存在一个BLOB字段，对应的列名叫PHOTO!PHOTO不就是照片吗？！是不是因为我们之前的查询无法查出BLOB字段的大小？通过查资料得知，LOB 由两部分组成：数据（值）和指向数据的指针（定位器）。尽管值与表自身一起存储，但是一个 LOB 列并不包含值，仅有它的定位指针。更进一步，为了使用大对象，程序必须声明定位器类型的本地变量。当 LOB （除了 BFILE ）被创建时，定位器被存放在列中，值被存放在 LOB 段中， LOB 段是在数据库内部表的一部分。当 BFILE 被创建时，定位器如同平常一样存储在列中。也就是说，我之前的查询语句：select onwer,segment_name,segment_type,bytes/1024/1024 MB from dba_segments where segment_name='TABLE_NAME';无法查出photo列的数据量大小。通过select dbms_lob.getLength(column_nmae) from owner.table_name,查出了该表中photo列的大小，通过大致估算整个表数据量大小应该为20个多GB。
![[PWN][基础篇]格式字符串漏洞发生的条件（下）](https://ucc.alicdn.com/pic/developer-ecology/74fc61a2fe91451a9f83d7b23610c2fe.png?x-oss-process=image/resize,h_160,m_lfit)
![[PWN][基础篇]格式字符串漏洞发生的条件（上）](https://ucc.alicdn.com/pic/developer-ecology/84bb4e1615d34e858870dfa620ffc74e.png?x-oss-process=image/resize,h_160,m_lfit)