Thursday, 28 November 2013

ORACLE 11203 RMAN Active Database Cloning without Source Backup



11203 RMAN Active Database Cloning without Source Backup:

Source database will be in Mount Stage (No ArchiveLog Mode) è SRCDB
Target Database will be In NoMount Stage while Active cloning:  è DUPB
Time Taken: 12mins for 180GB (Same Server with ASM DiskGroup) 

Steps Overview:

Step1: Source DB = Mount (NO ARCHIVE LOG)

Setp2: Target DB - Nomount  (Auxiliary)

Step3: RMAN -

run {
 ALLOCATE CHANNEL d1 TYPE DISK ;
 ALLOCATE CHANNEL d2 TYPE DISK ;
 ALLOCATE CHANNEL d3 TYPE DISK ;
 ALLOCATE AUXILIARY CHANNEL a1 TYPE DISK ;
 ALLOCATE AUXILIARY CHANNEL a2 TYPE DISK ;
 ALLOCATE AUXILIARY CHANNEL a3 TYPE DISK ;
 duplicate target database to DUPDB  from active database;
 }

Step 4: Copy the wallet encryption file from source db  to target db (if you having Wallet encryption in your database)

Step5: start the db in mount stage (after cloning) 

step6: open the wallet

step7: Alter database open;


Generating Pfile from Cloning Duplicate Database:

[oracle@MyServer ~]$ echo $ORACLE_SID
SRCDB
[oracle@MyServer ~]$ sqlplus '/as sysdba'
SQL> create pfile='/localfs/export/SRCDB/initSRCDB.ora' from spfile;
File created.
SQL> exit
Edit your PFILE:
[oracle@MyServer SRCDB]$ cp initSRCDB.ora initDUPDB.ora
[oracle@MyServer SRCDB]$ vi initDUPDB.ora           
*.audit_file_dest='/localfs/orasrc/admin/DUPDB/adump'
*.audit_trail='db'
*.compatible='11.2.0.0.0'
#*.control_files='/localfs/oradata/DUPDB/control01.ctl','/localfs/oradata/DUPDB/control02.ctl'
*.db_block_size=8192
*.db_domain='MYDOMAIN.ORG'
*.db_name='DUPDB'
*.diagnostic_dest='/localfs/orasrc'
*.dispatchers='(PROTOCOL=TCP) (SERVICE=DUPDBXDB)'
*.open_cursors=300
*.pga_aggregate_target=235929600
*.processes=150
*.remote_login_passwordfile='EXCLUSIVE'
*.sga_target=707788800
*.undo_tablespace='UNDOTBS1'
db_file_name_convert='/localfs/oradata/SRCDB/','/localfs/oradata/DUPDB/'
log_file_name_convert='/localfs/oradata/SRCDB/','/localfs/oradata/DUPDB/'
 
Copy your Soruce Password file
[oracle@MyServer SRCDB]$ cd $ORACLE_HOME/dbs
[oracle@MyServer dbs]$ cp orapwSRCDB orapwDUPDB
[oracle@MyServer dbs]$ cd -
/localfs/export/SRCDB 
Creating Spfile:
[oracle@MyServer SRCDB]$ sqlplus '/as sysdba'
SQL*Plus: Release 11.2.0.2.0 Production on Tue Feb 19 04:14:33 2013
Copyright (c) 1982, 2010, Oracle.  All rights reserved.
Connected to an idle instance.
SQL> create spfile from pfile='/localfs/export/SRCDB/initDUPDB.ora';
File created. 
SQL> startup nomount;
ORACLE instance started.
Total System Global Area  705662976 bytes
Fixed Size                  2229840 bytes
Variable Size             201329072 bytes
Database Buffers          494927872 bytes
Redo Buffers                7176192 bytes
SQL> exit
Source Database Mount:
[oracle@MyServer admin]$ echo $ORACLE_SID
SRCDB 
SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup mount;
ORACLE instance started.
Total System Global Area  705662976 bytes
Fixed Size                  2229840 bytes
Variable Size             201329072 bytes
Database Buffers          494927872 bytes
Redo Buffers                7176192 bytes
Database mounted.
SQL> exit
My Listener Entries:
LSNR_DUPDB =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = MyServer.MYDOMAIN.ORG)(PORT = 1522))
  )
SID_LIST_LSNR_DUPDB =
  (SID_LIST =
    (SID_DESC =
      (GLOBAL_DBNAME = DUPDB.MYDOMAIN.ORG)
      (ORACLE_HOME = /localfs/orasrc/product/db/11.2.0.2)
      (SID_NAME = DUPDB)
    )
    (SID_DESC =
      (GLOBAL_DBNAME = SRCDB.MYDOMAIN.ORG)
      (ORACLE_HOME = /localfs/orasrc/product/db/11.2.0.2)
      (SID_NAME = SRCDB)
    )
  )
[oracle@MyServer admin]$ ps -ef | grep tns
oracle   28013     1  0 04:36 ?        00:00:00 /localfs/orasrc/product/db/11.2.0.2/bin/tnslsnr LSNR_DUPDB -inherit
Note:  NoMount Stage Database required the Seperate Listener to avoid the below error while cloning the database using RMAN Auxiliary connection
ORA-12528: TNS:listener: all appropriate instances are blocking new connections
My TnsName Entry:
SRCDB.MYDOMAIN.ORG =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = MyServer.MYDOMAIN.ORG)(PORT = 1522))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = SRCDB.MYDOMAIN.org)
    )
  )
