oracle 5632,Oracle系统默认临时表空间以及redo日志文件问题处理
本人現在要把Oracle的數據同步到MySQL,運用的ETL工具,由于數據量很大,而且有子查詢要用到臨時表空間,導致原來的該臨時表空間
問題:本人現在要把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區了),那么也不會對業務造成錯誤導致中斷,發現問題之后只需要新建一個臨時表空間就可以了。你要是了解備份恢復的話,實際上在進行備份的時候臨時表空間都不會進行備份,而只是有一個創建臨時表空間的語句而已)
騰出空間之后,數據庫終于算是起來了。
但是這顯然是不行的,移動位置,相當于物理層面刪掉了日志組的成員,這樣每個組就只有一個成員了,非常危險.此時在數據庫里查看時,被移動的文件的狀態變成了invalid,
SQL> select GROUP#,STATUS , from v$logfile;
GROUP# STATUS MEMBER
---------- -------
2 invalied /software/oradata/JLPROJCT/redo02A.log
本文原創發布php中文網,轉載請注明出處,感謝您的尊重!
總結
以上是生活随笔為你收集整理的oracle 5632,Oracle系统默认临时表空间以及redo日志文件问题处理的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: oracle 提示i386,新手请教:R
- 下一篇: linux内存占满但是无进程,为什么TO