Re: [oracle_br] Re: select para descobrir o caminho do TNSNAMES?

[Fabiano Lira fabianocl...@gmail.com [oracle_br]]

Vc pode dar um 'where tnsping' no windows.

Ele vai te mostrar todos os clients instalados.

Em 23 de março de 2015 17:34, Eduardo Perdomo panc...@gmail.com [oracle_br]
 escreveu:

>
>
> O problema acontece também quando se instala vários clientes.
> Ou se instala um banco na máquina cliente, como o xe por exemplo. O que eu
> faço é localizar os tnsnames e ir drletando um a um até achar aquele que a
> aplicação está usando. Ou seja reclamar. Ou quando a aplicação não acha o
> banco e tem varios clients. Eu mesclo todos os tnsnames.
> Em 23/03/2015 17:06, "Leandro Tadeu Belpiede ltbelpi...@hotmail.com
> [oracle_br]"  escreveu:
>
>>
>>
>> obrigado pela ajuda de todos
>>
>>
>> --
>> To: oracle_br@yahoogrupos.com.br
>> From: oracle_br@yahoogrupos.com.br
>> Date: Mon, 23 Mar 2015 09:55:38 -0700
>> Subject: [oracle_br] Re: select para descobrir o caminho do TNSNAMES?
>>
>>
>>  Tudo jóia ?? Então, de cara tenho que te dizer que NÃO, esse tipo de
>> informação do cliente não é necessária para o funcionamento do database,
>> então tabela interna NENHUMA, afaik, registra a localização do TNSNAMES.ORA
>> usado para indicar o alvo da conexão, então NÃO TEM COMO se obter isso via
>> SELECT nenhum, okdoc ??
>>  Uma opção seria vc, a partir da máquina-cliente da qual vc quer saber a
>> localização do TNSNAMES.ORA, ter as variáveis necessárias setadas e pedir
>> um TNSPING, esse comando mostra o caminho paara o TNSNAMES que foi usado
>>  Note porém que em condições normais isso  Não é Necessário  :
>> localizar o TNSNAMES.ORA usado é via de regra uma questão simples - SE a
>> variável TNS_ADMIN estiver setada, ela indica o caminho pra ele, E SE a
>> variável não estiver setada, o default é $ORACLE_HOME/network/admin ,
>> simples  Única coisa é que eu disse "em condições normais" porque
>> sempre há as exceções, como por exemplo aplicações que oram programadas
>> para procurar o TNSNAMES.ORA num lugar específico : como um exemplo,
>> algumas versões antigas do TOAD que usei deixavam você indicar o PATH aonde
>> estava o TNSNAMES.ORA, independente das variáveis de ambiente...
>>
>>   []s
>>
>>Chiappa
>>
>> OBS : lembro apenas que se for Windows o Sistema Operacional, além das
>> variáveis de ambiente podemos ter TAMBÉM indicação de localização do
>> TNSNAMES no REGISTRY...
>>
>>
>



-- 
Atenciosamente,
Fabiano Lira.

RE: [oracle_br] Re: select para descobrir o caminho do TNSNAMES?

[Eduardo Perdomo panc...@gmail.com [oracle_br]]

O problema acontece também quando se instala vários clientes.
Ou se instala um banco na máquina cliente, como o xe por exemplo. O que eu
faço é localizar os tnsnames e ir drletando um a um até achar aquele que a
aplicação está usando. Ou seja reclamar. Ou quando a aplicação não acha o
banco e tem varios clients. Eu mesclo todos os tnsnames.
Em 23/03/2015 17:06, "Leandro Tadeu Belpiede ltbelpi...@hotmail.com
[oracle_br]"  escreveu:

>
>
> obrigado pela ajuda de todos
>
>
> --
> To: oracle_br@yahoogrupos.com.br
> From: oracle_br@yahoogrupos.com.br
> Date: Mon, 23 Mar 2015 09:55:38 -0700
> Subject: [oracle_br] Re: select para descobrir o caminho do TNSNAMES?
>
>
>  Tudo jóia ?? Então, de cara tenho que te dizer que NÃO, esse tipo de
> informação do cliente não é necessária para o funcionamento do database,
> então tabela interna NENHUMA, afaik, registra a localização do TNSNAMES.ORA
> usado para indicar o alvo da conexão, então NÃO TEM COMO se obter isso via
> SELECT nenhum, okdoc ??
>  Uma opção seria vc, a partir da máquina-cliente da qual vc quer saber a
> localização do TNSNAMES.ORA, ter as variáveis necessárias setadas e pedir
> um TNSPING, esse comando mostra o caminho paara o TNSNAMES que foi usado
>  Note porém que em condições normais isso  Não é Necessário  :
> localizar o TNSNAMES.ORA usado é via de regra uma questão simples - SE a
> variável TNS_ADMIN estiver setada, ela indica o caminho pra ele, E SE a
> variável não estiver setada, o default é $ORACLE_HOME/network/admin ,
> simples  Única coisa é que eu disse "em condições normais" porque
> sempre há as exceções, como por exemplo aplicações que oram programadas
> para procurar o TNSNAMES.ORA num lugar específico : como um exemplo,
> algumas versões antigas do TOAD que usei deixavam você indicar o PATH aonde
> estava o TNSNAMES.ORA, independente das variáveis de ambiente...
>
>   []s
>
>Chiappa
>
> OBS : lembro apenas que se for Windows o Sistema Operacional, além das
> variáveis de ambiente podemos ter TAMBÉM indicação de localização do
> TNSNAMES no REGISTRY...
>
>

RE: [oracle_br] Re: select para descobrir o caminho do TNSNAMES?

[Leandro Tadeu Belpiede ltbelpi...@hotmail.com [oracle_br]]

obrigado pela ajuda de todos

 
To: oracle_br@yahoogrupos.com.br
From: oracle_br@yahoogrupos.com.br
Date: Mon, 23 Mar 2015 09:55:38 -0700
Subject: [oracle_br] Re: select para descobrir o caminho do TNSNAMES?














 

 



  



  
  
  Tudo jóia ?? Então, de cara tenho que te dizer que NÃO, esse tipo de 
informação do cliente não é necessária para o funcionamento do database, então 
tabela interna NENHUMA, afaik, registra a localização do TNSNAMES.ORA usado 
para indicar o alvo da conexão, então NÃO TEM COMO se obter isso via SELECT 
nenhum, okdoc ??
 Uma opção seria vc, a partir da máquina-cliente da qual vc quer saber a 
localização do TNSNAMES.ORA, ter as variáveis necessárias setadas e pedir um 
TNSPING, esse comando mostra o caminho paara o TNSNAMES que foi usado
 Note porém que em condições normais isso  Não é Necessário  : 
localizar o TNSNAMES.ORA usado é via de regra uma questão simples - SE a 
variável TNS_ADMIN estiver setada, ela indica o caminho pra ele, E SE a 
variável não estiver setada, o default é $ORACLE_HOME/network/admin , 
simples  Única coisa é que eu disse "em condições normais" porque sempre há 
as exceções, como por exemplo aplicações que oram programadas para procurar o 
TNSNAMES.ORA num lugar específico : como um exemplo, algumas versões antigas do 
TOAD que usei deixavam você indicar o PATH aonde estava o TNSNAMES.ORA, 
independente das variáveis de ambiente...

  []s

   Chiappa

OBS : lembro apenas que se for Windows o Sistema Operacional, além das 
variáveis de ambiente podemos ter TAMBÉM indicação de localização do TNSNAMES 
no REGISTRY...



 









  

Re: [oracle_br] RE: Select full

[Bruno N. Barboza]

Muito obrigado pelas respostas!!


Em 14 de janeiro de 2014 17:55,  escreveu:

>
>
>  Bom, faz tempo que "milh€ ¢Ãµes de registros" deixou de ser algo extremo
> am hardware de produ€ ¢Ã§Ã£o, enterprise-class, mas de qquer maneira, eu
> penso nas coisas de sempre, ie :
>
>  a) SE o teu servidor tiver capacidade sobrando (ie, mem€ ¢Ã³ria, banda de
> I/O, CPU, etc) ainda n€ ¢Ã£o usada e dispon€ ¢Ã­vel, vc pode fazer a query
> em paralelo : isso implica que "sess€ ¢Ãµes escravas" ser€ ¢Ã£o abertas e
> alocadas ao mesmo tempo, cada uma lendo um pedacinho da "tabelona" 
> Veja a Documenta€ ¢Ã§Ã£o do RDBMS (especialmente o manual de Concepts e o
> DW Guide da tua vers€ ¢Ã£o) para conceitos, sintaxes e alguns exemplos, e
> sites de refer€ ¢Ãªncia como http://oracledoug.com/px.html e
> https://asktom.oracle.com/pls/asktom/f?p=100:11:0P11_QUESTION_ID:39946845137685para
>  mais detalhes...
>  S€ ¢Ã³ REPITO : vc s€ ¢Ã³ pode pensar nisso ** SE ** realmente vc tem a
> capacidade sobrando no servidor : caso hoje ele j€ ¢Ã¡ esteja no gargalo,
> Muito Provavelmente n€ ¢Ã£o vai haver capacidade de I/O, poder de CPU e
> mem€ ¢Ã³ria livre para fazer frente € ¢Ã  n sess€ ¢Ãµes escravas "atacando"
> ao mesmo tempo...
>
>  b) se assegurar que o sistema operacional e o I/O est€ ¢Ã¡ setado para a
> melhor performance poss€ ¢Ã­vel : por exemplo, € ¢Ã© CR€ ¢Ã’­TICO que o
> ambiente permita I/O As€ ¢Ã­ncrono (Asynchronous I/O) e (via de regra)
> Direct I/O  : Asynch significa que haver€ ¢Ã¡ m€ ¢Ãºltiplos I/Os
> simult€ ¢Ã¢noes, ie , os pr€ ¢Ã³ximos I/Os que sejam independentes daquele
> em execu€ ¢Ã§Ã£o no momento N€ ¢Ã’£O PRECISAM ficar esperando que o atual
> termine... Isso € ¢Ã© IMPRESCIND€ ¢Ã’­VEL em opera€ ¢Ã§Ãµes de full table
> scan que seja usado paralelismo, ajuda em muito via de regra paraque as
> sess€ ¢Ãµes escravas n€ ¢Ã£o fiquem esperando umas pelas outras...
>J€ ¢Ã¡ o Direct I/O significa que os dados lidos s€ ¢Ã£o enviados
> diretamente para o RDBMS, que j€ ¢Ã¡ tem buffers e caches Pr€ ¢Ã³prios,
> n€ ¢Ã£o se perdendo tempo em se fazer o Sistema Operacional copiar o que
> foi lido para os buffers/caches de sistema operacional Via de regra
> esse setting € ¢Ã© Positivo para a performance...
>   alguns ajustes do sub-sistema de I/O (como striping size, balanceamento
> de discos, etc) podem tamb€ ¢Ã©m influenciar se vc est€ ¢Ã¡ usando um
> storage de discos : isso € ¢Ã© algo a se alinhar com os sysadmins e time de
> storage
>
>  c)   n€ ¢Ã£o com se assegurar que o armazenamento interno est€ ¢Ã¡ OK, e
> que as configs de DB est€ ¢Ã£o apropriadas : por exemplo, o RDBMS ao fazer
> um full-table scan l€ ¢Ãª uma por€ ¢Ã§Ã£o de blocos cont€ ¢Ã­guos, o
> chamado EXTENT : se a tabela tiver sido criada com extents muito
> pequenos/consistentemente menores do que o m€ ¢Ã¡ximo de bytes que o
> sistema operacional pode ler, OU se o tamanho do extent n€ ¢Ã£o for um
> m€ ¢Ãºltiplo exato do tamanho m€ ¢Ã¡ximo de I/O do sistema operacional, ao
> inv€ ¢Ã©s de um I/O ser€ ¢Ã£o necess€ ¢Ã¡rios dois para ler o mesmo
> extent Outros pontos, ainda dentro do database :
>- pode valer a pena (via ALTER SESSION) setar temporariamente o
> par€ ¢Ã¢metro DB_FILE_MULTIBLOCK_READ_COUNT para um n€ ¢Ãºmero de blocos
> que se equipare ao m€ ¢Ã¡ximo I/O do sistema operacional
>- vc ** TEM ** que garantir que os dados da tal tabela est€ ¢Ã£o
> gravados em extents com o ** m€ ¢Ã­nimo poss€ ¢Ã­vel ** de espa€ ¢Ã§o em
> branco e/ou blocos alocados mas n€ ¢Ã£o usados - o objetivo aqui € ¢Ã©,
> mais uma vez, diminuir ao m€ ¢Ã¡ximo a qtdade de blocos (e portanto a
> qtdade de I/Os) necess€ ¢Ã¡ria para se recuperar a informa€ ¢Ã§Ã£o...
> E que fique claro : blocos com espa€ ¢Ã§o em branco e/ou n€ ¢Ã£o
> usados podem resultar tanto das op€ ¢Ã§Ãµes de controle de armazenamento da
> tabela (exemplo, o porcentual de espa€ ¢Ã§o que o RDBMS reserva para
> futuros UPDATEs) quanto de DMLs , como DELETEs que removeram os dados mas o
> espa€ ¢Ã§o n€ ¢Ã£o foi reusado, ou de opera€ ¢Ã§Ãµes de APPEND de dados ...
>
>  d) vc VAI se assegurar, dentro do poss€ ¢Ã­vel, que a rotina ser€ ¢Ã¡
> agendada para uma data/hora em que n€ ¢Ã£o est€ ¢Ã£o sendo feitos grandes
> DMLs na tal tabela grande : a quest€ ¢Ã£o € ¢Ã© que, para se assegurar que
> n€ ¢Ã£o h€ ¢Ã¡ leitura suja, de dados n€ ¢Ã£o-comitados, durante DMLs a
> informa€ ¢Ã§Ã£o consistente € ¢Ã© armazenada em undo blocks, que significam
> mais I/Os extras
>
>  []s
>
>Chiappa
>
>



