ORA-01536: space quota exceeded for tablespace 错误的深入分析

今天在用户kf下面删除一条数据时:
delete from kf_gongnengtx where texingid=2736;


报错:
ORA-01536: space quota exceeded for tablespace 'TS_HIS3'

 

根据网上资料,该问题是由于用户在使用表空间时候受到了权限的限制.
解决方案很简单,修改这个用户的使用这个表空间的空间的权限就可以了

 

oracle提供二种方法:
1. Increase the tablespace quota allocated to that user or role by using the following command(即增加具体的大小限额):
ALTER USER <username> QUOTA <integer> [K/M] ON <tablespacename>

2. suggest QUOTA UNLIMITED(即去掉配额限制,unlimited,推荐使用这种,否则当第一个方法用后,如果再不够,那岂不是要再进行分配限额!):
ALTER USER <username> QUOTA UNLIMITED ON <tablespacename>

方法2的另外一种写法:
grant unlimited tablespace to <username>;

 

于是在sqlplus下面以sysdba权限登陆操作:
SQL> grant unlimited tablespace to kf;

Grant succeeded.

SQL> delete from kf_gongnengtx where texingid=2736;

1 row deleted

操作成功,问题解决!

 

本来到这里也告一段落,结果在一篇文章上面(http://www.dbasupport.com/forums/archive/index.php/t-47410.html)发现产生这个问题可能与role是DBA和RESOURCE被revoke有关,

 

里面有一段关键的话:

UNLIMITED TABLESPACE is kind of "wierd" system privilege. It is not granted to any role (and in fact it CAN NOT BE GRANTED to any role!), yet when you grant some powerfull roles (like DBA and I think RESOURCE too - it might even be version dependand AFAIK) to user, Oracle "silently" adds that UNLIMITED TABLESPACE privilege to that user directly. And when you revoke such role from user, Oracle silently revokes UNLIMITED TABLESPACE privilege from user too!

Now, when someone gets UNLIMITED TABLESPACE granted, it doesn't meen taht quotas on all tablespaces are set to unlimited to him. His quotas on tablespaces remain exactly the same - if he had quota 0 on tablespace USERS before, he still has quota 0 on that tablespace now. But when he has UNLIMITED TABLESPACE privilege, this takes priority over any quota settings and therefore he will be able to use space in that tablespace for new extents. However, if you later revoke UNLIMITED TABLESPACE from that user, his quota 0 will be put in effect and he will no longer be able to use any additional available space from tablespace USERS.

 

继续深入:
在metalink上面找到ORA-01536 After Revoking DBA Role [ID 465737.1]的文档,原来grant 或者revoke role DBA 或者 RESOURCE会导致该问题,然后我做了metalink上面的实验,果然如此,当你revoke DBA from <username>或者revoke resource from <username>时,如果空间不够,就会产生该问题

 

下面是相关描述:

ORA-01536: space quota exceeded for tablespace '<Tablespace_Name>'
After revoking DBA or Resource Role from a user

Example:

SQL> conn /as sysdba
Connected.
SQL> create user testrights identified by testos;
User created.
SQL> grant connect, resource to testrights;
Grant succeeded.
SQL> connect testrights/testos;
Connected.

SQL> CREATE TABLE "TESTRIGHTS"."TESTTAB" ( "TESTFIELD" VARCHAR2(200) NOT NULL
, CONSTRAINT "TESTPK" PRIMARY KEY ("TESTFIELD") VALIDATE ) TABLESPACE "USERS" STORAGE ( INITIAL 64M) ;
Table created.

SQL> conn /as sysdba
Connected.
SQL> grant dba to testrights;
Grant succeeded.
SQL> revoke dba from testrights;
Revoke succeeded.
SQL> show user
USER is "SYS"
SQL> drop table testrights.testtab;
Table dropped.
SQL> conn testrights/testos;
Connected.
SQL> CREATE TABLE "TESTRIGHTS"."TESTTAB" ( "TESTFIELD" VARCHAR2(200) NOT NULL
, CONSTRAINT "TESTPK" PRIMARY KEY ("TESTFIELD") VALIDATE ) TABLESPACE "USERS"  STORAGE ( INITIAL 64M) ;

CREATE TABLE "TESTRIGHTS"."TESTTAB" ( "TESTFIELD" VARCHAR2(200) NOT NULL ,
CONSTRAINT "TESTPK" PRIMARY KEY ("TESTFIELD") VALIDATE ) TABLESPACE "USERS"
 STORAGE ( INITIAL 64M)
*
ERROR at line 1:
ORA-1536: space quota exceeded for tablespace 'USERS'

SQL> conn /as sysdba
Connected.
SQL> grant connect, resource to testrights;
Grant succeeded.

SQL> conn testrights/testos;
Connected.
SQL>
SQL> CREATE TABLE "TESTRIGHTS"."TESTTAB" ( "TESTFIELD" VARCHAR2(200) NOT NULL , CONSTRAINT "TESTPK" PRIMARY KEY ("TESTFIELD") VALIDATE ) TABLESPACE "USERS"
STORAGE ( INITIAL 64M) ;

Table created.

 

Cause

This issue has been discussed in Bug 6494010.
The behavior seen in the above example is expected and not a bug

When roles were first introduced into Oracle in 7.0, the old Oracle V6 privileges of  RESOURCE and DBA were migrated to use the new role functionality. But because  the RESOURCE and DBA roles are not allowed to be granted UNLIMITED  TABLESPACE, in order to preserve the backwards compatibility with V6, the  parser automatically transforms statements such that "grant resource to abc" automatically becomes "grant resource, unlimited tablespace to abc" and  "revoke resource from abc" automatically becomes "revoke resource, unlimited  tablespace from abc". The same is true when granting and revoking the DBA  role. This behaviour used to be well documented in the SQL reference guide which read:


Note: If you grant or revoke the RESOURCE or DBA role to or from a  user, Oracle implicitly grants or revokes the UNLIMITED TABLESPACE system privilege to or from the user.

 

Solution

To Resolve this issue you need to :

1] Grant DBA or Resource Role back to the user from whom it was revoked.

 

 

 

