Dense Rank -Vs- Rank -Vs- Row_Number

Rank => Rank with Gaps (Eg: 1,2,2,4,5)
Dense Rank => Rank without Gaps (Eg: 1,2,2,3,4)
Row_Number => Ordering of rows; no consideration of equal ranks (Eg: 1,2,3,4,5)

Rank over (ORDER BY clause)
Dense_rank over (ORDER BY clause)
Row_number over (ORDER BY clause)

ORDER BY clause can also be replaced by "PARTITION BY x ORDER BY y"

For details see the example here

Analytic Function: Lag

Lag: Analytic function to retrieve a value from the previous row.

Usage:

Lag([column]) OVER (PARTITION BY [partition_column] ORDER BY [ordering_column])


column - column to be pulled in from the previous row
ordering_column - column by which a partition will be ordered
partition_column - column to be used to partition data. On first thought it might seem that this column can as well be included in the ordering_column list. On careful inspection one may notice that doing so can result in incorrect data. Suppose the requirement is not just to pull data from any previous row; rather only rows belonging to the same class as the current row; in such a case including the partition_column under ordering_column will produce an incorrect result.

Eg: See below example: Fetching transaction amounts for customers over a two months: Here the data needs to be partitioned by the customer and then the previous row may be pulled in.


CREATE TABLE tmp828cust(month date, custno number, cust_name varchar2(50))
CREATE TABLE tmp828transact(month date, transactno number, custno number, amount number)

Required output:
CUSTNO CUST_NAME TOTAL-MONTH1 TOTAL-MONTH2
1 A 5000 5500
2 B 1000 500
3 C 2000 1800



Inefficient Solution

SELECT t1.custno,
t1.cust_name,
t1.tot,
t2.tot
FROM
(
SELECT c.custno,
c.cust_name,
Sum(t.amount) tot
FROM tmp828cust c,
tmp828transact t
WHERE c.month = t.month
AND c.custno = t.custno
AND t.MONTH = '01-JAN-2008'
GROUP BY c.custno, c.cust_name
)t1,
(
SELECT c.custno,
c.cust_name,
Sum(t.amount) tot
FROM tmp828cust c,
tmp828transact t
WHERE c.month = t.month
AND c.custno = t.custno
AND t.MONTH = '01-FEB-2008'
GROUP BY c.custno, c.cust_name
)t2
WHERE t1.custno = t2.custno




Better Solution

SELECT *
FROM (SELECT custno,
cust_name,
month,
amt,
Lag(amt) OVER (PARTITION BY custno ORDER BY month) last_amt
FROM (SELECT t.month,
c.custno,
c.cust_name,
Sum(t.amount) amt
FROM tmp828cust c,
tmp828transact t
WHERE c.month = t.month
AND c.custno = t.custno
GROUP BY t.month,
c.custno,
c.cust_name
)
)
WHERE last_amt IS NOT NULL


Notice the usage of Lag function here
Lag(amt) OVER (PARTITION BY custno ORDER BY month) : Get the amt column from the previous row, rows should be Partitioned by custno and Ordered by month

References:
1. http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:1396477600346947904
2. http://www.adp-gmbh.ch/ora/sql/analytical/lag.html

Oracle AQ

Here's a good article on Oracle Advanced Queues (AQ). The article talks about the basics of a queue and goes on to explain how this is implemented in Oracle's AQ. There's also a basic explanation about Oracle's JMS interface to AQ.

http://www.akadia.com/services/ora_advanced_queueing.html

Result_Cache in Oracle 11g

One interesting feature in Oracle 11g database is result caching. To reduce disk I/O, oracle already caches data blocks. With result caching, this is taken one step ahead - results of a query are cached in memory so that a repeat evaluation is not required. So if you have a common SQL being executed in your application, Oracle 11g does the caching for you. And this caching does not compromise on data integrity - whenever a DML operation is performed on a dependant table, the result cache is invalidated.

As Tom says, Result_Cache is more like a Just-In-Time Materialized View - an MV which does not require DBA intervention

For examples usages of Result_Cache click here.

Why are COMMIT times generally flat?

Contrary to intuitive reasoning, COMMIT is an operation which is not dependant on the size of the transaction (a more or less flat CommitTime-Vs-Volume chart). The reason behind this is that even before the COMMIT is issued, most of the volume dependant operations have been completed (Modifying data blocks in SGA, undo block generation, redo information generation etc). When a COMMIT is issued, the following operations are performed
1. Generate an SCN for the transaction
2. Write remaining buffered redo log entries to disk and record the SCN (lengthiest operation).
3. Release any locks that were acquired as part of the transaction.


Hence COMMIT time is not affected by the size of the transaction. Now thats why wise men say - Never issue COMMITs in a loop (of course, unless each iteration is required to be an atomic transactions in itself!).

Join Types - NestedLoop, HashJoin, SortMerge

Nested Loop Join
============
Outer Loop : Row source 1 is scanned (outer /driving table)
Inner Loop : Each row returned drives a lookup in row source 2 (inner)
Joining rows are then returned
Cost: Read driving table and access on inner table.
Performance is very dependent on index on inner table

Optimizer uses nested loop when we are joining tables containing small number of rows with an efficient driving condition. It is important to have an index on column of inner join table as this table is probed every time for a new value from outer table.

Hash Join
=======
In theory - the most efficient joint method.
Build Phase: The smaller row source is used to build a hash table and a bitmap
Probe Phase: The second row source is hashed and checked against the hash table
The bitmap is used as a quick lookup to check if rows are in the hash table.
It requires single pass for each row source , and more efficient than sorting and merging
Optimizer uses has join while joining big tables or big fraction of small tables.

SortMerge Join
===========
Sort Phase : Rows from source 1 are sorted; Rows from source 2 are then sorted by the same sort key
Merge Phase : Sorted rows from both sides are then merged
Cost : sorting, reading tables, I/O for temporary segments
Optmizer choose SM Join in following cases
a) When the join condition is an inequality condition (like <, <=, >=). This is because hash join cannot be used for inequality conditions and if the data set is large, nested loop is definitely not an option.
b) If sorting is anyways required due to some other attribute (other than join) like “order by”, optimizer prefers sort merge join over hash join as it is cheaper.

More Info:
www.oraclenotes.com/Articles/Optimizer%20and%20CBO.ppt
http://oracle-online-help.blogspot.com/2007/03/nested-loops-hash-join-and-sort-merge.html

LSNRCTL

LSNRCTL is a utility to manage Oracle's listener processes.

What does the listener do?
The Oracle listener process is required for database applications to access the database through SQL*Net or Net8.
* listens for requests on a specific port
* spawns or requests a database process/thread
* redirects or passes the connection to the process/thread

Config File for the Listener -> listener.ora

What does listener.org contain?
The listener.ora file resides on the server and defines
a. network listener address
b. SID for the database for which it listens
c. optional parameters for tracing and logging