--
Att,
Bruno N. Barboza

Re: [oracle_br] Re: Select … for update … nowait

[JLSilva]

Tá certo, chefe.
Obrigado.

On Mar 19, 2013, at 12:52 PM, "J. Laurindo Chiappa"  
wrote:

> Então, achei que estava claro mas pelo jeito não ficou : 
> 
> a) "será que existe uma forma de auxiliá-lo a melhorar a situação?".
> 
>  A ÚNICA forma segura e adequada é o Fornecedor corrigir a aplicação, não 
> ficando indefinidamente tentando lockar o objeto, PONTO. Enquanto isso não 
> ocorre, o que vc pode fazer como Paliativo é o
>  que eu indiquei em msgs anteriores, ie :
> 
>1. SE vc quer serializar completamente (ie, se quando já há alguém 
> executando o processo vc quer que as outras sessões que tentem executar 
> simultaneamente falhem, com aviso) , vc pode ter alguma tela/programa que o 
> usuário executa antes de entrar na rotina e checa se a rotina já está em 
> execução em outra sessão , abortando
> 
>2. SE não é serialização completa o que vc quer :
> 
> - caso o processo chega a terminar depois de demorar muito, fazer algum 
> TUNING no processo para que ele termine o mais rapidamente possível e assim a 
> sessão A mantenha o lock o mínimo possível e libere o lock para a sessão B 
> processar, e B terminando o mais rápido possível libera o quanto antes C, 
> assim por diante
> 
> e/ou
> 
> - vc faz o que a aplicação não faz, ie, ENCERRA  a transação que está 
> demorando muito : para isso (provavelmente num job que rode a cada x 
> minutos), vc Identifica a sessão que obteve o lock , OU então coloca um 
> PROFILE limitando o tempo de conexão
> 
> e é ISSO o quew vc pode fazer, sim ?? E como identificar os envolvidos, 
> vide abaixo...
> 
> 
> b)  "quem está bloqueando ***QUEM***"
> 
>  Esse é o ponto PRINCIPAL das minhas respostas, que pelo jeito não ficou 
> Claro : as outras sessões que estão num loop aguardando para obter o lock *** 
> NÂO ESTÃO BLOQUEADAS, elas estão acessando o objeto e tentando obter o lock, 
> mas ainda NÃO o obtiveram, sim ??? Não há LOCK WAIT aí, captou ??? Então, 
> para "quem está bloqueando" a resposta é, NINGUÉM, não há Bloqueio, não há 
> LOCK... E IMPORTANTE : como não há locks, não há uma FILA de espera, as n 
> sessões que estão acessando o objeto lockado para tentar obter o lock NÂO vão 
> ser atendidas por ordem, eu mostrei isso ...
>   O que há na verdade é ACESSO constante ao objeto que está lockado na 
> Tentativa de obter um lock, sim ??? E como vc identifica um objeto lockado ? 
> pelas views de lock, como mostrei Como vc identifica as sessões que estão 
> CONSTANTEMENTE, pesadamente, tentando e tentando e tentando acessar esse 
> objeto lockado ? Pelo evento de concorrência, como mostrei. E como vc SABE 
> que esse acesso constante é para obter lock com FOR UPDATE NOWAIT ?? Vc 
> consulta o SQL que está sendo enviado pelas sessões sofrendo de Concurrency E 
> confere se é o SELECT FOR UPDATE NOWAIT, okdoc ???
> 
>   Então ESSA é a resposta : não há bloqueio, há Acesso Constante a um objeto 
> bloqueado, e para Identificar esse cenário vc faz o que eu disse acima e 
> mostrei no meu exemplo, tá bem ?? Afora isso não sei realmente o que mais 
> dizer...
> 
>[]s
> 
>  Chiappa
> 
> --- Em oracle_br@yahoogrupos.com.br, JLSilva  escreveu
>> 
>> Chiappa, gosto muito do nível de detalhes que vc responde, colocando bons 
>> exemplos e sempre muito úteis.
>> Mas, vejo que você apenas está repetindo o que eu disse na minha primeira 
>> mensagem.
>> Parafraseando seu modo de escrever:
>> Eu ***JÁ*** sei que é um select for update nowait. Ja identifiquei isto, por 
>> isso enviei o meu primeiro email, pois não tenho como evitar qua a aplicação 
>> faça o que está fazendo.
>> Eu ***JÁ*** sei que é a aplicação que ***DEVERIA 
>> encerrar a transação. Mas, com eu ***JÁ*** disse: a aplicação ***NÃO O 
>> FAZ***.
>> Eu achei que tinha deixado claro qual era a minha intenção ao perguntar se 
>> alguém conhece uma maneira de desativar um nowait: a aplicação está fazendo 
>> caca, e o cliente está sofrendo a consequencia, portanto "será que existe 
>> uma forma de auxiliá-lo a melhorar a situação?".
>> 
>> O que eu gostaria de responder é:
>> Quem está bloqueando ***QUEM*** (não "oque", ok?) O "que" está esperando eu 
>> já sei, é uma determinada tabela. O problema é descobrir a ordem dessa fila, 
>> para fazer o deadlock manualmente e adequadamente. Ok?
>> 
>> On Mar 18, 2013, at 9:16 PM, "J. Laurindo Chiappa"  wrote:
>> 
>>> Nope, veja as minhas outras msgs com demonstrações (que provavelmente não 
>>> te chegaram antes de vc escrever esta), que :
>>> 
>>> - é CLARO que as sessões estão SIM esperando por algo, sessão que não 
>>> espera por nadaé IMPOSSÍVEL 
>>> 
>>> - é Claro que (ao menos desde a introdução do 10g) o banco Registra sim na 
>>> V$SESSION o SQL_ID sendo executado, a Espera, o objeto causando a espera, a 
>>> CLASSE da espera, então tanto DÁ SIM para vc identificar sessões acessando 
>>> sempre e sempre o mesmo objeto QUANTO dá para vc identificar que o SQL é 
>>> com NOWAIT, o que fecha o cenário que vc

Re: [oracle_br] Re: Select … for update … nowait

[JLSilva]

Chiappa, gosto muito do nível de detalhes que vc responde, colocando bons 
exemplos e sempre muito úteis.
Mas, vejo que você apenas está repetindo o que eu disse na minha primeira 
mensagem.
Parafraseando seu modo de escrever:
Eu ***JÁ*** sei que é um select for update nowait. Ja identifiquei isto, por 
isso enviei o meu primeiro email, pois não tenho como evitar qua a aplicação 
faça o que está fazendo.
Eu ***JÁ*** sei que é a aplicação que ***DEVERIA encerrar a 
transação. Mas, com eu ***JÁ*** disse: a aplicação ***NÃO O FAZ***.
Eu achei que tinha deixado claro qual era a minha intenção ao perguntar se 
alguém conhece uma maneira de desativar um nowait: a aplicação está fazendo 
caca, e o cliente está sofrendo a consequencia, portanto "será que existe uma 
forma de auxiliá-lo a melhorar a situação?".

O que eu gostaria de responder é:
Quem está bloqueando ***QUEM*** (não "oque", ok?) O "que" está esperando eu já 
sei, é uma determinada tabela. O problema é descobrir a ordem dessa fila, para 
fazer o deadlock manualmente e adequadamente. Ok?

On Mar 18, 2013, at 9:16 PM, "J. Laurindo Chiappa"  
wrote:

