Re: [oracle_br] Dulvidas sql
Blz Paulo. Pelo que entendi você deve ter um coluna na tabela do tipo date, se for isso é fácil. no where coloque: *TO_CHAR(coluna,'D') = 5* Em 15 de outubro de 2014 22:24, JOSE PAULO jjpaulo@hotmail.com [oracle_br] escreveu: > > > Boa noite Pessoal. > Estou Precisando dá um Select em todos os registros ema determinada tabela > de um banco oracle, mais que o retorno fosse só os registros de todas as > quinta-feira da semana, isso é possivel? Qual seria a Sintaxe. > Grato > Paulo > > > -- Fabiano P. Fone: (46) 9113-6731 E-Mail: fabiano...@gmail.com Skype: fabianofpb
[oracle_br] Dulvidas sql
Boa noite Pessoal.Estou Precisando dá um Select em todos os registros ema determinada tabela de um banco oracle, mais que o retorno fosse só os registros de todas as quinta-feira da semana, isso é possivel? Qual seria a Sintaxe.GratoPaulo
Re: [oracle_br] OCI-22141: given size [string] must be even in UTF-16 environment
Opa, blz ? Miltão, pmfji mas PRIMEIRO de tudo vc tem que considerar a possibilidade de limitações externas ao database : por exemplo, se o teu pessoal usa o framework Zend no PHP, http://forums.zend.com/viewtopic.php?f=8&t=6448 nos diz que (ao menos na versão citada na thread) o cara vinha com o client Oracle OCI Instant Client, que RECONHECIDAMENTE tinha/tem limitações no tocante à charactersets, aí a pessoa simplesmente baixou o client full e fez lá as configs pro coiso usar o client oci full completo Eu diria pra antes de tudo vc tentar chamar a tal procedure de dentro do PL/SQL e a partir de uma outra tool cliente (sqlplus, por exemplo) : indo tudo OK, a gente desconfia de limitações do teu ambiente PHP, não funcionando talvez a bronca seja nessas parâmetros IN e OUT varchar2 que vc tem, talvez eles devam ser definidos com um tamanho específico e par []s Chiappa
Re: [oracle_br] OCI-22141: given size [string] must be even in UTF-16 environment
Miltão Relendo sua primeira mensagem, o erro acontece na chamada procedure, não é? Se a declaração já está como VARCHAR2(20 CHAR), então o problema não deve estar no parâmetro declarado... pois o valor passado tem só 9 caracteres. Poderia fazer um teste, alterando a declaração para NVarchar2(20 char)... que geralmente usa UTF-16... só para ver como se comporta. Outro teste seria tentar simular o erro, diretamente no SQL-Plus... pois pode ser que o bug seja algo na biblioteca de conexão do PHP. [ ]'s André Em 15/10/14, 'Milton Bastos Henriquis Jr.' miltonbas...@gmail.com [oracle_br] escreveu: > Beleza André? > > Olha como está as declarações: > > CREATE OR REPLACE TYPE "PHP_ARRAY" AS VARRAY(20) OF VARCHAR2(20 CHAR) > > > > procedure p_createInventory(iType in number, > iDesc in varchar2, > iRecord in PHP_ARRAY, -- in varchar2, > --multisel_values_table, > omensagem out varchar2) > > > O tipo já está como VARCHAR2(20 CHAR)! > > Att, > > > > > Em 15 de outubro de 2014 12:51, Andre Santos andre.psantos...@gmail.com > [oracle_br] escreveu: > >> >> >> Miltão >> >> Nesse cenário específico, pela mensagem de erro, o ambiente está usando >> character-set UTF-16 que usa, no mínimo, 2 bytes por caractere. >> Ou seja, quando é declarada uma variável VARCHAR2(9) **não** são 9 >> caracteres, são 9 BYTES. >> Porém a quantidade de bytes, para UTF-16, tem de ser múltiplo de 2 >> (bytes). >> Para declarar o tamanho em "caracteres", pode usar a sintaxe: VARCHAR2(9 >> CHAR). >> >> [ ]'s >> >> André Santos >> >> >> Em 15 de outubro de 2014 12:35, 'Milton Bastos Henriquis Jr.' >> miltonbas...@gmail.com [oracle_br] >> escreveu: >> >> >>> >>> Boa tarde pessoal >>> >>> Cenário: >>> - Oracle database 11.2.0.3 >>> - Servidor Oracle Linux 64 bits >>> - Aplicação em PHP rodando num servidor IIS >>> >>> >>> OCI-22141: given size [string] must be even in UTF-16 environment >>> Cause: The given resize size is odd. In a UTF-16 environment, all >>> characters are 2 bytes in length. >>> Action: Ensure that the given size is even. >>> >>> >>> Em uma certa tela do sistema, o usuário seleciona vários itens e clica >>> num botão. >>> Ao clicar nesse botão, esses itens são enviados pra um parâmetro de >>> entrada de uma >>> procedure. Como o número de itens é variado, o tipo desse parâmetro é um >>> VARRAY. >>> Cada item é uma string de 9 caracteres. >>> O fato de ser 9 caracteres causa o erro acima - se passar 8 ou 10 >>> caracteres >>> funciona, não acontece o erro. Mas se for uma quantidade ímpar, acontece >>> o erro. >>> >>> O que faço pra corrigir isso? Devo alterar algo em algum parametro NLS? >>> >>> >>> >>> Att, >>> >>> >>> >>> Uma certa tela do sistema >>> >>> >> >> >
[oracle_br] Re: Horario de verão 2014
Blz ? Então, primeira coisa no mundo ideal nós *** não *** teríamos que mudar a hora dos n servidores, mas sim teríamos todos sincronizando num serviço/servidor NTP que esteja setado para reconhecer horário de verão E as aplicações todas usam datatypes com TZ incluso, o que deixaria basicamente transparente, mas nem sempre é assim (pra não dizer quase NUNCA :0) Assim, pode sim ser que nos seus ambientes vc tenha que intervir : aí, como sabemos, para o funcionamento do banco de dados em si vc mudar o clock do sistema não influencia EM NADA, pois o RDBMS se controla por SCN, que é um número sequencial sempre crescente, não necessitando para nada da hora do sistema As situações em que vc pode ter problema com o avanço (OU com o retrocesso da hora, quando acabar o horário de verão) são : => se vc tem RAC, qquer diferença de data/hora numa máquina pode levar à evisceração eventualmente => se vc tem JOBs agendados nesse database, evidentemente vc pode ter jobs não-executados nessa hora 'perdida' ao se avançar o system clock, EM ESPECIAL se vc não estiver usando o SCHEDULER, que permite indicar timezone com DST e portanto é em princípio imune à alterações DST => se a sua aplicação usa uma chave data/hora, ou usa data/hora para auditoria, vc pode ter duplicidade de registros na volta => se vc tiver que fazer um RECOVER time-based nesse database, vc pode ter problemas já que vc teria uma hora "perdida" no avanço da hora e chance de duas horas iguais (duas meias-noites, provavelmente) na hora de voltar Então a resposta é : para os bancos single-instance que não tenham JOBs extras schedulados e que a aplicação não dependa da data do sistema, vc simplesmente registra/anota o SCN (para que se preciso vc faça um recover until scn, não baseado em data) e muda o system clock sem providência nenhuma , e cabou Já nos casos mais complexos em que os pontos acima possam pegar, o Ideal e seguro é mesmo se ter uma parada programada para manutenção, parando/shuteando o ambiente antes de alterar o system clock e/ou o serviço de NTP... No final do horário de verão, quando vc tem que voltar a data/hora, para evitar o problema de duas horas iguais/duas meias-noites, o que normalmente programo é um intervalo de uma hora depois do ambiente parado... []s Chiappa OBS : é claro que se vc tiver um ambiente altamente crítico onde NENHUMA indisponibilidade é tolerada, há diversas opções para se work-aroundear as possibilidades acima, como setar a NEXT_DATE dos jobs com DBMS_JOB.NEXT_DATE, UPDATE / trigger de DMl nas colunas DATETIME, e outras Isso é possível MAS pode rapidamente se tornar complexo, então só mesmo se for Impossível Realmente a opção mais segura e simples de uma parada programada é que eu iria atrás dessas coisas...
Re: [oracle_br] OCI-22141: given size [string] must be even in UTF-16 environment
Beleza André? Olha como está as declarações: CREATE OR REPLACE TYPE "PHP_ARRAY" AS VARRAY(20) OF VARCHAR2(20 CHAR) procedure p_createInventory(iType in number, iDesc in varchar2, iRecord in PHP_ARRAY, -- in varchar2, --multisel_values_table, omensagem out varchar2) O tipo já está como VARCHAR2(20 CHAR)! Att, Em 15 de outubro de 2014 12:51, Andre Santos andre.psantos...@gmail.com [oracle_br] escreveu: > > > Miltão > > Nesse cenário específico, pela mensagem de erro, o ambiente está usando > character-set UTF-16 que usa, no mínimo, 2 bytes por caractere. > Ou seja, quando é declarada uma variável VARCHAR2(9) **não** são 9 > caracteres, são 9 BYTES. > Porém a quantidade de bytes, para UTF-16, tem de ser múltiplo de 2 (bytes). > Para declarar o tamanho em "caracteres", pode usar a sintaxe: VARCHAR2(9 > CHAR). > > [ ]'s > > André Santos > > > Em 15 de outubro de 2014 12:35, 'Milton Bastos Henriquis Jr.' > miltonbas...@gmail.com [oracle_br] > escreveu: > > >> >> Boa tarde pessoal >> >> Cenário: >> - Oracle database 11.2.0.3 >> - Servidor Oracle Linux 64 bits >> - Aplicação em PHP rodando num servidor IIS >> >> >> OCI-22141: given size [string] must be even in UTF-16 environment >> Cause: The given resize size is odd. In a UTF-16 environment, all >> characters are 2 bytes in length. >> Action: Ensure that the given size is even. >> >> >> Em uma certa tela do sistema, o usuário seleciona vários itens e clica >> num botão. >> Ao clicar nesse botão, esses itens são enviados pra um parâmetro de >> entrada de uma >> procedure. Como o número de itens é variado, o tipo desse parâmetro é um >> VARRAY. >> Cada item é uma string de 9 caracteres. >> O fato de ser 9 caracteres causa o erro acima - se passar 8 ou 10 >> caracteres >> funciona, não acontece o erro. Mas se for uma quantidade ímpar, acontece >> o erro. >> >> O que faço pra corrigir isso? Devo alterar algo em algum parametro NLS? >> >> >> >> Att, >> >> >> >> Uma certa tela do sistema >> >> > >
Re: [oracle_br] coleta de estatísticas..
Márcio Só um ponto de atenção: normalmente quando a sessão fica KILLED por algum tempo, é porque o Oracle está executando o processo de rollback, através de processos de background (se for uma atualização pesada, o tempo do rollback pode ser longo). Se for esse o caso (se não for algum "bug"...), ao matar o processo do S.O. (kill -9) "parece" que resolveu o problema... mas, na realidade, pode ocorrer de não ter completado o rollback. Se isso ocorreu, uma nova consulta nesses mesmos dados pode ter impacto na performance: o Oracle perceber que os dados não estão atualizados no datafile e terá de verificar e ler segmentos de rollback (se a transação original foi longa, pode ter muita coisa no rollback que não foi restaurada... e a busca ficará um pouco mais lenta). Os experts aqui do grupo, por favor, me corrijam, se tiver algo incorreto neste raciocínio! :) [ ]'s André Em 13 de outubro de 2014 13:48, 'Grupos' marcio_...@yahoo.com.br [oracle_br] escreveu: > > > Olá... > > > > Encontrei o problema. Uma sessão tinha sido matada, há um tempo atrás, mas > ficou marcada como KILLED, e a sua sessão no HP-UX ficou sendo executada, > matei a sessão no HP-UX e normalizou. > > > > Grato. > > > > *De:* oracle_br@yahoogrupos.com.br [mailto:oracle_br@yahoogrupos.com.br] > *Enviada em:* segunda-feira, 13 de outubro de 2014 09:45 > *Para:* oracle_br@yahoogrupos.com.br > *Assunto:* [oracle_br] coleta de estatísticas.. > > > > > > Bom dia! > > > > A coleta de estatísticas de uma instância está apresentando muita > lentidão, estou colendo da seguinte maneira: > > > > dbms_stats.gather_table_stats(ownname=>'USER',tabname=>'TABELA',granularity=>'ALL',method_opt=>'FOR > ALL INDEXED COLUMNS SIZE AUTO', estimate_percent=>10,cascade=>TRUE, > DEGREE=>6); > > > > Antes de apresentar a lentidão, era executado em 50 minutos, para toda um > schema com tamanho de 150GB. > > > > Como eu posso monitorar e ver onde está apresentando a lentidão, lentidão > essa de ficar rodando dias. > > > > Oracle 11.2.0.3 > > HP-UX > > > > Grato. > > >
Re: [oracle_br] Re: Performance
Gustavo
Para investigar o que ocorre na aplicação, num determinado processo, gosto
de usar "trace/tkprof" mesmo.
O Chiappa indicou duas referências muito boas!
Só enfatizo que, ao gerar o trace, é muito útil colocar as opções de
WAITS=true.
Desse modo você terá detalhes dos eventos de espera (tempos) dos processo.
[ ]'s
André Santos
Em 15 de outubro de 2014 11:20, jlchia...@yahoo.com.br [oracle_br] <
oracle_br@yahoogrupos.com.br> escreveu:
>
>
> Tudo jóia ? Então, o certo seria a Aplicação dispor de INSTRUMENTAÇÃO,
> isto é, de um modo de debug que vc ativaria e aí obteria um report de cada
> passo que está sendo executado e quanto está demorando, JUSTAMENTE para vc
> poder identificar aonde que está a demora Não preciso dizer, porém, que
> em 99,999% das Aplicações (em nome da "agilidade", dizem alguns) são feitas
> é nas coxas mesmo, de qquer jeito e sem planejamento, visando mesmo é o
> menor custo e o mais curto prazo de entrega, assim as primeiras coisas
> cortadas são justamente as impreteríveis , ie, a DOCUMENTAÇÃO e a
> INSTRUMENTAÇÃO...
> Não havendo instrumentação nativa : caso a aplicação seja desenvolvida
> in-house e vc tenha os fontes e a possibilidade de a alterar, a
> Recomendação seria vc implementar uma instrumentação, nem que seja algo
> muito simples, tipo :
>
> imprimir mensagem ('Vou fazer o select das NFs em' || data e hora);
> SELECT .
> imprimir mensagem ('Feito SELECT em ' || data e hora);
> ...
>
> negócio bem básico e rastaquera, mas que já te daria a info...
>
> CASO não seja possível implementar nada de nada, aí o recurso seria vc
> ativar o TRACE no banco de dados : isso vai te gerar um arquivo de trace
> com a relação completa dos comandos executados e o tempo gasto (bem como o
> Plano de Execução dos SQLs), aí com isso vc saberá se o culpado é algum SQL
> ruim, se é latch (ie, muitas pessoas acessando as mesmas tabelas ao mesmo
> tempo tendo que esperarem pela liberação do latch de acesso), espera por
> LOCK (já vi sistemas doidos aonde assim que o usuário inicia uma sessão de
> uso no sistema o aplicativo insere/updateia registros em tabelas de
> controles, aí se por qquer motivo múltiplas pessoas iniciarem ao mesmo
> tempo há espera por lock), se é a rede que está sobrecarregada ao
> transmitir os dados para o cliente (às vezes o banco em si está perfeito
> mas a rede é que tá enfrentando pico de uso - vc ** NÂO ** pode dizer de
> bate-pronto que a lentidão está sendo causada por seu banco), ou o que
> for... Dá um look na Documentação, e para mais refs vc pode usar
> http://www.oracle-base.com/articles/misc/sql-trace-10046-trcsess-and-tkprof.php
> para trace de sessão dedicada, e
> http://www.dbspecialists.com/files/presentations/tracing_ind_sessions.html
> para os casos mais difíceis aonde a conexão ao banco não seja direta,
> havendo algum tipo de pool de conexões em que uma sessão no banco atende N
> solicitações diferentes de usuários diferentes...
>
> []s
>
> Chiappa
>
>
Re: [oracle_br] OCI-22141: given size [string] must be even in UTF-16 environment
Miltão Nesse cenário específico, pela mensagem de erro, o ambiente está usando character-set UTF-16 que usa, no mínimo, 2 bytes por caractere. Ou seja, quando é declarada uma variável VARCHAR2(9) **não** são 9 caracteres, são 9 BYTES. Porém a quantidade de bytes, para UTF-16, tem de ser múltiplo de 2 (bytes). Para declarar o tamanho em "caracteres", pode usar a sintaxe: VARCHAR2(9 CHAR). [ ]'s André Santos Em 15 de outubro de 2014 12:35, 'Milton Bastos Henriquis Jr.' miltonbas...@gmail.com [oracle_br] escreveu: > > > Boa tarde pessoal > > Cenário: > - Oracle database 11.2.0.3 > - Servidor Oracle Linux 64 bits > - Aplicação em PHP rodando num servidor IIS > > > OCI-22141: given size [string] must be even in UTF-16 environment > Cause: The given resize size is odd. In a UTF-16 environment, all > characters are 2 bytes in length. > Action: Ensure that the given size is even. > > > Em uma certa tela do sistema, o usuário seleciona vários itens e clica num > botão. > Ao clicar nesse botão, esses itens são enviados pra um parâmetro de > entrada de uma > procedure. Como o número de itens é variado, o tipo desse parâmetro é um > VARRAY. > Cada item é uma string de 9 caracteres. > O fato de ser 9 caracteres causa o erro acima - se passar 8 ou 10 > caracteres > funciona, não acontece o erro. Mas se for uma quantidade ímpar, acontece o > erro. > > O que faço pra corrigir isso? Devo alterar algo em algum parametro NLS? > > > > Att, > > > > Uma certa tela do sistema > > >
[oracle_br] OCI-22141: given size [string] must be even in UTF-16 environment
Boa tarde pessoal Cenário: - Oracle database 11.2.0.3 - Servidor Oracle Linux 64 bits - Aplicação em PHP rodando num servidor IIS OCI-22141: given size [string] must be even in UTF-16 environment Cause: The given resize size is odd. In a UTF-16 environment, all characters are 2 bytes in length. Action: Ensure that the given size is even. Em uma certa tela do sistema, o usuário seleciona vários itens e clica num botão. Ao clicar nesse botão, esses itens são enviados pra um parâmetro de entrada de uma procedure. Como o número de itens é variado, o tipo desse parâmetro é um VARRAY. Cada item é uma string de 9 caracteres. O fato de ser 9 caracteres causa o erro acima - se passar 8 ou 10 caracteres funciona, não acontece o erro. Mas se for uma quantidade ímpar, acontece o erro. O que faço pra corrigir isso? Devo alterar algo em algum parametro NLS? Att, Uma certa tela do sistema
[oracle_br] Re: Performance
Tudo jóia ? Então, o certo seria a Aplicação dispor de INSTRUMENTAÇÃO, isto
é, de um modo de debug que vc ativaria e aí obteria um report de cada passo que
está sendo executado e quanto está demorando, JUSTAMENTE para vc poder
identificar aonde que está a demora Não preciso dizer, porém, que em
99,999% das Aplicações (em nome da "agilidade", dizem alguns) são feitas é nas
coxas mesmo, de qquer jeito e sem planejamento, visando mesmo é o menor custo e
o mais curto prazo de entrega, assim as primeiras coisas cortadas são
justamente as impreteríveis , ie, a DOCUMENTAÇÃO e a INSTRUMENTAÇÃO...
Não havendo instrumentação nativa : caso a aplicação seja desenvolvida
in-house e vc tenha os fontes e a possibilidade de a alterar, a Recomendação
seria vc implementar uma instrumentação, nem que seja algo muito simples, tipo :
imprimir mensagem ('Vou fazer o select das NFs em' || data e hora);
SELECT .
imprimir mensagem ('Feito SELECT em ' || data e hora);
...
negócio bem básico e rastaquera, mas que já te daria a info...
CASO não seja possível implementar nada de nada, aí o recurso seria vc ativar
o TRACE no banco de dados : isso vai te gerar um arquivo de trace com a relação
completa dos comandos executados e o tempo gasto (bem como o Plano de Execução
dos SQLs), aí com isso vc saberá se o culpado é algum SQL ruim, se é latch (ie,
muitas pessoas acessando as mesmas tabelas ao mesmo tempo tendo que esperarem
pela liberação do latch de acesso), espera por LOCK (já vi sistemas doidos
aonde assim que o usuário inicia uma sessão de uso no sistema o aplicativo
insere/updateia registros em tabelas de controles, aí se por qquer motivo
múltiplas pessoas iniciarem ao mesmo tempo há espera por lock), se é a rede que
está sobrecarregada ao transmitir os dados para o cliente (às vezes o banco em
si está perfeito mas a rede é que tá enfrentando pico de uso - vc ** NÂO **
pode dizer de bate-pronto que a lentidão está sendo causada por seu banco), ou
o que for... Dá um look na Documentação, e para mais refs vc pode usar
http://www.oracle-base.com/articles/misc/sql-trace-10046-trcsess-and-tkprof.php
para trace de sessão dedicada, e
http://www.dbspecialists.com/files/presentations/tracing_ind_sessions.html para
os casos mais difíceis aonde a conexão ao banco não seja direta, havendo algum
tipo de pool de conexões em que uma sessão no banco atende N solicitações
diferentes de usuários diferentes...
[]s
Chiappa
Re: [oracle_br] Performance
Gustavo, tenta identificar os Sql´s que estão gerando estes picos no seu EM. Segue abaixo, link para auxiliar na identificação das consultas que estão penalizando seu banco de dados: http://blog.gaudencio.net.br/2013/10/oracle-identificando-sql-problematico.html Att, Emerson Em 15 de outubro de 2014 09:07, Gustavo gust.goul...@yahoo.com.br [oracle_br] escreveu: > > > Senhores, bom dia! > > Alguem aqui na lista poderia indicar alguns metodos para identificar o > motivo e como corrigir a lentidão que esta acontecendo no meu DB ? > > Na verdade é mais na aplicação, e só em uma parte dela. Quando o usuário > loga na aplicação, ela lê algumas tabelas e então forma uma pauta de > compromissos do usuário logado, nesse ponto quando o usuário esta logando, > meu EM, no gráfico de principais atividades da um pico tipo everest. Nessa > pauta, onde aparece os compromissos do usuário, se ele for dar baixa em > alguma atividade a aplicação congela por uns 30 segundos, meu gráfico do EM > vai lá nas alturas e depois volta tudo ao normal. > > O que mais me chama atenção, é que se ele der baixa por outro caminho é > instantaneo, nada acontece. > > Agradeço orientações. > > Obrigado! > > >
