Re: [oracle_br] Re: ORA-32004
Segue resultado da query. SQL SELECT INST_ID, KSPPONM 2 FROM X$KSPPO 3 WHERE KSPPOVAL 0 4 AND KSPPOFLG = 1; no rows selected - Original Message - From: Carlos E. Gorges To: oracle_br@yahoogrupos.com.br Sent: Tuesday, February 03, 2009 6:09 PM Subject: Re: [oracle_br] Re: ORA-32004 Boa tarde, Nenhum desses parâmetros é depreciado no 10g, o warning está ocorrendo por outro parâmetro. Olhe o alert log ou a query : SELECT INST_ID, KSPPONM, FROM X$KSPPO WHERE KSPPOVAL 0 -- modificado ? AND KSPPOFLG = 1 -- deprecated/obsolete cya[]; Carlos E. Gorges carlos.gor...@gmail.com 2009/2/3 Ricardo Portilho Proni rportilhopr...@yahoo.com.br: Coloque o que tem no alert log na hora do startup aqui para gente ver. Ricardo Portilho Proni Coordenador / Bancos de Dados SAP Basis - Solvo S/A --- Em ter, 3/2/09, joeycfx joey...@yahoo.com.br escreveu: De: joeycfx joey...@yahoo.com.br Assunto: [oracle_br] Re: ORA-32004 Para: oracle_br@yahoogrupos.com.br Data: Terça-feira, 3 de Fevereiro de 2009, 12:01 João, O parametro é o optimizer_mode. No oracle 10g o CBO é habilitado por padrão. Existe um novo parâmetro que trata de estatísticas que e influencia no otimizador, que é o statistics_level. []'s Joaquim --- Em oracle...@yahoogrup os.com.br, João Paulo jpvel...@.. . escreveu Ricardo bom dia, São esses os parametros alterados. log_archive_ dest_1 open_cursors job_queue_processes processes sessions optimizer_mode Será que pode ser algum desses? - Original Message - From: Ricardo Portilho Proni To: oracle...@yahoogrup os.com.br Sent: Tuesday, February 03, 2009 11:43 AM Subject: Re: [oracle_br] ORA-32004 Oi João. No alert log desta instância deve ter qual o parâmetro que causou este erro. Ou tente lembrar qual foi. :-) Se você usa SPFILE, o que é o mais comum hoje em dia, terá que fazer um pfile sem este parâmetro antigo. No 11g, este tipo de situação foi minimizada, o Oracle não permite parâmetros inválidos, também se o SCOPE é SPFILE. Ricardo Portilho Proni Coordenador / Bancos de Dados SAP Basis - Solvo S/A --- Em ter, 3/2/09, João Paulo jpvel...@.. . escreveu: De: João Paulo jpvel...@.. . Assunto: [oracle_br] ORA-32004 Para: oracle...@yahoogrup os.com.br Data: Terça-feira, 3 de Fevereiro de 2009, 10:34 Bom dia pessoal, Gostaria de mais uma ajuda. Ao fazer o startup do banco aparece a seguinte mensagem abaixo, mas o banco sobre normalmente. SQL startup mount ORA-32004: obsolete and/or deprecated parameter(s) specified O que poderia causar isso? Grato, João Paulo [As partes desta mensagem que não continham texto foram removidas] Veja quais são os assuntos do momento no Yahoo! +Buscados http://br.maisbusca dos.yahoo. com [As partes desta mensagem que não continham texto foram removidas] [As partes desta mensagem que não continham texto foram removidas] Veja quais são os assuntos do momento no Yahoo! +Buscados http://br.maisbuscados.yahoo.com [As partes desta mensagem que não continham texto foram removidas] [As partes desta mensagem que não continham texto foram removidas]
Re: [oracle_br] RMAN no RAC
Ricardo, Sei que pode, é que no meu caso particular os servidores estão em um datacenter, onde a infra de backup robotizada é gerenciada pelo datacenter, com um agente nos servidores que só encherga arquivos regulares no file system, o backup é feito por uma interface de rede dedicada, não existem unidades físicas de fita nos servidores. Alexandre, Fiz isso na criação do BD, mas acho que um exemplo seria: 1- Supondo que você tem um DG que se chama FRA e que o tamanho disponível seja 7500MB; 2- Configure o destino com: ALTER SYSTEM SET db_recovery_file_dest = +FRA SCOPE=BOTH SID='*'; 3- Ajuste o tamanho com: ALTER SYSTEM SET db_recovery_file_dest_size = 786432 SCOPE=BOTH SID='*'; 4- Direcione os archivedlogs para o FRA com: ALTER SYSTEM SET log_archive_dest_1='LOCATION=USE_DB_RECOVERY_FILE_DEST'; Acho que é só isso. Att, Carlos Alfredo Ricardo Portilho Proni escreveu: E o RMAN não pode gravar direto para a fita (allocate chanel device type tape...)? Qual é seu software de backup? Ricardo Portilho Proni Coordenador / Bancos de Dados SAP Basis - Solvo S/A --- Em ter, 3/2/09, Carlos Alfredo M. de Menezes carlos.mene...@usinacoruripe.com.br mailto:carlos.menezes%40usinacoruripe.com.br escreveu: De: Carlos Alfredo M. de Menezes carlos.mene...@usinacoruripe.com.br mailto:carlos.menezes%40usinacoruripe.com.br Assunto: Re: [oracle_br] RMAN no RAC Para: oracle_br@yahoogrupos.com.br mailto:oracle_br%40yahoogrupos.com.br Data: Terça-feira, 3 de Fevereiro de 2009, 19:38 Colega, Eu uso tudo compartilhado usando ASM, no caso eu tenho um DG para os LOG´s e um outro que uso como minha Flash Recover Area, onde coloco os arqchived logs. A minha desvantagem é que meu software de backup não reconhece volumes do ASM, logo tenho que usar o RMAN para copiar os arquivos do ASM para o file system, para só depois copiar para fitas. Att, Carlos Alfredo Alexandre Anselmo escreveu: Ae pessoal vou seguindo com minhas duvidas no RAC... Alguem tem um turorial legal para montar uma estrategia de backup/restore com RMAN no RAC. Estou com um livro que fala da geração dos archives para o disco local de cada nó e fazer um cruzamento via NFS (NAO GOSTEI DISSO!). Qual a melhor solução? Archive para o Shared Disk, disco local? Se alguem tiver algum exemplo ajudaria muito. Ats, Alexandre Tenorio. Veja quais são os assuntos do momento no Yahoo! +Buscados http://br.maisbuscados.yahoo.com http://br.maisbuscados.yahoo.com [As partes desta mensagem que não continham texto foram removidas]
[oracle_br] Criar external table sem log
Eai pessoal,
Estou com um pequeno problema e talvez alguem ja tenha a solução. Tenho uma
external table que carrega os dados de um arquivo texto para dentro de uma
tabela oracle, porém toda vez que é feito um select nessa external table um
arquivo de LOG é criado.
Eu queria impedir a criacao desse log, tem como?
O comando para criar a external table é esse:
create table ext_table_teste18117 (
cod_linha Varchar2(70),
cod_empresa varchar2(70),
cod_emp Varchar2(70),
cod_ben Varchar2(70),
cod_dep Varchar2(70),
nro_titulo Varchar2(70),
mensagem1 Varchar2(70),
mensagem2 Varchar2(70),
mensagem3 Varchar2(70),
mensagem4 Varchar2(70),
mensagem5 Varchar2(70)
)
organization external (
type oracle_loader
default directory dir_boleto
access parameters (
records delimited by '|'
fields terminated by ';'
missing field values are null
)
location ('CPEREIRA18117.Rem')
)
reject limit Unlimited;
Tentei adicionar dentro da clausula acess_parameters:
NOBADFILE
NODISCARDFILE
NOLOGFILE
Mas dá erro, alguem poderia me ajudar?
Abraço
--
José Eduardo Batista Juliano
Cel (16)9189-2486
Híade Informática
Consultoria Oracle e desenvolvimento de sistemas.
Ribeirão Preto - SP
[As partes desta mensagem que não continham texto foram removidas]
Re: [oracle_br] RMAN no RAC
Alexandre, A regra para localização dos Archives em ambiente RAC é a mesma usada para a Flash Recovery Area, isto é: 1) Utilizar ASM; 2) Cluster File System (ocfs ou outro disponível no teu Sistema Operacional); 3) E por último o NFS; Tu terás dificuldades em colocar em uma área não compartilhada é na necessidade de recovery, onde, se for assim, tu deverás copiar manualmente os archives para o nó onde o recovery está sendo executado. Sucesso, Anderson Haertel Rodrigues Consultor Oracle TEIKO Soluções em Tecnologia da Informação Blumenau/SC (47) - 3035 3777 - (47) 9178 0170 www.teiko.com.br --- Em qua, 4/2/09, Carlos Alfredo M. de Menezes carlos.mene...@usinacoruripe.com.br escreveu: De: Carlos Alfredo M. de Menezes carlos.mene...@usinacoruripe.com.br Assunto: Re: [oracle_br] RMAN no RAC Para: oracle_br@yahoogrupos.com.br Data: Quarta-feira, 4 de Fevereiro de 2009, 10:26 Ricardo, Sei que pode, é que no meu caso particular os servidores estão em um datacenter, onde a infra de backup robotizada é gerenciada pelo datacenter, com um agente nos servidores que só encherga arquivos regulares no file system, o backup é feito por uma interface de rede dedicada, não existem unidades físicas de fita nos servidores. Alexandre, Fiz isso na criação do BD, mas acho que um exemplo seria: 1- Supondo que você tem um DG que se chama FRA e que o tamanho disponível seja 7500MB; 2- Configure o destino com: ALTER SYSTEM SET db_recovery_file_dest = +FRA SCOPE=BOTH SID='*'; 3- Ajuste o tamanho com: ALTER SYSTEM SET db_recovery_file_dest_size = 786432 SCOPE=BOTH SID='*'; 4- Direcione os archivedlogs para o FRA com: ALTER SYSTEM SET log_archive_dest_1='LOCATION=USE_DB_RECOVERY_FILE_DEST'; Acho que é só isso. Att, Carlos Alfredo Ricardo Portilho Proni escreveu: E o RMAN não pode gravar direto para a fita (allocate chanel device type tape...)? Qual é seu software de backup? Ricardo Portilho Proni Coordenador / Bancos de Dados SAP Basis - Solvo S/A --- Em ter, 3/2/09, Carlos Alfredo M. de Menezes carlos.mene...@usinacoruripe.com.br mailto:carlos.menezes%40usinacoruripe.com.br escreveu: De: Carlos Alfredo M. de Menezes carlos.mene...@usinacoruripe.com.br mailto:carlos.menezes%40usinacoruripe.com.br Assunto: Re: [oracle_br] RMAN no RAC Para: oracle_br@yahoogrupos.com.br mailto:oracle_br%40yahoogrupos.com.br Data: Terça-feira, 3 de Fevereiro de 2009, 19:38 Colega, Eu uso tudo compartilhado usando ASM, no caso eu tenho um DG para os LOG´s e um outro que uso como minha Flash Recover Area, onde coloco os arqchived logs. A minha desvantagem é que meu software de backup não reconhece volumes do ASM, logo tenho que usar o RMAN para copiar os arquivos do ASM para o file system, para só depois copiar para fitas. Att, Carlos Alfredo Alexandre Anselmo escreveu: Ae pessoal vou seguindo com minhas duvidas no RAC... Alguem tem um turorial legal para montar uma estrategia de backup/restore com RMAN no RAC. Estou com um livro que fala da geração dos archives para o disco local de cada nó e fazer um cruzamento via NFS (NAO GOSTEI DISSO!). Qual a melhor solução? Archive para o Shared Disk, disco local? Se alguem tiver algum exemplo ajudaria muito. Ats, Alexandre Tenorio. Veja quais são os assuntos do momento no Yahoo! +Buscados http://br.maisbuscados.yahoo.com http://br.maisbuscados.yahoo.com [As partes desta mensagem que não continham texto foram removidas] -- Atenção! As mensagens do grupo ORACLE_BR são de acesso público e de inteira responsabilidade de seus remetentes. Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/ -- Apostilas » Dicas e Exemplos » Função » Mundo Oracle » Package » Procedure » Scripts » Tutoriais - O GRUPO ORACLE_BR TEM SEU PROPRIO ESPAÇO! VISITE: http://www.oraclebr.com.br/ Links do Yahoo! Grupos Veja quais são os assuntos do momento no Yahoo! +Buscados http://br.maisbuscados.yahoo.com
Res: [oracle_br] Re: Recuperação de Tablespa ce em no logging
Obrigado Carlos Com relação aos dados não haverá problema, pois tenho como reiniciar a carga dos dados. O meu receio maior é quanto a recuperar o datafile dessa tablespace em no logging. Se o BD por exemplo, iria reconhecer um datafile de um cold backup anterior, mesmo com os datafiles das outras tablespaces, controlfile estarem numa nova versão. Fique com Deus. Um grande abraço. Att. Alexandre Brum De: Carlos E. Gorges carlos.gor...@gmail.com Para: oracle_br@yahoogrupos.com.br Enviadas: Terça-feira, 3 de Fevereiro de 2009 16:59:07 Assunto: Re: [oracle_br] Re: Recuperação de Tablespace em no logging Boa tarde, Depende do tipo de backup que você faz. Em um cold backup, termine o banco com immediate, não com abort (ou ao menos force um checkpoint e espere ele terminar)... o abort faz com que o banco execute o restore no startup e com nologging não há dados no redo para o restore. Em um hot backup (expdb/export, etc) não há problema, pois os blocos são lidos logicamente (datafiles, undo e buffer cache) e não fisicamente do disco, pegando as informações corretas via leitura consistente. Em um backup baseado em archive, você NÃO terá as informações dessas alterações, já que o archive é na verdade o redolog que encheu e com nologging as informações dos blocos de dados alterados não vão para o redolog... você conseguirá fazer o recover: os datafiles ficarão legiveis pelo oracle mas em nível de dados eles provavelmente ficarão inconsistentes, além da estrutura dos metadados e índices que ficarão incorretas de acordo com os dados da tabela. cya[]; Carlos E. Gorges carlos.gorges@ gmail.com 2009/2/3 alexandre_brum alexandre_brum@ yahoo.com. br: Carlos Sim. Sei que irei perder esses dados. Mas no caso do datafile dessa tablespace se corromper, como seria o processo de restore do backup a fim de que eu possa novamente ter essa tablespace disponível? Obrigado. Att. Alexandre Brum --- Em oracle...@yahoogrup os.com.br, Carlos E. Gorges carlos.gorges@ ... escreveu Boa tarde, O nologging irá desligar parte da geração do redolog, incluindo os blocos de dados alterados no DML. Como esses dados ficarão em memória até ser descarregados para os datafiles em um checkpoint e não estão em redo (disco), em caso de crash na máquina/banco os dados em memória (SGA-Buffer cache) serão perdidos e consequentemente esses blocos alterados também serão perdidos. O resultado será um segmento em uma versão (SCN) anterior ou parcial... Note que se algum datafile seja corrompido, por bug ou problema no subsistema de I/O por exemplo, o log não vai adiantar nada de qualquer modo... Em resumo: não há recuperação :-) cya[]; Carlos E. Gorges carlos.gorges@ ... 2009/2/3 Alexandre Brum alexandre_brum@ ...: Prezados Durante um processo de carga pretendo colocar a tablespace desse usuário da carga em no logging para agilizar a carga. Entretanto, tenho dúvidas de como seria a recuperação dessa tablespace, se por algum motivo, durante a carga, os datafiles dessa tablespace se corrompam. Como seria a recuperação dessa tablespace? Muito obrigado. Fique com Deus. Um grande abraço. Att. Alexandre Brum Veja quais são os assuntos do momento no Yahoo! +Buscados http://br.maisbuscados.yahoo.com [As partes desta mensagem que não continham texto foram removidas]
RE: [oracle_br] Vaga Absurda anunciada na APINFO
Olá pessoal, Concordo que não podemos julgar... Mas o empregador não está levando em consideração que este profissional deixará o serviço assim que tiver oportunidade! []'s Cláudio Moraes --- Em seg, 2/2/09, Flaviano, Wellington (GE Money) wellington.flavi...@ge.com escreveu: De: Flaviano, Wellington (GE Money) wellington.flavi...@ge.com Assunto: RE: [oracle_br] Vaga Absurda anunciada na APINFO Para: oracle_br@yahoogrupos.com.br Data: Segunda-feira, 2 de Fevereiro de 2009, 9:33 Foi o que eu havia mencionado, você não pode julgar quem aceita a vaga porque não sabe a real condição da pessoa. Imagina se tivesse uma familia para criar, filhos, esposa, contas e há 4 meses sem emprego e aparece uma oportunidade desta ... Você aceita sem pensar duas vezes porque ama seu filho, sua esposa e precisa dar de alimento para eles ... É triste mas isto acontece, e muito, e está sujeito a isto. Sinceramente espero que ninguem daqui passa por esta situação, mas na infelicidade de acontecer será o primeiro a aceitar. []'s -Original Message- From: oracle...@yahoogrup os.com.br [mailto:oracle...@yahoogrup os.com.br] On Behalf Of Mosan Santos Sent: segunda-feira, 2 de fevereiro de 2009 09:12 To: oracle...@yahoogrup os.com.br Subject: Re: [oracle_br] Vaga Absurda anunciada na APINFO Srs; Sempre, fui da opnião que esse tipo de empregador, só existe por tem gente que aceita. Isso é verdade, mas por que tem gente que aceita? Eu estava me disvinculando de um cliente que prestava serviço 20h por semana. O rh deles captou um recurso que trabalhará, no mês 40h por um sálario R$ 200,00 a menos que eu ganhava por semana. Este profissional sofreu vários quedas no último ano. Tinha uma consultoria estável, perdeu todos os clientes para o sócio. Para resumir... Estava morando numa vaga e a esposa com o filho foi morar com a mãe. Então é dificil julgar... Abraços Mosán Santos _ _ OCP DBA 10g OCE SQL OCE Managing Oracle on Linux OCA PL/SQL CCNA JNCIA -ER FCP Master FCP Fundamental OCM(2010) ...LOAD _ _ --- Em qui, 29/1/09, Marcelo Bittencourt mboi...@gmail. com escreveu: De: Marcelo Bittencourt mboi...@gmail. com Assunto: Re: [oracle_br] Vaga Absurda anunciada na APINFO Para: oracle...@yahoogrup os.com.br Data: Quinta-feira, 29 de Janeiro de 2009, 12:19 Mas, a culpa de ter salários nestes patamares é que tem gente que aceita... Saudações, 2009/1/29 Anderson Ferreira andfr2...@hotmail. com Nossa olha isso, tem empresas que são venha nós hein... DBA Oracle A RedeSPC, administradora da CheckOk Verificação Eletrônica de Crédito, necessita de profissional para atuar com Banco de Dados: Ter mais de dois anos de experiência comprovada como DBA Oracle. Experiência com otimização de Performance. Conhecimentos dos conceito de ciclo de vida da informação(incluindo extração, transformação e carregamento de dados) assim como também as atividades relacionadas com a Gestão de Dados e Data Base para assegurar a integração e a padronização das estruturas de dados. Compreender, definir e documentar as normas e conceitos. Desejável experiência em ambiente financeiro/telecomu nicações. CLT+ VT+ VA. Início Imediato. Faixa Salarial 1500,00. Horário Comercial. Empresa .: RedeSPC CheckOK Enviar curriculum para ...: Clique somente se for seu perfil Código ...: 72232 [As partes desta mensagem que não continham texto foram removidas] -- Marcelo Bittencourt de Oliveira 21-8349-6287 [As partes desta mensagem que não continham texto foram removidas] Veja quais são os assuntos do momento no Yahoo! +Buscados http://br.maisbusca dos.yahoo. com [As partes desta mensagem que não continham texto foram removidas] - - -- - - - - - - Atenção! As mensagens do grupo ORACLE_BR são de acesso público e de inteira responsabilidade de seus remetentes. Acesse: http://www.mail- archive.com/ oracle_br@ yahoogrupos. com.br/ - - - - - - Apostilas » Dicas e Exemplos » Função » Mundo Oracle » Package » Procedure » Scripts » Tutoriais - O GRUPO ORACLE_BR TEM SEU PROPRIO ESPAÇO! VISITE: http://www.oraclebr .com.br/ - - - - - - Links do Yahoo! Grupos Veja quais são os assuntos do momento no Yahoo! +Buscados http://br.maisbuscados.yahoo.com [As partes desta mensagem que não continham texto foram removidas]
[oracle_br] 04 Fevereiro 2009-ORA-00932: tipos de dados inconsistentes
Gostaria de ajuda Ao sair do sistema que utilizo ocorre esta msg de erro: ORA-00932: tipos de dados inconsistentes: esperava NUMBER obteve DATE Estou sem saber por onde começar Caso possa ajudar agradeço
RE: [oracle_br] 04 Fevereiro 2009-ORA-00932: tipos de dados inconsistentes
Vc tem que ver o que está sendo atualizado quando vc executa a função de 'sair do sistema'. From: oracle_br@yahoogrupos.com.br [mailto:oracle...@yahoogrupos.com.br] On Behalf Of luciangelacatizanecatizane Sent: quarta-feira, 4 de fevereiro de 2009 11:17 To: oracle_br@yahoogrupos.com.br Subject: [oracle_br] 04 Fevereiro 2009-ORA-00932: tipos de dados inconsistentes Gostaria de ajuda Ao sair do sistema que utilizo ocorre esta msg de erro: ORA-00932: tipos de dados inconsistentes: esperava NUMBER obteve DATE Estou sem saber por onde começar Caso possa ajudar agradeço [As partes desta mensagem que não continham texto foram removidas]
[oracle_br] Enterprise Manager
Senhores(as), Boa Tarde! Estou querendo migrar um sistema que esta em SQL Server para o ORACLE 10g, fiz a instalação em um notebook da HP com 4GB Memoria, 160 de HD com o Windows Vista Enterprise com o SP1, porem ao final da criação de um Banco de Dados não é mostrada a URL de acesso do EM, gostaria de saber como fazer para habilitar o EM para que funcione no Windows Vista Enterprise. Grato a todos Cesar [As partes desta mensagem que não continham texto foram removidas]
Re: [oracle_br] Criar external table sem log
Segue um exemplo ai cara espero que ajude :
CREATE TABLE system.log_table (TEXT VARCHAR2(400))
ORGANIZATION EXTERNAL (
TYPE oracle_loader
DEFAULT DIRECTORY bdump
ACCESS PARAMETERS (
RECORDS DELIMITED BY NEWLINE
NOBADFILE NODISCARDFILE NOLOGFILE
FIELDS TERMINATED BY '0x0A'
MISSING FIELD VALUES ARE NULL)
LOCATION ('alert_orabase.log'))
REJECT LIMIT unlimited;
Quanto mais se proíbe,quanto mais se restringe, mais os melhores são
atingidos,pois os medíocres estarão sempre dispostos a aceitar as limitações
que lhes são impostas, sem questionar sua natureza.
David R. B. Siqueira
E-mail : dr...@uol.com.br
Em 04/02/2009 10:35, José Eduardo Batista Juliano escreveu:
Eai pessoal,
Estou com um pequeno problema e talvez alguem ja tenha a solução. Tenho uma
external table que carrega os dados de um arquivo texto para dentro de uma
tabela oracle, porém toda vez que é feito um select nessa external table um
arquivo de LOG é criado.
Eu queria impedir a criacao desse log, tem como?
O comando para criar a external table é esse:
create table ext_table_teste18117 (
cod_linha Varchar2(70),
cod_empresa varchar2(70),
cod_emp Varchar2(70),
cod_ben Varchar2(70),
cod_dep Varchar2(70),
nro_titulo Varchar2(70),
mensagem1 Varchar2(70),
mensagem2 Varchar2(70),
mensagem3 Varchar2(70),
mensagem4 Varchar2(70),
mensagem5 Varchar2(70)
)
organization external (
type oracle_loader
default directory dir_boleto
access parameters (
records delimited by '|'
fields terminated by ';'
missing field values are null
)
location ('CPEREIRA18117.Rem')
)
reject limit Unlimited;
Tentei adicionar dentro da clausula acess_parameters:
NOBADFILE
NODISCARDFILE
NOLOGFILE
Mas dá erro, alguem poderia me ajudar?
Abraço
--
José Eduardo Batista Juliano
Cel (16)9189-2486
Híade Informática
Consultoria Oracle e desenvolvimento de sistemas.
Ribeirão Preto - SP
[As partes desta mensagem que não continham texto foram removidas]
[oracle_br] ORA-21700: object does not exist or is marked for delete
pessoal eu estou usando Oracle 10G e tenho de deletar um tipo de dados e qdo eu tento deletar ele não funciona e dá p seguinte erro: ORA-21700: object does not exist or is marked for delete Alguém sabe como eu resolvo isso? -- [As partes desta mensagem que não continham texto foram removidas]
Re: [oracle_br] Erro ORA-12518
Boa noite Julio. Tive um erro semelhante, também no Windows 2003, com 10.2.0.4. No meu caso foi falta de recurso de SO, tive que baixar o número de processos de Data Guard (o meu ambiente estava replicando). Lucio Citando Julio Bittencourt juliobit_...@yahoo.com.br: Pessoal, alguém já viu isso?  Instalei o 10gR2 (10.2.0.4.0) no Ruindows Server 2003 SP2, mas ao tentar conectar com sqlplus sys...@instancia dá o erro ORA-12518: TNS:listener could not hand off client connection. Ao fazer um tnsping está OK. Conexão local com sqlplus no próprio servidor também tá ok. Não consegui testar um cliente em outra máquina ainda.  No listener.log há o erro 32-bit Windows Error: 2: No such file or directory  No metalink a nota 550859.1 descreve essse problema , mas a solução não tem nada a ver, pois o banco tá no ar e consigo conectar local.  Error: 2: No such file or directory Error stack in listener log:  TNS-12518: TNS:listener could not hand off client connection  TNS-12560: TNS:proto adapter error   TNS-00530: Proto adapter error    32-bit Windows Error: 2: No such file or directory Error Description: ERROR_FILE_NOT_FOUND 2 The system cannot find the file specified. Cause: This indicates the database service is not actually available Ation: 1.Verify if the inteneded database really up and accepting local BEQ connections.  Se alguém tiver alguma idéia, agradeceria muito.  Julio. Veja quais são os assuntos do momento no Yahoo! +Buscados http://br.maisbuscados.yahoo.com [As partes desta mensagem que não continham texto foram removidas] ___ Para fazer uma ligação DDD pra perto ou pra longe, faz um 21. A Embratel tem tarifas muito baratas esperando por você. Aproveite!
[oracle_br] Re: ORA-21700: object does not exist or is marked for delete
Colega, eu sempre coloco a utilização de OO (e consequentemente types, nested tables, e cia bela) no mesmo patamar que o SQL dinâmico, que o XML, que o ANYTYPE, ie : features que devem ser usadas o mínimo do mínimo, pois adicionam ** complexidade ** enorme na hora de debug, podem causar perda de performance (por exemplo, por causa do armazenamento invisível extra que causa cfrme http://asktom.oracle.com/pls/asktom/f?p=100:11:0P11_QUESTION_ID:2318607631616#2333499811237 e http://asktom.oracle.com/pls/asktom/f?p=100:11:0P11_QUESTION_ID:1545206281987#15017578511385 mostram, xml por causa da tendência dos Gênios que programam com isso quererem independência de banco aí enfiam XML onde cabe e onde não cabe), então pessoalmente uso pouquíssimo isso e nunca vi essa msg, mas vamos ver até onde consigo te indicar : a) primeiro de tudo, é ** ABSOLUTAMENTE ** insuficiente dizer 10g, exatamente QUAL é a versão do banco, com 4 dígitos (tipo, 10.2.0.4) ?? Isso para eliminarmos a change de bug, como por exemplo as notas metalink 736979.1 , 4460775.8 e 602033.1 mostram A edição do banco (XE, EE, SE) , o ambiente de programação (se SQL, PL/SQL ou outro), e dados sobre seu ambiente não seriam nada mau... e b) o mais importante , CRIE um teste pequeno mas que reproduza o problema, execute-o no sqlplus e mande pra gente : isso porque via de regra msg do tipo ** nunca ** aparecem quando vc usa um TYPE simples, composto por datatypes escalares, ** quase sempre ** tem complexidades aí, tem herança de alguma tabela, ou usa algum datatype não escalar como o já citado XML, ou types do Context ... Isso tem *** MUITO ** a ver, pois se no banco a feature xml ou context ou o que for que vc precisa não tá ok, é exatamente msg do tipo que vc recebe, como http://forums.oracle.com/forums/thread.jspa?messageID=2495752 ou http://www.experts-exchange.com/Database/Oracle/Q_22159592.html?sfQueryTermInfo=1+succesfulli por exemplo mostram... Provavelmente vc pode extrair o DDL do type em questão via export full com ROWS=N e depois imp com indexfile-arquivo , ou com DBMS_METADATA, ou até mesmo com a ** documentação ** do seu sistema, a idéia é vc simplificar esse DDL e tentar recriar no seu banco teste (que vc TEM, é claro...), aí a gente consegue ver a questão mais claramente, e mesmo durante a tentativa de recriação vcvai ver que ele pede alguma coisa a mais, isso te ajuda até a debugar a questão... []s Chiappa --- Em oracle_br@yahoogrupos.com.br, Leonardo Santos da Mata leonardodam...@... escreveu pessoal eu estou usando Oracle 10G e tenho de deletar um tipo de dados e qdo eu tento deletar ele não funciona e dá p seguinte erro: ORA-21700: object does not exist or is marked for delete Alguém sabe como eu resolvo isso? -- [As partes desta mensagem que não continham texto foram removidas]
Res: [oracle_br] Re: Recuperação de Tablespace em no logging
Colegas, vamos botar uns detalhes aí nessa thread : Brum, primeiro de tudo se vc pedir um ALTER TABLESPACE nn NOLOGGING (ou a criar como NOLOGGING), o que vc conseguiu nesse momento com isso foi NADA, ZERO, NIENTE, ** COISA ALGUMA ** - somente quando vc ** CRIAR ** e/ou mover segmentos/tabelas pra dentro dessa tablespace sem especificar cláusula de log é que esse atributo da tablespace vai ser assumido pelo segmento/tabela, e isso é CRUCIAL, pois operações NOLOGGING são ** sempre ** a nível de tabela/segmento, esse atributo NOLOG da tablespace serve apenas como default quando vc cria a tabela/segmento...O manual mesmo já nos diz : When an existing tablespace logging attribute is changed by an ALTER TABLESPACE statement, all tables, indexes, and partitions created after the statement will have the new default logging attribute (which you can still subsequently override). The logging attribute of existing objects is not changed. Continuando, para que uma operação não gere log, *** absolutamente não basta *** que o atributo de NOLOG esteja ativo, há uma SEGUNDA exigência , é EXIGIDO que a operação esteja na lista de operações que são permitidas nesse modo : UPDATE por exemplo não é, e já cansei de ver expertos recomendarem ou debaterem contra a conveniência de UPDATE em tabelas nolog, o que não faz o MENOR SENTIDO... Ok ? Isto deve ficar escrupulosamente claro, o fato de vc ativar o atributo de NOLOG numa tabela por si *** NÂO QUER DIZER NADA **, não fará COISA ALGUMA se a operação não permite modo nolog, apenas umas poucas operações (como INSERT /*+ APPEND */ , CREATE TABLE, etc) permitem... Há uma TERCEIRA condição, que é a de que o modo NOLOG de operação SEJA permitido nesse banco, vc pode ativar o atributo FORCE LOGGING no seu banco, aí esse cara tem precedência sobre os anteriores, num banco com FORCELOGGING vc pode ativar o atributo num dado segmento e tentar uma operação que normalmente permite nolog que o log será SIM gerado...A Oracle criou isso para os casos em que há replicação lógica/standby, streams ou coisas do tipo, aonde o log é exigido sempre para que tais features funcionem a contento. Muito bem, agora sobre o backup : realmente, se vc tem um dado segmento com atributo NOLOG e o banco não está em FORCELOGGING, se vc iniciar uma operação que permita NOLOG às (digamos) 09:00h , não será gerado log desse ponto em diante para esse segmento, então a coisa é assim : necessariamente esse recurso é usado para cargas em ambiente DW, á noite, onde o segmento em questão ** NÃO ** está sendo usado por ninguém , NÂO HÁ absolutamente outras transações usando a tal tablespace ativamente (só consultas), então SE durante a operação, ou mesmo imediatamente após a operação vc tiver um crash, vc volta o backup anterior do(s) datafile(s) (que óbvio, está com SCN ** anterior ** à operação) e aplica os logs ** até ** às 09:00h, que vc tem,vc perde só a operação NOLOG, yes ??? Simples... O que vc faz também é , imediatamente após a operação NOLOG, é fazer um novo backup ** DO(s) DATAFILE(S) que sofreram a operação, aí sim com esse backup se depois dele vc tiver um crash é ELE que vc vai recuperar, cfrme citado na thread não há log gerados na operação, então NUNCA vc conseguirá fazer um recover com os logs apenas E o datafile do backup anterior está antigo, vc TEM que ter backup dos datafiles APÓS A OPERAÇÃO, mesmo... O manual de Backup nos diz textualmente isso : The presence of NOLOGGING operations must be taken into account when devising the backup and recovery strategy. When a database relies on NOLOGGING operations, the conventional recovery strategy (of recovering from the latest tape backup and applying the archived logfiles) is no longer applicable because the log files cannot recover the NOLOGGING operation. É claro, isso ainda tem que ser joeirado com a sua estratégia de uso : por exemplo, num cliente anterior (DW) o particionamento era por dia do mês, e cada partição ficava numa tablespace diferente, assim era feita a carga NOLOG na partição do dia de hoje, que era uma tablespace só pra ela, SE eu tivesse problema eu simplesmente ** dropava ** a tablespace, recriava VAZIA e re-executava o procedimento de carga do dia... []s Chiappa --- Em oracle_br@yahoogrupos.com.br, Alexandre Brum alexandre_b...@... escreveu Obrigado Carlos Com relação aos dados não haverá problema, pois tenho como reiniciar a carga dos dados. O meu receio maior é quanto a recuperar o datafile dessa tablespace em no logging. Se o BD por exemplo, iria reconhecer um datafile de um cold backup anterior, mesmo com os datafiles das outras tablespaces, controlfile estarem numa nova versão. Fique com Deus. Um grande abraço. Att. Alexandre Brum De: Carlos E. Gorges carlos.gor...@... Para: oracle_br@yahoogrupos.com.br Enviadas: Terça-feira, 3 de Fevereiro de 2009 16:59:07 Assunto: Re: [oracle_br] Re: Recuperação de Tablespace em no logging Boa tarde,
[oracle_br] Re: 04 Fevereiro 2009-ORA-00932: tipos de dados inconsistentes
Colega, a msg é razoavelmente clara : um ** programa ** estava sendo executado e num trecho dele ele chama um componente (uma função, uma procedure, o que for) que exige argumento NUMBER e recebeu CHAR, absolutamente *** NÂO É *** problema do banco em si Esse programa defeituoso pode estar no seu aplicativo mesmo, pode estar gravado no banco mesmo (via database trigger de logout, por exemplo), o seu trabalho é : a) acionar o DBA para que ele capture mais detalhes do erro, ele pode fazer isso fazendo um TRACE da sua sessão e/ou criando uma trigger de banco do tipo ON ERROR que capture mais detalhes do ambiente quando o erro se dá. O DBA também tem poder para consultar os programas (trigers, procedures, etc) armazenados no banco pra ver se acha alguma coisa e b) vc vai acionar os desenvolvedores (ou o fornecedor, se for aplicativo de terceiros) e passar a situação EXATA pra eles, que tela que vc usava, passo a passo o que vc fez, pra eles reproduzirem e descobrirem onde o problema está. Alguns programas/aplicativos melhor desenvolvidos tem opção de debug/rastreio que pode ser ativada, te mostrando nome das rotinas que está executando e quetais, isso pode ser muito útil também, veja com os desenvolvedores/fornecedores se é o seu caso []s Chiappa --- Em oracle_br@yahoogrupos.com.br, luciangelacatizanecatizane luciangela20catiz...@... escreveu Gostaria de ajuda Ao sair do sistema que utilizo ocorre esta msg de erro: ORA-00932: tipos de dados inconsistentes: esperava NUMBER obteve DATE Estou sem saber por onde começar Caso possa ajudar agradeço
Res: [oracle_br] Re: Recuperação de Tablespace em no logging
Só complementando : como eu disse, normalmente operações NOLOG ocorrem em período de carga, então via de regra não há outras transações gravando/alterando na mesma tablespace, normalmente não há considerações necessárias, MAS se houver em caso de crash vc voltará um backup anterior dos datafiles dessa tablespace e irá aplicar os logs até o momento imediatamente anterior ao início NOLOG, que é o que vc tem - ou seja, na prática o banco VOLTA à situação que estava nessa ocasião, as transações outras que estavam ocorrendo em paralelo à operação NOLOG serão perdidas, também terão que ser re-executadas...São coisas do tipo que vc TEM que estabelecer/combinar muito muito direitinho com o DBA e com os OUTROS desenvolvedores , ok ? []s Chiappa Colegas, vamos botar uns detalhes aí nessa thread : Brum, primeiro de tudo se vc pedir um ALTER TABLESPACE nn NOLOGGING (ou a criar como NOLOGGING), o que vc conseguiu nesse momento com isso foi NADA, ZERO, NIENTE, ** COISA ALGUMA ** - somente quando vc ** CRIAR ** e/ou mover segmentos/tabelas pra dentro dessa tablespace sem especificar cláusula de log é que esse atributo da tablespace vai ser assumido pelo segmento/tabela, e isso é CRUCIAL, pois operações NOLOGGING são ** sempre ** a nível de tabela/segmento, esse atributo NOLOG da tablespace serve apenas como default quando vc cria a tabela/segmento...O manual mesmo já nos diz : When an existing tablespace logging attribute is changed by an ALTER TABLESPACE statement, all tables, indexes, and partitions created after the statement will have the new default logging attribute (which you can still subsequently override). The logging attribute of existing objects is not changed. Continuando, para que uma operação não gere log, *** absolutamente não basta *** que o atributo de NOLOG esteja ativo, há uma SEGUNDA exigência , é EXIGIDO que a operação esteja na lista de operações que são permitidas nesse modo : UPDATE por exemplo não é, e já cansei de ver expertos recomendarem ou debaterem contra a conveniência de UPDATE em tabelas nolog, o que não faz o MENOR SENTIDO... Ok ? Isto deve ficar escrupulosamente claro, o fato de vc ativar o atributo de NOLOG numa tabela por si *** NÂO QUER DIZER NADA **, não fará COISA ALGUMA se a operação não permite modo nolog, apenas umas poucas operações (como INSERT /*+ APPEND */ , CREATE TABLE, etc) permitem... Há uma TERCEIRA condição, que é a de que o modo NOLOG de operação SEJA permitido nesse banco, vc pode ativar o atributo FORCE LOGGING no seu banco, aí esse cara tem precedência sobre os anteriores, num banco com FORCELOGGING vc pode ativar o atributo num dado segmento e tentar uma operação que normalmente permite nolog que o log será SIM gerado...A Oracle criou isso para os casos em que há replicação lógica/standby, streams ou coisas do tipo, aonde o log é exigido sempre para que tais features funcionem a contento. Muito bem, agora sobre o backup : realmente, se vc tem um dado segmento com atributo NOLOG e o banco não está em FORCELOGGING, se vc iniciar uma operação que permita NOLOG às (digamos) 09:00h , não será gerado log desse ponto em diante para esse segmento, então a coisa é assim : necessariamente esse recurso é usado para cargas em ambiente DW, á noite, onde o segmento em questão ** NÃO ** está sendo usado por ninguém , NÂO HÁ absolutamente outras transações usando a tal tablespace ativamente (só consultas), então SE durante a operação, ou mesmo imediatamente após a operação vc tiver um crash, vc volta o backup anterior do(s) datafile(s) (que óbvio, está com SCN ** anterior ** à operação) e aplica os logs ** até ** às 09:00h, que vc tem,vc perde só a operação NOLOG, yes ??? Simples... O que vc faz também é , imediatamente após a operação NOLOG, é fazer um novo backup ** DO(s) DATAFILE(S) que sofreram a operação, aí sim com esse backup se depois dele vc tiver um crash é ELE que vc vai recuperar, cfrme citado na thread não há log gerados na operação, então NUNCA vc conseguirá fazer um recover com os logs apenas E o datafile do backup anterior está antigo, vc TEM que ter backup dos datafiles APÓS A OPERAÇÃO, mesmo... O manual de Backup nos diz textualmente isso : The presence of NOLOGGING operations must be taken into account when devising the backup and recovery strategy. When a database relies on NOLOGGING operations, the conventional recovery strategy (of recovering from the latest tape backup and applying the archived logfiles) is no longer applicable because the log files cannot recover the NOLOGGING operation. É claro, isso ainda tem que ser joeirado com a sua estratégia de uso : por exemplo, num cliente anterior (DW) o particionamento era por dia do mês, e cada partição ficava numa tablespace diferente, assim era feita a carga NOLOG na partição do dia de hoje, que era uma tablespace só pra ela, SE eu tivesse problema eu simplesmente ** dropava ** a tablespace, recriava VAZIA e re-executava o