> Nope, veja as minhas outras msgs com demonstrações (que provavelmente não te 
> chegaram antes de vc escrever esta), que :
> 
>  - é CLARO que as sessões estão SIM esperando por algo, sessão que não espera 
> por nadaé IMPOSSÍVEL 
> 
>  - é Claro que (ao menos desde a introdução do 10g) o banco Registra sim na 
> V$SESSION o SQL_ID sendo executado, a Espera, o objeto causando a espera, a 
> CLASSE da espera, então tanto DÁ SIM para vc identificar sessões acessando 
> sempre e sempre o mesmo objeto QUANTO dá para vc identificar que o SQL é com 
> NOWAIT, o que fecha o cenário que vc descreve - INCLUSIVE, ao menos por mim 
> essa foi uma das mais festejadas alterações no 10g, junto com a AUTOMAÇÂO das 
> estatísticas de execução de um SQL longo na V$SQL... Só quem teve o desprazer 
> de trabalhar com versões anteriores pode avaliar o quão útil isso é
> 
>  - é VERDADE que não há como vc identificar o REGISTRO já lockado e sendo 
> acessado constantemente via for update nowait em um loop, Mas como eu mostrei 
> vc consegue Sim identificar as sessões constantemente acessando o mesmo 
> OBJETO e aí pelo SQL dessas sessões vc Comprova ou não que é esse caso do 
> NOWAIT
> 
> 
>  ==> e só para deixar Escrupulosamente Claro : quem TEM que fazer COMMIT ou 
> ROLLBACK é a sessão A, que obteve o lock e o está mantendo, SIM ???  A falha 
> da Aplicação é que ela NEM limita o tempo que A fica com a transação aberta e 
> mantendo o LOCK, e NEM (mesmo ela, Aplicação) sabendo que PODEM haver 
> transações erradamente abertas por muito muito tempo, nem mesmo assim ela 
> aplica algum LIMITE na qtdade de vezes e/ou no tempo que fica esperando A 
> liberar o lock com o encerramento da Transação 
> 
>[]s
>   
> Chiappa
> 
> 
> --- Em oracle_br@yahoogrupos.com.br, JLSilva  escreveu
>> 
>> Chiappa,
>> Agradeço o tempo que você despendeu para analisar o caso, mas devo discordar 
>> totalmente de você, amigo.
>> 1. Veja, não há nenhuma sessão esperando nada.. o select for update está 
>> usando NOWAIT, que é justamente para não esperar.. Ocorre o ORA-00054, e a 
>> aplicação tenta bloquear o registro novamente, e ocorre novamente o 
>> ORA-00054, e tenta novamente.. nesse processo, ela nunca faz 
>> commit/rollback, entende..? A sessão nunca fica numa longa espera por lock...
>> 2. Não é possível identificar exatamente quem está bloqueando quem, já que 
>> não tenho como saber qual registro uma sessão está bloqueando sem ter 
>> antecipadamente ativado um trace. O máximo que consigo é verificar todas as 
>> sessões que têm uma transação aberta em uma tabela.. mas não em qual 
>> registro, correto?
>> 3. Absolutamente verdadeiro quando digo que nunca vai terminar esse loop: 
>> veja que é como um deadlock, mas sem o mecanismo de deadlock do Oracle, uma 
>> vez que a aplicação é que fica num loop eterno tentando bloquear um registro 
>> que está blqueado por outra sessão, sendo que essa outra sessão nunca vai 
>> fazer commit/rollback já que ela também está tentando bloquear registros que 
>> estão bloqueados pela outra sessão.
>> 
>> On Mar 18, 2013, at 7:39 PM, "J. Laurindo Chiappa"  wrote:
>> 
>>> Hmmm, peraí : "nunca vai sair" é absolutamente Falso : o lock que A está 
>>> mantendo (e que impede B de lockar o mesmo recurso) *** NÃO *** é Eterno, 
>>> ele VAI SIM ser liberado assim que A encerrar a transação, seja com COMMIT 
>>> seja com ROLLBACK, yes ??? Da mesma maneira, dizer que é "impossível 
>>> identificar quem está lockando registros de quem" sorry, mas afaik é 
>>> Inverdade também : via script é Plenamente Possível vc consultar quem está 
>>> esperando pelo que, aí não é impossível não vc localizar quem está com o 
>>> lock para si, os outros TODOS estão em espera por essa sessão, dado o 
>>> cenário que vc descreve...
>>> 
>>>  O que é Questionável, podendo mesmo ser c

Re: [oracle_br] Re: Select … for update … nowait

[JLSilva]

Chiappa,
Agradeço o tempo que você despendeu para analisar o caso, mas devo discordar 
totalmente de você, amigo.
1. Veja, não há nenhuma sessão esperando nada.. o select for update está usando 
NOWAIT, que é justamente para não esperar.. Ocorre o ORA-00054, e a aplicação 
tenta bloquear o registro novamente, e ocorre novamente o ORA-00054, e tenta 
novamente.. nesse processo, ela nunca faz commit/rollback, entende..? A sessão 
nunca fica numa longa espera por lock...
2. Não é possível identificar exatamente quem está bloqueando quem, já que não 
tenho como saber qual registro uma sessão está bloqueando sem ter 
antecipadamente ativado um trace. O máximo que consigo é verificar todas as 
sessões que têm uma transação aberta em uma tabela.. mas não em qual registro, 
correto?
3. Absolutamente verdadeiro quando digo que nunca vai terminar esse loop: veja 
que é como um deadlock, mas sem o mecanismo de deadlock do Oracle, uma vez que 
a aplicação é que fica num loop eterno tentando bloquear um registro que está 
blqueado por outra sessão, sendo que essa outra sessão nunca vai fazer 
commit/rollback já que ela também está tentando bloquear registros que estão 
bloqueados pela outra sessão.

On Mar 18, 2013, at 7:39 PM, "J. Laurindo Chiappa"  
wrote:

>  Hmmm, peraí : "nunca vai sair" é absolutamente Falso : o lock que A está 
> mantendo (e que impede B de lockar o mesmo recurso) *** NÃO *** é Eterno, ele 
> VAI SIM ser liberado assim que A encerrar a transação, seja com COMMIT seja 
> com ROLLBACK, yes ??? Da mesma maneira, dizer que é "impossível identificar 
> quem está lockando registros de quem" sorry, mas afaik é Inverdade também : 
> via script é Plenamente Possível vc consultar quem está esperando pelo que, 
> aí não é impossível não vc localizar quem está com o lock para si, os outros 
> TODOS estão em espera por essa sessão, dado o cenário que vc descreve...
> 
>   O que é Questionável, podendo mesmo ser considerado uma FALHA no aplicativo 
> é esse comportamento de :
> 
>1. deixar a transação que obteve o lock ficar ILIMITADAMENTE aberta, sem 
> nenhum tipo de timeout, nem de aviso ao Operador se a transação for 
> controlada pelo Usuário da aplicação e não for encerrada o mais logo possível
>   
>   e
>   
>   2. dado o fato 1. acima (de poder existir Transação sem controle 
> estrito de tempo), após a Aplicação corretamente usar o for update nowait 
> para testar se um recurso está lockado, quando detectar que um 
> registro/resource está lockado (recebendo o ORA-0054) a Aplicação ficar 
> tentando e retentando o lock INDEFINIDAMENTE é falha - o correto ao invés 
> seria LIMITAR a quantidade de vezes em que espera o lock ser liberado (via 
> LOOP ** não-eterno **, repetido uma qtdade FIXA de vezes) E/OU limitar o 
> período de tempo em que espera o lock já presente ser encerrado com o fim 
> datransação que o criou...
> 
> Agora entendi, é uma falha de Controle/Tratamento pela Aplicação no 
> procedimento de LOCK NOWAIT, que em si está Corretíssimo e Não deveria causar 
> espanto algum, ok... 
> 
>  Muito bem, o que vc vai poder fazer aí a nível de banco de dados, Enquanto a 
> Aplicação não tem essa falha corrigida é fazer no banco de dados o que a 
> Aplicação não faz, ie, LIMITAR a duração de uma transação (e portanto limitar 
> o tempo que um lock pode existir), OU então eliminar esses casos, o que 
> poderia ser feito via :
> 
>  a) implementação algum tipo de timeout nas sessões (via PROFILE, talvez), 
> para que uma sessão A que obteve um lock num dado recurso NÂO fique com 
> transações abertas por tempo irrazoavelmente longo, assim limitando o tempo 
> que B fica esperando pelo lock
> 
> e/ou
> 
>  b) tendo um JOB no banco que a cada poucos x minutos consulta a V$SESSION 
> e/ou a DBA_LOCKS e/ou views de WAIT, e se detectar espera muito longa por 
> locks o JOB poderia mandar um e-mail para te avisar e/ou matar a sessão 
> incial que implantou o lock (REGISTRANDO essa ação nalgum lugar, é Claro), 
> coisa do tipo
> 
>  []s
> 
>Chiappa
> 
> 
> --- Em oracle_br@yahoogrupos.com.br, JLSilva  escreveu
>> 
>> Chiappa, o meu espanto é devido à lógica utilizada na aplicação.
>> Se o registro está lockado, o processo entra em um loop e tenta novamente 
>> executar exatamente o mesmo select for update nowait para lockar o registro.
>> O efeito cascata disso é que, ao fazer isto, a sessão A não libera os 
>> registros anteriores e continua tentando lockar novos registros que estão 
>> lockados pela sessão B.
>> Enquanto isso, a sessão B que está lockando outros registros, e em um 
>> determinado momento, a sessão B vai tentar lockar o registro que está 
>> lockado pela sessão A.
>> Se não fosse utilizado o "nowait" nesse select, ocorreria um deadlock, pois 
>> A está locando o registro 1, B está locando o registro 2, A tenta locar o 
>> registro 2 e B tenta locar o registro 1.
>> Mas, devido à forma que a aplicação foi construída, o deadlock nunca ocorre, 
>> e a aplicação nun

Re: [oracle_br] Re: Select … for update … nowait

[JLSilva]

Chiappa, o meu espanto é devido à lógica utilizada na aplicação.
Se o registro está lockado, o processo entra em um loop e tenta novamente 
executar exatamente o mesmo select for update nowait para lockar o registro.
O efeito cascata disso é que, ao fazer isto, a sessão A não libera os registros 
anteriores e continua tentando lockar novos registros que estão lockados pela 
sessão B.
Enquanto isso, a sessão B que está lockando outros registros, e em um 
determinado momento, a sessão B vai tentar lockar o registro que está lockado 
pela sessão A.
Se não fosse utilizado o "nowait" nesse select, ocorreria um deadlock, pois A 
está locando o registro 1, B está locando o registro 2, A tenta locar o 
registro 2 e B tenta locar o registro 1.
Mas, devido à forma que a aplicação foi construída, o deadlock nunca ocorre, e 
a aplicação nunca vai sair desse loop.
Agora, imagine isto ocorrendo com muitas sessões (mais de 10 sessões).
Acaba que tem várias sessões lockando registros, elas não liberam esses 
registros, e ficam tentando locar novos registros que já estão lockados por 
outras, e ficam nesse loop. Fica impossível identificar quem está lockando 
registros de quem.
Infelizmente, o fornecedor é daquele tipo difícil, e diz que "o sistema está 
funcionando em 200 outros locais". Ok, mas aqui está ocorrendo esse problema...
Mas, concordo com você. Desativar o nowait teria um resultado muito 
imprevisível para o funcionamento do rdbms como um todo.