DUPDB.MYDOMAIN.ORG =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = MyServer.MYDOMAIN.ORG)(PORT = 1522))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = DUPDB.MYDOMAIN.org)
    )
  )
=============================================================================
RMAN Execution:
[oracle@MyServer SRCDB]$ rman
Recovery Manager: Release 11.2.0.2.0 - Production on Tue Feb 19 04:40:54 2013
Copyright (c) 1982, 2009, Oracle and/or its affiliates.  All rights reserved.
RMAN> connect auxiliary sys/PassWd@DUPDB
connected to auxiliary database: DUPDB (not mounted)
RMAN> connect target sys/PassWd@SRCDB
connected to target database: SRCDB (DBID=523443299, not open)
RMAN> run
2>  {
3>  ALLOCATE CHANNEL d1 TYPE DISK ;
 ALLOCATE CHANNEL d2 TYPE DISK ;
4> 5>  ALLOCATE CHANNEL d3 TYPE DISK ;
6>  ALLOCATE AUXILIARY CHANNEL a1 TYPE DISK ;
7>  ALLOCATE AUXILIARY CHANNEL a2 TYPE DISK ;
8>  ALLOCATE AUXILIARY CHANNEL a3 TYPE DISK ;
9>  duplicate target database to DUPDB from active database;
10>  }
using target database control file instead of recovery catalog
allocated channel: d1
channel d1: SID=63 device type=DISK
allocated channel: d2
channel d2: SID=129 device type=DISK
allocated channel: d3
channel d3: SID=191 device type=DISK
allocated channel: a1
channel a1: SID=63 device type=DISK
allocated channel: a2
channel a2: SID=129 device type=DISK
allocated channel: a3
channel a3: SID=192 device type=DISK
Starting Duplicate Db at 19-FEB-13
contents of Memory Script:
{
   sql clone "alter system set  db_name =
 ''SRCDB'' comment=
 ''Modified by RMAN duplicate'' scope=spfile";
   sql clone "alter system set  db_unique_name =
 ''DUPDB'' comment=
 ''Modified by RMAN duplicate'' scope=spfile";
   shutdown clone immediate;
   startup clone force nomount
   backup as copy current controlfile auxiliary format  '/localfs/orasrc/product/db/11.2.0.2/dbs/cntrlDUPDB.dbf';
   alter clone database mount;
}
executing Memory Script
......
......
......
......
contents of Memory Script:
{
   Alter clone database open resetlogs;
}
executing Memory Script
database opened
Finished Duplicate Db at 19-FEB-13
released channel: d1
released channel: d2
released channel: d3
released channel: a1
released channel: a2
released channel: a3
RMAN> exit

Recovery Manager complete.
[oracle@MyServer SRCDB]$
=============================================================================
[oracle@MyServer ~]$ export ORACLE_SID=DUPDB
[oracle@MyServer ~]$ sqlplus '/as sysdba'
SQL*Plus: Release 11.2.0.2.0 Production on Tue Feb 19 04:45:02 2013
Copyright (c) 1982, 2010, Oracle.  All rights reserved.

Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
SQL> select open_mode from v$database;
OPEN_MODE
------------------------------------------------------------
READ WRITE
======================================================================


with and without AUTOBACKUP-Restoring the SPFILE

Let us look at some backup and recovery scenarios pertaining to the SPFIILE. The SPFILE is a small but very important file and if we lose the spfile, we cannot start the database even if all the other database files are present and intact.
So in my opinion, it is quite an important thing to consider in our disaster recovery strategy.
Remember best practise is to turn the autobackup of the control file to ON (it is OFF by default).
SPFILE is automatically backed up along with the database control file when any of the following events occur and when the control file autobackup has been enabled in RMAN. .
RMAN> show controlfile autobackup;

RMAN configuration parameters for database with db_unique_name GAVIN are:
CONFIGURE CONTROLFILE AUTOBACKUP ON;
When does the SPFILE gat backed up with AUTOBACKUP now tuned on?
  • After every BACKUP or CREATE CATALOG command
  • After every BACKUP command contained in a RUN block
  • After every structural change to the database occurs like adding a new tablespace, altering the state of a tablespace or datafile (for example, bringing it online), adding a new online redo log, renaming a file

Where does the SPFILE autobackup reside?
RMAN> show controlfile autobackup format ;

RMAN configuration parameters for database with db_unique_name GAVIN are:
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; # default
This is the default setting for CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK
By default, RMAN will send the autobackup to the flash recovery area (if used).
Let us now remove the default keyword
RMAN> CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F';

new RMAN configuration parameters:
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F';
new RMAN configuration parameters are successfully stored
In this case the SPFILE (and control file) autobackup is located anywhere you specify, but default location will be %ORACLE_HOME%\Database on Windows and $ORACLE_HOME/dbs on UNIX.
RMAN> list backup of spfile;

using target database control file instead of recovery catalog

List of Backup Sets
===================

BS Key  Type LV Size       Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
252     Full    9.73M      DISK        00:00:00     13-JUN-13
        BP Key: 267   Status: AVAILABLE  Compressed: NO  Tag: TAG20130613T144508
        Piece Name: /u01/app/oracle/product/11.2.0/dbhome_1/dbs/c-2968723077-20130613-00
Let us now specify an actual location on disk instead of just the %F,
RMAN> CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '/u01/backup/%F';

