Home

Sunday, September 21, 2014

Displaying Oracle background processes on Windows

Displaying Oracle background processes on Windows


We knows how to use the "ps -ef" command in UNIX to see Oracle background processes but we are not able to see the background processes in Windows ? When we view Oracle processes on Windows, all we see is one background process called oracle.exe.?

This is because in Windows, the "thread" model is used, and Oracle dispatches his own background tasks within the domain of the single process, oracle.exe. Hence, we cannot see any background processes from the Windows OS (but we can see listener process and parallel query slaves).To see details about the background processes in Windows,we need to run a dictionary query against the v$bgprocess view to see what the background processes are doing in Window .

The below sql statement is useful to view the background process in windows .

SQL> select a.sid,a.serial#, a.program, p.pid, p.spid, a.osuser, b.name, b.DESCRIPTION, p.PGA_USED_MEM   from v$session a,v$process p, v$bgprocess b where a.paddr=b.paddr 
      and    a.paddr=p.addr and p.background=1;
Output  : 

Identify Your Oracle Database Software Release

Identify Your Oracle Database Software Release



To understand the release nomenclature used by Oracle, examine the following example of an Oracle Database server labeled "Release 10.1.0.1.0".
Oracle Database continues to evolve and can require maintenance, Oracle periodically produces new releases. Not all customers initially subscribe to a new release or require specific maintenance for their existing release. As a result, multiple releases of the product exist simultaneously.As many as five numbers may be required to fully identify a release. The significance of these numbers is

Release Number Format
                      
Note:
Starting with release 9.2, maintenance releases of Oracle Database are denoted by a change to the second digit of a release number. In previous releases, the third digit indicated a particular maintenance release.
Major Database Release Number :  The first digit is the most general identifier. It represents a major new version of the software that contains significant new functionality.
Database Maintenance Release Number :  The second digit represents a maintenance release level. Some new features may also be included.
Application Server Release Number :  The third digit reflects the release level of the Oracle Application Server (OracleAS) .

Component-Specific Release Number : The fourth digit identifies a release level specific to a component. Different components can have different numbers in this position depending upon, for example, component patch sets or interim releases.

Platform-Specific Release Number :  The fifth digit identifies a platform-specific release. Usually this is a patch set. When different platforms require the equivalent patch set, this digit will be the same across the affected platforms.

Checking The Current Release Number :  To identify the release of Oracle Database that is currently installed and to see the release levels of other database components we are using, query the data dictionary view product_component_version. A sample query follows.(We can also query the v$version view to see component-level information.) Other product release levels may increment independent of the database server.

SQL> select * from product_component_version;
PRODUCT                                                  VERSION     STATUS
--------------------------                         -----------  -----------
NLSRTL                                                     10.2.0.1.0   Production
Oracle Database 10g Enterprise Edition           10.2.0.1.0   Production
PL/SQL                                                     10.2.0.1.0   Production

It is important to convey to Oracle the results of this query when we report problems with the software

ORACLE_HOME and ORACLE_BASE

ORACLE_HOME and ORACLE_BASE

ORACLE_HOME specifies the directory containing the Oracle software for a given release. It corresponds to the environment in which Oracle Database products run. This environment includes the location of installed product files, the PATH variable pointing to the binary files of installed products, registry entries, net service names, and program groups.The Optimal Flexible Architecture (OFA) recommended value is: $ORACLE_BASE/product/release/db_1/ .    
For example :     /u01/app/oracle/product/10.2.0/db_1.

ORACLE_BASE specifies the directory at the top of the Oracle software and administrative file structure. The value recommended for an OFA configuration is software_mount_point/app/oracle.
For example: /u01/app/oracle.

If  we are not using an OFA-compliant system, then we do not have to set  ORACLE_BASE, but it is highly recommended that we should set it.We can find the ORACLE_HOME  from below steps : 