On Mar 18, 2013, at 5:30 PM, "J. Laurindo Chiappa"  
wrote:

>  Bom, vamos começar respondendo à sua pergunta : Não, em princípio afaik 
> (salvo alguma alteração PESADA, não-suportada e EXTREMAMENTE perigosa de 
> interferir no banco como um todo, tipo via parâmetros internos, OU então 
> jogando-se o parâmetro de compatibility lá embaixo pra alguma versão antiga, 
> etc ) no caso não há como vc alterar o comportamento do comando "SELECT FOR 
> UPDATE NOWAIT", não... Aliás, de modo geral, Não Há como vc fazer um dado 
> comando que está documentado agir assim ou assado agir de outro jeito, não...
> 
> Isso respondido, observo que vc está "espantado" com a utilização, e nem 
> imagino porque : veja vc, é ABSOLUTAMENTE normal e documentado (vide manual 
> "Oracle® Database Advanced Application Developer's Guide" cap. 1 - SQL 
> Processing for Application Developers , e algumas entradas sobre LOCKs no 
> Concepts) que é EXATAMENTE ASSIM que vc "pergunta" se um registro está 
> lockado ou não : vc tenta fazer um lock com NOWAIT e se der ORA-0054 ele tá 
> lockado, se não der não está... Eu ABSOLUTAMENTE NÃO ENTENDI a sua 
> "admiração", os "!!!" que vc colocou na msg, sim  Também Não Entendi 
> porque vc quer mudar isso - é Absolutamente Normal que um recurso 
> (tabela/registro/whatever) possa ser acessado em modo exclusivo, corretamente 
> o teu Aplicativo CHECA isso, e vc quer remover esse check ?? Não entendo 
> porque - diga para nós EXATAMENTE o que vc quer que a gente tenta sugerir 
> algo
> 
> []s
> 
>   Chiappa
> 
> 
> --- Em oracle_br@yahoogrupos.com.br, JLSilva  escreveu
>> 
>> Senhores, boa tarde.
>> Temos uma aplicação de terceiros (CHB) que faz "select ... for update ... 
>> NOWAIT".
>> Essa aplicação recebe o erro ORA-00054 e o tratamento que ela dá é: tenta o 
>> select novamente!!!
>> Com isso, não ocorre o deadlock, nem consigo saber exatamente quem é o 
>> bloqueador, pois há dezenas de sessões atualizando a mesma tabela.
>> Alguém aí sabe se é possível desativar o "nowait" através de algum 
>> parâmetro/configuração do banco?
>> Obrigado!
>> 
> 
> 
> 
> 
> 
> 
> --
>> 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: [oracle_br] Re: Select

[Carlos Pinto]

Agora da-me este erro 

 

ORA-00934: group function is not allowed here

 

Estas tambem a selecionar o group by max(data),valor….Funciona?



 

 

 

Carlos Pinto

 

De: oracle_br@yahoogrupos.com.br [mailto:oracle_br@yahoogrupos.com.br] Em
nome de Ricardo
Enviada: terça-feira, 9 de Agosto de 2011 11:19
Para: oracle_br@yahoogrupos.com.br
Assunto: [oracle_br] Re: Select

 

  

Bom dia!

tente usar:
-
select max(data) as data, valor

from alt3

where tar = '14000' and key = '21' and nat = 'AD' group by max(data),valor
--

fiz o teste aq e funcionou assim.
boa sorte!

--- Em oracle_br@yahoogrupos.com.br 
, "Carlos Pinto"  escreveu
>
> Ola a Todos, mais uma ajuda.
> 
> 
> 
> select data, valor 
> 
> from alt3 
> 
> where tar = '14000' and key = '21' and nat = 'AD'
> 
> 
> 
> Estou a executar este select e a informação que dá é a seguinte:
> 
> 
> 
> Data - Valor
> 
> 12-07-2004 - 8,5
> 
> 12-07-2004 - 8,5
> 
> 01-03-2011 - 2,5
> 
> 01-03-2011 - 2,5
> 
> 
> 
> 
> 
> A informação que necessitava era o MAX data e o valor respectivo dessa
data.
> 
> 
> 
> 
> 
> 
> 
> Carlos Pinto
> 
> 
> 
> 
> 
> [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] Re: select if ..

[GILBERTO MEDEIROS DE SOUZA]

Tente usar no seu select a instrução DECODE que simula um comando IF dentro do seu select:
   
  DECODE(col|expr, compara1, resultado1
  [, compara2, resultado2, ...],
  valor_omissao)
   
  select decode (tipcli, 'F', to_char(cgcent,'999.999.999-99'), 'J',
to_char(cgcent,'99.999.999/-99')) tipcli, codcli, nomcli 
 from e085cli
   
  Espero ter ajudado.
   
  

jlchiappa <[EMAIL PROTECTED]> escreveu:
  Eduardo, na verdade isto não se aplica em lugar NENHUM do Oracle, não
existe uma função chamada IF(), no dialeto SQL do bd Oracle a função
de decisão se chama CASE, consulte o manual "oracle SQL Reference" que
vc acha a sintaxe completa dela, e alguns exemplos.

[]s

Chiappa

--- Em oracle_br@yahoogrupos.com.br, "Eduardo - Wat Alimentos Ltda"
escreveu
>
> Galera, onde está errado nesta condição, ou isto não aplica-se
exatamente aki ...
> 
> select if(tipcli='F', to_char(cgcent,'999.999.999-99'),
to_char(cgcent,'99.999.999/-99')), codcli, nomcli 
> from e085cli
> 
> [As partes desta mensagem que não continham texto foram removidas]
>






--
Atenção! As mensagens deste grupo são de acesso público e de inteira responsabilidade de seus remetentes.
Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/ 
--__

Este Grupo recebe o apoio da SQL Magazine - www.devmedia.com.br/sqlmagazine 
__
O grupo Oracle_br não aceita anexos. Quando oferecer algum arquivo, tenha o link do mesmo para evitar trafego(pedidos) desnecessário. 
Links do Yahoo! Grupos









    
-
 Abra sua conta no Yahoo! Mail - 1GB de espaço, alertas de e-mail no celular e anti-spam realmente eficaz. 

[As partes desta mensagem que não continham texto foram removidas]







--
Atenção! As mensagens deste grupo são de acesso público e de inteira responsabilidade de seus remetentes.
Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/ 
--__

Este Grupo recebe o apoio da SQL Magazine - www.devmedia.com.br/sqlmagazine 
__
O grupo Oracle_br não aceita anexos. Quando oferecer algum arquivo, tenha o link do mesmo para evitar trafego(pedidos) desnecessário.





  




  
Yahoo! Grupos, um serviço oferecido por:
  
  
PUBLICIDADE




  
  



  




  
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:[EMAIL PROTECTED] 
O uso que você faz do Yahoo! Grupos está sujeito aos Termos do Serviço do Yahoo!.

Re: [oracle_br] Re: Select into

[Aline Rios]

Boa tarde!
Já consegui resolver.
  De qualquer forma, muito obrigada pela ajuda e atenção!
  Sds.

nabilna10 <[EMAIL PROTECTED]> escreveu:
  Oi Aline,
Me diz uma coisa, onde voce esta preenchendo o parametro de saida, 
o p_retorno ?

[]s
Nabil

--- Em oracle_br@yahoogrupos.com.br, Aline Rios 
escreveu
>
> Pessoal, boa tarde!
> Tenho uma procedure que faz um select-into, mas que não está 
funcionando.
> No ambiente de teste ela funciona, mas no de homologação não.
> Ela não dá erro oracle algum, mas não insere os registros.
> Fazendo o select sem o into, os registros são selecionados 
normalmente.
> Segue abaixo o código.
> Agradeço se alguém tiver alguma sugestão.
> Sds.
> 
> procedure insEndereco(p_matricula in 
siape.cadastropessoal.matricula%type,
> p_seq_pessoa in pessoa.seq_pessoa%type,
> p_retorno out number)
> is
> v_rua endereco.rua%type;
> v_numero endereco.numero%type;
> v_complemento endereco.complemento%type;
> v_bairro endereco.bairro%type;
> v_cidade endereco.cidade%type;
> v_cep endereco.cep%type;
> v_cod_estado estados.codestado%type; 
> begin
> SELECT E.LOGRADOURO,
> E.NUMERO,
> E.COMPLEMENTO,
> E.BAIRRO,
> E.CIDADE,
> E.CEP,
> (select codEstado from estados where estados.siglaestado 
= e.uf)
> INTO v_rua,
> v_numero,
> v_complemento,
> v_bairro,
> v_cidade,
> v_cep,
> v_cod_estado 
> FROM SIAPE.CADASTROPESSOAL C,
> SIAPE.ENDERECO E
> WHERE C.MATRICULA = p_matricula
> AND C.MATRICULA = E.MATRICULA
> AND E.TIPO = 'S';
> 
> 
> -
> Novidade no Yahoo! Mail: receba alertas de novas mensagens no seu 
celular. Registre seu aparelho agora!
> 
> [As partes desta mensagem que não continham texto foram removidas]
>







--
Atenção! As mensagens deste grupo são de acesso público e de inteira responsabilidade de seus remetentes.
Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/ 
--__

Este Grupo recebe o apoio da SQL Magazine - www.devmedia.com.br/sqlmagazine 
__
O grupo Oracle_br não aceita anexos. Quando oferecer algum arquivo, tenha o link do mesmo para evitar trafego(pedidos) desnecessário. 
Links do Yahoo! Grupos







  


    
-
 Yahoo! doce lar. Faça do Yahoo! sua homepage.

[As partes desta mensagem que não continham texto foram removidas]







--
Atenção! As mensagens deste grupo são de acesso público e de inteira responsabilidade de seus remetentes.
Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/ 
--__

Este Grupo recebe o apoio da SQL Magazine - www.devmedia.com.br/sqlmagazine 
__
O grupo Oracle_br não aceita anexos. Quando oferecer algum arquivo, tenha o link do mesmo para evitar trafego(pedidos) desnecessário.





  




  
Yahoo! Grupos, um serviço oferecido por:
  
  
PUBLICIDADE




  
  



  




  
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:[EMAIL PROTECTED] 
O uso que você faz do Yahoo! Grupos está sujeito aos Termos do Serviço do Yahoo!.

Re: [oracle_br] Re: Select reduzido

[André_Oracle]