old RMAN configuration parameters:
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F';
new RMAN configuration parameters:
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '/u01/backup/%F';
new RMAN configuration parameters are successfully stored


RMAN> list backup of spfile;

using target database control file instead of recovery catalog

List of Backup Sets
===================


BS Key  Type LV Size       Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
256     Full    9.73M      DISK        00:00:01     13-JUN-13
        BP Key: 271   Status: AVAILABLE  Compressed: NO  Tag: TAG20130613T155004
        Piece Name: /u01/backup/c-2968723077-20130613-01
Note the SPFILE autobackup is now located at /u01/backup and we can see the format of the backup file on disk is no longer OMF.
The DBID (2968723077) and the timestamp (20130613) is now contained in the backup file name c-2968723077-20130613-01
Let us now revert the autobackup back to the FRA.
RMAN> CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK CLEAR;


old RMAN configuration parameters:
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F';
RMAN configuration parameters are successfully reset to default value

RMAN> show CONTROLFILE AUTOBACKUP FORMAT;

RMAN configuration parameters for database with db_unique_name GAVIN are:
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; # default


RMAN> list backup of spfile;

using target database control file instead of recovery catalog

List of Backup Sets
===================


BS Key  Type LV Size       Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
266     Full    9.73M      DISK        00:00:01     13-JUN-13
        BP Key: 281   Status: AVAILABLE  Compressed: NO  Tag: TAG20130613T162411
        Piece Name: /u01/app/oracle/fast_recovery_area/GAVIN/autobackup/2013_06_13/o1_mf_s_818007851_8vlsdd3n_.bkp
Autobackup is now back to OMF.
Recovery scenarios involving loss of SPFILE
Case 1) Autobackup in Flash (or now called Fast) Recovery Area
The SPFILE has accidently been deleted and now the database is not starting up after a shutdown has been executed.
FRA has been configured.
If FRA has been configured, the backup of the SPFILE is located in the autobackup sub-directory.
For example:
/u01/app/oracle/fast_recovery_area/GAVIN/autobackup/2013_06_10/ o1_mf_s_818007851_8vlsdd3n_.bkp
Note that it is stored in OMF format in this example. The ‘s’ in the string identifies the OMF as a backup related to the SPFILE
To recover from loss of SPFILE if you are NOT using an RMAN Catalog, we need to do two things first :
1) Set the DBID
2) Issue the STARTUP NOMOUNT FORCE command from an RMAN prompt (note – not SQL*PLUS)
RMAN> SET DBID=2968723077;

executing command: SET DBID

RMAN> startup force nomount;

startup failed: ORA-01078: failure in processing system parameters
LRM-00109: could not open parameter file '/u01/app/oracle/product/11.2.0/dbhome_1/dbs/initgavin.ora'

starting Oracle instance without parameter file for retrieval of spfile
Oracle instance started

Total System Global Area     158662656 bytes

Fixed Size                     2226456 bytes
Variable Size                104859368 bytes
Database Buffers              46137344 bytes
Redo Buffers                   5439488 bytes
This is a typical error we will face when either restoring the SPFILE or control file from an autobackup.
RMAN>  restore controlfile from autobackup;

Starting restore at 13-JUN-13
using channel ORA_DISK_1

channel ORA_DISK_1: looking for AUTOBACKUP on day: 20130613
channel ORA_DISK_1: looking for AUTOBACKUP on day: 20130612
channel ORA_DISK_1: looking for AUTOBACKUP on day: 20130611
channel ORA_DISK_1: looking for AUTOBACKUP on day: 20130610
channel ORA_DISK_1: looking for AUTOBACKUP on day: 20130609
channel ORA_DISK_1: looking for AUTOBACKUP on day: 20130608
channel ORA_DISK_1: looking for AUTOBACKUP on day: 20130607
channel ORA_DISK_1: no AUTOBACKUP in 7 days found
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of restore command at 06/13/2013 17:15:52
RMAN-06172: no AUTOBACKUP found or specified handle is not a valid copy or piece
The reason in this case is that since the spfile is missing and we have mounted the instance using a dummy spfile, the database needs to know where to look to find the autobackup of the spfile .
So now we include the db_file_recovery_dest and db_name parameters in the RESTORE SPFILE command.
RMAN> restore spfile from autobackup db_recovery_file_dest='/u01/backup/fast_recovery_area' db_name='GAVIN';

Starting restore at 13-JUN-13
using channel ORA_DISK_1

recovery area destination: /u01/backup/fast_recovery_area
database name (or database unique name) used for search: GAVIN
channel ORA_DISK_1: AUTOBACKUP /u01/backup/fast_recovery_area/GAVIN/autobackup/2013_06_10/o1_mf_s_818007851_8vlsdd3n_.bkp found in the recovery area
channel ORA_DISK_1: looking for AUTOBACKUP on day: 20130613
channel ORA_DISK_1: restoring spfile from AUTOBACKUP /u01/backup/fast_recovery_area/GAVIN/autobackup/2013_06_10/o1_mf_s_818007851_8vlsdd3n_.bkp
channel ORA_DISK_1: SPFILE restore from AUTOBACKUP complete
Finished restore at 13-JUN-13
Case 2) Autobackup in non-FRA location – non OMF
RMAN> startup nomount force

startup failed: ORA-01078: failure in processing system parameters
LRM-00109: could not open parameter file '/u01/app/oracle/product/11.2.0/dbhome_1/dbs/initgavin.ora'

starting Oracle instance without parameter file for retrieval of spfile
Oracle instance started

