Primeiro, vamos criar a tabela de teste:

CREATE TABLE glufke_teste
(nro_nota  NUMBER, item NUMBER, valor NUMBER);
INSERT INTO glufke_teste VALUES ( 50, 1, 1.45);
INSERT INTO glufke_teste VALUES ( 50, 2, 3.91);
INSERT INTO glufke_teste VALUES ( 50, 3, 5.04);

SQL> SELECT * FROM glufke_teste;

  NRO_NOTA       ITEM      VALOR
---------- ---------- ----------
        50          1       1,45
        50          2       3,91
        50          3       5,04

SQL>

Nosso objetivo é ratear um valor proporcionalmente nessas linhas. Como exemplo prático, vamos distribuir o valor R$ 49,30!

Sabemos que a soma das 3 linhas é 10,40:

SQL> SELECT SUM(VALOR) FROM GLUFKE_TESTE;

SUM(VALOR)
----------
      10,4

SQL>

Então, através de uma simples regra de 3, vemos o percentual de cada linha! Ou seja, temos que aplicar o valor de 49,30 conforme esses percentuais!

SQL> SELECT VALOR, VALOR/10.4*100 PERC FROM GLUFKE_TESTE;

     VALOR       PERC
---------- ----------
      1,45 13,9423076
      3,91 37,5961538
      5,04 48,4615384

SQL>

Com isso, basta colocar o valor 49.30 ali que temos distribuído! Repare que a soma do valor rateado é exatamente os 49,30 ! Ou seja, está distribuído conforme nossa necessidade!

SQL> select valor, valor/10.4* 49.3 vlr_rateado from glufke_teste;

     VALOR VLR_RATEADO
---------- -----------
      1,45 6,873557692
      3,91 18,53490384
      5,04 23,89153846

SQL>

Usando funções analíticas pra obter esse resultado!

Agora, usando a função analitica SUM, pra buscar “em tempo de execução” a soma da coluna valor (abaixo, a coluna TOTAL), e fazer o cálculo todo numa única tacada!

SELECT
  nro_nota
, item
, valor
, sum(valor) over (order by nro_nota) total
, valor / sum(valor) over (order by nro_nota) * 49.3 vlr_rateado
FROM GLUFKE_teste
WHERE nro_nota = 50
/

  NRO_NOTA       ITEM      VALOR      TOTAL VLR_RATEADO
---------- ---------- ---------- ---------- -----------
        50          1       1,45       10,4 6,873557692
        50          2       3,91       10,4 18,53490384
        50          3       5,04       10,4 23,89153846

SQL>

Vamos adicionar mais um campo chamado VLR_RATEADO, que arredonda pra 2 casas decimais o valor:

SELECT
  nro_nota
, item
, valor
, sum(valor) over (order by nro_nota) total
, valor / sum(valor) over (order by nro_nota) * 50 vlr_rateado
, ROUND(   valor / sum(valor) over (order by nro_nota) * 49.3 ,2 ) vlr_arr
FROM glufke_teste
WHERE nro_nota = 50
/

  NRO_NOTA       ITEM      VALOR      TOTAL VLR_RATEADO VLR_ARR
---------- ---------- ---------- ---------- ----------- -----------
        50          1       1,45       10,4 6,971153846        6,87
        50          2       3,91       10,4 18,79807692       18,53
        50          3       5,04       10,4 24,23076923       23,89

SQL>

PROBLEMA A VISTA!
Quando fazemos rateios e arredondamos o valor, a chance de dar uma diferença de 1 centavo ou mais é muito grande! Se somarmos o valor rateado não fecha com os 49.3!

Veja: 6.87 + 18.53 + 23.89 = 49.29 !!! (diferença de 1 centavo!)

Resolvendo problema do centavo

Vamos usar funções analíticas pra jogar essa diferença de 1 centavo para uma das linhas da nota! (no caso, vamos jogar para a linha de maior valor).

Primeiro, vamos descobrir se realmente existe uma diferença de 1 centavo ou mais:

SELECT
  VLR_RATEADO
, ROUND(VLR_RATEADO,2)                        VLR_ARR
, COUNT(1) OVER (ORDER BY 1)                  QTD_LIN
, ROW_NUMBER()    OVER (ORDER BY VLR_RATEADO) LIN
, SUM(VLR_RATEADO) OVER (ORDER BY 1)          SOMA
, SUM(ROUND(VLR_RATEADO,2)) OVER (ORDER BY 1) SOMA_ARR
FROM
(
 SELECT
   nro_nota
 , item
 , valor
 , valor / SUM(valor) OVER (ORDER BY nro_nota) * 49.3 vlr_rateado
 FROM glufke_teste
 WHERE nro_nota = 50
 )
/

VLR_RATEADO    VLR_ARR    QTD_LIN        LIN       SOMA   SOMA_ARR
----------- ---------- ---------- ---------- ---------- ----------
6,873557692       6,87          3          1       49,3      49,29
18,53490384      18,53          3          2       49,3      49,29
23,89153846      23,89          3          3       49,3      49,29

SQL>

Acima, as colunas QTD_LIN e LIN vão nos ser úteis pra aplicar a diferença apenas na última linha, ou seja, quando QTD_LIN = LIN (no caso 3=3).
A coluna SOMA, contém o valor total.
A coluna SOMA_ARR é a soma do valor arredondado! Repare que tem 1 centavo a menos!

Então, basta fazer um DECODE que aplica essa diferença (49.3 – 49.2 –> SOMA – SOMA_ARR )
Veja:

SELECT
  VLR_RATEADO
, ROUND(VLR_RATEADO,2) VLR_RATEADO_ARR
, DECODE( COUNT( 1) OVER (ORDER BY 1)
       , ROW_NUMBER()    OVER (ORDER BY VLR_RATEADO)
       , SUM( VLR_RATEADO) OVER (ORDER BY 1) - SUM( ROUND(VLR_RATEADO,2)) OVER (ORDER BY 1)+ ROUND(VLR_RATEADO,2)
       , ROUND(VLR_RATEADO,2)
       )  VLR_COM_DIF
FROM
(
SELECT
  nro_nota
, item
, valor
, (valor) / SUM(valor) OVER (ORDER BY nro_nota) * 49.3 vlr_rateado
FROM GLUFKE_teste
WHERE nro_nota = 50
)
/

