Re: [oracle_br] Re: [licença oracle 9i em VM]

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

Pessoal, falo um pouco sobre virtualização nesse vídeo:
https://www.youtube.com/watch?v=y56a6lkVGoc.

[]s

*Fábio Prado*

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


Em 8 de dezembro de 2016 16:26, '[Paulo Sousa]' paulorso...@gmail.com
[oracle_br]  escreveu:

>
>
> Obrigado pela resposta, Chiappa.
>
> Paulo Sousa
>
> 2016-12-08 15:29 GMT-02:00 jlchia...@yahoo.com.br [oracle_br] <
> oracle_br@yahoogrupos.com.br>:
>
>>
>>
>> Não, colega, primeiro não é só quando entra VM no meio : se vc vai
>> licenciar por servidor (é a opção quando vc não pode licenciar por named
>> users), NECESSARIAMENTE vc tem SIM multiplicadores a aplicar por cada core,
>> cada tipo de processador tem um fator diferente Isso INDEPENDE de se
>> usar VM ou não
>>
>> Entenda também que falamos aqui de servidor, não é da "farm" toda, se vc
>> tem múltiplos servidores independentes... Nem preciso dizer que se vc tiver
>> máquina com n blades, cada blade NÂO É CAPAZ de computar independentente
>> (há um link de comunicação entre eles) então eles não são considerados
>> servidores independentes, nesse caso todos os blades do conjunto compõem um
>> único servidor físico, então esse que vai ser considerado...
>>
>> O ponto crucial a ser considerado quando falamos em Virtualização  tem a
>> ver também com ** qual ** solução de VM vc está usando : independente da
>> versão do RDBMS que vc vai rodar, se vc criar VMs, a Oracle só aceita
>> licenciar só a VM se a solução de virtualização for homologada como
>> HARD-PARTITIONING, ie, cenário onde é garantido que o hardware não- alocado
>> pra VM não participa do processamento da VM de modo algum : esse é o caso
>> para o ORACLE VM (não o Virtualbox, mas o Oracle VM mesmo), para as VMs
>> feitas pelo sistema operacional (zonas no Solaris, LPARs no AIX,
>> domes/VPARs no HP-UX, etc) - http://www.oracle.com/us/corpo
>> rate/pricing/partitioning-070609.pdf é o paper da Oracle que documenta
>> isso... A idéia aqui é que se vc tem, digamos, 4 processadores físicos mas
>> criou uma VM que está amarrada/usa só dois desses, vc s´licencia esses
>> dois, aplicando ofator de custo e de cores apenas para esses dois que estão
>> sendo enxergados/usados pela VM a licenciar, é isso...
>>
>> CASO vc vá utilizar uma solução de virtualização que NÂO SEJA
>> homologada/aceita pela Oracle como HARD-PARTITIONING (é o caso de VMWARE,
>> de Virtualbox, de XEN, de KVM, etc) , absolutamente NÂO IMPORTA quantas VMs
>> de quantos processadores lógicos vc vai criar, para Licenciar vc vai ter
>> que licenciar o SERVIDOR FÍSICO INTEIRINHO, aplicando o fator de custo E os
>> multiplicadores para CADA core Físico de CADA processadore físico
>> presente
>>
>>
>> Dá uma lida no manual de Licenciamento e nos papers Oracle sobre
>> licenciamento que vc obtém a tabela de factors e multipliers a ser usada
>> cada cada tipo de processador
>>
>> []s
>>
>>   Chiappa
>>
>> OBS : afaik tudo o que falei acima vale INDIFERENTEMENTE se for 9i, 10g ,
>> 11g ou que versão for - o Custo para ter o direito de uso (ie, LICENCIAR)
>> independe de versão do RDBMS...
>>  O que vc NÂO VAI TER, de forma alguma, é Suporte (ie, bugfix de qualquer
>> tipo, chamado no Suportte Técnico para assistência, documentos técnicos,
>> etc) em sendo uma versão tão antiga e defasada quanto 9i...
>>
>
> 
>

