expdp到nfs磁盘的一次糟糕记忆

公司要分离业务，需要对数据进行一个快照的备份，准备走物理备份，可以由于数据文件创建太多 太乱琐碎就不利用cp，就考虑走逻辑备份，800g的数据准备用expdp开启并行倒是很轻松的可以在简短的时间完成的，不过由于晚上应用又再次重启导致备份了12个小时才备份了1/3而已。

简要记载一下这次expdp的过程，有些东西看起来简单单实际过程中并不是这么顺利。

Nfs挂载的磁盘root用户开始无法写入，然后做了一系列的改动后发现还是存在问题，root用户虽然能写入了，但是oracle用户无法写入，没办法准备添加root用户到dba组完成expdp，不过发现了虽然添加成功但是root居然默认的还是用的root组，不会利用附属的dba组，那也就不能用常规的desktop/desktop来完成expdp的导出，需要通过desktop/desktop@benguo采取走监听方式来执行导出。（不清楚这个添加服务后是否会影响expdp的效率，望大牛给出解答）

[oracle@server119 ~]$ df -h

文件系统 容量 已用 可用 已用% 挂载点

/dev/sda3 39G 26G 12G 69% /

/dev/sda10 331G 312G 2.3G 100% /opt

/dev/sda9 20G 173M 19G 1% /tmp

/dev/sda8 20G 305M 19G 2% /var

/dev/sda7 20G 2.3G 17G 13% /home

/dev/sda6 20G 1.7G 17G 9% /vol

/dev/sda2 331G 313G 1.4G 100% /db

/dev/sda1 2.0G 42M 1.8G 3% /boot

tmpfs 16G 0 16G 0% /dev/shm

/dev/sdb1 929G 705G 177G 80% /db2

/dev/sdb2 905G 200M 859G 1% /opt2

192.168.0.121:/nfs6 939G 200M 891G 1% /dbbak1

192.168.0.121:/nfs7 1.1T 304G 708G 30% /dbbak2

接下来问题又来了

