问题:本人现在要把Oracle的数据同步到MySQL,运用的ETL工具,由于数据量很大,而且有子查询要用到临时表空间,导致原来的该临时表空间,空间不足,根据报错直接想到了给该临时表空间添加临时文件。查看了它原有的临时文件的路径,也没有多想直接在这个路径下添加了一个文件,谁知道该路径空间不足了,还没有把新加的临时文件用完,数据库就down了,原因是redo日志文件也在这个挂载点下,我们知道任何操作都要先写redo,虽然redo是循环复写的,在如果大量产生日志的时候,还没有归档的redo日志文件是不能被复写的,最终由于空间不足,导致数据库down掉。
解决的过程:尝试起库,发现报错,说/shared_data 共享内存空间不足什么的,导致无法审计,直接想到去清理空间,
[oracle@rac1 trace]$ df -Th
文件系统 类型 容量 已用 可用 已用% 挂载点
/dev/sda2 ext3 142G 135G 0 100% /
/dev/sda6 ext3 66G 48G 16G 76% /data
/dev/sda3 ext3 48G 17G 29G 37% /software
/dev/sda1 ext3 190M 14M 167M 8% /boot
tmpfs tmpfs 16G 0 16G 0% /dev/shm
/dev/mapper/mpath2
ext3 2.0T 1.2T 764G 61% /backup
/dev/mapper/oraclep1
ext3 1008G 686G 272G 72% /software/oradata01
rac1:/shared_grid
nfs 142G 135G 0 100% /software/app/11.2.0/grid
rac1:/shared_home
nfs 142G 135G 0 100% /software/app/oracle/product/11.2.0/db_1
rac1:/shared_config
nfs 142G 135G 0 100% /software/shared_config
rac1:/shared_data
nfs 142G 135G 0 100% /software/oradata
none tmpfs 16G 128K 16G 1% /var/lib/xenstored
很显然 挂在点 / 空间被沾满,红色部分,很显然,有可能可以清理的只有 /software/oradata ,以所以在这个路径下找占用空间比较大的文件,
[oracle@rac1 JLPROJCT]$ pwd
/shared_data/JLPROJCT
[oracle@rac1 JLPROJCT]$ ll
总计 79771028
-rw-r----- 1 oracle oinstall 25706496 05-28 22:13 control01.ctl
-rw-r----- 1 oracle oinstall 1536 04-02 13:55 orapwJLPROJCT
-rw-r----- 1 oracle oinstall 2097152512 05-27 21:52 redo01A.log
-rw-r----- 1 oracle oinstall 2097152512 05-27 21:48 redo02A.log
-rw-r----- 1 oracle oinstall 2097152512 05-28 17:47 redo03A.log
-rw-r----- 1 oracle oinstall 2097152512 05-28 17:47 redo04A.log
-rw-r----- 1 oracle oinstall 2097152512 05-28 22:13 redo05A.log
-rw-r----- 1 oracle oinstall 2097152512 05-28 22:12 redo06A.log
-rw-r----- 1 oracle oinstall 2097152512 05-28 17:47 redo07A.log
-rw-r----- 1 oracle oinstall 2097152512 05-28 17:47 redo08A.log
-rw-r----- 1 oracle oinstall 5632 05-27 19:37 spfileJLPROJCT.ora
-rw-r----- 1 oracle oinstall 3330285568 05-28 22:12 sysaux01.dbf
-rw-r----- 1 oracle oinstall 13532930048 05-28 22:12 system01.dbf
-rw-r----- 1 oracle oinstall 34358697984 05-28 11:24 temp01.dbf
-rw-r----- 1 oracle oinstall 8017420288 05-28 22:13 undotbs01.dbf
-rw-r----- 1 oracle oinstall 6121594880 05-28 22:11 undotbs02.dbf
-rw-r----- 1 oracle oinstall 104865792 05-28 17:48 users01.dbf
发现redo的命名规范(有A ),显然是其中的一部分成员,根据redo成员镜像的关系,想到了把这八个成员移动到别的位置(其实不应该这样,应该移动临时文件,因为即便丢失了所有的临时表空间,只要不是数据库当中用到了order by、子查询、group by、distinct等需要消耗临时表空间的语句(而且要比较大才行,小的话就直接用pga的SORT_AREA区了),那么也不会对业务造成错误导致中断,发现问题之后只需要新建一个临时表空间就可以了。你要是了解备份恢复的话,实际上在进行备份的时候临时表空间都不会进行备份,而只是有一个创建临时表空间的语句而已)
腾出空间之后,数据库终于算是起来了。