oracle重新編譯視圖
1.批量編譯存儲工程的存儲過程
create or replace procere compile_invalid_proceres(
p_owner varchar2 -- 所有者名稱，即 SCHEMA) as--編譯某個用戶下的無效存儲過程
str_sql varchar2(200);begin
for invalid_proceres in (select object_name from all_objects
where status = 'INVALID' and object_type = 'PROCEDURE' and owner=upper(p_owner))loop
str_sql := 'alter procere ' ||invalid_proceres.object_name || ' compile';begin
execute immediate str_sql;exception
--When Others Then Null;
when OTHERS Then
dbms_output.put_line(sqlerrm);end;end loop;end;
2.批量編譯視圖的存儲過程
⑵ oracle： 不知道為什麼，我的視圖可以查詢，但是點編輯 或是從新編譯那個視圖，PLSQL就卡死了。謝謝
很有可能是視圖鎖了。或者是視圖里的某一個表鎖了
⑶ oracle視圖問題！
你好，希望我的回答對你有所幫助。
因為你所創建的三個視圖都依賴於同一個表userinfo，當你修改了原有表的表結構時不會出現三個視圖都畫紅叉的錯誤，因為alter語句是DDL語句，已經自動提交了，所以影響了視圖中的表結構，此時視圖本身並沒有被修改，而其所依賴的表已經修改；而在修改視圖後，視圖所依賴的表已經被修改，然後再修改視圖，保存後當然不會出錯了，你說呢？
⑷ 如何重編譯ORACLE資料庫的無效對象
Oracle中出現無效對象，就是因為在創建函數或存儲過程等，里邊的內容書寫不正確導致。如果要重新編譯，需要先修正錯誤，然後編譯。
工具：Oracle 10g、PL/SQL
步驟：
1、在PL/SQL中打開出現編譯錯誤的函數或存儲過程，這里以存儲過程為例。
⑸ oracle資料庫開發人員說『需要重新編譯一下』是什麼意思 是說要重新跑某個過程嗎
重新編譯，就是某個過程或者函數哪裡做了修改 需要重新編譯成可以執行的文件，並不是說重新跑某個過程。編譯完成之後，把編譯好了的過程再重新運行。
⑹ Oracle資料庫視圖管理經驗技巧
視圖 對於資料庫來說 是一個最基本的 也是最重要的功能之一 資料庫視圖設計的好壞 直接跟資料庫的性能相關 而且 在大型資料庫設計中 大家分工合作 基礎表的設計與報表視圖的設陸和計往往由不同的人負責 所以 視圖的設計管理跟基礎表的設計管理一樣 都有很大的學問 在這篇文章中 筆者將結合自己在視圖設計管理方面的工作經驗 談談在這方面的一些鮮為人知的技巧
技巧一 把基礎表與視圖脫離開來
一般來說 視圖都是在基礎表的上面建立起來的 也就是說 要先有基礎表 而後有視圖 但是 在大型資料庫的設計過程中 出於項目時間的考慮 往往基礎表與視圖的設計是同時進行的 如一些人負責基礎表的建立 另一些人則負責視圖的設計與建立等等 在這個過程中 往往基礎表不存在的時候 就需要建立一些視圖 以加快項目的進度
為了使得基礎表的創建和修改與視圖的創建於修改沒有必然的聯系 以便於員工之間工作的同步 提高工作效率 所以 在Oracle資料庫中提出了信宏一個 強制創建視圖 的概念 也就是說 正常情況下 如果基本表不存在 則創建視圖就會失敗 但是 我們可以在創建視圖的過程中 加入一個參數 只要創建視圖的語法沒有錯誤的話 即使基礎表不存在 仍然可以建立這張表格 這個有用的參數就是force選項 如我們建立視圖時 CREATE FORCE VIEW TEXT 只需要在關鍵字VIEW之前加入FORCE參數即可 如此的話 系統在編譯視圖的時候 就不會去考慮基礎表是否存在
不過這里要注意一點 若基礎表不存在的話 則編譯後該視圖的狀態為 無效 不能再這個視圖的基礎上執行一些操作 如查詢操作等等 當下次訪問這個視圖的時候 則資料庫會對這個視圖進行重新編譯 若此時基礎表存在了 則該基礎表就會變為有效;若基礎表不存在 則這視圖就會失效
Oracle資料庫之所以如此設置 主要是出於在資料庫設計過程中協同辦公的需要 有了這個功能之後 則在資料庫建立的過程中 只要把資料庫基礎表與視圖設計好之後 大家就可以分工合作 在資料庫中建立相關的對象 不然的話 要等基礎表建立好之後再建立視圖 如此就會明顯的影響資料庫建立的進度 所以 在資料庫建立的過程中 特別是中大型的資料庫系統 這是一個很實用的功能
技巧二 創建視圖的理想步驟
無論是簡單視圖 還是比較復雜的視圖 筆者覺得資料庫管理員在創建視圖的時候 最好能夠遵循一定的步驟 這一方面是因為視圖的更改相對來說 是一件比較麻煩的工作 所以 我們在建立視圖的時候 要確保視圖的准確性 另一方面 視圖是基礎表的一個體現形式 若不按步驟來做的話 有可能就不能夠達到我們預計的需求
當然這個步驟沒有官方的版本 完全是資料庫管理員根據實際的經驗總結出來的 這個步驟不僅對Oracle資料庫有效 對於其他資料庫來說 也是類似的道理
一般來說 視圖創建可以分為五步走
第一步 先考慮Select語句的編寫 我們知道 視圖其實就是一個Select語句的集合 所以 我們建立視圖的第一步 就是考慮這個Select語句該如何編寫 這個Select語句編寫的是否合理 執行效率的高低直接影響著這個視圖的性能 另外 在Select語句中 可能還會有格式的控制 內容的編排等等 如在Select語句中 可以把一些欄位合並成一個欄位;也可以把相關的內容進行倒置等等 這些功能都是Select語句完成的 所以可以這么說 Select語句的編寫是視圖建立的基礎
第二步 對這個Select語句進行測試 當我們編寫好Select語句之後 就需要在資料庫中執行這條語句 看其能否查詢到我們想要的值 在對Select語句進行測試的時候 需要注意一個問題 有時候Select查詢語句可以查到准確的數據 但是在以這條語滑悉冊句建立視圖的時候 可能就會通不過 如在一些表之間的連接查詢的時候 如果兩個表中有個欄位名相同 是可以的 因為他們除了欄位名字之外 還有表名一起來定義這個欄位 如A name與B name 這是不算重名的 但是 若在建立視圖的時候 這就會被認為是重復的列明 需要對其中的一個列名進行重定義 這一點在資料庫視圖建立的時候 要特別的注意
第三步 考慮查詢結果的准確性 通過查詢語句把我們想要的結果查詢出來後 我們就需要看看這個結果是否滿足我們的需要 在這個過程中 我們主要注意兩點 一是形式欄位是否齊全 在一些應用系統中 若資料庫的視圖要能夠被前台的應用程序調用的話 則必須包含一些形式欄位 如筆者以前在設計一個ERP系統的時候 若前台系統要調用資料庫中的視圖的時候 必須包含記錄更新時間 更新者 記錄創建時間 創建者等相關信息 若缺乏這些信息的話 則前台調用這張視圖的時候 就會出現錯誤 故在考慮查詢結果准確性的問題的時候 就要考慮到前台應用程序的需要 看看這些形式欄位是否齊全 二是實體內容的完整性 我們到底需要顯示表中的哪些欄位呢 這個我們在這里要確認清楚 若顯示內容太多的話 則會影響視圖的執行效率 而且也會降低視圖的安全性作用;但是 若欄位內容顯示不足的話 則以後要添加欄位的話 會比較麻煩 有一定的工作量 所以在這個檢驗的時候 需要根據視圖的實際功用 確定視圖需要顯示的內容
第四步 視圖的修飾 有時候 為了閱讀的方便 我們需要對查詢結果進行一些修飾 如現在有兩張表 一張是員工基本信息表 這表中有員工姓名 員工職位編號等等;另一張表是職位基本信息表 在這表中有職位編號 職位名稱 我們希望在視圖中能夠如下顯示 職位 員工名字 如資料庫工程師 Victor 也就是說 把兩個欄位合並起來 並且在中間加入一個冒號 這些格式性的內容都是在查詢的時候實現的 所以 我們確認查詢的結果沒有錯誤之後 接下來就要確認格式問題 若能夠在視圖中規范這些格式問題 則前台的程序設計就會相對來說比較簡單
lishixin/Article/program/Oracle/201311/17034
⑺ oracle升級psu前後為什麼要檢查是否有需要重新編譯的視圖
因為視圖所依賴的對象發生改變。
忘記補充了。應該可以確認的是視圖相關的表之類的都沒有修改。
視圖底層的對象發生過DDL變化，可以查一下與此視圖相關的對象的LAST_DDL_TIME時間。
⑻ oracle資料庫的問題！視圖編譯前後sql語句發生變化，是什麼問題
你在創建視圖的時候，是select t.*，而在這個語法執行的時候，ORACLE會自動的把你的語法解析成詳細的查詢語法，就和你平時使用select *查詢一樣，這個型號資料庫也是自動解析成from後邊表的欄位的。所以這個創建語法，實際上是解析後的語法，這個也沒什麼為什麼，因為實際你創建視圖的語法，是ORACLE分析你原是語法之後得到的SQL語句創建的。