Re: [oracle_br] Re: tamanho ideal do redo..

[jlchia...@yahoo.com.br [oracle_br]]

É bem capaz que vc tenha que rever essa parte de redo na ocasião, mas que fique 
claro, isso vai ser devido ** NÃO ** ao crescimento da tabela em si (redo 
gerado NÂO TEM NADA A VER com tamanho da tabela), mas devido ao aumento do 
volume das Transações, em especial a UPDATEs, sim sim ??? 

[]s

  Chiappa

Re: [oracle_br] Re: tamanho ideal do redo..

[jlchia...@yahoo.com.br [oracle_br]]

Legal : 200 mb eu acho que via de regra é pequeno (como eu comentei, numa base 
produção ativa E que de vez em quando sofre Atualizações pesadas estilo DW eu 
começo com 512 Mb) mas se mesmo após as maiores transações ele tá aguentando 
bem (ie, não aparece nenhuma msg de checkpoint not complete, o intervalo entre 
gravações de archive tá razoável, etc) tá então, vc atingiu o sweetspot ou pelo 
menos tá bem perto...

[]s

  Chiappa
  
OBS : só comentando, esse detalhe do archive file não ser o mesmo tamanho do 
redo log file reflete o fato de que há mito tempo o archive deixou de ser 
gerado só quando o redo log file enche, ocasião em que ele era 'copiado' - às 
vezes quando dava curso ou quando explicava o mecanismo de archive pra alguém 
eu 'arredondava' a explicação por didática e mandava essa, mas não é bem assim 
: 
https://asktom.oracle.com/pls/apex/f?p=100:11:0P11_QUESTION_ID:3393267691681
 e 
https://asktom.oracle.com/pls/apex/f?p=100:11:0P11_QUESTION_ID:9532368200346164524
 falam sobre isso...

Re: [oracle_br] Re: tamanho ideal do redo..

[angelo angelolis...@gmail.com [oracle_br]]

O bicho vai pegar mesmo quando começarmos a rodar o sistema de nota fiscal
eletrônica nesse sistema, porque toda rotina de faturamento do ERP novo vai
integrar com ele.. e tabelas que tratam de capa e corpo de nota fiscal e
pedidos e estoque costumam crescer demasiadamente rapido..

Fabio, no teu site tem algum artigo de tuning?  vou dar uma procurada


[]s


2016-12-14 13:35 GMT-02:00 Fabio Prado fbifa...@gmail.com [oracle_br] <
oracle_br@yahoogrupos.com.br>:

>
>
> Pessoal,
>
>  Só para reforçar os comentários do Chiappa, já fiz consultoria de
> Tuning nos BDs de alguns ex-alunos, e em vários deles o problema principal
> de performance horrenda do BD era o tamanho dos redo logs que estava com o
> valor padrão de 50M, e eram muito pequenos para a carga atual de transações
> daqueles BDs.
>
>  O cálculo que eu faço para dimensionar o redo log era recriá-los com
> um tamanho aproximado ao volume de redo que é gerado num período de 20
> minutos... tempo aprox. ideal (conforme diversas fontes de pesquisas,
> incluindo docs da Oracle que dizem que o tempo ideal de um switch log deve
> ser de 15 ou 20 minutos) para balancear performance e seguranças dos dados
> do redo.
>
> []s
>
>
> *Fábio Prado*
> 
> www.fabioprado.net
> "Compartilhando conhecimentos e treinando profissionais em Bancos de Dados
> Oracle"
>
>
> Em 14 de dezembro de 2016 12:14, jlchia...@yahoo.com.br [oracle_br] <
> oracle_br@yahoogrupos.com.br> escreveu:
>
>>
>>
>> Angelo, se esse ambiente é PROD e (portanto) segurança/recuperabilidade é
>> paradigma máximo, faça isso Pra Ontem : um só log file é um
>> SPOF/SinglePointOfFailure total e completo E, já que tanto aumentar
>> redo log file size QUANTO ter redo log file group members (apontando pra
>> discos DIFERENTES, é Óbvio!!, se não tiver usando disk devices num storage)
>> são coisas ONLINE, se vc já tiver o hardware nem precisa esperar pela
>> próxima janela
>>
>> []s
>>
>>   Chiappa
>>
>
> 
>