Total System Global Area     158662656 bytes

Fixed Size                     2226456 bytes
Variable Size                104859368 bytes
Database Buffers              46137344 bytes
Redo Buffers                   5439488 bytes

RMAN> set DBID=2968723077

executing command: SET DBID

RMAN>  run {
2> set CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '/u01/backup/%F';
3> restore spfile from autobackup;
4> }

executing command: SET CONTROLFILE AUTOBACKUP FORMAT

Starting restore at 13-JUN-13
using channel ORA_DISK_1

channel ORA_DISK_1: looking for AUTOBACKUP on day: 20130613
channel ORA_DISK_1: AUTOBACKUP found: '/u01/backup/c-2968723077-20130613-01
channel ORA_DISK_1: restoring spfile from AUTOBACKUP '/u01/backup/c-2968723077-20130613-01
channel ORA_DISK_1: SPFILE restore from AUTOBACKUP complete
Finished restore at 13-JUN-13
Case 3) Total Disaster Recovery ( restore by specifying the backup file name)
In this scenario, the entire database server has crashed and we have lost the entire database files including the SPFILE.
A new server has been provisioned and all the latest backup files have been restored from tape to a location on disk /u01/backup.
In this case the backup files are OMF and we have been able to identify the SPFILE backup file from the ‘s’ keyword in the backup file name
RMAN> restore spfile from '/u01/backup/o1_mf_s_818007851_8vlsdd3n_.bkp';

Starting restore at 13-JUN-13
using channel ORA_DISK_1

channel ORA_DISK_1: restoring spfile from AUTOBACKUP /u01/backup/o1_mf_s_818007851_8vlsdd3n_.bkp
channel ORA_DISK_1: SPFILE restore from AUTOBACKUP complete
Finished restore at 13-JUN-13

Case 4) Total Disaster Recovery ( restore by specifying restore from AUTOBACKUP)
In this case, the scenario is the same as the above.
But what happens if we want to use the AUTOBACKUP command to restore the spfile because many backup files have been restored and we are not sure which backup file contains the SPFILE backup.
But what happens in this case when we try to restore the SPFILE from the location where the backup has been restored.
RMAN>  run {
2> set CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '/u01/backup/%F';
3> restore spfile from autobackup;
4> }

executing command: SET CONTROLFILE AUTOBACKUP FORMAT

Starting restore at 17-JUN-13
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=171 device type=DISK

channel ORA_DISK_1: looking for AUTOBACKUP on day: 20130617
channel ORA_DISK_1: looking for AUTOBACKUP on day: 20130616
channel ORA_DISK_1: looking for AUTOBACKUP on day: 20130615
channel ORA_DISK_1: looking for AUTOBACKUP on day: 20130614
channel ORA_DISK_1: looking for AUTOBACKUP on day: 20130613
channel ORA_DISK_1: looking for AUTOBACKUP on day: 20130612
channel ORA_DISK_1: looking for AUTOBACKUP on day: 20130611
channel ORA_DISK_1: no AUTOBACKUP in 7 days found
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of restore command at 06/17/2013 15:29:58
RMAN-06172: no AUTOBACKUP found or specified handle is not a valid copy or piece
So to work around this, we tried to fool RMAN by creating the directory structure when using a FRA.
We create the directory structure GAVIN/autobackup/2013_06_17 under the to level location /u01/backup and copy the backup pieces to this location.
-bash-3.2$ cd /u01/backup
-bash-3.2$ mkdir -p GAVIN/autobackup/2013_06_17
-bash-3.2$ mv /u01/backup/o1* /u01/backup/GAVIN/autobackup/2013_06_17
Now we are able to restore the SPFILE from autobackup!
RMAN>  run {
2> restore spfile from autobackup db_recovery_file_dest='/u01/backup/' db_name='GAVIN';
3> }

Starting restore at 17-JUN-13
using channel ORA_DISK_1

recovery area destination: /u01/backup/
database name (or database unique name) used for search: GAVIN
channel ORA_DISK_1: AUTOBACKUP /u01/backup/GAVIN/autobackup/2013_06_17/o1_mf_s_818349778_8vx79lo6_.bkp found in the recovery area
channel ORA_DISK_1: looking for AUTOBACKUP on day: 20130617
channel ORA_DISK_1: restoring spfile from AUTOBACKUP /u01/backup/GAVIN/autobackup/2013_06_17/o1_mf_s_818349778_8vx79lo6_.bkp
channel ORA_DISK_1: SPFILE restore from AUTOBACKUP complete
Finished restore at 17-JUN-13

Friday, 10 August 2012

Query Is Slow...

First of all, you have to know why it is slow. What is the real cause of your problem. If the reason why is not known, suggesting to rewrite the query, or hinting the query, suggesting parallellization et cetera is not very productive. Once in a while you may get lucky. But even then you have to realize that if your problem seems "solved", but you don't know why, nothing guarantees you that the problem won't come back tomorrow. So the first step should always be to investigate the root cause. The tools at your disposal are,

 among more: -

 dbms_profiler -

explain plan -
SQL*Trace / tkprof - s

tatspack Use dbms_profiler


 if you want to know where time is being spent in PL/SQL code. Statspack is a must if you are a dba and want to know what is going on in your entire database. For a single query or a small process, explain plan and SQL*Trace and tkprof are your tools. explain plan in SQL*Plus you have to type: explain plan for Your Query; select * from table(dbms_xplan.display); When you get error messages or a message complaining about an old version of plan_table, make sure you run the script utlxplan.sql. The output you get here basically shows you what the cost based optimizer expects. It gives you an idea on why the cost based optimizer chooses an access path.

