Tuesday, February 17, 2015

Upgrade the recovery catalog

If you created the recovery catalog owner in a release before 10gR1, and if the RECOVERY_CATALOG_OWNER role did not include the CREATE TYPE privilege, then grant it.

1. For example, start SQL*Plus, You can then execute the following GRANT statement:

SQL> GRANT CREATE TYPE TO rman;
SQL> EXIT;

2. Start RMAN and connect RMAN to the recovery catalog database.

3. Run the UPGRADE CATALOG command:

 RMAN> UPGRADE CATALOG;

recovery catalog owner is rman enter UPGRADE CATALOG command again to confirm catalog upgrade

4. Run the UPDATE CATALOG command again to confirm:

RMAN> UPGRADE CATALOG;


recovery catalog upgraded to version 11.01.00 DBMS_RCVMAN package upgraded to version 11.01.00 DBMS_RCVCAT package upgraded to version 11.01.00

Querying Details of Past and Current RMAN Jobs

An RMAN job is the set of commands executed within an RMAN session. Thus, one RMAN job can contain multiple commands. For example, you may execute two separate BACKUP commands and a RECOVER COPY command in a single session. An RMAN backup job is the set of BACKUP commands executed in one RMAN job. For example, a BACKUP DATABASE and BACKUP ARCHIVELOG ALL command executed in the same RMAN job constitute a single RMAN backup job.

The views V$RMAN_BACKUP_JOB_DETAILS and V$RMAN_BACKUP_SUBJOB_DETAILS and their corresponding recovery catalog versions provide details of RMAN backup jobs. For example, the views show how long a backup took, how many backup jobs have been issued, the status of each backup job (for example, whether it failed or completed), when a job started and finished, and what type of backup was performed. The SESSION_KEY column is the unique key for the RMAN session in which the backup job occurred.

RMAN backups often write less than they read. Because of RMAN compression, the OUTPUT_BYTES_PER_SEC column cannot be used as the measurement of backup speed. The appropriate column to measure backup speed is INPUT_BYTES_PER_SEC. The ratio between read and written data is described in the COMPRESSION_RATIO column.
To query details about past and current RMAN jobs:
  1. Connect SQL*Plus to the database whose backup history you intend to query.
  2. Query the V$RMAN_BACKUP_JOB_DETAILS view for information about the backup type, status, and start and end time.
The following query shows the backup job history ordered by session key, which is the primary key for the RMAN session:

COL STATUS FORMAT a9
COL hrs    FORMAT 999.99
SELECT SESSION_KEY, INPUT_TYPE, STATUS,
       TO_CHAR(START_TIME,'mm/dd/yy hh24:mi') start_time,
       TO_CHAR(END_TIME,'mm/dd/yy hh24:mi')   end_time,
       ELAPSED_SECONDS/3600                   hrs
FROM V$RMAN_BACKUP_JOB_DETAILS
ORDER BY SESSION_KEY;
The following sample output shows the backup job history:
SESSION_KEY INPUT_TYPE    STATUS    START_TIME     END_TIME           HRS
----------- ------------- --------- -------------- -------------- -------
          9 DATAFILE FULL COMPLETED 04/18/07 18:14 04/18/07 18:15     .02
         16 DB FULL       COMPLETED 04/18/07 18:20 04/18/07 18:22     .03
        113 ARCHIVELOG    COMPLETED 04/23/07 16:04 04/23/07 16:05     .01
  1. Query the V$RMAN_BACKUP_JOB_DETAILS view for the rate of backup jobs in an RMAN session.
The following query shows the backup job speed ordered by session key, which is the primary key for the RMAN session. The columns IN_SEC and OUT_SEC display the data input and output per second.

COL in_sec FORMAT a10
COL out_sec FORMAT a10
COL TIME_TAKEN_DISPLAY FORMAT a10
SELECT SESSION_KEY,
       OPTIMIZED,
       COMPRESSION_RATIO,
       INPUT_BYTES_PER_SEC_DISPLAY in_sec,
       OUTPUT_BYTES_PER_SEC_DISPLAY out_sec,
       TIME_TAKEN_DISPLAY
FROM   V$RMAN_BACKUP_JOB_DETAILS
ORDER BY SESSION_KEY;

The following sample output shows the speed of the backup jobs:
SESSION_KEY OPT COMPRESSION_RATIO IN_SEC     OUT_SEC    TIME_TAKEN
----------- --- ----------------- ---------- ---------- ----------
          9 NO                  1     8.24M      8.24M  00:01:14
         16 NO         1.32732239     6.77M      5.10M  00:01:45
        113 NO                  1     2.99M      2.99M  00:00:44
  1. Query the V$RMAN_BACKUP_JOB_DETAILS view for the size of the backups in an RMAN session.
