Pois é isso mesmo! A querida tabela do ORACLE que nos mostra o plano de execução dos SQLs hoje completa 21 anos!
Hoje eu fui olhar um plano de execução e me deparei com a seguinte mensagem:

SET AUTOTRACE ON
SELECT bla bla bla...

Execution Plan
----------------------------------------------------------

--------------------------------------------------------------
| Id  | Operation          | Name       | Rows  | Cost (%CPU)|
--------------------------------------------------------------
|   0 | SELECT STATEMENT   |            |     1 |   102   (0)|
|   1 |  SORT AGGREGATE    |            |     1 |            |
|   2 |   TABLE ACCESS FULL| TABELA     |  4322 |   102   (0)|
--------------------------------------------------------------

Note
-----
   - 'PLAN_TABLE' is old version

PLAN_TABLE is old version ???

Olhei no script de criação da nova PLAN_TABLE e descobri nos comentários a data de cada modificação: 19 de Outubro de 1988 !

rem
rem $Header: utlxplan.sql 29-oct-2001.20:28:58 mzait Exp $ xplainpl.sql
rem
Rem Copyright (c) 1988, 2001, Oracle Corporation.  All rights reserved.
Rem NAME
REM    UTLXPLAN.SQL
Rem  FUNCTION
Rem  NOTES
Rem  MODIFIED
Rem     mzait      10/26/01  - add keys and filter predicates to the plan table
Rem     ddas       05/05/00  - increase length of options column
Rem     ddas       04/17/00  - add CPU, I/O cost, temp_space columns
Rem     mzait      02/19/98 -  add distribution method column
Rem     ddas       05/17/96 -  change search_columns to number
Rem     achaudhr   07/23/95 -  PTI: Add columns partition_{start, stop, id}
Rem     glumpkin   08/25/94 -  new optimizer fields
Rem     jcohen     11/05/93 -  merge changes from branch 1.1.710.1 - 9/24
Rem     jcohen     09/24/93 - #163783 add optimizer column
Rem     glumpkin   10/25/92 -  Renamed from XPLAINPL.SQL
Rem     jcohen     05/22/92 - #79645 - set node width to 128 (M_XDBI in gendef)
Rem     rlim       04/29/91 -         change char to varchar2
Rem   Peeler     10/19/88 - Creation
Rem
Rem This is the format for the table that is used by the EXPLAIN PLAN
Rem statement.  The explain statement requires the presence of this
Rem table in order to store the descriptions of the row sources.

create table PLAN_TABLE (
	statement_id 	varchar2(30),
	timestamp    	date,
	remarks      	varchar2(80),
	operation    	varchar2(30),
	options       	varchar2(255),
	object_node  	varchar2(128),
	object_owner 	varchar2(30),
	object_name  	varchar2(30),
	object_instance numeric,
	object_type     varchar2(30),
	optimizer       varchar2(255),
	search_columns  number,
	id		numeric,
	parent_id	numeric,
	position	numeric,
	cost		numeric,
	cardinality	numeric,
	bytes		numeric,
	other_tag       varchar2(255),
	partition_start varchar2(255),
        partition_stop  varchar2(255),
        partition_id    numeric,
	other		long,
	distribution    varchar2(30),
	cpu_cost	numeric,
	io_cost		numeric,
	temp_space	numeric,
        access_predicates varchar2(4000),
        filter_predicates varchar2(4000));

Atingiu a maioridade! Feliz aniversário PLAN_TABLE!

Esse post vai mais a título de curiosidade. Sabemos que os números primos são números naturais que podem ser divididos apenas por dois números naturais, o 1 (um) e ele mesmo. Pois a tempos que eu queria um SQL que retornasse esses números!

Após um pouco de tentativas, saiu o SQL abaixo:

select z.zz PRIMOS
from
 (select rownum+1 zz
  from user_tables
  where rownum < 100
 ) z
where zz not in (
                select y.bb
                from (select rownum+1 aa from user_tables a where rownum < 100) x
                ,    (select rownum+1 bb from user_tables b where rownum < 100) y
                where bb<>aa
                  and mod(bb, aa)=0
                  and aa<=bb
                )
/

Abaixo, colocaremos uma amostra dos resultados:

SQL> select z.zz PRIMOS
  2  from
  3   (select rownum+1 zz
  4    from user_tables
  5    where rownum < 100
  6   ) z
  7  where zz not in (
  8                  select y.bb
  9                  from (select rownum+1 aa from user_tables a where rownum < 100) x
 10                  ,    (select rownum+1 bb from user_tables b where rownum < 100) y
 11                  where bb<>aa
 12                    and mod(bb, aa)=0
 13                    and aa<=bb
 14                  )
 15  /

   PRIMOS
---------
        2
        3
        5
        7
       11
       13
       17
       19
       23
       29
       31
       37
       41
       43
       47
       53
       59
       61
       67
       71
       73
       79
       83
       89
       97

25 rows selected.
SQL>

Talvez essa não seja a melhor forma de fazer isso (obviamente, que usar SQL pra calcular isso não é a melhor saída). Mesmo assim, fica como um "desafio vencido".

Comentários aqui

Todos conhecem a função do Oracle que faz a potêcia: o POWER. Abaixo, vamos demonstrar como elevar números sem usar essa função.

select power(2,3)
from dual

Além dessa função é possível usar o ** para potência:

SQL> set serveroutput on
SQL> declare
  2    vtemp number;
  3  begin
  4    vtemp := 2**3;   -- Equivalente a POWER(2,3)
  5    dbms_output.put_line ( 'Resultado: '||vtemp );
  6  end;
  7  /
Resultado: 8

PL/SQL procedure successfully completed.

SQL>

Verificamos que o uso do ** equivale a função POWER do Oracle. Infelizmente o uso não é permitido dentro de blocos PL/SQL. Não funciona direto num SQL.

Comente aqui

Sabemos que mudando o NLS_LANG do oracle, ele assume comportamentos diferentes. (Por exemplo, muda o formato da Data, muda o Ponto Decimal ou Vírgula Decimal, etc.) Mas uma coisa que as vezes passa despercebido é que o NLS_LANG também pode mudar a ORDEM das colunas:

Exemplo: (Note a diferença)

SQL> SELECT * FROM A ORDER BY 1;

F
-
1
5
A
B
C

SQL> ALTER SESSION SET NLS_LANGUAGE = 'PORTUGUESE';

Session altered.

SQL> SELECT * FROM A ORDER BY 1;

F
-
A
B
C
1
5

Como se pode ver, mudei de AMERICAN para PORTUGUESE e a ordem mudou! No primeiro caso, os números vieram primeiro. No segundo, os números ficaram por último. Como podemos nos certificar que uma coluna SEMPRE vai obedecer a mesma ordem, mesmo se o NLS_LANG for diferente ?

Solução 1
Pode se criar uma pequena função que indica se o campo é numérico ou não. Daí­, ordenamos primeiro pelo resultado dessa função. Lá vai:

SQL> create or replace Function f_nro ( p_numero in varchar2 ) return number
  2  as
  3    l_numero number;
  4  begin
  5    l_numero := to_number(p_numero);
  6    return 1;
  7  exception when others then return 0;
  8  end;
  9
 10
 11  /

Function created.

SQL> select f_nro('1234') from dual;

F_NRO('1234')
-------------
              1

SQL> select f_nro('1234a') from dual;

F_NRO('1234A')
--------------
             0

SQL>

Veja… ela retorna ZERO se não é um número! Daí­ podemos ordenar desta forma:

SQL> ALTER SESSION SET NLS_LANGUAGE = 'PORTUGUESE';

Session altered.

SQL>  SELECT * FROM A ORDER BY 1;

F
-
A
B
C
1
5

SQL> SELECT * FROM A ORDER BY f_nro(FIELD) desc, field;

F
-
5
1
A
B
C

SQL>

Voalá!!!

Solução 2
É possí­vel usar a função DUMP. Exemplo:

SQL> select dump('A') from dual;

DUMP('A')
----------------
Typ=96 Len=1: 65

SQL> SELECT * FROM A ORDER BY dump(FIELD);

F
-
1
5
A
B
C

Se tiver outras maneiraas, fique a vontade de postá-las aqui!

Sabemos que quando um variável ou um campo no Oracle está NULL, ele não pode ser simplesmente comparado a um outro valor, pois o resultado da compração também será false!

declare
  a number:=null;
  b number:=null;