SQL*Trace/tkprof=> For this you have to type in

SQL*Plus: - alter session set sql_trace true;

- - disconnect (this step is important, because it ensures all cursors get closed, and "row source operation" is generated) - identify your trace file in the server directory as specified in the parameter user_dump_dest - on your operating system:

tkprof a.txt sys=no sort=prsela exeela fchela

 The file a.txt will now give you valuable information on what has actually happened. No predictions but the truth. By comparing the output from explain plan with the output from tkprof, you are able to identify the possible problem areas. I am fully aware that this text is only a tiny fraction of what can be done, and that other people may choose different tools and actions, but the above gives you a very reasonable start at solving your performance problem. Below is the sequence of statments we should follow while writing a sql query,
example:

 1. filter column shold come first,

 2. Thn join conditions,

3 etc How to use explain plan:

 SQL> explain plan for select * from scott.emp;
Explained.

 SQL> select plan_table_output from table(dbms_xplan.display);


 PLAN_TABLE_OUTPUT --------------------------------------------------------------------------------

Plan hash value:
3956160932 --------------------------------------------------------------------------

Id Operation Name Rows Bytes
Cost (%CPU) Time -------------------------------------------------------------------------- 0

SELECT STATEMENT 14 518 3 (0) 00:00:01 1 TABLE ACCESS FULL EMP 14 518 3 (0) 00:00:01 -------------------------------------------------------------------------- 8 rows selected.



SQL> select * from V$version; BANNER --------------------------------------------------------------------------------
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 -

Production PL/SQL Release 10.2.0.4.0 -

 Production CORE 11.1.0.6.0

Production TNS for Linux: Version 10.2.0.4.0 -

 Production NLSRTL Version 10.2.0.4.0 - Production

 Most import is to read the explain plan in the tkprof.
and finally LIKE operater should be used as 'Word%' to give a match first and to improve Query performance.


Sql Tuning

What are the hints and what are the different types of hints (INTERVIEW Question)


Ans: Hints(Optimizer hints) are used to alter the execution plan of the sql statments.

We should first get the explain plan of our SQL and determine what changes can be done to make the code operate without using hints if possible. However, Oracle hints such as ORDERED, LEADING, INDEX, FULL, and the various AJ and SJ Oracle hints can tame a wild optimizer and give you optimal performance.

With hints one can influence the optimizer. The usage of hints (with exception of the RULE-hint) causes Oracle to use the Cost Based optimizer.

The following syntax is used for hints:

select /*+ HINT */ name
from emp
where id =1;

Where HINT is replaced by the hint text.
When the syntax of the hint text is incorrect, the hint text is ignored and will not be used.
here you can find undocumented hints.

Hints for Optimization Approaches and Goals

ALL_ROWS The ALL_ROWS hint explicitly chooses the cost-based approach to optimize a statement block with a goal of best throughput (that is, minimum total resource consumption).

FIRST_ROWS The FIRST_ROWS hint explicitly chooses the cost-based approach to optimize a statement block with a goal of best response time (minimum resource usage to return first row). In newer Oracle version you should give a parameter with this hint: FIRST_ROWS(n) means that the optimizer will determine an executionplan to give a fast response for returning the first n rows.

CHOOSE The CHOOSE hint causes the optimizer to choose between the rule-based approach and the cost-based approach for a SQL statement based on the presence of statistics for the tables accessed by the statement

RULE The RULE hint explicitly chooses rule-based optimization for a statement block. This hint also causes the optimizer to ignore any other hints specified for the statement block. The RULE hint does not work any more in Oracle 10g.
Hints for Access Paths

FULL The FULL hint explicitly chooses a full table scan for the specified table. The syntax of the FULL hint is FULL(table) where table specifies the alias of the table (or table name if alias does not exist) on which the full table scan is to be performed.

ROWID The ROWID hint explicitly chooses a table scan by ROWID for the specified table. The syntax of the ROWID hint is ROWID(table) where table specifies the name or alias of the table on which the table access by ROWID is to be performed. (This hint depricated in Oracle 10g)

CLUSTER The CLUSTER hint explicitly chooses a cluster scan to access the specified table. The syntax of the CLUSTER hint is CLUSTER(table) where table specifies the name or alias of the table to be accessed by a cluster scan.

HASH The HASH hint explicitly chooses a hash scan to access the specified table. The syntax of the HASH hint is HASH(table) where table specifies the name or alias of the table to be accessed by a hash scan.

HASH_AJ The HASH_AJ hint transforms a NOT IN subquery into a hash anti-join to access the specified table. The syntax of the HASH_AJ hint is HASH_AJ(table) where table specifies the name or alias of the table to be accessed.(depricated in Oracle 10g)

INDEX The INDEX hint explicitly chooses an index scan for the specified table. The syntax of the INDEX hint is INDEX(table index) where:table specifies the name or alias of the table associated with the index to be scanned and index specifies an index on which an index scan is to be performed. This hint may optionally specify one or more indexes:

NO_INDEX The NO_INDEX hint explicitly disallows a set of indexes for the specified table. The syntax of the NO_INDEX hint is NO_INDEX(table index)
INDEX_ASC The INDEX_ASC hint explicitly chooses an index scan for the specified table. If the statement uses an index range scan, Oracle scans the index entries in ascending order of their indexed values.