If you run BACKUP DATABASE, then V$RMAN_BACKUP_JOB_DETAILS.OUTPUT_BYTES shows the total size of backup sets written by the backup job for the database that you are backing up. To view backup set sizes for all registered databases, query V$RMAN_BACKUP_JOB_DETAILS.
The following query shows the backup job size and throughput ordered by session key, which is the primary key for the RMAN session. The columns IN_SIZE and OUT_SIZE display the data input and output per second.

COL in_size  FORMAT a10
COL out_size FORMAT a10
SELECT SESSION_KEY,
       INPUT_TYPE,
       COMPRESSION_RATIO,
       INPUT_BYTES_DISPLAY in_size,
       OUTPUT_BYTES_DISPLAY out_size
FROM   V$RMAN_BACKUP_JOB_DETAILS
ORDER BY SESSION_KEY;

The following sample output shows the size of the backup jobs:
SESSION_KEY INPUT_TYPE    COMPRESSION_RATIO IN_SIZE    OUT_SIZE
----------- ------------- ----------------- ---------- ----------
         10 DATAFILE FULL                 1   602.50M    602.58M
         17 DB FULL              1.13736669   634.80M    558.13M


Sunday, February 15, 2015

Sql Query to locate the long running operations in database

select sid
      , username
      , opname
      ,target
      , decode(totalwork,0,0,null,0,sofar*100/totalwork) progress
      , totalwork
      , units
      , start_time
      , elapsed_seconds
      ,sql_id
from v$session_longops
order by sid, start_time

Saturday, February 14, 2015

Restoring a NOARCHIVELOG Database to a New Location

In this scenario, you restore the database files to an alternative location because the original location is damaged by a media failure.

To restore the most recent whole database backup to a new location:
If the database is open, then shut it down. For example, enter:
SHUTDOWN IMMEDIATE