VLR_RATEADO VLR_RATEADO_ARR VLR_COM_DIF
----------- --------------- -----------
6,873557692            6,87        6,87
18,53490384           18,53       18,53
23,89153846           23,89       23,90

SQL>

O select acima, aplica a diferença de 1 centavo apenas na ultima linha. Dessa forma, a diferença de centavo vai pra uma das linhas e o total rateado sempre fecha corretamente!
A soma do VLR_RATEADO está errada! ( 6,87 + 18,53 + 23,89 = 49,29)
Já o campo VLR_COM_DIF está com a soma correta, fechando os 49,30 !

Dessa forma, com apenas 1 select foi possível realizar o rateio e ainda aplicar a diferença do arredondamento em uma das linhas, graças as funções analíticas!

Outro Exemplo:

INSERT INTO glufke_teste VALUES ( 51, 1, 5);
INSERT INTO glufke_teste VALUES ( 51, 2, 5);
INSERT INTO glufke_teste VALUES ( 51, 3, 5);
INSERT INTO glufke_teste VALUES ( 51, 4, 7.5);
INSERT INTO glufke_teste VALUES ( 51, 5, 7.5);

Vamos aplicar o valor 10 nesses valores:

SELECT
  NRO_NOTA
, ITEM
, VALOR
, ROUND(VLR_RATEADO,2) VLR_RATEADO_ARR
, DECODE( COUNT( 1) OVER (ORDER BY 1)
       , ROW_NUMBER()    OVER (ORDER BY VLR_RATEADO)
       , SUM( VLR_RATEADO) OVER (ORDER BY 1)
       - SUM( ROUND(VLR_RATEADO,2)) OVER (ORDER BY 1)
       + ROUND(VLR_RATEADO,2)
       , ROUND(VLR_RATEADO,2)
       )  VLR_COM_DIF
FROM
(
SELECT
  nro_nota
, item
, valor
, (valor) / SUM(valor) OVER (ORDER BY nro_nota) * 10 vlr_rateado
FROM GLUFKE_teste
WHERE nro_nota = 51
)

  NRO_NOTA       ITEM      VALOR VLR_RATEADO_ARR VLR_COM_DIF
---------- ---------- ---------- --------------- -----------
        51          1          5            1,67        1,67
        51          2          5            1,67        1,67
        51          3          5            1,67        1,67
        51          4        7,5            2,50        2,50
        51          5        7,5            2,50        2,49

SQL>

Para terminar a saga, vamos adicionar a palavra-chave PARTITION BY, e dessa forma, podemos fazer o calculo acima para todas as notas! No exemplo abaixo, vamos ratear o valor 10 pra cada nota. Ou seja, no total, a soma vai dar 20, pois temos apenas 2 notas no exemplo:

SELECT
  NRO_NOTA
, ITEM
, VALOR
, ROUND(VLR_RATEADO,2) VLR_RATEADO_ARR
, DECODE( COUNT( 1) OVER (partition by nro_nota  ORDER BY 1)
       , ROW_NUMBER()    OVER (partition by nro_nota ORDER BY VLR_RATEADO)
       , SUM( VLR_RATEADO) OVER (partition by nro_nota ORDER BY 1)
       - SUM( ROUND(VLR_RATEADO,2)) OVER (partition by nro_nota ORDER BY 1)
       + ROUND(VLR_RATEADO,2)
       , ROUND(VLR_RATEADO,2)
       )  VLR_COM_DIF
FROM
(
SELECT
  nro_nota
, item
, valor
, (valor) / SUM(valor) OVER (partition by nro_nota ORDER BY nro_nota) * 10 vlr_rateado
FROM GLUFKE_teste
)

  NRO_NOTA       ITEM      VALOR VLR_RATEADO_ARR VLR_COM_DIF
---------- ---------- ---------- --------------- -----------
        50          1       1,45            1,39        1,39
        50          2       3,91            3,76        3,76
        50          3       5,04            4,85        4,85
        51          1       5,00            1,67        1,67
        51          3       5,00            1,67        1,67
        51          2       5,00            1,67        1,67
        51          5       7,50            2,50        2,50
        51          4       7,50            2,50        2,49

8 rows selected

SQL> 

Observe que a soma da coluna VLR_COM_DIF fecha exatamente os 20. Ja a coluna VLR_RATEADO_ARR dá diferença de centavo!

Neste LINK tem diversos exemplos muito bons! Até mais!

Nestes casos, podemos usar a ALL_SOURCE, que contém os códigos de todos programas de banco. Normalmente um select com LIKE resolve o problema:

SELECT * FROM all_source
WHERE UPPER(text) LIKE '%INSERT%TABELA%'

O problema é que nem sempre o código está no padrão, por exemplo, o nome da tabela pode estar no lado ou na próxima linha!

INSERT INTO tabelax...

INSERT
INTO tabelax...

O mesmo vale pra UPDATES! Ou seja, se o comando INSERT estiver na linha anterior, essa consulta simples não vai retornar o que procuramos!

UPDATE tabelax SET...

UPDATE
tabelax
SET...

Para resolver o problema, eu fiz esse SQL que busca no banco todas linhas que contém a tabelax E a linha anterior! Com isso você pode encontrar os INSERTS e UPDATES que estão na linha antes também!

SELECT *
FROM (
      SELECT a.owner, a.name, a.line, a.text
      FROM all_source a
      , (
          SELECT owner, name, line, type
          FROM all_source
          WHERE UPPER(text) LIKE '%%ENG_REVISED_ITEMS%'    ----> TABELA A PROCURAR !!!!
            AND owner='APPS'
            AND type <>'PACKAGE'
         )   B
      WHERE a.owner = b.owner
        AND a.name  = b.name
        AND a.type  = b.type
        AND (a.line  = b.line or a.line  = b.line-1)
      )
WHERE UPPER(text) LIKE '%INSERT%'                          ----> COMANDO QUE PODE ESTAR NA LINHA ANTERIOR !!!!
ORDER BY 1,2,3,4;

1 – Baixar e instalar Oracle XE

Download nesse link: http://www.oracle.com/technetwork/database/express-edition/overview/index.html

2 – Baixar Oracle Apex 4.1

Download nesse link: http://www.oracle.com/technetwork/developer-tools/apex/downloads/index.html?ssSourceSiteId=ocombr

