一個簡單的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的空間是有些捉襟見肘了。需要進一步擴容。當然更多的資料庫相關的工作我還是樂于支援的。從這個看起來非常不經意的案例中，我們發現很多問題其實早就産生在了萌芽之中，如果不重視，就會逐漸擴大影響，如果在這個期間出現了嚴重的問題，那就很可能是不可恢複的災難，從這也可以窺探出如果管理不夠專業和規範，很容易出現各種奇怪的問題，問題要扼殺在搖籃之中。