How to find an Index size

select segment_name,segment_type,bytes/1024/1024 MB
 from dba_segments
 where segment_type='INDEX' and segment_name='your_index_name';

How to find a table size

select segment_name,segment_type,bytes/1024/1024 MB
 from dba_segments
 where segment_type='TABLE' and segment_name='your_table_name';

Script to see Database Size

COLUMN "Total Mb" FORMAT 999,999,999.0
COLUMN "Redo Mb" FORMAT 999,999,999.0
COLUMN "Temp Mb" FORMAT 999,999,999.0
COLUMN "Data Mb" FORMAT 999,999,999.0


SELECT (SELECT Sum(bytes / 1048576)
        FROM   dba_data_files) "Data Mb",
       (SELECT Nvl(Sum(bytes / 1048576), 0)
        FROM   dba_temp_files) "Temp Mb",
       (SELECT Sum(bytes / 1048576) * Max(members)
        FROM   v$log)          "Redo Mb",
       (SELECT Sum(bytes / 1048576)
        FROM   dba_data_files)
       + (SELECT Nvl(Sum(bytes / 1048576), 0)
          FROM   dba_temp_files)
       + (SELECT Sum(bytes / 1048576) * Max(members)
          FROM   v$log)        "Total Mb"
FROM   dual; 

Active session information

    SELECT SID, Serial#, UserName, Status, SchemaName, Logon_Time
    FROM V$Session
    WHERE
    Status='ACTIVE' AND
    UserName IS NOT NULL;

Multiplexing Controlfile through RMAN in RAC

Login to the first node

column is_recovery_dest_file format a25
column name format a60
set linesize 160
select status, name, is_recovery_dest_file from v$controlfile;


check the control file status and names using the above quey,


i my case i had


STATUS  NAME                                                         IS_RECOVERY_DEST_FILE
------- ------------------------------------------------------------ -------------------------
        +DATA_RAJ/rajesh/controlfile/current.986.790135655           NO

hence ,

login in to sqlplus , and alter the system as below with your new place pointed to

alter system set control_files = '+DATA_RAJ/rajesh/controlfile/current.986.790135655','+RECO_RAJ' scope=spfile sid='*';


in my case i have the data and reco groups created on the asm, hence trying to place the controlfiles in to two different disk groups.


once alterd the system , shutdown the instance using srvctl


srvctl stop database -d xxx

after then , login to sql prmpt and startup the instance in no mount stage , once the db came up on nomount stage exit from the sql prompt and login in rman prompt

example

rman

connect  target

restore controlfile from '+DATA_RAJ/rajesh/controlfile/current.986.790135655';


it will restore/multiplex our control file to the existing and our new path. once the restore complete, shutdown the instances and startup normal

it should come up with the two controlfiles,

issues i was facing here were, one of the instance spfile was not on the shared drive hence i was failing on the below command

alter system set control_files = '+DATA_RAJ/rajesh/controlfile/current.986.790135655','+RECO_RAJ' scope=spfile sid='*';


as spfile could not be modifiable etc ... after which i have mounted the spfile on the shared drive and followed the same

Good Luck !!


Thanks

How to backup oracle home

Follow the steps to backup oracle home


say if u have the oracle home like /opt/oracle/product/11.2.0/ then the binaries , and let say u want to have the home backup taken to some backup directory

cd to the home directory

cd /opt/oracle/product/11.2.0

and then issue

tar -cvf - . |compress > /backup/11.2.0.tar.Z


if u want to untar it

u use tar -xvf

How to Clean Up Duplicate Objects Owned by SYS and SYSTEM Schema

Refference with the document How to Clean Up Duplicate Objects Owned by SYS and SYSTEM Schema [ID 1030426.6]


Hi Had faced an issue where the database was created manually some way got corrupted when running the immediate scripts after the db creation catproc/catalog like the pupbld etc ..


due with that i was getting issues like memory issue 4031 , and even i am not able to query the dba tables or the register views, followed the above document that resolved the issue simply the below were the steps that i followed


Below is a SQL*Plus script that will list all objects that have been created in both the SYS and SYSTEM schema: 

column object_name format a30
select object_name, object_type
from dba_objects
where object_name||object_type in
   (select object_name||object_type 
    from dba_objects
    where owner = 'SYS')
