一個簡單的bigfile tablespace無法擴充套件的案例處理

最近幫助開發的同學處理了一個簡單的問題，想透過這個問題來反思一下。
    在一天下午的時候，開發的同事突然找到我說，有一個開發的資料庫貌似有些表空間的問題，儘管這個資料庫是劃分在他們名下，但是對於資料庫的操作他們還是沒底，想讓我幫忙看看，當然對於這類問題，我都腦海裡閃現一兩分鐘搞定問題的成就感了。剛好下午有些事情，就叫了另外一個新同事去練練手，但是過了一會兒，新同事給我打來了電話，說現在好像有些問題，目前他們的庫使用的是bigfile tablespace,對於這類表空間，新增資料檔案是不行的，然後他嘗試了resize竟然也不成功。我腦海裡搜尋關於bigfile的內容，沒有搜尋到相關的太多資訊，實際工作中這個特性真只是一個特性而已，實踐意義應該不大，難得開發的同學這麼時髦，竟然用了這個特性。
   於是我叫新同事去看看是不是哪裡的操作不對，如果實在不行，看看作業系統級是不是沒有空間了，他反饋說開發的同學目前還沒有許可權登入作業系統，他們目前使用的是客戶端工具連線。對於這類問題，看起來情況似乎已經非常明顯了，但是好像又好像探不到底。於是我建議他，這類空間的，如果實在resize不了，可以再新建一個表空間，把使用者的預設表空間改到這個新的表空間應該就可以了。新同事忙活了一會，看起來還是沒有起色。在忙完手頭的工作之後，我就到開發的同學那裡去看看真偽。
    到了現場之後，發現這位同事已經嘗試了不少的方法。簡單瞭解了問題的前因後果，發現這確實是一個使用了bigfile tablespace的庫，資料檔案目前已經有50G，開發的同學在呼叫一個儲存過程的時候會丟擲空間不足的ORA錯誤。而且新同事已經建立了一個新的表空間，目前先分配了50M的空間，但是執行這個儲存過程還是報錯。
為了排除各種影響，我們就一個一個來分析。首先是這個bigfile tablespace的問題，既然丟擲了空間不足的錯誤，怎麼使用resize的時候會有問題呢，這類表空間裡面只對應一個資料檔案，檔案可以無限膨脹，達到TB級別都是很容易支援的。對於一個只有50G的資料檔案而言，是在是太小兒科了。而同事在同一個目錄下面建立了一個表空間，足以說明這個目錄下面還是有空間的。所以這個現象就比較奇怪，我再次確認，他使用的命令情況，他是使用resize嘗試把資料檔案調到100G,50G到100G裡面還是有太多的變數，於是我就保守了一下，調到了60G，稍等一會之後，從客戶端看命令就執行成功了。從這一點來看，就可以反推出來，這個問題應該不是bug導致，而是由於作業系統的空間剩餘在50G以內，導致resize 為100G的時候出錯。首先這個問題確認了，問題就解決了一大半，開發同學再次嘗試這個儲存過程，發現就沒有任何錯誤了，可見問題的解決已經告一段落，那麼我們來解釋另外幾個問題。
   問題1:對於bigfile tablespace的表空間，預設都是開啟了自動擴充套件的，為什麼這個表空間到了50G就出問題了呢？
   問題2：另外一個問題是對於新增的表空間，為什麼執行儲存過程依舊報錯。
   問題3：最後一個問題是這個問題後續改怎麼改進。
對於第一個問題，自己也著實有些糾結，不過檢視一些資訊就會明白了。首先表空間CYTJ是一個bigfile tablespace,其它的表空間都是smallfile tablespace.
SQL> select tablespace_name,next_extent,bigfile from dba_tablespaces;
TABLESPACE_NAME                NEXT_EXTENT BIG
------------------------------ ----------- ---
CYTJ_DATA                                  YES
TEMP_DATA                          1048576 NO
CYTJ_DATA01                                NO
對於這個表空間而言，可以透過檢視資料檔案的資料字典來檢視maxsize了。可以看到目前是61440M。可見這個表空間在建立開始就是指定了50G的maxsize.
SQL>select tablespace_name,file_name,bytes/1024/1024 size_MB,bytes/1024/1024 max_size_MB from dba_data_files
TABLESPACE_NAME      FILE_NAME                                             SIZE_MB MAX_SIZE_MB
-------------------- -------------------------------------------------- ---------- -----------
USERS                /U01/app/oracle/oradata/cytj/users01.dbf                    5           5
CYTJ_DATA            /home/oracle/tablespace/cytj_data.dbf                   61440       61440
CYTJ_DATA01          /home/oracle/tablespace/cytj_data01.dbf                    50          50
當然要看到更多的資訊，還是登陸到資料庫端去檢視日誌了，然後讓開發同事繼續協調，他們連進了作業系統，使用df -h一下子就可以看出來確實是檔案系統的空間不足，目前只剩下5G左右的空間了，而從資料庫日誌裡面，可以赫然發現，這個表空間在很早的時候就建立了。
create bigfile tablespace cytj_data
logging
datafile '/home/oracle/tablespace/cytj_data.dbf'
size 10G
autoextend on
next 200m maxsize 50G
extent management local
Wed Nov 26 11:45:15 2014
Completed: create bigfile tablespace cytj_data
有了這些一切都明瞭了。
對於問題2：
為什麼新增了表空間之後，執行儲存過程依舊報錯，這個經過排查發現，同事對裡面的使用者都指定了新的表空間為more表空間，唯獨漏了當前使用者，這個也算是操作不夠謹慎，所以給開發的同事簡單建立一個表驗證一下，就很清晰了。
第3個問題。這個問題後續的改進。
可以從資料庫日誌看出。這個問題其實已經發生很久了。
但是直到最近才被開發的同學重視起來，可能有一些功能缺失需要，產生了很大的影響，所以才被重視了起來，如果細細扒開來看，這個問題發生了已經快半年了。
Thu Mar 03 15:43:34 2016
ORA-1653: unable to extend table REPORTS.CLIENTSTATDATA_REAL by 128 in                 tablespace CYTJ_DATA
ORA-1653: unable to extend table REPORTS.CLIENTSTATDATA_REAL by 1024 in                 tablespace CYTJ_DATA
但是明白了問題之後，發現其實都是很簡單，從目前他們使用資料的情況來看短期內不會出現問題，但是從長遠考慮，目前的硬碟配置有些低了，只剩餘5G的空間是有些捉襟見肘了。需要進一步擴容。當然更多的資料庫相關的工作我還是樂於支援的。從這個看起來非常不經意的案例中，我們發現很多問題其實早就產生在了萌芽之中，如果不重視，就會逐步擴大影響，如果在這個期間出現了嚴重的問題，那就很可能是不可恢復的災難，從這也可以窺探出如果管理不夠專業和規範，很容易出現各種奇怪的問題，問題要扼殺在搖籃之中。