Oracle  9i /10g/11g
SQL> select NVL(SUBSTR(FILE_SPEC, 1, INSTR(FILE_SPEC, '\', -1, 2) -1) , SUBSTR(FILE_SPEC, 1, INSTR(FILE_SPEC, '/', -1, 2) -1))  FOLDER  FROM DBA_LIBRARIES  WHERE LIBRARY_NAME = 'DBMS_SUMADV_LIB' ;
Output : 
FOLDER
-------------------------------------
C:\app\neerajs\product\11.2.0\dbhome_1


Oracle 10g
SQL > VAR OHM VARCHAR2(100);
SQL > EXEC DBMS_SYSTEM.GET_ENV('ORACLE_HOME', :OHM) ;
SQL > PRINT OHM ;


Linux/Unix echo $ORACLE_HOME
If we  fire command  ps -ef | grep tns
then tns entry details and also shows full path of oracle home.Because if env is not set then echo$ORACLE_HOME does not work.


Windows :
1. Click Start > Run 
2. Type "regedit" and press Return/Enter
3. The registry will now be displayed
4. Expand the folder as HKEY_LOCAL_MACHINE – SOFTWARE – ORACLE

Database Objects

Database Objects

Here are some scripts related to Database Objects :

DATABASE CLUSTER NOTES:
  Owner - Owner of the table/cluster
  Tablespace - Name of the tablespace containing the cluster
  Cluster Name - Name of the cluster
  Table Name - Clustered table name
  Table Column - Key column in the table
  Cluster Column - Key column in the cluster

SQL> select a.OWNER,TABLESPACE_NAME, a.CLUSTER_NAME,
           TABLE_NAME,TAB_COLUMN_NAME,CLU_COLUMN_NAME
           from    dba_clusters a, dba_clu_columns b
           where   a.CLUSTER_NAME = b.CLUSTER_NAME
           order   by a.OWNER,TABLESPACE_NAME,a.CLUSTER_NAME,TABLE_NAME ;

DATABASE JOB NOTES :
  Log User - USER who was logged in when the job was submitted.
  Schema - Default schema used to parse the job. For example, if the SCHEMA_USER is SCOTT and you submit the procedure HIRE_EMP as a job, Oracle looks for SCOTT.HIRE_EMP.
  Job# - Identifier of job. Neither import/export nor repeated executions change it.
  Interval - A date function, evaluated at the start of execution, becomes next NEXT_DATE.
  Next Execution - Date/time that this job will next be executed.
  Broken - If Y, no attempt is made to run this job. See DBMS_JOBQ.BROKEN (JOB).
  What - Body of the anonymous PL/SQL block that this job executes.

SQL> select LOG_USER, SCHEMA_USER schema,JOB job#, INTERVAL,
           to_char(NEXT_DATE,'MM/DD/YYYY HH24:MI:SS') next_execution,
           BROKEN, substr(WHAT,1,100) what
            from    dba_jobs order   by LOG_USER

DATABASE LINK NOTES:
  Owner - Owner of the database link
  DBLink - Name of the database link
  Username - Name of user to log in as
  Host - SQL*Net string for connect
  Created - Creation time of the database link

SQL> select OWNER,DB_LINK,USERNAME, HOST,
           to_char(CREATED,'MM/DD/YYYY HH24:MI:SS') created
           from    dba_db_links  order   by OWNER,DB_LINK ; 

DATABASE PROCEDURE/PACKAGE NOTES : 
  Owner - Owner of the object
  Name - Name of the object
  Type - Type of object

SQL> select  OWNER, NAME, TYPE from  dba_source
           group   by OWNER,NAME,TYPE
           order   by OWNER,NAME,TYPE ; 

DATABASE SEQUENCE NOTES : 
  Owner - Owner of the sequence
  Name - Name of the sequence
  MinValue - Minimum value of the sequence
  MaxValue - Maximum value of the sequence
  Increment - Value by which sequence is incremented
  Cycle - Does sequence wrap around on reaching limit?
  Order - Are sequence numbers generated in order?
  Cache Size - Number of sequence numbers to cache
  Last Number - Last sequence number written to disk

SQL> select SEQUENCE_OWNER,SEQUENCE_NAME, MIN_VALUE,
        MAX_VALUE,INCREMENT_BY, CYCLE_FLAG, ORDER_FLAG,
        CACHE_SIZE, LAST_NUMBER  from dba_sequences
        where   SEQUENCE_OWNER not in ('SYS','SYSTEM')
        order   by SEQUENCE_OWNER,SEQUENCE_NAME ;  

DATABASE SNAPSHOT NOTES : 
  Owner - Owner of the snapshot
  Name - The view used by users and applications for viewing the snapshot
  Table Name - Table the snapshot is stored in, has an extra column for the master rowid
  Master View - View of the master table, owned by the snapshot owner, used for refreshes
  Master Owner - Owner of the master table
  Master - Name of the master table of which this snapshot is a copy
  Master Link - Database link name to the master site
  Can Use Log - If NO, this snapshot is complex and will never use a log
  Updatable - If NO, the snapshot is read only
  Last Refresh - SYSDATE from the master site at the time of the last refresh
  Error - The number of failed automatic refreshes since last successful refresh
  Type - The type of refresh (complete, fast, force) for all automatic refreshes
  Next Refresh - The date function used to compute next refresh dates
  Refresh Group - GROUP All snapshots in a given refresh group get refreshed in the same transaction

SQL> select  OWNER,NAME, TABLE_NAME, MASTER_VIEW, MASTER_OWNER,
        MASTER, MASTER_LINK, CAN_USE_LOG, UPDATABLE, LAST_REFRESH,
        ERROR,  TYPE, NEXT, REFRESH_GROUP  from    dba_snapshots
          order   by OWNER,NAME ; 

DATABASE SYNONYM NOTES :  
  Owner - Owner of the synonym
  Name - Name of the synonym
  Table Owner - Owner of the table
  Table Name - Name of the table
  DB Link - Name of the database link

SQL> select  OWNER, SYNONYM_NAME, TABLE_OWNER,
            TABLE_NAME,DB_LINK from    dba_synonyms
            where   owner not in ('SYS','SYSTEM','PUBLIC','DBSNMP')
           order   by OWNER,SYNONYM_NAME ;    

DATABASE TRIGGER NOTES  :
  Table Owner - Owner of the table
  Table Name - Name of the table
  Trigger Name - Name of the trigger
  Trigger Name - When the trigger fires (BEFORE EACH ROW, AFTER EACH ROW, BEFORE STATEMENT, AFTER STATEMENT)
  Triggering Event - Statement that fires the trigger (INSERT, UPDATE, DELETE)
  Status - Whether the trigger is enabled (ENABLED or DISABLED)

SQL> select TABLE_OWNER, TABLE_NAME, TRIGGER_NAME, TRIGGER_TYPE,
           TRIGGERING_EVENT, STATUS from    dba_triggers
          order   by TABLE_NAME, TRIGGER_NAME; 

DATABASE VIEW NOTES :
  Owner - Owner of the view
  View Name - Name of the view
  Created - Date/time view was created
  Status - Status of the view

SQL> select OWNER, OBJECT_NAME,to_char(CREATED,'MM/DD/YYYY HH24:MI:SS') created,
        status from    dba_objects  where   OWNER not in ('SYS','SYSTEM') and              OBJECT_TYPE='VIEW'  order   by OWNER,OBJECT_NAME ; 


Move all the Indexes of Schema to Different Tablespace

Move all the Indexes of Schema to Different Tablespace


Once my friend ask me  " Is it beneficial to move all indexes of schema to other tablespace  " .
The answered depends on what you're trying to accomplish.There would be no performance benefit to doing this. There would almost certainly be no reliability/ recoverability benefit. There may be some benefit to the DBA's sense of organization but it's exceptionally unlikely that there will be any practical benefits.

If he really need that then he may do this :

BEGIN
  FOR idx IN (SELECT * FROM dba_indexes WHERE owner = <<schema name>> AND tablespace_name = <<old tablespace name>>)
  LOOP
    EXECUTE IMMEDIATE 'ALTER INDEX ' || idx.owner || '.' || idx.index_name || ' REBUILD TABLESPACE <<new tablespace name>>';
  END LOOP;
END;

Estimate Oracle Database Size

Estimate Oracle Database Size

Oracle database is consists of datafiles, controlfiles and redolog files . Therefore , the size of oracle database can be calculated by adding above files. The below script will estimate the oracle database size .

SQL> select a.datafile_size + b.temp_size + c.redo_size d.controlfile_size  "Total_size in GB"
from ( select sum(bytes)/1024/1024/1024  as datafile_size 
from dba_data_files) a,
( select nvl(sum(bytes),0)/1024/1024/1024 as temp_size 
from dba_temp_files ) b,
( select sum(bytes)/1024/1024/1024 as  redo_size
from sys.v_$log ) c,
( select sum(BLOCK_SIZE*FILE_SIZE_BLKS)/1024/1024/1024 as  controlfile_size 
from v$controlfile) d
output :

Total_size in GB
----------------
       1.9475708

How to find startup & shutdown time of Oracle Database

How to find startup & shutdown time of Oracle Database


Sometimes, we have to determine the startup and shutdown history of a database . There is no any data-dictionary  tables which contains the history of startup and shutdown time . Sometimes a system administrator reboot server in such cases we can determines the startup and shutdown time by checking the alert logfile. Since alert logfile keeps on increasing and we manages the alert logfile either by truncate or deleting its contains . 

Instead of depending on alert logfile , we can create table which contains the history of startup and shutdown by using the triggers . Here we will create two triggers i.e, first trigger will fired once the database is startup and second trigger is fired when database is shutdown . Let's have a  look . 

1.) Create a table to store history
SQL> create table db_history ( time date , event  varchar2(12)) ;
Table created.

2.) Create trigger for catching startup time 
SQL>create or replace trigger dbhist_start_trigr
after startup on database 
begin
insert into db_history values (sysdate , 'StartUp' ) ;
end ; 
/
Trigger created.

3.) Create Trigger to catch shutdown time 
SQL> create or replace trigger dbhist_shut_trigr
before shutdown on database
begin
insert into db_history values (sysdate, 'ShutDown' ) ;
end;
/
Trigger created

