记一次测试数据库炸了,周五放假回家数据库还是好好的,周一过来登录数据库就直接报这个错误,看的我一脸懵逼。
之前没遇到过这个问题,个人当时推测是数据库挂了,,然后就去找百度爸爸了~不得不说,百度真实个好东西,,废话不多说了,上真家伙了,
我当时查询了一下,发现出现这个问题的原因是由于表空间不足导致的,百度上面有着一堆的sql去扩大表空间的大小,但是,我现在连PL/SQL都登不上去,,怎么写sql去扩大表空间大小啊~~~
然后我就想想了,好像可以直接在服务器上面输入sql,然后我登录了我们安装oracle的服务器,
发现,,咋sysdba用户都登录不上去了,,
然后又百度了一下这个问题,发现是数据库变量ORACLE_SID没有设置,然后,在登录前设置一下就行了,切记,要先切换到oracle用户哦~
然后就登录进去了。登录进去之后,就查询对应表空间,
select
a.tablespace_name
as
"表空间名"
,
a.bytes / 1024 / 1024
as
"表空间大小(M)"
,
(a.bytes - b.bytes) / 1024 / 1024
as
"已使用空间(M)"
,
b.bytes / 1024 / 1024
"空闲空间(M)"
,
round(((a.bytes - b.bytes) / a.bytes) * 100, 2)
"使用比"
from
(
select
tablespace_name,
sum
(bytes) bytes
from
dba_data_files
group
by
tablespace_name) a,
(
select
tablespace_name,
sum
(bytes) bytes,
max
(bytes) largest
from
dba_free_space
group
by
tablespace_name) b
where
a.tablespace_name = b.tablespace_name
order
by
((a.bytes - b.bytes) / a.bytes)
desc
;
然后看对应的表空间的大小以及使用比等等,
当时一看就知道是这个SYSTEM表空间出的问题,因为使用占比已达到98%多,所以,想都不用想,肯定是这个表空间了,然后,查询一下表空间在服务器上的路径
select
tablespace_name,
file_id,
file_name as
"表空间所在路径"
,
round(bytes / (1024 * 1024), 0) total_space
from
dba_data_files
order
by
tablespace_name
查询了一下,知道我服务器上表空间对应路径是/oradata/QYPT/system.dbf
然后就可以直接用扩大表空间的sql,直接扩大表空间大小
记得当时直接写了这个sql,alter database datafile '/oradata/QYPT/system.dbf' resize 300M;当时我以为是直接在原来的基础大小上直接加300M,但是报了这个错误,我就知道,这个resize,应该是修改之后大小,因为我上面这个表空间的大小已经是2000M多了,所以改成300M肯定会报这个错误的
于是我就直接alter database datafile '/oradata/QYPT/system.dbf' resize 3000M;
然后数据库又可以登录
表空间有个自动增长机制,我也给它加上了,具体是否生效的话,还有待校验
ALTER DATABASE DATAFILE '/oradata/QYPT/system.dbf' AUTOEXTEND ON;//打开自动增长
ALTER DATABASE DATAFILE '/oradata/QYPT/system.dbf' AUTOEXTEND ON NEXT 200M ;//每次自动增长200m
另外看了别人的博客,也分析的挺好的,也摘抄下来
oracle表空间不足,一般有两个原因:一,原表空间太小,没有自增长;二,表空间已自增长,而且表空间也已足够大,对于这两种原因分别有各自的解决办法。
可以看出来,这边我遇到的情况是第一种,第二种的话,解决方法也配上来
【解决办法-原因二】
因为表空间中的数据文件已经足够大(达到32G),所以,这时仅仅增加表空间大小是不行的。
这个时候,我们可以增加该表空间的数据文件,这样表空间的大小即变为64G了。
ALTER TABLESPACE aaa
ADD DATAFILE 'E:\APP\ORACLE11GR2\ORADATA\ORCL\aaa_DATA02.DBF'
SIZE 32767M;
解决了问题之后,心情不错,特写此博客,以来记录