Oracle - Drop Tablesapce question.

[watermelonyu]

HI,



當我 drop 一個 Oracle Tablespace 並且 rm

該 tablesapce 所屬的 datafile 後發現該

datafile 的 size 並沒歸還給 OS.



check filesystems:



1.使用 du command.

pherpp01:/oracle/PP1/sapdata12#du .

0 ./lost+found

2048032 ./btabi_22

4096032 ./btabd_27

2048032 ./btabi_24

1433632 ./afrud_3

4177952 ./btabd_31

102432 ./poold_10

2048032 ./btabi_26

2048032 ./btabi_27

1024032 ./btabi_28

617120 ./temp_4

2099952 ./roll_1

4096032 ./btabi_23

4096032 ./btabd_29

819232 ./stabd_3

4096032 ./btabi_25

1024032 ./clud_5

35874646 .



PS:35874646/2=17937323KB



2. 使用 bdf 請參考附加檔.



附加檔顯示 filesystem /oracle/PP1/sapdata12

used 21040404 而非 17937323,Why?

[watermelonyu]

Hi,



試一下 df -k 看看結果是否不同?



Best Rgds,



Eric

[watermelonyu]

Hi Eric,



df -k 與 bdf 所得到的 allocate,used,free 相同.



Regards,

[watermelonyu]

你是否曾遇過將一些大的檔案清除之後, 再用 bdf 去看檔案系統使用空間

卻仍然很滿, 空間並未完全釋放出來, 該怎麼辦 ? 例如 :



# bdf

Filesystem kbytes used avail %used Mounted on

/dev/vg00/lvol3 204800 187788 16281 92% /

# du: 82516

=>>> bdf 和 du 指令執行結果相差100MB



這種情形有時候是因為那些被刪除的檔案仍然被系統的 Process 所 open.

一般而言, 當 Process 正常結束後, 檔案系統使用空間應該就會釋放出來了.

現在有一個新的工具叫做 “uli”,可以協助你快點找出來可能是那個系統

Process 仍然一直開啟已經被刪除的檔案. 以下是 “uli” 執行出來的結果 :





Opening /stand/vmunix /dev/kmem



Loading symbols from /stand/vmunix

Found 21 matching unlinked file table entries.



PID PPID COMMAND INODE DEVICE SIZE(bytes)

15894 15613 dtfile 609 /dev/vg00/lvol4 135260

15613 15512 dtfile 609 /dev/vg00/lvol4 135260

240 1 ttsession 104 /dev/vg00/lvol5 867

...

17805 1 ttsession 158 /dev/vg00/lvol5 867

6278 1 oracle 3640 /dev/root 105711881 =>>>

4763 1 sysstat_em 1782 /dev/root 6760

...

555 1 ntl_reader 4581 /dev/vg00/lvol8 230829



我們分析 Process 6278 它所佔用的 /dev/root 空間有 105MB 之大. 再透過 Glance

或 find 指令再分析後, 我們懷疑 Process 6278 有問題, 使用 ”kill –9 6278” 指令

後, 檔案系統使用空間就釋放出來了.

[watermelonyu]

Hi,



其實之前就有類似情況發生,我只要 Shutdown Oracle 後 space 就會 release,但我不希望每次遇到就 restart Oracle.



Regards,

[watermelonyu]

I can successfully execute uli on hpux 11.X



# uli

libp4 (9.12): Opening /stand/vmunix /dev/kmem



Loading symbols from /stand/vmunix

Kernel TEXT pages not requested in crashconf

Will use an artificial mapping from a.out TEXT pages

Loading symbols from /stand/dlkm/mod.d/migattr

Warning: Load vt failed on this module

Warning: Load debug_header failed on this module

Found 4 matching unlinked file table entries.

PID PPID COMMAND INODE DEVICE SIZE(bytes)

11179 1 sh 2843 /dev/root 8628

3655 3654 sh 2843 /dev/root 8628

20104 20103 sh 3686 /dev/root 28476

2031 1 swagentd 15971 /dev/vg00/lvol8 115



I have no idea why it can't be executed on hpux 10.20 ?

[watermelonyu]

這本來就是 Oracle 的特性



Oracle® Database SQL Reference

就提到



When you drop a tablespace, Oracle Database does not place it in the recycle bin. Therefore, you cannot subsequently either purge or undrop the tablespace.

[watermelonyu]

Hi 陳兄,