Descompactar arquivos no C:\oraclexe\apex

CMD> cd c:\oraclexe\apex
CMD> sqlplus sys@xe as sysdba
SQL> @apexins SYSAUX SYSAUX TEMP /i/
CMD> sqlplus sys@xe as sysdba
SQL> @apxldimg.sql c:\oraclexe
SQL> @apxxepwd.sql <password>
SQL> exec dbms_xdb.setListenerLocalAccess (l_access => FALSE);
SQL> exit
CMD> cd C:\oraclexe\apex\builder\pt-br
CMD> set NLS_LANG=American_America.AL32UTF8
CMD> sqlplus sys@xe as sysdba
SQL> ALTER SESSION SET CURRENT_SCHEMA = APEX_040100;
SQL> @load_pt-br.sql
SQL> exit
CMD> exit

3 – Como acessar

Acesse o Apex pelo navegador: http://127.0.0.1:8080/apex
Workspace: Internal
Username: Admin
Password: <password>
Agora é só criar sua Workspace e começar a trabalhar..

Texto criado por Alex Pagliarini
Comentários aqui

Aprender Oracle

Achei muito bom o evento, muito bem organizado, ótimos palestrantes e congressistas. Valeu cada minuto que estava lá. Parabéns a todos e ano que vem, pretendo ir de novo!!!

http://aprenderoracle.com/2011/07/review-do-evento-guob-2011/

PHPDBA

Um evento ótimo, mas sem excelência, seria como ganhar um iPad de presente numa caixa de papelão. Que se dane a caixa de papelão, eu ganhei um iPad!

O GUOB Tech Day é como ganhar um iPad das mãos do Steve Jobs, tirando uma foto com ele entregando o produto embalado, na caixa original, com uma dedicatória e ainda ganhar um bônus infinito de créditos na AppleStore!

Eu saio do GUOB com um espírito renovado. Cheio de idéias, cheio de intenções, cheio de vontade de crescer na área, de ser um profissional mais completo, de ajudar a comunidade. Sinto-me muito bem por participar de uma comunidade de DBAs quando estou ali, no meio daquela galera. (Paulo Henrique)

http://phpdba.wordpress.com/2011/07/22/guob-tech-day-2011-attendant-feedback/

iMasters

O conjunto de palestrantes nacionais e internacionais foi bem escolhido e a organização, instalações, local e demais detalhes foram ótimos. Recomendo a todos que estiverem interessados no mundo de tecnologias Oracle que se filiem gratuitamente ao GUOB e que participem da comunidade para tornar eventos como este cada vez melhores.

http://www.imasters.com.br/artigo/21478/outros/cobertura-do-guob-tech-day-2011

Eduardo Legatti

Quem não foi, realmente perdeu uma grande oportunidade de ver excelentes palestras e prestigiar grandes profissionais do mundo Oracle. Foi sensacional.

http://eduardolegatti.blogspot.com/2011/07/minha-experiencia-no-guob-tech-day-2011.html

CAPIN

Eu Fui! E irei em outros.
http://franquini.wordpress.com/2011/07/17/guob-tech-day-2011/

FOTOS OFICIAIS DO GUOB

http://www.guob.com.br/index.php?page=album-de-fotos

COBERTURA PELA OTN LA

Abaixo, deixo os links da cobertura feita pela OTN:

FOTOS:
Brasil – Oracle Technology Network America Latina Tour 2011

VIDEOS:
Rodrigo Almeida
Eduardo Hahn
Marcus Vinicius
Rodrigo Mufalani
Thomas Glufke
David Siquiera
Marina Neumann

Se você tem um review do GUOB Tech Day, envie um email para thomas arroba glufke.net com o link do seu review que atualizaremos essa página!

Este recurso permite criar funções que retornam dados como se fossem uma tabela virtual, podendo transformar os dados de retorno enquanto eles são produzidos, ou seja, é possível alterar os dados pesquisados em uma tabela, linha por linha, enquanto eles são processados, sem ter que esperar pelo retorno completo do “result set” (conjunto de dados que são retornados pela função).

Este recurso é ótimo para ETL (Extract, Transform, and Load), pois é rápido e consome menos memória que outros métodos que podem ser utilizados para o mesmo objetivo, como por exemplo, preencher um cursor e percorrê-lo para transformar e retornar dados.

Seguem abaixo 3 scripts que demonstram como criar e testar uma Pipelined Table Function. Os scripts utilizam a tabela EMPLOYEES do schema de exemplo HR.

Para iniciar o passo-a-passo dos itens abaixo, é necessário conectar-se previamente no Banco de Dados desejado, através do SQL Plus, com um usuário com privilégios administrativos (usuário contendo a role DBA ou o privilégio de sistema SYSDBA) ou com o usuário HR.

1- Criando a package HR.PKG_TYPES

A package HR.PKG_TYPES contém os tipos de dados que são criados para retornarem uma tabela virtual na função que será criada no próximo passo:

create or replace package HR.PKG_TYPES as
  TYPE TABLEEMPTYPE IS TABLE OF EMPLOYEES%ROWTYPE;
  TYPE ROWEMPTYPE IS RECORD(
          EMPLOYEE_ID    EMPLOYEES.EMPLOYEE_ID%TYPE,
          FIRST_NAME     EMPLOYEES.FIRST_NAME%TYPE,
          LAST_NAME      EMPLOYEES.LAST_NAME%TYPE,
          EMAIL          EMPLOYEES.EMAIL%TYPE,
          PHONE          EMPLOYEES.PHONE_NUMBER%TYPE,
          HIRE_DATE      EMPLOYEES.HIRE_DATE%TYPE,
          JOB_ID         EMPLOYEES.JOB_ID%TYPE,
          SALARY         EMPLOYEES.SALARY%TYPE,
          COMMISSION_PCT EMPLOYEES.COMMISSION_PCT%TYPE,
          MANAGER_ID     EMPLOYEES.MANAGER_ID%TYPE,
          DEPARTMENT_ID  EMPLOYEES.DEPARTMENT_ID%TYPE
         );
END;
/

2- Criando a função HR.FC_OBTER_EMPREGADOS

A função HR.FC_OBTER_EMPREGADOS lê e retorna os dados de apenas 4 colunas da tabela HR.EMPLOYEES, transformando os dados das colunas LAST_NAME e EMAIL:

