http://oracledbawings.blogspot.

com/

Tables Data Dictionary Views

DBA view describes all relational tables in the database. ALL view describes all tables accessible
to the user. USER view is restricted to tables owned by the user. Some columns in these views
contain statistics that are generated by the DBMS_STATS package or ANALYZE statement.
DBA_TABLES
ALL_TABLES
USER_TABLES

These views describe the columns of tables, views, and clusters in the database. Some columns
in these views contain statistics that are generated by the DBMS_STATS package or ANALYZE
statement.
DBA_TAB_COLUMNS
ALL_TAB_COLUMNS
USER_TAB_COLUMNS

These views describe all relational and object tables in the database. Object tables are not
specifically discussed in this book..
DBA_ALL_TABLES
ALL_ALL_TABLES
USER_ALL_TABLES

These views display comments for tables and views. Comments are entered using the
COMMENT statement.
DBA_TAB_COMMENTS
ALL_TAB_COMMENTS
USER_TAB_COMMENTS

These views display comments for table and view columns. Comments are entered using the
COMMENT statement..
DBA_COL_COMMENTS
ALL_COL_COMMENTS
USER_COL_COMMENTS

These views list the specific attributes of external tables in the database.
DBA_EXTERNAL_TABLES
ALL_EXTERNAL_TABLES
USER_EXTERNAL_TABLES

These views list the data sources for external tables.

DBA_EXTERNAL_LOCATIONS
ALL_EXTERNAL_LOCATIONS
USER_EXTERNAL_LOCATIONS

These views describe histograms on tables and views.

DBA_TAB_HISTOGRAMS
ALL_TAB_HISTOGRAMS
USER_TAB_HISTOGRAMS

These views contain optimizer statistics for tables.

DBA_TAB_STATISTICS
ALL_TAB_STATISTICS
USER_TAB_STATISTICS

These views provide column statistics and histogram information extracted from the related
TAB_COLUMNS views.
DBA_TAB_COL_STATISTICS
ALL_TAB_COL_STATISTICS
USER_TAB_COL_STATISTICS

These views describe tables that have been modified since the last time table statistics were
gathered on them. They are not populated immediately, but after a time lapse (usually 3 hours).
DBA_TAB_MODIFICATIONS
ALL_TAB_MODIFICATIONS
USER_TAB_MODIFICATIONS

These views list table columns that are encrypted, and for each column, lists the encryption
algorithm in use.
DBA_ENCRYPTED_COLUMNS
USER_ENCRYPTED_COLUMNS
ALL_ENCRYPTED_COLUMNS

These views list tables with unused columns, as marked by the ALTER TABLE ... SET UNUSED
statement.
DBA_UNUSED_COL_TABS
ALL_UNUSED_COL_TABS
USER_UNUSED_COL_TABS

These views list tables that have partially completed DROP COLUMN operations. These
operations could be incomplete because the operation was interrupted by the user or a system
failure.
DBA_PARTIAL_DROP_TABS
ALL_PARTIAL_DROP_TABS
USER_PARTIAL_DROP_TABS

ROW ID
Every row in every table has a physical address. The address of a row is determined from a
combination of
the following:

Datafile number.
Block number.
Location of the row within the block.
Object number.
You can display the address of a row in a table by querying the ROWID pseudo-columnfor
example:

SQL> select rowid, emp_id from emp;

Heres some sample output:

ROWID EMP_ID
------------------ ---------
AAAFWXAAFAAAAlWAAA 1

You can translate the ROWID value into meaningful information via the DBMS_ROWID
package. For example,

select emp_id
,dbms_rowid.rowid_relative_fno(rowid) file_num
,dbms_rowid.rowid_block_number(rowid) block_num
,dbms_rowid.rowid_row_number(rowid) row_num
from emp;

Heres some sample output:

EMP_ID FILE_NUM BLOCK_NUM ROW_NUM

---------- ---------- ---------- ----------
2960 4 144 126
2961 4 144 127