這並非 Oracle 之特性,並非每次 drop tablesapce 後 sapce 無法 release,若您會 建立 tablespace 您可試著Craete a tablespace 然後在 drop 該 Tablespace,該

datafile 所暫的 sapce 應可收回.

我認為應該是"老鷹"所說的"被刪除的檔案仍然被系統的 Process 所 open".



Best Regards,

[watermelonyu]

Hi 蘇兄,



可否告知你所使用的 Oracle 和 HP-UX 版本?



Best Rgds,



Eric

[watermelonyu]

Hi Eric,



我所負責的很多,有:



OS Oracle

-----------------------

10.20 7.3.4

10.20 8.0.6

11.11 8.0.6

11.11 9.1.7

W2k 8.1.7

W2k 9.2.0.5



並非所有的作業系統與 Oracle 我都有試過,問題是發生在 10.20 + Oracle 7.3.4 但在這個

組合下也有過 drop a tablespace 後 space

有收回的情況,W2K 則有發生過 drop a tablespace 成功(PS:select * from dba_tablespace 該 tablespace 已不存在)但在 W2K level 確不能 delete 該 tablespace 所屬的 datafiles,但HP-UX or W2K 我只要 restart Oracle 問題就可解,故我才認為 Angela 所說的 "有時候是因為那些被刪除的檔案仍然被系統的 Process 所 open"

才是問題所在,現在我把解法擺在"如何找出那個系統 Process 仍然一直開啟已經被刪除的檔案?",只是在 10.20 上我 run uli 有問題.



Thks & Best Regards,

[watermelonyu]

Hi,



靈異事件,請看附加檔.



???????

[watermelonyu]

Hi,

Your reply article can't more than 100 chinese words. I encounter same error message before. And after I reply article with smaller contents. It is successful.

Regards,

[watermelonyu]

嗯嗯,我已經將這個問題 feedback 給開發系統的人員了,有任何 update 再告訴大家

[watermelonyu]

pherpp01:/#./uli.bin

x ./uli-a-1, 994023 bytes, 1942 tape blocks

x ./uli.install, 536 bytes, 2 tape blocks

[watermelonyu]

Hi 老鷹,

Try it.

打開我的附加檔然後"全選"-->"複製".

接下來"回覆文章" --> "貼上" 然後按

"送出".



好像不是中文超過 100 的問題喔!



Regrads,

[watermelonyu]

剛剛試過了......

直接複製貼上，會出現同樣的錯誤訊息。

我想應該是內容有描述到某個指令有關：

A potentially dangerous Request.Form value was detected from the client (textBoxMessage="...").



系統發現可能有危險的敘述......

[watermelonyu]

Let me check whether the uli support on hp-ux 10.20 ? Tks.

[watermelonyu]

Hi,



I find the "uli" tool owner. And I get the uli for 10.20 now. Pls download attachedment. Tks.

[watermelonyu]

Hi 老鷹,

謝謝,但仍有問題



pherpp01:/#./uli



libp4 (9.36): Opening /stand/vmunix /dev/kmem



'v_op' is not a member of 'vnode_t'

libp4 exiting...



Error Message 跟上個 uli 版本不一樣.



Thks & Best Regards,

[watermelonyu]

Hi,



I can successfully use this uli version to execute on my hpux 10.20 system now. I guess there are some library which version are not compatible with uli's.

Regards,

[watermelonyu]

Hi,



Pls check whether the new uli same as below :

$ sum uli

27228 1918 uli

$ file uli

uli: PA-RISC1.1 shared executable dynamically linked

[watermelonyu]

Hi 老鷹,

相同.



pherpp01:/#./uli



libp4 (9.36): Opening /stand/vmunix /dev/kmem



'v_op' is not a member of 'vnode_t'

libp4 exiting...

pherpp01:/#sum uli

27228 1918 uli

pherpp01:/#file uli

uli:PA-RISC1.1 shared executable dynamically linked

pherpp01:/#





Regards,

[watermelonyu]

Hi,



I think your system patch level is older than mine. Pls try to download another uli version. Thanks a lot.

[watermelonyu]

Hi,



This is uli update version from the developer.Pls try it. Tks.

Regards,

[watermelonyu]

Hi 老鷹,



1. Update 版的 uli 可用了.

2. 跟據您的方法找出及 kill 掉 hold 住

datafiles 的 processes,現將近 3GB

的空間已 release 出來.



真的非常非常非常的感謝您.



Thks & Best Regards,