CREATE OR REPLACE function HR.FC_OBTER_EMPREGADOS
  return PKG_TYPES.TABLEEMPTYPE
  PIPELINED IS
  var_linha PKG_TYPES.ROWEMPTYPE;
BEGIN
  FOR CUR_ROW IN (SELECT EMPLOYEE_ID, FIRST_NAME, LAST_NAME, EMAIL
                    FROM HR.EMPLOYEES) LOOP
    var_linha.EMPLOYEE_ID := CUR_ROW.EMPLOYEE_ID;
    var_linha.FIRST_NAME  := CUR_ROW.FIRST_NAME;
    var_linha.LAST_NAME   := UPPER(CUR_ROW.LAST_NAME);
    var_linha.EMAIL       := UPPER(cur_row.EMAIL || '@ORACLE.COM');

    PIPE ROW(VAR_LINHA);
  END LOOP;

  RETURN;
END;
/

Obs.: A instrução PIPE ROW retorna os resultados para a sessão de usuário Oracle, linha por linha. Isso otimiza o tempo de resposta da aplicação.

3- Testando a função HR.FC_OBTER_EMPREGADOS

A query abaixo retorna os dados da função HR.FC_OBTER_EMPREGADOS, como se fossem uma tabela virtual:

SELECT * FROM TABLE(HR.FC_OBTER_EMPREGADOS);
/

Observações:

O exemplo deste artigo foi criado apenas para demonstrar o uso de Pipelined Table Functions. Para mais informações e exemplos deste tipo de função, consulte as referências no final deste artigo.

Comentários Finais:

Apesar das Pipelined Table Functions serem trabalhosas para criar, elas são ótimas para otimizar performance de queries complexas que utilizam funções de transformação para alterar os valores originais das consultas.

Na empresa em que trabalho temos um caso de uma query que demorava 54 segundos para gerar os dados da folha de ponto mensal de cada empregado. Essa query estava literalmente “parando” o servidor de Banco de Dados. Eu orientei o desenvolvedor da query a alterá-la utilizando a Cláusula WITH (ver artigo “Cláusula WITH (para tunar queries)” que eu postei neste blog em 01/10/2010) + Pipelined Table Function. Após as alterações o tempo de execução da query caiu para 0.4 segundos.

Referências:

- http://www.praetoriate.com/10g_139.htm
- http://oraclelon1.oracle.com/docs/cd/B14117_01/appdev.101/b10800/dcitblfnsref.htm
- http://www.codeguru.com/cpp/data/mfc_database/oracle/article.php/c4285/
- http://www.databasejournal.com/features/oracle/article.php/2222781
- http://download.oracle.com/docs/cd/B28359_01/appdev.111/b28425/pipe_paral_tbl.htm

Fonte: http://www.fabioprado.net/2010/12/pipelined-table-functions-funcao-para.html

Fábio Prado – http://www.fabioprado.net/
Oracle Certified (OCA)
Microsoft Certified (MCT + MCPD + MCAD + MCSD + MCDBA)

Estes serão os livros sorteados:

SORTEIO ENCERRADO – LISTA DOS GANHADORES
Dia 13/08/2010 – Guia Novatec – Oracle 10g SQL – GANHADOR: @garcia_joao
Dia 20/08/2010 – Guia Novatec – Cascading Style Sheets – GANHADOR: @marcelo_hugo
Dia 27/08/2010 – Guia Novatec – Java 2 – GANHADOR: @stefandeckert
Dia 03/09/2010 – Guia Novatec – JavaServer Pages – GANHADOR: @jeroqueiroz
Dia 10/09/2010 – Livro Programação de Jogos com C++ e DirectX – GANHADOR: @anitokj

Como Participar?

1. Para concorrer você deve seguir no twitter o @glufke

2. Enviar a seguinte mensagem:

Quero participar do sorteio de livros de oracle, java, etc do @glufke – http://bit.ly/cMIzSV

3. Aguardar o sorteio nos dias acima ao MEIO DIA!

Normas

1. O Sorteio se dará de forma aleatória para todos que estão seguindo @glufke e deram RT na mensagem.
2. O vencedor será contatado via twitter e será solicitado o endereço para enviar o livro.
3. O envio do livro será pago pelo GLUFKE.NET via encomenda registrada

Qualquer dúvida, envie para o twitter @glufke

BOA SORTE E BONS ESTUDOS

1 – Adicionar o tipo de saída Microsoft Excel

Na responsabilidade Administrador de Sistema você deve acessar o caminho abaixo:
Instalar -> Idiomas
Insira um registro com estes valores:
Formato do Arquivo = Text
Tipo de Mime = application/vnd.ms-excel
Descrição = Microsoft Excel

2 – Criar um procedimento PL/SQL

A saída deve ter os campos separados pelo caractere TAB.

CREATE OR REPLACE PACKAGE PKG_REP_EXCEL IS

  PROCEDURE BUILD (ERRBUF OUT VARCHAR2,
                   RETCODE OUT NUMBER);
END PKG_REP_EXCEL;
/

CREATE OR REPLACE PACKAGE BODY PKG_REP_EXCEL IS
  PROCEDURE BUILD (ERRBUF OUT VARCHAR2,
                   RETCODE OUT NUMBER) IS
    CURSOR CUR IS
      SELECT '1' A, '2' B, '3' C FROM DUAL
      UNION
      SELECT '4' A, '5' B, '6' C FROM DUAL
      UNION SELECT '7' A, '8' B, '9' C FROM DUAL;

    REG CUR%ROWTYPE;

    V_DIV VARCHAR2(1) := CHR(9); -- TAB
    V_OUT VARCHAR2(4000);

  BEGIN

    -- HEADER
    V_OUT := 'A' || V_DIV || 'B' || V_DIV || 'C';
    FND_FILE.PUT_LINE(FND_FILE.OUTPUT, V_OUT);

    -- LINES
    FOR REG IN CUR LOOP
      V_OUT := REG.A || V_DIV || REG.B ||   V_DIV || REG.C;
      FND_FILE.PUT_LINE(FND_FILE.OUTPUT, V_OUT);
    END LOOP;

  END BUILD;

END PKG_REP_EXCEL;
/

3 – Criar o Concorrente