Marcio Portes escreveu:
> Totalizar o que? Agrupado pelo o que?
> Exemplo da tabela e o que está tentando fazer são bem-vindos.
>
>
> --- Em oracle_br@yahoogrupos.com.br, André_Oracle
> <[EMAIL PROTECTED]> escreveu
> >
> > Caros amigos...
> > Montei um select na minha tabela de movimentação de estoque que me
> dá o
> > seguinte resultado.
> >
> > *Cod   qtdevalor   total*
> > 1  1   5,00  5,00
> > 1  2   5,00 10,00
> >
> > O que eu precisava era  mostrar apenas uma linha totalizada da
> seguinte
> > forma:
> >
> > *Cod   qtdevalor   total*
> > 1  35,0015,00
> >
> > Vcs poderiam me ajudar?
> >
> > Obrigado.
> >
> > André
> >
>
>
>
>
>
>
>
> --
> Atenção! As mensagens deste grupo são de acesso público e de inteira 
> responsabilidade de seus remetentes.
> Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/
> --__
>
> Este Grupo recebe o apoio da SQL Magazine - 
> www.devmedia.com.br/sqlmagazine
> __
> O grupo Oracle_br não aceita anexos. Quando oferecer algum arquivo, 
> tenha o link do mesmo para evitar trafego(pedidos) desnecessário.
>
>
> 
> *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:
>   [EMAIL PROTECTED]
>   
>
> * O uso que você faz do Yahoo! Grupos está sujeito aos Termos do
>   Serviço do Yahoo! .
>
>
Caro Márcio, obrigado pela atenção...

Acabo de resolver o problema.
Segue o código certo :

Select mo.cdmaterial CODIGO,
   m.nomaterial  DESCRICAO, 
   sum(round(mo.qtmovimento,2))   
QTDE_VENDIDA,
   sum(round(mo.vlunitario,2))
VL_VENDIDO,
  -- sum(round(mo.vlunitario * mo.qtmovimento ,2))  
SUBTOTAL,
   sum(round(mo.vlunitario * mo.qtmovimento ,2))* 
sum(round(mo.qtmovimento,2)) SUBTOTAL2,
   sum(nvl(mo.vlcustomedio,me.vlcustomedio))  CUSTO_MEDIO_SEM_ICMS,
   
roundsum(mo.vlunitario)/sum(nvl(mo.vlcustomedio,me.vlcustomedio)))*100)-100),2)
  
MARGEM

from movimento mo,
 material_empresa me,
 material m
 
where mo.cdmaterial = me.cdmaterial
and   mo.cdempresa  = me.cdempresa
and   mo.cdunidademedida = me.cdunidademedida
and   mo.cdmaterial = m.cdmaterial
and   mo.cdhistorico = 40.01 -- vendas
and  mo.dtmovimento between '01/03/2006' and '31/03/2006'
--and mo.cdmaterial = 1
group by
   mo.cdmaterial ,
   m.nomaterial 
order by mo.cdmaterial ,
   m.nomaterial

O que estava faltando era o group by dessa forma que está agora...


Mais uma vez obrigado pela atenção.


André



--
Atenção! As mensagens deste grupo são de acesso público e de inteira 
responsabilidade de seus remetentes.
Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/ 
--__

Este Grupo recebe o apoio da SQL Magazine - www.devmedia.com.br/sqlmagazine 
__
O grupo Oracle_br não aceita anexos. Quando oferecer algum arquivo, tenha o 
link do mesmo para evitar trafego(pedidos) desnecessário. 
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:
[EMAIL PROTECTED]

<*> O uso que você faz do Yahoo! Grupos está sujeito aos:
http://br.yahoo.com/info/utos.html

 

Re: [oracle_br] Re: Select reduzido

[Cristiano Becker]

André,

Acho que é isso que você quer:

select cod,nvl(sum(qtde),0) qtde,valor,nvl(sum(total),0) total
from 
group by cod,valor

Cristiano

- Original Message -
  From: Marcio Portes
  To: oracle_br@yahoogrupos.com.br
  Sent: Thursday, April 06, 2006 2:25 PM
  Subject: [oracle_br] Re: Select reduzido


  Totalizar o que? Agrupado pelo o que?
  Exemplo da tabela e o que está tentando fazer são bem-vindos.


  --- Em oracle_br@yahoogrupos.com.br, André_Oracle
  <[EMAIL PROTECTED]> escreveu
  >
  > Caros amigos...
  > Montei um select na minha tabela de movimentação de estoque que me
  dá o
  > seguinte resultado.
  >
  > *Cod   qtdevalor   total*
  > 1  1   5,00  5,00
  > 1  2   5,00 10,00
  >
  > O que eu precisava era  mostrar apenas uma linha totalizada da
  seguinte
  > forma:
  >
  > *Cod   qtdevalor   total*
  > 1  35,0015,00
  >
  > Vcs poderiam me ajudar?
  >
  > Obrigado.
  >
  > André
  >







  
--
  Atenção! As mensagens deste grupo são de acesso público e de inteira 
responsabilidade de seus remetentes.
  Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/
  
--__

  Este Grupo recebe o apoio da SQL Magazine - www.devmedia.com.br/sqlmagazine
  __
  O grupo Oracle_br não aceita anexos. Quando oferecer algum arquivo, tenha o 
link do mesmo para evitar trafego(pedidos) desnecessário.



--
  Links do Yahoo! Grupos

a.. Para visitar o site do seu grupo na web, acesse:
http://br.groups.yahoo.com/group/oracle_br/
 
b.. Para sair deste grupo, envie um e-mail para:
[EMAIL PROTECTED]
 
c.. O uso que você faz do Yahoo! Grupos está sujeito aos Termos do Serviço 
do Yahoo!.



---
Esta mensagem pode conter informacoes confidenciais ou privilegiadas.
Se voce recebeu esta mensagem por engano, voce nao deve usar, copiar,
divulgar ou tomar qualquer atitude com base nestas informacoes.

Solicitamos que voce  apague a mensagem e avise imediatamente pelo endereco
[EMAIL PROTECTED]
Opinioes, conclusoes ou informacoes nesta mensagem nao necessariamente refletem
a posicao oficial da Empresa.
---

[As partes desta mensagem que não continham texto foram removidas]



--
Atenção! As mensagens deste grupo são de acesso público e de inteira 
responsabilidade de seus remetentes.
Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/ 
--__

Este Grupo recebe o apoio da SQL Magazine - www.devmedia.com.br/sqlmagazine 
__
O grupo Oracle_br não aceita anexos. Quando oferecer algum arquivo, tenha o 
link do mesmo para evitar trafego(pedidos) desnecessário. 
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:
[EMAIL PROTECTED]

<*> O uso que você faz do Yahoo! Grupos está sujeito aos:
http://br.yahoo.com/info/utos.html

 

Re: [oracle_br] Re: SELECT retornado por uma PROCEDURE

[Nícolas Santana]

Eu fiz um teste com esse exemplo que vc passou e executou normalmente, 
porém eu estava tentando gerar um relatorio no Crystal Reports e quando 
importava a Procedure para ele, ele nao "entendia" que ela tinha um retorno,não 
sei se pode ser o tipo de retorno entende? .O Crystal não estava reconhecendo o 
cursor como o retorno da Procedure sendo uma consulta para gerar o rel.
Por isso eu gostaria de saber se existe outra forma de retornar uma consulta 
com procedures.

Estou usando ORACLE 9i e win2000 Pro

  - Original Message - 
  From: jlchiappa 
  To: oracle_br@yahoogrupos.com.br 
  Sent: Monday, December 26, 2005 10:14 PM
  Subject: [oracle_br] Re: SELECT retornado por uma PROCEDURE


  Nicolas, essas respostas tão meio no ar (fiz isso, tentei aquilo, mas
  não se diz EXATAMENTE o que tentou, que problema deu), então sugiro :
  PRIMEIRO, http://asktom.oracle.com/~tkyte/ResultSets/index.html contém
  exemplos corretos de retorno de cursos pras algumas tools (sqlplus,
  asp, php) e linguagens (java, linguagens com acesso ODBC, PL/SQL,
  Perl),vc leu essa página ? Se sim, e se AINDA assim não conseguiu, por
  favor mande outra msg especificando : versão EXATA do banco Oracle
  usado, versão do client de banco usado (se não for thin-connection),
  versão do DRIVER/API usado (se jdbc, ODBC, o que for), versão EXATA da
  tool/linguagem que vc está usando, versão do Sistema Operacional , E
  um exemplo curtinho do que vc está tentando, que quem trabalhar no
  mesmo ambiente que vc aí sim pode te ajudar mais...

  []s

  Chiappa

  --- Em oracle_br@yahoogrupos.com.br, Nícolas Santana
  <[EMAIL PROTECTED]> escreveu
  >
  > Estou querendo fazer algo desse tipo também...
  > 
  > Fiz alguns testes aqui tentando fazer esse esquema, mas acabei
  criando uma função que retorna um cursor, porém não deu o resultado
  que eu esperava...
  > 
  > 
  > 
  > 
  >   - Original Message - 
  >   From: gibajr 
  >   To: oracle_br@yahoogrupos.com.br 
  >   Sent: Monday, December 26, 2005 4:28 PM
  >   Subject: [oracle_br] SELECT retornado por uma PROCEDURE
  > 
  > 
  >   Olah amigos,
  > 
  >   Estou tentando fazer uma PROCEDURE retornar o resultado de um SELECT.
  > 
  >   Tentei alguma coisa e não consegui. Alguém tem uma solução?
  > 
  >   Grato
  > 
  >   Gilberto
  > 
  > 
  > 
  > 
  > 
  > 
  > 
  >  
  
--
  >   Atenção! As mensagens deste grupo são de acesso público e de
  inteira responsabilidade de seus remetentes.
  >   Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/ 
  >  
  
--_
  >   Area de download do grupo -
  http://www.4shared.com/dir/101727/a4dcc423 
  > 
  > 
  > Yahoo! Grupos, um serviço oferecido por: 
  >   PUBLICIDADE
  > 
  >
  > 
  > 
  >
  --
  >   Links do Yahoo! Grupos
  > 
  > a.. Para visitar o site do seu grupo na web, acesse:
  > http://br.groups.yahoo.com/group/oracle_br/
  >   
  > b.. Para sair deste grupo, envie um e-mail para:
  > [EMAIL PROTECTED]
  >   
  > c.. O uso que você faz do Yahoo! Grupos está sujeito aos Termos
  do Serviço do Yahoo!. 
  > 
  > 
  > 
  > [As partes desta mensagem que não continham texto foram removidas]
  >






  
--
  Atenção! As mensagens deste grupo são de acesso público e de inteira 
responsabilidade de seus remetentes.
  Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/ 
  
--_
  Area de download do grupo - http://www.4shared.com/dir/101727/a4dcc423 


Yahoo! Grupos, um serviço oferecido por: 
  PUBLICIDADE

   


--
  Links do Yahoo! Grupos

a.. Para visitar o site do seu grupo na web, acesse:
http://br.groups.yahoo.com/group/oracle_br/
  
