現在有一個需求，某個環境中存在兩個使用者，一個使用者中存在物化檢視，另一個使用者中存在源表，根據業務的需要，需要做一種特別的物化檢視重新整理。

物化檢視使用者中的物化檢視為CORP_NAME 源資料使用者中的表為ADD_CORP_NAME 可能資料重新整理是沒有問題，關鍵就是在於CORP_NAME中的欄位要比ADD_CORP_NAME多一些。 CORP_NAME ADD_CORP_NAME CORP_ID | CORP_ID SYS_CREATION_DATE | SYS_CREATION_DATE SYS_UPDATE_DATE | SYS_UPDATE_DATE OPERATOR_ID | OPERATOR_ID APPLICATION_ID | APPLICATION_ID DL_SERVICE_CODE | DL_SERVICE_CODE DL_UPDATE_STAMP | DL_UPDATE_STAMP CORP_NAME | CORP_NAME FUTURE1 | FUTURE2 | FUTURE3 |

根據開發的反饋，FUTURE1，FUTURE2，FUTURE3這三個欄位的值是dummy欄位，只是純粹業務需要，但是沒有實際的值。根據業務的需求，這三個欄位的資料型別需要為VARCHAR2(10),VARCHAR2(20),VARCHAR2(30) 明白了大體的需求，因為表資料量很小，所以沒有做特別的處理，採用全表重新整理。 CREATE MATERIALIZED VIEW CORP_NAME AS SELECT CORP_ID , SYS_CREATION_DATE , SYS_UPDATE_DATE , OPERATOR_ID , APPLICATION_ID , DL_SERVICE_CODE , DL_UPDATE_STAMP , CORP_NAME , ' ' FUTURE1 , ' ' FUTURE2 , ' ' FUTURE3 FROM XXXX.ADD_CORP_NAME;

但是建立好之後，檢視，FUTURE1,2,3的資料型別為CHAR(1),明顯和需求不符。 如果這個時候做全表重新整理還可以，但是重新整理就會報錯，

和開發做了確認，雖然這幾個欄位是dummy欄位，但是可能會從客戶端做校驗，如果是char(1)很可能會有錯誤。 最後在查看了一些資料後，發現可以更改物化檢視的資料型別。 ALTER MATERIALIZED VIEW CORP_NAME MODIFY(FUTURE1 VARCHAR2(10)); ALTER MATERIALIZED VIEW CORP_NAME MODIFY(FUTURE2 VARCHAR2(20)); ALTER MATERIALIZED VIEW CORP_NAME MODIFY(FUTURE3 VARCHAR2(30));

自己的固有思維中，物化檢視的欄位資料型別都是不能手動改變的，這種思維應該是從檢視的認知中轉移過來的。 從這個角度來看，這也是物化檢視和普通檢視的一大區別。至少對於檢視來說我們如果要實現這種需求真是無能為力了。 最關鍵的部分就是重新整理了，使用如下的語句做全表重新整理沒有問題，這個問題就告一段落了。 EXEC DBMS_MVIEW.REFRESH('CORP_NAME','C'); 後續的需求就是hi定期重新整理，我建議他們使用scheduler來實現，畢竟使用crontab或者外部job，shell指令碼也都可以，資料庫層面來說還是比較方便的。 這個問題發生在昨天，雖然問題很小，但是從中可以明白對於很多東西都需要打破固有的一些思維，不能想當然的處理問題。