You can use the ROWID value in the SELECT and WHERE clauses of a SQL statement. In most
cases, the
ROWID uniquely identifies a row.

Execution plans
------------------

Basically, Oracle provides four methodes to obtain execution plan.

1. Execute the SQL statement EXPLAIN plan, and then query the table where the output was
written.

- EXPLAIN PLAN for query;

- select * from plan_table;

2. Query a dynamic performance view showing the excution plans cached in the library cache.

3. Query an Automatic workload Repository or statspack table, showing the execution plans
stored in the repository.

NOTE: statspack default user is PERF_STAT.

4. Activate tracing facility providing execution plans.

No other methods exist.

1) SQL statement EXPLAIN plan (EXPLAIN PLAN is a statement for EXECUTION PLAN)

example --> EXPLAIN PLAN for select count(*) from user_objects;

plan table --> where sql statemnet explian plan writes the output. -------------------------This query
use to diplay result

$ORACLE_HOME/rdbms/admin/utlxplan.sql (using to create PLAN_TABLE in any schema,just

run this query as the user we desired.)

select * from table (dbms_xplan.display); -------------------------------------------this query also to get

result

HOW WE CAN CRAETE A TAG AND HOW CAN DISPLAY WITH TAG.
-----------------------------------------------------

EXPLAIN PLAN set statement_id='myplan' into plan_table for select count(*) from dba_users;

select * from table(DBMS_XPLAN.DISPLAY('PLAN_TABLE','myplan'));

NOTE: 1. We can mention "update statement" also in EXPLAIN PLAN query, that update action
wont affect the table,just getting how the query works..

2. 10g onwards we are having PLAN_TABLE by default in SYS..

Eg:

OWNER OBJECT_NAME OBJECT_TYPE STATUS

------------------------------ ---------------------------------------- ------------------- -------
SYS PLAN_TABLE$ TABLE VALID
PUBLIC PLAN_TABLE SYNONYM VALID ------this is the synonym for above SYS table
PLAN_TABLE$
EXFSYS PLAN_STMT_ID INDEX VALID
ORDSYS PLANAR_CONFIGURATION181_T TYPE VALID
SIEBEL_O PLAN_TABLE TABLE VALID

select * from TABLE(DBMS_XPLAN.DISPLAY_AWR('61mzs5g8h12ww', 1318028273 )); ----------

--This query also to get result.But we can mention SQLID and PLAN_HASH value.

select * from TABLE(DBMS_XPLAN.DISPLAY_CURSOR('61mzs5g8h12ww')); ------------This

query also to get result

2) Dynamic performance views.

Four dynamic performance views show information about the cursors present in the library
cache.

v$sql_plan
v$sql_plan_statistics
v$sql_workarea
v$sql_plan_statistics_all

3) AWR/Statspack.

to get explain plan from AWR table dba_hist_sql_plan

SELECT * from table(dbms_xplan.display_awr('61mzs5g8h12ww'));

HOW we can compare execution plan:

@$ORACLE_HOME/rdbms/admin/awrsqrpt.sql or awrsqlrpt.sql

OR

select * from TABLE(DBMS_XPLAN.DISPLAY_AWR('&sqlid'));

statspack stores execution plan in stats$sql_plan.

@$ORACLE_HOME/rdbms/admin/sprepsql.sql--------------------using to compare the plan hash

value

4) Traceing

NOTE: A trace generated only when a hard parse (means once we run new query in DB first
time) performed.

EVENT 10053:

we should start and off the event to generate trace file.

ALTER SESSION SET events '10053 trace name context forever'

***query***

ALTER SESSION SET events '10053 trace name context off'

EVENT 10132:

ALTER SESSION SET events '10132 trace name context forever'

***query***

ALTER SESSION SET events '10132 trace name context off'

ALTER SYSTEM SET events '10132 trace name context forever'

***query***

ALTER SYSTEM SET events '10132 trace name context off'

NOTE:

Here are some common acts that will change execution plans:

