Marcado: view materializada job
- Este tópico contém 22 respostas, 3 vozes e foi atualizado pela última vez 2 anos, 2 meses atrás por José Laurindo Chiappa.
-
AutorPosts
-
13 de outubro de 2022 às 7:20 pm #158068José Laurindo ChiappaModerador
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
14 de outubro de 2022 às 8:27 am #158081José Laurindo ChiappaModeradorEventualmente, 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
14 de outubro de 2022 às 2:21 pm #158093Anderson RibeiroParticipanteTestei 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.
15 de outubro de 2022 às 4:35 pm #158102José Laurindo ChiappaModerador“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
15 de outubro de 2022 às 4:58 pm #158104Anderson RibeiroParticipanteÉ 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.
15 de outubro de 2022 às 5:06 pm #158105José Laurindo ChiappaModeradorSim, 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
15 de outubro de 2022 às 5:28 pm #158107MottaParticipanteEste 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.
!!!!15 de outubro de 2022 às 7:14 pm #158128José Laurindo ChiappaModeradorPara 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
-
AutorPosts
- Você deve fazer login para responder a este tópico.