INDEX_COMBINE If no indexes are given as arguments for the INDEX_COMBINE hint, the optimizer will use on the table whatever boolean combination of bitmap indexes has the best cost estimate. If certain indexes are given as arguments, the optimizer will try to use some boolean combination of those particular bitmap indexes. The syntax of INDEX_COMBINE is INDEX_COMBINE(table index).

INDEX_JOIN Explicitly instructs the optimizer to use an index join as an access path. For the hint to have a positive effect, a sufficiently small number of indexes must exist that contain all the columns required to resolve the query.

INDEX_DESC The INDEX_DESC hint explicitly chooses an index scan for the specified table. If the statement uses an index range scan, Oracle scans the index entries in descending order of their indexed values.

INDEX_FFS This hint causes a fast full index scan to be performed rather than a full table.

NO_INDEX_FFS Do not use fast full index scan (from Oracle 10g)

INDEX_SS Exclude range scan from query plan (from Oracle 10g)

INDEX_SS_ASC Exclude range scan from query plan (from Oracle 10g)

INDEX_SS_DESC Exclude range scan from query plan (from Oracle 10g)

NO_INDEX_SS The NO_INDEX_SS hint causes the optimizer to exclude a skip scan of the specified indexes on the specified table. (from Oracle 10g)

Hints for Query Transformations

NO_QUERY_TRANSFORMATION Prevents the optimizer performing query transformations. (from Oracle 10g)

USE_CONCAT The USE_CONCAT hint forces combined OR conditions in the WHERE clause of a query to be transformed into a compound query using the UNION ALL set operator. Normally, this transformation occurs only if the cost of the query using the concatenations is cheaper than the cost without them.

NO_EXPAND The NO_EXPAND hint prevents the optimizer from considering OR-expansion for queries having OR conditions or IN-lists in the WHERE clause. Usually, the optimizer considers using OR expansion and uses this method if it decides that the cost is lower than not using it.

REWRITE The REWRITE hint forces the optimizer to rewrite a query in terms of materialized views, when possible, without cost consideration. Use the REWRITE hint with or without a view list. If you use REWRITE with a view list and the list contains an eligible materialized view, then Oracle uses that view regardless of its cost.

NOREWRITE / NO_REWRITE In Oracle 10g renamed to NO_REWRITE. The NOREWRITE/NO_REWRITE hint disables query rewrite for the query block, overriding the setting of the parameter QUERY_REWRITE_ENABLED.

MERGE The MERGE hint lets you merge views in a query.

NO_MERGE The NO_MERGE hint causes Oracle not to merge mergeable views. This hint is most often used to reduce the number of possible permutations for a query and make optimization faster.

FACT The FACT hint indicated that the table should be considered as a fact table. This is used in the context of the star transformation.

NO_FACT The NO_FACT hint is used in the context of the star transformation to indicate to the transformation that the hinted table should not be considered as a fact table.

STAR_TRANSFORMATION The STAR_TRANSFORMATION hint makes the optimizer use the best plan in which the transformation has been used. Without the hint, the optimizer could make a query optimization decision to use the best plan generated without the transformation, instead of the best plan for the transformed query.

NO_STAR_TRANSFORMATION Do not use star transformation (from Oracle 10g)
UNNEST The UNNEST hint specifies subquery unnesting.
NO_UNNEST Use of the NO_UNNEST hint turns off unnesting for specific subquery blocks.

Hints for Join Orders

LEADING Give this hint to indicate the leading table in a join. This will indicate only 1 table. If you want to specify the whole order of tables, you can use the ORDERED hint. Syntax: LEADING(table)

ORDERED The ORDERED hint causes Oracle to join tables in the order in which they appear in the FROM clause. If you omit the ORDERED hint from a SQL statement performing a join , the optimizer chooses the order in which to join the tables. You may want to use the ORDERED hint to specify a join order if you know something about the number of rows selected from each table that the optimizer does not. Such information would allow you to choose an inner and outer table better than the optimizer could.

Hints for Join Operations

USE_NL The USE_NL hint causes Oracle to join each specified table to another row source with a nested loops join using the specified table as the inner table. The syntax of the USE_NL hint is USE_NL(table table) where table is the name or alias of a table to be used as the inner table of a nested loops join.

NO_USE_NL Do not use nested loop (from Oracle 10g)

USE_NL_WITH_INDEX Specifies a nested loops join. (from Oracle 10g)

USE_MERGE The USE_MERGE hint causes Oracle to join each specified table with another row source with a sort-merge join. The syntax of the USE_MERGE hint is USE_MERGE(table table) where table is a table to be joined to the row source resulting from joining the previous tables in the join order using a sort-merge join.

NO_USE_MERGE Do not use merge (from Oracle 10g)

USE_HASH The USE_HASH hint causes Oracle to join each specified table with another row source with a hash join. The syntax of the USE_HASH hint is USE_HASH(table table) where table is a table to be joined to the row source resulting from joining the previous tables in the join order using a hash join.

NO_USE_HASH Do not use hash (from Oracle 10g)
Hints for Parallel Execution

PARALLEL The PARALLEL hint allows you to specify the desired number of concurrent query servers that can be used for the query. The syntax is PARALLEL(table number number). The PARALLEL hint must use the table alias if an alias is specified in the query. The PARALLEL hint can then take two values separated by commas after the table name. The first value specifies the degree of parallelism for the given table, the second value specifies how the table is to be split among the instances of a parallel server. Specifying DEFAULT or no value signifies the query coordinator should examine the settings of the initialization parameters (described in a later section) to determine the default degree of parallelism.