<think>好的,我现在需要解决用户遇到的Oracle数据库错误,主要是ORA-01031权限不足和ORA-06512在DBMS_SNAPSHOT包中的问题。首先,我需要回顾用户提供的引用内容,看看有没有相关的线索。 根据引用[1]和[2],用户在执行DBMS_MVIEW.REFRESH时遇到了ORA-01031错误,这说明当前用户没有足够的权限来刷新物化视图。ORA-06512指出了错误发生的位置,具体是在DBMS_SNAPSHOT包的某个行数。这可能意味着用户需要被授予特定的系统权限,比如CREATE MATERIALIZED VIEW或者ALTER ANY MATERIALIZED VIEW。另外,可能还需要检查物化视图所属用户的权限,确保有权限访问基表。 接下来,引用[3]提到了JOB异常和ORA-06512,可能与权限或存储过程有关。引用[4]涉及到数据泵的问题,但当前用户的问题主要集中在物化视图刷新上,所以暂时可以忽略数据泵相关的错误。 首先,我会建议用户检查当前执行刷新操作的用户是否具有必要的权限。可能需要授予CREATE MATERIALIZED VIEW或者更具体的权限,比如在物化视图上的SELECT权限。此外,如果物化视图属于另一个用户(如user_a),则需要确保当前用户有权限访问该物化视图,并且基表的SELECT权限也被正确授予。 另外,用户可能需要直接授予EXECUTE权限在DBMS_SNAPSHOT或DBMS_MVIEW包上,因为有时候即使有系统权限,如果没有包的执行权限,也会导致问题。例如,执行DBMS_MVIEW.REFRESH可能需要EXECUTE ON DBMS_MVIEW。 然后,检查物化视图的定义,确认基表的权限是否正确。如果基表属于其他用户,可能需要通过角色授予权限,但Oracle在存储过程中有时不继承角色权限,所以最好直接授予给用户。 还有可能需要检查是否在创建物化视图时使用了QUERY REWRITE权限,特别是如果物化视图用于查询重写的话。此外,检查用户是否有足够的表空间配额,避免因为空间不足导致错误,但这里的主要错误是权限问题,所以配额可能不是主要原因。 如果用户被授予了必要的权限,但仍然遇到问题,可能需要检查是否存在同义词问题,或者物化视图的依赖对象是否有权限问题。例如,物化视图可能引用了其他用户的表、视图或函数,这些都需要显式授权。 总结步骤应该是:授予系统权限、授予对象权限、检查包的执行权限、验证基表权限、检查角色权限的继承问题,最后考虑其他可能的原因,比如存储过程权限或环境配置。 最后,生成相关问题,帮助用户进一步排查其他可能的错误,比如角色权限的问题、如何查看现有权限、处理存储过程中的权限问题等。</think>### 解决方案:ORA-01031权限不足与ORA-06512错误处理 #### 1. 检查系统权限 **问题根源**:执行`DBMS_MVIEW.REFRESH`或操作物化视图时,用户需具备以下权限: - `CREATE MATERIALIZED VIEW`:创建/刷新物化视图的权限 - `ALTER ANY MATERIALIZED VIEW`:修改其他用户的物化视图权限 - `SELECT`权限:访问基表的权限[^1][^2] **操作步骤**: ```sql -- 以SYSDBA身份登录后执行 GRANT CREATE MATERIALIZED VIEW TO user_a; GRANT ALTER ANY MATERIALIZED VIEW TO user_a; GRANT SELECT ON base_table TO user_a; -- 替换为实际基表名 ``` #### 2. 验证包执行权限 **问题根源**:若用户缺少`DBMS_SNAPSHOT`或`DBMS_MVIEW`包的`EXECUTE`权限,会触发ORA-01031错误。 **操作步骤**: ```sql GRANT EXECUTE ON SYS.DBMS_SNAPSHOT TO user_a; GRANT EXECUTE ON SYS.DBMS_MVIEW TO user_a; ``` #### 3. 检查对象所有权 **问题根源**:若物化视图属于其他用户,需显式授予权限: ```sql -- 以物化视图所有者身份执行 GRANT SELECT ON mv_demo TO user_a; -- 替换为实际物化视图名 ``` #### 4. 处理角色权限问题 **问题根源**:Oracle存储过程不继承角色权限,需直接授予用户。 **验证方法**: ```sql -- 查看用户权限 SELECT * FROM USER_SYS_PRIVS; SELECT * FROM USER_TAB_PRIVS; ``` #### 5. 其他可能原因 - **QUERY REWRITE权限**:若物化视图用于查询重写,需授予`QUERY REWRITE`权限: ```sql GRANT QUERY REWRITE TO user_a; ``` - **表空间配额**:确保用户有足够空间配额: ```sql ALTER USER user_a QUOTA UNLIMITED ON tablespace_name; ``` --- ###
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值