While checking v$sql in my database, I came across this query.
select p_obj#, flags, code, audit$ from edition$ where obj#=:1
Can anybody please explain what is this select statement for ?
I think the query is executed while gathering schema statistics by my application. But I cannot understand it.
Oracle actually stores meta data information on base tables(usually followed by $ sign on its name).
Its a base table for edition objects. DBA_EDITIONS is the view created for this base table.
An edition makes it possible to have two or more versions of the same editionable objects in the database.
SQL> select obj# from edition$;
OBJ#
----------
133
SQL> select object_type, object_name from all_objects where object_id=133;
OBJECT_TYPE OBJECT_NAME
---------------- -------------------
EDITION ORA$BASE
Related
I have to drop a table and to create a view with the same fields and name.
How can I get previously all the objects (tables, triggers, procedure, ...) connected to the original table so as to eventually or recompiling either modifying them?
Oracle version 11g
Thanks!
Run such a query; currently, I'm connected as a privileged user who is capable of querying DBA_DEPENDENCIES.
SQL> SELECT owner, name, type
2 FROM dba_dependencies
3 WHERE 1 = 1
4 AND referenced_owner = 'SCOTT'
5 AND referenced_type = 'TABLE'
6 AND referenced_name = 'EMP';
OWNER NAME TYPE
------------------------------ ------------------------------ ------------------
SCOTT TRG_BIU_EMP TRIGGER
MIKE PKG_EMPLOYEE PACKAGE BODY
SQL>
It says that emp table, owned by scott, is referenced by two other objects:
trigger named trg_biu_emp owned by scott
package body named pkg_employee owned by mike
You can also go with all_dependencies and user_dependencies (pay attention to their description! owner column is missing in user_ views), but you'll get fewer and fewer results because both of them contain less information than dba_dependencies.
Therefore, if you don't want to miss something, look everywhere (i.e. dba_ views). If you don't have required privileges, talk to your DBA.
Also, note that such a query won't discover possible references to that object elsewhere, such as front-end applications developed in e.g. Oracle Forms and Reports or Apex or ...
Is it possible to add a metadata field at column-level (in the Oracle Data Dictionary)?
The purpose would be to hold a flag identifying where individual data items in a table have been anonymised.
I'm an analyst (not a DBA) and I'm using Oracle SQL Developer which surfaces (and enables querying of) the COLUMN_NAME, DATA_TYPE, NULLABLE, DATA_DEFAULT, COLUMN_ID, and COMMENTS metadata fields of our Oracle DB (see pic).
I'd be looking to add another metadata field at this level (essentially, to add a second 'COMMENTS' field) to hold the 'Anonymisation' flag, to support easy querying of our flagged-anonymised data.
If it's possible (and advisable / supportable), I'd be grateful for any advice for describing the steps required to enable this, which I can then discuss with our Developer and DBA.
Short answer: NO.
But where could you keep that information?
In your data model.
Oracle provides a free data modeling solution, Oracle SQL Developer Data Modeler. It provides the ability to mark table/view columns as sensitive or PII.
Those same models can be stored back in your database so they can be accessed via SQL.
Once you've marked up all of your sensitive attributes/columns, and store it back into the database, you can query it back out.
Disclaimer: I work for Oracle, I'm the product manager for Data Modeler.
[TL;DR] Don't do it. Find another way.
If it's advisable
NO
Never modify the data dictionary; (unless Oracle support tells you to) you are likely to invalidate your support contract with Oracle and may break the database and make it unusable.
If it's possible
Don't do this.
If you really want to try it then still don't.
If you really, really want to try it then find a database you don't care about (the don't care about bit is important!) and log on as a SYSDBA user and:
ALTER TABLE whichever_data_dictionary_table ADD anonymisation_flag VARCHAR2(10);
Then you can test whether the database breaks (and it may not break immediately but at some point later), but if it does then you almost certainly will not get any support from Oracle in fixing it.
Did we say, "Don't do it"... we mean it.
As you already know, you shouldn't do that.
But, nothing prevents you from creating your own table which will contain such an info.
For example:
SQL> CREATE TABLE my_comments
2 (
3 table_name VARCHAR2 (30),
4 column_name VARCHAR2 (30),
5 anonymisation VARCHAR2 (10)
6 );
Table created.
Populate it with some data:
SQL> insert into my_comments (table_name, column_name)
2 select table_name, column_name
3 from user_tab_columns
4 where table_name = 'DEPT';
3 rows created.
Set the anonymisation flag:
SQL> update my_comments set anonymisation = 'F' where column_name = 'DEPTNO';
1 row updated.
When you want to get such an info (along with some more data from user_tab_columns, use (outer) join:
SQL> select u.table_name, u.column_name, u.data_type, u.nullable, m.anonymisation
2 from user_tab_columns u left join my_comments m on m.table_name = u.table_name
3 and m.column_name = u.column_name
4 where u.column_name = 'DEPTNO';
TABLE_NAME COLUMN_NAME DATA_TYPE N ANONYMISATION
---------- --------------- ------------ - ---------------
DEPT DEPTNO NUMBER N F
DSV DEPTNO NUMBER N
DSMV DEPTNO NUMBER Y
EMP DEPTNO NUMBER Y
SQL>
Advantages: you won't break the database & you'll have your additional info.
Drawbacks: you'll have to maintain the table manually.
Last night got a call from my team lead and he asked me to make the list of all the procedures along with the tables and columns used in Oracle.
I got a query to list all the procedures along with tables and dblink but couldn't get column names (along with DML if possible) used in that Procedure :
select DISTINCT OWNER, NAME, referenced_name, referenced_link_name, referenced_type
from dba_dependencies
where OWNER = 'OWNER_NAME';
My required output is as follows:
Owner_Name
Procedure_Name
Referenced_name
Referenced_link
Referenced_type
Column_Name,
dml_type(select/insert/update).
Please help if possible..
columns will be in DBA_TAB_COLUMNS.
as for the SQL statements, this is a bit more difficult, but doable if you have Diagnostics pack licensed; here's the outline (works in 11g or above):
DBA_HIST_ACTIVE_SESS_HISTORY.top_level_sql_id is the SQL id of the calling procedure,
so listing DBA_HIST_ACTIVE_SESS_HISTORY.sql_id for that top_level_sql_id is "all" the SQL from the execution of the procedure.
DBA_HIST_SQL_TEXT can be queried to get the sql text for the sql_id.
If you don't have the Diagnostics Pack, you'd have to instrument v$session for the top_level_sql_id's and sql_id's and the look in v$sql for the text.
I want to record all oracle select statement executed on specific table oracle
and pc ip address, windows username, PC name
in other words I need to know who and when a table was read..
I searched and found the this query will return pc ip address, windows username, PC name
SELECT SYS_CONTEXT ('USERENV', 'IP_ADDRESS'),
SYS_CONTEXT ('USERENV', 'HOST'),
SYS_CONTEXT ('userenv', 'OS_USER')
FROM DUAL;
But I am wondering does this will return correct information when there is no database on that pc ?
since trigger cannot be launched on select then How to deal with that case ?
I am using oracle forms 6i application if there is possible solution too
You can use database auditing for individual SQL DML/DDL statements.
Example:
SQL> conn sys as sysdba
SQL> alter system set audit_trail=DB,EXTENDED scope=spfile;
Reboot the database.
I have a table called T1 and I want audit SELECT statements fired against it.
SQL> audit select on t1 by access;
Audit succeeded.
SQL> select * from t1;
no rows selected
The audit information can be obtained from USER_AUDIT_TRAIL view.
SQL> select OS_USERNAME,USERNAME, USERHOST, SQL_TEXT, ACTION_NAME from dba_audit_trail where obj_name='T1';
OS_USERNAME USERNAME USERHOST SQL_TEXT ACTION_NAME
------------ --------- ------------ ----------------- ------------
oracle JAY myserver.js select * from t1 SELECT
Individually Auditing SQL Statements
I have a query like
INSERT INTO sid_rem#dev_db
(sid)
select sid from v$session
Now, when i execute this query i get
ORA-02070: database does not support in this context
This error happens only when I insert data from v$session into some remote db. Its working fine for any other table.
Anyone know why this issue and any workaround for this?
Works using gv$session instead of v$session:
INSERT INTO sid_rem#dev_db(sid)
select sid from gv$session;
gv$ views are global views, that is, they are not restricted to one node(instance), but see the entire database(RAC). v$ views are subviews of gv$.
Searching on the internet I found this has something to do with distributed transactions.
Thread on ora-code.com
Late answer but might still be useful. I've found this error occurs when trying to select from system views across a database link where the system view contains columns of type LONG. If the query can be reworded to avoid the LONG columns these joins will work fine.
Example:
SELECT dc_prod.*
FROM dba_constraints#prod_link dc_prod
INNER JOIN dba_constraints dc_dev
ON (dc_dev.CONSTRAINT_NAME = dc_prod.CONSTRAINT_NAME)
will fail with an ORA-02070 due to accessing the LONG column SEARCH_CONDITION, but
SELECT dc_prod.*
FROM (SELECT OWNER,
CONSTRAINT_NAME,
CONSTRAINT_TYPE,
TABLE_NAME,
-- SEARCH_CONDITION,
R_OWNER,
R_CONSTRAINT_NAME,
DELETE_RULE,
STATUS,
DEFERRABLE,
DEFERRED,
VALIDATED,
GENERATED,
BAD,
RELY,
LAST_CHANGE,
INDEX_OWNER,
INDEX_NAME,
INVALID,
VIEW_RELATED
FROM dba_constraints#prod_link) dc_prod
INNER JOIN (SELECT OWNER,
CONSTRAINT_NAME,
CONSTRAINT_TYPE,
TABLE_NAME,
-- SEARCH_CONDITION,
R_OWNER,
R_CONSTRAINT_NAME,
DELETE_RULE,
STATUS,
DEFERRABLE,
DEFERRED,
VALIDATED,
GENERATED,
BAD,
RELY,
LAST_CHANGE,
INDEX_OWNER,
INDEX_NAME,
INVALID,
VIEW_RELATED
FROM dba_constraints) dc_dev
ON (dc_dev.CONSTRAINT_NAME = dc_prod.CONSTRAINT_NAME)
works fine because the LONG column SEARCH_CONDITION from DBA_CONSTRAINTS is not accessed.
Share and enjoy.
I don't know why this is happening, it's probably in the documentation somewhere but my Oracle-Docs-Fu seems to have deserted me today.
One possible work-around is to use a global temporary table
SQL> create table tmp_ben ( sid number );
Table created.
SQL> connect schema/pw#db2
Connected.
SQL> create table tmp_ben ( sid number );
Table created.
SQL> insert into tmp_ben#db1 select sid from v$session;
insert into tmp_ben#db1 select sid from v$session
*
ERROR at line 1:
ORA-02070: database does not support in this context
SQL> create global temporary table tmp_ben_test ( sid number );
Table created.
SQL> insert into tmp_ben_test select sid from v$session;
73 rows created.
SQL> insert into tmp_ben#db1 select * from tmp_ben_test;
73 rows created.