- Enabling dynamic sampling

- Table in index DDL (e.g. dropping an index)

- Re-analyze the schema statistics (done automatically, starting in 10g)

- Changing an optimizer parameter (optimizer_mode, optimizer_index_cost_adj)

- Enabling parallelism
Rare Example:

rajesh@ORA10GR2> set autotrace traceonly explain statistics;

rajesh@ORA10GR2>
rajesh@ORA10GR2> select *
2 from t
3 where object_id in (select * from table ( sys.odcinumberlist(1,2,3,4,5,6) ) );

Elapsed: 00:00:00.07

Execution Plan
----------------------------------------------------------
Plan hash value: 1584247153
----------------------------------------------------------------------------
| Id | Operation | Name | Rows | Cost (%CPU)|
----------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 187 (4)|
|* 1 | HASH JOIN RIGHT SEMI | | 1 | 187 (4)|
| 2 | COLLECTION ITERATOR CONSTRUCTOR FETCH| | | |
| 3 | TABLE ACCESS FULL | T | 50096 | 161 (3)|
----------------------------------------------------------------------------

DDL - Metadata of Objects

TABLE:
------

SET LONG 2000000

SET PAGESIZE 0
SELECT DBMS_METADATA.GET_XML('TABLE','EMP','SCOTT')
FROM DUAL;

To get the create scripts of all tables of a particular schema

------------------------------------------------------------------
SQL>spool tables.sql
SQL>select 'select dbms_metadata.get_ddl(''TABLE'', '''||TABLE_NAME||''','''') from dual;' FROM
DBA_TABLES
/

USERS and GRANTS:

-----------------

set long 20000000

SELECT DBMS_METADATA.GET_DDL('USER','G09104071') FROM dual;

select DBMS_METADATA.GET_GRANTED_DDL('ROLE_GRANT','G09104071') from dual;

SELECT DBMS_METADATA.GET_GRANTED_DDL('SYSTEM_GRANT','G09104071') FROM

DUAL;

SELECT DBMS_METADATA.GET_GRANTED_DDL('OBJECT_GRANT','G09104071') FROM

DUAL;

DB LINK:
--------

set long 20000000

SELECT DBMS_METADATA.GET_DDL('DB_LINK','VENR.WORLD') FROM dual;

OR

All DBlinks backup:

---------------------
set pages 0
set long 90000
set trimspool on
SELECT u.OWNER,DBMS_METADATA.GET_DDL('DB_LINK',u.DB_LINK,u.OWNER) FROM
dba_db_links u;

For a specific DBlink backup:

---------------------------------
set pages 0
set long 90000
set trimspool on
SELECT DBMS_METADATA.GET_DDL('DB_LINK','&DB_LINK_NAME','&USER_NAME') FROM
dba_db_links;

TABLESPACE:
-----------

set long 20000000

SELECT DBMS_METADATA.GET_DDL('TABLESPACE','FGL_LOB') FROM dual;

PACKAGE and PACKAGE BODY:

-------------------------

PACKAGE BACKUP
--------------
set heading off
set echo off
set flush off
set pagesize 50000
set linesize 32767
set long 99999999
spool PACKAGE_NAME.pks
select dbms_metadata.get_ddl('PACKAGE','','') from dual ;
spool off;

OR

set linesize 500

set pagesize 100000
set head off
set verify off
spool PACKAGE_NAME.pks
select text from dba_source where owner=''and name='';
spool off

OR

select text from dba_source where owner='' and name='PACKAGE_NAME' and

type='PACKAGE' order by line;

PACKAGE BODY BACKUP

-------------------
select dbms_metadata.get_ddl('PACKAGE_BODY','','') from dual ;

OR

set pagesize 0
set linesize 800
set trimspool on
set heading off
set feedback off
spool PACKAGE_BODY_NAME.pkb
select text from dba_source where owner=''and name='';
spool off

OR

select text from dba_source where owner='' and name='PACKAGE_BODY_NAME' and