b.. Para sair deste grupo, envie um e-mail para:
[EMAIL PROTECTED]
  
c.. O uso que você faz do Yahoo! Grupos está sujeito aos Termos do Serviço 
do Yahoo!. 



[As partes desta mensagem que não continham texto foram removidas]



--
Atenção! As mensagens deste grupo são de acesso público e de inteira 
responsabilidade de seus remetentes.
Acesse: htt

Re:[oracle_br] Re: Select Tabela Particionada

[jlchiappa]

--- Em oracle_br@yahoogrupos.com.br, "Ronaldo Sales" 
<[EMAIL PROTECTED]> escreveu

> O livro eu quero comprar pois não tenho mesmo.

Altamente recomendado, e já que vc está no trabalho de tentar criar 
processos bons, eficientes no uso do banco, eu recomendo também que 
vc adquira e leia o "Effective Oracle by Design", do mesmo autor : 
foi com livro que me caiu a ficha de muitas coisas, como índices 
seletivos, que me ajudaram a cortar ** horas ** dos meus 
processamentos.

> 
> ... cada vez que eu vou lá eu compro uma briga com eles. Eles tavam 
me falando que a clausula PARTITION é obrigatória no FROM TABELA

bad news, realmente. Na verdade o problema nem é a pessoa errar 
(embora seja algo basicão de tudo pra DBAs, IMHO), mas reside no 
seguinte : pra demonstrar que essa cláusula não é obrigatória basta 
um teste de 3 minutos no sql*plus, como eu fiz no e-mail anterior, 
uma resposta categórica dessas indica que esses "dbas" simplesmente 
nem se importaram com o assunto, são daqueles provavelmente que há X 
anos atrás aprenderam  algo e nunca mais testaram pra ver se ainda é 
verdadeiro : não é o tipo de atitude que eu endosse.
 Bom, vc está no caminho certo, o negócio é provar POR DEMONSTRAÇÂO, 
e aí o e-mail com a prova, num toque sutil, vc copia também pro teu 
chefe, pro chefe deles, prum adversário do chefe deles, quem sabe 
esses "dbas" se tocam, é o que vc pode fazer politicamente. 
  Sorte pra vc.
  
  []s
  
   Chiappa
   





__

Cancelar assinatura...: [EMAIL PROTECTED]
Moderadores da lista:Dorian Anderson Soutto [EMAIL PROTECTED] 
Fernanda Damous [EMAIL PROTECTED] 
Alisson Aguiar [EMAIL PROTECTED]
__
http://br.groups.yahoo.com/group/oracle_br/ 
__

Sair da Lista...: [EMAIL PROTECTED] 
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:
[EMAIL PROTECTED]

<*> O uso que você faz do Yahoo! Grupos está sujeito aos:
http://br.yahoo.com/info/utos.html

 

Re:[oracle_br] Re: Select Tabela Particionada

[Ronaldo Sales]

Novamente muito obrigado a vc e a todos.

O livro eu quero comprar pois não tenho mesmo. Docs eu to lendo cada vez pois 
estou sentindo a necessidade de saber cada vez para criar processos bons.

Em relação aos params do banco ainda não parei pra conversar com os DBAs, cada 
vez que eu vou lá eu compro uma briga com eles. Eles tavam me falando que a 
clausula PARTITION é obrigatória no FROM TABELA, por isso que eu comecei a 
fazer teste, além é claro de visar a performance da consulta. A tabela atual 
está particionada por RANGE e subparticionada por HASH. E eu li que por HASH 
não garantia que cada plataforma caisse no seu devido lugar.

Abraços a todos.

Ronaldo.





De:oracle_br@yahoogrupos.com.br

Para:oracle_br@yahoogrupos.com.br

Cópia:

Data:Wed, 22 Jun 2005 20:05:01 -

Assunto:Re:[oracle_br] Re: Select Tabela Particionada

Legal. Pra vc não tropeçar mais quando fazendo testes de performance, 
recomendaria uma revisada nas docs correspondentes e no capítulo de 
tools de performance do livro "Expert One in One" do Tom Kyte - se vc 
não o tem, adquira o seu, vc não vai se arrepender!!
E insisto no aviso, se os params do CBO (como os que citei no e-
mail) não estão bons, esses testes que vc está fazendo nessa máquina 
não vão servir pra absolutamente NADA em termos de performance...
[]s
Chiappa
--- Em oracle_br@yahoogrupos.com.br, "Ronaldo Sales" 
escreveu
> uh, realmente os conceitos me pegaram mesmo então.
> 
> To me matando achando que ta errado o acesso.
> 
> refiz meu teste com uma sugestão de partição do Márcio Portes. 
Fazendo 
> PARTITION BY RANGE (ANOMES,PLATAFORMA)
> ( PARTITION P2004 VALUES LESS THAN (200411,12)
> ,PARTITION P20041112 VALUES LESS THAN (200411,13)
> ,PARTITION P20041211 VALUES LESS THAN (200412,12)
> ,PARTITION P20041212 VALUES LESS THAN (200412,13))
> 
> Aí sim todos os valores caem na partição certo ( não sei porque ele 
não faz o values less than para o anomes, só para a plataforma).
> 
> E olhando o plano ainda estava vendo o FULL table scan.
> 
> Vou reproduzir o mesmo caminho que vc fez.
> 
> Muito obrigado a vc e a todos que contribuiram com idéiais.
> 
> 
> 
> 
> 
> 
> De:oracle_br@yahoogrupos.com.br
> 
> Para:oracle_br@yahoogrupos.com.br
> 
> Cópia:
> 
> Data:Wed, 22 Jun 2005 19:02:48 -
> 
> Assunto:Re:[oracle_br] Re: Select Tabela Particionada
> 
> Dois conceitos te pegaram aqui :
> 
> a) a operação de ler uma partição inteira AINDA se chama FULL TABLE 
> SCAN, pra vc ver que o SCAN está sendo feito por partição vc tem 
que 
> ver o partition start/stop
> 
> b) o AUTOTRACE (que deve ter sido o que vc usou) ** não mostra ** o 
> início/fim de leitura de partição , mas o EXPLAIN PLAN mostra, e o 
> TKPROF também, como mais abaixo mostrado.
> 
> 
> ==>> Agora, a obs sobre os seus params e sobre o seu teste : vc diz 
> que está testando COM & partições, mas testar CBO sem que as 
configs 
> dele estejam OK, ou estejam default sem ser feita análise, é 
inútil. 
> Por exemplo : optimizer_index_caching 0 e optimizer_index_cost_adj 
> 100 ??? Isso é o default !!hash_multiblock_io_count=0, vc REALMENTE 
> não quer ter hash joins ??? Outra coisa, vc setou multiblock_read 
> como 8192 * 128 = 1 Mb, ** mas se ** os extents das tabelas maiores 
> (que se beneficiam de scan) forem menores que isso vc NÂO VAI se 
> aproveitar disso, como eu mostrei lá na demonstração da ENPO.
> 
> E só pra constar : no caso presente tudo bem, mas vc nos casos que 
> for preciso, ** VAI ** analizar índices E computar histogramas, 
né ???
> 
> 
> Segue a demonstração, mostrando que li via scan apenas a partição 1 
> das 4 que tenho :
> 
> 
> SQL*Plus: Release 8.1.7.0.0 - Production on Qua Jun 22 14:50:53 2005
> 
> (c) Copyright 2000 Oracle Corporation. All rights reserved.
> 
> 
> Conectado a:
> Personal Oracle8i Release 8.1.7.0.0 - Production
> With the Partitioning option
> JServer Release 8.1.7.0.0 - Production
> 
> [EMAIL PROTECTED]:SQL>CREATE TABLE part_ronaldo
> 2 (ANOMES NUMBER(6) NOT NULL,
> 3 PLATAFORMA NUMBER(2) NOT NULL,
> 4 COD_CLIENTE NUMBER(7) ,
> 5 COD_CELULAR NUMBER(7) )
> 6 PARTITION BY RANGE (ANOMES,PLATAFORMA)
> 7 ( PARTITION P2004 VALUES LESS THAN (200412,12)
> 8 ,PARTITION P20041112 VALUES LESS THAN (200412,13)
> 9 ,PARTITION P20041211 VALUES LESS THAN (200501,12)
> 10 ,PARTITION P20041212 VALUES LESS THAN (200501,13))
> 11 ;
> 
> Tabela criada.
> 
> [EMAIL PROTECTED]:SQL>insert into PART_RONALDO
> 2 select 200411, decode(mod(rownum,2),0,12,11), rownum, 23
> 3 from ALL_OBJECTS
> 4 where rownum <= 10;
> 
> 21802 linhas criadas.
> 
> [EMAIL PROTECTED]:SQL>commit;
> 
> Validação completa.
> 
> [EMAIL PROTECTED]:SQL>analyze table PART_RONALDO compute statistics;
> 
> Tabela analisada.
> 
> [EMAIL PROTECTED]:SQL>select ANOMES,PLATAFORMA, count(*) from 
PART_RONALDO 
> group by ANOMES,PLATAFORMA;
> 
> ANOMES PLATAFORMA COUNT(*)
> -- -- --
> 200411 11 10901
> 200411 12 10901
> 
> [EMAIL PROTECTED]:SQL>select table

Re:[oracle_br] Re: Select Tabela Particionada

[jlchiappa]

Legal. Pra vc não tropeçar mais quando fazendo testes de performance, 
recomendaria uma revisada nas docs correspondentes e no capítulo de 
tools de performance do livro "Expert One in One" do Tom Kyte - se vc 
não o tem, adquira o seu, vc não vai se arrepender!!
 E insisto no aviso, se os params do CBO (como os que citei no e-
mail) não estão bons, esses testes que vc está fazendo nessa máquina 
não vão servir pra absolutamente NADA em termos de performance...
 
 []s
 
  Chiappa
  