Table_exists_action Parameter of Data Pump

Table_exists_action Parameter of Data Pump

Sometimes it happens that we need to import table into an existing table.If we import the table in that schemas it throws error regarding the existence of the particular table.If we have to preserve the old data of table and append the new data,we can use the table_exists_action parameter of data pump.The valid key words are {SKIP | APPEND | TRUNCATE | REPLACE}.

The possible values of the following effects are :

1.) SKIP  : leaves the table as is and moves on to the next object. This is not a valid option if the CONTENT parameter is set to DATA_ONLY.By default the value is SKIP .

2.) APPEND loads rows from the source and leaves existing rows unchanged.

3.) TRUNCATE deletes existing rows and then loads rows from the source.

4.) REPLACE drops the existing table and then creates and loads it from the source. This is not a valid option if the CONTENT parameter is set to DATA_ONLY.

Here is a  DEMO of the TABLE_EXISTS_ACTION parameter  :

First of all we will take the export table (say test ) which is in neer schemas.

C:\>expdp system/xxxx@noida directory=dpump tables=neer.test dumpfile=neer_test.dmp logfile=exp_neerlog.log
Export: Release 11.1.0.6.0 - Production on Tuesday, 19 April, 2011 13:21:28
Copyright (c) 2003, 2007, Oracle.  All rights reserved.
Connected to: Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
Starting "SYSTEM"."SYS_EXPORT_TABLE_01":  system/********@noida directory=dpump tables=neer.test dumpfile=neer_test.dmp logfile=exp_neerlog.log
Estimate in progress using BLOCKS method...
Processing object type TABLE_EXPORT/TABLE/TABLE_DATA
Total estimation using BLOCKS method: 64 KB
Processing object type TABLE_EXPORT/TABLE/TABLE
. . exported "NEER"."TEST"                               5.062 KB       9 rows
Master table "SYSTEM"."SYS_EXPORT_TABLE_01" successfully loaded/unloaded
******************************************************************************
Dump file set for SYSTEM.SYS_EXPORT_TABLE_01 is:
  D:\DPUMP\NEER_TEST.DMP
Job "SYSTEM"."SYS_EXPORT_TABLE_01" successfully completed at 13:23:13

Now we consider each of the valid keywords of  action_exists_append parameter.

Case 1 : action_exists_append=skip (by defaults)

C:\>impdp system/xxxx@noida directory=dpump full=y  dumpfile=neer_test.dmp logfile=imp_neerlog.log
Import: Release 11.1.0.6.0 - Production on Tuesday, 19 April, 2011 13:32:22
Copyright (c) 2003, 2007, Oracle.  All rights reserved.
Connected to: Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
Master table "SYSTEM"."SYS_IMPORT_FULL_01" successfully loaded/unloaded
Starting "SYSTEM"."SYS_IMPORT_FULL_01":  system/********@noida directory=dpump full=y dumpfile=neer_test.dmp logfile=imp_neerlog.log
Processing object type TABLE_EXPORT/TABLE/TABLE
ORA-39151: Table "NEER"."TEST" exists. All dependent metadata and data will be skipped due to table_exists_action of skip
Processing object type TABLE_EXPORT/TABLE/TABLE_DATA
Job "SYSTEM"."SYS_IMPORT_FULL_01" completed with 1 error(s) at 13:32:35

Hence, above results shows that the table is skipped .

Case 2 : table_exists_action=append  
Now we delete the table test and recreate populate it values.

SQL> drop table test;
Table dropped.
SQL> create table test (id number);
Table created.

SQL> insert into test values (&Y);
Enter value for y: 111
old   1: insert into test values (&Y)
new   1: insert into test values (123)
1 row created.

SQL> /
Enter value for y: 222
old   1: insert into test values (&Y)
new   1: insert into test values (234)
1 row created.

SQL> /
Enter value for y: 333
old   1: insert into test values (&Y)
new   1: insert into test values (345)
1 row created.

SQL> commit;
Commit complete.

SQL> select * from test;
        ID
----------
       111
       222
       333

Now we will import the dump in neer schemas having table "test"

SQL>HOST impdp system/xxxx@noida directory=dpump dumpfile=NEER_TEST.dmp table_exists_action=append
Import: Release 11.1.0.6.0 - Production on Tuesday, 19 April, 2011 14:22:39
Copyright (c) 2003, 2007, Oracle.  All rights reserved.
Connected to: Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
Master table "SYSTEM"."SYS_IMPORT_FULL_01" successfully loaded/unloaded
Starting "SYSTEM"."SYS_IMPORT_FULL_01":  system/********@noida directory=dpump dumpfile=NEER_TEST.dmp table_exists_action=append
Processing object type TABLE_EXPORT/TABLE/TABLE
ORA-39152: Table "NEER"."TEST" exists. Data will be appended to existing table but all dependent metadata will be skipped due to table_exists_action of append
Processing     object type         TABLE_EXPORT/TABLE/TABLE_DATA
. . imported "NEER"."TEST"                               5.062 KB       9 rows
Job "SYSTEM"."SYS_IMPORT_FULL_01" completed with 1 error(s) at 14:22:58

SQL> select * from test;
        ID
----------
       111
       222
       333
        11
        22
        33
        44
        55
        66
        77
        88

        ID
----------
        99
12 rows selected.

Hence we find that the imported table appends in existing table . This parameter only import the data of the tables and skips the indexes  .

Case 3 :  table_exists_action=truncate
we have already 12 rows in table "test" .Now we again import the dump having 9 rows.

SQL>host impdp system/xxxx@noida directory=dpump dumpfile=NEER_TEST.dmp table_exists_action=truncate
Import: Release 11.1.0.6.0 - Production on Tuesday, 19 April, 2011 14:26:35
Copyright (c) 2003, 2007, Oracle.  All rights reserved.
Connected to: Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
Master table "SYSTEM"."SYS_IMPORT_FULL_01" successfully loaded/unloaded
Starting "SYSTEM"."SYS_IMPORT_FULL_01":  system/********@noida directory=dpump dumpfile=NEER_TEST.dmp table_exists_action=truncate
Processing object type TABLE_EXPORT/TABLE/TABLE
ORA-39153: Table "NEER"."TEST" exists and has been truncated. Data will be loaded but all dependent metadata will be skipped due to table_exists_action of truncate
Processing object type TABLE_EXPORT/TABLE/TABLE_DATA
. . imported "NEER"."TEST"                               5.062 KB       9 rows
Job "SYSTEM"."SYS_IMPORT_FULL_01" completed with 1 error(s) at 14:26:51

SQL> select * from test;
        ID
----------
        11
        22
        33
        44
        55
        66
        77
        88
        99
9 rows selected.

Case 4  : table_exists_action= replace 
Now we will add few rows in table "test" to check the results.

SQL> insert into test values(1234);
1 row created.
SQL> insert into test values(12345);
1 row created.
SQL> insert into test values(34567);
1 row created.
SQL> commit;
Commit complete.

SQL> select * from test;
        ID
----------
        11
        22
        33
        44
        55
        66
        77
        88
        99
      1234
     12345
     34567
12 rows selected.

SQL>host impdp system/xxxx@noida directory=dpump dumpfile=NEER_TEST.dmp table_exists_action=replace
Import: Release 11.1.0.6.0 - Production on Tuesday, 19 April, 2011 14:33:23
Copyright (c) 2003, 2007, Oracle.  All rights reserved.
Connected to: Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
Master table "SYSTEM"."SYS_IMPORT_FULL_01" successfully loaded/unloaded
Starting "SYSTEM"."SYS_IMPORT_FULL_01":  system/********@noida directory=dpump dumpfile=NEER_TEST.dmp table_exists_action=replace
Processing object type TABLE_EXPORT/TABLE/TABLE
Processing object type TABLE_EXPORT/TABLE/TABLE_DATA
. . imported "NEER"."TEST"                               5.062 KB       9 rows
Job "SYSTEM"."SYS_IMPORT_FULL_01" successfully completed at 14:33:42

SQL> select  *  from test ; 
        ID
----------
        11
        22
        33
        44
        55
        66
        77
        88
        99
9 rows selected.

Hence, table_exists_action=replace parameter internally drop and recreate the table .Hence all the existing metadata also  get dropped and is recreated .
Note: Parameter table_exists_action=replace for a job with no metadata will not get imported .


How to gather statistics on data dictionary objects in Oracle

How to gather statistics on data dictionary objects in Oracle


Before Oracle database 10g ,Oracle   explicitly recommended   not  to   gather   statistics   on  data dictionary   objects . As   of   Oracle database 10g   Oracle   explicitly does   recommend to   gather statistics on   data    dictionary   objects. As   we   might   know, there   is an   automatically   created   SCHEDULER JOB    in every   10g database   which runs   every night and   checks    for object    which   have either no statistics   at   all   or   for   which   the statistics   have   become   STALE   (which  means stat    at   least 10%   of   the  values have changed).   This   job   is   call GATHER_STATS_JOB and    belongs   to   the autotask   job   class.   

It   uses   a   program   which   again   call   a   procedure   from   built    in package DBMS_STATS   which does   the   statistics   collection. This   feature   only   works   if   the   initialization   parameter   STATISTICS_LEVEL   is   set to TYPICAL at   least   (which is the DEFAULT in 10g) and  it utilizes the TABLE MONITORING feature . TABLE  MONITORING is   enabled for  all tables in 10g by DEFAULT.

One question may come in our mind that  “Does  this job also collect   statistics on the data dictionary objects as well?” The answer is  “YES, it does!” and here is the proof  for this . First let us check if dbms_stats.gather_database_stats collect statistics for the data dictionary:

SQL> select count(*) from tab$;

COUNT(*) 
--------------
1227
SQL> create table t2 (col1 number);
Table created.

SQL> select count(*) from tab$;
COUNT(*)      
---------------
 1228

SQL> select NUM_ROWS from dba_tables where table_name=’TAB$’;
NUM_ROWS
------------------
1213

SQL> exec dbms_stats.gather_database_stats;
PL/SQL procedure successfully completed.

SQL> select NUM_ROWS from dba_tables where table_name=’TAB$’;   
 NUM_ROWS
-------------------
1228             
IT DOES! – and now let’s see if the job does also: 

SQL> create table t3 (col1 number);
Table created.

SQL> create table t4 (col1 number);
Table created.

SQL> select NUM_ROWS from dba_tables where table_name=’TAB$’;
NUM_ROWS
--------------
1228

Now  gather_stats_job run manually from DATABASE CONTROL !!! 

SQL> select NUM_ROWS from dba_tables where table_name=’TAB$’;
NUM_ROWS
-----------------
1230

and IT ALSO DOES! 
Even  though  there were  not  even 0.1%  of  the values changed it did!  So when should we gather statistics for the data dictionary manually? Oracle recommends to collect them when a significant  number of changes  were applied  to the data  dictionary,   like  dropping  significant  numbers  of  part ions  and creating new ones dropping tables, indexes, creating new ones and so on. But this only if it  is a significant number of changes and we cannot wait for the next automatically scheduled job run

How full is the current redo log file?

How full is the current redo log file?


Here is a query that can tell us how full the current redo log file is. This is useful  when we  need to predict when the next log file will be archived out.

SQL> SELECT le.leseq                      "Current log sequence No",
          100*cp.cpodr_bno/le.lesiz         "Percent Full",
           cp.cpodr_bno                            "Current Block No",
           le.lesiz                                       "Size of Log in Blocks"
           FROM   x$kcccp  cp,    x$kccle  le
           WHERE    le.leseq =CP.cpodr_seq
           AND  bitand(le.leflg,24) = 8 ;

Sample Output :
Current log sequence No      Percent Full        Current Block No         Size of Log in Blocks
-----------------------                -------------           -----------------             ---------------------
                  7                       18.1982422               18635                        102400