Query the permissions of the SQL statement being executed and executed by Oracle (1) v $ session table

Query the SQL statements being executed and executed by Oracle (1) v $ session table permissions when a trigger is created under a non-system user and the v $ session record type is referenced. An error occurs: "tables and views do not exist", but in pl/SQL, the v $ session that can run select * from v $ session is a synonym, and the v _ $ session is a view that needs to be processed as follows: you can directly authorize sys: grant select on v _ $ session to youruser. Note: This is a good problem. A common user has the select any dictionary permission, you can access any system view, including v $ session. Since the dba role includes the select any dictionary permission, therefore, it is okay for your hospital user to select * from v $ session, but in PL/SQL, you should refer to a table rowtype or use a table when defining the cursor, so you have to have select permission on this table. Although your dba role has select any table permission, the default value (false) is required for the initialization parameter O7_DICTIONARY_ACCESSIBILITY in 9i) in this case, a user still cannot access the sys object even if he has the select any table permission, unless 1 sets O7_DICTIONARY_ACCESSIBILITY to true, that is, even the practice or 2 directly grants the select permission of the sys object to this user, that is, the practice of biti references the dictionary table (View) in the storage object) you must separately authorize SQL> select synonym_name, table_name from dba_synonyms where synonym_name like '% SESSION %'; SYNONYM_NAME TABLE_NAME =---------------------------- V $ SESSION V _ $ SESSION v $ session is synonymous, v _ $ session is a view. In essence, it is a feature of pl/SQL programs. In pl/SQL program design, due to some features of pl/SQL compilation, oracle adopts the policy that the role does not work in Stored Procedures, functions, packages, and other famous pl/SQL statements. It must be authorized directly to take effect. Therefore, even if the dba role is invalid in stored procedures