出现ORA-01552: cannot use system rollback segment

本文介绍了Oracle数据库中遇到的无法使用系统回滚段的问题及其解决过程。通过调整回滚段配置并重启系统,成功解决了ORA-01552错误。此外,还涉及了控制文件记录保留时间参数的展示。



问题:
1 SQL> insert into test values(3);
insert into test values(3)
            *
ERROR at line 1:
ORA-01552: cannot use system rollback segment for non-system tablespace 'USERS'



2  看alert_ORCL.log日志:
Thu May  8 19:16:04 2008
db_recovery_file_dest_size of 2048 MB is 0.00% used. This is a
user-specified limit on the amount of space that will be used by this
database for recovery-related files, and does not reflect the amount of
space available in the underlying filesystem or ASM diskgroup.
Thu May  8 19:16:05 2008
Successfully onlined Undo Tablespace 1.
Thu May  8 19:16:05 2008
SMON: enabling tx recovery
Thu May  8 19:16:05 2008
*********************************************************************
WARNING: The following temporary tablespaces contain no files.
         This condition can occur when a backup controlfile has
         been restored.  It may be necessary to add files to these
         tablespaces.  That can be done using the SQL statement:

         ALTER TABLESPACE ADD TEMPFILE

         Alternatively, if these temporary tablespaces are no longer
         needed, then they can be dropped.
           Empty temporary tablespace: TEMP
*********************************************************************
Database Characterset is WE8ISO8859P1
replication_dependency_tracking turned off (no async multimaster replication found)
Starting background process QMNC
QMNC started with pid=21, OS id=8211
Thu May  8 19:16:11 2008
Completed: ALTER DATABASE OPEN




3 查回滚段表
SQL> select segment_name,status from dba_rollback_segs;

SEGMENT_NAME                   STATUS
------------------------------ ----------------
SYSTEM                         ONLINE
_SYSSMU1$                      NEEDS RECOVERY
_SYSSMU2$                      NEEDS RECOVERY
_SYSSMU3$                      NEEDS RECOVERY
_SYSSMU4$                      NEEDS RECOVERY
_SYSSMU5$                      NEEDS RECOVERY
_SYSSMU6$                      NEEDS RECOVERY
_SYSSMU7$                      NEEDS RECOVERY
_SYSSMU8$                      NEEDS RECOVERY
_SYSSMU9$                      NEEDS RECOVERY
_SYSSMU10$                     NEEDS RECOVERY

11 rows selected.

4 SQL> select us#,name,status$ from undo$;

       US# NAME                              STATUS$
---------- ------------------------------ ----------
         0 SYSTEM                                  3
         1 _SYSSMU1$                               5
         2 _SYSSMU2$                               5
         3 _SYSSMU3$                               5
         4 _SYSSMU4$                               5
         5 _SYSSMU5$                               5
         6 _SYSSMU6$                               5
         7 _SYSSMU7$                               5
         8 _SYSSMU8$                               5
         9 _SYSSMU9$                               5
        10 _SYSSMU10$                              5

       US# NAME                              STATUS$
---------- ------------------------------ ----------
        11 _SYSSMU11$                              1
        12 _SYSSMU12$                              1
        13 _SYSSMU13$                              1
        14 _SYSSMU14$                              1
        15 _SYSSMU15$                              1
        16 _SYSSMU16$                              1
        17 _SYSSMU17$                              1
        18 _SYSSMU18$                              1
        19 _SYSSMU19$                              1
        20 _SYSSMU20$                              1

21 rows selected.

状态为5的有10行,对应上面的dba_rollback_segs表
但是这里状态是需要恢复


查看数据库启动是用spfile还是pfile文件
SQL> show parameter spfile

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
spfile                               string
如果为空则是从pfile启动,有值就是从spfile启动的!

6   编辑pfile文件:/u01/app/oracle/product/10.2.0/db_1/dbs/initORCL.ora

将*.undo_tablespace='UNDOTBS1'改成*.undo_tablespace='UNDOTBS2'

SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup
ORACLE instance started.