begin
  if a=b
  then dbms_output.put_line('SIM');
  else  dbms_output.put_line('nao');
  end if;
end;

SQL> /
nao

POUCO EFICIENTE
Para “sanar” este problema, é possivel usar NVL, que não é uma boa prática. Veremos porque:

if nvl(a, 123456789) = nvl(b, 123456789)
then --seu código

O exemplo acima até funciona se o valor for diferente de 123456789. Se o valor for igual, ferra a comparação!

MUITO EFICIENTE
A melhor prática possível
É um pouco trabalhosa, mas sempre funcionará:

if a<>b
or (a is null and b is not null)
or (a is not null and b is null)
then --seu codigo

Comente aqui

Este caso é no mí­nimo curioso! É bem comum usarmos “IN” quando queremos que o banco considere várias opções para um determinado campo. Neste exemplo, vamos demonstrar que o ORACLE concatena espaços em branco em comparações com IN. Vamos aos exemplos:

Sabemos que o otimizador substitui todas opções do IN pra vários “OR” no SQL. No exemplo abaixo, vamos deixar o primeiro “SP” com um espaço em branco na direita! Não deveria retornar nenhuma linha:

SQL> SELECT 'SQL IN contatena espaços em branco!' CAMPO
2 FROM DUAL
3 WHERE 'SP ' IN ( 'SP', 'RJ' )
4 /

SQL>

Agora, o mesmo teste com o TAB:
SQL> SELECT 'SQL IN contatena TAB!' CAMPO
2 FROM DUAL
3 WHERE 'SP ' IN ( 'SP', 'RJ' )
4 /

SQL>

Agora, tentamos o mesmo com espaço em branco na esquerda:
SQL> SELECT 'SQL IN não concatena espaços na esquerda!' CAMPO
2 FROM DUAL
3 WHERE ' SP' IN ( 'SP', 'RJ' )
4 /

SQL>

Agora, dentro de um bloco PL/SQL
SQL> DECLARE
2 VTEMP VARCHAR2(100);
3 BEGIN
4 SELECT 'SQL IN contatena espaços em branco!' CAMPO
5 INTO VTEMP
6 FROM DUAL
7 WHERE 'SP ' IN ( 'SP', 'RJ' );
8
9 DBMS_OUTPUT.PUT_LINE('Concatenou');
10
11 EXCEPTION WHEN NO_DATA_FOUND THEN
12 DBMS_OUTPUT.PUT_LINE('Nao concatenou');
13 END;
14 /
Concatenou

SQL>

Interessante: Usando variável, ele não faz isso!
SQL> DECLARE
2 VTEMP VARCHAR2(100);
3 VALOR VARCHAR2(10) :='SP ';
4 BEGIN
5 SELECT 'SQL IN contatena espaços em branco!' CAMPO
6 INTO VTEMP
7 FROM DUAL
8 WHERE valor IN ( 'SP', 'RJ' );
9
10 DBMS_OUTPUT.PUT_LINE('Concatenou');
11
12 EXCEPTION WHEN NO_DATA_FOUND THEN
13 DBMS_OUTPUT.PUT_LINE('Nao concatenou');
14 END;
15 /
Nao concatenou

SQL>

CONCLUSÃO
Mais uma prova que usar BINDS é sempre uma boa. “Montar” comandos SQL dinamicamente pode acarretar essa concatenação acima.

EXPLICAÇÃO PARA O CASO

Após uma pesquisa na internet sobre o assunto, verificamos um texto de Chip Dawes que diz o seguinte:

Blank-Padded and Nonpadded Comparison Semantics

With blank-padded semantics, if the two values have different lengths, then Oracle first adds blanks to the end of the shorter one so their lengths are equal. Oracle then compares the values character by character up to the first character that differs. The value with the greater character in the first differing position is considered greater. If two values have no differing characters, then they are considered equal. This rule means that two values are equal if they differ only in the number of trailing blanks. Oracle uses blank-padded comparison semantics only when both values in the comparison are either expressions of datatype CHAR, NCHAR, text literals, or values returned by the USER function.

OU seja, o Oracle concatena espaços em branco na string menor para que tenham o mesmo tamanho. Após isso, ele faz a comparação das strings. Se nenhuma letra é diferente, então são iguais.

Caso encerrado!