Pular para o conteúdo
  • Este tópico contém 22 respostas, 3 vozes e foi atualizado pela última vez 2 anos, 2 meses atrás por Avatar photoJosé Laurindo Chiappa.
Visualizando 8 posts - 16 até 23 (de 23 do total)
  • Autor
    Posts
  • #158068
    Avatar photoJosé Laurindo Chiappa
    Moderador

      Seguem respostas :

      “Oi Chiappa, sim tentei incluir colunas de rowid na consulta, fazer as junções no where e também de criar a view com uma única tabela, todas essas tentativas falharam. Criei as tabelas de log com várias opções de parâmetros diferentes e não funcionou.”

      ==>> hmmm, a partir do momento que NEM MESMo uma view materializada de UMA SÓ TABELA, que é a mais simples possível, vc consegue ter FAST REFRESH, parou : vc COM CERTEZA tem alguma issue aí nesse seu banco… Talvez alguma permissão faltante, TALVEZ (como eu disse Antes!!) alguma limitação do CLOUD (bem possível, EM ESPECIAL se for Autonomous database), tem caroço nesse angú – VALIDE isso com seu DBA e/ou com o Suporte Oracle….
      A sugestão é vc repetir este meu teste aqui de baixo, usando a tabela de demo chamada DEPT, do schema SCOTT, onde a PK é essa coluna DEPT :

      => crio PRIMEIRO o mv log, isso é Crucial :

      scott@DESENV:SQL>create materialized view log on DEPT with rowid, primary key;

      Log de view materializada criado.

      => crio uma mv que deve ser populada IMEDIATAMENTE, com TODOS os dados que Obedecerem à qiery, mas Futuramente só vai ser atualizada sob demanda (cláusula ON DEMMAND) e de modo INCREMENTAL, usando os LOGs que servem pra isso (REFRESH FAST) :

      scott@DESENV:SQL>create materialized view MV_DEPT BUILD IMMEDIATE REFRESH FAST ON DEMAND
      2 AS
      3 select
      4 ROWID as DEPT_ROWID, DEPTNO, DNAME FROM DEPT WHERE DEPTNO < 40;

      View materializada criada.

      => consulto os dados na tabela E na mv :

      scott@DESENV:SQL>select * from dept;
      
      

      DEPTNO DNAME LOC

      
      
      <hr />
      
      
      43 dept43
      42 dep 42
      77 depto 77
      75 depto 75
      10 ACCOUNTING     NEW YORK
      20 RESEARCH       DALLAS
      30 SALES          CHICAGO
      40 OPERATIONS     BOSTON
      44 NOVO DEPT 44
      
      
      
      9 linhas selecionadas.
      
      scott@DESENV:SQL>select * from MV_DEPT;
      
      DEPT_ROWID             DEPTNO DNAME
      
      <hr />
      
      AAAXmhAAhAAAjTwAAA         10 ACCOUNTING
      AAAXmhAAhAAAjTwAAB         20 RESEARCH
      AAAXmhAAhAAAjTwAAC         30 SALES

      ==> só para mostrar que a mv FOI criada como especifiquei, não tem nada a ver com o exercício em si :

      scott@DESENV:SQL>@print_query "select * from user_mviews"
      OWNER                         : SCOTT
      MVIEW_NAME                    : MV_DEPT
      CONTAINER_NAME                : MV_DEPT
      QUERY                         : select ROWID as DEPT_ROWID, DEPTNO, DNAME FROM DEPT WHERE DEPTNO < 40
      QUERY_LEN                     : 72
      UPDATABLE                     : N
      UPDATE_LOG                    :
      MASTER_ROLLBACK_SEG           :
      MASTER_LINK                   :
      REWRITE_ENABLED               : N
      REWRITE_CAPABILITY            : GENERAL
      REFRESH_MODE                  : DEMAND
      REFRESH_METHOD                : FAST
      BUILD_MODE                    : IMMEDIATE
      FAST_REFRESHABLE              : DML
      LAST_REFRESH_TYPE             : COMPLETE
      LAST_REFRESH_DATE             : 13-out-2022 19:48:22
      STALENESS                     : NEEDS_COMPILE
      AFTER_FAST_REFRESH            : NEEDS_COMPILE
      UNKNOWN_PREBUILT              : N
      UNKNOWN_PLSQL_FUNC            : N
      UNKNOWN_EXTERNAL_TABLE        : N
      UNKNOWN_CONSIDER_FRESH        : N
      UNKNOWN_IMPORT                : N
      UNKNOWN_TRUSTED_FD            : N
      COMPILE_STATE                 : NEEDS_COMPILE
      USE_NO_INDEX                  : N
      
      <h2>STALE_SINCE                   :</h2>
      
      Procedimento PL/SQL concluído com sucesso.

      ==> agora vou INSERIR dados na tabela real :

      scott@DESENV:SQL>insert into DEPT VALUES (22, ‘DEPTO 22’, ‘X’);

      1 linha criada.

      scott@DESENV:SQL>commit;

      Commit concluído.

      ==> dados ESTÃO na tabela real :

      scott@DESENV:SQL>select * from dept order by deptno;
      
      

      DEPTNO DNAME LOC

      
      
      <hr />
      
      
      10 ACCOUNTING     NEW YORK
      20 RESEARCH       DALLAS
      22 DEPTO 22       X
      30 SALES          CHICAGO
      40 OPERATIONS     BOSTON
      42 dep 42
      43 dept43
      44 NOVO DEPT 44
      75 depto 75
      77 depto 77
      
      
      
      10 linhas selecionadas.
      
      => MV não foi refrescada :
      
      scott@DESENV:SQL>select * from MV_DEPT;
      
      DEPT_ROWID             DEPTNO DNAME
      
      <hr />
      
      AAAXmhAAhAAAjTwAAA         10 ACCOUNTING
      AAAXmhAAhAAAjTwAAB         20 RESEARCH
      AAAXmhAAhAAAjTwAAC         30 SALES

      ==> agora VOU fazer o REFRESH (poderia ser um JOB, mas vou fazer na mão, só pra exemplo) – o F é para FAST :

      scott@DESENV:SQL>exec DBMS_SNAPSHOT.REFRESH( ‘MV_DEPT’,’F’);

      Procedimento PL/SQL concluído com sucesso.

      scott@DESENV:SQL>select * from MV_DEPT;
      
      DEPT_ROWID             DEPTNO DNAME
      
      <hr />
      
      AAAXmhAAhAAAjTwAAA         10 ACCOUNTING
      AAAXmhAAhAAAjTwAAB         20 RESEARCH
      AAAXmhAAhAAAjTwAAC         30 SALES
      AAAXmhAAhAAAjTuAAD         22 DEPTO 22
      
      scott@DESENV:SQL>

      Tá certinho ??? Tenta repetir aí no seu database, se NEM ISSO vc conseguir, aí tá PROVADO que é alguma issue NO SEU BANCO…


      O refresh por commit está descartado, pois colocaram como justificativa que quando a transação está aberta pela aplicação ela só vai fechar após a atualização da view materializada, o que pode gerar um impacto que não se sabe mensurar. E eu também não tenho ideia disso.

      ==> Até é verdade que enquanto a MV com refresh ON-COMMIT está sendo refrescada a transação não encerra, mas (JUSTAMENTE por causa do FAST REFRESH!!!) isso deve representar SEGUNDOS a mais, nem isso…. COM CERTEZA eu Aconselho vc a TESTAR exatamente qual seria o overhead aí no SEU ambiente, NÃO SAIA DESCARTANDO opçoes só porque alguém Falou, queremos PROVAS, queremos um TESTE real, sim sim ??

      Veja lá…

      Abraços,

      José Laurindo Chiappa

      #158081
      Avatar photoJosé Laurindo Chiappa
      Moderador

        Eventualmente, se vc não tiver aí no seu database essa tabela de exemplo DEPT , cria ela assim para poder repetir meu exemplo :

        CREATE TABLE DEPT
        (DEPTNO NUMBER(2) CONSTRAINT PK_DEPT PRIMARY KEY,
        DNAME VARCHAR2(14) ,
        LOC VARCHAR2(13) ) ;

        INSERT INTO DEPT VALUES (10,’ACCOUNTING’,’NEW YORK’);
        INSERT INTO DEPT VALUES (20,’RESEARCH’,’DALLAS’);
        INSERT INTO DEPT VALUES (30,’SALES’,’CHICAGO’);
        INSERT INTO DEPT VALUES (40,’OPERATIONS’,’BOSTON’);

        e aí execute EXATAMENTE O MESMO que eu fiz, e então VEREMOS se é uma restrição GERAL do seu database/ambiente para views materializadas ou não, blz ? E TAMBÈM, seria muito MUITO bom vc instalar um SGBD ORACLE numa máquina local qualquer sua aí e fazer os MESMOS TESTES, em funcionando (como deve) isso comprovaria que é algo a ver ou com o cloud ou com o database aonde vc tá agora…

        Abraços,

        Chiappa

        #158093
        Anderson Ribeiro
        Participante

          Testei localmente num Oracle no docker e funcionou. Depois incluí uma junção com a tabela de empregados e também deu certo.

          Em relação ao problema real eu já sei do que se trata. A view está sendo criada com uma função para tratar um campo lob e o mesmo está sendo quebrado em outros 29, e isso está sendo feito em tempo de execução e não numa etapa anterior o qual já exista essa tabela.

          Para ficar mais claro, tempos uma junção dessa forma

          
          FROM TABELA1 T1
          INNER JOIN TABELA2 T2 ON TABELA2.COLUNA2 = T1.COLUNA1
          INNER JOIN TABLE (FUNCAO_TRATAR_CAMPOS( T2.CAMPO_REGISTRO_NOVO )) FUNC_NEW ON 0=0
          INNER JOIN TABLE (FUNCAO_TRATAR_CAMPOS( T2.CAMPO_REGISTRO_ANTIGO )) FUNC_OLD ON 0=0

          Como o Oracle informa, no erro ORA-12015: não pode criar uma view materializada de atualização rápida a partir de uma consulta complexa.

          Essa junção com função inviabiliza a criação da view como FAST ON DEMAND, mas permite outras opções.

          Então sugeri para a equipe que seja discutido as opções a seguir:

          1- Criar a view com FORCE DEMAND para que a mesma seja recriada por completo a cada doze horas, sendo atualizada por job. Nesse caso a view é criada com sucesso.

          2- Criar a view para ser REFRESH ON COMMIT. Aqui nem precisaria de job. Essa opção eu não testei, mas é bem provável que não dê erro na criação da view.

          3- Uma outra forma de não utilizar uma função na junção da criação da view, o que significa que teria que haver uma outra forma de quebrar o campo único em outros 29 campos em um passo anterior ao da criação da view materializada.

          Chiappa, obrigado pelo tempo despendido, sem dúvida aprendi coisas novas relacionadas a esse tópico.

          #158102
          Avatar photoJosé Laurindo Chiappa
          Moderador

            “Em relação ao problema real eu já sei do que se trata. A view está sendo criada com uma função para tratar um campo lob….”

            Pára TUDO aí, colega : eu tinha pedido JUSTAMENTE o DDL de tudo EXATAMENTE para ver se não tinha datatype não-escalar, E na sua resposta vc NÃO TINHA DITO nem MOSTRADO absolutamente NADA de Lob nem de qquer outro datatype não-escalar, E mostrou CREATE de tabela SIMPLES, sem view, sem trigger amarrada nelas… IGUALMENTE, vc NÃO TINHA MOSTRADo absolutamente NADA de função, NEM no DDL de criação de tabelas e NEM do DDL de criação da view materializada em si…. Se na verdade vc TINHA elementos complicadores do tipo, não teríamos como Adivinhar iosso, daí não termos nem Pensado em alternativas…

            “Testei localmente num Oracle no docker e funcionou. Depois incluí uma junção com a tabela de empregados e também deu certo.”

            ok, cria agora as tabelas DEPT e EMP NESSE BANCO EXTREME PERFORMANCE (que IMAGINO seja Cloud) onde vc relatou o erro, originalmente, e testa : SE FUNCIONAR OK nesse banco, TUDO que te falei em termos de BUG / disfuncionalidade do SGBD Oracle simplesmente CAI POR TERRA, e chegamos à conclusão que Realmente era erro seu,mesmo….

            Abraços,

            José Laurindo Chiappa

            #158104
            Anderson Ribeiro
            Participante

              É um projeto de empresa petrolífera, portanto não teria como eu mostrar nada.

              Aí fui tentando fazer num projeto pessoal, para depois implementar na empresa.

              #158105
              Avatar photoJosé Laurindo Chiappa
              Moderador

                Sim, o ponto é : quanto MENOS soubermos sobre os detalhes, MENOS vamos poder te ajudar…. Mas blz, se vc chegar no ponto em que um teste O MAIS SIMPLIFICADO possível FUNCIONE TANTO no seu banco pessoal de testes QUANTO no banco aonde a coisa REAL vai ser implementada, pronto : a funcionalidade Básica foi Comprovada OK, aí vc vai Sofisticando aos poucos cfrme preciso, ok ??

                Abraços,

                Chiappa

                #158107
                Motta
                Participante

                  Este tópico ficou muito bom , vou estudá-lo para a solução que fiz por tabela. Sites como este devem existir para melhorar as soluções.
                  !!!!

                  #158128
                  Avatar photoJosé Laurindo Chiappa
                  Moderador

                    Para Facilitar a quem quiser repetir (para fins de testes num SGBD ORACLE), seguem os DDLs (para encurtar, Omiti as mensagens de criação dos objetos e dos DMLs, mas TUDO foi OK, sem NENHUMA msg de erro) :

                    create table dept( deptno number(2,0), dname varchar2(14), loc varchar2(13), constraint pk_dept primary key (deptno) );
                    
                    create table emp( empno    number(4,0),
                                      ename    varchar2(10),
                                      job      varchar2(9),
                                      mgr      number(4,0),
                                      hiredate date,
                                      sal      number(7,2),
                                      comm     number(7,2),
                                      deptno   number(2,0),
                                      constraint pk_emp primary key (empno),
                                      constraint fk_deptno foreign key (deptno) references dept (deptno) );
                    
                    insert into dept values(10, 'ACCOUNTING', 'NEW YORK');
                    insert into dept values(20, 'RESEARCH', 'DALLAS');
                    insert into dept values(30, 'SALES', 'CHICAGO');
                    insert into dept values(40, 'OPERATIONS', 'BOSTON');
                    
                    insert into emp values(7839, 'KING',   'PRESIDENT', null , to_date('17-11-1981', 'dd-mm-yyyy'),5000, null, 10);
                    insert into emp values(7698, 'BLAKE',  'MANAGER',    7839, to_date('01-05-1981', 'dd-mm-yyyy'),2850, null, 30);
                    insert into emp values(7782, 'CLARK',  'MANAGER',    7839, to_date('09-06-1981', 'dd-mm-yyyy'),2450, null, 10);
                    insert into emp values(7566, 'JONES',  'MANAGER',    7839, to_date('02-04-1981', 'dd-mm-yyyy'),2975, null, 20);
                    insert into emp values(7788, 'SCOTT',  'ANALYST',    7566, to_date('13-07-1987', 'dd-mm-yyyy'),3000, null, 20);
                    insert into emp values(7902, 'FORD',   'ANALYST',    7566, to_date('03-12-1981', 'dd-mm-yyyy'),3000, null, 20);
                    insert into emp values(7369, 'SMITH',  'CLERK',     7902,  to_date('17-12-1980', 'dd-mm-yyyy'),800,  null, 20);
                    insert into emp values(7499, 'ALLEN',  'SALESMAN',  7698,  to_date('20-02-1981', 'dd-mm-yyyy'),1600,  300, 30);
                    insert into emp values(7521, 'WARD',   'SALESMAN',  7698,  to_date('22-02-1981', 'dd-mm-yyyy'),1250,  500, 30);
                    insert into emp values(7654, 'MARTIN', 'SALESMAN',  7698,  to_date('28-09-1981', 'dd-mm-yyyy'),1250, 1400, 30);
                    insert into emp values(7844, 'TURNER', 'SALESMAN',  7698,  to_date('08-09-1981', 'dd-mm-yyyy'),1500,    0, 30);
                    insert into emp values(7876, 'ADAMS',  'CLERK',     7788,  to_date('13-07-1987', 'dd-mm-yyyy'),1100, null, 20);
                    insert into emp values(7900, 'JAMES',  'CLERK',     7698,  to_date('03-12-1981', 'dd-mm-yyyy'),950,  null, 30);
                    insert into emp values(7934, 'MILLER', 'CLERK',     7782,  to_date('23-1-1982',  'dd-mm-yyyy'),1300, null, 10);
                    
                    create materialized view log  on DEPT with rowid, primary key;
                    create materialized view log  on EMP  with rowid, primary key;
                    

                    ==> crio um view materializada com uma query Não-Complexa (ie, SEM GROUP BY, SEM inline views, SEM sub-queries, SEM CTE/WITH CLAUSE, SEM chamada à funções, etc, etc) :

                    create materialized view MV_DEPT_EMP BUILD IMMEDIATE REFRESH FAST ON DEMAND
                     AS
                     select D.ROWID as DEPT_ROWID, D.DEPTNO, D.DNAME, E.ROWID as EMP_ROWID, E.EMPNO, E.ENAME, E.SAL
                      from DEPT D JOIN EMP E ON (D.DEPTNO = E.DEPTNO)
                     where D.DEPTNO < 40 AND E.SAL > 1000;
                    

                    ==> mostrando que a MV ** foi ** criada com os dados atuais (cláusula BUILD IMMEDIATE) :

                    select * from MV_DEPT_EMP order by deptno, empno
                    
                    DEPT_ROWID             DEPTNO DNAME          EMP_ROWID               EMPNO ENAME             SAL
                    ------------------ ---------- -------------- ------------------ ---------- ---------- ----------
                    AAAStyAABAAAIt5AAA         10 ACCOUNTING     AAASt0AABAAAIuJAAC       7782 CLARK            2450
                    AAAStyAABAAAIt5AAA         10 ACCOUNTING     AAASt0AABAAAIuJAAA       7839 KING             5000
                    AAAStyAABAAAIt5AAA         10 ACCOUNTING     AAASt0AABAAAIuJAAN       7934 MILLER           1300
                    AAAStyAABAAAIt5AAB         20 RESEARCH       AAASt0AABAAAIuJAAD       7566 JONES            2975
                    AAAStyAABAAAIt5AAB         20 RESEARCH       AAASt0AABAAAIuJAAE       7788 SCOTT            3000
                    AAAStyAABAAAIt5AAB         20 RESEARCH       AAASt0AABAAAIuJAAL       7876 ADAMS            1100
                    AAAStyAABAAAIt5AAB         20 RESEARCH       AAASt0AABAAAIuJAAF       7902 FORD             3000
                    AAAStyAABAAAIt5AAC         30 SALES          AAASt0AABAAAIuJAAH       7499 ALLEN            1600
                    AAAStyAABAAAIt5AAC         30 SALES          AAASt0AABAAAIuJAAI       7521 WARD             1250
                    AAAStyAABAAAIt5AAC         30 SALES          AAASt0AABAAAIuJAAJ       7654 MARTIN           1250
                    AAAStyAABAAAIt5AAC         30 SALES          AAASt0AABAAAIuJAAB       7698 BLAKE            2850
                    AAAStyAABAAAIt5AAC         30 SALES          AAASt0AABAAAIuJAAK       7844 TURNER           1500
                    
                    12 linhas selecionadas. 
                    

                    ==> insiro uma linha na tabela DEPT :

                    insert into DEPT VALUES (22, 'DEPTO 22', 'X');
                    commit;

                    ==> faço um REFRESH :

                    exec DBMS_SNAPSHOT.REFRESH( 'MV_DEPT_EMP','F');

                    ==> NOTAR que , já que é um EQUI-JOIn e NÂO um OUTER JOIN, como NÂO há empregado para o depto 22, a view materializada Não trará dados para esse depto :

                    select * from MV_DEPT_EMP order by deptno, empno
                    
                    DEPT_ROWID             DEPTNO DNAME          EMP_ROWID               EMPNO ENAME             SAL
                    ------------------ ---------- -------------- ------------------ ---------- ---------- ----------
                    AAAStyAABAAAIt5AAA         10 ACCOUNTING     AAASt0AABAAAIuJAAC       7782 CLARK            2450
                    AAAStyAABAAAIt5AAA         10 ACCOUNTING     AAASt0AABAAAIuJAAA       7839 KING             5000
                    AAAStyAABAAAIt5AAA         10 ACCOUNTING     AAASt0AABAAAIuJAAN       7934 MILLER           1300
                    AAAStyAABAAAIt5AAB         20 RESEARCH       AAASt0AABAAAIuJAAD       7566 JONES            2975
                    AAAStyAABAAAIt5AAB         20 RESEARCH       AAASt0AABAAAIuJAAE       7788 SCOTT            3000
                    AAAStyAABAAAIt5AAB         20 RESEARCH       AAASt0AABAAAIuJAAL       7876 ADAMS            1100
                    AAAStyAABAAAIt5AAB         20 RESEARCH       AAASt0AABAAAIuJAAF       7902 FORD             3000
                    AAAStyAABAAAIt5AAC         30 SALES          AAASt0AABAAAIuJAAH       7499 ALLEN            1600
                    AAAStyAABAAAIt5AAC         30 SALES          AAASt0AABAAAIuJAAI       7521 WARD             1250
                    AAAStyAABAAAIt5AAC         30 SALES          AAASt0AABAAAIuJAAJ       7654 MARTIN           1250
                    AAAStyAABAAAIt5AAC         30 SALES          AAASt0AABAAAIuJAAB       7698 BLAKE            2850
                    AAAStyAABAAAIt5AAC         30 SALES          AAASt0AABAAAIuJAAK       7844 TURNER           1500
                    
                    12 linhas selecionadas. 

                    ==> agora insiro uma linha correspondente na EMP, e faço refresh, a MV ** VAI ** re-executar a Query, VAI validar pelos MV LOGs quais foram os dados que Mudaram, E (agora sim, já que HÁ as condições exigidas no JOIN) VAI trazer os novos dados :

                    insert into emp values(8888, 'CHIAPPA',   'DBA', null , to_date('17-11-2022', 'dd-mm-yyyy'),11000, null, 22);
                    commit;
                    exec DBMS_SNAPSHOT.REFRESH( 'MV_DEPT_EMP','F');
                    
                    DEPT_ROWID             DEPTNO DNAME          EMP_ROWID               EMPNO ENAME             SAL
                    ------------------ ---------- -------------- ------------------ ---------- ---------- ----------
                    AAAStyAABAAAIt5AAA         10 ACCOUNTING     AAASt0AABAAAIuJAAC       7782 CLARK            2450
                    AAAStyAABAAAIt5AAA         10 ACCOUNTING     AAASt0AABAAAIuJAAA       7839 KING             5000
                    AAAStyAABAAAIt5AAA         10 ACCOUNTING     AAASt0AABAAAIuJAAN       7934 MILLER           1300
                    AAAStyAABAAAIt5AAB         20 RESEARCH       AAASt0AABAAAIuJAAD       7566 JONES            2975
                    AAAStyAABAAAIt5AAB         20 RESEARCH       AAASt0AABAAAIuJAAE       7788 SCOTT            3000
                    AAAStyAABAAAIt5AAB         20 RESEARCH       AAASt0AABAAAIuJAAL       7876 ADAMS            1100
                    AAAStyAABAAAIt5AAB         20 RESEARCH       AAASt0AABAAAIuJAAF       7902 FORD             3000
                    AAAStyAABAAAIt5AAE         22 DEPTO 22       AAASt0AABAAAIuJAAO       8888 CHIAPPA         11000
                    AAAStyAABAAAIt5AAC         30 SALES          AAASt0AABAAAIuJAAH       7499 ALLEN            1600
                    AAAStyAABAAAIt5AAC         30 SALES          AAASt0AABAAAIuJAAI       7521 WARD             1250
                    AAAStyAABAAAIt5AAC         30 SALES          AAASt0AABAAAIuJAAJ       7654 MARTIN           1250
                    AAAStyAABAAAIt5AAC         30 SALES          AAASt0AABAAAIuJAAB       7698 BLAKE            2850
                    AAAStyAABAAAIt5AAC         30 SALES          AAASt0AABAAAIuJAAK       7844 TURNER           1500
                    
                    13 linhas selecionadas. 

                    ==> última demonstração, vou alterar o mecanismo de REFRESH de ON DEMAND para ON COMMIT. mas AINDA MANTENDO REFRESH INCREMENTAL (FAST REFRESH) :

                    alter materialized view MV_DEPT_EMP REFRESH FAST ON COMMIT;
                    insert into emp values(9999, 'JLC',  'PL/SQL', null , to_date('17-11-2022', 'dd-mm-yyyy'),11000, null, 22);
                    commit;
                    SELECT * FROM MV_DEPT_EMP ORDER BY DEPTNO, EMPNO;
                    
                    DEPT_ROWID             DEPTNO DNAME          EMP_ROWID               EMPNO ENAME             SAL
                    ------------------ ---------- -------------- ------------------ ---------- ---------- ----------
                    AAAStyAABAAAIt5AAA         10 ACCOUNTING     AAASt0AABAAAIuJAAC       7782 CLARK            2450
                    AAAStyAABAAAIt5AAA         10 ACCOUNTING     AAASt0AABAAAIuJAAA       7839 KING             5000
                    AAAStyAABAAAIt5AAA         10 ACCOUNTING     AAASt0AABAAAIuJAAN       7934 MILLER           1300
                    AAAStyAABAAAIt5AAB         20 RESEARCH       AAASt0AABAAAIuJAAD       7566 JONES            2975
                    AAAStyAABAAAIt5AAB         20 RESEARCH       AAASt0AABAAAIuJAAE       7788 SCOTT            3000
                    AAAStyAABAAAIt5AAB         20 RESEARCH       AAASt0AABAAAIuJAAL       7876 ADAMS            1100
                    AAAStyAABAAAIt5AAB         20 RESEARCH       AAASt0AABAAAIuJAAF       7902 FORD             3000
                    AAAStyAABAAAIt5AAE         22 DEPTO 22       AAASt0AABAAAIuJAAO       8888 CHIAPPA         11000
                    AAAStyAABAAAIt5AAE         22 DEPTO 22       AAASt0AABAAAIuJAAP       9999 JLC             11000
                    AAAStyAABAAAIt5AAC         30 SALES          AAASt0AABAAAIuJAAH       7499 ALLEN            1600
                    AAAStyAABAAAIt5AAC         30 SALES          AAASt0AABAAAIuJAAI       7521 WARD             1250
                    AAAStyAABAAAIt5AAC         30 SALES          AAASt0AABAAAIuJAAJ       7654 MARTIN           1250
                    AAAStyAABAAAIt5AAC         30 SALES          AAASt0AABAAAIuJAAB       7698 BLAKE            2850
                    AAAStyAABAAAIt5AAC         30 SALES          AAASt0AABAAAIuJAAK       7844 TURNER           1500
                    
                    14 linhas selecionadas. 

                    ===>> DEPOIS que os testes O MAIS SIMPLES POSSÌVEL funcionaram OK, aí para poder TESTAR A PERFORMANCE e validar a Aplicabilidade do recurso num ambiente Produtivo (principalmente no caso de REFRESH FAST ON COMMIT, que via de regra É a opção Recomendada, já que apresenta ZERO chance de dados desatualizados), é ir Sofisticando, inserindo (num LOOP, provavelmente) mais e mais linhas, ir aumentando o número de JOINs, adicionando novas features na query cfrme necessário (SEMPRE DE OLHO nos Manuais Oracle, para ver o que é PERMITIDO ou não para CADA tipo de query em cada opção de REFRESH na MV), assim por diante…

                    Abraços,

                    José Laurindo Chiappa

                  Visualizando 8 posts - 16 até 23 (de 23 do total)
                  • Você deve fazer login para responder a este tópico.
                  plugins premium WordPress