[root@server119 dbbak2]$ desktop/********@benguo dumpfile=0629desktop.dmp logfile=0629desktop.log directory=back parallel=8

ORA-27054: NFS file system where the file is created or resides is not mounted with correct options

看来还远远没有如此简单，还是nfs挂载上可能出现了问题，由于os上自身还是比较薄弱，采取的oracle的方式设置事件后续重启就可以成功导出了。

Alter system set event= ‘10298 trace name context forever,level 32’ scope=spfile

记录一下这次expdp的过程中观察的db等待事件：

[oracle@server119 dbbak2]$ ps -ef|grep dm00

oracle 27343 1 0 Jun29 ? 00:00:26 ora_dm00_benguo

oracle 32726 32691 0 11:40 pts/4 00:00:00 grep dm00

[oracle@server119 dbbak2]$ ps -ef|grep dw

oracle 27347 1 0 Jun29 ? 00:00:43 ora_dw01_benguo

oracle 27349 1 13 Jun29 ? 02:15:07 ora_dw02_benguo

oracle 27351 1 0 Jun29 ? 00:00:19 ora_dw03_benguo

oracle 27353 1 0 Jun29 ? 00:00:30 ora_dw04_benguo

oracle 27355 1 0 Jun29 ? 00:00:24 ora_dw05_benguo

oracle 27357 1 0 Jun29 ? 00:00:18 ora_dw06_benguo

oracle 27359 1 0 Jun29 ? 00:00:20 ora_dw07_benguo

oracle 27361 1 0 Jun29 ? 00:00:24 ora_dw08_benguo

oracle 32663 32134 0 11:31 pts/1 00:00:00 grep dw

观察后台进程出现了9个进程，一个是ora_dm00_benguo这个是data pump master进程，其余的8个是相应真正负责epxpd子进程data pump worker，相应的大家可以根据v$session的program去查看详细的信息，此时大家可以查查等待事件。

SQL> col program for a30

SQL> col event for a50

SQL> col wait_class for a10

SQL> select program,event,wait_class from v$session where program like '%DM%';

PROGRAM EVENT WAIT_CLASS

------------------------------ -------------------------------------------------- ----------

oracle@server119 (DM00) wait for unread message on broadcast channel Idle

SQL> select program,event,wait_class from v$session where program like '%DW%';

PROGRAM EVENT WAIT_CLASS

------------------------------ -------------------------------------------------- ----------

oracle@server119 (DW08) wait for unread message on broadcast channel Idle

oracle@server119 (DW07) wait for unread message on broadcast channel Idle

oracle@server119 (DW06) wait for unread message on broadcast channel Idle

oracle@server119 (DW05) wait for unread message on broadcast channel Idle

oracle@server119 (DW04) wait for unread message on broadcast channel Idle

oracle@server119 (DW03) wait for unread message on broadcast channel Idle

oracle@server119 (DW02) direct path read User I/O

oracle@server119 (DW01) wait for unread message on broadcast channel Idle

8 rows selected.

这些等待都是idle，关注的这个direct path read是导出的lob字段引起的，可以根据v$session的program来查看session作业的具体程序，是后台进程还是用户连接进程，以前就做过kill一个dbwn进程，也是看他的等待事件是cache buffer lru chain直接就kill，导致数据库直接关闭，所以大家以后做kill操作时还是多看看这个program具体是什么吧。

总以为这次expdp就只能慢慢等了，不过后面的事情出现了，下午服务器意外又死机了，这台机器硬件上面已经存在很大的问题，想先略去一个大表和其上的lob段然后再执行expdp

Expdp desktop/desktop@benguo parfile=/dbbak2/parfile01.par

相应的parfile文件：

Dumpfile=0629desktop.dmp logfile=0629desktop.log exclude=table:”in(‘ARTICLE’)” parallel=6

这里最好用parfile文件来略去linux上复杂的转义字符。

速度还算给力，不过观察到一段时间后log中出现了如下错误：

Processing object type SCHEMA_EXPORT/REFRESH_GROUP

. . exported "DESKTOP"."AUTOSVC3_RULEARTICLE" 38.32 GB 139967557 rows

. . exported "DESKTOP"."ARTURLMD5" 27.79 GB 280393110 rows

ORA-39095: Dump file space has been exhausted: Unable to allocate 8192 bytes

Job "DESKTOP"."SYS_EXPORT_SCHEMA_03" stopped due to fatal error at 16:04:29

Job SYS_EXPORT_SCHEMA_03 has been reopened at Saturday, 30 June, 2012 16:23

Ora-39095 dump file space has been exausted unable to allocate 8192 bytes报错的解释：

Expdp的转储空间太小，数据无法写入转储文件内，其实还是不明白为什么会觉得转储文件太小了，上次导出快300g都没有报错，也是一个dumpfile，这次expdp不到200g的dumpfile才到70g就出现错误。

也有可能是设置parallel大于转储文件数目引起的，parallel io server processes写文件不能同时写一个，如果只有一个dumpfile或少于parallel并行数则会影响性能，而如果io server process在等待从而不能写dumpfile的时候就会出现ora-39095。

[oracle@server119 dbbak2]$ oerr ora 39095

. . exported "DE39095, 00000, "Dump file space has been exhausted: Unable to allocate %s bytes"

// *Cause: The Export job ran out of dump file space before the job was

// completed.

// *Action: Reattach to the job and add additional dump files to the job

// restarting the job.

通过上面的解释应该清楚了：因为开启parallel后还是用的一个dumpfile，会影响并行性能的，所以最好开启parallel等于dumpfile文件的一致，然后如果parallel io server processes处理不过来就可能出现ora-39095

其实开启并行下dumpfile最后写成变量形式dumpfile=0629desktop_%u.dmp让其oracle自由分配。

方法也是很简单的进入交互模式，

Expdp desktop/desktop@benguo attach=desktop.sys_export_schema_03

然后add_file=0629_02desktop.dmp增加了几个转储文件，然后start_job最后退出continue_client

还有网友碰到过如下的expdp错误

ORA-39097: Data Pump job encountered unexpected error -39079

。。。

ORA-39079: unable to enqueue message

[oracle@server119 dbbak2]$ oerr ora 39079

39079, 00000, "unable to enqueue message %s"

// *Cause: The Data Pump's communication layer was unable to send the

// specified message on the control or status queue. Subsequent

// messages will detail the problem.

// *Action: Fix the problem if possible, or contact Oracle Customer Support.

应该是expdp导出队列无法分配，具体原因自己也暂时没有深究过。

解决方案就是增加stream_pool_size不过流池也是属于sga的自动管理下，asmm应该会自动分配的。（苦于没有碰到真实的案例）

总体来说expdp估计能在后续完成，不过感觉这次处理还是暴露了os上薄弱，nfs挂载应该是可以到root然后chown disk给oracle用户组的。Expdp的交互使用确实强大，可以修改并行度和add_file dumpfile的文件等。

[@more@]

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/25362835/viewspace-1058681/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/25362835/viewspace-1058681/