案例环境:
今天启动应用程序,程序报错如下:
ExceptionMessage=ORA-01653: 表 HBXNB_CS.BZ29 无法通过 1024 (在表空间 USERS 中) 扩展
ORA-06512: 在 "HBXNB_CS.DBMS_CONTEXT", line 40
ORA-01653: 表 HBXNB_CS.BZ29 无法通过 1024 (在表空间 USERS 中) 扩展
ORA-06512: 在 "HBXNB_CS.DBMS_CONTEXT", line 146
ORA-06512: 在 line 1
解决过程:
1、表空间USERS无法自动扩展,说明磁盘不能分配新的空间,是遇到了操作系统最大文件大小的限制?还是磁盘没有空间了?
当然磁盘没有空间是最常见的情况,快速查看操作系统磁盘空间使用情况。
SQL> !df -h
文件系统 容量 已用 可用 已用% 挂载点
/dev/sda1 31G 30G 42M 100% /
tmpfs 1.9G 0 1.9G 0% /dev/shm
2、OK,磁盘使用已100%,下面的问题就是释放磁盘表空间,先查看表空间的使用情况。
通过继续查看各个表空间,发现很多用户都公用USERS表空间,导致USERS表空间一直处于自动增长状态,这会成为影响数据库性能的瓶颈。
解决这个自动增长问题的最佳思路是,新建表空间,然后把各个用户分别move出去。但由于目前磁盘空间没有,并且exp/imp非常麻烦,采取了最不好的处理方式,收缩别的表空间大小,然后为USERS所用,把问题留到了日后。
3、下面是收缩表空间的处理方式:
SELECT a.file_id,
a.file_name,
a.filesize,
b.freesize,
(a.filesize - b.freesize) usedsize,
c.hwmsize,
c.hwmsize - (a.filesize - b.freesize) unsedsize_belowhwm,
a.filesize - c.hwmsize canshrinksize
FROM (SELECT file_id, file_name, round(bytes / 1024 / 1024) filesize FROM dba_data_files) a,
(SELECT file_id, round(SUM(dfs.bytes) / 1024 / 1024) freesize FROM dba_free_space dfs GROUP BY file_id) b,
(SELECT file_id, round(MAX(block_id) * 8 / 1024) HWMsize FROM dba_extents GROUP BY file_id) c
WHERE a.file_id = b.file_id
AND a.file_id = c.file_id
ORDER BY unsedsize_belowhwm DESC;
5 /opt/oracle/oradata/orcl/HXPT.dbf 10000 5974 4026 6043 2017 3957
3 /opt/oracle/oradata/orcl/sysaux01.dbf 390 8 382 384 2 6
1 /opt/oracle/oradata/orcl/system01.dbf 540 9 531 531 0 9
2 /opt/oracle/oradata/orcl/undotbs01.dbf 1655 1628 27 889 862 766
4 /opt/oracle/oradata/orcl/users01.dbf 7511 3131 4380 7509 3129 2
结果说明:
File_id : 文件编号
File_name: 文件名称
File_size: 数据文件占用磁盘空间大小
Freesize:文件中被标记为free的空间大小
Usedsize: 使用的空间大小。
Hwmsize: 已经分配出去的空间大小,如果希望通过alter database datafile … resize integerM回收空间,将需要这个值作为参考,不能回收到这个值之下,否则会报错。
Freee_belowhwm_size: 在HWM(高水位标记线之下的空闲空间数),这个是理论上的可以回收的空间大小。
Curr_can_shrink: 这个是实际大小与HWM标记之间的差,就是还没有分配出去的空间大小。
Oracle数据库的体系结构包括物理存储结构和逻辑存储结构。由于它们是相分离的,所以在管理数据的物理存储结构时并不会影响对逻辑存储结构的存取
4、SQL> alter database datafile 5 resize 7000M;
数据库已更改。
问题暂时解决。
总结:
DBA需要认真规划数据库,随便导入用户的结果会导致日后的大麻烦
今天启动应用程序,程序报错如下:
ExceptionMessage=ORA-01653: 表 HBXNB_CS.BZ29 无法通过 1024 (在表空间 USERS 中) 扩展
ORA-06512: 在 "HBXNB_CS.DBMS_CONTEXT", line 40
ORA-01653: 表 HBXNB_CS.BZ29 无法通过 1024 (在表空间 USERS 中) 扩展
ORA-06512: 在 "HBXNB_CS.DBMS_CONTEXT", line 146
ORA-06512: 在 line 1
解决过程:
1、表空间USERS无法自动扩展,说明磁盘不能分配新的空间,是遇到了操作系统最大文件大小的限制?还是磁盘没有空间了?
当然磁盘没有空间是最常见的情况,快速查看操作系统磁盘空间使用情况。
SQL> !df -h
文件系统 容量 已用 可用 已用% 挂载点
/dev/sda1 31G 30G 42M 100% /
tmpfs 1.9G 0 1.9G 0% /dev/shm
2、OK,磁盘使用已100%,下面的问题就是释放磁盘表空间,先查看表空间的使用情况。
通过继续查看各个表空间,发现很多用户都公用USERS表空间,导致USERS表空间一直处于自动增长状态,这会成为影响数据库性能的瓶颈。
解决这个自动增长问题的最佳思路是,新建表空间,然后把各个用户分别move出去。但由于目前磁盘空间没有,并且exp/imp非常麻烦,采取了最不好的处理方式,收缩别的表空间大小,然后为USERS所用,把问题留到了日后。
3、下面是收缩表空间的处理方式:
SELECT a.file_id,
a.file_name,
a.filesize,
b.freesize,
(a.filesize - b.freesize) usedsize,
c.hwmsize,
c.hwmsize - (a.filesize - b.freesize) unsedsize_belowhwm,
a.filesize - c.hwmsize canshrinksize
FROM (SELECT file_id, file_name, round(bytes / 1024 / 1024) filesize FROM dba_data_files) a,
(SELECT file_id, round(SUM(dfs.bytes) / 1024 / 1024) freesize FROM dba_free_space dfs GROUP BY file_id) b,
(SELECT file_id, round(MAX(block_id) * 8 / 1024) HWMsize FROM dba_extents GROUP BY file_id) c
WHERE a.file_id = b.file_id
AND a.file_id = c.file_id
ORDER BY unsedsize_belowhwm DESC;
5 /opt/oracle/oradata/orcl/HXPT.dbf 10000 5974 4026 6043 2017 3957
3 /opt/oracle/oradata/orcl/sysaux01.dbf 390 8 382 384 2 6
1 /opt/oracle/oradata/orcl/system01.dbf 540 9 531 531 0 9
2 /opt/oracle/oradata/orcl/undotbs01.dbf 1655 1628 27 889 862 766
4 /opt/oracle/oradata/orcl/users01.dbf 7511 3131 4380 7509 3129 2
结果说明:
File_id : 文件编号
File_name: 文件名称
File_size: 数据文件占用磁盘空间大小
Freesize:文件中被标记为free的空间大小
Usedsize: 使用的空间大小。
Hwmsize: 已经分配出去的空间大小,如果希望通过alter database datafile … resize integerM回收空间,将需要这个值作为参考,不能回收到这个值之下,否则会报错。
Freee_belowhwm_size: 在HWM(高水位标记线之下的空闲空间数),这个是理论上的可以回收的空间大小。
Curr_can_shrink: 这个是实际大小与HWM标记之间的差,就是还没有分配出去的空间大小。
Oracle数据库的体系结构包括物理存储结构和逻辑存储结构。由于它们是相分离的,所以在管理数据的物理存储结构时并不会影响对逻辑存储结构的存取
4、SQL> alter database datafile 5 resize 7000M;
数据库已更改。
问题暂时解决。
总结:
DBA需要认真规划数据库,随便导入用户的结果会导致日后的大麻烦