Paulo, manda os CREATE TABLEs e uns tantos INSERTs para popular : eu ** acho
** que talvez vc possa estar com NULL ou com espaços em branco nalguma coluna,
ou tá rolando alguma conversão implícita Vc mandando isso a gente tenta
reproduzir por aqui...
[]s
Chiappa
--- Em oracle_br@yah
Nao sei qual a necessidade, mas será que isso nao viola a segurança não?
sei lá, uma triger executando um grant...
2013/4/25 Andre Santos
> Marcelo
>
> Seria melhor tentar implementar isso fora de um trigger (talvez uma
> procedure).
> Mesmo se utilizar o "execute immediate", o GRANT teria um
Marcelo
Seria melhor tentar implementar isso fora de um trigger (talvez uma
procedure).
Mesmo se utilizar o "execute immediate", o GRANT teria um commit implícito,
o que não é permitido num trigger comum.
Se você puder explicar o contexto da necessidade, talvez o pessoal aqui do
grupo possa ajuda
Boa tarde.
Sim, são tabelas.
Att,
Paulo
-Mensagem original-
De: oracle_br@yahoogrupos.com.br [mailto:oracle_br@yahoogrupos.com.br] Em
nome de Andre Santos
Enviada em: quinta-feira, 25 de abril de 2013 13:48
Para: oracle_br@yahoogrupos.com.br
Assunto: Re: [oracle_br] Problema com query
Paulo
São tabelas mesmo, ou são views?
[ ]
André
Em 25 de abril de 2013 09:41, Paulo escreveu:
> **
>
>
> Bom dia.
>
> Opa, realmente ficou confuso mesmo, pois o yahoo retirou a formatação que
> criei no e-mail.
> Sim já testei como você mencionou, foi a primeira coisa que fiz quando
> iden
Bem, realmente pode ser qualquer problema de espaço em disco/diretório não
criado (nome não deve ser, já que afaik em outra msg o colega já falou que na
máquina-destino ele tem o diskgroup +DATA já criado), mas eu penso mesmo em
arquivos de backup restaurados da fita pra um diretório diferente
José Antonio,
Veja um exemplo do meu PFILE, que tem a conversão de caminhos do ASM, onde
DATA11, 12, 13, 14 e 15 eram do servidor origem do backup. Na máquina de
restore, eu tenho somente o diskgroup DATA2.
*.db_file_name_convert = ('+DATA11', '+DATA2',
'+DATA12', '+
A única diferença José Mario, é que um ambiente é RAC e o outro ambiente
não é RAC, em ambos os ambientes dados estão armazenados e gerenciados por
uma instância ASM (+DATA/) que seguem exatamente a mesma estrutura. Eu acho
que está faltando apontar para o RMAN para o diretório onde armazenado o
BA
José Antonio
Provavelmente está faltando agora a conversão dos caminhos dos datafiles.
Você está saindo de um RAC provavelmente para uma base single certo?
Provavelmente você não tenha um +DATA para seus datafiles e suim um
/u01/oradata.
Procure por db_file_name_convert e log_file_name_convert.
Bom Dia Ederson.
As dicas que você passou são perfeitas, estou seguindo elas em parceria com
o blog do Bruno Murassaki (
http://profissionaloracle.com.br/blogs/brunomurassaki/2009/08/15/rman-recuperando-um-banco-de-dados-inteiro/),
só travei na hora de fazer o restore database que deu esse erro:
Bom dia José Antonio,
Beleza, com os detalhes adicionais ficou mais claro, mas ainda falta alguns
pontos do check que precisamos fazer.
-Vc tem uma máquina de produção e está passando o backup de uma instância para
esta máquina que já contém outra instância, confere?
-Nesta máquina que receberá
Bom dia.
Opa, realmente ficou confuso mesmo, pois o yahoo retirou a formatação que
criei no e-mail.
Sim já testei como você mencionou, foi a primeira coisa que fiz quando
identifiquei algo estranho.
É um lance muito estranho, porque se selecionar registros de 15 de
dezembro/2012 a até hoje, func
Está um pouquinho confuso seu e-mail... mas tente isso:
Select *
from titulos T, fornecedor F
where T.fornecedor_codi = F.codi
and T.fornecedor_loja = F.loja;
2013/4/25 Listas
> **
>
>
>
>
> Boa tarde.
>
> Estou com um problema e gostaria da opinião dos amigos do grupo.
>
> Tenho um select
13 matches
Mail list logo