RE: [oracle_br] Problemas com o Enterprise Manager 12c

['L. Andrade JR' andrad...@uol.com.br [oracle_br]]

[oracle_br] Re: Problemas com o Enterprise Manager 12c

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

Colega, existiram diversas issues de compatibilidade entre versão de Java e 
arquitetura/bitsize do target 
(http://blog.dbi-services.com/oracle-cloud-control-12c-database-target-remains-in-pending-state-sles-x8664-target/
 lista um caso possível), há casos em que vc tem que fazer reload mas 
especificando timeout diferentes 
(http://oraclepoint.com/oralife/2013/07/29/troubleshooting-the-pending-status-for-a-database-target-in-oem-gc-12c/
 exemplifica), para bancos standby vc pode ter que fazer um registro cfrme 
http://www.redstk.com/database-system-target-in-pending-status-for-standby-database-in-oem-12c/
 indica... Talvez vc possa tentar um RESYNC pelo próprio OEM 
(https://www.pythian.com/blog/how-to-fix-a-target-with-a-pending-status-in-oem-12cr2/
 exemplifica)
 Mas minha Sugestão é , antes de tentar essas possibilidades todas, Primeiro 
pesquisar as demais notas metalink referentes a target de database em status 
pending, CHECAR as notas de compatibilidade entre arquiteturas/SOs x versão de 
Java instalada (se for o caso mandar um UPDATE nesse Java!!), e CHECAR a 
possibilidade de bug conhecido, se for o caso aplicando PATCH
 
 []s
 
   Chiappa

[oracle_br] Problemas com o Enterprise Manager 12c

[Wanderson Barrence wbarre...@gmail.com [oracle_br]]

Caros,

Boa tarde!!!

Recentemente nós implementamos aqui na empresa o monitoramento do banco de
dados utilizando o EM 12c, mas estamos tendo muitos problemas com relação a
alguns bancos de dados que não estamos conseguindo resolver, talvez vocês
possam nos ajudar, com conselhos, indicando materiais ou até mesmo algum
curso de enterprise manager.

Nós já instalamos o servidor com banco de dados, e já também instalamos os
agentes em todas as máquinas monitoradas.

O problema é que em algumas máquinas o sistema e o banco de dados estão com
estado "pending" e não conseguimos deixá-los "up". Fora que alguns
servidores o sistema ou o banco de dados ficam com estado "agent
unreachable".

Já tentei:

emctl status agent

emctl upload agent

emctl verifykey

emctl stop agent

emctl clearstate agent

emctl secure agent

emctl config agent addinternaltargets

emctl config agent listtargets

emctl start agent

emctl upload agent

emctl status agent

emctl pingOMS

Mas até agora nada, alguém tem alguma dica, ou conselho do que possa estar
acontecendo?

Muito obrigado!!!

E desde já agradeço pela ajuda de todos.

Att,

Wanderson

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 
#66;height:62px;overflow:hidden;width:62px;}#photos div l

[oracle_br] Re: Duvida na construção de select para locali zar um Nome com ou sem acento (JOÃO e JOAO)

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

Seguinte : vc tem diversas possibilidades pra isso - como vc não diz a Versão 
nem a Edição do seu RDBMS Oracle, nem diz se usa sessões isoladas ou algum tipo 
de pool de conexão pra se conectar no banco, e Também não diz se cada usuário 
da aplicação cria a sua sessão particular com o seu usuário no banco Oracle , 
não podemos dizer qual dessas soluções abaixo seria aplicável
 Estou (já que vc NÂO NOS INFORMA) aqui SUPONDO que a sua aplicação tem os SQLs 
escritos no código-fonte, e que através de algum comando da linguagem/tool de 
desenvolvimento a aplicação se conecta no banco , esses SQLs são enviados pro 
banco e os resultsets são processados na aplicação... 
 
 Isso posto,  de modo geral seriam as soluções  :