O executável é criado normalmente como Procedimento Armazenado do PL/SQL e o programa com formato de saída Texto.

4 – Execução

Após a visualização da saída, utilize o menu Ferramentas e a opção Copiar Arquivo. Nesse momento aparecerá uma LOV para você escolher o tipo de saída.

5 – Arquivo Microsoft Excel

Selecionado o tipo de arquivo Microsoft Excel, basta salvar ou abrir e temos o nosso relatório.
Observação: Tome cuidado ao salvar o arquivo para não deixar a extensão TXT. Caso o arquivo seja gravado com essa extensão, altere para XLS.

Texto criado por Ricardo Rauber – Tutorial disponível para download AQUI
Comentários aqui

• O que é um Local Index?
• O que é um Global Index?
• Quando você forçaria a criação de um Global Index em uma partition table?
• Quando você recomendaria criar um Global Index em vez de um Local Index?

Para responder a essas perguntas….

1. O que é um Local Index?

Local Indexes particionados são mais fáceis de gerenciar, cada partição do Local Index está associado a uma partição. Eles também oferecem maior disponibilidade e são comuns em ambientes de DSS. Quando tomamos qualquer ação (MERGE, SPLIT,EXCHANGE etc) em um Local Index, isso impacta apenas aquela partição e as outras estarão disponíveis. Nós não podemos adicionar explicitamente um Local Index para uma nova partição. O Local Index será adicionado implicitamente a nova partição, quando for criada uma nova partição na tabela. Da mesma forma, não podemos dropar o índice local em uma partição específica. Ele pode ser dropado automaticamente quando nós dropamos a partição da tabela subjacente. Local Indexes podem ser UNIQUE quando a chave da partição é parte do índice composto. Unique Local Indexes são úteis para o ambiente OLTP. Podemos também criar bitmap indexes em tabelas, com a restrição de que os índices de bitmap deve ser local para a tabela particionada. Eles não podem ser Global Indexes.

SQL> CREATE TABLE employees
2 (employee_id NUMBER(4) NOT NULL,
3 last_name VARCHAR2(10),
4 department_id NUMBER(2))
5 PARTITION BY RANGE (department_id)
6 (PARTITION employees_part1 VALUES LESS THAN (10) TABLESPACE ODS_STAGE_DATA,
7 PARTITION employees_part2 VALUES LESS THAN (20) TABLESPACE ODS_STAGE_DATA,
8 PARTITION employees_part3 VALUES LESS THAN (30) TABLESPACE ODS_STAGE_DATA);

Table created.

SQL> declare
2 v_no number :=1;
3 begin
4 delete employees;
5 for i in 1..10 loop
6 insert into employees values(v_no,'name...',v_no);
7 v_no := v_no+1;
8 end loop;
9 end;
10 /

PL/SQL procedure successfully completed.

SQL>
SQL> create index idx_local on employees(last_name) local;

Index created.

SQL>

2. O que é Global Index?

Global Indexe são usado em ambientes OLTP e oferecem um acesso eficiente a qualquer registro individual. Temos dois tipos de Global Index: Eles são global Non-partitioned index e Global partitioned index. Global Non-partitioned index se comportam como um índice não particionado.

A chave de partição de um Global partitioned index é independente da chave de partição da tabela. A maior partição de um Global Index deve ter um limite de partição, cujos todos valores são MAXVALUE. Se você quiser adicionar uma nova partição, sempre, é preciso dividir a partição MAX. Se um Global Index Partition está vazio, você pode dropá-lo explicitamente com um ALTER INDEX DROP PARTITION. Se um Global Index Partition contém dados, ao dropar a partição faz com que a partição mais próxima seja marcada como inutilizável. Não é possível dropar a maior partição de um índice global.

Exemplo de Global Non-partitioned index:

SQL> CREATE INDEX employees_global_idx ON employees(employee_id);

Index created.

SQL>

Exemplo de Global Partitioned index:

SQL> CREATE INDEX employees_global_part_idx ON employees(employee_id)
2 GLOBAL PARTITION BY RANGE(employee_id)
3 (PARTITION p1 VALUES LESS THAN(3),
4 PARTITION p2 VALUES LESS THAN(6),
5 PARTITION p3 VALUES LESS THAN(9));
PARTITION p3 VALUES LESS THAN(9))
*
ERROR at line 5:
ORA-14021: MAXVALUE must be specified for all columns

SQL> CREATE INDEX employees_global_part_idx ON employees(employee_id)
2 GLOBAL PARTITION BY RANGE(employee_id)
3 (PARTITION p1 VALUES LESS THAN(3),
4 PARTITION p2 VALUES LESS THAN(6),
5 PARTITION p3 VALUES LESS THAN(11),
6 PARTITION p4 VALUES LESS THAN(20),
7 PARTITION p5 VALUES LESS THAN(MAXVALUE));

Index created.

Agora a partição p4 está vazia. Vamos dropar a partição vazia e ver o status:

SQL> select count(*) from employees where
2 employee_id between 12 and 20;

COUNT(*)
----------
0
SQL> ALTER index employees_global_part_idx drop partition p4;

Index altered.

SQL> SELECT partition_name,status from user_ind_partitions where
2 index_name='EMPLOYEES_GLOBAL_PART_IDX';

PARTITION_NAME STATUS
------------------------------ --------
P1 USABLE
P2 USABLE
P3 USABLE
P5 USABLE

Agora vamos dropar a partição P3 e ver o estado. Ao dropar essa partição, isso deve invalidar a partição mais próxima. Aqui a partição P5 é a próxima maior partição.

SQL> alter index employees_global_part_idx drop partition p3;

Index altered.

SQL> SELECT partition_name,status from user_ind_partitions where
2 index_name='EMPLOYEES_GLOBAL_PART_IDX';

PARTITION_NAME STATUS
------------------------------ --------
P1 USABLE
P2 USABLE
P5 UNUSABLE

SQL> alter index employees_global_part_idx rebuild;
alter index employees_global_part_idx rebuild
*
ERROR at line 1:
ORA-14086: a partitioned index may not be rebuilt as a whole

SQL> alter index employees_global_part_idx rebuild partition p5;

Index altered.

SQL> SELECT partition_name,status from user_ind_partitions where
2 index_name='EMPLOYEES_GLOBAL_PART_IDX';