and owner = 'SYSTEM';


The output from this script will either be 'zero rows selected' or will look something like the following:
OBJECT_NAME                OBJECT_TYPE
------------------------------ -------------
ALL_DAYS                       VIEW
CHAINED_ROWS                   TABLE
COLLECTION                     TABLE
COLLECTION_ID                  SEQUENCE
DBA_LOCKS                      SYNONYM
DBMS_DDL                       PACKAGE
DBMS_SESSION                   PACKAGE
DBMS_SPACE                     PACKAGE
DBMS_SYSTEM                    PACKAGE
DBMS_TRANSACTION               PACKAGE
DBMS_UTILITY                   PACKAGE


If the select statement returns any rows then this is an indication that at least 1 script has been run as both SYS and SYSTEM.

Since most data dictionary objects should be owned by SYS (see exceptions below) you will want to drop the objects that are owned by SYSTEM in order to clear up this situation.


EXCEPTION TO THE RULE

THE REPLICATION SCRIPTS (XXX) CORRECTLY CREATES OBJECTS WITH THE SAME NAME IN THE SYS AND SYSTEM ACCOUNTS. LISTED BELOW ARE THE OBJECTS USED BY REPLICATION THAT SHOULD BE CREATED IN BOTH ACCOUNTS. DO NOT DROP THESE OBJECTS FROM THE SYSTEM ACCOUNT IF YOU ARE USING REPLICATION. DOING SO WILL CAUSE REPLICATION TO FAIL!

The following objects are duplicates that will show up (and should not be removed) when running this script in 8.1.x and higher.

Without replication installed:
INDEX           AQ$_SCHEDULES_PRIMARY
TABLE           AQ$_SCHEDULES

If replication is installed by running catrep.sql:
INDEX           AQ$_SCHEDULES_PRIMARY
PACKAGE         DBMS_REPCAT_AUTH
PACKAGE BODY    DBMS_REPCAT_AUTH
TABLE           AQ$_SCHEDULES

When database is upgraded to 11g using DBUA, following duplicate objects are also created
OBJECT_NAME                OBJECT_TYPE
------------------------------ -------------
Help                          TABLE
Help_Topic_Seq                  Index

The objects created by sqlplus/admin/help/hlpbld.sql must be owned by SYSTEM because when sqlplus retrieves the help information, it refers to the SYSTEM schema only. DBCA runs this script as SYSTEM user when it creates the database but DBUA runs this script as SYS user when upgrading the database (reported as an unpublished BUG 10022360).  You can drop the ones in SYS schema.

Now that you have a list of duplicate objects you will simply issue the appropriate DROP command to get rid of the object that is owned by the SYSTEM user.


If the list of objects is large then you may want to use the following SQL*Plus script to automatically generate an SQL script that contains the appropriate DROP commands:

set pause off
set heading off
set pagesize 0
set feedback off
set verify off
spool dropsys.sql
select 'DROP ' || object_type || ' SYSTEM.' || object_name || ';'
from dba_objects
where object_name||object_type in
   (select object_name||object_type 
    from dba_objects
    where owner = 'SYS')
and owner = 'SYSTEM';
spool off
exit


You will now have a file in the current directory named dropsys.sql that contains all of the DROP commands. You will need to run this script as a normal SQL script as follows:

$ sqlplus
SQL*Plus: Release 3.3.2.0.0 - Production on Thu May  1 14:54:20 1997
Copyright (c) Oracle Corporation 1979, 1994.  All rights reserved.
Enter user-name: system
Enter password: manager
SQL> @dropsys

Note: You may receive one or more of the following errors:
ORA-2266 (unique/primary keys in table referenced by enabled foreign keys): 
If you encounter this error then some of the tables you are dropping have constrints that prevent the table from being dropped. To fix this problem you will have to manually drop the objects in a different order than the script does.
     
ORA-2429 (cannot drop index used for enforcement of unique/primary key):
 This is similar to the ORA-2266 error except that it points to an index. You will have to manually disable the constraint associated with the index and then drop the index.

ORA-1418 (specified index does not exist):
 This occurs because the table that the index was created on  has already been dropped which also drops the index. When the script tries to drop the index it is no longer there and thus the ORA-1418 error. You can safely ignore this error.