NOPARALLEL / NO_PARALLEL The NOPARALLEL hint allows you to disable parallel scanning of a table, even if the table was created with a PARALLEL clause. In Oracle 10g this hint was renamed to NO_PARALLEL.

PQ_DISTRIBUTE The PQ_DISTRIBUTE hint improves the performance of parallel join operations. Do this by specifying how rows of joined tables should be distributed among producer and consumer query servers. Using this hint overrides decisions the optimizer would normally make.

NO_PARALLEL_INDEX The NO_PARALLEL_INDEX hint overrides a PARALLEL attribute setting on an index to avoid a parallel index scan operation.
Additional Hints

APPEND When the APPEND hint is used with the INSERT statement, data is appended to the table. Existing free space in the block is not used. If a table or an index is specified with nologging, this hint applied with an insert statement produces a direct path insert which reduces generation of redo.

NOAPPEND Overrides the append mode.

CACHE The CACHE hint specifies that the blocks retrieved for the table in the hint are placed at the most recently used end of the LRU list in the buffer cache when a full table scan is performed. This option is useful for small lookup tables. In the following example, the CACHE hint overrides the table default caching specification.

NOCACHE The NOCACHE hint specifies that the blocks retrieved for this table are placed at the least recently used end of the LRU list in the buffer cache when a full table scan is performed. This is the normal behavior of blocks in the buffer cache.

PUSH_PRED The PUSH_PRED hint forces pushing of a join predicate into the view.

NO_PUSH_PRED The NO_PUSH_PRED hint prevents pushing of a join predicate into the view.

PUSH_SUBQ The PUSH_SUBQ hint causes nonmerged subqueries to be evaluated at the earliest possible place in the execution plan.

NO_PUSH_SUBQ The NO_PUSH_SUBQ hint causes non-merged subqueries to be evaluated as the last step in the execution plan.

QB_NAME Specifies a name for a query block. (from Oracle 10g)

CURSOR_SHARING_EXACT Oracle can replace literals in SQL statements with bind variables, if it is safe to do so. This is controlled with the CURSOR_SHARING startup parameter. The CURSOR_SHARING_EXACT hint causes this behavior to be switched off. In other words, Oracle executes the SQL statement without any attempt to replace literals by bind variables.

DRIVING_SITE The DRIVING_SITE hint forces query execution to be done for the table at a different site than that selected by Oracle

DYNAMIC_SAMPLING The DYNAMIC_SAMPLING hint lets you control dynamic sampling to improve server performance by determining more accurate predicate selectivity and statistics for tables and indexes. You can set the value of DYNAMIC_SAMPLING to a value from 0 to 10. The higher the level, the more effort the compiler puts into dynamic sampling and the more broadly it is applied. Sampling defaults to cursor level unless you specify a table.

SPREAD_MIN_ANALYSIS This hint omits some of the compile time optimizations of the rules, mainly detailed dependency graph analysis, on spreadsheets. Some optimizations such as creating filters to selectively populate spreadsheet access structures and limited rule pruning are still used. (from Oracle 10g)
Hints with unknown status

MERGE_AJ The MERGE_AJ hint transforms a NOT IN subquery into a merge anti-join to access the specified table. The syntax of the MERGE_AJ hint is MERGE_AJ(table) where table specifies the name or alias of the table to be accessed.(depricated in Oracle 10g)

AND_EQUAL The AND_EQUAL hint explicitly chooses an execution plan that uses an access path that merges the scans on several single-column indexes. The syntax of the AND_EQUAL hint is AND_EQUAL(table index index) where table specifies the name or alias of the table associated with the indexes to be merged. and index specifies an index on which an index scan is to be performed. You must specify at least two indexes. You cannot specify more than five. (depricated in Oracle 10g)
STAR The STAR hint forces the large table to be joined last using a nested loops join on the index. The optimizer will consider different permutations of the small tables. (depricated in Oracle 10g)

BITMAP Usage: BITMAP(table_name index_name) Uses a bitmap index to access the table. (depricated ?)
HASH_SJ
Use a Hash Anti-Join to evaluate a NOT IN sub-query. Use this hint in the sub-query, not in the main query. Use this when your high volume NOT IN sub-query is using a FILTER or NESTED LOOPS join. Try MERGE_AJ if HASH_AJ refuses to work.(depricated in Oracle 10g)

NL_SJ Use a Nested Loop in a sub-query. (depricated in Oracle 10g)

NL_AJ Use an anti-join in a sub-query. (depricated in Oracle 10g)
ORDERED_PREDICATES (depricated in Oracle 10g)

EXPAND_GSET_TO_UNION (depricated in Oracle 10g)


Thursday, 26 July 2012

Row Migration & Row chaining


What is Row Chaining
-----------------------------


Row Chaining happens when a row is too large to fit into a single database block. For example, if you use a 8KB block size for your database and you need to insert a row of 16KB into it, Oracle will use 2/3 blocks and store the row in chain of data blocks for that segment. And Row Chaining happens only when the row is being inserted.

you can show the block size of database by

SQL> conn / as sysdba
SQL> show parameter db_block_size



What is Row Migration
---------------------
­­­­-----------