PARTITION_NAME STATUS
------------------------------ --------
P1 USABLE
P2 USABLE
P5 USABLE

Partition Index podem ser mantidos usando UPDATE GLOBAL INDEXES. Os índice estarão disponíveis durante a manutenção e está disponível online. Nós não precisamos de rebuild o índice após a manutenção do índice.

Por exemplo,

SQL> alter table employees drop partition employees_part3
2 update global indexes;

Table altered.

SQL> SELECT partition_name,status from user_ind_partitions where
2 index_name='EMPLOYEES_GLOBAL_PART_IDX';

PARTITION_NAME STATUS
------------------------------ --------
P1 USABLE
P2 USABLE
P5 USABLE

SQL>

3. Quando você forçaria a criação de Global index em uma Partition table?

Quando você cria uma chave primária, você será forçado a criar um Global Index. Quando você cria Unique Index, você é forçado a criar o Global Index. Manter a coluna única é a razão mais comum para os índices globais. Se você tentar criar um Local Index em chave única, você receberá o erro abaixo.

ORA-14039: partitioning columns must form a subset of key columns of a UNIQUE index

Assim, podemos criar Local Index em chave única, quando adicionamos a chave de partição como parte da chave composta no índice. Vamos demonstrar isto:

No exemplo abaixo, o Unique Index falhou já que a chave da partição não é parte da chave composta do índice.

SQL> create unique index idx_emp_id on employees(employee_id) local;
create unique index idx_emp_id on employees(employee_id) local
*
ERROR at line 1:
ORA-14039: partitioning columns must form a subset of key columns of a UNIQUE index

No caso abaixo, ele permite criar um Global Index:

SQL> create unique index idx_emp_id on employees(employee_id);

Index created.

SQL> drop index idx_emp_id;

Index dropped.

O caso abaixo, o Unique Index é criado com sucesso, pois a chave DEPARTMENT_ID é parte da chave composta.

SQL> create unique index idx_emp_id on employees(employee_id,department_id) local;

Index created.

SQL>

4. Quando você recomendaria criar Global Index vs. Local Index?

Podemos usar Global Index se uma consulta retorna um número pequeno de linhas a partir de um número potencialmente grande de partições.

Texto baseado no blog do Govind

Você pensou que o Iron Man era mesmo o bilionário industrial Tony Stark, temos provas de que isso é apenas um apelido mal disfarçado do magnata bilionário da Oracle, Larry Ellison. A prova:

Larry Ellison – Oracle:

Tony Stark – Ironman

Tony Stark tem o ROSTO do Larry, a VOZ do Larry, os CARROS do Larry, o DINHEIRO de Larry e os AVIÕES também. Pra completar a lista de evidências, temos a Oracle como um dos principais patrocinadores do filme:

Está comprovado!

Ao longo dos anos, o banco Oracle permite realizrmos muitas operações online, como:

• Modificar a maioria dos parâmetros (Apenas 90 dos 350 não são modificáveis online.)
• Reorganização de objetos (transformar uma tabela não particionada em uma particionada, recuperando um espaço livre, e assim por diante)
• Criar índices
• Aplicação de patches no Banco de dados com o Oracle Real Application Clusters
• Atualizar o banco de dados Oracle de release em release

O resultado é que quase todas mudanças em nível de banco de dados pode ser feito enquanto o banco está funcionando e realizando transações – com algumas raras excepções gritantes, como re-criar uma procedure, alterar triggers, adicionar grants, revoke de grant, e modificar views. Em suma, os objetos que constituem esse tipo de modificação não podiam ser modificadas, enquanto os usuários estavam utilizando. Se uma procedure estava sendo executada e um DBA tentou atualizar ela (CREATE OR REPLACE o código com o novo código mexido, afim de corrigir um bug), o DBA iria ficar esperando (BLOCKED) por essa pessoa até terminar sua execução.

Além disso, qualquer pessoa que tentou posteriormente executar uma procedure que o DBA está tentando substituir também ficaria bloqueado pelo DBA. E na maioria dos casos, o DBA não modifica apenas uma única procedure, mas muitas,  e o CREATE OR REPLACE do novo código da procedure tenderia a invalidar outros objetos dependentes também. O banco de dados parece “congelar”, o DBA não pode realizar as tarefas de patch (substituir alguns procedimentos, pacotes, views, triggers, e assim por diante), e os usuários finais não podem realizar as suas tarefas. Eles acabaram bloqueando e travando-se mutuamente.

Isto tudo termina tudo com o Oracle Database 11g Release 2 e o Edition-Based Redefinition, que permite aos DBAs e usuários finais acessar mais de uma ocorrência de uma stored procedure, trigger, view, e outros objetos e, portanto, isolar as mudanças em um esquema. Começando com o Oracle Database 11g Release 2, um único esquema pode agora ter duas ou mais ocorrências (vamos pensar em “versões”) de um stored procedure (função, trigger, e assim por diante) ou uma view ou de sinônimos e todos seus metadados relacionados, tais como GRANTS a esses objetos. (Estas duas ocorrências são independentes, eles coexistem, mas não interferem umas com as outras.) A “mágica” que permite isso é o novo objeto de edição (EDITION),  que introduz um novo namespace transparente que permite mais de uma ocorrência ao mesmo tempo de uma stored procedure, trigger e assim por diante.

No passado, um objeto de esquema era referenciado com dois componentes: o owner do objeto e o nome. Isso impedira a existência de dois procedimentos armazenados como “P” em um único esquema. Ou seja, você poderia ter apenas um objeto referenciado por “OWNER.P”.

O objeto de edição no Oracle Database 11g Release 2 introduz uma terceira dimensão no esquema de resolução de nomes: todos os objetos são referenciados pela edição da sessão, o owner do objeto e o nome do objeto. Cada banco de dados tem pelo menos uma edição a ela associados, e a base de dados tem sempre uma edição padrão. Quando você cria uma sessão no Oracle Database 11g Release 2, a sua sessão terá um atributo associado a ela que indica a edição que sua sessão estará usando (por padrão, esta será a edição padrão do banco de dados). Usando ALTER SESSION, você pode especificar qualquer edição para a qual tiver sido concedido o acesso em sua sessão.