type='PACKAGE BODY' order by line;

Whats the meaning of the TIMESTAMP column in the

DBA_OBJECTS view ?
Thanks to Tom Kyte
The timestamp is used in remote dependency checking. It is the time of the last update
that changed the specification of the object. If the object is a PACKAGE -- the
"specification" is clear. If the object is a VIEW, the specification is perhaps not as
clear. The specification of a view is the number, names, and types of columns it
returns. Same with other objects -- their specification is their "external interface".
Anytime their external interface has changed -- their timestamp will change.

We use this timestamp to manage dependencies between remote objects (eg: in a distributed
system where we have local procedures that call remote procedures -- we have to
invalidate local procedures that depend on remote procedures whose timestamps have
changed).

CREATED = date of creation of the object

LAST_DDL_TIME = last ddl on object, would include CREATE OR REPLACE (example below)

TIMESTAMP = last time the external "view" or "specification" of the object changed --
will be between created and last_ddl_time.

here is an example with a view:

tkyte@TKYTE816> create view v

2 as
3 select * from dual;

View created.

tkyte@TKYTE816>
tkyte@TKYTE816> select timestamp, to_char(created,'hh24:mi:ss'),
2 to_char(last_ddl_time,'hh24:mi:ss')
3 from dba_objects
4 where object_name = 'V'
5 and owner = USER
6/

TIMESTAMP TO_CHAR( TO_CHAR(

------------------- -------- --------
2000-12-13:13:11:26 13:11:26 13:11:26

it starts with the timestamp = created = last_ddl_time. Now, lets alter the view
(doesn't change its EXTERNAL interface):

tkyte@TKYTE816>
tkyte@TKYTE816> exec dbms_lock.sleep(2)

PL/SQL procedure successfully completed.

tkyte@TKYTE816>
tkyte@TKYTE816> alter view v compile
2/

View altered.

tkyte@TKYTE816> select timestamp, to_char(created,'hh24:mi:ss'),

2 to_char(last_ddl_time,'hh24:mi:ss')
3 from dba_objects
4 where object_name = 'V'
5 and owner = USER
6/

TIMESTAMP TO_CHAR( TO_CHAR(

------------------- -------- --------
2000-12-13:13:11:26 13:11:26 13:11:28

Now, the timestamp did not change -- it is still the same as the created. The
last_ddl_time did however change as we just did some DDL on the view. We can in fact do
some DDL on the view you might think would change the timestamp:

tkyte@TKYTE816>
tkyte@TKYTE816> exec dbms_lock.sleep(2)

PL/SQL procedure successfully completed.

tkyte@TKYTE816> create or replace view v

2 as
3 select * from dual;

View created.

tkyte@TKYTE816>
tkyte@TKYTE816> select timestamp, to_char(created,'hh24:mi:ss'),
2 to_char(last_ddl_time,'hh24:mi:ss')
3 from dba_objects
4 where object_name = 'V'
5 and owner = USER
6/

TIMESTAMP TO_CHAR( TO_CHAR(

------------------- -------- --------
2000-12-13:13:11:26 13:11:26 13:11:30

But it does not -- the "signature" or external interface of the view did not change.
If we do a create or replace that changes the interface of the view:

tkyte@TKYTE816>
tkyte@TKYTE816> exec dbms_lock.sleep(2)

PL/SQL procedure successfully completed.

tkyte@TKYTE816> create or replace view v

2 as
3 select dummy x from dual;

View created.

tkyte@TKYTE816>
tkyte@TKYTE816> select timestamp, to_char(created,'hh24:mi:ss'),
2 to_char(last_ddl_time,'hh24:mi:ss')
3 from dba_objects
4 where object_name = 'V'
5 and owner = USER
6/
TIMESTAMP TO_CHAR( TO_CHAR(
------------------- -------- --------
2000-12-13:13:11:32 13:11:26 13:11:32

tkyte@TKYTE816>

And so now the timestamp is different since the "specification" of this view is
different.