[oracle_br] Re: Oracle Database Express Edition
Sim, vc está absolutamente correto, vc pode embutir o XE no seu aplicativo, redistribui-lo a seus clientes, sem prob algum, e não há nenhuma restrição quanto ao seu Aplicativo ser desenvolvido em qual linguagem for, em qual SO que for, em qual ambiente (client/server ou web), nem em relação ao número de usuários, nem nada assim... Apenas fique ciente que, Além das severas restrições de espaço e processamento vc : a) absolutamente *** NÃO *** vai ter o menor Suporte da Oracle, nunca, ou seja : deu um erro ORA-600 por causa de um bug, digamos, vc tá por sua conta... Idem se vc precisar de um patch pra resolver alguma questão de Segurança, ou de Usabilidade (tipo alguma feature que quebra em determinados momentos , talvez de pico de uso) ... b) vc NÃO vai ter direito de usar no seu Aplicativo *** muitas *** features do banco que por vezes poderiam ser Cruciais para performance/administração/usabilidade, tais como Particionamento, rotinas Java dentro do banco, Assistentes de configuração/performance, alguns itens de encriptação de dados, enter Vários outros... c) não é para todos os Sistemas Operacionais que a Oracle suporta o database que vc tem versão do XE, é basicamente pro Linux e pro Windows , ambos 32-bits : TODOS os seus Clientes que quiserem usar algum servidor UNIX, por exemplo (que já possuam, digamos) tão fora, e quem tiver Windows ou Linux de 64 bits vai ter que gambiarrar e rodar em modo de Compatibilidade : dado o tamanhinho de nada máximo do XE, isso via de regra não é impedimento, MAS saiba que a issue Existe, isso Pode ter dar problemas... Se NADA disso te perturba, go ahead... []s Chiappa --- Em oracle_br@yahoogrupos.com.br, lcgr_rib luiz.ribeiro@... escreveu Olá amigos. Na licença de uso do OracleXE, li (e interpretei) que posso distribuir minha aplicação juntamente com o Oracle Express Edition. Segue abaixo: License Rights We grant you a nonexclusive, nontransferable limited license to use the programs for: (a) purposes of developing, prototyping and running your applications for your own internal data processing operations; (b) you may also distribute the programs with your applications; (c) you may use the programs to provide third party demonstrations and training; and d) you may copy and distribute the programs to your licensees provided that each such licensee agrees to the terms of this Agreement. You are not permitted to use the programs for any purpose other than as permitted under this Agreement. Program documentation is either shipped with the programs, or documentation may accessed online at http://www.oracle.com/technology/documentation/ . Gostaria de saber se minha interpretação está correta, ou seja, posso vender minha aplicação e junto com ela fornecer o OracleXE para o cliente? Existe alguma restrição quanto a plataforma de desenvolvimento ou linguagem de programação? Tenho conhecimento dos limites de espaço, processamento e memória do OracleXE. É que para pequenas empresas, fica complicado investir direto num Database Enterprise, por exemplo. Muito obrigado.
Re: [oracle_br]Relatório com imagens
Colega, afaik praticamente ** todos ** os principais Produtos de desenvolvimento de aplicações possuem geradores de relatório, e quase todos os geradores de relatórios suportam BLOBs : da própria Oracle vc tem por exemplo o Oracle Reports, o Oracle Business Intelligence Publisher, o APEX, entre outras, e de terceiros aí a lista chega na dúzia, vai desde tradicionais genéricos como Crystal Reports, não focados em Oracle como o Microsoft Reporting, mesclados como o Jasper Reports, até produtos focados como MicroStrategy e Information Builders, freewares como o Pentaho, a lista vai looonge, TODOS esses eu já vi ser usado com BLOBs , e não vou nem tentar exemplificar mais, senão eu ficaria até amanhã, E ainda levaria pau dos fãs da tool/linguagem/gerador A, B ou C que esqueci O que vc TEM que ter em mente é : a) BLOB é um binário, e portanto pode ter gravado nele imagens de QUALQUER formato, MAS nem todas as tools aceitam TODOS os formatos de imagem num report : formatos mais ou menos 'universais' como .BMP, .PCX, .PDF, .TIFF, etc, normalmente vão bem, mas vc Tem Que ver qual formato de imagem tá sendo usado aí no seu banco, pra só depois checar se a tool que vc está analisando o aceita... b) quanto à qual é o melhor , é a resposta de sempre : NÃO há ** uma ** que claramente se sobressaia em Todos os quesitos, que seja ao mesmo tempo intuitiva, poderosa , barata, que tenha um comunidade de usuários ativa, não SE vc hoje já usa alguma, já a possui e tá costumado com ela, veja lá na Documentação e na internet/grupos de usuários/livros e outras fontes se ela aceita ler BLOBs E SE aceita o formato de imagem que vc quer, SE vc não tem nenhuma e deseja uma, eu diria pra vc experimentar as que citei, E dar uma googlada/conversada com outros desenvolvedores que usam a mesma tool de desenv que vc o que eles recomendam... Vc até pode , embora o fórum não seja focado nisso, mandar uma Outra mensagem explicando qual é o seu ambiente de desenvolvimento, qual tool usa (E em qual versão/SO!!), se é web ou não, número de usuários, tamanho da equipe, experiências anteriores da equipe, que quem tiver + ou - similar pode palpitar []s Chiappa --- Em oracle_br@yahoogrupos.com.br, Marcelo Feijó Vargas marcelofvargas@... escreveu Pessoal, boa noite! Alguém sabe alguma forma de gerar relatórios com imagems (campo blob), e qual a melhor maneira? Existe alguma ferramenta que faça isso? Minha base de dados é oracle 10g Obrigado., Marcelo Feijó Vargas
RES: [oracle_br] Re: DBWR lento
Olá pessoal... Gostaria de saber se há alguma nota no metalink que diz se quanto em quanto tempo é um switch para um banco OLTP.. Eu costumo deixar/recomendar que os switchs sejam de pelo menos uns 10 minutos., claro dependendo do horário este número pode variar um pouco tanto para mais quanto para menos. Mas com toda esta discussão fiquei curioso sobre isso... Att, Welvis Douglas De: oracle_br@yahoogrupos.com.br [mailto:oracle_br@yahoogrupos.com.br] Em nome de Fábio Gibon - Comex System Enviada em: segunda-feira, 6 de junho de 2011 22:08 Para: oracle_br@yahoogrupos.com.br Assunto: Re: [oracle_br] Re: DBWR lento Na real eu não queria saber realmente se o redolog deveria ser 50mb, 200mb, 2gb, ... foi levantado a hipótese aqui de que o problema de desempenho do banco era por problema de performance de IO nos discos onde estavam os redologs, então tentei levantar alguns dados para ver se não estava pecando em alguma configuração (antes de sair culpando o disk group que estão os redos) sds Fábio Gibon - Original Message - From: jljlsilva To: oracle_br@yahoogrupos.com.br Sent: Monday, June 06, 2011 4:40 PM Subject: [oracle_br] Re: DBWR lento portilho, legal suas observações. penso que o caminho é esse mesmo. eu imagino que as pessoas que colocam perguntas desse tipo que o fábio gibon colocou aqui nesse tópico, não tem informações suficientes sobre o assunto e precisam justamente desse tipo de comentário, sem exageros, mas direcionando, neste caso, sobre como calcular o que ele precisa. legal... valeu... --- Em oracle_br@yahoogrupos.com.br, Ricardo Portilho Proni ricardo.proni@... escreveu Oi. - Não importa o tamanho do banco, e sim o tamanho das gravações. Um banco de 1TB que só sofre SELECT não terá impacto em ter os pequenos Redo Logs padrão do Oracle (3 x 50MB); - Você deve ter Redo Logs suficientes (em tamanho e quantidade) para contar sua maior gravação concorrente. Veja neste exemplo, eu executo uma gravação de 250MB sem ter 250MB de Redo Log, e o tempo é prejudicado em mais de 100%. Após adicionar um único Redo Log de 1GB, tenho meu problema solucionado: http://profissionaloracle.com.br/blogs/portilho/2009/01/14/imp-lento-no-oracle/ - Você deve ter Redo Logs suficientes (em tamanho em quantidade) de forma que o Wait Event log file switch não ocupe um tempo relevante no período analisado. Se ele ocupa apenas 5% do seu tempo de banco, e você não precisa destes 5% de tempo, não precisa altera-los; - Redo Logs grandes não impactam o sistema por conta da geração de Archives grandes: se você está efetuando uma gravação de 100GB, o Oracle irá gerar 100GB (+ ou -) de Archives de qualquer forma, seja em pedaços de 100MB ou de 1GB; - Em um RAC de 8 Nós, teriam sido gastos alguns milhões de dólares só de licenças do Oracle. Neste cenário, 160GB de disco é irrelevante, este ambiente deve ter até mais de 160GB de RAM. Espero ter ajudado. Em Sáb, 2011-06-04 às 01:32 +, jljlsilva escreveu: chiappa, mas, vamos detalhar um pouco mais. o que é um banco de dados nanico prá vc? vc acha q um redolog muito grande não poderia causar problemas de performance no momento do arquivamento? afinal, não é toda empresa que tem storages de performance tão alta quanto gostaríamos. nunca precisei usar um membro de redolog de 2GB, até o momento. me parece q, como vc citou no final da sua explicação, vc usou como base níveis / volumes não triviais, o que precisaria de muito mais análise para se chegar a tal conclusão. entende porque me surpreendeu? até porque vc enfatiza com letras grandes como se o básico/mínimo fosse aquilo, via de regra. --- Em oracle_br@yahoogrupos.com.br, José Laurindo jlchiappa@ escreveu Então, seguinte : é Claro que a maneira Correta e precisa de especificar o redo log size no 10g é usar o Assistente apropriado, e é claro também que o redo log guarda alterações vindas de DML basicamente, então o tamanho apropriado depende Totalmente de quantas alterações simultâneas vc tem E o quanto elas 'alteram' , E também óbvio que podem existir bancos nanicos aonde o mínimo do mínimo tá mais que bão, mas eu penso aqui em produção plena, ambiente com criticidade, numa Empresa com muitos usuários, muitas alterações e centenas e centenas de Gb de dados, NÂO-ESTÁTICOS Nesse cenário não tem como eu chamar centena de Mbs de outra coisa que não anão, mínimo do mínimo , verticalmente prejudicado se vc quiser ser politicamente correto... Pra vc ter uma idéia , a nota oficial sobre isso (a General Guideline For Sizing The Online Redo Log Files (Doc ID 781999.1), acessível no metalink) diz : 'An excerpt from the Oracle Database Performance Tuning Guide provides the general guideline. It may not always be possible to provide a specific size recommendation for redo log files, but redo log files in the range of a hundred megabytes to a few gigabytes are considered reasonable. Size your online redo
Re: [oracle_br] Re: DBWR lento
Bom dia Welvis, Eu não conheço nenhuma nota que fale a respeito, mas já tive essa mesma dúvida que você e na época eu encontrei na documentação que o switch deve acontecer em 20 minutos mais ou menos. Vou procurar o link para passar aqui no grupo. Abraço Att. Marcelo Procksch Em 7 de junho de 2011 09:44, wel...@stcruz.com.br escreveu: Olá pessoal... Gostaria de saber se há alguma nota no metalink que diz se quanto em quanto tempo é um switch para um banco OLTP.. Eu costumo deixar/recomendar que os switchs sejam de pelo menos uns 10 minutos., claro dependendo do horário este número pode variar um pouco tanto para mais quanto para menos. Mas com toda esta discussão fiquei curioso sobre isso... Att, Welvis Douglas De: oracle_br@yahoogrupos.com.br [mailto:oracle_br@yahoogrupos.com.br] Em nome de Fábio Gibon - Comex System Enviada em: segunda-feira, 6 de junho de 2011 22:08 Para: oracle_br@yahoogrupos.com.br Assunto: Re: [oracle_br] Re: DBWR lento Na real eu não queria saber realmente se o redolog deveria ser 50mb, 200mb, 2gb, ... foi levantado a hipótese aqui de que o problema de desempenho do banco era por problema de performance de IO nos discos onde estavam os redologs, então tentei levantar alguns dados para ver se não estava pecando em alguma configuração (antes de sair culpando o disk group que estão os redos) sds Fábio Gibon - Original Message - From: jljlsilva To: oracle_br@yahoogrupos.com.br Sent: Monday, June 06, 2011 4:40 PM Subject: [oracle_br] Re: DBWR lento portilho, legal suas observações. penso que o caminho é esse mesmo. eu imagino que as pessoas que colocam perguntas desse tipo que o fábio gibon colocou aqui nesse tópico, não tem informações suficientes sobre o assunto e precisam justamente desse tipo de comentário, sem exageros, mas direcionando, neste caso, sobre como calcular o que ele precisa. legal... valeu... --- Em oracle_br@yahoogrupos.com.br, Ricardo Portilho Proni ricardo.proni@... escreveu Oi. - Não importa o tamanho do banco, e sim o tamanho das gravações. Um banco de 1TB que só sofre SELECT não terá impacto em ter os pequenos Redo Logs padrão do Oracle (3 x 50MB); - Você deve ter Redo Logs suficientes (em tamanho e quantidade) para contar sua maior gravação concorrente. Veja neste exemplo, eu executo uma gravação de 250MB sem ter 250MB de Redo Log, e o tempo é prejudicado em mais de 100%. Após adicionar um único Redo Log de 1GB, tenho meu problema solucionado: http://profissionaloracle.com.br/blogs/portilho/2009/01/14/imp-lento-no-oracle/ - Você deve ter Redo Logs suficientes (em tamanho em quantidade) de forma que o Wait Event log file switch não ocupe um tempo relevante no período analisado. Se ele ocupa apenas 5% do seu tempo de banco, e você não precisa destes 5% de tempo, não precisa altera-los; - Redo Logs grandes não impactam o sistema por conta da geração de Archives grandes: se você está efetuando uma gravação de 100GB, o Oracle irá gerar 100GB (+ ou -) de Archives de qualquer forma, seja em pedaços de 100MB ou de 1GB; - Em um RAC de 8 Nós, teriam sido gastos alguns milhões de dólares só de licenças do Oracle. Neste cenário, 160GB de disco é irrelevante, este ambiente deve ter até mais de 160GB de RAM. Espero ter ajudado. Em Sáb, 2011-06-04 às 01:32 +, jljlsilva escreveu: chiappa, mas, vamos detalhar um pouco mais. o que é um banco de dados nanico prá vc? vc acha q um redolog muito grande não poderia causar problemas de performance no momento do arquivamento? afinal, não é toda empresa que tem storages de performance tão alta quanto gostaríamos. nunca precisei usar um membro de redolog de 2GB, até o momento. me parece q, como vc citou no final da sua explicação, vc usou como base níveis / volumes não triviais, o que precisaria de muito mais análise para se chegar a tal conclusão. entende porque me surpreendeu? até porque vc enfatiza com letras grandes como se o básico/mínimo fosse aquilo, via de regra. --- Em oracle_br@yahoogrupos.com.br, José Laurindo jlchiappa@ escreveu Então, seguinte : é Claro que a maneira Correta e precisa de especificar o redo log size no 10g é usar o Assistente apropriado, e é claro também que o redo log guarda alterações vindas de DML basicamente, então o tamanho apropriado depende Totalmente de quantas alterações simultâneas vc tem E o quanto elas 'alteram' , E também óbvio que podem existir bancos nanicos aonde o mínimo do mínimo tá mais que bão, mas eu penso aqui em produção plena, ambiente com criticidade, numa Empresa com muitos usuários, muitas alterações e centenas e centenas de Gb de dados, NÂO-ESTÁTICOS Nesse cenário não tem como eu chamar centena de Mbs de outra coisa que não anão, mínimo do mínimo , verticalmente prejudicado se vc quiser ser politicamente correto... Pra vc ter uma idéia , a nota oficial sobre isso (a
Re: RES: [oracle_br] Re: DBWR lento
fala Welvis. blz? aquela nota que o chiappa citou fala sobre isso: 781999.1 vc tem acesso ao metalink? se sim, dê uma olhada nessa nota. mas em resumo, a sugestão da nota é dimensionar os redologs para 20 minutos entre cada switch. On Jun 07, 2011, at 9:44 , wel...@stcruz.com.br wrote: Olá pessoal... Gostaria de saber se há alguma nota no metalink que diz se quanto em quanto tempo é um switch para um banco OLTP.. Eu costumo deixar/recomendar que os switchs sejam de pelo menos uns 10 minutos., claro dependendo do horário este número pode variar um pouco tanto para mais quanto para menos. Mas com toda esta discussão fiquei curioso sobre isso... Att, Welvis Douglas De: oracle_br@yahoogrupos.com.br [mailto:oracle_br@yahoogrupos.com.br] Em nome de Fábio Gibon - Comex System Enviada em: segunda-feira, 6 de junho de 2011 22:08 Para: oracle_br@yahoogrupos.com.br Assunto: Re: [oracle_br] Re: DBWR lento Na real eu não queria saber realmente se o redolog deveria ser 50mb, 200mb, 2gb, ... foi levantado a hipótese aqui de que o problema de desempenho do banco era por problema de performance de IO nos discos onde estavam os redologs, então tentei levantar alguns dados para ver se não estava pecando em alguma configuração (antes de sair culpando o disk group que estão os redos) sds Fábio Gibon - Original Message - From: jljlsilva To: oracle_br@yahoogrupos.com.br Sent: Monday, June 06, 2011 4:40 PM Subject: [oracle_br] Re: DBWR lento portilho, legal suas observações. penso que o caminho é esse mesmo. eu imagino que as pessoas que colocam perguntas desse tipo que o fábio gibon colocou aqui nesse tópico, não tem informações suficientes sobre o assunto e precisam justamente desse tipo de comentário, sem exageros, mas direcionando, neste caso, sobre como calcular o que ele precisa. legal... valeu... --- Em oracle_br@yahoogrupos.com.br, Ricardo Portilho Proni ricardo.proni@... escreveu Oi. - Não importa o tamanho do banco, e sim o tamanho das gravações. Um banco de 1TB que só sofre SELECT não terá impacto em ter os pequenos Redo Logs padrão do Oracle (3 x 50MB); - Você deve ter Redo Logs suficientes (em tamanho e quantidade) para contar sua maior gravação concorrente. Veja neste exemplo, eu executo uma gravação de 250MB sem ter 250MB de Redo Log, e o tempo é prejudicado em mais de 100%. Após adicionar um único Redo Log de 1GB, tenho meu problema solucionado: http://profissionaloracle.com.br/blogs/portilho/2009/01/14/imp-lento-no-oracle/ - Você deve ter Redo Logs suficientes (em tamanho em quantidade) de forma que o Wait Event log file switch não ocupe um tempo relevante no período analisado. Se ele ocupa apenas 5% do seu tempo de banco, e você não precisa destes 5% de tempo, não precisa altera-los; - Redo Logs grandes não impactam o sistema por conta da geração de Archives grandes: se você está efetuando uma gravação de 100GB, o Oracle irá gerar 100GB (+ ou -) de Archives de qualquer forma, seja em pedaços de 100MB ou de 1GB; - Em um RAC de 8 Nós, teriam sido gastos alguns milhões de dólares só de licenças do Oracle. Neste cenário, 160GB de disco é irrelevante, este ambiente deve ter até mais de 160GB de RAM. Espero ter ajudado. Em Sáb, 2011-06-04 às 01:32 +, jljlsilva escreveu: chiappa, mas, vamos detalhar um pouco mais. o que é um banco de dados nanico prá vc? vc acha q um redolog muito grande não poderia causar problemas de performance no momento do arquivamento? afinal, não é toda empresa que tem storages de performance tão alta quanto gostaríamos. nunca precisei usar um membro de redolog de 2GB, até o momento. me parece q, como vc citou no final da sua explicação, vc usou como base níveis / volumes não triviais, o que precisaria de muito mais análise para se chegar a tal conclusão. entende porque me surpreendeu? até porque vc enfatiza com letras grandes como se o básico/mínimo fosse aquilo, via de regra. --- Em oracle_br@yahoogrupos.com.br, José Laurindo jlchiappa@ escreveu Então, seguinte : é Claro que a maneira Correta e precisa de especificar o redo log size no 10g é usar o Assistente apropriado, e é claro também que o redo log guarda alterações vindas de DML basicamente, então o tamanho apropriado depende Totalmente de quantas alterações simultâneas vc tem E o quanto elas 'alteram' , E também óbvio que podem existir bancos nanicos aonde o mínimo do mínimo tá mais que bão, mas eu penso aqui em produção plena, ambiente com criticidade, numa Empresa com muitos usuários, muitas alterações e centenas e centenas de Gb de dados, NÂO-ESTÁTICOS Nesse cenário não tem como eu chamar centena de Mbs de outra coisa que não anão, mínimo do mínimo , verticalmente prejudicado se vc quiser ser politicamente correto... Pra vc ter uma idéia , a nota oficial sobre isso (a General Guideline For Sizing The Online Redo Log Files (Doc ID 781999.1), acessível no metalink) diz : 'An excerpt from
RES: RES: [oracle_br] Re: DBWR lento
Boa, eu havia guardado em minhas anotações.. Mas não havia lido a nota... Valeu pala ajuda Silva.. Abraço! De: oracle_br@yahoogrupos.com.br [mailto:oracle_br@yahoogrupos.com.br] Em nome de JLSilva Enviada em: terça-feira, 7 de junho de 2011 10:01 Para: oracle_br@yahoogrupos.com.br Assunto: Re: RES: [oracle_br] Re: DBWR lento fala Welvis. blz? aquela nota que o chiappa citou fala sobre isso: 781999.1 vc tem acesso ao metalink? se sim, dê uma olhada nessa nota. mas em resumo, a sugestão da nota é dimensionar os redologs para 20 minutos entre cada switch. On Jun 07, 2011, at 9:44 , wel...@stcruz.com.br wrote: Olá pessoal... Gostaria de saber se há alguma nota no metalink que diz se quanto em quanto tempo é um switch para um banco OLTP.. Eu costumo deixar/recomendar que os switchs sejam de pelo menos uns 10 minutos., claro dependendo do horário este número pode variar um pouco tanto para mais quanto para menos. Mas com toda esta discussão fiquei curioso sobre isso... Att, Welvis Douglas De: oracle_br@yahoogrupos.com.br [mailto:oracle_br@yahoogrupos.com.br] Em nome de Fábio Gibon - Comex System Enviada em: segunda-feira, 6 de junho de 2011 22:08 Para: oracle_br@yahoogrupos.com.br Assunto: Re: [oracle_br] Re: DBWR lento Na real eu não queria saber realmente se o redolog deveria ser 50mb, 200mb, 2gb, ... foi levantado a hipótese aqui de que o problema de desempenho do banco era por problema de performance de IO nos discos onde estavam os redologs, então tentei levantar alguns dados para ver se não estava pecando em alguma configuração (antes de sair culpando o disk group que estão os redos) sds Fábio Gibon - Original Message - From: jljlsilva To: oracle_br@yahoogrupos.com.br Sent: Monday, June 06, 2011 4:40 PM Subject: [oracle_br] Re: DBWR lento portilho, legal suas observações. penso que o caminho é esse mesmo. eu imagino que as pessoas que colocam perguntas desse tipo que o fábio gibon colocou aqui nesse tópico, não tem informações suficientes sobre o assunto e precisam justamente desse tipo de comentário, sem exageros, mas direcionando, neste caso, sobre como calcular o que ele precisa. legal... valeu... --- Em oracle_br@yahoogrupos.com.br, Ricardo Portilho Proni ricardo.proni@... escreveu Oi. - Não importa o tamanho do banco, e sim o tamanho das gravações. Um banco de 1TB que só sofre SELECT não terá impacto em ter os pequenos Redo Logs padrão do Oracle (3 x 50MB); - Você deve ter Redo Logs suficientes (em tamanho e quantidade) para contar sua maior gravação concorrente. Veja neste exemplo, eu executo uma gravação de 250MB sem ter 250MB de Redo Log, e o tempo é prejudicado em mais de 100%. Após adicionar um único Redo Log de 1GB, tenho meu problema solucionado: http://profissionaloracle.com.br/blogs/portilho/2009/01/14/imp-lento-no-oracle/ - Você deve ter Redo Logs suficientes (em tamanho em quantidade) de forma que o Wait Event log file switch não ocupe um tempo relevante no período analisado. Se ele ocupa apenas 5% do seu tempo de banco, e você não precisa destes 5% de tempo, não precisa altera-los; - Redo Logs grandes não impactam o sistema por conta da geração de Archives grandes: se você está efetuando uma gravação de 100GB, o Oracle irá gerar 100GB (+ ou -) de Archives de qualquer forma, seja em pedaços de 100MB ou de 1GB; - Em um RAC de 8 Nós, teriam sido gastos alguns milhões de dólares só de licenças do Oracle. Neste cenário, 160GB de disco é irrelevante, este ambiente deve ter até mais de 160GB de RAM. Espero ter ajudado. Em Sáb, 2011-06-04 às 01:32 +, jljlsilva escreveu: chiappa, mas, vamos detalhar um pouco mais. o que é um banco de dados nanico prá vc? vc acha q um redolog muito grande não poderia causar problemas de performance no momento do arquivamento? afinal, não é toda empresa que tem storages de performance tão alta quanto gostaríamos. nunca precisei usar um membro de redolog de 2GB, até o momento. me parece q, como vc citou no final da sua explicação, vc usou como base níveis / volumes não triviais, o que precisaria de muito mais análise para se chegar a tal conclusão. entende porque me surpreendeu? até porque vc enfatiza com letras grandes como se o básico/mínimo fosse aquilo, via de regra. --- Em oracle_br@yahoogrupos.com.br, José Laurindo jlchiappa@ escreveu Então, seguinte : é Claro que a maneira Correta e precisa de especificar o redo log size no 10g é usar o Assistente apropriado, e é claro também que o redo log guarda alterações vindas de DML basicamente, então o tamanho apropriado depende Totalmente de quantas alterações simultâneas vc tem E o quanto elas 'alteram' , E também óbvio que podem existir bancos nanicos aonde o mínimo do mínimo tá mais que bão, mas eu penso aqui em produção plena, ambiente com criticidade, numa Empresa com muitos usuários, muitas alterações e centenas e centenas de Gb de dados, NÂO-ESTÁTICOS Nesse cenário não tem como eu chamar
Re: RES: [oracle_br] Re: DBWR lento
Achei o link da documentação. http://download.oracle.com/docs/cd/B19306_01/server.102/b14211/build_db.htm#i19558 Abraço Att. Marcelo Procksch Em 7 de junho de 2011 10:06, wel...@stcruz.com.br escreveu: Boa, eu havia guardado em minhas anotações.. Mas não havia lido a nota... Valeu pala ajuda Silva.. Abraço! De: oracle_br@yahoogrupos.com.br [mailto:oracle_br@yahoogrupos.com.br] Em nome de JLSilva Enviada em: terça-feira, 7 de junho de 2011 10:01 Para: oracle_br@yahoogrupos.com.br Assunto: Re: RES: [oracle_br] Re: DBWR lento fala Welvis. blz? aquela nota que o chiappa citou fala sobre isso: 781999.1 vc tem acesso ao metalink? se sim, dê uma olhada nessa nota. mas em resumo, a sugestão da nota é dimensionar os redologs para 20 minutos entre cada switch. On Jun 07, 2011, at 9:44 , wel...@stcruz.com.br wrote: Olá pessoal... Gostaria de saber se há alguma nota no metalink que diz se quanto em quanto tempo é um switch para um banco OLTP.. Eu costumo deixar/recomendar que os switchs sejam de pelo menos uns 10 minutos., claro dependendo do horário este número pode variar um pouco tanto para mais quanto para menos. Mas com toda esta discussão fiquei curioso sobre isso... Att, Welvis Douglas De: oracle_br@yahoogrupos.com.br [mailto:oracle_br@yahoogrupos.com.br] Em nome de Fábio Gibon - Comex System Enviada em: segunda-feira, 6 de junho de 2011 22:08 Para: oracle_br@yahoogrupos.com.br Assunto: Re: [oracle_br] Re: DBWR lento Na real eu não queria saber realmente se o redolog deveria ser 50mb, 200mb, 2gb, ... foi levantado a hipótese aqui de que o problema de desempenho do banco era por problema de performance de IO nos discos onde estavam os redologs, então tentei levantar alguns dados para ver se não estava pecando em alguma configuração (antes de sair culpando o disk group que estão os redos) sds Fábio Gibon - Original Message - From: jljlsilva To: oracle_br@yahoogrupos.com.br Sent: Monday, June 06, 2011 4:40 PM Subject: [oracle_br] Re: DBWR lento portilho, legal suas observações. penso que o caminho é esse mesmo. eu imagino que as pessoas que colocam perguntas desse tipo que o fábio gibon colocou aqui nesse tópico, não tem informações suficientes sobre o assunto e precisam justamente desse tipo de comentário, sem exageros, mas direcionando, neste caso, sobre como calcular o que ele precisa. legal... valeu... --- Em oracle_br@yahoogrupos.com.br, Ricardo Portilho Proni ricardo.proni@... escreveu Oi. - Não importa o tamanho do banco, e sim o tamanho das gravações. Um banco de 1TB que só sofre SELECT não terá impacto em ter os pequenos Redo Logs padrão do Oracle (3 x 50MB); - Você deve ter Redo Logs suficientes (em tamanho e quantidade) para contar sua maior gravação concorrente. Veja neste exemplo, eu executo uma gravação de 250MB sem ter 250MB de Redo Log, e o tempo é prejudicado em mais de 100%. Após adicionar um único Redo Log de 1GB, tenho meu problema solucionado: http://profissionaloracle.com.br/blogs/portilho/2009/01/14/imp-lento-no-oracle/ - Você deve ter Redo Logs suficientes (em tamanho em quantidade) de forma que o Wait Event log file switch não ocupe um tempo relevante no período analisado. Se ele ocupa apenas 5% do seu tempo de banco, e você não precisa destes 5% de tempo, não precisa altera-los; - Redo Logs grandes não impactam o sistema por conta da geração de Archives grandes: se você está efetuando uma gravação de 100GB, o Oracle irá gerar 100GB (+ ou -) de Archives de qualquer forma, seja em pedaços de 100MB ou de 1GB; - Em um RAC de 8 Nós, teriam sido gastos alguns milhões de dólares só de licenças do Oracle. Neste cenário, 160GB de disco é irrelevante, este ambiente deve ter até mais de 160GB de RAM. Espero ter ajudado. Em Sáb, 2011-06-04 às 01:32 +, jljlsilva escreveu: chiappa, mas, vamos detalhar um pouco mais. o que é um banco de dados nanico prá vc? vc acha q um redolog muito grande não poderia causar problemas de performance no momento do arquivamento? afinal, não é toda empresa que tem storages de performance tão alta quanto gostaríamos. nunca precisei usar um membro de redolog de 2GB, até o momento. me parece q, como vc citou no final da sua explicação, vc usou como base níveis / volumes não triviais, o que precisaria de muito mais análise para se chegar a tal conclusão. entende porque me surpreendeu? até porque vc enfatiza com letras grandes como se o básico/mínimo fosse aquilo, via de regra. --- Em oracle_br@yahoogrupos.com.br, José Laurindo jlchiappa@ escreveu Então, seguinte : é Claro que a maneira Correta e precisa de especificar o redo log size no 10g é usar o Assistente apropriado, e é claro também que o redo log guarda alterações vindas de DML basicamente, então o tamanho apropriado depende Totalmente de quantas alterações simultâneas vc tem E o
Re: RES: [oracle_br] Re: DBWR lento
marcelo, esse tópico da doc foi muito bom. valeu pela dica. JLSilva On Jun 07, 2011, at 10:12 , Marcelo Procksch wrote: Achei o link da documentação. http://download.oracle.com/docs/cd/B19306_01/server.102/b14211/build_db.htm#i19558 Abraço Att. Marcelo Procksch Em 7 de junho de 2011 10:06, wel...@stcruz.com.br escreveu: Boa, eu havia guardado em minhas anotações.. Mas não havia lido a nota... Valeu pala ajuda Silva.. Abraço! De: oracle_br@yahoogrupos.com.br [mailto:oracle_br@yahoogrupos.com.br] Em nome de JLSilva Enviada em: terça-feira, 7 de junho de 2011 10:01 Para: oracle_br@yahoogrupos.com.br Assunto: Re: RES: [oracle_br] Re: DBWR lento fala Welvis. blz? aquela nota que o chiappa citou fala sobre isso: 781999.1 vc tem acesso ao metalink? se sim, dê uma olhada nessa nota. mas em resumo, a sugestão da nota é dimensionar os redologs para 20 minutos entre cada switch. On Jun 07, 2011, at 9:44 , wel...@stcruz.com.br wrote: Olá pessoal... Gostaria de saber se há alguma nota no metalink que diz se quanto em quanto tempo é um switch para um banco OLTP.. Eu costumo deixar/recomendar que os switchs sejam de pelo menos uns 10 minutos., claro dependendo do horário este número pode variar um pouco tanto para mais quanto para menos. Mas com toda esta discussão fiquei curioso sobre isso... Att, Welvis Douglas De: oracle_br@yahoogrupos.com.br [mailto:oracle_br@yahoogrupos.com.br] Em nome de Fábio Gibon - Comex System Enviada em: segunda-feira, 6 de junho de 2011 22:08 Para: oracle_br@yahoogrupos.com.br Assunto: Re: [oracle_br] Re: DBWR lento Na real eu não queria saber realmente se o redolog deveria ser 50mb, 200mb, 2gb, ... foi levantado a hipótese aqui de que o problema de desempenho do banco era por problema de performance de IO nos discos onde estavam os redologs, então tentei levantar alguns dados para ver se não estava pecando em alguma configuração (antes de sair culpando o disk group que estão os redos) sds Fábio Gibon - Original Message - From: jljlsilva To: oracle_br@yahoogrupos.com.br Sent: Monday, June 06, 2011 4:40 PM Subject: [oracle_br] Re: DBWR lento portilho, legal suas observações. penso que o caminho é esse mesmo. eu imagino que as pessoas que colocam perguntas desse tipo que o fábio gibon colocou aqui nesse tópico, não tem informações suficientes sobre o assunto e precisam justamente desse tipo de comentário, sem exageros, mas direcionando, neste caso, sobre como calcular o que ele precisa. legal... valeu... --- Em oracle_br@yahoogrupos.com.br, Ricardo Portilho Proni ricardo.proni@... escreveu Oi. - Não importa o tamanho do banco, e sim o tamanho das gravações. Um banco de 1TB que só sofre SELECT não terá impacto em ter os pequenos Redo Logs padrão do Oracle (3 x 50MB); - Você deve ter Redo Logs suficientes (em tamanho e quantidade) para contar sua maior gravação concorrente. Veja neste exemplo, eu executo uma gravação de 250MB sem ter 250MB de Redo Log, e o tempo é prejudicado em mais de 100%. Após adicionar um único Redo Log de 1GB, tenho meu problema solucionado: http://profissionaloracle.com.br/blogs/portilho/2009/01/14/imp-lento-no-oracle/ - Você deve ter Redo Logs suficientes (em tamanho em quantidade) de forma que o Wait Event log file switch não ocupe um tempo relevante no período analisado. Se ele ocupa apenas 5% do seu tempo de banco, e você não precisa destes 5% de tempo, não precisa altera-los; - Redo Logs grandes não impactam o sistema por conta da geração de Archives grandes: se você está efetuando uma gravação de 100GB, o Oracle irá gerar 100GB (+ ou -) de Archives de qualquer forma, seja em pedaços de 100MB ou de 1GB; - Em um RAC de 8 Nós, teriam sido gastos alguns milhões de dólares só de licenças do Oracle. Neste cenário, 160GB de disco é irrelevante, este ambiente deve ter até mais de 160GB de RAM. Espero ter ajudado. Em Sáb, 2011-06-04 às 01:32 +, jljlsilva escreveu: chiappa, mas, vamos detalhar um pouco mais. o que é um banco de dados nanico prá vc? vc acha q um redolog muito grande não poderia causar problemas de performance no momento do arquivamento? afinal, não é toda empresa que tem storages de performance tão alta quanto gostaríamos. nunca precisei usar um membro de redolog de 2GB, até o momento. me parece q, como vc citou no final da sua explicação, vc usou como base níveis / volumes não triviais, o que precisaria de muito mais análise para se chegar a tal conclusão. entende porque me surpreendeu? até porque vc enfatiza com letras grandes como se o básico/mínimo fosse aquilo, via de regra. --- Em oracle_br@yahoogrupos.com.br, José Laurindo jlchiappa@ escreveu Então, seguinte : é Claro que a maneira Correta e precisa de especificar o redo log size no 10g é usar o Assistente apropriado, e é claro também que o redo log guarda alterações vindas de DML basicamente, então o tamanho apropriado
Re: [oracle_br] Re: Oracle Database Express Edition
Nesse contexto você pode usar o oracle 11G versão XE.Com algumas features do 11g mas nada tão avançado mas se eu não me engano quanto a espaço estar maior! Emerson Martins Analista de Banco de Dados Itec/AL 82 9123-5504 82 9668-1283 Em 7 de junho de 2011 07:31, José Laurindo jlchia...@yahoo.com.brescreveu: Sim, vc está absolutamente correto, vc pode embutir o XE no seu aplicativo, redistribui-lo a seus clientes, sem prob algum, e não há nenhuma restrição quanto ao seu Aplicativo ser desenvolvido em qual linguagem for, em qual SO que for, em qual ambiente (client/server ou web), nem em relação ao número de usuários, nem nada assim... Apenas fique ciente que, Além das severas restrições de espaço e processamento vc : a) absolutamente *** NÃO *** vai ter o menor Suporte da Oracle, nunca, ou seja : deu um erro ORA-600 por causa de um bug, digamos, vc tá por sua conta... Idem se vc precisar de um patch pra resolver alguma questão de Segurança, ou de Usabilidade (tipo alguma feature que quebra em determinados momentos , talvez de pico de uso) ... b) vc NÃO vai ter direito de usar no seu Aplicativo *** muitas *** features do banco que por vezes poderiam ser Cruciais para performance/administração/usabilidade, tais como Particionamento, rotinas Java dentro do banco, Assistentes de configuração/performance, alguns itens de encriptação de dados, enter Vários outros... c) não é para todos os Sistemas Operacionais que a Oracle suporta o database que vc tem versão do XE, é basicamente pro Linux e pro Windows , ambos 32-bits : TODOS os seus Clientes que quiserem usar algum servidor UNIX, por exemplo (que já possuam, digamos) tão fora, e quem tiver Windows ou Linux de 64 bits vai ter que gambiarrar e rodar em modo de Compatibilidade : dado o tamanhinho de nada máximo do XE, isso via de regra não é impedimento, MAS saiba que a issue Existe, isso Pode ter dar problemas... Se NADA disso te perturba, go ahead... []s Chiappa --- Em oracle_br@yahoogrupos.com.br, lcgr_rib luiz.ribeiro@... escreveu Olá amigos. Na licença de uso do OracleXE, li (e interpretei) que posso distribuir minha aplicação juntamente com o Oracle Express Edition. Segue abaixo: License Rights We grant you a nonexclusive, nontransferable limited license to use the programs for: (a) purposes of developing, prototyping and running your applications for your own internal data processing operations; (b) you may also distribute the programs with your applications; (c) you may use the programs to provide third party demonstrations and training; and d) you may copy and distribute the programs to your licensees provided that each such licensee agrees to the terms of this Agreement. You are not permitted to use the programs for any purpose other than as permitted under this Agreement. Program documentation is either shipped with the programs, or documentation may accessed online at http://www.oracle.com/technology/documentation/ . Gostaria de saber se minha interpretação está correta, ou seja, posso vender minha aplicação e junto com ela fornecer o OracleXE para o cliente? Existe alguma restrição quanto a plataforma de desenvolvimento ou linguagem de programação? Tenho conhecimento dos limites de espaço, processamento e memória do OracleXE. É que para pequenas empresas, fica complicado investir direto num Database Enterprise, por exemplo. Muito obrigado. [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 * Para visitar o site do seu grupo na web, acesse: http://br.groups.yahoo.com/group/oracle_br/ * Para sair deste grupo, envie um e-mail para: oracle_br-unsubscr...@yahoogrupos.com.br * O uso que você faz do Yahoo! Grupos está sujeito aos: http://br.yahoo.com/info/utos.html
Re: [oracle_br] Re: Oracle Database Express Edition
Só lembrando que o 11g XE ainda está em beta. 2011/6/7 Emerson Martins emersonmarti...@gmail.com: Nesse contexto você pode usar o oracle 11G versão XE.Com algumas features do 11g mas nada tão avançado mas se eu não me engano quanto a espaço estar maior! Emerson Martins Analista de Banco de Dados Itec/AL 82 9123-5504 82 9668-1283 Em 7 de junho de 2011 07:31, José Laurindo jlchia...@yahoo.com.brescreveu: Sim, vc está absolutamente correto, vc pode embutir o XE no seu aplicativo, redistribui-lo a seus clientes, sem prob algum, e não há nenhuma restrição quanto ao seu Aplicativo ser desenvolvido em qual linguagem for, em qual SO que for, em qual ambiente (client/server ou web), nem em relação ao número de usuários, nem nada assim... Apenas fique ciente que, Além das severas restrições de espaço e processamento vc : a) absolutamente *** NÃO *** vai ter o menor Suporte da Oracle, nunca, ou seja : deu um erro ORA-600 por causa de um bug, digamos, vc tá por sua conta... Idem se vc precisar de um patch pra resolver alguma questão de Segurança, ou de Usabilidade (tipo alguma feature que quebra em determinados momentos , talvez de pico de uso) ... b) vc NÃO vai ter direito de usar no seu Aplicativo *** muitas *** features do banco que por vezes poderiam ser Cruciais para performance/administração/usabilidade, tais como Particionamento, rotinas Java dentro do banco, Assistentes de configuração/performance, alguns itens de encriptação de dados, enter Vários outros... c) não é para todos os Sistemas Operacionais que a Oracle suporta o database que vc tem versão do XE, é basicamente pro Linux e pro Windows , ambos 32-bits : TODOS os seus Clientes que quiserem usar algum servidor UNIX, por exemplo (que já possuam, digamos) tão fora, e quem tiver Windows ou Linux de 64 bits vai ter que gambiarrar e rodar em modo de Compatibilidade : dado o tamanhinho de nada máximo do XE, isso via de regra não é impedimento, MAS saiba que a issue Existe, isso Pode ter dar problemas... Se NADA disso te perturba, go ahead... []s Chiappa --- Em oracle_br@yahoogrupos.com.br, lcgr_rib luiz.ribeiro@... escreveu Olá amigos. Na licença de uso do OracleXE, li (e interpretei) que posso distribuir minha aplicação juntamente com o Oracle Express Edition. Segue abaixo: License Rights We grant you a nonexclusive, nontransferable limited license to use the programs for: (a) purposes of developing, prototyping and running your applications for your own internal data processing operations; (b) you may also distribute the programs with your applications; (c) you may use the programs to provide third party demonstrations and training; and d) you may copy and distribute the programs to your licensees provided that each such licensee agrees to the terms of this Agreement. You are not permitted to use the programs for any purpose other than as permitted under this Agreement. Program documentation is either shipped with the programs, or documentation may accessed online at http://www.oracle.com/technology/documentation/ . Gostaria de saber se minha interpretação está correta, ou seja, posso vender minha aplicação e junto com ela fornecer o OracleXE para o cliente? Existe alguma restrição quanto a plataforma de desenvolvimento ou linguagem de programação? Tenho conhecimento dos limites de espaço, processamento e memória do OracleXE. É que para pequenas empresas, fica complicado investir direto num Database Enterprise, por exemplo. Muito obrigado. [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 -- Rosivaldo Azevedo Ramalho rosiva...@gmail.com Consultor Oracle Database Fusion Middlerware http://about.me/rosivaldo
[oracle_br] Criação de Script - Coelta de Estatisticas
Bom dia colegas,
Estou refazendo alguns script antigos, quanto a coleta de estatisticas e estou
tendo alguma dificuldade para criar um unico script, com a devida passagem de
parametros relacionada aos owners que possuo...
Irei fazer uma criação de histogramas diaria (20%) e no sabado, uma coelta full
de estatisticas...
A idéia seria a seguinte...
begin
cursor_username in (select distinct (username)
from dba_users
where lower(username) not in ('apex_public_user',
'flows_03',
'flows_files',
'owbsys',
'spatial_csw_admin_usr',
'spatial_wfs_admin_usr',
'wkproxy',
'wksys',
'wk_test',
'xs$null',
'si_informmtn_schema',
'scott',
'oracle_ocm',
'dip',
'outln',
'mgmt_view',
'tsmsys',
'ix',
'anonymous',
'sysman',
'mdsys',
'sys',
'system',
'xdb',
'dbsnmp',
'olapsys',
'oe',
'wmsys',
'xdb',
'dmsys',
'ordplugins',
'ordsys',
'wmsys',
'exfsys',
'ctxsys',
'home',
'hs',
'si_informtn_schema',
'mddata',
'ora_xp_auditoria')
order by username)
EXEC DBMS_STATS.GATHER_SCHEMA_STATS('cursor_username',ESTIMATE_PERCENT = 20,
METHOD_OPT ='FOR ALL COLUMNS SIZE AUTO', DEGREE = 4, CASCADE = TRUE);
end;
/
Mas não esta rolando...alguem tem alguma sugestão ou ideiá ? Senão terei que
criar linha a linha para todos os schemas que possuo...
Obrigadão
RES: [oracle_br] Criação de Script - Coelta de Estatisticas
Bom dia...
Olha, acho que não é por ai
Você está tentando coletar estatística de todos os usuários do banco de
dados. Veja bem, tem objetos no banco de dados Oracle que não se pode
alterar as estatísticas..
Neste caso, recomendo você a coletar apenas de seu usuário de produção,
onde roda seu ERP. Agora, vc pode também coletar as estatísticas do
usuário SYS, vi alguma coisa na documentação a respeito..
Agora de tudo, acho desnecessário..
E outra, isso é um número estimado.. tipo 20%, a algum tempo, o Chiappa
colocou uns scripts aqui no forum, onde ele dividia entre tabelas
pequenas, médias e grande.. e coletava de forma diferente para cada uma
delas...
O que você precisa fazer? Qual Sua idéia? Qual banco versão? Qual SO...
Abraço!
De: oracle_br@yahoogrupos.com.br [mailto:oracle_br@yahoogrupos.com.br] Em
nome de candiurudba
Enviada em: terça-feira, 7 de junho de 2011 11:37
Para: oracle_br@yahoogrupos.com.br
Assunto: [oracle_br] Criação de Script - Coelta de Estatisticas
Bom dia colegas,
Estou refazendo alguns script antigos, quanto a coleta de estatisticas e
estou tendo alguma dificuldade para criar um unico script, com a devida
passagem de parametros relacionada aos owners que possuo...
Irei fazer uma criação de histogramas diaria (20%) e no sabado, uma coelta
full de estatisticas...
A idéia seria a seguinte...
begin
cursor_username in (select distinct (username)
from dba_users
where lower(username) not in ('apex_public_user',
'flows_03',
'flows_files',
'owbsys',
'spatial_csw_admin_usr',
'spatial_wfs_admin_usr',
'wkproxy',
'wksys',
'wk_test',
'xs$null',
'si_informmtn_schema',
'scott',
'oracle_ocm',
'dip',
'outln',
'mgmt_view',
'tsmsys',
'ix',
'anonymous',
'sysman',
'mdsys',
'sys',
'system',
'xdb',
'dbsnmp',
'olapsys',
'oe',
'wmsys',
'xdb',
'dmsys',
'ordplugins',
'ordsys',
'wmsys',
'exfsys',
'ctxsys',
'home',
'hs',
'si_informtn_schema',
'mddata',
'ora_xp_auditoria')
order by username)
EXEC DBMS_STATS.GATHER_SCHEMA_STATS('cursor_username',ESTIMATE_PERCENT =
20, METHOD_OPT ='FOR ALL COLUMNS SIZE AUTO', DEGREE = 4, CASCADE =
TRUE);
end;
/
Mas não esta rolando...alguem tem alguma sugestão ou ideiá ? Senão terei
que criar linha a linha para todos os schemas que possuo...
Obrigadão
Re: [oracle_br] Criação de Script - Coelta de Estatisticas
carandiuruba vc poderia enviar o bloco plsql completo, exatamente como está
escrito?
quando vc diz q não tá rolando, vc se refere a algum erro? se sim, qual erro?
On Jun 07, 2011, at 11:37 , candiurudba wrote:
Bom dia colegas,
Estou refazendo alguns script antigos, quanto a coleta de estatisticas e
estou tendo alguma dificuldade para criar um unico script, com a devida
passagem de parametros relacionada aos owners que possuo...
Irei fazer uma criação de histogramas diaria (20%) e no sabado, uma coelta
full de estatisticas...
A idéia seria a seguinte...
begin
cursor_username in (select distinct (username)
from dba_users
where lower(username) not in ('apex_public_user',
'flows_03',
'flows_files',
'owbsys',
'spatial_csw_admin_usr',
'spatial_wfs_admin_usr',
'wkproxy',
'wksys',
'wk_test',
'xs$null',
'si_informmtn_schema',
'scott',
'oracle_ocm',
'dip',
'outln',
'mgmt_view',
'tsmsys',
'ix',
'anonymous',
'sysman',
'mdsys',
'sys',
'system',
'xdb',
'dbsnmp',
'olapsys',
'oe',
'wmsys',
'xdb',
'dmsys',
'ordplugins',
'ordsys',
'wmsys',
'exfsys',
'ctxsys',
'home',
'hs',
'si_informtn_schema',
'mddata',
'ora_xp_auditoria')
order by username)
EXEC DBMS_STATS.GATHER_SCHEMA_STATS('cursor_username',ESTIMATE_PERCENT = 20,
METHOD_OPT ='FOR ALL COLUMNS SIZE AUTO', DEGREE = 4, CASCADE = TRUE);
end;
/
Mas não esta rolando...alguem tem alguma sugestão ou ideiá ? Senão terei que
criar linha a linha para todos os schemas que possuo...
Obrigadão
--
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
RES: [oracle_br] Criação de Script - Coelta de Estatisticas
Pode ser que a coleta de estatistica estaja bloqueada para alguns usuários..
Att,
Welvis
De: oracle_br@yahoogrupos.com.br [mailto:oracle_br@yahoogrupos.com.br] Em
nome de JLSilva
Enviada em: terça-feira, 7 de junho de 2011 11:50
Para: oracle_br@yahoogrupos.com.br
Assunto: Re: [oracle_br] Criação de Script - Coelta de Estatisticas
carandiuruba vc poderia enviar o bloco plsql completo, exatamente como
está escrito?
quando vc diz q não tá rolando, vc se refere a algum erro? se sim, qual erro?
On Jun 07, 2011, at 11:37 , candiurudba wrote:
Bom dia colegas,
Estou refazendo alguns script antigos, quanto a coleta de estatisticas e
estou tendo alguma dificuldade para criar um unico script, com a devida
passagem de parametros relacionada aos owners que possuo...
Irei fazer uma criação de histogramas diaria (20%) e no sabado, uma
coelta full de estatisticas...
A idéia seria a seguinte...
begin
cursor_username in (select distinct (username)
from dba_users
where lower(username) not in ('apex_public_user',
'flows_03',
'flows_files',
'owbsys',
'spatial_csw_admin_usr',
'spatial_wfs_admin_usr',
'wkproxy',
'wksys',
'wk_test',
'xs$null',
'si_informmtn_schema',
'scott',
'oracle_ocm',
'dip',
'outln',
'mgmt_view',
'tsmsys',
'ix',
'anonymous',
'sysman',
'mdsys',
'sys',
'system',
'xdb',
'dbsnmp',
'olapsys',
'oe',
'wmsys',
'xdb',
'dmsys',
'ordplugins',
'ordsys',
'wmsys',
'exfsys',
'ctxsys',
'home',
'hs',
'si_informtn_schema',
'mddata',
'ora_xp_auditoria')
order by username)
EXEC DBMS_STATS.GATHER_SCHEMA_STATS('cursor_username',ESTIMATE_PERCENT
= 20, METHOD_OPT ='FOR ALL COLUMNS SIZE AUTO', DEGREE = 4, CASCADE =
TRUE);
end;
/
Mas não esta rolando...alguem tem alguma sugestão ou ideiá ? Senão terei
que criar linha a linha para todos os schemas que possuo...
Obrigadão
--
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
Re: RES: [oracle_br] Criação de Script - Coelta de Estatisticas
Amigo, utilizo assim, veja se te ajuda e/ou altere para seu ambiente
declare
cursor cr is
select d.owner,d.object_name,d.object_type
from dba_objects d
where d.owner not in
('XDB','OUTLN','WMSYS','PUBLIC','SYS','SYSTEM','OUTLN','DBSNMP','TRACESVR','SCOTT','AURORA$ORB$UNAUTHENTICATED','WMSYS','MDSYS','EXFSYS','SYSMAN','TSMSYS','ORDSYS','DMSYS','CTXSYS','OLAPSYS','WKSYS','FLOWS_FILES','FLOWS_010500','WK_TEST')
and d.object_type in ('TABLE')
and d.object_name not like 'BIN$%';
VCOMANDO VARCHAR2(255);
begin
for r in cr loop
VCOMANDO := 'begin
dbms_stats.gather_table_stats('''||r.owner||''','''||r.object_name||''',cascade=
true);end;';
EXECUTE IMMEDIATE VCOMANDO;
commit;
end loop;
end;
De: wel...@stcruz.com.br wel...@stcruz.com.br
Para: oracle_br@yahoogrupos.com.br
Enviadas: Terça-feira, 7 de Junho de 2011 11:47
Assunto: RES: [oracle_br] Criação de Script - Coelta de Estatisticas
Bom dia...
Olha, acho que não é por ai
Você está tentando coletar estatística de todos os usuários do banco de
dados. Veja bem, tem objetos no banco de dados Oracle que não se pode
alterar as estatísticas..
Neste caso, recomendo você a coletar apenas de seu usuário de produção,
onde roda seu ERP. Agora, vc pode também coletar as estatísticas do
usuário SYS, vi alguma coisa na documentação a respeito..
Agora de tudo, acho desnecessário..
E outra, isso é um número estimado.. tipo 20%, a algum tempo, o Chiappa
colocou uns scripts aqui no forum, onde ele dividia entre tabelas
pequenas, médias e grande.. e coletava de forma diferente para cada uma
delas...
O que você precisa fazer? Qual Sua idéia? Qual banco versão? Qual SO...
Abraço!
De: oracle_br@yahoogrupos.com.br [mailto:oracle_br@yahoogrupos.com.br] Em
nome de candiurudba
Enviada em: terça-feira, 7 de junho de 2011 11:37
Para: oracle_br@yahoogrupos.com.br
Assunto: [oracle_br] Criação de Script - Coelta de Estatisticas
Bom dia colegas,
Estou refazendo alguns script antigos, quanto a coleta de estatisticas e
estou tendo alguma dificuldade para criar um unico script, com a devida
passagem de parametros relacionada aos owners que possuo...
Irei fazer uma criação de histogramas diaria (20%) e no sabado, uma coelta
full de estatisticas...
A idéia seria a seguinte...
begin
cursor_username in (select distinct (username)
from dba_users
where lower(username) not in ('apex_public_user',
'flows_03',
'flows_files',
'owbsys',
'spatial_csw_admin_usr',
'spatial_wfs_admin_usr',
'wkproxy',
'wksys',
'wk_test',
'xs$null',
'si_informmtn_schema',
'scott',
'oracle_ocm',
'dip',
'outln',
'mgmt_view',
'tsmsys',
'ix',
'anonymous',
'sysman',
'mdsys',
'sys',
'system',
'xdb',
'dbsnmp',
'olapsys',
'oe',
'wmsys',
'xdb',
'dmsys',
'ordplugins',
'ordsys',
'wmsys',
'exfsys',
'ctxsys',
'home',
'hs',
'si_informtn_schema',
'mddata',
'ora_xp_auditoria')
order by username)
EXEC DBMS_STATS.GATHER_SCHEMA_STATS('cursor_username',ESTIMATE_PERCENT =
20, METHOD_OPT ='FOR ALL COLUMNS SIZE AUTO', DEGREE = 4, CASCADE =
TRUE);
end;
/
Mas não esta rolando...alguem tem alguma sugestão ou ideiá ? Senão terei
que criar linha a linha para todos os schemas que possuo...
Obrigadão
[As partes desta mensagem que não continham texto foram removidas]
Res: Re: RES: [oracle_br] Re: DBWR lento
Eu respeitosamente discordo da métrica, pois ela nao eh absoluta. Em uma carga de OLAP, atualmente gero 500 GB de dados em 30 minutos. De acordo com a metrica, teria que ter Redo Logs de cerca de 300 GB cada. O problema nao e um (ou 20) switch, mas o ultimo switch sem que haja um Redo Log disponivel para continuar a gravacao. Isto tb invalida a metrica. Um cliente nao liga para switch, ele nao reclama disso. Ele quer que o SQL execute em menos tempo, e para isto você deve analisar o tempo que o banco gastou esperando por Redo Log livre (evento log file switch completion). Esta analise eh simples com o AWR. Enviado pelo meu aparelho BlackBerry da Claro -Original Message- From: JLSilva jljlsi...@yahoo.com.br Sender: oracle_br@yahoogrupos.com.br Date: Tue, 7 Jun 2011 10:01:18 To: oracle_br@yahoogrupos.com.br Reply-To: oracle_br@yahoogrupos.com.br Subject: Re: RES: [oracle_br] Re: DBWR lento fala Welvis. blz? aquela nota que o chiappa citou fala sobre isso: 781999.1 vc tem acesso ao metalink? se sim, dê uma olhada nessa nota. mas em resumo, a sugestão da nota é dimensionar os redologs para 20 minutos entre cada switch. On Jun 07, 2011, at 9:44 , wel...@stcruz.com.br wrote: Olá pessoal... Gostaria de saber se há alguma nota no metalink que diz se quanto em quanto tempo é um switch para um banco OLTP.. Eu costumo deixar/recomendar que os switchs sejam de pelo menos uns 10 minutos., claro dependendo do horário este número pode variar um pouco tanto para mais quanto para menos. Mas com toda esta discussão fiquei curioso sobre isso... Att, Welvis Douglas De: oracle_br@yahoogrupos.com.br [mailto:oracle_br@yahoogrupos.com.br] Em nome de Fábio Gibon - Comex System Enviada em: segunda-feira, 6 de junho de 2011 22:08 Para: oracle_br@yahoogrupos.com.br Assunto: Re: [oracle_br] Re: DBWR lento Na real eu não queria saber realmente se o redolog deveria ser 50mb, 200mb, 2gb, ... foi levantado a hipótese aqui de que o problema de desempenho do banco era por problema de performance de IO nos discos onde estavam os redologs, então tentei levantar alguns dados para ver se não estava pecando em alguma configuração (antes de sair culpando o disk group que estão os redos) sds Fábio Gibon - Original Message - From: jljlsilva To: oracle_br@yahoogrupos.com.br Sent: Monday, June 06, 2011 4:40 PM Subject: [oracle_br] Re: DBWR lento portilho, legal suas observações. penso que o caminho é esse mesmo. eu imagino que as pessoas que colocam perguntas desse tipo que o fábio gibon colocou aqui nesse tópico, não tem informações suficientes sobre o assunto e precisam justamente desse tipo de comentário, sem exageros, mas direcionando, neste caso, sobre como calcular o que ele precisa. legal... valeu... --- Em oracle_br@yahoogrupos.com.br, Ricardo Portilho Proni ricardo.proni@... escreveu Oi. - Não importa o tamanho do banco, e sim o tamanho das gravações. Um banco de 1TB que só sofre SELECT não terá impacto em ter os pequenos Redo Logs padrão do Oracle (3 x 50MB); - Você deve ter Redo Logs suficientes (em tamanho e quantidade) para contar sua maior gravação concorrente. Veja neste exemplo, eu executo uma gravação de 250MB sem ter 250MB de Redo Log, e o tempo é prejudicado em mais de 100%. Após adicionar um único Redo Log de 1GB, tenho meu problema solucionado: http://profissionaloracle.com.br/blogs/portilho/2009/01/14/imp-lento-no-oracle/ - Você deve ter Redo Logs suficientes (em tamanho em quantidade) de forma que o Wait Event log file switch não ocupe um tempo relevante no período analisado. Se ele ocupa apenas 5% do seu tempo de banco, e você não precisa destes 5% de tempo, não precisa altera-los; - Redo Logs grandes não impactam o sistema por conta da geração de Archives grandes: se você está efetuando uma gravação de 100GB, o Oracle irá gerar 100GB (+ ou -) de Archives de qualquer forma, seja em pedaços de 100MB ou de 1GB; - Em um RAC de 8 Nós, teriam sido gastos alguns milhões de dólares só de licenças do Oracle. Neste cenário, 160GB de disco é irrelevante, este ambiente deve ter até mais de 160GB de RAM. Espero ter ajudado. Em Sáb, 2011-06-04 às 01:32 +, jljlsilva escreveu: chiappa, mas, vamos detalhar um pouco mais. o que é um banco de dados nanico prá vc? vc acha q um redolog muito grande não poderia causar problemas de performance no momento do arquivamento? afinal, não é toda empresa que tem storages de performance tão alta quanto gostaríamos. nunca precisei usar um membro de redolog de 2GB, até o momento. me parece q, como vc citou no final da sua explicação, vc usou como base níveis / volumes não triviais, o que precisaria de muito mais análise para se chegar a tal conclusão. entende porque me surpreendeu? até porque vc enfatiza com letras grandes como se o básico/mínimo fosse aquilo, via de regra. --- Em oracle_br@yahoogrupos.com.br, José Laurindo jlchiappa@ escreveu Então, seguinte :
Re: Res: Re: RES: [oracle_br] Re: DBWR lento
ricardo proni, correto seu raciocínio. mas, novamente está falando de algo fora do trivial. quando se está trabalhando fora do trivial, a análise não é trivial também. segundo entendi, a nota lá fala que 1 switch a cada 20 minutos é uma regra geral, para ambiente transacional (OLTP), em horário de pico. On Jun 07, 2011, at 12:13 , ricardo.pr...@gmail.com wrote: Eu respeitosamente discordo da métrica, pois ela nao eh absoluta. Em uma carga de OLAP, atualmente gero 500 GB de dados em 30 minutos. De acordo com a metrica, teria que ter Redo Logs de cerca de 300 GB cada. O problema nao e um (ou 20) switch, mas o ultimo switch sem que haja um Redo Log disponivel para continuar a gravacao. Isto tb invalida a metrica. Um cliente nao liga para switch, ele nao reclama disso. Ele quer que o SQL execute em menos tempo, e para isto você deve analisar o tempo que o banco gastou esperando por Redo Log livre (evento log file switch completion). Esta analise eh simples com o AWR. Enviado pelo meu aparelho BlackBerry da Claro -Original Message- From: JLSilva jljlsi...@yahoo.com.br Sender: oracle_br@yahoogrupos.com.br Date: Tue, 7 Jun 2011 10:01:18 To: oracle_br@yahoogrupos.com.br Reply-To: oracle_br@yahoogrupos.com.br Subject: Re: RES: [oracle_br] Re: DBWR lento fala Welvis. blz? aquela nota que o chiappa citou fala sobre isso: 781999.1 vc tem acesso ao metalink? se sim, dê uma olhada nessa nota. mas em resumo, a sugestão da nota é dimensionar os redologs para 20 minutos entre cada switch. On Jun 07, 2011, at 9:44 , wel...@stcruz.com.br wrote: Olá pessoal... Gostaria de saber se há alguma nota no metalink que diz se quanto em quanto tempo é um switch para um banco OLTP.. Eu costumo deixar/recomendar que os switchs sejam de pelo menos uns 10 minutos., claro dependendo do horário este número pode variar um pouco tanto para mais quanto para menos. Mas com toda esta discussão fiquei curioso sobre isso... Att, Welvis Douglas De: oracle_br@yahoogrupos.com.br [mailto:oracle_br@yahoogrupos.com.br] Em nome de Fábio Gibon - Comex System Enviada em: segunda-feira, 6 de junho de 2011 22:08 Para: oracle_br@yahoogrupos.com.br Assunto: Re: [oracle_br] Re: DBWR lento Na real eu não queria saber realmente se o redolog deveria ser 50mb, 200mb, 2gb, ... foi levantado a hipótese aqui de que o problema de desempenho do banco era por problema de performance de IO nos discos onde estavam os redologs, então tentei levantar alguns dados para ver se não estava pecando em alguma configuração (antes de sair culpando o disk group que estão os redos) sds Fábio Gibon - Original Message - From: jljlsilva To: oracle_br@yahoogrupos.com.br Sent: Monday, June 06, 2011 4:40 PM Subject: [oracle_br] Re: DBWR lento portilho, legal suas observações. penso que o caminho é esse mesmo. eu imagino que as pessoas que colocam perguntas desse tipo que o fábio gibon colocou aqui nesse tópico, não tem informações suficientes sobre o assunto e precisam justamente desse tipo de comentário, sem exageros, mas direcionando, neste caso, sobre como calcular o que ele precisa. legal... valeu... --- Em oracle_br@yahoogrupos.com.br, Ricardo Portilho Proni ricardo.proni@... escreveu Oi. - Não importa o tamanho do banco, e sim o tamanho das gravações. Um banco de 1TB que só sofre SELECT não terá impacto em ter os pequenos Redo Logs padrão do Oracle (3 x 50MB); - Você deve ter Redo Logs suficientes (em tamanho e quantidade) para contar sua maior gravação concorrente. Veja neste exemplo, eu executo uma gravação de 250MB sem ter 250MB de Redo Log, e o tempo é prejudicado em mais de 100%. Após adicionar um único Redo Log de 1GB, tenho meu problema solucionado: http://profissionaloracle.com.br/blogs/portilho/2009/01/14/imp-lento-no-oracle/ - Você deve ter Redo Logs suficientes (em tamanho em quantidade) de forma que o Wait Event log file switch não ocupe um tempo relevante no período analisado. Se ele ocupa apenas 5% do seu tempo de banco, e você não precisa destes 5% de tempo, não precisa altera-los; - Redo Logs grandes não impactam o sistema por conta da geração de Archives grandes: se você está efetuando uma gravação de 100GB, o Oracle irá gerar 100GB (+ ou -) de Archives de qualquer forma, seja em pedaços de 100MB ou de 1GB; - Em um RAC de 8 Nós, teriam sido gastos alguns milhões de dólares só de licenças do Oracle. Neste cenário, 160GB de disco é irrelevante, este ambiente deve ter até mais de 160GB de RAM. Espero ter ajudado. Em Sáb, 2011-06-04 às 01:32 +, jljlsilva escreveu: chiappa, mas, vamos detalhar um pouco mais. o que é um banco de dados nanico prá vc? vc acha q um redolog muito grande não poderia causar problemas de performance no momento do arquivamento? afinal, não é toda empresa que tem storages de performance tão alta quanto gostaríamos. nunca precisei usar um membro de redolog de 2GB, até o momento. me
[oracle_br] Re: Criação de Script - Coelta de Estatisticas
Colega, alguns coments : Primeiro, ANTES de fazer o que quer que seja num
ambiente que atende pacote de terceiros (não desenvolvido em casa), E
principalmente para ERPs, vc TEM QUE checar documentação e Recomendações do
fabricante, é Comum que o fabricante estabeleça exigências diferentes para
coleta de estatísticas em diferentes schemas e/ou objetos, ou mesmo (como a
Oracle faz com o EBS, por ex.) que forneça um job/script/rotina Específico pra
isso e que a preferência seja rodar essa cara...
SE não existir job/script pré-fabricado que seja exigido, APÓS vc levantar
direitinho na doc/suporte do fabricante quais são as exigências e/ou
recomendações em termos de coleta de estatísticas (se precisa ou não de
histogramas, se tem schema que ele recomenda e schema que não recomenda, qual o
percentual de sample que eles tem visto dar bons resultados, etc) E APÓS vc ter
levantado com os usuários qual seria a janela possível, qual/quais
schemas/objetos são mais alterados e/ou são maiores, e tudo o mais que puder
obter, AÍ sim temos que :
1. eu SEMPRE prefiro ao invés de executar um SQL dinâmico em loop escrever um
script que GERA UM OUTRO SCRIPT com os comandos, pois aí eu tenho um LOG do
resultado da geração (fica bico ver qquer erro de lógica) , E também se
precisar re-executar com pequenas alterações passo a mão no textpad e num
segundinho altero o script de comandos
2. vc está ** ENFILEIRANDO ** a execução : a tua lógica pega o schema 1, coleta
estats, SÓ depois que 1 foi coletado aí sim ela pega o 2, ou 3, assim por
diante : isso via de regra NÃO É EFICIENTE pra performance, um servidor
Produção normalmente aguenta ter mais de um job em execução, então vc poderia
ter vários scripts executando em várias janelas diferentes simultaneamente,
cada script coletando uma parte diferente das estats...
3. vc está usando os mesmos params / níveis de coleta pra todo mundo, é
INDETERMINADO se isso é bom - como citado no Primeiro ponto, tranquilamente
Pode Ser que existam necessidades especiais pro teu ambiente...
Em cima disso , além do que, uma idéia que implantei num cliente DW um tempo
atrás e foi bem vista era se ter vários scripts sendo gerados : um com os
objetos mais pequenos/triviais que se coleta tudo default, outro com objetos
médios em termos de tamanhoxalterações, outro com objetos/schemas que exigem
histogramas, outro com objetos que não exigem histogramas, outro com objetos
grandes que 9esses sim) vc Quer enfileirar em não havendo poder de I/O pra
coletar stats de vários objs grandes ao mesmo tempo, por aí...
= Este é o meu script sql*plus básico , fique à vontade de alterá-lo cfrme
queira :
set term off feedback off verify off pages 0 lines 500 trimspool on head off
spool C:\coleta_stats.sql
select 'execute sys.dbms_stats.gather_table_stats(ownname='
|| chr(39) || owner || chr(39) || ',tabname='
|| chr(39) || table_name || chr(39)
|| ',granularity=' || chr(39) || 'ALL'|| chr(39)
|| ',method_opt=' || chr(39) || 'FOR ALL INDEXED COLUMNS SIZE AUTO' ||
chr(39)
|| ', estimate_percent=NULL,cascade=TRUE, DEGREE=6);'
from dba_tables
where owner in ('DMGGER', 'DMCOMUM')
and owner not in ('SYS', 'SYSTEM')
order by table_name
/
select 'exit' || chr(10) from dual
/
spool off
exit
== A idéia é vc ter uma versão desse script para cada conjunto de
objetos/schemas, que vc agrupa cfrme necessário (ie, grupo dos grandes, grupo
dos que podem ser feito SEM estimate, grupo dos que exigem ESTIMATE de x%, etc,
etc...
[]s
Chiappa
--- Em oracle_br@yahoogrupos.com.br, candiurudba candiurudba@... escreveu
Bom dia colegas,
Estou refazendo alguns script antigos, quanto a coleta de estatisticas e
estou tendo alguma dificuldade para criar um unico script, com a devida
passagem de parametros relacionada aos owners que possuo...
Irei fazer uma criação de histogramas diaria (20%) e no sabado, uma coelta
full de estatisticas...
A idéia seria a seguinte...
begin
cursor_username in (select distinct (username)
from dba_users
where lower(username) not in ('apex_public_user',
'flows_03',
'flows_files',
'owbsys',
'spatial_csw_admin_usr',
'spatial_wfs_admin_usr',
'wkproxy',
'wksys',
'wk_test',
'xs$null',
'si_informmtn_schema',
'scott',
'oracle_ocm',
'dip',
'outln',
'mgmt_view',
'tsmsys',
'ix',
'anonymous',
'sysman',
Re: Res: Re: RES: [oracle_br] Re: DBWR lento
Para OLAP acredito que a regra seja outra. Mas como o JLSilva disse, situação diferente pede uma abordagem diferente. Para OLTP, dependendo do ambiente até de 15 em 15 minutos atende. E se levar em conta também que a cada switch vai ter um checkpoint, o cliente vai acabar reclamando de qualquer jeito, pois muitos switchs em pouco tempo tem impacto negativo na performance. On 6/7/11, JLSilva jljlsi...@yahoo.com.br wrote: ricardo proni, correto seu raciocínio. mas, novamente está falando de algo fora do trivial. quando se está trabalhando fora do trivial, a análise não é trivial também. segundo entendi, a nota lá fala que 1 switch a cada 20 minutos é uma regra geral, para ambiente transacional (OLTP), em horário de pico. On Jun 07, 2011, at 12:13 , ricardo.pr...@gmail.com wrote: Eu respeitosamente discordo da métrica, pois ela nao eh absoluta. Em uma carga de OLAP, atualmente gero 500 GB de dados em 30 minutos. De acordo com a metrica, teria que ter Redo Logs de cerca de 300 GB cada. O problema nao e um (ou 20) switch, mas o ultimo switch sem que haja um Redo Log disponivel para continuar a gravacao. Isto tb invalida a metrica. Um cliente nao liga para switch, ele nao reclama disso. Ele quer que o SQL execute em menos tempo, e para isto você deve analisar o tempo que o banco gastou esperando por Redo Log livre (evento log file switch completion). Esta analise eh simples com o AWR. Enviado pelo meu aparelho BlackBerry da Claro -Original Message- From: JLSilva jljlsi...@yahoo.com.br Sender: oracle_br@yahoogrupos.com.br Date: Tue, 7 Jun 2011 10:01:18 To: oracle_br@yahoogrupos.com.br Reply-To: oracle_br@yahoogrupos.com.br Subject: Re: RES: [oracle_br] Re: DBWR lento fala Welvis. blz? aquela nota que o chiappa citou fala sobre isso: 781999.1 vc tem acesso ao metalink? se sim, dê uma olhada nessa nota. mas em resumo, a sugestão da nota é dimensionar os redologs para 20 minutos entre cada switch. On Jun 07, 2011, at 9:44 , wel...@stcruz.com.br wrote: Olá pessoal... Gostaria de saber se há alguma nota no metalink que diz se quanto em quanto tempo é um switch para um banco OLTP.. Eu costumo deixar/recomendar que os switchs sejam de pelo menos uns 10 minutos., claro dependendo do horário este número pode variar um pouco tanto para mais quanto para menos. Mas com toda esta discussão fiquei curioso sobre isso... Att, Welvis Douglas De: oracle_br@yahoogrupos.com.br [mailto:oracle_br@yahoogrupos.com.br] Em nome de Fábio Gibon - Comex System Enviada em: segunda-feira, 6 de junho de 2011 22:08 Para: oracle_br@yahoogrupos.com.br Assunto: Re: [oracle_br] Re: DBWR lento Na real eu não queria saber realmente se o redolog deveria ser 50mb, 200mb, 2gb, ... foi levantado a hipótese aqui de que o problema de desempenho do banco era por problema de performance de IO nos discos onde estavam os redologs, então tentei levantar alguns dados para ver se não estava pecando em alguma configuração (antes de sair culpando o disk group que estão os redos) sds Fábio Gibon - Original Message - From: jljlsilva To: oracle_br@yahoogrupos.com.br Sent: Monday, June 06, 2011 4:40 PM Subject: [oracle_br] Re: DBWR lento portilho, legal suas observações. penso que o caminho é esse mesmo. eu imagino que as pessoas que colocam perguntas desse tipo que o fábio gibon colocou aqui nesse tópico, não tem informações suficientes sobre o assunto e precisam justamente desse tipo de comentário, sem exageros, mas direcionando, neste caso, sobre como calcular o que ele precisa. legal... valeu... --- Em oracle_br@yahoogrupos.com.br, Ricardo Portilho Proni ricardo.proni@... escreveu Oi. - Não importa o tamanho do banco, e sim o tamanho das gravações. Um banco de 1TB que só sofre SELECT não terá impacto em ter os pequenos Redo Logs padrão do Oracle (3 x 50MB); - Você deve ter Redo Logs suficientes (em tamanho e quantidade) para contar sua maior gravação concorrente. Veja neste exemplo, eu executo uma gravação de 250MB sem ter 250MB de Redo Log, e o tempo é prejudicado em mais de 100%. Após adicionar um único Redo Log de 1GB, tenho meu problema solucionado: http://profissionaloracle.com.br/blogs/portilho/2009/01/14/imp-lento-no-oracle/ - Você deve ter Redo Logs suficientes (em tamanho em quantidade) de forma que o Wait Event log file switch não ocupe um tempo relevante no período analisado. Se ele ocupa apenas 5% do seu tempo de banco, e você não precisa destes 5% de tempo, não precisa altera-los; - Redo Logs grandes não impactam o sistema por conta da geração de Archives grandes: se você está efetuando uma gravação de 100GB, o Oracle irá gerar 100GB (+ ou -) de Archives de qualquer forma, seja em pedaços de 100MB ou de 1GB; - Em um RAC de 8 Nós, teriam sido gastos alguns milhões de dólares só de licenças do Oracle. Neste cenário, 160GB de disco é irrelevante, este ambiente deve ter até mais de 160GB de RAM. Espero ter ajudado. Em Sáb,
[oracle_br] Oracle Cliente X I 5
Boa tarde. Estou tentando instalar o Oracle em um PC com processador Intel I 5 e Windows XP SP3 de 32 bits e 3Gb de RAM. Ao clicar no SETUP.EXE a instalação não inicia e não dá nenhuma mensagem. Tentei com o 10.1.0.2 e com o 10.2.0.3; tentei também aumentar o arquivo de memória virtual para mais que o dobro da memória física e não adiantou. Alguem teria uma solução para isso ? Leonardo A. Souza TRE-GO [As partes desta mensagem que não continham texto foram removidas]
RES: [oracle_br] Oracle Cliente X I 5
A versão 10.2.0.3 é para Windows Vista, Windows Server 2008 e Windows 7. Para o Windows XP a versão correta é 10.2.0.1. Att, Milton De: oracle_br@yahoogrupos.com.br [mailto:oracle_br@yahoogrupos.com.br] Em nome de Leonardo Enviada em: terça-feira, 7 de junho de 2011 18:23 Para: oracle_br@yahoogrupos.com.br Assunto: [oracle_br] Oracle Cliente X I 5 Boa tarde. Estou tentando instalar o Oracle em um PC com processador Intel I 5 e Windows XP SP3 de 32 bits e 3Gb de RAM. Ao clicar no SETUP.EXE a instalação não inicia e não dá nenhuma mensagem. Tentei com o 10.1.0.2 e com o 10.2.0.3; tentei também aumentar o arquivo de memória virtual para mais que o dobro da memória física e não adiantou. Alguem teria uma solução para isso ? Leonardo A. Souza TRE-GO [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] Oracle Cliente X I 5
leonardo, abre o prompt de comando do windows, acessa o diretório onde descompactou o instalador e executa o setup.exe por lá. talvez está aparecendo algum erro e vc não tá vendo ele porque quando vc executa pelo windows explorer a tela fecha rapidamente. outra coisa, o instalador para windows xp 32bit é o 10.2.0.1.0 vc pode baixar em: http://www.oracle.com/technetwork/database/10201winsoft-095341.html On Jun 07, 2011, at 18:23 , Leonardo wrote: Boa tarde. Estou tentando instalar o Oracle em um PC com processador Intel I 5 e Windows XP SP3 de 32 bits e 3Gb de RAM. Ao clicar no SETUP.EXE a instalação não inicia e não dá nenhuma mensagem. Tentei com o 10.1.0.2 e com o 10.2.0.3; tentei também aumentar o arquivo de memória virtual para mais que o dobro da memória física e não adiantou. Alguem teria uma solução para isso ? Leonardo A. Souza TRE-GO [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
[oracle_br] Re: Oracle Cliente X I 5
Algumas coisas que a gente pensa : 1) pode haver issues com softwares de conexão remota (como terminal Server) , eu recomendo que vc vá até a máquina, conecte LOCALMENTE nela, com um usuário local, pra fazer a instalação 2) cfrme vc sabe, a instalação de um software Oracle ** vai ** ter que fazer algumas ações a nível de sistema (ie, criar coisas no registry, acessar diretório fora da pasta USERS, alterar variáveis de ambiente como a PATH, etc) : talvez o usuário com que vc esteja logado não tenha permissões para isso Pra evitar coisas do tipo eu costumo deixar o usuário local com o qual vc conectou no cliente Windows como Administrador local da máquina (é um usuário LOCAL, e não usuário de rede, e Admin LOCAL, não admin de rede NEM de domínio) 3) Há algumas exigências de hardware e config (como resolução de tela no mínimo 800x600 em 256 cores, ao menos 512 Mb de RAM presentes (e ** livres **, é claro, não adianta vc ter mais que isso MAS estar usado por outros progs :) : veja se vc está cumprindo-as 4) veja lá SE vc não tem softwares de controle de rede segurança (firewall do windows, anti-vírus, anti-spyware) , e/ou de controle de acesso (seja externos, seja de rede, seja simplesmente POLICY do Windows) nessa máquina-cliente barrando o instalador (que , Inclusive, é em Java, portanto além do SETUP.EXE ** também ** o JAVA.EXE ** tem ** que ser permitido/autorizado/bypassado pelo que vc tiver aí nessa máquina === CHEQUE direitinho essas possibilidades todas... SE nada disso resolver, uma dica pra facilitar o debug seria : conectado localmente COM o usuário local administrador que nem citei acima, blablabla, abre um prompt de comando DOS como Administrador (ie, Iniciar/Todos os Programas/Acessórios , click com botão direito no ícone do DOS, na opção Executar Como escolha o usuário administrador) entra no disco e diretório onde tá o instalador e executa aí nesse prompt DOS o SETUP.EXE : o objetivo aqui é confirmar que não está sendo exibida alguma msg de erro muito rapidamente que a GUI esteja escondendo... []s Chiappa --- Em oracle_br@yahoogrupos.com.br, Leonardo leoz09@... escreveu Boa tarde. Estou tentando instalar o Oracle em um PC com processador Intel I 5 e Windows XP SP3 de 32 bits e 3Gb de RAM. Ao clicar no SETUP.EXE a instalação não inicia e não dá nenhuma mensagem. Tentei com o 10.1.0.2 e com o 10.2.0.3; tentei também aumentar o arquivo de memória virtual para mais que o dobro da memória física e não adiantou. Alguem teria uma solução para isso ? Leonardo A. Souza TRE-GO [As partes desta mensagem que não continham texto foram removidas]