Quando você invocar ou referenciar objetos no Oracle Database 11g Release 2, esses objetos são referenciado também com a edição fixada na sua sessão. Isso significa que um administrador do aplicativo pode agora logar, alterar uma sessão para utilizar uma edição chamada VERSION2, por exemplo, e compilar o código para esta edição. O trabalho realizado pelo administrador da aplicação na edição VERSION2 é visível apenas em sessões usando a edição VERSION2. “VERSION2″ porque não é a edição padrão, ninguém mais vê essas mudanças (novas procedures, views, drop de pacotes, e assim por diante) a menos que a pessoa solicita especificamente (via ALTER SESSION) e tem o privilégio de usar e “ver” aquela edição. O administrador do aplicativo é capaz de criar ou substituir qualquer código sem concorrer com os outros que estão executando o código. Se o administrador do aplicativo precisa substituir 50 unidades de PL/SQL, essa pessoa pode fazê-lo em isolamento durante todo o tempo enquanto aplicação de produção continua rodando.

O exemplo a seguir demonstra este pequeno conceito. Vou começar como DBA, criando uma conta de demonstração e concedendo o mínimo de privilégios necessário:

SQL> create user demo
  2    identified by demo;
User created.

SQL> grant create session,
  2       create procedure
  3    to demo;
Grant succeeded.

Agora vou iniciar o processo que me permitirá criar mais de uma ocorrência de objetos do meu código na base de dados. Vou precisar de uma nova edição, a fim de fazer isso. O seguinte comando cria a nova edição:

SQL> create edition version2
  2      as child of ora$base;
Edition created.

Criei uma edição chamada VERSION2 no meu banco de dados, e ela começa sendo filha de ORA$BASE. Como mencionado acima, cada banco de dados tem pelo menos uma edição e cada banco de dados tem uma edição padrão. Por exemplo, todo Oracle Database 11g Release 2 vai ter uma edição padrão chamado ORA$BASE. Como filha de ORA$BASE, minha edição VERSION2 começa a vida como uma cópia completa da edição padrão ORA$BASE. Tudo que está valendo em ORA$BASE também está em VERSION2.

É importante notar, contudo, que esta VERSION2 é uma cópia virtual. A instrução CREATE EDITION não copia fisicamente cada objeto da ORA$BASE. Pelo contrário, VERSION2 aponta para os objetos ORA$BASE, e não vai começar a usar espaço no dicionário até que eu modifique os objetos no contexto da edição VERSION2.

Então, agora eu vou instalar a versão 1 da minha aplicação na conta DEMO:

DEMO> create or replace
  2      procedure my_procedure
  3      as
  4      begin
  5         dbms_output.put_line
  6         ( 'I am version 1.0' );
  7      end;
  8      /
Procedure created.

DEMO> create or replace
  2      procedure my_procedure2
  3      as
  4      begin
  5         my_procedure;
  6      end;
  7      /
Procedure created.

Até agora muito simples, e quando eu executo essa “aplicação” eu vejo o seguinte:

DEMO> exec my_procedure2
I am version 1.0

PL/SQL procedure successfully completed.

Agora, vamos supor que este código esteja executando em produção por um tempo e eu descubro um bug, algo que precise reparar na stored procedure. No passado, eu precisaria que o usuário parasse de rodar, a fim de instalar o novo código.

Agora, no entanto, eu posso levantar a mudança no banco de dados enquanto o banco está funcionando, e os usuários estão executando o meu código com a edição padrão (ORA$BASE). Primeiro, como o DBA, eu preciso permitir que a conta DEMO use edições, e então eu preciso permitir que a conta DEMO veja e use a edição VERSION2. Além disso, para esta demonstração, vou deixar que a conta SCOTT veja e use VERSION2:

SQL> alter user demo
  2    enable editions;
User altered.

SQL> grant use
  2    on edition version2
  3    to demo;
Grant succeeded.

SQL> grant use
  2    on edition version2
  3    to scott;
Grant succeeded.

A instrução ALTER USER permite que a conta DEMO use edições dos códigos. Sem este GRANT, a conta DEMO seria capaz de ter apenas de ter uma cópia do código em vigor, em determinado momento, assim como na versão 7.0 até a versão 11.1 do Oracle Database. A instrução GRANT USE em seguida, permite que a conta DEMO e SCOTT vejam a edição VERSION2. Como a conta DEMO é habilitada para edição, ela será capaz de modificar a edição VERSION2 assim como alterar implementação de vários objetos, nesta edição, sem afetar outras edições. A conta SCOTT será capaz de usar apenas a edição deste VERSION2 – para definir a sua edição atual, na sua sessão de VERSION2 e ver os objetos como eles existem naquela edição.

Agora eu vou “patchear” a minha aplicação. Logando novamente com a conta DEMO, vou ver primeiro o que eu tenho no local após alterar a minha sessão de usar a edição VERSION2, como mostrado na Listagem 1.

Listagem de código 1: Definindo a edição VERSION2 e selecionando procedures

DEMO> alter session
  2       set edition = version2;
Session altered. 

DEMO> select object_name,
  2               object_type,
  3               status,
  4               edition_name
  5      from user_objects;

OBJECT_NAME      OBJECT_TYPE    STATUS    EDITION_NAME
-------------    -----------    ------    ------------
MY_PROCEDURE2    PROCEDURE      VALID     ORA$BASE
MY_PROCEDURE     PROCEDURE      VALID     ORA$BASE

Então, agora, na edição VERSION2, eu tenho ambas unidades de PL/SQL (MY_PROCEDURE e MY_PROCEDURE2), mas como denota a coluna EDITION_NAME, eles são “herdadas” da ORA$BASE. A edição VERSION2 está apontando para a cópia em ORA$BASE, mas não é uma cópia física do código.

Digamos que eu tenha que corrigir dois bugs. Primeiro, eu tenho um bug na implementação de MY_PROCEDURE, e eu vou substituir esse código. Em segundo lugar, eu perdi um GRANT, quando estava fazendo deploy do meu aplicativo, o usuário SCOTT era pra ter o privilégio EXECUTE MY_PROCEDURE2, mas de alguma forma isso não aconteceu quando eu instalei a última aplicação. Eu vou começar atualizando o código:

DEMO> create or replace
  2      procedure my_procedure
  3      as
  4      begin
  5         dbms_output.put_line
  6         ( 'I am version 2.0' );
  7      end;
  8      /
Procedure created.

