ora-01653: unable to extend table sys.aud$ by 8192 in tablespac system

ora-01653: unable to extend table sys.aud$ by 8192 in tablespac system[转载].

在用sqlplus user/[email protected]登录数据库时报如下错误:
ORA-00604: error occurred at recursive SQL level 1
ORA-01653: unable to extend table SYS.AUD$ by 8192 in tablespace SYSTEM
ORA-02002: error while writing to audit trail
ORA-00604: error occurred at recursive SQL level 1
ORA-01653: unable to extend table SYS.AUD$ by 8192 in tablespace SYSTEM
ORA-00604: error occurred at recursive SQL level 1的错误指的是 内部的SQL语句执行失败
ORA-01653: unable to extend table SYS.AUD$ by 8192 in tablespace SYSTEM 意思是表空间已满
 以sqlplus / as sysdba 登录数据库
首先用下列SQL语句查看表空间的使用情况
select tablespace_name,(bytes/1024/1024) M from dba_data_files;
2种方法处理表空间已满。
(1)更改system表空间的数据文件SYSTEM.dbf分配空间
alter database datafile ‘/u04/oradata/truth/system01.dbf‘ resize 5524M;
(2)为system表空间另外新增一个数据文件
(3)把system表空间中的表移到非系统表空间
检查下是否有其他非系统表放在系统表空间下,
要是有的话,可以移到非系统表空间
alter table move tablespace tablespace_name

Oracle 11g缺省安装数据库启动了audit功能,导致oracle不断累积sys.aud$表及相关索引数据量增加;
如果导致表空间满了,在alert日志中将会报ORA-1654: unable to extend index SYS....错误。
如果不用到审计功能,建议关闭审计。
处理过程:
1、用oracle用户登录到数据库服务器,执行:
sqlplus / as sysdba
2、取消audit,将初始化参数audit_trail设置为NONE
alter system set audit_trail=none scope=spfile;
3、然后重启数据库.
shutdown immediate;
sqlplus / as sysdba
startup;
4、删除审计数据,oracle用户登录到数据库服务器:
sqlplus / as sysdba
truncate table SYS.AUD$;

时间: 2024-10-14 09:42:08

ora-01653: unable to extend table sys.aud$ by 8192 in tablespac system的相关文章

ORA-1653: unable to extend table SYS.AUD$

今早运维组的同事反映有个系统功能很多地方都报错,怀疑是不是数据库有什么问题.于是登录数据库检查,通过crsctl status res -t检查,发现所有集群资源都是OK的,没有哪个资源挂掉了.于是到bdump目录下去检查alter日志文件,发现出现大量的异常日志:ORA-1653: unable to extend table SYS.AUD$.糟糕,SYSTEM估计已经满了.通过语句检查表空间使用率,发现SYSTEM表空间的数据文件已经自增长到了30G,而其中AUD$表就占用了29G,并且无

ORA-1652: unable to extend temp segment by 128 in tablespace xxx Troubleshootin

当收到告警信息ORA-01652: unable to extend temp segment by 128 in tablespace xxxx 时,如何Troubleshooting ORA-1652这样的问题呢? 当然一般xxx是临时表空间,也有可能是用户表空间. 我们先来模拟一下这个情况,在两个会话窗口执行下面SQL语句,这个视图比较特殊(因为比较懒,不想去构造一个大量消耗临时段的SQL,便使用手头的一个案例脚本),它里面有一个DISTINCT操作会消耗TEMP表空间中大量的临时段 SQ

ORA-01652: unable to extend temp segment by 128 in tablespace TEMP

解决办法   --创建中转临时表空间    2.create  temporary   tablespace  TEMP02  TEMPFILE  '/u01/app/oracle/oradata/perm/temp02.dbf'  SIZE 1024M  REUSE  AUTOEXTEND  ON  NEXT  640K  MAXSIZE  UNLIMITED;   --改变缺省临时表空间   为刚刚创建的新临时表空间temp02   3.alter  database  default  t

ORA-01652: unable to extend temp segment by 128 in tablespace TEMP01

收集数据库信息时候报ORA-01652错 如下 SQL> EXEC DBMS_STATS.gather_database_stats; BEGIN DBMS_STATS.gather_database_stats; END; * ERROR at line 1: ORA-01652: unable to extend temp segment by 128 in tablespace TEMP01 ORA-06512: at "SYS.DBMS_STATS", line 1321

Oracle unable to extend temp segment by 128 in tablespace TEMP

Description Error report: SQL Error: ORA-12801: error signaled in parallel query server P010 ORA-01652: unable to extend temp segment by 128 in tablespace TEMP 12801. 00000 - "error signaled in parallel query server %s" *Cause: A parallel query

ORACLE 11g ORA-20000: Unable to analyze TABLE "AA"."CMP3$87651", insufficient privileges or does not exist

Sat Sep 21 06:00:00 2019Begin automatic SQL Tuning Advisor run for special tuning task "SYS_AUTO_SQL_TUNING_TASK"End automatic SQL Tuning Advisor run for special tuning task "SYS_AUTO_SQL_TUNING_TASK"Sat Sep 21 22:01:51 2019DBMS_STATS:

Oracle连接出错(一)

1.错误描述 java.sql.SQLException: ORA-0064:error occurred at recursive SQL level 1. ORA-06153:unable to extend table SYS.AUD$ by 8192 in tablespace SYSTEM. ORA-02002:error while writing to audit trail. ORA-00604:error occurred at recursive SQL level 1. O

users表空间满导致应用无法连接

应用报无法连接 alert: ORA-1653: unable to extend table SYS.AUD$ by 8192 in                 tablespace USERS SYS.AUD$  审计使用的表 11gr2版本,oracle把参数audit_trail 自动设置为DB级别,导致很多数据库的操作被记录在审计表sys.aud$中,导致sys.aud$所在的表空间快速增长.可以通过TRUNCATE清空改表,同时,为了system表空间的安全,建议把改表转移至别的

Oracle的awr和ash

1.     10g之前 用户的连接将产生会话,当前会话记录保存在v$session中:处于等待状态的会话会被复制一份放在v$session_wait中.当该连接断开后,其原来的连接信息在v$session和v$session_wait中就会被删除.这是10g之前的状况. 2.     v$session_wait_history与ASH 若是一个普通的会话(我是指没有大量地耗费资源),则对于性能调整来说无足轻重.但若该会话在活动时大量占用了资源(比如:CPU,内存,I/O等),该会话信息的丢失