Re: [oracle_br] Re: tamanho ideal do redo..

[angelo angelolis...@gmail.com [oracle_br]]

Já o fiz, no domingo passado

Agora o redo está multiplexado por 2x (acho que é suficiente, e em discos
separados), e acrescentei mais 3 grupos de 200mb, removendo os originais
(de 50) ,e foi...
Engraçado que os arquivos  *.arc na hora que descarrega eles não saem com
200 mb, sai sempre um pouco menor, 180, 188 mb + ou - ... enfim, são
detalhes..

[]s


2016-12-14 12:14 GMT-02:00 jlchia...@yahoo.com.br [oracle_br] <
oracle_br@yahoogrupos.com.br>:

>
>
> Angelo, se esse ambiente é PROD e (portanto) segurança/recuperabilidade é
> paradigma máximo, faça isso Pra Ontem : um só log file é um
> SPOF/SinglePointOfFailure total e completo E, já que tanto aumentar
> redo log file size QUANTO ter redo log file group members (apontando pra
> discos DIFERENTES, é Óbvio!!, se não tiver usando disk devices num storage)
> são coisas ONLINE, se vc já tiver o hardware nem precisa esperar pela
> próxima janela
>
> []s
>
>   Chiappa
> 
>

Re: [oracle_br] Re: tamanho ideal do redo..

[Fabio Prado fbifa...@gmail.com [oracle_br]]

Pessoal,

 Só para reforçar os comentários do Chiappa, já fiz consultoria de
Tuning nos BDs de alguns ex-alunos, e em vários deles o problema principal
de performance horrenda do BD era o tamanho dos redo logs que estava com o
valor padrão de 50M, e eram muito pequenos para a carga atual de transações
daqueles BDs.

 O cálculo que eu faço para dimensionar o redo log era recriá-los com
um tamanho aproximado ao volume de redo que é gerado num período de 20
minutos... tempo aprox. ideal (conforme diversas fontes de pesquisas,
incluindo docs da Oracle que dizem que o tempo ideal de um switch log deve
ser de 15 ou 20 minutos) para balancear performance e seguranças dos dados
do redo.

[]s


*Fábio Prado*

www.fabioprado.net
"Compartilhando conhecimentos e treinando profissionais em Bancos de Dados
Oracle"


Em 14 de dezembro de 2016 12:14, jlchia...@yahoo.com.br [oracle_br] <
oracle_br@yahoogrupos.com.br> escreveu:

>
>
> Angelo, se esse ambiente é PROD e (portanto) segurança/recuperabilidade é
> paradigma máximo, faça isso Pra Ontem : um só log file é um
> SPOF/SinglePointOfFailure total e completo E, já que tanto aumentar
> redo log file size QUANTO ter redo log file group members (apontando pra
> discos DIFERENTES, é Óbvio!!, se não tiver usando disk devices num storage)
> são coisas ONLINE, se vc já tiver o hardware nem precisa esperar pela
> próxima janela
>
> []s
>
>   Chiappa
> 
>

Re: [oracle_br] Re: tamanho ideal do redo..

[jlchia...@yahoo.com.br [oracle_br]]

Angelo, se esse ambiente é PROD e (portanto) segurança/recuperabilidade é 
paradigma máximo, faça isso Pra Ontem : um só log file é um 
SPOF/SinglePointOfFailure total e completo E, já que tanto aumentar redo 
log file size QUANTO ter redo log file group members (apontando pra discos 
DIFERENTES, é Óbvio!!, se não tiver usando disk devices num storage) são coisas 
ONLINE, se vc já tiver o hardware nem precisa esperar pela próxima janela

[]s

  Chiappa

