É verdade, ele tinha um problema, mas as horas não estão incluídas na base de produção, nem na coluna date nem na tswtz. Obrigado pela atenção! A todos!
Em Sexta-feira, 8 de Novembro de 2013 16:05, J. Laurindo Chiappa <jlchia...@yahoo.com.br> escreveu: Ou seja, o dado que deveria estar como "12/09/16 00:00:00,000000 00:00" (sem fração de segundo E SEM tz) estava como "12/09/16 00:00:00,000000 -03:00" - sim, Claro que não ia funfar mesmo...Na verdade, se a fração de segundos E a TZ devem ser desconsideradas, alguém mais curioso perguntaria ** PARA QUE RAIOS ** exatamente se criou a coluna como TIMESTAMP ao invés de DATE... Bom, mas isso não muda nem a análise nem a conclusão - talvez possa até ser o caso de se Questionar com o solicitante se REALMENTE pode ter uma ocasião em que pode vir a ser exigido se guardar fração de segundo e/ou TZ - aí, se não for considerar a possibilidade de deixar como DATE a coluna, e se for possível de precisar aí NECESSARIAMENTE eles que alterem as queies ** todas ** que precisarem comparar tz com DT para fazer uma conversão explícita e para mesmos datatypes, nem que seja um simples WHERE TO_CHAR(colunadate,'dd/mm/yyyy') = TO_CHAR(colunatimestampTZ, 'dd/mm/yyyy') se não quiser usar o CAST citado na msg anterior.... []s Chiappa --- Em oracle_br@yahoogrupos.com.br, Roland Martins <dadim_op@...> escreveu > > Okdoc, passamos a sugestão/norma de nunca usar conversões implícitas para > eles. > > Agora, continuando a análise notei que, se fizer "ALTER SESSION SET > TIME_ZONE='-03:00';" o join volta a funcionar !!! E saímos de : > > COUNT(*) > ---------- > 0 > > Para: > > COUNT(*) > ---------- > 2571 > > Isso comparando "date" com "timestamp with timezone". > Analisando os dados da tabela que tem o TS com TZ, todas as linhas são do > tipo "12/09/16 00:00:00,000000 -03:00", ou seja, dados carregados *antes* do > horário de verão, como o componente -03:00 mostra. > > > > > Em Sexta-feira, 8 de Novembro de 2013 10:52, J. Laurindo Chiappa > <jlchiappa@...> escreveu: > > > Tudo jóia ? Só umas obs : realmente, como eu disse "qquer mudancinha de > client/database/ambiente/NLS settings/whatever" pode fazer a conversão > implícita parar de funcionar, e mudança de driver JDBC se encaixa nisso, sim, > é possível.... E como eu disse também, enquanto o pessoal ficar usando > conversão implícita, Riscos existirão : a SOLUÇÃO única e Recomendada é PARAR > DE USAR CONVERSÃO IMPLÍCITA, sim ??? Só isso vai te dar uma Mínia Segurança e > Estabilidade... > No caso específico do ODI ainda não trabalhei muito com ele (como foram muito > mais ambientes de DW por onde passei, o pessoal usava muito mais o OWB), > então não sei te indicar como, mas o pessoal TEM que descobrir como > "influenciar" o SQL gerado pelo ODI para que ele inclua necessariamente as > funções de conversão, de forma Explícita, comparando datatypes IGUAIS mesmo > as colunas sendo de datatypes diferentes... OK ? > > []s > > Chiappa > > --- Em oracle_br@yahoogrupos.com.br, Roland Martins <dadim_op@> escreveu > > > > Opa Chiappa, na verdade faltaram mesmo informações. estou na correria mas > > deixa eu dizer algumas: > > > > 1. O banco é 11203 EE. > > 2. Tem um ODI - Data Integrator - no meio da conversa, preciso ir lá ver se > > estão falando de alguma conversão que rola do lado de lá (na aplicação). > > 3. Falaram em versão de driver de jdbc. > > É isso, amanhã pela manhã verei como vai esta thread. > > Thank you all and good night! > > > > > > > > Em Quinta-feira, 7 de Novembro de 2013 22:23, J. Laurindo Chiappa > > <jlchiappa@> escreveu: > > > > > > Pitacos vc pediu, pitacos seguem, então .... > > > > a. vc conhece um filósofo chamado Gregory House ?? Ele tem uma regra geral, > > que é : EVERYBODY LIES! Assim, quando me fazem uma afirmação "ah, era > > assim, funcionava assim" mas SEM PROVAS, eu basicamente DESCONSIDERO... > > > > b. vc Não Diz a versão de nada : vou assumir aqui versão 10g nos meus > > testes e considerações, mas afaik deve valer pra outras também... > > Basicamente eu vejo que , quando vc faz : ... > > trunc(colunatimestamp)=trunc(colunadate) vc ***** CONTINUA ***** usando > > Conversão Implícita, sim ????? Veja lá na doc , em > > http://docs.oracle.com/cd/B19306_01/server.102/b14200/functions201.htm#i79761 > > no item sobre TRUNC, que ele SÓ FUNCIONA/recebe/aceita DATEs, sim ??? > > Então Com Certeza Óbvio que vai rolar algum tipo de conversão interna, SEJA > > dos dois datatypes para string e depois a string para DATE, seja do date > > para timestamp with tz, ou mesmo do timestamp with tz para DATE (embora não > > haja uma função direta para isso - > > http://docs.oracle.com/cd/B19306_01/server.102/b14200/functions183.htm#i1003589 > > no item TO_DATE ** Claramente ** que a função de conversão TO_DATE *** Não > > É capaz de converter nenhum tipo de stamp para DATE -, de repente o RDBMS > > pode fazer isso internamente com o equivalente a trunc(cast(timestamp as > > date)) .... > > O fato é : SE vc deixou pro RDBMS fazer uma conversão implícita, Qualquer > > Coisa pode acontecer.... Então ABSOLUTAMENTE não me espanta o TO_CHAR que > > vc viu no plano, Não Tem Porque não ser uma das opções.... No MEU DATABASE > > EE 10.2.0.5 o RDBMS optou diferente : > > > > SYSTEM@O10GR2:SQL>create table teste_tz > > 2 ( > > 3 col1 TIMESTAMP(6) WITH TIME ZONE, > > 4 col2 date > > 5 ) > > 6 / > > > > Tabela criada. > > > > SYSTEM@O10GR2:SQL> insert into teste_tz values > > 2 (CURRENT_TIMESTAMP, sysdate); > > > > 1 linha criada. > > > > SYSTEM@O10GR2:SQL>commit; > > > > Commit concluÝdo. > > > > SYSTEM@O10GR2:SQL>select * from teste_tz; > > > > COL1 > > COL2 > > ---------------------------------------------------------- > > ------------------- > > 07/11/13 21:48:17,065000 -02:00 > > 07/11/2013 21:48:17 > > > > SYSTEM@O10GR2:SQL>set autotrace on; > > SYSTEM@O10GR2:SQL>select count(*) from teste_tz where col1=col2; > > > > COUNT(*) > > ------------------ > > 0 > > > > Plano de ExecuþÒo > > ---------------------------------------------------------- > > Plan hash value: 4129657688 > > > > ---------------------------------------------------------- > > | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time > > | > > ---------------------------------------------------------- > > | 0 | SELECT STATEMENT | | 1 | 24 | 2 (0)| > > 00:00:01 | > > | 1 | SORT AGGREGATE | | 1 | 24 | | > > | > > |* 2 | TABLE ACCESS FULL| TESTE_TZ | 1 | 24 | 2 (0)| > > 00:00:01 | > > ---------------------------------------------------------- > > > > Predicate Information (identified by operation id): > > --------------------------------------------------- > > > > 2 - filter(SYS_EXTRACT_UTC("COL1")=SYS_EXTRACT_UTC(INTERNAL_FUNCTION( > > "COL2"))) > > > > EstatÝstica > > ---------------------------------------------------------- > > 5 recursive calls > > 0 db block gets > > 4 consistent gets > > 0 physical reads > > 0 redo size > > 418 bytes sent via SQL*Net to client > > 396 bytes received via SQL*Net from client > > 2 SQL*Net roundtrips to/from client > > 0 sorts (memory) > > 0 sorts (disk) > > 1 rows processed > > > > SYSTEM@O10GR2:SQL>select count(*) from teste_tz where > > trunc(col1)=trunc(col2); > > > > COUNT(*) > > ------------------ > > 1 > > > > Plano de ExecuþÒo > > ---------------------------------------------------------- > > Plan hash value: 4129657688 > > > > ---------------------------------------------------------- > > | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time > > | > > ---------------------------------------------------------- > > | 0 | SELECT STATEMENT | | 1 | 24 | 2 (0)| > > 00:00:01 | > > | 1 | SORT AGGREGATE | | 1 | 24 | | > > | > > |* 2 | TABLE ACCESS FULL| TESTE_TZ | 1 | 24 | 2 (0)| > > 00:00:01 | > > ---------------------------------------------------------- > > > > Predicate Information (identified by operation id): > > --------------------------------------------------- > > > > 2 - filter(TRUNC(INTERNAL_FUNCTION("COL1"))=TRUNC(INTERNAL_FUNCTION(" > > COL2"))) > > > > Note > > ----- > > - dynamic sampling used for this statement > > > > EstatÝstica > > ---------------------------------------------------------- > > 5 recursive calls > > 0 db block gets > > 7 consistent gets > > 0 physical reads > > 0 redo size > > 419 bytes sent via SQL*Net to client > > 396 bytes received via SQL*Net from client > > 2 SQL*Net roundtrips to/from client > > 0 sorts (memory) > > 0 sorts (disk) > > 1 rows processed > > > > ==> OU SEJA, optou por não fazer o TO_CHAR que o seu fez - PROVAVELMENTE > > deve estar usando algum CAST, mas é indeterminado.... > > > > c. para vc deixar de ter conversão implícita (que é INCONFIÁVEL, o RDBMS é > > livre pra fazer o que bem entender, pode invalidar uso de índices, etc, > > tátátá, tudo de RUIM), que é a SOLUÇÂO para o "problema" dos seus usuários, > > vc teria que EXPLICITAMENTE converter os datatypes (que são diferentes) na > > comparação do WHERE : já que não há (ao menos aqui no 10g, REPITO) uma > > função Oficial para converter stamp para DATE, penso que seria usar as > > oficiais (como a TO_TIMESTAMP_TZ) para EXPLICITAMENTE converter a coluna > > DATE para TIMESTAMP WITH TIME ZONE (obviamente usando o mesmo TZ da outra > > coluna).... > > E lembre-se : AINDA que por acidente hoje uma conversão implícita > > "funcione", NADA impede que amanhã, com qquer mudancinha de > > client/database/ambiente/NLS settings/whatever ela PARE DE FUNCIONAR.... > > Repito, a Única Solução é largar mão de usar implícita... > > > > []s > > > > Chiappa > > > > --- Em oracle_br@yahoogrupos.com.br, "dadim_op" <dadim_op@> escreveu > > > > > > Boa noite a todos! > > > > > > Estou pesquisando forums, etc e ainda não encontrei um resposta. > > > É simples: 2 tabelas, 1 join, de um lado coluna date, do outro, > > > timestamp(6) with timezone. Estão jurando aqui que funcionava uma > > > conversão implícita e retornava dados, isso em 02/outubro/13. > > > Até onde sei e pesquisei, não funciona. Nunca funcionou. > > > > > > Se vocês tiverem algum link, documento e puderem dar uns pitacos, > > > agradeço. Fiz o teste abaixo, até aqui conclusivo de que não funciona: > > > > > > > > > JACK on 07/nov/2013 19:17 at TESTDB >create table teste_tz > > > 2 ( > > > 3 col1 TIMESTAMP(6) WITH TIME ZONE, > > > 4 col2 date > > > 5 ) > > > 6 / > > > > > > Tabela criada. > > > Decorrido: 00:00:00.05 > > > JACK on 07/nov/2013 19:17 at TESTDB > insert into teste_tz values > > > (CURRENT_TIMESTAMP, sysdate) > > > 2 / > > > 1 linha criada. > > > Decorrido: 00:00:00.02 > > > > > > JACK on 07/nov/2013 19:18 at TESTDB > commit > > > 2 / > > > Commit concluÝdo. > > > Decorrido: 00:00:00.00 > > > > > > JACK on 07/nov/2013 19:18 at TESTDB > select * from teste_tz; > > > > > > COL1 > > > COL2 > > > ---------------------------------------------------------- > > > ----------------- > > > 07/11/13 19:18:26,743956 -02:00 > > > 07/nov/2013 19:18 > > > > > > Decorrido: 00:00:00.01 > > > JACK on 07/nov/2013 19:18 at TESTDB >select count(*) from teste_tz > > > 2 where col1=col2; > > > > > > COUNT(*) > > > ---------- > > > 0 > > > > > > JACK on 07/nov/2013 19:19 at TESTDB >r > > > 1 select count(*) from teste_tz > > > 2* where trunc(col1)=trunc(col2) > > > > > > COUNT(*) > > > ---------- > > > 1 > > > > > > Mais uma informação interessante vinda do EXPLAIN PLAN FOR: > > > Tab_001 é a tabela Fato. > > > > > > --SQL COM CONVERSÃO EXPLICITA FUNCIONA (retorna 2500 linhas) > > > Predicate Information (identified by operation id): > > > --------------------------------------------------- > > > 1 - > > > access(TO_CHAR(INTERNAL_FUNCTION("TAB_001"."COL_TIPO_DATE"),'dd/mm/rr')=TO_CHAR(INTERNAL_FUNCTION("DIMENSAO_DIA"."COL_TIPO_TIMESTAMP_WITH_TZ"),'dd/mm/rr')) > > > > > > > > > --SQL COM CONVERSÃO IMPLICITA NÃO FUNCIONA (retorna 0 linhas) > > > Predicate Information (identified by operation id): > > > --------------------------------------------------- > > > 1 - > > > access(SYS_EXTRACT_UTC(INTERNAL_FUNCTION("TAB_001"."COL_TIPO_DATE"))=SYS_EXTRACT_UTC("DIMENSAO_DIA"."COL_TIPO_TIMESTAMP_WITH_TZ")) > > > > > >