Row Migration Occurs when a row that originally fitted into one data block is updated so that the overall row length increases, and the block's free space is already completely filled. In this case, Oracle migrates the data for the entire row to a new data block, assuming the entire row can fit in a new block. Oracle preserves the original row piece of a migrated row to point to the new block containing the migrated row: the rowid of a migrated row does not change.



How can identified Row Chaining and row migration
-------------------------------------------------------------------------


There are 3 ways :-     1) by Analyze command
                                    2) USER_TABLES
                                    3) V$SYSSTAT


Materialized View

Everytime you use a view oracle has to execute the sql statement defined for that view (called view resolution), it must be done each time the view is used. If the view is complex this can take sometime, this is where a materialized views comes in, unlike a view it contains space and storage just like a regular table. You can even partition them and create indexes on them. Materialized views take a snapshot of the underlying tables which means that data may not represent the source data. To get the materialized view data up to date you must refresh it. Creating materialized views is simple but optimizing it can be tricky, keeping the data up to date and also getting the CBO (cost based optimizer) to use the view. As with view materialized views can be inserted, updated and deleted from.

There are 3 types of materialized views:

Readonly Materialized view
Cannot be updated and complex materialized views are supported
Updateable Materialized view
can be updated even when disconnected from the master site, are refreshed on demand and consume fewer resources but requires advanced replication option to be installed
Writeable Materialized view
are created with the for update clause, any changes are lost when the view is updated this also requiresadvanced replication option to be installed.

Materialized View Refresh
To ensure that a materialized view is consistent with its master table or master materialized view, you must refresh the materialized view periodically. Oracle provides the following three methods to refresh materialized views:
    ■ Fast refresh uses materialized view logs to update only the rows that have changed since the last refresh.
    ■ Complete refresh updates the entire materialized view.
    ■ Force refresh performs a fast refresh when possible. When a fast refresh is not possible,force refresh performs a complete refresh.

1. INTRODUCTION
===============
A materialized view is a replica of a target master from a single point in time.
The concept was first introduced with Oracle7 termed as SNAPSHOT.
NOTE :   Materialized views can be used for many purposes, including:
·         Denormalization
·         Validation
·         Data Warehousing
·         Replication.

2. Usage of Materialized Views
=======================

Materialized views can be used both for:
   - creating summaries to be utilized in data warehouse environments
   - replicating data in distributed environments


3. Refreshing Materialized Views
==========================

Initially, a materialized view contains the same data as in the master table.
After the materialized view is created, changes can be made to the master table, and possibly also to the materialized view. To keep a materialized view's data relatively current with the data in the master table, the materialized view must be periodically refreshed. Refresh can be accomplished by one of the following procedures

   dbms_mview.refresh( '<mview list>', '<Refresh Type>' )

   dbms_refresh.refresh( '<refresh group>' )

You can choose between Complete, Fast, and Force refresh types.

4. Materialized View Types
======================

Read-Only Materialized Views
----------------------------------------
As the name implies it is not possible to perform DML on snapshots in this category.

Updatable Materialized Views
----------------------------------------
Updatable materialized views eliminate the restriction of DMLs on snapshots. Users are allowed to insert, update and delete rows of the updatable materialized view.

Subquery Materialized Views
---------------------------------------
Materialized views that are created with subqueries in the WHERE clause of the mview query are referred to as subquery materialized views.

Multitier Materialized Views
----------------------------
A multitier materialized view is a materialized view whose master table is itself a materialized view. This feature enables fast refresh of materialized views that have materialized views as their masters.


5. Data type Support
================

The following datatypes are supported in snapshot replication:
 - VARCHAR2
 - NVARCHAR2
 - NUMBER
 - DATE
 - TIMESTAMP
 - TIMESTAMP WITH TIME ZONE
 - TIMESTAMP LOCAL TIME ZONE
 - INTERVAL YEAR TO MONTH
 - INTERVAL DAY TO SECOND
 - RAW
 - ROWID
 - CHAR
 - NCHAR
 - User-defined data types
 - Binary LOB (BLOB)
 - Character LOB (CLOB)
 - National character LOB (NCLOB)
 - UROWID (supported only for readonly materialized views)

The following types are NOT supported in snapshot replication:
 - LONG
 - LONG RAW
 - BFILE
 - UROWID (not supported for updatable snapshots)


NOTE :   3 distinct types of users perform operations on materialized views:
                Creator: The user who creates the materialized view.
                Refresher: The user who refreshes the materialized view.
                Owner: The user who owns the materialized view. The materialized view resides in this          user's schema

TO FIND SCHEMA SIZE OF DATABASE


SQL> set pagesize 10000
SQL> BREAK ON REPORT
SQL> COMPUTE SUM LABEL TOTAL OF "Size of Each Segment in MB" ON REPORT
SQL> select segment_type, sum(bytes/1024/1024) "Size of Each Segment in MB" from dba_segments where owner='SYS' group by segment_type order by 1;

SEGMENT_TYPE       Size of Each Segment in MB
------------------          --------------------------
CLUSTER                              1872.0625
INDEX                                   1419.3125
INDEX PARTITION                    166.25
LOB PARTITION                          .1875
LOBINDEX                                17.1875
LOBSEGMENT                        478.8125
NESTED TABLE                                   1
ROLLBACK                                          2
TABLE                                      1218.875
TABLE PARTITION                 441.3125
TYPE2 UNDO                         1055.5625
                                    --------------------------
TOTAL                                    6672.5625

11 rows selected.