DEMO> select object_name,
  2         edition_name
  3      from user_objects;

OBJECT_NAME      EDITION_NAME
-------------    ------------
MY_PROCEDURE2    ORA$BASE
MY_PROCEDURE     VERSION2

Como você pode ver, eu ainda tenho apenas dois objetos, mas existem três objetos físicos lá, como você verá em seguida. Tenho MY_PROCEDURE2, que é herdado ORA$BASE, e eu tenho MY_PROCEDURE, que agora existe fisicamente na edição VERSION2. Isso é chamado de colocar em prática o código quando eu tenho uma cópia física na edição, eu atualizei o código naquela edição.

Usando um novo conjunto de views pra ver em todas as edições e final em _AE – Eu posso ver todo o estado do meu esquema DEMO. Eu consulto a view USER_OBJECTS_AE para OBJECT_NAME e EDITION_NAME:

DEMO> select object_name,
  2         edition_name
  3      from user_objects_AE;

OBJECT_NAME      EDITION_NAME
-------------    ------------
MY_PROCEDURE     ORA$BASE
MY_PROCEDURE2    ORA$BASE
MY_PROCEDURE     VERSION2

Olhando para as diferentes edições, você pode ver que eu atualizei duas cópias físicas de MY_PROCEDURE agora: uma na edição padrão ORA$BASE e uma na nova edição VERSION2 que estou trabalhando. Agora vou aplicar o grant de EXECUTE para SCOTT:

DEMO> grant execute
  2      on my_procedure2
  3      to scott;
Grant succeeded.

DEMO> select object_name,
  2          edition_name
  3       from user_objects;

OBJECT_NAME      EDITION_NAME
-------------    ------------
MY_PROCEDURE2    VERSION2
MY_PROCEDURE     VERSION2

DEMO> select object_name,
  2         edition_name
  3       from user_objects_AE;

OBJECT_NAME      EDITION_NAME
-------------    ------------
MY_PROCEDURE2    ORA$BASE
MY_PROCEDURE     ORA$BASE
MY_PROCEDURE2    VERSION2
MY_PROCEDURE     VERSION2

Se você olhar para USER_OBJECTS, verá que eu tenho as duas procedures, mas ambas já foram atualizadas na edição VERSION2. Ao conceder o grant de EXECUTE nas procedures MY_PROCEDURE2 para SCOTT, eu fiz uma versão física da stored procedure aparecer na edição VERSION2, e eu apliquei o grant para que a edição em isolamento, sem encontrar quaisquer problemas de concorrência (problemas de bloqueios / lock porque alguém estava rodando a procedure). Olhando a USER_OBJECTS_AE, você pode ver que há agora quatro objetos físicos, dois em cada edição.

Agora, quando eu executo a procedure MY_PROCEDURE2 na edição VERSION2, eu vejo

DEMO> SELECT SYS_CONTEXT
  2         ('userenv',
  3          'current_edition_name') sc
  4       FROM DUAL;

SC
----------------------
VERSION2

DEMO> exec my_procedure2
I am version 2.0

PL/SQL procedure successfully completed.

A versão 2.0 do código é executada.

Agora, simplesmente por conectar e depois usar o banco com edição padrão (ainda ORA$BASE), iremos ver

DEMO> connect demo/demo
Connected.

DEMO> SELECT SYS_CONTEXT
  2         ('userenv',
  3          'current_edition_name') sc
  4      FROM DUAL;

SC
-----------------------
ORA$BASE

DEMO> exec my_procedure2
I am version 1.0

PL/SQL procedure successfully completed.

A versão 1.0 do código ainda está lá, e por padrão, ele será executado.

Além disso, para ver o efeito do privilégio EXECUTE que eu concedi ao SCOTT, eu posso conectar como SCOTT e tentar executar o procedimento armazenado MY_PROCEDURE2 na edição padrão e a edição VERSION2, como mostrado na Listagem 2.

Listagem de código 2: Executando my_procedure2 em edições atuais e na VERSION2

DEMO> connect scott/tiger
Connected.

SCOTT> SELECT SYS_CONTEXT
  2         ('userenv',
  3          'current_edition_name') sc
  4       FROM DUAL;

SC
-----------------------
ORA$BASE

SCOTT> exec demo.my_procedure2
BEGIN demo.my_procedure2; END;

      *
ERROR at line 1:
ORA-06550: line 1, column 7:
PLS-00201: identifier 'DEMO.MY_PROCEDURE2' must be declared
ORA-06550: line 1, column 7:
PL/SQL: Statement ignored

SCOTT> alter session
  2       set edition = version2;
Session altered.

SCOTT> exec demo.my_procedure2
I am version 2.0

PL/SQL procedure successfully completed.

Como você pode ver, quando SCOTT está usando a edição ORA$BASE, ele não pode ver ou executar a stored procedure MY_PROCEDURE2. No entanto, na edição VERSION2 o usuário SCOTT pode ver e executar esse procedimento, por isso, quando a versão 2.0 do aplicativo entra em produção, SCOTT terá a capacidade de executar esse procedimento por padrão.

Neste ponto, estou pronto para liberar este código para a produção para ser utilizado pela comunidade geral. Um único, simples ALTER DATABASE feito pelo DBA define a edição atual do banco de dados para VERSION2, e esse código se torna imediatamente acessível.

Gostaria de salientar que esta é apenas a ponta do iceberg. Aqui eu tive que fazer operações relativamente comums: substituir algumas unidades PL/SQL existentes e mudar GRANTS em alguns objetos. Eu não tomei toda a aplicação da versão 1.0 para a versão 2.0, porque isso implicaria mudar tabelas e outros objetos que não são “editáveis”. Então, o que esta coluna discutiu até agora é uma necessidade muito comum de aplicar correções em um sistema, em que você precise aplicar alterações e mudanças de código e privilégio, mas não alterações físicas, como alterações de esquema como adicionar colunas, acrescentar índices ou alterar tabelas. Estarei abordando a forma de realizar essas tarefas na próxima coluna.

Até então, veja o Capítulo 19 “Oracle Database Advanced Application Developer’s Guide 11g Release 2 (11.2)” encontrado em www.bit.ly/1m2n0J.

Esta é uma tradução literal do artigo escrito por Tom Kyte na Oracle Magazine de Janeiro/2010 por glufke.net.

Comente AQUI