--- Em oracle_br@yahoogrupos.com.br, "Ronaldo Sales" 
<[EMAIL PROTECTED]> escreveu
> uh, realmente os conceitos me pegaram mesmo então.
> 
> To me matando achando que ta errado o acesso.
> 
> refiz meu teste com uma sugestão de partição do Márcio Portes. 
Fazendo 
> PARTITION BY RANGE (ANOMES,PLATAFORMA)
> ( PARTITION P2004 VALUES LESS THAN (200411,12)
>  ,PARTITION P20041112 VALUES LESS THAN (200411,13)
>  ,PARTITION P20041211 VALUES LESS THAN (200412,12)
>  ,PARTITION P20041212 VALUES LESS THAN (200412,13))
> 
> Aí sim todos os valores caem na partição certo ( não sei porque ele 
não faz o values less than para o anomes, só para a plataforma).
> 
> E olhando o plano ainda estava vendo o FULL table scan.
> 
> Vou reproduzir o mesmo caminho que vc fez.
> 
> Muito obrigado a vc e a todos que contribuiram com idéiais.
> 
> 
> 
> 
> 
> 
> De:oracle_br@yahoogrupos.com.br
> 
> Para:oracle_br@yahoogrupos.com.br
> 
> Cópia:
> 
> Data:Wed, 22 Jun 2005 19:02:48 -
> 
> Assunto:Re:[oracle_br] Re: Select Tabela Particionada
> 
> Dois conceitos te pegaram aqui :
> 
> a) a operação de ler uma partição inteira AINDA se chama FULL TABLE 
> SCAN, pra vc ver que o SCAN está sendo feito por partição vc tem 
que 
> ver o partition start/stop
> 
> b) o AUTOTRACE (que deve ter sido o que vc usou) ** não mostra ** o 
> início/fim de leitura de partição , mas o EXPLAIN PLAN mostra, e o 
> TKPROF também, como mais abaixo mostrado.
> 
> 
> ==>> Agora, a obs sobre os seus params e sobre o seu teste : vc diz 
> que está testando COM & partições, mas testar CBO sem que as 
configs 
> dele estejam OK, ou estejam default sem ser feita análise, é 
inútil. 
> Por exemplo : optimizer_index_caching 0 e optimizer_index_cost_adj 
> 100 ??? Isso é o default !!hash_multiblock_io_count=0, vc REALMENTE 
> não quer ter hash joins ??? Outra coisa, vc setou multiblock_read 
> como 8192 * 128 = 1 Mb, ** mas se ** os extents das tabelas maiores 
> (que se beneficiam de scan) forem menores que isso vc NÂO VAI se 
> aproveitar disso, como eu mostrei lá na demonstração da ENPO.
> 
> E só pra constar : no caso presente tudo bem, mas vc nos casos que 
> for preciso, ** VAI ** analizar índices E computar histogramas, 
né ???
> 
> 
> Segue a demonstração, mostrando que li via scan apenas a partição 1 
> das 4 que tenho :
> 
> 
> SQL*Plus: Release 8.1.7.0.0 - Production on Qua Jun 22 14:50:53 2005
> 
> (c) Copyright 2000 Oracle Corporation. All rights reserved.
> 
> 
> Conectado a:
> Personal Oracle8i Release 8.1.7.0.0 - Production
> With the Partitioning option
> JServer Release 8.1.7.0.0 - Production
> 
> [EMAIL PROTECTED]:SQL>CREATE TABLE part_ronaldo
> 2 (ANOMES NUMBER(6) NOT NULL,
> 3 PLATAFORMA NUMBER(2) NOT NULL,
> 4 COD_CLIENTE NUMBER(7) ,
> 5 COD_CELULAR NUMBER(7) )
> 6 PARTITION BY RANGE (ANOMES,PLATAFORMA)
> 7 ( PARTITION P2004 VALUES LESS THAN (200412,12)
> 8 ,PARTITION P20041112 VALUES LESS THAN (200412,13)
> 9 ,PARTITION P20041211 VALUES LESS THAN (200501,12)
> 10 ,PARTITION P20041212 VALUES LESS THAN (200501,13))
> 11 ;
> 
> Tabela criada.
> 
> [EMAIL PROTECTED]:SQL>insert into PART_RONALDO
> 2 select 200411, decode(mod(rownum,2),0,12,11), rownum, 23
> 3 from ALL_OBJECTS
> 4 where rownum <= 10;
> 
> 21802 linhas criadas.
> 
> [EMAIL PROTECTED]:SQL>commit;
> 
> Validação completa.
> 
> [EMAIL PROTECTED]:SQL>analyze table PART_RONALDO compute statistics;
> 
> Tabela analisada.
> 
> [EMAIL PROTECTED]:SQL>select ANOMES,PLATAFORMA, count(*) from 
PART_RONALDO 
> group by ANOMES,PLATAFORMA;
> 
> ANOMES PLATAFORMA COUNT(*)
> -- -- --
> 200411 11 10901
> 200411 12 10901
> 
> [EMAIL PROTECTED]:SQL>select table_name, partition_name, 
PARTITION_POSITION 
> from user_tab_partitions;
> 
> TABLE_NAME PARTITION_NAME 
> PARTITION_POSITION
> -- -- --
--
> --
> PART_RONALDO 
> P2004 1
> PART_RONALDO 
> P20041112 2
> PART_RONALDO 
> P20041211 3
> PART_RONALDO 
> P20041212 4
> 
> [EMAIL PROTECTED]:SQL>set autotrace on
> 
> [EMAIL PROTECTED]:SQL>select * from PART_RONALDO where ANOMES=200411 and 
> PLATAFORMA=11;
> 
> ...
> ANOMES PLATAFORMA COD_CLIENTE 
> COD_CELULAR
> -- -- -- ---
--
> -
> 200411 11 
> 21737 23
> 200411 11 
> 21739 23
> 200411 11 
> 21741 23
> 200411 11 
> 21743 23
> 200411 11 
> 21745 23
> 200411 11 
> 21747 23
> 200411 11 
> 21749 23
> 200411 11 
> 21751 23
> 200411

Re:[oracle_br] Re: Select Tabela Particionada

[Ronaldo Sales]

uh, realmente os conceitos me pegaram mesmo então.

To me matando achando que ta errado o acesso.

refiz meu teste com uma sugestão de partição do Márcio Portes. Fazendo 
PARTITION BY RANGE (ANOMES,PLATAFORMA)
( PARTITION P2004 VALUES LESS THAN (200411,12)
 ,PARTITION P20041112 VALUES LESS THAN (200411,13)
 ,PARTITION P20041211 VALUES LESS THAN (200412,12)
 ,PARTITION P20041212 VALUES LESS THAN (200412,13))

Aí sim todos os valores caem na partição certo ( não sei porque ele não faz o 
values less than para o anomes, só para a plataforma).

E olhando o plano ainda estava vendo o FULL table scan.

Vou reproduzir o mesmo caminho que vc fez.

Muito obrigado a vc e a todos que contribuiram com idéiais.






De:oracle_br@yahoogrupos.com.br

Para:oracle_br@yahoogrupos.com.br

Cópia:

Data:Wed, 22 Jun 2005 19:02:48 -

Assunto:Re:[oracle_br] Re: Select Tabela Particionada

Dois conceitos te pegaram aqui :

a) a operação de ler uma partição inteira AINDA se chama FULL TABLE 
SCAN, pra vc ver que o SCAN está sendo feito por partição vc tem que 
ver o partition start/stop

b) o AUTOTRACE (que deve ter sido o que vc usou) ** não mostra ** o 
início/fim de leitura de partição , mas o EXPLAIN PLAN mostra, e o 
TKPROF também, como mais abaixo mostrado.


==>> Agora, a obs sobre os seus params e sobre o seu teste : vc diz 
que está testando COM & partições, mas testar CBO sem que as configs 
dele estejam OK, ou estejam default sem ser feita análise, é inútil. 
Por exemplo : optimizer_index_caching 0 e optimizer_index_cost_adj 
100 ??? Isso é o default !!hash_multiblock_io_count=0, vc REALMENTE 
não quer ter hash joins ??? Outra coisa, vc setou multiblock_read 
como 8192 * 128 = 1 Mb, ** mas se ** os extents das tabelas maiores 
(que se beneficiam de scan) forem menores que isso vc NÂO VAI se 
aproveitar disso, como eu mostrei lá na demonstração da ENPO.

E só pra constar : no caso presente tudo bem, mas vc nos casos que 
for preciso, ** VAI ** analizar índices E computar histogramas, né ???


Segue a demonstração, mostrando que li via scan apenas a partição 1 
das 4 que tenho :


SQL*Plus: Release 8.1.7.0.0 - Production on Qua Jun 22 14:50:53 2005

(c) Copyright 2000 Oracle Corporation. All rights reserved.


Conectado a:
Personal Oracle8i Release 8.1.7.0.0 - Production
With the Partitioning option
JServer Release 8.1.7.0.0 - Production

[EMAIL PROTECTED]:SQL>CREATE TABLE part_ronaldo
2 (ANOMES NUMBER(6) NOT NULL,
3 PLATAFORMA NUMBER(2) NOT NULL,
4 COD_CLIENTE NUMBER(7) ,
5 COD_CELULAR NUMBER(7) )
6 PARTITION BY RANGE (ANOMES,PLATAFORMA)
7 ( PARTITION P2004 VALUES LESS THAN (200412,12)
8 ,PARTITION P20041112 VALUES LESS THAN (200412,13)
9 ,PARTITION P20041211 VALUES LESS THAN (200501,12)
10 ,PARTITION P20041212 VALUES LESS THAN (200501,13))
11 ;

Tabela criada.

[EMAIL PROTECTED]:SQL>insert into PART_RONALDO
2 select 200411, decode(mod(rownum,2),0,12,11), rownum, 23
3 from ALL_OBJECTS
4 where rownum <= 10;

21802 linhas criadas.

[EMAIL PROTECTED]:SQL>commit;

Validação completa.

[EMAIL PROTECTED]:SQL>analyze table PART_RONALDO compute statistics;

Tabela analisada.

[EMAIL PROTECTED]:SQL>select ANOMES,PLATAFORMA, count(*) from PART_RONALDO 
group by ANOMES,PLATAFORMA;

ANOMES PLATAFORMA COUNT(*)
-- -- --
200411 11 10901
200411 12 10901

[EMAIL PROTECTED]:SQL>select table_name, partition_name, PARTITION_POSITION 
from user_tab_partitions;

TABLE_NAME PARTITION_NAME 
PARTITION_POSITION
-- -- 
--
PART_RONALDO 
P2004 1
PART_RONALDO 
P20041112 2
PART_RONALDO 
P20041211 3
PART_RONALDO 
P20041212 4

[EMAIL PROTECTED]:SQL>set autotrace on

[EMAIL PROTECTED]:SQL>select * from PART_RONALDO where ANOMES=200411 and 
PLATAFORMA=11;

...
ANOMES PLATAFORMA COD_CLIENTE 
COD_CELULAR
-- -- -- -
-
200411 11 
21737 23
200411 11 
21739 23
200411 11 
21741 23
200411 11 
21743 23
200411 11 
21745 23
200411 11 
21747 23
200411 11 
21749 23
200411 11 
21751 23
200411 11 
21753 23
200411 11 
21755 23
200411 11 
21757 23
200411 11 
21759 23
200411 11 
21761 23
200411 11 
21763 23
200411 11 
21765 23
200411 11 
21767 23
200411 11 
21769 23
200411 11 
21771 23
200411 11 
21773 23
200411 11 
21775 23
200411 11 
21777 23
200411 11 
21779 23
200411 11 
21801 23

10901 linhas selecionadas.


Execution Plan
--
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=10 Card=10901 
Bytes=130812)
1 0 TABLE ACCESS (FULL) OF 'PART_RONALDO' (Cost=10 Card=10901 
Bytes=130812)