Re: [oracle_br] Re: tamanho ideal do redo..

[jlchia...@yahoo.com.br [oracle_br]]

Ah sim : tudo que eu falei aqui vale para bancos single/padrão : no instante em 
que o REDO LOG é usado para outras coisas (por exemplo, o redo precisa ser 
enviado para outro servidor para ser usado num standby físico) a história muda 
- sim, dependendo se a funcionalidade exige algum processamento no redo log 
file aí a coisa muda de figura Por exemplo, o dataguard tradicionalmente 
enviava pro standby os archives, mas com a introdução (no 10g, iirc) do Log 
Apply Services, o dataguard passou a ter a opção de  real-time apply, que 
permite recuperar e aplicar no standby o redo diretamente do standby redo log 
file... 
 Mas sim, no instante em que vc VAI usar o redo pra alguma coisa settings como 
tamanho de redo log file, tempo de geração de archives, etc, mudam , sim...
 
 []s
 
   Chiappa

Re: [oracle_br] Re: tamanho ideal do redo..

[angelo angelolis...@gmail.com [oracle_br]]

"pois mesmo que vc não tenha o log necessário archivado em caso de crash vc
 OBVIAMENTE  está MULTIPLEXANDO seus log files, né não ??? "

==> Resp:  Não.. :-(Mas é uma tarefa a ser feita na próxima janela.
Pouco tempo pra ficar preparando.. queriam começar a usar logo, ai ja viu
né..



2016-12-14 10:16 GMT-02:00 jlchia...@yahoo.com.br [oracle_br] <
oracle_br@yahoogrupos.com.br>:

>
>
> Blz ? Então, no tocante á otimização para que os redos atendam a um tempo
> mínimo de recuperação desejado, uma opção pode ser vc usar o ADVISOR
> específico pra isso , veja http://www.orafaq.com/node/1437 e
> http://www.databasejournal.com/features/oracle/article.
> php/3395731/Oracle-10gs-Redo-Logfile-Sizing-Advisor.htm para exemplos e
> refs... Notar também que há muuito tempo (desde 9i iirc) já temos o
> FAST_START_MTTR_TARGET para indicar tempo de recuperabilidade...
>
>   Já no que se refere à performance eu tenho alguns pontos : o primeiro é
> que, ao contrário do que vc parece pensar (julgando pelo que vc escreveu no
> parágrafo em que vc fala de redo) por princípio NÃO HÁ COMO o tamanho
> grande demais de um redo log file interferir na performance, pois a
> gravação de redo no redo log file NÂO IMPLICA em acessar o arquivo todo, o
> arquivo é aberto em APPEND-MODE...
>
>  Já um tamanho de redo log file muito pequeno ** SIM **, pode interferir
> pois em princípio independente de outros settings, se um redo log file
> enche um archive deverá ser criado, se esse enchimento for frequente Não só
> o processo de ARCH pode ficar sobrecarregado (já que vai ser acionado a
> "toda hora") mas também o LOG WRITER pode ter que ficar "esperando" o ARCH
> liberar / confirmar a criação de archive antes da geração de novos logs
> poder avançar É baseado mais ou menos nisso que a Oracle recomenda um
> intervalo de alguns minutos entre a geração de cada archive - é um jogo de
> Equilíbrio entre a segurança e a performance, muito embora a questão de
> Segurança não é tão crítica, pois mesmo que vc não tenha o log necessário
> archivado em caso de crash vc  OBVIAMENTE  está MULTIPLEXANDO seus
> log files, né não ???
>
> O resumo da ópera então é : avalie a possibilidade de usar o Advisor,
> saiba que log file muito grande não deve interferir (negativamente ou
> positivamente) E que um log file muito pequeno PODE SIM interferir
> negativamente - sendo assim, eu sempre chuto como valor inicial algo em
> torno de 500Mb a 1 GB como log file size, esses 50 Mb default numa
> utilização em ambiente Produtivo via de regra são ridículos... Aí depois
> uso o Advisor, analiso os waits referentes a log e archive, analiso a
> diferença de tempos de criação dos archives, por aí...
>
> []s
>
>   Chiappa
> 
>

Re: [oracle_br] Re: tamanho ideal do redo..

[angelo angelolis...@gmail.com [oracle_br]]

Porque vc acha isso, Rafael ?

Você ta imaginando uma situacao dele ser replicado, espelhado ?  DG =
Dataguard certo ?



On 14 December 2016 at 11:44, Rafael Mendonca raffaell.t...@yahoo.com
[oracle_br]  wrote:

>
>
> Chiappa, uma dúvida:
>
>
> "por princípio NÃO HÁ COMO o tamanho grande demais de um redo log file
> interferir na performance"
>
> Quando se tem uma infra com DG configurado com protection mode max
> protection por exemplo, um log grande demais não vai interferir na
> performance ?
>
> Enviado do Yahoo Mail para iPhone 
>
> On quarta-feira, dezembro 14, 2016, 9:16 AM, jlchia...@yahoo.com.br
> [oracle_br]  wrote:
>
>
>
> Blz ? Então, no tocante á otimização para que os redos atendam a um tempo
> mínimo de recuperação desejado, uma opção pode ser vc usar o ADVISOR
> específico pra isso , veja http://www.orafaq.com/node/1437 e
> http://www.databasejournal.com/features/oracle/article.
> php/3395731/Oracle-10gs-Redo-Logfile-Sizing-Advisor.htm para exemplos e
> refs... Notar também que há muuito tempo (desde 9i iirc) já temos o
> FAST_START_MTTR_TARGET para indicar tempo de recuperabilidade...
>
>   Já no que se refere à performance eu tenho alguns pontos : o primeiro é
> que, ao contrário do que vc parece pensar (julgando pelo que vc escreveu no
> parágrafo em que vc fala de redo) por princípio NÃO HÁ COMO o tamanho
> grande demais de um redo log file interferir na performance, pois a
> gravação de redo no redo log file NÂO IMPLICA em acessar o arquivo todo, o
> arquivo é aberto em APPEND-MODE...
>
>  Já um tamanho de redo log file muito pequeno ** SIM **, pode interferir
> pois em princípio independente de outros settings, se um redo log file
> enche um archive deverá ser criado, se esse enchimento for frequente Não só
> o processo de ARCH pode ficar sobrecarregado (já que vai ser acionado a
> "toda hora") mas também o LOG WRITER pode ter que ficar "esperando" o ARCH
> liberar / confirmar a criação de archive antes da geração de novos logs
> poder avançar É baseado mais ou menos nisso que a Oracle recomenda um
> intervalo de alguns minutos entre a geração de cada archive - é um jogo de
> Equilíbrio entre a segurança e a performance, muito embora a questão de
> Segurança não é tão crítica, pois mesmo que vc não tenha o log necessário
> archivado em caso de crash vc  OBVIAMENTE  está MULTIPLEXANDO seus
> log files, né não ???
>
> O resumo da ópera então é : avalie a possibilidade de usar o Advisor,
> saiba que log file muito grande não deve interferir (negativamente ou
> positivamente) E que um log file muito pequeno PODE SIM interferir
> negativamente - sendo assim, eu sempre chuto como valor inicial algo em
> torno de 500Mb a 1 GB como log file size, esses 50 Mb default numa
> utilização em ambiente Produtivo via de regra são ridículos... Aí depois
> uso o Advisor, analiso os waits referentes a log e archive, analiso a
> diferença de tempos de criação dos archives, por aí...
>
> []s
>
>   Chiappa
>
> 
>

Re: [oracle_br] Re: tamanho ideal do redo..

[Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]]

 blockquote, div.yahoo_quoted { margin-left: 0 !important; border-left:1px 
#715FFA solid !important; padding-left:1ex !important; background-color:white 
!important; } Chiappa, uma dúvida:

