hash join and nested loop are used in full table scan

hash join - Some sql queries runs faster in hash join. Uses more RAM. hash are
built in RAM memory.

nested join - most common join,

terminolgy :
Driving Table
secondary table
index range scan
multi-block reads
parallel query

Index are created by defualt while creating a primmary key ?

###################################################################################
https://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:14188501024541

REF CURSOR VS CURSOR

###################################################################################
technically, under the covers, at the most "basic level", they are the same.

A "normal" plsql cursor is static in defintion.

Ref cursors may be dynamically opened or opened based on logic.

Declare
type rc is ref cursor;

cursor c is select * from dual;

l_cursor rc;
begin
if ( to_char(sysdate,'dd') = 30 ) then
open l_cursor for 'select * from emp';
elsif ( to_char(sysdate,'dd') = 29 ) then
open l_cursor for select * from dept;
else
open l_cursor for select * from dual;
end if;
open c;
end;
/

Given that block of code -- you see perhaps the most "salient" difference -- no
matter how many times you run that block -- cursor C will always be select * from
dual. The ref cursor can be anything.

Another difference is a ref cursor can be returned to a client. a plsql "cursor

cursor" cannot be returned to a client.

Another difference is a cursor can be global -- a ref cursor cannot (you cannot
define them OUTSIDE of a procedure / function)

Another difference is a ref cursor can be passed from subroutine to subroutine -- a

cursor cannot be.

Another difference is that static sql (not using a ref cursor) is much more
efficient then using ref cursors and that use of ref cursors should be limited to
- returning result sets to clients
- when there is NO other efficient/effective means of achieving the goal

that is, you want to use static SQL (with implicit cursors really) first and use a
ref cursor only when you absolutely have to

Then sit back and say "anything else you wanted to know about them"

###################################################################################
##########

11g vs 12c
create multiple indexes on same column.Prior to oracle 12c, user will be able to
create single index on one column
The new cache mechanism called as big table cache is used to improve the
performance for full table scan.
To migrate the table partition and subpartition to different tablespace can be
moved to different tablespace online or offline.
When specific column is defined as invisible it will not appear in generic queries.