[oracle_br] Re: Blocagem diferente no Oracle
Não é OLTP o meu banco, mas vamos ver até onde consigo te ajudar . Por partes : primeiro, embora a Oracle não tenha uma recomendação exata para isso, a documentação envolvida são os manuais de Concepts e de Tunning, e no metalink principalmente a nota nro 46757.1 Notes on Choosing an Optimal DB BLOCK SIZE . Depois, tendo os conceitos referentes à essa atividade bem claros (se não os tem, re-estudo das fontes citadas), vamos pensar juntos - a vantagem principal de um bloco maior é que vc popupa I/O, no seguinte esquema : suponha um banco (ou uma tablespace, no 9i) com blocksize de 8 Kb e uma aplicação que frequentemente necessita de dados de vários e vários blocos, se vc precisa (digamos) de dados de dois blocos o bd teve em tese (ignorando os casos de multiblock read) que fazer dois I/Os, e já que cada I/O implica (em tese) em espera por seek time, por rotação de disco, etc, se essa operação fosse feita com blocksize de 16 Kb vc fez um único I/O, poupou-se algum tempo, às vezes até coisa de alguns pontos percentuais. = PORÉM, notar que estamos falando de economia em cima duma operação que custa *** MILISEGUNDOS **, obviamente uma aplicação teria que fazer MUITO e MUITO I/O pra que essa economia seja notável, alguns % de uns tantos milisegundos normalmente é coisa ** DESPREZÌVEL ** ... O segundo efeito (também citado e deduzido das docs citadas) é que, como os caches do bd são criados/mantidos em RAM e controlados via latches e similares, certamente se vc tiver um bloco maior menos blocos serão necessários para se controlar a mesma qtdade de RAM, portanto menos listas de controles, menos latches, etc, seriam necessários em tese, MAS novamente só mesmo em caches ** enormes ** vc veria alguma diferença E não esquecendo que a cada release o bd se torna mais eficiente na administração desses caches, o algoritmo está constantemente melhorando, também.. Então, à vista do acima citado, eu penso que em sendo OLTP nada disso se aplicaria muito : em OLTP é bem menor que em DW a chance da aplicação precisar de infos que com bloco maior cairiam no mesmo bloco (oltp é tipicamente bem aleatória a recuperação de dados), e ainda por cima em oltp por maior que seja a base atual, tipicamente vão ser recuperados via índice relativamente POUCO disso, relativamente pequenas FRAÇõES do todo Óbvio ululante, vc VAI testar antes no seu banco de testes/homologação, principalmente a chance de se ter os índices em bloco maior, mas acho que muito provavelmente os seus testes aí serão negativos Em sendo CPU o seu principal problema e sistema oltp (onde são queries relativamente simples, com poucos dados retornados MAS com enorme massa de usuários fazendo operações similares) , acho que a estratégia de ataque seria ** mesmo mesmo ** é na aplicação, se ASSEGURANDO que a aplicação faz 1 parse e vários executes, usa bind variables, NÃO faz context switch, NÃO usa abusa de loops e cursores aonde o processamento poderia ser feito num SQL só, NÃO chama dentro do SQL functions PL/SQL... Via de regra essas coisas QUEIMAM CPU , detonam, comem-na no café da manhã, é a primeira coisa que teria que ser vista... []s Chiappa --- Em oracle_br@yahoogrupos.com.br, logg [EMAIL PROTECTED] escreveu blz, até aqui tudo bem, já tinha visto isto, tanto é que minha suspeita é esta, pois meu storage é um cavalo e com isto não tenho problemas de I/O , tendo problemas sim de processamento da maquina, chegando a dar 100% dos 15 processadores... De:oracle_br@yahoogrupos.com.br Para:oracle_br@yahoogrupos.com.br Cópia: Data:Sun, 15 Apr 2007 11:05:06 -0300 Assunto:Re: [oracle_br] Blocagem diferente no Oracle Acho que este aqui pode ser interessante, http://www.dba-oracle.com/art_dbazine_9i_multiblock.htm logg escreveu: Senhores, ja li muito a respeito disso no Oracle, agora oq peço é a experiência de vcs, alguém utiliza isto em ambiente OLTP?? Tenho um banco grande, coisa de uns 5TR, minhas tabelas estão desnormalizadas, tenho tabelas com coisa de 250 campos e tudo isto com blocagem default do oracle. A minha idéia seria criar uma tablespace com uma blocagem maior e mover estas minhas tabelas com grande quantidade de campos para lá para ver se consigo um aumento na performance e diminuindo assim a grande leitura de blocos . Alguém tem alguma documentação sobre este tipo de aplicação em ambiente OLTP ?? vlw [As partes desta mensagem que não continham texto foram removidas] -- Atenciosamente, Rodrigo Mufalani OCA 10g tel.: 91739169 [As partes desta mensagem que não continham texto foram removidas]
[oracle_br] Re: Blocagem diferente no Oracle
Ah, o ponto mais importante só pra variar ia esquecendo ... Com certeza, quando vc diz que tem tabelas com duzentas e tantas colunas, é grande a chance aí de vc estar tendo row chaining, em http://asktom.oracle.com/pls/asktom/f? p=100:11:0P11_QUESTION_ID:19013375626973 o autor mostra como testar por isso - SE realmente é o seu caso, isso é um argumento pró um aumento no bloco, mas PLEASE, antes de partir pra isso, veja a chance de normalizar um pouco esse modelo, quando se vê tabela com dúzias de colunas de imediato se pensa é em falha de modelo []s Chiappa --- Em oracle_br@yahoogrupos.com.br, jlchiappa [EMAIL PROTECTED] escreveu Não é OLTP o meu banco, mas vamos ver até onde consigo te ajudar . Por partes : primeiro, embora a Oracle não tenha uma recomendação exata para isso, a documentação envolvida são os manuais de Concepts e de Tunning, e no metalink principalmente a nota nro 46757.1 Notes on Choosing an Optimal DB BLOCK SIZE . Depois, tendo os conceitos referentes à essa atividade bem claros (se não os tem, re-estudo das fontes citadas), vamos pensar juntos - a vantagem principal de um bloco maior é que vc popupa I/O, no seguinte esquema : suponha um banco (ou uma tablespace, no 9i) com blocksize de 8 Kb e uma aplicação que frequentemente necessita de dados de vários e vários blocos, se vc precisa (digamos) de dados de dois blocos o bd teve em tese (ignorando os casos de multiblock read) que fazer dois I/Os, e já que cada I/O implica (em tese) em espera por seek time, por rotação de disco, etc, se essa operação fosse feita com blocksize de 16 Kb vc fez um único I/O, poupou-se algum tempo, às vezes até coisa de alguns pontos percentuais. = PORÉM, notar que estamos falando de economia em cima duma operação que custa *** MILISEGUNDOS **, obviamente uma aplicação teria que fazer MUITO e MUITO I/O pra que essa economia seja notável, alguns % de uns tantos milisegundos normalmente é coisa ** DESPREZÌVEL ** ... O segundo efeito (também citado e deduzido das docs citadas) é que, como os caches do bd são criados/mantidos em RAM e controlados via latches e similares, certamente se vc tiver um bloco maior menos blocos serão necessários para se controlar a mesma qtdade de RAM, portanto menos listas de controles, menos latches, etc, seriam necessários em tese, MAS novamente só mesmo em caches ** enormes ** vc veria alguma diferença E não esquecendo que a cada release o bd se torna mais eficiente na administração desses caches, o algoritmo está constantemente melhorando, também.. Então, à vista do acima citado, eu penso que em sendo OLTP nada disso se aplicaria muito : em OLTP é bem menor que em DW a chance da aplicação precisar de infos que com bloco maior cairiam no mesmo bloco (oltp é tipicamente bem aleatória a recuperação de dados), e ainda por cima em oltp por maior que seja a base atual, tipicamente vão ser recuperados via índice relativamente POUCO disso, relativamente pequenas FRAÇõES do todo Óbvio ululante, vc VAI testar antes no seu banco de testes/homologação, principalmente a chance de se ter os índices em bloco maior, mas acho que muito provavelmente os seus testes aí serão negativos Em sendo CPU o seu principal problema e sistema oltp (onde são queries relativamente simples, com poucos dados retornados MAS com enorme massa de usuários fazendo operações similares) , acho que a estratégia de ataque seria ** mesmo mesmo ** é na aplicação, se ASSEGURANDO que a aplicação faz 1 parse e vários executes, usa bind variables, NÃO faz context switch, NÃO usa abusa de loops e cursores aonde o processamento poderia ser feito num SQL só, NÃO chama dentro do SQL functions PL/SQL... Via de regra essas coisas QUEIMAM CPU , detonam, comem-na no café da manhã, é a primeira coisa que teria que ser vista... []s Chiappa --- Em oracle_br@yahoogrupos.com.br, logg logg@ escreveu blz, até aqui tudo bem, já tinha visto isto, tanto é que minha suspeita é esta, pois meu storage é um cavalo e com isto não tenho problemas de I/O , tendo problemas sim de processamento da maquina, chegando a dar 100% dos 15 processadores... De:oracle_br@yahoogrupos.com.br Para:oracle_br@yahoogrupos.com.br Cópia: Data:Sun, 15 Apr 2007 11:05:06 -0300 Assunto:Re: [oracle_br] Blocagem diferente no Oracle Acho que este aqui pode ser interessante, http://www.dba-oracle.com/art_dbazine_9i_multiblock.htm logg escreveu: Senhores, ja li muito a respeito disso no Oracle, agora oq peço é a experiência de vcs, alguém utiliza isto em ambiente OLTP?? Tenho um banco grande, coisa de uns 5TR, minhas tabelas estão desnormalizadas, tenho tabelas com coisa de 250 campos e tudo isto com blocagem default do oracle. A minha idéia seria criar uma tablespace com uma blocagem maior e mover estas minhas tabelas
[oracle_br] Migração de Banco Server p/ Oracle
Caros amigos, tenho um banco todo desenvolvido em SQL Server mais necessitamos fazer a migração de todo o banco para ORACLE... Aguem saberia me dizer se existe uma ferramenta que possa fazer isso sem danificar o banco... __ Fale com seus amigos de graça com o novo Yahoo! Messenger http://br.messenger.yahoo.com/ [As partes desta mensagem que não continham texto foram removidas]
[oracle_br] exibir conteúdo de arquivo txt no forms
Olá pessoal... preciso da ajuda de vcs.. estou precisando acessar o conteúdo de um arquivo txt, é um arquivo log.. preciso acessar esse arquivo que se encontra no servidor de aplicação, e depois exibir o conteúdo do arquivo no forms alguém poderia me ajudar ? para teste... se alguém souber como fazer isso localmente, ou seja, acessar um txt da minha máquina e exibir o conteúdo no forms, já ajuda... estou usando o forms 10g, acredito que conseguirei algo do tipo pelo webutil, enfim... qualquer ajuda será bem vinda ! desde já, agradeço a todos !
Re: RES: RES: [oracle_br] e-panelinha
boa tarde pessoal. Estou querendo novos desafios também, estou me mudando para São Paulo agora em maio. Será que vocês podem me indicar no e-panelinha tb? Obrigado Wilson Rodrigues de Oliveira Netto --- Em oracle_br@yahoogrupos.com.br, Vanberto Alessandro de Souza Zuim - FOR [EMAIL PROTECTED] escreveu Boa tarde ,Daniel você podedria me indicar tbm Obrigado, Vanberto Zuim Administrador de Banco de Dados OCA Oracle 10g Tecnologia da Informação [EMAIL PROTECTED] (85) 4006-6021 De: oracle_br@yahoogrupos.com.br [mailto:[EMAIL PROTECTED] Em nome de Marco Pereira Enviada em: quinta-feira, 12 de abril de 2007 08:32 Para: oracle_br@yahoogrupos.com.br Assunto: Re: RES: [oracle_br] e-panelinha Valeu Danilo Azevedo [EMAIL PROTECTED] mailto:danilo.azevedo% 40foa.org.br escreveu: Olá Marco, Já mandei um convite pra vc... Um outro site muito interessante é o www.apinfo.com.br. Boa sorte! Atenciosamente, Danilo Azevedo DI - UniFOA _ De: oracle_br@yahoogrupos.com.br mailto:oracle_br% 40yahoogrupos.com.br [mailto:oracle_br@yahoogrupos.com.br mailto:oracle_br%40yahoogrupos.com.br ] Em nome de Marco Pereira Enviada em: quarta-feira, 11 de abril de 2007 16:11 Para: oracle_br@yahoogrupos.com.br mailto:oracle_br% 40yahoogrupos.com.br Assunto: [Possível SPAM] - [oracle_br] e-panelinha - Email found in subject Olá amigos, Alguém pode me indicar no e-panelinha, estou buscando novos desafios. Att, Marco __ Fale com seus amigos de graça com o novo Yahoo! Messenger http://br.messenger http://br.messenger.yahoo.com/ http://br.messenger.yahoo.com/ .yahoo.com/ [As partes desta mensagem que não continham texto foram removidas] -- Esta mensagem e seus anexos podem conter informações confidenciais ou privilegiadas. Caso não seja o destinatário dos mesmos você não está autorizado a utilizar o material para qualquer fim. Solicitamos que apague a mensagem e avise imediatamente o remetente. O conteúdo desta mensagem e seus anexos não representam necessariamente a opinião e a intenção da empresa, não implicando em qualquer obrigação ou responsabilidade da parte da mesma. [As partes desta mensagem que não continham texto foram removidas] __ Fale com seus amigos de graça com o novo Yahoo! Messenger http://br.messenger.yahoo.com/ http://br.messenger.yahoo.com/ [As partes desta mensagem que não continham texto foram removidas] [As partes desta mensagem que não continham texto foram removidas]
[oracle_br] Migração de Banco Server p/ Oracle
Caros amigos, tenho um banco todo desenvolvido em SQL Server mais necessitamos fazer a migração de todo o banco para ORACLE... Aguem saberia me dizer se existe uma ferramenta que possa fazer isso sem danificar o banco... jlchiappa [EMAIL PROTECTED] escreveu: Não é OLTP o meu banco, mas vamos ver até onde consigo te ajudar . Por partes : primeiro, embora a Oracle não tenha uma recomendação exata para isso, a documentação envolvida são os manuais de Concepts e de Tunning, e no metalink principalmente a nota nro 46757.1 Notes on Choosing an Optimal DB BLOCK SIZE . Depois, tendo os conceitos referentes à essa atividade bem claros (se não os tem, re-estudo das fontes citadas), vamos pensar juntos - a vantagem principal de um bloco maior é que vc popupa I/O, no seguinte esquema : suponha um banco (ou uma tablespace, no 9i) com blocksize de 8 Kb e uma aplicação que frequentemente necessita de dados de vários e vários blocos, se vc precisa (digamos) de dados de dois blocos o bd teve em tese (ignorando os casos de multiblock read) que fazer dois I/Os, e já que cada I/O implica (em tese) em espera por seek time, por rotação de disco, etc, se essa operação fosse feita com blocksize de 16 Kb vc fez um único I/O, poupou-se algum tempo, às vezes até coisa de alguns pontos percentuais. = PORÉM, notar que estamos falando de economia em cima duma operação que custa *** MILISEGUNDOS **, obviamente uma aplicação teria que fazer MUITO e MUITO I/O pra que essa economia seja notável, alguns % de uns tantos milisegundos normalmente é coisa ** DESPREZÌVEL ** ... O segundo efeito (também citado e deduzido das docs citadas) é que, como os caches do bd são criados/mantidos em RAM e controlados via latches e similares, certamente se vc tiver um bloco maior menos blocos serão necessários para se controlar a mesma qtdade de RAM, portanto menos listas de controles, menos latches, etc, seriam necessários em tese, MAS novamente só mesmo em caches ** enormes ** vc veria alguma diferença E não esquecendo que a cada release o bd se torna mais eficiente na administração desses caches, o algoritmo está constantemente melhorando, também.. Então, à vista do acima citado, eu penso que em sendo OLTP nada disso se aplicaria muito : em OLTP é bem menor que em DW a chance da aplicação precisar de infos que com bloco maior cairiam no mesmo bloco (oltp é tipicamente bem aleatória a recuperação de dados), e ainda por cima em oltp por maior que seja a base atual, tipicamente vão ser recuperados via índice relativamente POUCO disso, relativamente pequenas FRAÇõES do todo Óbvio ululante, vc VAI testar antes no seu banco de testes/homologação, principalmente a chance de se ter os índices em bloco maior, mas acho que muito provavelmente os seus testes aí serão negativos Em sendo CPU o seu principal problema e sistema oltp (onde são queries relativamente simples, com poucos dados retornados MAS com enorme massa de usuários fazendo operações similares) , acho que a estratégia de ataque seria ** mesmo mesmo ** é na aplicação, se ASSEGURANDO que a aplicação faz 1 parse e vários executes, usa bind variables, NÃO faz context switch, NÃO usa abusa de loops e cursores aonde o processamento poderia ser feito num SQL só, NÃO chama dentro do SQL functions PL/SQL... Via de regra essas coisas QUEIMAM CPU , detonam, comem-na no café da manhã, é a primeira coisa que teria que ser vista... []s Chiappa --- Em oracle_br@yahoogrupos.com.br, logg [EMAIL PROTECTED] escreveu blz, até aqui tudo bem, já tinha visto isto, tanto é que minha suspeita é esta, pois meu storage é um cavalo e com isto não tenho problemas de I/O , tendo problemas sim de processamento da maquina, chegando a dar 100% dos 15 processadores... De:oracle_br@yahoogrupos.com.br Para:oracle_br@yahoogrupos.com.br Cópia: Data:Sun, 15 Apr 2007 11:05:06 -0300 Assunto:Re: [oracle_br] Blocagem diferente no Oracle Acho que este aqui pode ser interessante, http://www.dba-oracle.com/art_dbazine_9i_multiblock.htm logg escreveu: Senhores, ja li muito a respeito disso no Oracle, agora oq peço é a experiência de vcs, alguém utiliza isto em ambiente OLTP?? Tenho um banco grande, coisa de uns 5TR, minhas tabelas estão desnormalizadas, tenho tabelas com coisa de 250 campos e tudo isto com blocagem default do oracle. A minha idéia seria criar uma tablespace com uma blocagem maior e mover estas minhas tabelas com grande quantidade de campos para lá para ver se consigo um aumento na performance e diminuindo assim a grande leitura de blocos . Alguém tem alguma documentação sobre este tipo de aplicação em ambiente OLTP ?? vlw [As partes desta mensagem que não continham texto foram removidas] -- Atenciosamente, Rodrigo Mufalani OCA 10g tel.: 91739169 [As partes desta mensagem que não continham texto foram removidas]
[oracle_br] Fazer histórico de todas as transações efetuadas em tabelas
Caro colegas, Estou com um problema no desenvolvimento de um sistema de informação que irá utilizar Oracle, possivelmente 10g, com relação á historiar todas as transações (INSERT, UPDATE, DELETE) efetuadas nas tabelas do sistema. Este sistema poderá ter mais de 100 tabelas e algumas com algumas dezenas de colunas e ainda por cima o numero de registros já passa de 50 milhões, ou seja, é um sistema mostruoso. Me informaram que o 10g tem uma funcionalidade que historia as alterações feitas em campos, armazenando o usuário, data, hora, etc. que fez as alterações (INSERT, UPDATE, DELETE). Existe mesmo esta funcionalidade? Onde teria material de leitura para tal funcionalidade? Abraço a todos.
Re: [oracle_br] Fazer histórico de todas as transações efetuadas em tabelas
Sistema monstruoso - Sempre é bom pensar e repensar qualquer requisito antes de implementar. Portanto, considere os impactos sobre a implementação da solução abaixo em seu ambiente. http://mportes.blogspot.com/search?q=fga On 4/11/07, Marcelo Magalhães [EMAIL PROTECTED] wrote: Caro colegas, Estou com um problema no desenvolvimento de um sistema de informação que irá utilizar Oracle, possivelmente 10g, com relação á historiar todas as transações (INSERT, UPDATE, DELETE) efetuadas nas tabelas do sistema. Este sistema poderá ter mais de 100 tabelas e algumas com algumas dezenas de colunas e ainda por cima o numero de registros já passa de 50 milhões, ou seja, é um sistema mostruoso. Me informaram que o 10g tem uma funcionalidade que historia as alterações feitas em campos, armazenando o usuário, data, hora, etc. que fez as alterações (INSERT, UPDATE, DELETE). Existe mesmo esta funcionalidade? Onde teria material de leitura para tal funcionalidade? Abraço a todos. -- Marcio Portes Material Tecnico em Portugues - http://mportes.blogspot.com Practical Learning Oracle - http://mportes.blogspot.com/2006/02/practical-learning-oracle.html [As partes desta mensagem que não continham texto foram removidas]
[oracle_br] Conexão com o banco
Caros amigos Estou com uma dificuldade que a seguinte... Tenho um banco que foi instalado em uma maquina servidora e outras maquinas prescisam acessar esse banco... A rede funciona normalmente e via acesso remoto eu consigo acessar o banco, porem não consigo efetuar a configuração da rede para que o acesso fique de cliente / servidor... Detalhe foi instalado nas maquinas o cleint e configurado o tnsname quanto tento logar via maquina aparece o erro -- ORA - 12514: TNS:listener não pode resolver o service name fornecido no descritor de conexão... Deve esta esquecendo de algum parametro - Alguem poderia ma ajudar... jlchiappa [EMAIL PROTECTED] escreveu: Não é OLTP o meu banco, mas vamos ver até onde consigo te ajudar . Por partes : primeiro, embora a Oracle não tenha uma recomendação exata para isso, a documentação envolvida são os manuais de Concepts e de Tunning, e no metalink principalmente a nota nro 46757.1 Notes on Choosing an Optimal DB BLOCK SIZE . Depois, tendo os conceitos referentes à essa atividade bem claros (se não os tem, re-estudo das fontes citadas), vamos pensar juntos - a vantagem principal de um bloco maior é que vc popupa I/O, no seguinte esquema : suponha um banco (ou uma tablespace, no 9i) com blocksize de 8 Kb e uma aplicação que frequentemente necessita de dados de vários e vários blocos, se vc precisa (digamos) de dados de dois blocos o bd teve em tese (ignorando os casos de multiblock read) que fazer dois I/Os, e já que cada I/O implica (em tese) em espera por seek time, por rotação de disco, etc, se essa operação fosse feita com blocksize de 16 Kb vc fez um único I/O, poupou-se algum tempo, às vezes até coisa de alguns pontos percentuais. = PORÉM, notar que estamos falando de economia em cima duma operação que custa *** MILISEGUNDOS **, obviamente uma aplicação teria que fazer MUITO e MUITO I/O pra que essa economia seja notável, alguns % de uns tantos milisegundos normalmente é coisa ** DESPREZÌVEL ** ... O segundo efeito (também citado e deduzido das docs citadas) é que, como os caches do bd são criados/mantidos em RAM e controlados via latches e similares, certamente se vc tiver um bloco maior menos blocos serão necessários para se controlar a mesma qtdade de RAM, portanto menos listas de controles, menos latches, etc, seriam necessários em tese, MAS novamente só mesmo em caches ** enormes ** vc veria alguma diferença E não esquecendo que a cada release o bd se torna mais eficiente na administração desses caches, o algoritmo está constantemente melhorando, também.. Então, à vista do acima citado, eu penso que em sendo OLTP nada disso se aplicaria muito : em OLTP é bem menor que em DW a chance da aplicação precisar de infos que com bloco maior cairiam no mesmo bloco (oltp é tipicamente bem aleatória a recuperação de dados), e ainda por cima em oltp por maior que seja a base atual, tipicamente vão ser recuperados via índice relativamente POUCO disso, relativamente pequenas FRAÇõES do todo Óbvio ululante, vc VAI testar antes no seu banco de testes/homologação, principalmente a chance de se ter os índices em bloco maior, mas acho que muito provavelmente os seus testes aí serão negativos Em sendo CPU o seu principal problema e sistema oltp (onde são queries relativamente simples, com poucos dados retornados MAS com enorme massa de usuários fazendo operações similares) , acho que a estratégia de ataque seria ** mesmo mesmo ** é na aplicação, se ASSEGURANDO que a aplicação faz 1 parse e vários executes, usa bind variables, NÃO faz context switch, NÃO usa abusa de loops e cursores aonde o processamento poderia ser feito num SQL só, NÃO chama dentro do SQL functions PL/SQL... Via de regra essas coisas QUEIMAM CPU , detonam, comem-na no café da manhã, é a primeira coisa que teria que ser vista... []s Chiappa --- Em oracle_br@yahoogrupos.com.br, logg [EMAIL PROTECTED] escreveu blz, até aqui tudo bem, já tinha visto isto, tanto é que minha suspeita é esta, pois meu storage é um cavalo e com isto não tenho problemas de I/O , tendo problemas sim de processamento da maquina, chegando a dar 100% dos 15 processadores... De:oracle_br@yahoogrupos.com.br Para:oracle_br@yahoogrupos.com.br Cópia: Data:Sun, 15 Apr 2007 11:05:06 -0300 Assunto:Re: [oracle_br] Blocagem diferente no Oracle Acho que este aqui pode ser interessante, http://www.dba-oracle.com/art_dbazine_9i_multiblock.htm logg escreveu: Senhores, ja li muito a respeito disso no Oracle, agora oq peço é a experiência de vcs, alguém utiliza isto em ambiente OLTP?? Tenho um banco grande, coisa de uns 5TR, minhas tabelas estão desnormalizadas, tenho tabelas com coisa de 250 campos e tudo isto com blocagem default do oracle. A minha idéia seria criar uma tablespace com uma blocagem maior e mover estas minhas tabelas com grande quantidade de campos para lá para ver se consigo um
[oracle_br] Re: exibir conteúdo de arquivo txt no forms
Em sendo modo web acho que necessariamente seria mesmo pelo webutil, em http://www.oracle.com/technology/products/forms/htdocs/webutil/webutil .htm (a página-mãe dele) nos links de How Tos vc tem Performing Text_IO on the client using WebUtil que deve te ser útil... []s Chiappa --- Em oracle_br@yahoogrupos.com.br, silas_oracle [EMAIL PROTECTED] escreveu Olá pessoal... preciso da ajuda de vcs.. estou precisando acessar o conteúdo de um arquivo txt, é um arquivo log.. preciso acessar esse arquivo que se encontra no servidor de aplicação, e depois exibir o conteúdo do arquivo no forms alguém poderia me ajudar ? para teste... se alguém souber como fazer isso localmente, ou seja, acessar um txt da minha máquina e exibir o conteúdo no forms, já ajuda... estou usando o forms 10g, acredito que conseguirei algo do tipo pelo webutil, enfim... qualquer ajuda será bem vinda ! desde já, agradeço a todos !
[oracle_br] LOV com problemas
Olá pessoal... alguém já viu o seguinte erro: Situação: uma lov que busca valores em uma view, com muitos registros. Inicialmente a lov não estava abrindo não filtrando, o que demora muito tempo. A lov foi alterada para que filtre antes de abrir... ou seja, o usuário tem que digitar algo para buscar. Entretanto, a lov abre e o usuário digita o que quer, porém quando manda localizar, a lov fecha sozinha e apresenta o erro: FRM-40502 - Oracle Error Unable To Read LOV ORA-01403 - No Data Found Já peguei o select da lov e está correto. Pesquisei a encontrei um paper que fala ao, bem próximo do que está acontecendo. Diz-se de um BUG (463399). Alguém já viu isso? Tem o patch? Obrigado Ricardo. __ Fale com seus amigos de graça com o novo Yahoo! Messenger http://br.messenger.yahoo.com/ [As partes desta mensagem que não continham texto foram removidas]
RE: [oracle_br] Migração de Banco Server p/ Or acle
Marcião, com certeza essa é a melhor solução ! baixo risco e acredito que seja o menor custo também ! Acho que todos concordam que uma ferramenta de tradução nunca será a melhor solução ainda mais se tratando de escrever PL/SQL e os vários recursos de melhoria de desempenho tais como Cursores, Bulk Collect, etc... enfim, traduzir por traduzir é bem arriscado ! Abraço, Marco. From: oracle_br@yahoogrupos.com.br [mailto:[EMAIL PROTECTED] On Behalf Of PUB: Marcio Portes Sent: segunda-feira, 16 de abril de 2007 11:38 To: oracle_br@yahoogrupos.com.br Subject: Re: [oracle_br] Migração de Banco Server p/ Oracle Contrate uma equipe que SAIBA realmente LER código T-SQL e ESCREVER código PL/SQL e mais um DBA experiente em Oracle. Pronto, não danifica nada e voce terá sucesso em sua migração. On 4/16/07, Silvio Cesar Feitoza [EMAIL PROTECTED] mailto:s_feitoza%40yahoo.com.br wrote: Caros amigos, tenho um banco todo desenvolvido em SQL Server mais necessitamos fazer a migração de todo o banco para ORACLE... Aguem saberia me dizer se existe uma ferramenta que possa fazer isso sem danificar o banco... __ Fale com seus amigos de graça com o novo Yahoo! Messenger http://br.messenger.yahoo.com/ http://br.messenger.yahoo.com/ [As partes desta mensagem que não continham texto foram removidas] -- Marcio Portes Material Tecnico em Portugues - http://mportes.blogspot.com http://mportes.blogspot.com Practical Learning Oracle - http://mportes.blogspot.com/2006/02/practical-learning-oracle.html http://mportes.blogspot.com/2006/02/practical-learning-oracle.html [As partes desta mensagem que não continham texto foram removidas] [As partes desta mensagem que não continham texto foram removidas]
[oracle_br] Re: Data Pump
Ola Até ai tudo bem que esse parametro irá transferir todo o esquema do usuário, mas para efetuar somente o import das tabelas. Por exemplo com o usuario x quero realizar o impd e transferir as tabelas de um *.dmp para o usuário y. Valeu --- Em oracle_br@yahoogrupos.com.br, Marcio Portes [EMAIL PROTECTED] escreveu impdp help=y ... REMAP_SCHEMA Objects from one schema are loaded into another schema. ... On 4/15/07, Eli Dias [EMAIL PROTECTED] wrote: Boa noite. Galera existe algum parametro no IMPDP que realize a mesma função do fromuser/touser do import? -- Marcio Portes Material Tecnico em Portugues - http://mportes.blogspot.com Practical Learning Oracle - http://mportes.blogspot.com/2006/02/practical-learning-oracle.html [As partes desta mensagem que não continham texto foram removidas]
[oracle_br] Duvida Archive?
Olá Pessoal, gostaria de tirar uma duvida. para que uma tabela não passe a gerar Redu / Archive seria apenas dar um ALTER TABLE XXX NOLOGGING; ou submeter a tabela a um truncate table? é isso mesmo, ? att WELVIS DOUGLAS __ Fale com seus amigos de graça com o novo Yahoo! Messenger http://br.messenger.yahoo.com/ [As partes desta mensagem que não continham texto foram removidas]
Re: [oracle_br] Re: Data Pump
E quando voce faz import usando fromuser/touser voce espera enviar somente tabelas??? Não, voce precisa especificar com outro parâmetro, certo? No datapump também... use TABLESIdentifies a list of tables to import. Assim como no import normal. On 4/16/07, Eli Dias [EMAIL PROTECTED] wrote: Ola Até ai tudo bem que esse parametro irá transferir todo o esquema do usuário, mas para efetuar somente o import das tabelas. Por exemplo com o usuario x quero realizar o impd e transferir as tabelas de um *.dmp para o usuário y. Valeu --- Em oracle_br@yahoogrupos.com.br oracle_br%40yahoogrupos.com.br, Marcio Portes [EMAIL PROTECTED] escreveu impdp help=y ... REMAP_SCHEMA Objects from one schema are loaded into another schema. ... On 4/15/07, Eli Dias [EMAIL PROTECTED] wrote: Boa noite. Galera existe algum parametro no IMPDP que realize a mesma função do fromuser/touser do import? -- Marcio Portes Material Tecnico em Portugues - http://mportes.blogspot.com Practical Learning Oracle - http://mportes.blogspot.com/2006/02/practical-learning-oracle.html [As partes desta mensagem que não continham texto foram removidas] -- Marcio Portes Material Tecnico em Portugues - http://mportes.blogspot.com Practical Learning Oracle - http://mportes.blogspot.com/2006/02/practical-learning-oracle.html [As partes desta mensagem que não continham texto foram removidas]
[oracle_br] Dúvida SQL Loader
Boa tarde! Tenho uma pasta com cerca de 45 arquivos CSV no mesmo padrão de formato e quero subir para o banco com SQL Loader. A rotina para subir um dos arquivos já está funcionando, no entanto gostaria de saber se tem como ordenar o SQL Loader para ler de todos os arquivos com o mesmo comando ou se eu preciso pensar em algum batch avançado para isso... Obrigado desde já! Clayton Rocha [As partes desta mensagem que não continham texto foram removidas]
Re: [oracle_br] Dúvida SQL Loader
qual a versão do banco? E qual sistema operacional? (E eu juro que é a última vez que pergunto! ;-) On 4/16/07, Clayton Rocha [EMAIL PROTECTED] wrote: Boa tarde! Tenho uma pasta com cerca de 45 arquivos CSV no mesmo padrão de formato e quero subir para o banco com SQL Loader. A rotina para subir um dos arquivos já está funcionando, no entanto gostaria de saber se tem como ordenar o SQL Loader para ler de todos os arquivos com o mesmo comando ou se eu preciso pensar em algum batch avançado para isso... Obrigado desde já! Clayton Rocha [As partes desta mensagem que não continham texto foram removidas] -- Marcio Portes Material Tecnico em Portugues - http://mportes.blogspot.com Practical Learning Oracle - http://mportes.blogspot.com/2006/02/practical-learning-oracle.html [As partes desta mensagem que não continham texto foram removidas]
[oracle_br] Tablespace
Sr´s Já pesquisei em varias apostilas e livros sobre Tablespace, e sempre encontro alguma coisa a mais. Mas gostaria de encontrar alguma apostila ou livro falando tudo sobre Tablespace, algo completo. Se alguem souber de algum site ou livro que contenha essa informação, fico muito agradecido. Um abraço a todos.
RES: [oracle_br] Conexão com o banco
Olá Silvio, Realmente você está preenchendo o service name incorreto na maquina cliente ou nem está passando. mande para gente o tnsname de um dos clientes e mande tb o listener.ora do servidor para agente bater as informações. Ou voce mesmo pode fazer isso. É só verificar se o servicename do ser tnsnames.ora está no listener.ora do servidor. Se isso não resolver, pode ser problema de rede. - Verifique se a máquina cliente enxerga a máquina servidora. - Verifique se o banco está ativo no servidor - Verifique se o listener está ativo no servidor. Bom... se não resolver, poste de novo para continuarmos as possibilidades. Abraços -Mensagem original- De: oracle_br@yahoogrupos.com.br [mailto:[EMAIL PROTECTED] Em nome de Silvio Cesar Feitoza Enviada em: segunda-feira, 16 de abril de 2007 12:46 Para: oracle_br@yahoogrupos.com.br Assunto: [oracle_br] Conexão com o banco Caros amigos Estou com uma dificuldade que a seguinte... Tenho um banco que foi instalado em uma maquina servidora e outras maquinas prescisam acessar esse banco... A rede funciona normalmente e via acesso remoto eu consigo acessar o banco, porem não consigo efetuar a configuração da rede para que o acesso fique de cliente / servidor... Detalhe foi instalado nas maquinas o cleint e configurado o tnsname quanto tento logar via maquina aparece o erro -- ORA - 12514: TNS:listener não pode resolver o service name fornecido no descritor de conexão... Deve esta esquecendo de algum parametro - Alguem poderia ma ajudar... jlchiappa HYPERLINK mailto:jlchiappa%40yahoo.com.br[EMAIL PROTECTED] escreveu: Não é OLTP o meu banco, mas vamos ver até onde consigo te ajudar . Por partes : primeiro, embora a Oracle não tenha uma recomendação exata para isso, a documentação envolvida são os manuais de Concepts e de Tunning, e no metalink principalmente a nota nro 46757.1 Notes on Choosing an Optimal DB BLOCK SIZE . Depois, tendo os conceitos referentes à essa atividade bem claros (se não os tem, re-estudo das fontes citadas), vamos pensar juntos - a vantagem principal de um bloco maior é que vc popupa I/O, no seguinte esquema : suponha um banco (ou uma tablespace, no 9i) com blocksize de 8 Kb e uma aplicação que frequentemente necessita de dados de vários e vários blocos, se vc precisa (digamos) de dados de dois blocos o bd teve em tese (ignorando os casos de multiblock read) que fazer dois I/Os, e já que cada I/O implica (em tese) em espera por seek time, por rotação de disco, etc, se essa operação fosse feita com blocksize de 16 Kb vc fez um único I/O, poupou-se algum tempo, às vezes até coisa de alguns pontos percentuais. = PORÉM, notar que estamos falando de economia em cima duma operação que custa *** MILISEGUNDOS **, obviamente uma aplicação teria que fazer MUITO e MUITO I/O pra que essa economia seja notável, alguns % de uns tantos milisegundos normalmente é coisa ** DESPREZÌVEL ** ... O segundo efeito (também citado e deduzido das docs citadas) é que, como os caches do bd são criados/mantidos em RAM e controlados via latches e similares, certamente se vc tiver um bloco maior menos blocos serão necessários para se controlar a mesma qtdade de RAM, portanto menos listas de controles, menos latches, etc, seriam necessários em tese, MAS novamente só mesmo em caches ** enormes ** vc veria alguma diferença E não esquecendo que a cada release o bd se torna mais eficiente na administração desses caches, o algoritmo está constantemente melhorando, também.. Então, à vista do acima citado, eu penso que em sendo OLTP nada disso se aplicaria muito : em OLTP é bem menor que em DW a chance da aplicação precisar de infos que com bloco maior cairiam no mesmo bloco (oltp é tipicamente bem aleatória a recuperação de dados), e ainda por cima em oltp por maior que seja a base atual, tipicamente vão ser recuperados via índice relativamente POUCO disso, relativamente pequenas FRAÇõES do todo Óbvio ululante, vc VAI testar antes no seu banco de testes/homologaçã-o, principalmente a chance de se ter os índices em bloco maior, mas acho que muito provavelmente os seus testes aí serão negativos...-. Em sendo CPU o seu principal problema e sistema oltp (onde são queries relativamente simples, com poucos dados retornados MAS com enorme massa de usuários fazendo operações similares) , acho que a estratégia de ataque seria ** mesmo mesmo ** é na aplicação, se ASSEGURANDO que a aplicação faz 1 parse e vários executes, usa bind variables, NÃO faz context switch, NÃO usa abusa de loops e cursores aonde o processamento poderia ser feito num SQL só, NÃO chama dentro do SQL functions PL/SQL... Via de regra essas coisas QUEIMAM CPU , detonam, comem-na no café da manhã, é a primeira coisa que teria que ser vista... []s Chiappa --- Em HYPERLINK mailto:oracle_br%40yahoogrupos.com.br[EMAIL PROTECTED], logg [EMAIL PROTECTED] escreveu blz, até aqui tudo bem, já tinha visto isto, tanto é que minha suspeita é
[oracle_br] ORA-12571 TNS-packet writer failure
Pessoal, estou com um problema. Preciso de ajuda. Tenho uma aplicação que executa uma procedure (esta proc faz leitura em algumas tabelas de sistemas de terceiros) e grava alguns dados em uma tabela temporária. A aplicação funciona perfeitamente em ambiente de homologação. Quando coloco em ambiente de produção aparece o erro ORA-12571 TNS-packet writer failure. A aplicação no ambiente de homologação apontando para a base de produção funciona perfeitamente. A aplicação no ambiente de produção apontando para a base de homologação também funciona. Só dá problema quando tudo está no ambiente de produção. Se executo somente a procedure, no ambiente de produção, sem o uso da aplicação tudo funciona. A aplicação executa outras procedures e tudo funciona, somente uma está me dando este problema. Será que alguém do grupo já teve este problema ou pode me dar uma dica? Já andei procurando no Google, mas até agora não consegui entender este erro. Ambiente de produção = Oracle 8i Ambiente de homologação = Oracle 8i e 9 Obrigado pela atenção.
Re: [oracle_br] ORA-12571 TNS-packet writer failure
Revise essa procedure, veja se não há nada hard coded nela apontando a um ambiente específico. On 4/16/07, Jorge Augusto Lustosa [EMAIL PROTECTED] wrote: Pessoal, estou com um problema. Preciso de ajuda. Tenho uma aplicação que executa uma procedure (esta proc faz leitura em algumas tabelas de sistemas de terceiros) e grava alguns dados em uma tabela temporária. A aplicação funciona perfeitamente em ambiente de homologação. Quando coloco em ambiente de produção aparece o erro ORA-12571 TNS-packet writer failure. A aplicação no ambiente de homologação apontando para a base de produção funciona perfeitamente. A aplicação no ambiente de produção apontando para a base de homologação também funciona. Só dá problema quando tudo está no ambiente de produção. Se executo somente a procedure, no ambiente de produção, sem o uso da aplicação tudo funciona. A aplicação executa outras procedures e tudo funciona, somente uma está me dando este problema. Será que alguém do grupo já teve este problema ou pode me dar uma dica? Já andei procurando no Google, mas até agora não consegui entender este erro. Ambiente de produção = Oracle 8i Ambiente de homologação = Oracle 8i e 9 Obrigado pela atenção. -- Marcio Portes Material Tecnico em Portugues - http://mportes.blogspot.com Practical Learning Oracle - http://mportes.blogspot.com/2006/02/practical-learning-oracle.html [As partes desta mensagem que não continham texto foram removidas]