"por princípio NÃO HÁ COMO o tamanho grande demais de um redo log file 
interferir na performance"
Quando se tem uma infra com DG configurado com protection mode max protection 
por exemplo, um log grande demais não vai interferir na performance ?

Enviado do Yahoo Mail para iPhone


On quarta-feira, dezembro 14, 2016, 9:16 AM, jlchia...@yahoo.com.br [oracle_br] 
 wrote:

    
Blz ? Então, no tocante á otimização para que os redos atendam a um tempo 
mínimo de recuperação desejado, uma opção pode ser vc usar o ADVISOR específico 
pra isso , veja http://www.orafaq.com/node/1437 e 
http://www.databasejournal.com/features/oracle/article.php/3395731/Oracle-10gs-Redo-Logfile-Sizing-Advisor.htm
 para exemplos e refs... Notar também que há muuito tempo (desde 9i iirc) 
já temos o FAST_START_MTTR_TARGET para indicar tempo de recuperabilidade...

  Já no que se refere à performance eu tenho alguns pontos : o primeiro é que, 
ao contrário do que vc parece pensar (julgando pelo que vc escreveu no 
parágrafo em que vc fala de redo) por princípio NÃO HÁ COMO o tamanho grande 
demais de um redo log file interferir na performance, pois a gravação de redo 
no redo log file NÂO IMPLICA em acessar o arquivo todo, o arquivo é aberto em 
APPEND-MODE...
  
 Já um tamanho de redo log file muito pequeno ** SIM **, pode interferir pois 
