environment: enterprise linux + oracle11gr2
前情提要:
userA先生在9i的時代運作得相當正常,當然包含本篇所要探討的小小新建一個view的動作。升級到11g之後某天,卻發現userA再也無法在自己的schema下create view... 這麼小小一件事情都辦不到!!! 檢查了權限也跟9i時代完全相同(就是CONNECT, RESOURCE, UNLIMITED TABLESPACE這麼簡單,所以也沒把腦筋動到權限上),なんで??? 當時為了應急直接用dba帳號幫他處理掉了,今天又遇到一次,該是要面對的時候了..
一開始看到的都是在說"物件的權限需要直接grant給指定的人,不要透過角色(ROLE)來做"這件事情,因為在所有stroe procedures或PL/SQL block裡,角色權限是不會起作用的(All roles are disabled inside stored procedures.)等,不過這並不是我的情況..
無意間看到這篇文章在探討Oracle的Role包含了那些權限,才恍然大悟...
9ir2的CONNECT角色裡包含了"CREATE VIEW"的權限,但在11g裡,CONNECT的角色卻只剩下"CREATE SESSION"的權限... 就這麼簡單... 所以在11g要另外把CREATE VIEW的權限grant給userA先生,這樣就可以正常新建/修改view了... 就這樣orz
若要詳細列出角色所包含的權限,可使用以下查詢:
SQL> select * from ROLE_SYS_PRIVS where role='CONNECT';
(ROLE_SYS_PRIVS: 列出登入帳號所有擁的角色,及角色所包含的系統權限)
或者也可以這樣查:
SQL> select * from DBA_SYS_PRIVS where grantee='CONNECT';
(DBA_SYS_PRIVS: 列出所有user/role所擁有的系統權限)
真是一語驚醒夢中人阿~~總是會出這種奇怪的狀況~
下次可能要先看一下ChangeLog,不然還是會死的很難看
加油啦~!!
:D:D 謝謝啦~ 你也開始玩資料庫啦?
沒有阿~我最近在跟臉書的API決鬥當中