a. SE for viável em termos de Armazenamento/gasto de espaço em disco, vc pode 
ter uma coluna que ESPELHA o conteúdo da coluna NM_ENTIDADE mas tirando 
acentos, depois a Aplicação faz a consulta nessa coluna-espelho MAS exibe a 
coluna 'real' : no banco 11g em diante isso seria Automático usando o recurso 
da VIRTUAL COLUMN, em versões mais antigas a Aplicação teria que manter isso OU 
vc teria que ter uma trigger

b. SE cada usuário tem a sua sessão dedicada no banco, E os outros SQLs que vão 
ser executados nessa sessão podem também trabalhar com comparações sem 
acentuação, vc pode Ajustar alguns parâmetros de sessão para que o Oracle faça 
comparações e ordenações desprezando acentos : seriam comandos tipo ALTER 
SESSION SET NLS_COMP=LINGUISTIC; e  ALTER SESSION SET NLS_SORT=BINARY_xx; , one 
esse xx pode ser CI (Case-Insensitive, também ignora maiusc/minusc) ou pode não 
estar presente (só BYNARY) aí respeita  minusc/maiusc, entre outras opções - 
CONSULTE A DOCUMENTAÇÂO DA SUA VERSÃO, isso pode mudar de acordo com a versão 
em uso...
 Isso pode ser feito dentro da aplicação (basta a aplicação mandar o comando 
ALTER SESSION desejado pro banco - isso é SQL (veja que o comando ALTER é  
SIM  um comando SQL, até por isso está DOCUMENTADO NO MANUAL ORACLE DE 
SQL!!), então da mesma maneira que a sua linguagem/tool de programação pe capaz 
de enviar SELECTs pro banco ela DEVE SER CAPAZ de enviar ALTER SESSION), ou 
ENTÃO isso pode ser feito automaticamente pelo RDBMS Oracle quando a sessão é 
criada (veja o item LOGON TRIGGER na doc Oracle).
 
 Uma ** VARIAÇÃO ** da técnica, para 'isolar' o setting de ignorar acentos pra 
uma query, é vc (NO CÓDIGO-FONTE da sua aplicação!) alterar imediatamente antes 
da sua query o ALTER, executar a query e depois voltar o ALTER para o valor que 
estava antes
 
c. a sua idéia de ter uma função que troca os caracteres acentuados é possível 
sim também : a TRANSLATE funciona, é possível também usar outras funções 
built-in do RDBMS Oracle, e tais funções podem ser encapsuladas numa FUNCTION 
sua ou escritas diretamente no SQL da aplicação, sim


==> Porém, temos as questões de performance, SE o volume de dados a pesquisar 
será considerável : pra começo de conversa, se vc tem um índice criado com o 
valor "normal" da coluna X, OBVIAMENTE é isso que está armazenado no índice, se 
vc altera esse conteúdo com uma função qualquer LOGICAMENTE o índice não tem 
mais os mesmos valores então via de regra NÂO será Usado. Pra solucionar 
isso, vc pode criar um índice que indexe a mesma exata função que vc vai usar 
na pesquisa, veja na doc Oracle sobre FUNCTION BASED INDEX...
 Outro ponto é que vc usa % no começo e no fim, isso via de regra ** IMPEDE ** 
a utilização plena de um índice comum, pois o %valor% indica que o valor pode 
estar em QUALQUER posição do índive, aí o RDBMS teria que varrer o índice 
INTEIRINHO SE vc tiver isso instalado e disponível no seu RDBMS Oracle , 
normalmente é muito mais performático para esse tipo de pesquisa um índice do 
tipo TEXT, que é pensado/criado para pesquisas incompletas. Veja na doc as 
refs, E consulte com seu DBA se vc tem o recurso disponível
 
 []s
 
  Chiappa

[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