今天现场人员报告说exp的时候报权限不足的错误。
是用当前用户作的用户级别的exp，按理说应该没有什么权限的问题。
按照现场的情况作了测试，果然重现了问题。
d:/Temp>exp parfile=exp.par
Export: Release 9.2.0.5.0 - Production on Tue Dec 21 22:27:13 2004
Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.
EXP-00008: ORACLE error 1031 encountered
ORA-01031: insufficient privileges
EXP-00000: Export terminated unsuccessfully
其中exp.par的内容如下：
userid=scott/tiger
file=./scott.dmp
indexes=y
grants=y
rows=y
constraints=y
owner=scott
direct=n
compress=n
feedback=10000
resumable=y
resumable_timeout=7200
log=./export.log
没有发现什么问题，想作一个trace抓出错误的发生点，于是决定使用errorstack event。由于exp是在命令行中直接执行的，所以只能对整个数据库系统作trace，而由于只是想知道ORA-01031错误的发生原因，所以用以下语句：
alter system set events '1031 trace name errorstack level 3';
然后重新运行exp，仍然报错，这时候在udump目录中生成了trace文件，检查文件内容，发现：
*** SESSION ID:(15.210) 2004-12-21 22:22:36.704
*** 2004-12-21 22:22:36.704
ksedmp: internal or fatal error
ORA-01031: insufficient privileges
Current SQL statement for this session:
ALTER SESSION ENABLE RESUMABLE TIMEOUT 7200
原来问题出在ENABLE RESUMABLE部分，这是9i的新特性，用于在出现空间不足的问题时，挂起整个操作以等待操作人员解决空间问题。
只要确认了问题所在，就很好解决了，其实如果详细地看过adminitrator文档，也就不会犯这个错误，文档里面Enabling and Disabling Resumable Space Allocation部分很清楚地写着：如果要使用resumbale特性，那么必须有resumable系统权限。
检查现场用户的权限，发现只有connect和resource权限。于是：
grant resumable to username;
当然如果象一些应用里面那样，用户始终是具有DBA角色的话，那么永远也不会发生这个错误，因为DBA角色本来就具有esumable系统权限。不过为了安全起见，我们的应用中用户都不会具有DBA权限。
解决问题的方法很简单，没什么好说的，本文想介绍的也是发现问题的手段，也就是利用set events的方法。这个方法在我们对一个错误感到莫名其妙的时候往往会成为指路明灯。
作者简介:
张乐奕，网名kamus
曾任ITPUB Oracle认证版版主,现任itpub Oracle管理版版主。
现任职于北京某大型软件公司，首席DBA，主要负责证券行业的全国十数处核心交易系统数据库管理及维护工作。
热切关注Oracle技术和其它相关技术，出没于各大数据库技术论坛，目前是中国最大的Oracle技术论坛www.itpub.net的数据库管理版版主。
阅读更多技术文章和随笔可以登录我的个人blog。
http://blog.dbform.com。