O teu select possui aspas duplas no início do nome do objeto e não possui no
final, portanto não é válido. Executa de novo apenas com as aspas simples:
Errado:
SQL> select * from dba_objects where OBJECT_NAME='"MV_TAB_SAP_ALIMENTADOR';
no rows selected
SQL>
Certo:
SQL> select * fr
Bom, primeiro reporte-se que ABSOLUTAMENTE não faz sentido esse :
select * from dba_objects where OBJECT_NAME='"MV_TAB_SAP_ALIMENTADOR';
DEVERIA ser :
select * from dba_objects where OBJECT_NAME='MV_TAB_SAP_ALIMENTADOR';
aspas SIMPLES apenas, okdoc ?? Sempre, sempre, A NÃO SER que vc tenha
c
Não existe nenhum objeto com o nome da view.
SQL> select * from dba_objects where OBJECT_NAME='"MV_TAB_SAP_ALIMENTADOR';
no rows selected
SQL>
Atenciosamente,
Rogério Camatini.
Em 23 de outubro de 2013 18:28, Vitor Junior escreveu:
> **
>
>
> Ja existe uma tabela com o nome da mview que
Ja existe uma tabela com o nome da mview que tu tá tentando criar?
Em 23/10/2013 18:26, "Roger Camatini" escreveu:
> **
>
>
> Galera boa noite,
>
> Estou tentando criar uma view materializada mas recebo o erro abaixo:
>
> OR (carac.DT_DESATIVACAO= ' ' )
>
Galera boa noite,
Estou tentando criar uma view materializada mas recebo o erro abaixo:
OR (carac.DT_DESATIVACAO= ' ' )
*
ERROR at line 32:
ORA-00955: name is already used by an existing object
Alguem poderia me dar uma direção de onde começar pra resolv
Juliano,
Só para complementar o que o Chiappa informou, sugiro a leitura do
artigo:
http://www.fabioprado.net/2012/07/performance-de-tablespaces-separados.html
[]s
Fábio Prado
Em 23 de outubro de 2013 16:42, J. Laurindo Chiappa
escreveu:
> **
>
>
> SE essas tablespaces forem criadas nos me
SE essas tablespaces forem criadas nos mesmos discos de hoje, atendidos pelo
mesmo exato hardware que não está dando conta e fazendo os mesmos exatos I/Os
na mesma quantidade, É Claro que não dar diferença alguma de performance, isso
é Acadêmico... As tablespaces são um instrumento muito mais de
Obrigado pela resposta, Chiappa.
Vou ler a nota do Metalink e aumentar meu conhecimento nessa questão de Waits
devido I/O.
Foi possível monitorar, que essa queda na performance e registro dos Warnings
no arquivo de trace, tem ocorrido somente quando dois processos do ERP são
executados de form
Apenas separei os comandos em BEGIN ... END, deixando no bloco anonimo apenas o
laço para o update...
Em Terça-feira, 22 de Outubro de 2013 13:59, Fernando Martins
escreveu:
Sim, os comandos parecem corretos, acredito que o issue deve realmente ser no
nome das tabelas como o pessoal j
Obrigado chiappa, ainda estou tentando construir essa consulta. O seu exemplo é
bom, apesar de usar a user_constraints e selecionar a descendência. Estou
analisando ela para ver se a adpto à ascendência...
Em Terça-feira, 22 de Outubro de 2013 17:51, J. Laurindo Chiappa
escreveu:
Sorry
Colega, eu ainda não caí nisso nos 11.2.0.3.x que tenho, mas seguinte - a
primeira coisa que se pergunta é : vc abriu o chamado, ok, mas abriu
ADEQUADAMENTE, ie : vc IDENTIFICOU o SQL que estava executando na ocasião e
provavelmente provocou o erro ? Vc TENTOU REPRODUZIR a execução dele no seu
Já tentou no site da Editora Alta books...
O meu eu comprei lá...
Muito bom o Livro
Att.,
Sidnei Moreira
--- Em oracle_br@yahoogrupos.com.br, Josimar Gomes escreveu
>
> Alguém possui esse livro em português?
>
> Att,
>
> Josimar Gomes
>
Bem, essa feature de avisar se um I/O de tamanho determinado demora mais de
500 ms foi introduzida iirc no 10.2.0.4 , e não me lembro de bug/correção para
alguma issue com ela no 10.2.0.5 : dá um look no README do 10.2.0.5 para
confirmar, E considere muito cuidadosamente a possibilidade de apl
Pessoal,
Minha base de dados de produção tem apresentado desde o último dia 14/10/2013
as seguintes mensagens de trace no arquivo producao_lgwr_708.TRC. Com uma média
de 3 mensagens por hora.
Maximum redo generation record size = 156160 bytes
Maximum redo generation change vector size = 150676
14 matches
Mail list logo