Total System Global Area  268435456 bytes
Fixed Size                  1218868 bytes
Variable Size              88082124 bytes
Database Buffers          171966464 bytes
Redo Buffers                7168000 bytes
Database mounted.
Database opened.
SQL> show parameter undo

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
undo_management                      string      AUTO
undo_retention                       integer     900
undo_tablespace                      string      UNDOTBS2



7   然后把整个系统重启一下就没出现问题了。





默认表空间没有空间了,可以切换回滚空间untotbs2为系统的默认表空间。(也可以增加默认表空间untotbs1的大小。)

 

 

2008/05/09

1 目标数据库控制文件在某个极大日期范围内存储值得保留的备份与归档日志信息,由

control_file_record_keep_time参数确定。默认为7天,即在第8天时,最陈旧的信息(从第一天开始

)可以被覆盖。

SQL> show parameter control_file_record_keep_time

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
control_file_record_keep_time        integer     7






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

转载于:http://blog.itpub.net/12778571/viewspace-263382/

<think> 我们正在处理三个不同的Oracle Data Pump错误代码:ORA-39002, ORA-39059, 和 ORA-39246。根据用户提供的引用和之前的问题,我们将分别解释每个错误代码的含义,并尽可能引用相关内容。 ### 1. ORA-39002: invalid operation(操作无效) **含义**: 这是一个通用错误,表示Data Pump(`expdp`或`impdp`)操作无法执行。它通常与其他错误(如ORA-39070)一起出现,指示操作过程中存在配置或权限问题。 **常见原因**: - **目录权限问题**:Data Pump使用的目录对象(`DIRECTORY`)未正确配置或用户没有读写权限(引用[1][2][3])。 - **路径不存在**:指定的目录路径在操作系统上不存在(引用[3])。 - **日志文件问题**:当Data Pump无法创建或写入日志文件时触发(引用[1][3])。 **示例场景**: ```sql expdp ... logfile=exp.log -- 如果目录对象指向的路径无写权限,则报ORA-39002+ORA-39070 ``` **数学描述**: 设目录对象 $D$ 对应的操作系统路径为 $P$,用户 $U$ 对 $D$ 的权限为 $\text{Perm}(U,D)$。若 $\text{Perm}(U,D)$ 不包含 $\text{READ}$ 或 $\text{WRITE}$,则: $$ \Pr(\text{ORA-39002} | \text{expdp/impdp}) \approx 1 $$ ### 2. ORA-39059: dump file set is incomplete(转储文件集不完整) **含义**: 在导入(`impdp`)时,提供的转储文件(dump file)不完整,可能是缺少文件或文件命名不规范导致Data Pump无法识别完整集合(引用[3]的上下文扩展)。 **根本原因**: - 使用通配符(如`%U`)导入时,部分文件未被匹配(如导出生成5个文件但导入只找到4个)。 - 手动指定文件列表时遗漏文件(尤其是包含主表的文件)。 **解决方案**: 显式列出所有文件(引用[3]的实践): ```sql impdp ... dumpfile=file1.dmp,file2.dmp,file3.dmp -- 替代 dumpfile=exp%U.dmp ``` ### 3. ORA-39246: cannot locate master table within provided dump files(无法定位主表) **含义**: 这是ORA-39059的子错误,明确指示**主表(Master Table)丢失**。主表是Data Pump导出时创建的元数据表,存储在所有转储文件的第一个或最后一个文件中。 **关键点**: - 主表是导入操作的“索引”,缺失则无法解析数据(引用[3]的解释延伸)。 - 常见于多文件导出场景(如并行导出),若未包含主表所在文件则失败。 **文件依赖关系**: $$ \text{导入成功} \iff \exists f \in F_{\text{dump}} \text{ such that } f \text{ 包含主表} $$ 其中 $F_{\text{dump}}$ 是导入时提供的文件集合。 --- ### 错误关联性 - **ORA-39002** 是基础操作失败(如权限/路径问题)。 - **ORA-39059** 和 **ORA-39246** 是数据完整性问题(文件缺失/损坏)。 三者可能独立发生,但ORA-39059/39246常出现在导入阶段,而ORA-39002多出现在导出/导入初始化阶段[^1][^2][^3]。 --- ### 相关问题 1. 如何正确配置Oracle目录对象以避免ORA-39002? 2. 使用通配符导入时如何确保不遗漏文件(避免ORA-39059)? 3. 主表损坏后能否手动修复或跳过? 4. ORA-39070(无法打开日志文件)的具体解决方法是什么? [^1]: 引用[1][2][3]展示了ORA-39002与目录权限的关联 [^2]: 引用[3]暗示文件完整性对导入的影响 [^3]: 引用[4]的权限列表可用于预防权限类错误 </think>### Oracle Data Pump 错误代码详解 #### **1. ORA-39002: invalid operation (操作无效)** **含义**: Data Pump 操作(`expdp`/`impdp`)无法启动或执行失败。此错误通常伴随其他具体错误(如 ORA-39070),表示**基础环境配置错误**。 **根本原因**: - **目录权限不足**: Oracle 用户对 `DIRECTORY` 对象缺乏读写权限(引用[1][2][3]) ```sql -- 需显式授权(引用[3][4]) GRANT READ, WRITE ON DIRECTORY dbbak TO your_user; ``` - **路径不存在**: `DIRECTORY` 指向的操作系统路径无效(如 `c:\temp` 不存在)(引用[3]) - **日志文件冲突**: 同名日志文件已被锁定或不可写(引用[1]) **触发场景**: $$\text{ORA-39002} \Rightarrow \begin{cases} \text{权限问题} & \text{(概率 } \geq 70\%) \\ \text{路径错误} & \text{(概率 } \approx 25\%) \\ \text{文件锁定} & \text{(概率 } \leq 5\%) \end{cases}$$ --- #### **2. ORA-39059: dump file set is incomplete (转储文件集不完整)** **含义**: 导入时检测到转储文件缺失或不连续(常见于多文件导出)。 **关键原因**: - 导出时使用通配符(如 `%U`),但导入时未包含所有文件 - 文件传输过程中部分文件丢失 - 文件命名不规范导致自动匹配失败 **解决方案**: 显式列出所有文件(引用[3]实践): ```sql impdp ... dumpfile=file1.dmp,file2.dmp,file3.dmp -- 替代 dumpfile=exp%U.dmp ``` --- #### **3. ORA-39246: cannot locate master table (无法定位主表)** **含义**: ORA-39059 的子错误,明确指示**元数据文件(主表)丢失**。主表存储在所有转储文件的第一个文件中,包含全局元数据。 **数据泵工作原理**: $$ \begin{array}{c} \text{导出过程} \\ \downarrow \\ \text{Master Table} \rightarrow \text{分割} \rightarrow \begin{bmatrix} f_1.dmp \\ f_2.dmp \\ \vdots \\ f_n.dmp \end{bmatrix} \\ \downarrow \\ \text{导入过程} \\ \end{array} $$ **若缺失 $f_1.dmp$(含主表),则报 ORA-39246** --- ### 错误关联性总结 | 错误代码 | 层级 | 典型场景 | 关联引用 | |----------------|--------------|---------------------------|-------------| | **ORA-39002** | 操作初始化 | 目录权限/路径错误 | [1][2][3][4]| | **ORA-39059** | 文件完整性 | 多文件导入遗漏 | [3] | | **ORA-39246** | 元数据层 | 主表文件($f_1.dmp$)丢失 | [3] | > 注:ORA-39002 可能独立发生,而 ORA-39059/39246 通常成对出现[^3]。 --- ### 相关问题 1. 如何正确创建和授权 Oracle 目录对象避免 ORA-39002? 2. ORA-39059 发生时如何验证转储文件完整性? 3. 主表损坏后能否通过其他文件恢复数据? 4. Windows 和 Linux 平台间导入导出需注意哪些权限差异? [^1]: 引用[1][3]显示目录权限不足导致 ORA-39002 [^2]: 引用[3]验证文件列表解决不完整文件集问题 [^3]: 引用[3][4]提供目录操作和权限配置方案
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符  | 博主筛选后可见
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值