Restore all of the datafiles and control files of the whole database backup, not just the damaged files. If the hardware problem has not been corrected and some or all of the database files must be restored to alternative locations, then restore the whole database backup to a new location. For example, enter:
% cp /backup/*.dbf /new_disk/oradata/trgt/

If necessary, edit the restored parameter file to indicate the new location of the control files. For example:
CONTROL_FILES = "/new_disk/oradata/trgt/control01.dbf"

Start an instance using the restored and edited parameter file and mount, but do not open, the database. For example:
STARTUP MOUNT

If the restored datafile filenames will be different (as will be the case when you restore to a different file system or directory, on the same node or a different node), then update the control file to reflect the new datafile locations. For example, to rename datafile 1 you might enter:
ALTER DATABASE RENAME FILE '?/oradata/trgt/system01.dbf' TO
                           '/new_disk/oradata/system01.dbf';

If the online redo logs were located on a damaged disk, and the hardware problem is not corrected, then specify a new location for each affected online log. For example, enter:
ALTER DATABASE RENAME FILE '?/oradata/trgt/redo01.log' TO
                           '/new_disk/oradata/redo_01.log';
ALTER DATABASE RENAME FILE '?/oradata/trgt/redo02.log' TO
                           '/new_disk/oradata/redo_02.log';

Because online redo logs are not backed up, you cannot restore them with the datafiles and control files. In order to allow the database to reset the online redo logs, you must first mimic incomplete recovery:
RECOVER DATABASE UNTIL CANCEL;
CANCEL;

Open the database in RESETLOGS mode. This command clears the online redo logs and resets the log sequence to 1:
ALTER DATABASE OPEN RESETLOGS;

Note that restoring a NOARCHIVELOG database backup and then resetting the log discards all changes to the database made from the time the backup was taken to the time of the failure.

Making an Index Unusable

When you make an index unusable, it is ignored by the optimizer and is not maintained by DML. When you make one partition of a partitioned index unusable, the other partitions of the index remain valid.

You must rebuild or drop and re-create an unusable index or index partition before using it.
The following procedure illustrates how to make an index and index partition unusable, and how to query the object status.

To make an index unusable: 
  1. Query the data dictionary to determine whether an existing index or index partition is usable or unusable.
For example, issue the following query (output truncated to save space):

hr@PROD> SELECT INDEX_NAME AS "INDEX OR PART NAME", STATUS, SEGMENT_CREATED
  2  FROM   USER_INDEXES
  3  UNION ALL
  4  SELECT PARTITION_NAME AS "INDEX OR PART NAME", STATUS, SEGMENT_CREATED
  5  FROM   USER_IND_PARTITIONS;

INDEX OR PART NAME             STATUS   SEG
------------------------------ -------- ---
I_EMP_ENAME                    N/A      N/A
JHIST_EMP_ID_ST_DATE_PK        VALID    YES
JHIST_JOB_IX                   VALID    YES
JHIST_EMPLOYEE_IX              VALID    YES
JHIST_DEPARTMENT_IX            VALID    YES
EMP_EMAIL_UK                   VALID    NO
.
.
.
COUNTRY_C_ID_PK                VALID    YES
REG_ID_PK                      VALID    YES
P2_I_EMP_ENAME                 USABLE   YES
P1_I_EMP_ENAME                 UNUSABLE NO

22 rows selected.

The preceding output shows that only index partition p1_i_emp_ename is unusable.
  1. Make an index or index partition unusable by specifying the UNUSABLE keyword.
The following example makes index emp_email_uk unusable:

hr@PROD> ALTER INDEX emp_email_uk UNUSABLE;

Index altered.

The following example makes index partition p2_i_emp_ename unusable:

hr@PROD> ALTER INDEX i_emp_ename MODIFY PARTITION p2_i_emp_ename UNUSABLE;

Index altered.
  1. Optionally, query the data dictionary to verify the status change.
For example, issue the following query (output truncated to save space):

hr@PROD> SELECT INDEX_NAME AS "INDEX OR PARTITION NAME", STATUS,
  2  SEGMENT_CREATED
  3  FROM   USER_INDEXES
  4  UNION ALL
  5  SELECT PARTITION_NAME AS "INDEX OR PARTITION NAME", STATUS,
  6  SEGMENT_CREATED
  7  FROM   USER_IND_PARTITIONS;

INDEX OR PARTITION NAME        STATUS   SEG
------------------------------ -------- ---
I_EMP_ENAME                    N/A      N/A
JHIST_EMP_ID_ST_DATE_PK        VALID    YES
JHIST_JOB_IX                   VALID    YES
JHIST_EMPLOYEE_IX              VALID    YES
JHIST_DEPARTMENT_IX            VALID    YES
EMP_EMAIL_UK                   UNUSABLE NO
.
.
.
COUNTRY_C_ID_PK                VALID    YES
REG_ID_PK                      VALID    YES
P2_I_EMP_ENAME                 UNUSABLE NO
P1_I_EMP_ENAME                 UNUSABLE NO

22 rows selected.

A query of space consumed by the i_emp_ename and emp_email_uk segments shows that the segments no longer exist:

hr@PROD> SELECT SEGMENT_NAME, BYTES
  2  FROM   USER_SEGMENTS
  3  WHERE  SEGMENT_NAME IN ('I_EMP_ENAME', 'EMP_EMAIL_UK');


no rows selected

Rebuilding an Existing Index

Before rebuilding an existing index, compare the costs and benefits associated with rebuilding to those associated with coalescing indexes.

When you rebuild an index, you use an existing index as the data source. Creating an index in this manner enables you to change storage characteristics or move to a new tablespace. Rebuilding an index based on an existing data source removes intra-block fragmentation. Compared to dropping the index and using the CREATE INDEX statement, re-creating an existing index offers better performance.

The following statement rebuilds the existing index emp_name:

SQL> ALTER INDEX emp_name REBUILD;

The REBUILD clause must immediately follow the index name, and precede any other options. It cannot be used with the DEALLOCATE UNUSED clause.

If have the option of rebuilding the index online. The following statement rebuilds the emp_name index online:

SQL> ALTER INDEX emp_name REBUILD ONLINE;

If you do not have the space required to rebuild an index, you can choose instead to coalesce the index. Coalescing an index can also be done online.

Sunday, February 8, 2015

ORA-00020: maximum number of processes 150 exceeded

PROCESSES specifies the maximum number of operating system user processes that can simultaneously connect to Oracle

SQL> show parameter processes

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
processes                            integer     150

SQL> alter system set processes=250 scope=spfile;
System altered.
(the new value takes effect the next time you start an instance of the database.)

if you issue:
SQL> alter system set processes=250 scope=both;
alter system set processes=250 scope=both
                 *
ERROR at line 1:
ORA-02095: specified initialization parameter cannot be modified

after you restart database query for the changes

SQL> select * from gv$resource_limit;
or
SQL>show parameter processes

Thursday, February 5, 2015

Unable to Start / Connect Enterprise Manager dbconsole

step: localhost_<sid> directory
Go to the location <ORACLE_HOME>\
locate localhost_<sid> directory copy and paste
rename the directory with ipaddress example: 192.168.1.62_mydb1

step:  OC4J_DBConsole directory
Go to the location <ORACLE_HOME\oc4j\j2ee
locate OC4J_DBConsole_localhost_<sid> directory copy and paste
rename the directory with ipaddress example: OC4J_DBConsole_192.168.1.62_mydb1

step: Set the enviornment
ORACLE_SID=MYDB1
ORACLE_UNQNAME=MYDB1

step: Start the emctl dbconsole
emctl start dbconsole

step: open the internet browser
https:\\192.168.1.62:1158\em (or) https:\\192.168.1.62:5500\em\console ( as per your configured port)