em princípio independente de outros settings, se um redo log file enche um 
archive deverá ser criado, se esse enchimento for frequente Não só o processo 
de ARCH pode ficar sobrecarregado (já que vai ser acionado a "toda hora") mas 
também o LOG WRITER pode ter que ficar "esperando" o ARCH liberar / confirmar a 
criação de archive antes da geração de novos logs poder avançar É baseado 
mais ou menos nisso que a Oracle recomenda um intervalo de alguns minutos entre 
a geração de cada archive - é um jogo de Equilíbrio entre a segurança e a 
performance, muito embora a questão de Segurança não é tão crítica, pois mesmo 
que vc não tenha o log necessário archivado em caso de crash vc  OBVIAMENTE 
 está MULTIPLEXANDO seus log files, né não ??? 

O resumo da ópera então é : avalie a possibilidade de usar o Advisor, saiba que 
log file muito grande não deve interferir (negativamente ou positivamente) E 
que um log file muito pequeno PODE SIM interferir negativamente - sendo assim, 
eu sempre chuto como valor inicial algo em torno de 500Mb a 1 GB como log file 
size, esses 50 Mb default numa utilização em ambiente Produtivo via de regra 
são ridículos... Aí depois uso o Advisor, analiso os waits referentes a log e 
archive, analiso a diferença de tempos de criação dos archives, por aí...

[]s

  Chiappa
  -- #ygrp-mkp {border:1px solid #d8d8d8;font-family:Arial;margin:10px 