Statistics
--
0 recursive calls
4 db block gets
787 consistent gets
21 physical reads
0 redo size
524450 bytes sent via SQL*Net to client
81011 bytes received via SQL*Net from client
728 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
10901 rows processed


[EMA

Re:[oracle_br] Re: Select Tabela Particionada

[jlchiappa]

Dois conceitos te pegaram aqui :

a) a operação de ler uma partição inteira AINDA se chama FULL TABLE 
SCAN, pra vc ver que o SCAN está sendo feito por partição vc tem que 
ver o partition start/stop

b) o AUTOTRACE (que deve ter sido o que vc usou) ** não mostra ** o 
início/fim de leitura de partição , mas o EXPLAIN PLAN mostra, e o 
TKPROF também, como mais abaixo mostrado.


==>> Agora, a obs sobre os seus params e sobre o seu teste : vc diz 
que está testando COM & partições, mas testar CBO sem que as configs 
dele estejam OK, ou estejam default sem ser feita análise, é inútil. 
Por exemplo : optimizer_index_caching 0 e optimizer_index_cost_adj 
100 ??? Isso é o default !!hash_multiblock_io_count=0, vc REALMENTE 
não quer ter hash joins ??? Outra coisa, vc setou multiblock_read 
como 8192 * 128 = 1 Mb, ** mas se ** os extents das tabelas maiores 
(que se beneficiam de scan) forem menores que isso vc NÂO VAI se 
aproveitar disso, como eu mostrei lá na demonstração da ENPO.

E só pra constar : no caso presente tudo bem, mas vc nos casos que 
for preciso, ** VAI ** analizar índices E computar histogramas, né ???


Segue a demonstração, mostrando que li via scan apenas a partição 1 
das 4 que tenho  :


SQL*Plus: Release 8.1.7.0.0 - Production on Qua Jun 22 14:50:53 2005

(c) Copyright 2000 Oracle Corporation.  All rights reserved.


Conectado a:
Personal Oracle8i Release 8.1.7.0.0 - Production
With the Partitioning option
JServer Release 8.1.7.0.0 - Production

[EMAIL PROTECTED]:SQL>CREATE TABLE part_ronaldo
  2  (ANOMES NUMBER(6) NOT NULL,
  3  PLATAFORMA NUMBER(2) NOT NULL,
  4  COD_CLIENTE NUMBER(7) ,
  5  COD_CELULAR NUMBER(7) )
  6  PARTITION BY RANGE (ANOMES,PLATAFORMA)
  7  ( PARTITION P2004 VALUES LESS THAN (200412,12)
  8  ,PARTITION P20041112 VALUES LESS THAN (200412,13)
  9  ,PARTITION P20041211 VALUES LESS THAN (200501,12)
 10  ,PARTITION P20041212 VALUES LESS THAN (200501,13))
 11  ;

Tabela criada.

[EMAIL PROTECTED]:SQL>insert into PART_RONALDO
  2   select 200411, decode(mod(rownum,2),0,12,11), rownum, 23
  3from ALL_OBJECTS
  4   where rownum <= 10;

21802 linhas criadas.

[EMAIL PROTECTED]:SQL>commit;

Validação completa.

[EMAIL PROTECTED]:SQL>analyze table PART_RONALDO compute statistics;

Tabela analisada.

[EMAIL PROTECTED]:SQL>select ANOMES,PLATAFORMA, count(*) from PART_RONALDO 
group by ANOMES,PLATAFORMA;

ANOMES PLATAFORMA   COUNT(*)
-- -- --
200411 11  10901
200411 12  10901

[EMAIL PROTECTED]:SQL>select table_name, partition_name, PARTITION_POSITION 
from user_tab_partitions;

TABLE_NAME PARTITION_NAME 
PARTITION_POSITION
-- -- 
--
PART_RONALDO   
P2004   1
PART_RONALDO   
P20041112   2
PART_RONALDO   
P20041211   3
PART_RONALDO   
P20041212   4

[EMAIL PROTECTED]:SQL>set autotrace on

[EMAIL PROTECTED]:SQL>select * from PART_RONALDO where ANOMES=200411 and 
PLATAFORMA=11;

...
ANOMES PLATAFORMACOD_CLIENTE
COD_CELULAR
-- -- -- -
-
200411 11  
21737 23
200411 11  
21739 23
200411 11  
21741 23
200411 11  
21743 23
200411 11  
21745 23
200411 11  
21747 23
200411 11  
21749 23
200411 11  
21751 23
200411 11  
21753 23
200411 11  
21755 23
200411 11  
21757 23
200411 11  
21759 23
200411 11  
21761 23
200411 11  
21763 23
200411 11  
21765 23
200411 11  
21767 23
200411 11  
21769 23
200411 11  
21771 23
200411 11  
21773 23
200411 

Re:[oracle_br] Re: Select Tabela Particionada

[Ronaldo Sales]

Num e-mail anterior eu mandei exatamente os passos que fiz. Desde a criação da 
tabela, analyze, etc...

Desde ja agradeço a todos.

Segue os parametros que vc pediu:
NAME VALUE
- -
bitmap_merge_area_size 10485760
buffer_pool_keep buffers:500, lru_latches:2
buffer_pool_recycle
create_bitmap_area_size 10485760
db_block_buffers 13
db_block_size 8192
db_file_multiblock_read_count 128
hash_area_size 20971520
hash_join_enabled TRUE
hash_multiblock_io_count 0
java_max_sessionspace_size 0
java_pool_size 100
large_pool_size 8000
log_buffer 20971520
max_dump_file_size UNLIMITED
max_enabled_roles 50
mts_multiple_listeners FALSE
object_cache_max_size_percent 10
object_cache_optimal_size 102400
optimizer_features_enable 8.1.7
optimizer_index_caching 0
optimizer_index_cost_adj 100
optimizer_max_permutations 8
optimizer_mode CHOOSE
optimizer_percent_parallel 0
oracle_trace_collection_size 5242880
parallel_adaptive_multi_user TRUE
parallel_broadcast_enabled TRUE
parallel_execution_message_size 4096
partition_view_enabled FALSE
query_rewrite_enabled FALSE
shared_pool_reserved_size 2500
shared_pool_size 5
sort_area_retained_size 5242880
sort_area_size 10485760
sort_multiblock_read_count 8
star_transformation_enabled TRUE
use_indirect_data_buffers FALSE







De:oracle_br@yahoogrupos.com.br

Para:oracle_br@yahoogrupos.com.br

Cópia:

Data:Wed, 22 Jun 2005 14:06:23 -

Assunto:[oracle_br] Re: Select Tabela Particionada

PMFJI, mas que tal :

a) vc mostrar ** EXATAMENTE ** o comando que vc coletou as estats 
(pra gente ver se realmente vc lembrou de coletar pra tabela e pra 
índice, pra gente ver se vc usou compute ou não, enfim) ?

b) vc dar pra gente EXATAMENTE o CREATE TABLE e o(s) CREATE INDEX(es) 
envolvidos, junto com um INSERT de alguns dados ?

c) plano de execução EXATO que vc obteve ?

d) os PARÂMETROS do banco que se relacionam com CBO, principalmente 
optimizer_* , *size*, *buffer*, *enabled*, *mult* ?

e tudo via copy/paste do sql*plus ?? Aí sim podemos dizer algo 

[]s

Chiappa
--- Em oracle_br@yahoogrupos.com.br, "Ronaldo Sales" 
escreveu
> To ligado, no meu teste eu coloquei ambos os campos e mesmo assim 
ia pro Full table scan.
> 
> Ronaldo.
> 
> 
> 
> 
> 
> De:oracle_br@yahoogrupos.com.br
> 
> Para:oracle_br@yahoogrupos.com.br
> 
> Cópia:
> 
> Data:Wed, 22 Jun 2005 09:51:37 -0300
> 
> Assunto:Re: [oracle_br] Select Tabela Particionada
> 
> Ronaldo,
> 
> Quando não se referencia o campo chave da Partição (mes+plataforma, 
*pode
> ser este o problema*), o Banco irá ler todas as partições 
existentes. Não
> esqueça também, você precisa ter estatísticas fresquinhas para 
todas as
> partições.
> 
> Atenciosamente,
> 
> Anderson Haertel Rodrigues
> Administrador de Banco de Dados
> Oracle 9i Database Administrator Certified
> Microsoft Certified Professional SQL Server 2000
> Florianópolis/SC
> 
> - Original Message -
> From: "Ronaldo Sales" 
> To: "oracle_br" 
> Sent: Wednesday, June 22, 2005 9:33 AM
> Subject: Re: [oracle_br] Select Tabela Particionada
> 
> 
> Valeu Anderson, eu imaginei mesmo. É que ontem eu fiquei fazendo 
uns testes
> aqui num 8.1.7.4.0 e no plano de execução não fazia referencia a 
partição,
> que aliás eu criei por chave composta (mes, plataforma).
> 
> Pior que inseri uns dados, rodei analyze. E mesmo assim ele full na 
tabela
> toda.
> 
> Ronaldo.
> 
> 
> 
> 
> 
> De:oracle_br@yahoogrupos.com.br
> 
> Para:oracle_br@yahoogrupos.com.br
> 
> Cópia:
> 
> Data:Wed, 22 Jun 2005 09:17:41 -0300
> 
> Assunto:Re: [oracle_br] Select Tabela Particionada
> 
> Ronaldo,
> 
> Se houverem estatísticas fresquinhas, etc, o Banco vai ler apenas 
os blocos
> que fazem parte da Partição do mês "XX".
> 
> Atenciosamente,
> 
> Anderson Haertel Rodrigues
> Administrador de Banco de Dados
> Oracle 9i Database Administrator Certified
> Microsoft Certified Professional SQL Server 2000
> Florianópolis/SC
> 
> - Original Message -
> From: "Ronaldo Ap. de Sales"
> To:
> Sent: Tuesday, June 21, 2005 8:10 PM
> Subject: [oracle_br] Select Tabela Particionada
> 
> 
> >
> > Uma pergunta boba.
> >
> > Se eu tenho uma tabela particionada pelo campo MES.
> >
> > Digamos que eu faça um select assim:
> >
> > SELECT *
> > FROM TABELA
> > WHERE MES = XXX
> >
> > O Banco vai direto na partição do mês ou eu tenho que informar a 
clausula
> > Partition no FROM ?
> >
> > Ronaldo.
> >
> >
> >
> >
> > 
__
> >
> > Cancelar assinatura...: [EMAIL PROTECTED]
> > Moderadores da lista:Dorian Anderson Soutto [EMAIL PROTECTED]
> > Fernanda Damous [EMAIL PROTECTED]
> > Alisson Aguiar [EMAIL PROTECTED]
> > 
__
> > http://br.groups.yahoo.com/group/oracle_br/
> > 
__
> >
> > Sair da Lista...: [EMAIL PROTECTED]
> > Links do Yah