国产xxxx99真实实拍_久久不雅视频_高清韩国a级特黄毛片_嗯老师别我我受不了了小说

資訊專欄INFORMATION COLUMN

疑難診斷之指定表空間添加分區(qū)報錯

IT那活兒 / 2747人閱讀
疑難診斷之指定表空間添加分區(qū)報錯

上班屁股剛挨到凳子,就聽早班的同事在嘟嘟囔囔,根據(jù)哥對這個貨的了解,大概率碰到什么問題了。


湊近一看,原來一個測試庫在添加分區(qū)時指定表空間后報表空間不存在,哥的第一反應是不是這二貨昨晚和老婆滾床單滾的有點五行缺腎,把表空間名字寫錯了。


我自己反復確認后發(fā)現(xiàn),SQL語法沒錯,表空間沒問題。那為啥子會報錯呢,真的是遇到錘子了。


其中詭異的是表空間指定的是TBS_005,但報錯報的是表空間TBS_001不存在。


但有一個共同的特點是有LOB字段的表都無法創(chuàng)建到新的表空間。


搞到這里,莫名有種擠壓感,這問題貌似有點嚴重啊,分區(qū)創(chuàng)建不了,后續(xù)數(shù)據(jù)插不進來,到時候就是菊花滿地飄,雞飛狗跳了。


所以抓緊投入到問題診斷解決中。為了讓大家都知道發(fā)生了啥,截個報錯截圖:



作為一個偽專家,上來咱得先收集下相關trace不。于是ora-00959的error stack的走起,看看能不能發(fā)現(xiàn)什么幺蛾子:

alter session set tracefile_identifier=959;

alter session set events 959 trace name errorstack level 3;

alter table OUSP.T_TD add partition P20190402 values(20190402) compress for query high tablespace TBS_005

lob(BY_DISTNC_NAME,BY_GPRS_NAME) store as (tablespace TBS_005);

alter session set events 959 trace name errorstack off;


Trace日志截圖如下:


然鵝,并沒有發(fā)現(xiàn)啥有指向性的線索。。。


平復一下思緒,回到剛才的問題點,明明指定的表空間是TBS_005,為啥報TBS_001不存在?


哦!腦子在高速旋轉(zhuǎn)的過程中,突然想起來前段時間這個測試庫的表空間因為前期規(guī)劃不合理,為了規(guī)范簡約化運維,做過表空間數(shù)據(jù)遷移,并刪除了一部分表空間,TBS_001就是那批刪除表空間中的一個。


但當時做數(shù)據(jù)遷移時我們把所有對象都遷移至其他表空間,確認無誤后才刪除的TBS_001,并且整個刪除過程正常,無任何操作報錯+日志報錯。


既然TBS_001都變成灰,消戶了,那為啥子在添加分區(qū)的時候還報它的信息,想到這里感覺頭皮發(fā)麻。


這種麻觫感下,順其自然的想到還有什么跟這個表空間有關系,并且還是在添加分區(qū)的情況下?


難道是表的默認表空間是TBS_001?也沒道理啊,我都指定了其他表空間。


先查下表的默認表空間,截圖如下:



嘗試更改默認表空間:

ALTER TABLE OUSP.T_TD MODIFY DEFAULT ATTRIBUTES TABLESPACE TBS_005;


卵還是沒起到作用,添加分區(qū)時報錯依舊。


那還有什么對象和表空間相關?腦子想到這里,順口說了出來,只見單身20多年的這個哥們已經(jīng)把索引分區(qū)的默認表空間打出來了,截圖如下:


發(fā)現(xiàn)索引及LOB的默認表空間都是TBS_001。


嘗試修改LOB索引的默認表空間,截圖如下:

從報錯來看lob index不能修改,那就修改下LOB的默認表空間。

alter table OUSP.T_TD modify default attributes lob (SYS_LOB0000063498C00043$$) (tablespace TBS_005);

alter table OUSP.T_TD modify default attributes lob (SYS_LOB0000063498C00043$$) (tablespace TBS_005);


更改LOB默認表空間之后,分區(qū)可以正常添加了。


到這里這個疑難雜癥已經(jīng)一目了然了。


經(jīng)驗總結(jié):

涉及LOB表在遷移表空間時,除了要修改表的默認表空間,LOB的默認表空間也要根據(jù)具體情況考慮是否對應予以修改掉。


這里可以深入思考一下:為啥LOB默認表空間已經(jīng)不存在,數(shù)據(jù)還能插入,且不報錯?

文章版權歸作者所有,未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。

轉(zhuǎn)載請注明本文地址:http://specialneedsforspecialkids.com/yun/130235.html

相關文章

  • DBASK問答集萃(2)

    摘要:新晉技術專家下面是墨天輪部分新晉的技術專家。大家可以點擊往期閱讀墨天輪技術專家邀請函了解詳情,申請成為我們的技術專家,加入專家團隊,與我們一起創(chuàng)建一個開放互助的數(shù)據(jù)庫技術社區(qū)。新關聯(lián)公眾號墨天輪是一個開放互助的數(shù)據(jù)庫技術社區(qū)。 引言 近期我們在DBASK小程序增加了數(shù)據(jù)庫 MongoDB、Redis、 Elasticsearch、DB2、Weblogic 等新的的專題欄目和一些新的技術...

    liuchengxu 評論0 收藏0
  • DBASK問答集萃第四期

    摘要:問題九庫控制文件擴展報錯庫的擴展報錯,用的是裸設備,和還是原來大小,主庫的沒有報錯,并且大小沒有變,求解釋。專家解答從報錯可以看出,控制文件從個塊擴展到個塊時報錯,而裸設備最大只支持個塊,無法擴展,可以嘗試將參數(shù)改小,避免控制文件報錯。 鏈接描述引言 近期我們在DBASK小程序新關聯(lián)了運維之美、高端存儲知識、一森咖記、運維咖啡吧等數(shù)據(jù)領域的公眾號,歡迎大家閱讀分享。 問答集萃 接下來,...

    SKYZACK 評論0 收藏0

發(fā)表評論

0條評論

IT那活兒

|高級講師

TA的文章

閱讀更多
最新活動
閱讀需要支付1元查看
<