0;padding:0 10px;}#ygrp-mkp hr {border:1px solid #d8d8d8;}#ygrp-mkp #hd 
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 
0;}#ygrp-mkp #ads {margin-bottom:10px;}#ygrp-mkp .ad {padding:0 0;}#ygrp-mkp 
.ad p {margin:0;}#ygrp-mkp .ad a 
{color:#ff;text-decoration:none;}#ygrp-sponsor #ygrp-lc 
{font-family:Arial;}#ygrp-sponsor #ygrp-lc #hd {margin:10px 
0px;font-weight:700;font-size:78%;line-height:122%;}#ygrp-sponsor #ygrp-lc .ad 
{margin-bottom:10px;padding:0 0;}#actions 
{font-family:Verdana;font-size:11px;padding:10px 0;}#activity 
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#activity
 span {font-weight:700;}#activity span:first-child 
{text-transform:uppercase;}#activity span a 
{color:#5085b6;text-decoration:none;}#activity span span 
{color:#ff7900;}#activity span .underline {text-decoration:underline;}.attach 
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 
0;width:400px;}.attach div a {text-decoration:none;}.attach img 
{border:none;padding-right:5px;}.attach label 
{display:block;margin-bottom:5px;}.attach label a 
{text-decoration:none;}blockquote {margin:0 0 0 4px;}.bold 
{font-family:Arial;font-size:13px;font-weight:700;}.bold a 
{text-decoration:none;}dd.last p a 
{font-family:Verdana;font-weight:700;}dd.last p span 
{margin-right:10px;font-family:Verdana;font-weight:700;}dd.last p 
span.yshortcuts {margin-right:0;}div.attach-table div div a 
{text-decoration:none;}div.attach-table {width:400px;}div.file-title a, 
div.file-title a:active, div.file-title a:hover, div.file-title a:visited 
{text-decoration:none;}div.photo-title a, div.photo-title a:active, 
div.photo-title a:hover, div.photo-title a:visited 
{text-decoration:none;}div#ygrp-mlmsg #ygrp-msg p a span.yshortcuts 
{font-family:Verdana;font-size:10px;font-weight:normal;}.green 
{color:#628c2a;}.MsoNormal {margin:0 0 0 0;}o {font-size:0;}#photos div 
{float:left;width:72px;}#photos div div {border:1px solid 

[oracle_br] Re: tamanho ideal do redo..

[jlchia...@yahoo.com.br [oracle_br]]

Blz ? Então, no tocante á otimização para que os redos atendam a um tempo 
mínimo de recuperação desejado, uma opção pode ser vc usar o ADVISOR específico 
pra isso , veja http://www.orafaq.com/node/1437 e 
http://www.databasejournal.com/features/oracle/article.php/3395731/Oracle-10gs-Redo-Logfile-Sizing-Advisor.htm
 para exemplos e refs... Notar também que há muuito tempo (desde 9i iirc) 
já temos o FAST_START_MTTR_TARGET para indicar tempo de recuperabilidade...

  Já no que se refere à performance eu tenho alguns pontos : o primeiro é que, 
ao contrário do que vc parece pensar (julgando pelo que vc escreveu no 
parágrafo em que vc fala de redo) por princípio NÃO HÁ COMO o tamanho grande 
demais de um redo log file interferir na performance, pois a gravação de redo 
no redo log file NÂO IMPLICA em acessar o arquivo todo, o arquivo é aberto em 
APPEND-MODE...
  
 Já um tamanho de redo log file muito pequeno ** SIM **, pode interferir pois 
em princípio independente de outros settings, se um redo log file enche um 
archive deverá ser criado, se esse enchimento for frequente Não só o processo 
de ARCH pode ficar sobrecarregado (já que vai ser acionado a "toda hora") mas 
também o LOG WRITER pode ter que ficar "esperando" o ARCH liberar / confirmar a 
criação de archive antes da geração de novos logs poder avançar É baseado 
mais ou menos nisso que a Oracle recomenda um intervalo de alguns minutos entre 
a geração de cada archive - é um jogo de Equilíbrio entre a segurança e a 
performance, muito embora a questão de Segurança não é tão crítica, pois mesmo 
que vc não tenha o log necessário archivado em caso de crash vc  OBVIAMENTE 
 está MULTIPLEXANDO seus log files, né não ??? 

O resumo da ópera então é : avalie a possibilidade de usar o Advisor, saiba que 
log file muito grande não deve interferir (negativamente ou positivamente) E 
que um log file muito pequeno PODE SIM interferir negativamente - sendo assim, 
eu sempre chuto como valor inicial algo em torno de 500Mb a 1 GB como log file 
size, esses 50 Mb default numa utilização em ambiente Produtivo via de regra 
são ridículos... Aí depois uso o Advisor, analiso os waits referentes a log e 
archive, analiso a diferença de tempos de criação dos archives, por aí...

[]s

  Chiappa