Oracle表空间限额技术细节

2015-06-28刘伟

铁路计算机应用 2015年1期

关键词：技术细节行数限额

刘伟

（武汉铁路局信息技术处，武汉 430071）

技术与方法

Oracle表空间限额技术细节

刘伟

（武汉铁路局信息技术处，武汉 430071）

针对一例用户表空间限额引起的应用故障，分析Oracle 11g表空间限额的技术细节。

表空间；用户；限额

Oracle 数据库管理员几乎天天都要关心数据库表空间的使用状况，其中包括表空间的使用率以及用户所占表空间限额的情况。本文描述了一例由用户表空间限额引起的应用故障，在处理的过程中，Oracle表空间限额的技术细节逐步呈现出来。

1 故障背景介绍

某日中午 12:45，某铁路信息系统维护人员接到用户的故障报告，称该系统数据不再更新。应用系统维护人员立即排查故障，15 min 后系统自动恢复正常。数日后相同的故障又再次出现，这次故障没有在 15 min 内恢复，应用系统维护人员立即联系Oracle 数据库管理员共同排查故障。

第1步，查看该应用系统的日志文件，发现了报错，如图1所示。

图1 系统日志文件的报错信息

第 2 步，查看该应用的 Oracle 11g 数据库中有哪些用户使用该表空间，发现该表空间的从属对象中包含用户A，但是用户A对该表空间限额却是‘无’。立即更改用户A对该表空间限额为‘无限制’，随后该应用系统恢复正常。

看似很简单的一个问题，但是有两个疑问需要去解决。（1）在创建用户 A 时，使用的是如下语句 :

CREATE USER A IDENTIFIED BY "********" DEFAULT TABLESPACE "X_TS" QUOTA UNLIMITED ON "X_TS" ;

该语句表明已经为用户 A 在表空间 X_TS 限额上赋予了‘无限制’的权限，可是现在为什么查询到的表空间限额却是‘无’？

（2）在第 1 次应用系统报错时，为什么 15 min自动恢复了，而后又再次报错。用户A对该表空间限额是‘无’，为什么系统会自动恢复正常。什么情况下会恢复正常，什么情况下又再次报错？

2 故障分析与验证

针对问题（1），数据库管理人员仔细翻查了数据库的日志文件，发现曾对用户A做过以下操作:

grant connect, resource to A;

revoke unli-mited tablespace from A;

为了发现用户配额的变化，数据库管理人员分别在 Oracle 9i、Oracle 10g、Oracle 11g 3 个实验机上利用创建用户 A 的脚本创建了用户 test，它使用的表空间为 test_ts。这 3 个实验机上，用户 test创建后，显示它对表空间 test_ts 的限额是‘无限制’。在执行“grant connect , resource to test”语句后，3 个实验机都显示用户 test对表空间 test_ts 的限额是‘无限制’，并且它对所有其他表空间限额也是‘无限制’。接下来执行“revoke unlimited tablespace from test”语句后，结果则出现了不同。Oracle 9i、Oracle 10g两台实验机显示用户 test对表空间 test_ts 的限额依然是‘无限制’，而 Oracle 11g 实验机显示用户 test对表空间 test_ts 的限额却是‘无’。

实验表明 Oracle 11g 在用户对表空间限额的处理上发生了变化。revoke 语句收回的不仅仅是ulimited tablespace 权限，连在创建用户时指定的表空间限额也一并收回。Ulimited tablespace 权限是在将 resource 角色赋予用户时，一并赋予用户的；需要指出的是，unlimited tablespace 权限并不包括在resource 角色中。

针对问题（2），数据库管理员查询了数据库日志以及用户A的定时任务，发现发生故障当日的13:00，用户 A 有一个清理表数据的定时任务。清理出来的空间与表空间限额的关系究竟是怎样的，也通过了一个测试来寻找答案。

第 1 步 :在一台 Oracle 11g 的实验机上使用如下语句创建了表空间 test_ts，用户 test，以及用户test下的表 test_table:

第 2 步 :创建一个脚本 insert_test.sql

第 3 步 :在用户 test下执行完脚本 insert_test. sql后，revoke 用户 test的 unlimited tablespace 权限。

第 4 步 :在用户 test下多次执行脚本 insert_test. sql，直到数据库报表空间限额错误。查询此时test_table 的行数。

第 5 步 :执行 truncate table test_table 语句。

第 6 步 :执行 insert into test_table values(1)，查看数据库是否报表空间限额错误。

第7步:若第6步没有报错，则再次执行第4步操作。比对两次记录下的 test_table 行数是否一致。

第 4 步记录表 test_table 的行数为 3 300 行；且用户 test只用了表空间 test_ts 空间的 0.1 %。第 6 步的实验结果显示数据‘1’插入成功，并没有报表空间限额错误。第 7 步记录表 test_table 的行数为 3 300行，用户 test仍然只用了表空间 test_ts 空间的 0.1%。再次执行第 5、6、7 步，记录表 test_table 的行数为 3 300 行，用户 test还是只用了表空间 test_ts空间的 0.1 %。实验数据表明 :在 Oracle 11g 中，当 revoke 了用户的表空间限额后，对于之前用户占有的空间并不收回，同时也不会再分配该用户其他空间。依据这个结论，问题（2）得到了解释 :第 1 次发生故障的 15 min 后，由于清理表数据的定时任务启动，所以用户A可以再次写入新数据，当写满了已分配的数据块，而又无法分配到新的数据块则再次报错。