Re: [oracle_br] Re: Como saber se existem sessões c om trace ligado no banco de dados ?
Obrigado a todos pelas respostas.Sim, ainda existem clientes que são
permissivos com seus ambientes produtivos, em pleno 2018, por razões
várias.Como a maioria dos DBAs, concordo com um antigo colega que dizia que
"produção é vaca sagrada", que não deveríamos nem logar, só se precisássemos,
mas muitos não entendem assim (por motivos vários).Faremos as sugestões, mas
não sei se concordam comigo quando digo que, para uma empresa, a palavra da
Infra vale menos que a do time de sistemas (aplicações), pois são eles que
"geram" negócio, que fazem o cascalho entrar na empresa. Obviamente, não direi
que isso é uma tendência do mercado, mas assim parece.Trabalhei numa empresa
onde o time de infra definiu e mudou a senha do SYS, SYSTEM, só para chegar na
segunda e ter de colocar a senha antiga de volta. Isso foi lá por 2010, 2011, e
a desculpa e que "quem desenvolve precisa trabalhar".
Ademais, obrigado a todos e um forte abraço!
Em sexta-feira, 9 de março de 2018 18:35:41 BRT, Luis Freitas
lfreita...@yahoo.com [oracle_br] escreveu:
Roland,
alter system set max_dump_file_size=10;
Ou qualquer outro numero pequeno.
Atc,
Luis Freitas
On Friday, March 9, 2018 1:57 PM, "jlchia...@yahoo.com.br [oracle_br]"
wrote:
Óbvio número dois : esse trace NÃO É ativado sozinho : ALGUÉM criou uma
trigger de logon, um shell script (disparado por cron ou não), alguém alterou a
aplicação, alguém alterou o parâmetro SQL_TRACE no banco, enfim ALGUÉM ativou
isso - além de identificar QUAIS sessões estão com isso ativo, vc DEVERÁ
IDENTIFICAR também QUEM fez e COMO FEZPra isso vc VAI ter que ter acesso ao
servidor, aos códigos da aplic, aos shell scripts em uso/cron, às triggers do
banco em questão, etc, etc, etc... O que PODE te ajudar é vc ABRIR os trace
files gerados num editor de texto, pois algumas informações básicas (como
username, data/hora de início do trace, SID/SERIAL# da sessão, etc) estão no
cabeçalho do trace file gerado...
[]s
Chiappa
#yiv8157148482 #yiv8157148482 -- #yiv8157148482ygrp-mkp {border:1px solid
#d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv8157148482
#yiv8157148482ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv8157148482
#yiv8157148482ygrp-mkp #yiv8157148482hd
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px
0;}#yiv8157148482 #yiv8157148482ygrp-mkp #yiv8157148482ads
{margin-bottom:10px;}#yiv8157148482 #yiv8157148482ygrp-mkp ..yiv8157148482ad
{padding:0 0;}#yiv8157148482 #yiv8157148482ygrp-mkp .yiv8157148482ad p
{margin:0;}#yiv8157148482 #yiv8157148482ygrp-mkp .yiv8157148482ad a
{color:#ff;text-decoration:none;}#yiv8157148482 #yiv8157148482ygrp-sponsor
#yiv8157148482ygrp-lc {font-family:Arial;}#yiv8157148482
#yiv8157148482ygrp-sponsor #yiv8157148482ygrp-lc #yiv8157148482hd {margin:10px
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv8157148482
#yiv8157148482ygrp-sponsor #yiv8157148482ygrp-lc .yiv8157148482ad
{margin-bottom:10px;padding:0 0;}#yiv8157148482 #yiv8157148482actions
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv8157148482
#yiv8157148482activity
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv8157148482
#yiv8157148482activity span {font-weight:700;}#yiv8157148482
#yiv8157148482activity span:first-child
{text-transform:uppercase;}#yiv8157148482 #yiv8157148482activity span a
{color:#5085b6;text-decoration:none;}#yiv8157148482 #yiv8157148482activity span
span {color:#ff7900;}#yiv8157148482 #yiv8157148482activity span
.yiv8157148482underline {text-decoration:underline;}#yiv8157148482
.yiv8157148482attach
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px
0;width:400px;}#yiv8157148482 .yiv8157148482attach div a
{text-decoration:none;}#yiv8157148482 .yiv8157148482attach img
{border:none;padding-right:5px;}#yiv8157148482 .yiv8157148482attach label
{display:block;margin-bottom:5px;}#yiv8157148482 .yiv8157148482attach label a
{text-decoration:none;}#yiv8157148482 blockquote {margin:0 0 0
4px;}#yiv8157148482 .yiv8157148482bold
{font-family:Arial;font-size:13px;font-weight:700;}#yiv8157148482
.yiv8157148482bold a {text-decoration:none;}#yiv8157148482 dd.yiv8157148482last
p a {font-family:Verdana;font-weight:700;}#yiv8157148482 dd.yiv8157148482last p
span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv8157148482
dd.yiv8157148482last p span.yiv8157148482yshortcuts
{margin-right:0;}#yiv8157148482 div.yiv8157148482attach-table div div a
{text-decoration:none;}#yiv8157148482 div.yiv8157148482attach-table
{width:400px;}#yiv8157148482 div.yiv8157148482file-title a, #yiv8157148482
div.yiv8157148482file-title a:active, #yiv8157148482
div.yiv8157148482file-title a:hover, #yiv8157148482 div.yiv8157148482file-title
a:visited {text-decoration:none;}#yiv8157148482 div.yiv8157148482photo-title a,
#yiv8157148482 div.yiv8157148482photo-title a:active, #yiv8157148482
div.yiv815714
[oracle_br] Como saber se existem sessões com trace ligado no banco de dados ?
O problema: O cliente, por algum motivo, ligou trace em1, 2 ou mais sessões no banco Oracle, e os filesystems estão explodindo.A pergunta: Como identificar quais das mais de 3000 conexões por nó, tem TRACE ligado ? Obs.: Na v$session (portanto na gv$session) existe uma coluna chamada SQL_TRACE, que teria os valores DISABLED ou ENABLED, porém, realizado teste (ligar trace na sessão), apareneteente não funciona. Versão 11gR2 e superiores.SO: Oracle Linux.
Re: [oracle_br] DBSNMP obrigatorio?
A situação é semelhante:1 target (que é o ambiente de produção, RAC de 4 nós,
versão 12.1.0.2, sim Banco 12cR1)2 EM12c (o deles e o nosso, em servidores
standalone no mesmo data center que o target) ... cada EM12c tem seu sysman,
óbvio.
Mas ao se conectarem ao target, usam DBSNMP ... aí temos o conflito ... ambos
EM12c precisam usar o mesmo usuário de banco (DBSNMP) no target ?
Em Quinta-feira, 4 de Fevereiro de 2016 19:20, "Luis Freitas
lfreita...@yahoo.com [oracle_br]" escreveu:
Dadim,
Acho que você está confundindo DBSNMP com SYSMAN.
No EM 12c (ou 11g...), o esquema SYSMAN fica no repositorio do EM, mas o
DBSNMP é parte do catalogo dos respectivos bancos de dados.
Então se você tem dois EM 12c, o que acontece é que você tem dois esquemas
SYSMAN, um em cada base repositorio do EM, mas nos "targets", tem só um DBSNMP
mesmo.
É comum ter essa situação quando se usa o EM com o Exadata, pois o servidor
do "Platinum" tem um EM, mas que é exclusivo para o suporte da Oracle, então o
cliente tem que instalar um segundo EM separado se quiser usar.
Atc,Luis Freitas
On Thursday, February 4, 2016 8:56 AM, "dadim...@yahoo.com.br [oracle_br]"
wrote:
Suponhamos que minha empresa tem um contrato com outra, que usa o EM12c
para monitorar 1 determinado target (produção, super-crítico, 24x7, etc).Agora
suponhamos que minha empresa comprou o EM12c e quer monitorar o mesmo target
(inclusive banco de dados 24x7, supercrítico).É possível monitorar um banco com
outro usuário, que não o DBSNMP? Ou o EM12c é amarrado neste usuário ?Obrigado
pelas respostas!
#yiv5770992327 #yiv5770992327 -- #yiv5770992327ygrp-mkp {border:1px solid
#d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv5770992327
#yiv5770992327ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv5770992327
#yiv5770992327ygrp-mkp #yiv5770992327hd
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px
0;}#yiv5770992327 #yiv5770992327ygrp-mkp #yiv5770992327ads
{margin-bottom:10px;}#yiv5770992327 #yiv5770992327ygrp-mkp .yiv5770992327ad
{padding:0 0;}#yiv5770992327 #yiv5770992327ygrp-mkp .yiv5770992327ad p
{margin:0;}#yiv5770992327 #yiv5770992327ygrp-mkp .yiv5770992327ad a
{color:#ff;text-decoration:none;}#yiv5770992327 #yiv5770992327ygrp-sponsor
#yiv5770992327ygrp-lc {font-family:Arial;}#yiv5770992327
#yiv5770992327ygrp-sponsor #yiv5770992327ygrp-lc #yiv5770992327hd {margin:10px
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv5770992327
#yiv5770992327ygrp-sponsor #yiv5770992327ygrp-lc .yiv5770992327ad
{margin-bottom:10px;padding:0 0;}#yiv5770992327 #yiv5770992327actions
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv5770992327
#yiv5770992327activity
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv5770992327
#yiv5770992327activity span {font-weight:700;}#yiv5770992327
#yiv5770992327activity span:first-child
{text-transform:uppercase;}#yiv5770992327 #yiv5770992327activity span a
{color:#5085b6;text-decoration:none;}#yiv5770992327 #yiv5770992327activity span
span {color:#ff7900;}#yiv5770992327 #yiv5770992327activity span
.yiv5770992327underline {text-decoration:underline;}#yiv5770992327
.yiv5770992327attach
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px
0;width:400px;}#yiv5770992327 .yiv5770992327attach div a
{text-decoration:none;}#yiv5770992327 .yiv5770992327attach img
{border:none;padding-right:5px;}#yiv5770992327 .yiv5770992327attach label
{display:block;margin-bottom:5px;}#yiv5770992327 .yiv5770992327attach label a
{text-decoration:none;}#yiv5770992327 blockquote {margin:0 0 0
4px;}#yiv5770992327 .yiv5770992327bold
{font-family:Arial;font-size:13px;font-weight:700;}#yiv5770992327
.yiv5770992327bold a {text-decoration:none;}#yiv5770992327 dd.yiv5770992327last
p a {font-family:Verdana;font-weight:700;}#yiv5770992327 dd.yiv5770992327last p
span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv5770992327
dd.yiv5770992327last p span.yiv5770992327yshortcuts
{margin-right:0;}#yiv5770992327 div.yiv5770992327attach-table div div a
{text-decoration:none;}#yiv5770992327 div.yiv5770992327attach-table
{width:400px;}#yiv5770992327 div.yiv5770992327file-title a, #yiv5770992327
div.yiv5770992327file-title a:active, #yiv5770992327
div.yiv5770992327file-title a:hover, #yiv5770992327 div.yiv5770992327file-title
a:visited {text-decoration:none;}#yiv5770992327 div.yiv5770992327photo-title a,
#yiv5770992327 div.yiv5770992327photo-title a:active, #yiv5770992327
div.yiv5770992327photo-title a:hover, #yiv5770992327
div.yiv5770992327photo-title a:visited {text-decoration:none;}#yiv5770992327
div#yiv5770992327ygrp-mlmsg #yiv5770992327ygrp-msg p a
span.yiv5770992327yshortcuts
{font-family:Verdana;font-size:10px;font-weight:normal;}#yiv5770992327
.yiv5770992327green {color:#628c2a;}#yiv5770992327 .yiv5770992327MsoNormal
{margin:0 0 0 0;}#yiv5770992327 o {font-size:0;}#yiv57
Re: [oracle_br] Oracle 11G
http://www.novatemporeal.com.br/index.php?route=common/home Em Sexta-feira, 16 de Maio de 2014 14:15, "rosiva...@gmail.com [oracle_br]" escreveu: Www.saraiva.com.br Ou Www.livrosdeinformatica.com.br Att. -- Rosivaldo Ramalho http://about.me/rosivaldo Enviado via iPhone Em 16/05/2014, às 08:13, "Caio César ccpn1...@gmail.com [oracle_br]" escreveu: Aonde vocês indicam para dowload do livro Oracle 11G - PL/SQL Programação. > > >-- > > > Caio Neves >(11) 7759.6852 > >
Re: [oracle_br] Oracle x SQL Server
Samuel, mais algum material para ajudar: Sua pergunta tem uma resposta bastante abrangente, e a resposta mais correta seria ... "depende", depende do uso que você vai dar. Oracle, assumindo que você não tenha, pode vir de grátis (Oracle XE) com bastante restrições, idealmente para desenvolvimento e coisas muito simples. Pode ser Oracle Standard edition, Enterprise Edition. Se há uma necessidade de divisão de carga de trabalho e/ou alta disponibilidade, você pode usar o cluster da Oracle - RAC - que pode ser grátis (no Oracle Standard Edition) ou pago (no Enterprise Edition). Para Disaster/Recover a Oracle fornece o Dataguard. O MSSQL praticamente da mesma forma, SQL Express Edition, Standard, Enteprise, cluster Ativo/Passivo - MSCS, replicação com Log Shipping, Mirroring para Disaster/Recover. Do que eu já vi/li por aí, Oracle é bem mais complexo/configurável, adere mais ao ACID (http://www.orafaq.com/wiki/ACID) que o SQL server, se bem que a versão MSSQL 2014 nem passei perto. Com Oracle há uma certa liberdade de plataforma (pregavam isso antigamente), pode ser Windows Server, Linux, AIX, Solaris e outros. Com MSSQL você está preso ao Windows. Em termos de licenciamento também depende, mas entenda bem que instalando o Enterprise Edition vem uma série de Features prontas-para-uso (advanced security, advanced compression, Tuning+Diagnostics Pack liberados) que você precisa licenciar, caso contrário, numa auditoria que a Oracle fizer, ela irá cobrar estas features - se estiverem em uso. Não sei falar do MSSQL http://www.oracle.com/us/products/database/enterprise-edition/comparisons/index.html#ct02-Download http://docs.oracle.com/cd/B28359_01/license.111/b28287/options.htm#DBLIC138 Auditoria no Oracle é bem mais flexível que no MSSQL, até onde pude ver. http://www.dbspecialists.com/blog/best-practices/overview-of-oracle-auditing/ Preço, a Oracle tem o famoso "preço de lista", mas dependendo do seu contrato, pode ter descontos bem vantajosos, por exemplo trabalhei numa empresa do grupo News Corporation e o desconto era muito, muito bom. https://shop.oracle.com/pls/ostore/f?p=dstore:home:0 Em Quarta-feira, 14 de Maio de 2014 15:00, "Andre Machado andres.mac...@gmail.com [oracle_br]" escreveu: Pessoal, estou tentando ler de um arquivo UTL_File.Get_Line(arquivo_ler, Linha,32767); Porem a variavel retorna com quebra de linha ja tentei fazer um linha := REPLACE(linha,CHR(10), ''); mas nao resolveu, alguma ideia ? Em 14 de maio de 2014 14:55, Fabio Prado fbifa...@gmail.com [oracle_br] escreveu: > >Obrigado Carlos! > > >[]s > > >Fábio Prado > > >www.fabioprado.net >"Compartilhando conhecimentos e treinando profissionais em Bancos de Dados >Oracle" > > > >Em 14 de maio de 2014 13:58, carlosaama...@yahoo.com.br [oracle_br] > escreveu: > > > >> >>Olá a todos, boa tarde !! >> >> >> Parabéns pelo artigo Fábio... >> >> >> >> >> Um abraço, >> >> >> Carlos > -- ___ André Machado
Re: [oracle_br] Troca de idéias: Alguém par ou de usar AWR e passou a usar STATSPACK em 1 0g/11g ?
Chiappa, obrigado pelas informações e insigths. Vimos que perderemos muito com isso, e faremos de tal modo que fique evidente para quem manda no pedaço os drawbacks da retirada do mesmo. Em Terça-feira, 6 de Maio de 2014 13:07, "jlchia...@yahoo.com.br" escreveu: Roland, a minha experiência em substituir o AWR (e seus amigos, como ASH e Advisors) pelo statspack está um tanto defasada (já há alguns anos eu não mexo com ele, então pode ser que algumas das obs que vou fazer mudaram) , mas foi bem diferente do que vc fala : existem Sim diferenças gritantes entre AWR/ASH x Statspack... O busílis é que PODE SER que vc não esteja usando as features/recursos/tools que o AWR/ASH dão e o statspack não dá (aó Óbvio que a transição vai ser suave) mas se estiver fique sabendo que VAI SIM haver problemas, e que provavelmente vc (ou o DBA do cliente, enfim, alguém) ** VAI ** ter que escrever algo para satisfazer, esteja certo de contabilizar esse tempo/esforço De modo geral : a) o statspack não é habilitado por default, nem tem as coletas agendadas automaticamente, requerendo ação do DBA para setup E para agendar as coletas b) statspack não armazena históricos, é por sua conta criar uma rotina de arquivamento de históricos, no estilo de http://www.oraclerealworld.com/ash-masters/ : isso implica também que sem essa customização adicional, análises do tipo "comparar planos de execução anteriores com boa performance versus plano atual que piorou", ou "impacto no database depois da nova versão x da aplicação" não são viáveis... c) statspack só faz coletas ONLINE e não sobrevive a reboots/restarts do banco, Exigindo que o banco absolutamente não tenha sido parado no intervalo entre dois snapshots d) afaik statspack basicamente *** parou no tempo *** na versão 9ir2, a esmagadora maioria das novas estatísticas de performance introduzidas no 10g (como por exemplo a informação de I/Os extraída do SO, o plano de xecução Extendido - ie, colas A-ROWs e E-ROWS, por exemplo -, as estatísticas de SQl adicionadas ás views relacionadas à V$SQL, etc), e das novas técnicas de análise (como TIME MODEL, por exemplo) NÂO SÃO SUPORTADAS no statspack... Deixo sem comentar as capacidades do 11gr2 que o statspack não suporta, já que não tive a chance de comprovar num banco 11g , mas certamente imagino que devem ser basicamente todas e) statspack basicamente desconsidera as estatísticas de performance/waits referentes a RAC, e é single-instance : em caso de RAC é por sua conta rodar um report de statspack em cada nó f) afaik o statspack não permite análise a nível de SQL, ao contrário do AWR que o permite via e o mais impactante : ao não licenciar o diag pack, além de perder o AWR/ASH vc perder também os ADVISORS : ok que nem sempre eles te salvam a cara mas algumas vezes dão sim recomendações eventualmente úteis, e coisas que vc não tinha pensado Neste último caso, aí não há outra solução que não implementar manualmente a expertise do DBA nalguma rotina escrita por vc (ou pelo DBA do cliente, enfim) que Simule ações do tipo das que os Advisors fazem... []s Chiappa
Re: [oracle_br] Troca de idéias: Alguém parou de usar AWR e passou a usar STATSPACK em 10g/11g ?
Obrigado pela resposta Rosivaldo. Pelo que li até agora, o ato de desligar o AWR não deve trazer muitos problemas (no 11g talvez nenhum, apenas algumas features não-licenciáveis-separadamente irão parar de funcionar), no caso do 10g deve ser mais interessante, será preciso executar um pacote para desabilitar o AWR. Encontrei alguns documentos que podem ser de interesse, por exemplo: ORA-00600 [Ktspfupdst-1] On Delete From a STATSPACK Object. (Doc ID 750211.1) ORA-06550 PLS-00201 while running statspack.snap to generate snapshot (Doc ID 578293.1) Em Terça-feira, 6 de Maio de 2014 7:36, Rosivaldo Ramalho escreveu: Roland, Eu constantemente utilizo o statspack, principalmente em clientes com SE e SE1. Eu particularmente não vejo muita diferença entre ambos, o principal ponto é o método de trabalho. Você basicamente vai ter que ficar comparando diversas "versões" do relatório que você tira, mas no final, sempre vai para os waits e os SQLs que mais consomem, e a partir daí é tunning normal de banco. Lembra de fazer uma manutenção básica de limpeza dos dados do statspack, eles tendem a crescer quando a coleta fica automática. 2014-05-02 19:08 GMT-03:00 Roland Martins : > > >Boa noite a todos. Um dos clientes no qual dou suporte solicitou que façamos >um estudo para não usarmos o AWR (Diagnostics + Tuning Pack) e passarmos a >usar a alternativa STATSPACK por questões de licenciamento. Todas as versões >Oracle são EE 10.2 ou 11.2 em Linux, claro, com: > > >NAME TYPE VALUE > --- - >control_management_pack_access string DIAGNOSTIC+TUNING > > >Alguns documentos pesquisados incluem: >Controlling Diagnostic and Tuning Pack Usage and Disabling AWR [ID 436386.1] > >FAQ- Statspack Complete Reference (Doc ID 94224.1) > >AWR Reporting - Licensing Requirements Clarification (Doc ID 1490798.1) > >http://www.pythian.com/blog/an-open-letter-to-larry-ellison-on-awr-and-ash-licensing/ > > > >Dei início à minha pesquisa em Documentação / Notas de Metalink, mas seria >interessante saber se alguém já passou por coisa semelhante, que tipo de >problemas, surpresas - agradáveis e desagradáveis - encontrou, Links >interessantes e por aí afora. > > >Grato a todos! > > -- Rosivaldo Azevedo Ramalho Consultor Oracle Database & Fusion Middlerware http://about.me/rosivaldo
[oracle_br] Troca de idéias: Alguém parou de usar AWR e passou a usar STATSPACK em 10g/11g ?
Boa noite a todos. Um dos clientes no qual dou suporte solicitou que façamos um estudo para não usarmos o AWR (Diagnostics + Tuning Pack) e passarmos a usar a alternativa STATSPACK por questões de licenciamento. Todas as versões Oracle são EE 10.2 ou 11.2 em Linux, claro, com: NAME TYPE VALUE --- - control_management_pack_access string DIAGNOSTIC+TUNING Alguns documentos pesquisados incluem: Controlling Diagnostic and Tuning Pack Usage and Disabling AWR [ID 436386.1] FAQ- Statspack Complete Reference (Doc ID 94224.1) AWR Reporting - Licensing Requirements Clarification (Doc ID 1490798.1) http://www.pythian.com/blog/an-open-letter-to-larry-ellison-on-awr-and-ash-licensing/ Dei início à minha pesquisa em Documentação / Notas de Metalink, mas seria interessante saber se alguém já passou por coisa semelhante, que tipo de problemas, surpresas - agradáveis e desagradáveis - encontrou, Links interessantes e por aí afora. Grato a todos!
Re: [oracle_br] Re: Erro intermitente na execução de PL/SQL
Aproveite e dê uma checada no tipo de conexão com o banco, que versões, que drivers, etc. Em Quarta-feira, 30 de Abril de 2014 12:19, Milton Bastos Henriquis Jr. escreveu: Roberto Tem 99% de chances do erro ser do programador (Visual Basic). Se a procedure funciona normalmente rodando direto no banco, parece muito provável que há algo errado ao executar essas procedures pelo VB. TEM que debugar e conferir quais os valores EXATOS dos parâmetros que estão sendo passado ao chamar a procedure. As vezes vc pensa que tá passando um valor, mas tá passando oo - ou de repente não tá nem passando algum dos valores. As vezes também vc pensa que está passando uma data num formato, mas o banco está recebendo num formato diferente. Enfim... pra nós aqui completamente as cegas, sem saber o que está acontecendo e sem ver esses erros fica realmente quase impossível, vira apenas um exercício de adivinhação. Mas por experiências anteriores tudo leva a crer que seja isso que citei acima. Faça o debug, confira os valores! Em 30 de abril de 2014 11:37, Roberto Warstat escreveu: > >Ederson, >A questão é que não tenho nenhum erro ORA. Os erros que me refiro é da >aplicação não estar se comportando da maneira adequada. >Conforme postei inicialmente, o problema ocorre quando executo os processos >via front-end, que é feito em Visual Basic 6. Se executo via PL/SQL Developer, >não tenho problemas. > > >Abraço, >Roberto Warstat > > > >Em 30 de abril de 2014 11:34, escreveu: > > > >> >>Bom dia, >> >> >>Vamos lá: vc precisa colocar no texto da mensagem: os erros ORA, o número do >>erro e a mensagem com argumentos (se houver). Não coloque arquivo anexado >>pois o grupo não recebe anexos. >> >> >>Lembre-se que os erros que não começam com ORA- (FRM-, REP- e alguns mais), >>são mensagens da sua ferramenta de programação e devem ser debugados junto ao >>desenvolvedor da mesma. >> >> >>Aproveite para informar se no ALERT.log deste banco, está registrando algum >>erro durante a execução do processo que vc está verificando. >> >> >>Informe também se vc está usando alguma GUI como All Around PL/SQL Developer, >>Oracle Sql Developer, Toad/Squirrel etc e se já ligou o modo debug da >>ferramenta para entrar passo-a-passo em cada rotina até a apresentação do >>erro. >> >> >>Ederson Elias >>DBA Oracle - http://br.linkedin.com/pub/ederson-elias/24/8b/8b0 >> Labor improbus omnia vincit >
Re: [oracle_br] Pergunta rápida sobre options de se gurança
Chiappa, correto Oracle Label Security. Estamos analisando aqui implementar Label Security (OLS) e/ou VPD integrado com LDAP para os acessos externos (web) de consumidores de relatórios no BIEE, se puderem indicar algumas referências, agradeço. Enquanto isso, estou nas pesquisas. A idéia é usar apenas "row-level security". Obrigado a todos. Em Quinta-feira, 3 de Abril de 2014 18:50, "jlchia...@yahoo.com.br" escreveu: Roland, Adicionalmente, notar que desconheço a sigla OSL nesse contexto de produto de Segurança : será que vc não quis dizer OSB (Oracle Secure Backup), OLS (Oracle Label Security, provável) ou OAS (Oracle Advanced Security) ?? []s Chiappa
Re: [oracle_br] Pergunta rápida sobre options de segurança
Maravilha Milton! Obrigado! Em Quinta-feira, 3 de Abril de 2014 18:35, Milton Bastos Henriquis Jr. escreveu: Olá Roland Vc pode consultar aqui todas as Features e Options de cada edição do Oracle Database. O que tem pontinho vermelho é feature (ou seja, já incluso). O que tem escrito Option necessita de licenciamento adicional. http://www.oracle.com/us/products/database/enterprise-edition/comparisons/index.html Em 3 de abril de 2014 18:33, Roland Martins escreveu: > >Boa noite! >Oracle Enterprise Edition >Versão 11203 >Optando por usar VPD e/ou OSL, teríamos de fazer algum investimento? Ou elas >já estão inclusas na EE ? >Grato.
[oracle_br] Pergunta rápida sobre options de segurança
Boa noite! Oracle Enterprise Edition Versão 11203 Optando por usar VPD e/ou OSL, teríamos de fazer algum investimento? Ou elas já estão inclusas na EE ? Grato.
[oracle_br] Por que SYS não usa sua TEMPORARY_TABLESPACE no expdp ?
Prezados, boa noite! Um dos clientes no qual atuo (com área de Desempenho de aplicações principalmente, não administração) utiliza bastante Datapump, especialmente para mover partes de bases de produção (esquemas, ou partições de tabelas grandes) para bancos de teste, desenvolvimento e homologação. Embora a Oracle recomende que *não* se deve usar o SYS para esta tarefa, eles utilizam. Esta informação aparece aqui: http://docs.oracle.com/cd/E11882_01/server.112/e22490/dp_export.htm#SUTIL200 Pois é, no presente caso o banco de produção é 11203 em Linux (64bit). A default temporary tablespace do banco é uma, a temporary tablespace do SYS é outra. O que ocorre é que, quando rodam este expdp, o SYS não utiliza sua temporária, mas a temporária *default* do banco. Esta temporária*default* do banco foi criada para separar certos usuarios que gastam muita temp com joins cartesianos, e vez ou outra entram em RESUMABLE. Pesquisando neste sábado nebuloso de SP, não encontrei evidências descrevendo este comportamento (ainda), mas me lembrou o conceito de "definers rights" e "invokers rights", como descrito aqui http://allthingsoracle.com/invoker-rights-part-1/. Alterar a default *temp* do banco é um teste a ser feito, pode ser que o Kingpin comece a usar e explodir a temp "oficial" do banco. Seguem alguns dados (Obs.: Kingpin é o vilão da estória, o cara que derrubou o EXPDP): PUNISHER on 08/mar/2014 18:44 at prodDB >@defaulttbs PROPERTY_NAME PROPERTY_VALUE DESCRIPTION -- -- -- DEFAULT_TEMP_TABLESPACE TEMP_USERS Name of default temporary tablespace DEFAULT_PERMANENT_TABLESPACE USERS Name of default permanent tablespace PUNISHER on 08/mar/2014 18:44 at prodDB >@user Informe o valor para digite_dbuser: KINGPIN USERNAME CREATED ACCOUNT_STATUS LOCK_DATE TBS TBS_TEMP PROFILE --- - --- -- -- KINGPIN 06-JUN-13 11:12 OPEN USERS TEMP_USERS DEFAULT PUNISHER on 08/mar/2014 18:44 at prodDB >@user Informe o valor para digite_dbuser: SYS USERNAME CREATED ACCOUNT_STATUS LOCK_DATE TBS TBS_TEMP PROFILE --- - --- -- -- SYS 17-SET-11 09:46 OPEN SYSTEM TEMP DEFAULT
Re: [oracle_br] Valor Particionamento de Tabela
vocês não possuem um representante de vendas ou um gerente de contas? Muitas vezes eles podem esclarecer isso. Em Quinta-feira, 27 de Fevereiro de 2014 17:59, Vitor Junior escreveu: Hermenegildo!!! Você por aqui? Sempre brilhante! :) Att,/Regards, Vitor Jr. Infraestrutura / Infrastructure Team Oracle 11g DBA Certified Professional - OCP Oracle Certified Expert, Oracle Real Application Clusters 11g and Grid Infrastructure Administrator - OCE Oracle Database 11g Performance Tuning Certified Expert - OCE Oracle Exadata 11g Certified Implementation Specialist Oracle Certified Associate, MySQL 5 mail, gtalk e msn: vitorj...@gmail.com http://certificacaobd.com.br/ skype: vjunior1981 https://mybizcard.co/vitor.jr.385628 Em 27 de fevereiro de 2014 17:56, escreveu: > >Boa Tarde, > > >Ainda sobre o licenciamento: Alguns clientes que atendo adotaram o Oracle VM e >virtualizaram as maquinas onde rodam os bancos de dados, justamente para fugir >do problema dos múltiplos cores. Isso em função da maneira como o oracle é >licenciado quando esta rodando no OVM. Por exemplo: > > >Se tu usa um vmware e a tua maquina host tiver 12 cores, e tu cria uma VM com >2 cores apenas, no momento do licenciamento a Oracle cobra o valor dos 12 >cores, o que esta no host (para cada VM que usar oracle nesse host). Já se tu >tem o mesmo cenário mas com o Oracle VM, tu consegue licenciar apenas 2 cores >da vm que roda o oracle, independente de quantos cores o host das vms tiver. > > >Mas por que isso é bom ? > > >Por que assim tua empresa pode comprar maquinas muito superiores em poder de >processamento e controlar o quanto vai gastar com as licenças do oracle, >inclusive se baseando na demanda, já que tu pode num futuro precisar de mais >hardware e licenciar apenas os cores que tu adicionar. Hoje em dia é difícil >achar maquinas com poucos cores de alto poder de processamento, geralmente são >maquinas com múltiplos sockets e processadores de multiplos cores. Um terror >na hora de pagar a Oracle. > > >At >Hermes PimentelOracle Certified 11gR2 RAC and Grid Infrastructure >Administrator Expert >Oracle 11g DBA Certified Professional > >Oracle MySQL DBA Certified Professional
Re: [oracle_br] RE: Tunning de Queries
Rapaz, o que vemos por aí é a mesma coisa: o desenvolvedor escreve, quem "tuna" é o DBA. Visão errada esta, vários desenvolvedores sabem ler um plano, questionar estatísticas - de objetos e de sistema, histogramas, influenciar o CBO com hints, mas a qualidade de muitos desenvolvedores é bem ruim (eles ficam ali, escrevendo queries, mexendo nos celulares, sites de compras, viagens internacionais... e o desempenho da query ? Ah, a gente manda pros DBAs, aos 47 do segundo tempo, eles resolvem - e nem sempre do melhor jeito), isso quando o problema já não aparece direto em produção (tem lugares que funciona assim, todos sabemos) e aí é você que tem o pepino pra descascar. Mas, como diz aquele provérbio chinês, é melhor acender uma vela que queixar-se da escuridão. Chiappa está correto. Adiciono o que diz Thomas Kyte (na época do 8i Release 3, mas ainda atual): "Here is a short extract from a book I am working on. The short answer is if you want a 10 step guide to tuning a query, buy a piece of software. You are not needed in this process, anyone can put a query in, get a query out and run it to see if it is faster. There are tons of these tools on the market. They work using rules (heuristics) and can tune maybe 1% of the problem queries out there. They APPEAR to be able to tune a much larger percent but that is only because the people using these tools never look at the outcome -- hence they continue to make the same basic mistakes over and over and over. If you want to really be aboe to tune the other 99% of the queries out there, knowledge of lots of stuff -- physical storage mechanisms, access paths, how the optimizer works - thats the only way. of course, read: http://download-west.oracle.com/docs/cd/A87860_01/doc/server.817/a76965/toc.htm from cover to cover and http://download-west.oracle.com/docs/cd/A87860_01/doc/server.817/a76992/toc.htm as well 1.1 Efficient SQL This was probably the hardest part of the book to write - this chapter. That is not because the material is all that complex, rather because I know what people want - and I know what can be delivered. What people want: The 10 step process by which you can tune any query. What can be delivered: Knowledge about how queries are processed, knowledge you can use and apply day to day as you develop them. Think about it for a moment. If there were a 10 step or even 1,000,000 step process by which any query can be tuned (or even X% of queries for that matter), we would write a program to do it. Oh don't get me wrong, there are many programs that actually try to do this - Oracle Enterprise Manager with its tuning pack, SQL Navigator and others. What they do is primarily recommend indexing schemes to tune a query, suggest materialized views, offer to add hints to the query to try other access plans. They show you different query plans for the same statement and allow you to pick one. They offer "rules of thumb" (what I generally call ROT since the acronym and the word is maps to are so appropriate for each other) SQL optimizations - which if they were universally applicable - the optimizer would do it as a matter of fact. In fact, the cost based optimizer does that already - it rewrites our queries all of the time. These tuning tools use a very limited set of rules that sometimes can suggest that index or set of indexes you really should have thought of during your design. I'll close this idea out with this thought - if there were an N step process to tuning a query, to writing efficient SQL - the optimizer would incorporate it all and we would not be having a discussion about this topic at all. It is like the search for the holy grail - maybe someday the software will be sophisticated enough to be perfect in this regards, it will be able to take our SQL, understand the question being asked and process the question - rather then syntax. To me - writing efficient SQL requires a couple of things: o Knowledge of the physical organization of what I'm asked to query against. That is - the schema. Knowledge that the physical organization was actually designed in order to help me answer my frequently asked questions (refer back to the chapter on designing an efficient schema for advice in that arena) o Knowledge of what the database is capable of doing. If I did not know about "skip scan indexes" and what they did (we'll cover them below) - I might look at a schema and say "ah hah, we are missing an index" when in fact we are not. o Knowledge of all of the intricacies of SQL - from the lowly "WHERE" clause on up to analytics and psuedo columns. Knowledge of what using a particular construct will do to my runtime processing. o And most importantly of all - a solid understanding of the goal, of what the question is. Tuning a query or process is really hard (impossible I would say) - unless you understand the question in the first place. I cannot tell
[oracle_br] Decluster (desclusterizar) RAC 11.2 com 2 nós em Linux
Boa noite. Estou à procura de material, Notas do MOS, links sobre des-clusterizar um RAC 11.2 EE (2 nós) que hoje roda em Linux. A princípio imaginei deixar uma instance disabled, mas preciso compreender melhor todo o cenário envolvido. Seria tão simples quanto 1) cluster_database=false 2) deletenode.sh ? Se possuírem algum documento/link, agradeço antecipadamente. Boa noite a todos!
Re: [oracle_br] ORA 12514
Já, resolvi assim: SERVICE_NAME Parameter - Resolving The ORA-12514 Error [ID 77640.1] Em Segunda-feira, 13 de Janeiro de 2014 12:39, Roger Camatini escreveu: Bom dia, Alguem j€ ¦á teve problemas com esse erro acima, estou tendo em uma maquina que utiliza instant_client para acessar um banco de dados, entradas do tnsnames est€ ¦á ok, variavel tns_admin setada tbm. Atenciosamente, Rog€ ¦ério Camatini.
Re: [oracle_br] Oracle RAC e diferença de data entre os nodes
Creio que poderá verificar via Note: RAC and Oracle Clusterware Best Practices and Starter Kit (Platform Independent) (Doc ID 810394.1) Em Segunda-feira, 6 de Janeiro de 2014 15:22, Vitor Junior escreveu: Boa tarde pessoal. Alguém tem em mãos aí a nota do metalink que fala sobre o problema de reboot do node devido a diferença de data entre os nodes? Lembro de ter lido essa nota mas não estou achando entre meus favoritos. Abraços! Att,/Regards, Vitor Jr. Infraestrutura / Infrastructure Team Oracle 11g DBA Certified Professional - OCP Oracle Certified Expert, Oracle Real Application Clusters 11g and Grid Infrastructure Administrator - OCE Oracle Database 11g Performance Tuning Certified Expert - OCE Oracle Exadata 11g Certified Implementation Specialist Oracle Certified Associate, MySQL 5 mail, gtalk e msn: vitorj...@gmail.com http://certificacaobd.com.br/ skype: vjunior1981 https://mybizcard.co/vitor.jr.385628
Re: [oracle_br] Melhora este SQL (Everything on Parse)
Olá lista! Após alguma análise, alguns pontos ficaram bem claros: 1) Existem 3 IN lists com qtde enorme de valores, é uma query com mais de 800 linhas. 2) Esse sistema é estilo DSS, portanto MBRC está em 512, o que favorece FTS's for sure, mas pelo que eu vi nem é o caso o acesso às tabelas ditas "de usuários". 3) Pela ASH, ele passa muito tempo lendo objetos como SYS.C_OBJ#_INTCOL# (histogramas, pelo que pesquisei). Então pensei em rodar esta query ignorando os histogramas, mas imagino que o gargalo vai mudar de lugar, vai sair do parse e ir para o execute. O goal é rodar tal comando abaixo dos 5 minutos porque neste tempo a conexão é cancelada. Isso ocorre para 1 cliente num universo de dezenas (hoje, é claro, não posso falar de amanhã). Ontem, com algumas modificações, tipo fazendo HASH JOIN, fazendo PARALLEL ali, ficou assim: call count cpu elapsed disk query current rows --- -- -- -- -- -- -- Parse 1 1088.23 1091.13 0 0 0 0 Execute 1 0.00 0.00 0 0 0 0 Fetch 1 1.15 1.16 20472 61447 204 0 --- -- -- -- -- -- -- total 3 1089.40 1092.30 20472 61447 204 0 Se alguém já viu algo assim (muito IN), ou puder causar algum insight, agradeço antecipadamente. Em Sábado, 14 de Dezembro de 2013 10:47, dadim_op escreveu: Ambiente: OracleEE 11203 em Linux Red Hat 6. Filesystem. Me mandaram um SQL gerado pelo BIEE, ele tem umas 800 linhas. Não consigo rodar no sqlplus, dá erro de entrada longa demais (tem um IN nele com centenas de itens, e aparece 6 vezes em todas as 800 linhas). Assim, parti para o plsql developer,nele consigo rodar numa base de teste com massa da produção, com trace ligado. O plano não vem ao caso, o que despertou minha curiosidade foi isso, você sabe por que isso ocorre? OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS call count cpuelapsed disk querycurrentrows --- -- -- -- -- -- -- Parse6 2176.722179.10 0 4 0 0 Execute 6 0.00 0.00 0 0 0 4 Fetch2 0.21 0.22 1 4852432 1 --- -- -- -- -- -- -- total 14 2176.942179.33 1 4856432 5 Foi um único SQL, mas aqui tem os recursivos também, mas foi tudo na conta do grandão.
Re: [oracle_br] Processo Oracle no windows maior que os parâmetros de Memória Oracle
Não tenho os detalhes agora, mas tive problemas com o agente do Grid Control 11g (perl), que ia consumindo cada vez mais memória até capotar. Era em Windows 2003 Server. Foi resolvido com patch. Pode ser interessante procurar alguma evidência de memory leak também. HTH. Em Terça-feira, 3 de Dezembro de 2013 15:13, Alessandro Lúcio Cordeiro da Silva escreveu: Olá Fernando, no caso descobri que especificamente uma aplicação desenvolvido em PHP que causa o uso excessivo de memória. Quando desabilitamos esta aplicação, todas as demais aplicações funcionaram normalmente. Ainda não detectei a causa raiz do problema, mas pode ser que talvez não seja somente aplicar o 11.2.0.3, creio que talvez tenha que atualizar a versão do PHP. Alessandro Lúcio Cordeiro da Silva Analista de Sistema þ http://alecordeirosilva.blogspot.com/ Porque esta é a vontade de Deus, a saber, a vossa santificação: que vos abstenhais da prostituição. (1º Tessalonicenses 4:3) Em , Alessandro Lúcio Cordeiro da Silva escreveu: Os parametros MEMORY_TARGET e MEMORY_MAX_TARGET estão com 6G, os demais coloquei 0 (zero) para usar somente os novos parametros do 11g Alessandro Lúcio Cordeiro da Silva Analista de Sistema þ http://alecordeirosilva.blogspot.com/ Porque esta é a vontade de Deus, a saber, a vossa santificação: que vos abstenhais da prostituição. (1º Tessalonicenses 4:3) Em Terça-feira, 3 de Dezembro de 2013 10:49, Fabio Prado escreveu: Alessandro, passe para nós os valores configurados na instância para os parâmetros abaixo: SGA_TARGET SGA_MAX_SIZE MEMORY_TARGET MEMORY_MAX_TARGET PGA_AGGREGATE_TARGET Att, Fábio Prado www.fabioprado.net Em 3 de dezembro de 2013 08:40, Alessandro Lúcio Cordeiro da Silva escreveu: > > > > Bom dia Senhores, > > > > Após a migração do Oracle 10.2.0.4 para o 11.2.0.1 em um ambiente Windows >2008 Server R2, o processo Oracle começa a consumir toda a memória do Servidor >de 16G de memoria principal, mesmo configurando os parametros >SGA_TARGET/SGA_MAX_SIZE ou os novos parâmetros MEMORY_TARGET/MEMORY_MAX_TARGET. > > > Configuro estes parâmetros para usar cerca de 5 Giga, mas em algum >determinado momento o processo Oracle do Windows começa a crescer até bater os >quase 16 Giga, deixando a maquina super-lenta, alem do próprio Oracle. > > > Em uma analise feita até o momento alguma sessão de Usuário começa a >crescer muito e somente é possível mata-la via oraKill do Windows. Como uma >sessão de Usuário consegue usar mais memoria do que os parâmetros de memoria >do Oracle? Tentei limitar mesmo usar Profile de limite de uso, mas este >comportamento permanece. > > >Obrigado! > > > > > >Alessandro Lúcio Cordeiro da Silva > Analista de Sistema > >þ http://alecordeirosilva.blogspot.com/ > >Porque esta é a vontade de Deus, a saber, a vossa >santificação: que vos abstenhais da prostituição. >(1º Tessalonicenses 4:3) > -- Fábio Prado www.fabioprado.net "Compartilhando conhecimentos e treinando profissionais em Bancos de Dados Oracle"
Re: [oracle_br] Re: Conversão implícita date e timestamp with timezone
É 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 escreveu: Ou seja, o dado que deveria estar como "12/09/16 00:00:00,00 00:00" (sem fração de segundo E SEM tz) estava como "12/09/16 00:00:00,00 -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/') = TO_CHAR(colunatimestampTZ, 'dd/mm/') se não quiser usar o CAST citado na msg anterior []s Chiappa --- Em oracle_br@yahoogrupos.com.br, Roland Martins 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,00 -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 > 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 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 > > 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 > >
Re: [oracle_br] Re: Conversão implícita date e timestamp with timezone
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,00 -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 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 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 > 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 ( > 3col1 TIMESTAMP(6) WITH TIME ZONE, > 4col2 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 > > -
Re: [oracle_br] Re: Conversão implícita date e timestamp with timezone
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
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 (
3col1 TIMESTAMP(6) WITH TIME ZONE,
4col2 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;
COL1COL2
-- ---
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 b
Re: [oracle_br] Problemas com conexão - erro ORA-3113
Adotamos uma solução de contorno dentre algumas existentes. Nese caso até o momento, adotamos o valor "temp_disable" para o parâmetro "star_transformation_enable". Apenas como referência, o defeito que melhor descreveu nosso cenário foi o 12971242. HTH. Em Quinta-feira, 31 de Outubro de 2013 15:00, [Paulo Sousa] escreveu: Boa tarde. Como está o seu parâmetro "CURSOR_SHARING"? Como eu não sei qual o valor do seu parâmetro, tente executar a mesma consulta com o CURSOR_SHARING setado para 'EXACT' e depois para 'SIMILAR'. Realmente, como o Chiappa disse, você tem um bug aí nas suas mãos. O que você pode fazer até ter isso resolvido é encontrar a solução de contorno, como montar a consulta de um outro jeito, mudar o valor do parâmetro cursor_sharing quando for executar essa consulta ou fazer um flush na shared_pool e tentar a execução da mesma consulta. []'s Paulo Sousa 2013/10/22 dadim_op > >Boa noite pessoal. >O motivo que me levou a abrir este thread é saber se alguém já pegou este >problema, e talvez possa indicar um caminho. Se não, tudo bem. >Já temos chamado aberto, antes que perguntem. E já verificamos 2 ou 3 >workarounds, e pelo que entendi do assunto, é o que a maioria está adotando, e >não me surpreenderei se acontecer por aqui. Enfim, se já viram isso, conhecem >detalhes, agradeço a informação. > >Referências: Doc ID 1544427.1, Bug 15954362. > >Ao executar um comando num Oracle 11.2.0.3 EE em Linux: >1) No cliente: ORA-3113 >2) No alert log: > >Tue Oct 22 18:19:32 2013 >Exception [type: SIGSEGV, Address not mapped to object] [ADDR:0x2B438E9C7F4B] >[PC:0x459E302, _intel_fast_memcmp()+30] [flags: 0x0, count: 1] >Errors in file >/path1/app/oracle/diag/rdbms/banco1/banco1/trace/banco1_ora_32517.trc >(incident=624598): >ORA-07445: exceção encontrada: dump de memória [_intel_fast_memcmp()+30] >[SIGSEGV] [ADDR:0x2B438E9C7F4B] [PC:0x459E302] [Address not mapped to object] >[] >Incident details in: >/path1/app/oracle/diag/rdbms/banco1/banco1/incident/incdir_624598/banco1_ora_32517_i624598.trc >Use ADRCI or Support Workbench to package the incident. >See Note 411.1 at My Oracle Support for error and packaging details. >Tue Oct 22 18:19:35 2013 >Dumping diagnostic data in directory=[cdmp_20131022181935], requested by >(instance=1, osid=32517), summary=[incident=624598]. >Tue Oct 22 18:19:37 2013 >Sweep [inc][624598]: completed >Sweep [inc2][624598]: completed > >Agradeço antecipadamente a ajuda! >Valeu! > >PS.: O que achei curioso, é que no PLSQL DEV ele rola legal e faz o primeiro >fetch na tela, só pelo terceiro ou quarto fetch ele dá o ORA-3113. Já no >SQL*plus, tanto na minha estação quanto no próprio servidor nada é retornado, >apenas o erro 3113. > >
Re: [oracle_br] Re: Migração Oracle 8.
Talvez você já tenha ido atrás, mas não custa mencionar: Master Note For Oracle Database Upgrades and Migrations (Doc ID 1152016.1) Em Terça-feira, 29 de Outubro de 2013 15:30, Daniel Mello escreveu: Muito obrigado a todos pela ajuda. Pra eu encontrar a média de tempo para janela de migração, terei que ensaia-la algumas vezes, vou tentar todas as alternativas para escolher a que se sair melhor. Agradecido. Daniel. Em Segunda-feira, 28 de Outubro de 2013 18:13, J. Laurindo Chiappa escreveu: Tudo jóia, Daniel ? Deixe-me aproveitar e esclarecer um pouco o assunto, para vc poder fazer uma análise mais criteriosa aí das suas opções e tomar uma decisão mais informada 1. Quando a gente fala em database , no mundo Oracle, a gente está se referendo aos arquivos em disco que contém dados e metadados (ie, datafiles, tempfiles, controlfiles, etc), arquivos esses que são abertos/controlados pelo software RDBMS Oracle, formando a instância Oracle... Para podermos passar a utilizar uma versão mais recente do RDBMS Oracle (o software), vc primeiro precisa (tirando um BACKUP COMPLETO antes, óbvio :) instalar a nova versão do software no servidor em questão (no mesmo diretório/oracle home ou em um diferente, embora o mais recomnendado seja num HOME novo), E depois aí sim : ** OU ** vc cria um database vazio com esses binários da nova versão e transporta/transfere os dados do banco velho para o novo banco vazio, ** OU ** vc CONVERTE esse database (esse conjunto todo de arquivos de dados e metadados) já existente para poder ser aberto e usado pela nova versão de RDBMS... Ambos os procedimentos tem vantagens e desvantagens : para a opção de transferir os dados para um novo database, a Vantagem principal é que, como vc criou um database vazio, com tablespaces novas, tudo novo, vc Obviamente usou/vai usar as features de armazenamento e controle introduzidas pelo novo RDBMS que te sejam úteis e que vc não usava na antiga, como (digamos) ASSM, undo automático , tablespace SYSTEM criada como LMT, etc, etc... A Desvantagem é que realmente criar E transferir os dados demora Muito Mais do que só a conversão, que é relativamente simples e rápida.. Vice-versa as vantagens/desvantagens de usar a conversão... 2. Rigorosamente NÃO É só o tamanho do teu database que vai ser o seu único guia, mas sim TAMBÉM o tamanho da tua janela de manutenção : Lógico que se vc tiver, digamos, os dois dias do fim de semana para fazer o upgrade E as vantagens de recriar o database são atrativas para vc, Não Tem porque deixar de considerar as técnicas de export/transferência de dados do database velho para um novo recém criado vazio... 3. A sua performance NECESSARIAMENTE vai variar grandemente dependendo do teu hardware, Óbvio, mas tipicamente em hardware de Produção eu vi conversão de database de 500 GB demorar coisa de 4 ou 5 horas, e transporte/export de dados (USANDO as técnicas corretas/adequadas. como Paralelismo, múltiplas instâncias, não-validação de constraints, etc, etc) para esses mesmos 500 GB levar coisa de umas 15 horas []s Chiappa --- Em oracle_br@yahoogrupos.com.br, Daniel Mello escreveu > > Boa tarde pessoal. > > Por favor, tenho um banco para migrar e por ele ser uma versão antiga, a > 8i (vai para a 11g), não sei ao certo qual estratégia usar, levando em consideração seu tamanho, aproximadamente 500gb, pensei em expdp, mas acredito que o tempo será mto alto para esse cenário. Alguém já fez algo semelhante? > > Obrigado. > Daniel. > -- >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: Oracle 11.2 - Onde fica armazenado a propriedade DEGREE para as partições de idx
É isso mesmo. Tabela particionada, índice particionado local (todos eles são
locais). O índice - como visto em dba_indices - *não* está setado como
parallel, a partição dele (a que nos interessa - dba_ind_partitions) *não
tem/possui* propriedade de paralelismo.
O *temor* era que, feito um rebuild parallel 16, fosse necessário um alter
index partition *noparallel*.
Mas como seu teste mostrou e vimos por aqui também, isso não acontece e a
operação fullscan na partição do índice de interesse ocorreu serializada e não
em parallel.
Foi isso! Aquele abraço e até a próxima.
De: J. Laurindo Chiappa
Para: oracle_br@yahoogrupos.com.br
Enviadas: Sexta-feira, 20 de Setembro de 2013 16:30
Assunto: [oracle_br] Re: Oracle 11.2 - Onde fica armazenado a propriedade
DEGREE para as partições de idx
Opa, xo entender : o tal índice na tabela particionada é particionado também, o
índice Não está com um degree de paralelismo default especificado, e aí vc fez
um REBUILD PARALLEL 16 num dada partição, foi isso ?? Sim, se foi isso
REALMENTE como mostrado no caso de rebuild paralelo de uma partição dum índice
particionado (AO CONTRÁRIo do que ocorre no REBUILD dum índice 'normal',
não-particionado) isso Não Implica em herança do valor usado no REBUILD da
partição para a propriedade de DEGREE do indice, então uma operação qualquer
feita após o REBUILD vai assumir o mesmo DOP original, que no caso de não haver
DEGREE implica em serializar, sim Tudo funcionando nos conformes , se foi
isso
[]s
Chiappa
--- Em oracle_br@yahoogrupos.com.br, Roland Martins escreveu
>
> Obrigado Chiappa, pela resposta.
> Havíamos feito um teste com uma partição de 32 milhões de linhas, e uma
> operação INDEX_FFS no índice, após rebuild parallel 16. De fato, a operação
> ocorreu serializada, como esperado (ler ou não a partição inteira não era a
> questão aqui).
>
>
>
> De: J. Laurindo Chiappa
> Para: oracle_br@yahoogrupos.com.br
> Enviadas: Quarta-feira, 18 de Setembro de 2013 13:31
> Assunto: [oracle_br] Re: Oracle 11.2 - Onde fica armazenado a propriedade
> DEGREE para as partições de idx
>
>
>
>
> afaik o que acontece com segmentos particionados é que operações em partições
> só podem ser paralelizadas via indicação DIRETA do grau de paralelismo (por
> ALTER SESSION ou por indicação direta no DDL), ou da utilização do cálculo de
> DOP default (em cima do número de CPUs) - assim sendo, Não Há um propriedade
> de DEGREE para partições, pois o DOP indicado só vai ser usado no DDL ou na
> sessão atual , vide manual "Oracle® Database VLDB and Partitioning Guide
> 11g Release 2" :
>
> 'Rules for [CREATE | REBUILD] INDEX or [MOVE | SPLIT] PARTITION
>
> The rules for creating and altering indexes are discussed in the following
> topics:
>
> Parallel CREATE INDEX or ALTER INDEX ... REBUILD
>
> Parallel MOVE PARTITION or SPLIT PARTITION
>
> Parallel CREATE INDEX or ALTER INDEX ... REBUILD
>
> The CREATE INDEX and ALTER INDEX ... REBUILD statements can be parallelized
> only by a PARALLEL clause or an ALTER SESSION FORCE PARALLEL DDL statement.
> '
>
> Portanto, se vc fizer um REBUILD em paralelo, entendo que o DOP que vc
> indicar VAI ser usado mas não será assumido como default, já que default para
> isso Não Existe para partições É diferente do que ocorre com índices
> não-particionados, que POSSUEM a propriedade de garu de paralelismo, e após
> um DDL paralelizado vão ter a propriedade alterada, sim... Um exemplo curto :
>
> SQL> CREATE TABLE invoices
> 2 (invoice_noNUMBER NOT NULL,
> 3 invoice_date DATE NOT NULL,
> 4 comments VARCHAR2(500))
> 5 PARTITION BY HASH (invoice_no)
> 6 (PARTITION invoices_q1 TABLESPACE users,
> 7 PARTITION invoices_q2 TABLESPACE users,
> 8 PARTITION invoices_q3 TABLESPACE users,
> 9 PARTITION invoices_q4 TABLESPACE users) parallel 4;
>
> Tabela criada.
>
> SQL> CREATE INDEX invoices_idx ON invoices (invoice_date)
> 2 GLOBAL PARTITION BY RANGE (invoice_date)
> 3 (PARTITION invoices_q1 VALUES LESS THAN (TO_DATE('01/04/2001',
> 'DD/MM/')) TABLESPACE users,
> 4PARTITION invoices_q2 VALUES LESS THAN (TO_DATE('01/07/2001',
> 'DD/MM/')) TABLESPACE users,
> 5PARTITION invoices_q3 VALUES LESS THAN (TO_DATE('01/09/2001',
> 'DD/MM/')) TABLESPACE users,
> 6PARTITION invoices_q4 VALUES LESS THAN (MAXVALUE) TABLESPACE users)
> 7parallel 6;
>
> -ndice criado.
>
> SQL> insert into invoices values(1, to_date('01/01/2001', 'dd/mm/'),
> 'Invouce#1');
>
> 1 linha cri
Re: [oracle_br] Re: Oracle 11.2 - Onde fica armazenado a propriedade DEGREE para as partições de idx
P : SQL> alter index invoices_idx2 rebuild parallel 5; -ndice alterado. => veja que Neste Caso a propriedade de DOP default, que Existe para tabelas e Índices, Assumiu o DOP que indiquei : SQL> select table_name, index_name, degree from user_indexes where table_name='INVOICES'; TABLE_NAME INDEX_NAME DEGREE -- ------ INVOICES INVOICES_IDX2 5 INVOICES INVOICES_IDX 6 SQL> []s Chiappa --- Em oracle_br@yahoogrupos.com.br, Roland Martins escreveu > > Fala colega, > a dúvida era, no caso, um comando como o abaixo, armazenaria o DOP 16 para o > índice local aonde no dicionário de dados? Porém, por umas pesquisas que fiz, > esse "degree 16" não fica armazenado ... > > alter index TESTE.IE01_TABELA_PART_TESTE rebuild partition p_201312057005 > parallel (degree 16) compute statistics; > > Valeu! > > > > De: Fernando Martins > Para: oracle_br@yahoogrupos.com.br > Enviadas: Quarta-feira, 18 de Setembro de 2013 9:49 > Assunto: Re: [oracle_br] Oracle 11.2 - Onde fica armazenado a propriedade > DEGREE para as partições de idx > > > > > Olá colega, > > Sim, no momento que tu executou o rebuild com o parallel, ele grava essa > informação no dicionário de dados referente a estrutura desse indice e dai em > diante toda e qualquer operação nesse indice será executada com o degree > informado, ou seja, no teu caso parallel degree 10. Recomenda-se nesses casos > anotar o parallel antigo antes do rebuild (talvez seja um noparallel) para > após o rebuild rodar um alter index e voltar para o degree original. > > Abs, > > > -- > Fernando Martins > > Oracle Database 11g Administrator Certified Professional > Oracle Database 10g Real Application Clusters Administrator Certified Expert > Oracle Database 10g Administrator Certified Professional > Oracle Database 10g Administrator Certified Associate > Oracle9i Database Administrator Certified Associate > Linux Professional Institute Certfied Level 1 > > > facebook.com/fernandomarp > Linkedin: http://br.linkedin.com/pub/fernando-pereira/47/a92/97 > > "God grant us the serenity to accept the things we cannot change, > courage to change the things we can, > and wisdom to know the difference." > > > Em 17 de setembro de 2013 15:17, dadim_op escreveu: > > > > > >Cenário: Oracle 11.2.0.3 EE em Linux 64bit. > >Banco: Suporte a decisão (BI), com tabela FATO particionada (LIST), com > >índices locais (bitmap). > >Para cargas coloca-se a partição do índice em questão UNUSABLE, e depois da > >carga faz-se um "REBUILD parallel 10", digamos. > >Questiona-se: esta informação do DEGREE fica armazenada no dicionário? Onde? > >Ela é utilizada por uma operação tipo INDEX_FFS ? > > > > >
Re: [oracle_br] Oracle 11.2 - Onde fica armazenado a propriedade DEGREE para as partições de idx
Fala colega, a dúvida era, no caso, um comando como o abaixo, armazenaria o DOP 16 para o índice local aonde no dicionário de dados? Porém, por umas pesquisas que fiz, esse "degree 16" não fica armazenado ... alter index TESTE.IE01_TABELA_PART_TESTE rebuild partition p_201312057005 parallel (degree 16) compute statistics; Valeu! De: Fernando Martins Para: oracle_br@yahoogrupos.com.br Enviadas: Quarta-feira, 18 de Setembro de 2013 9:49 Assunto: Re: [oracle_br] Oracle 11.2 - Onde fica armazenado a propriedade DEGREE para as partições de idx Olá colega, Sim, no momento que tu executou o rebuild com o parallel, ele grava essa informação no dicionário de dados referente a estrutura desse indice e dai em diante toda e qualquer operação nesse indice será executada com o degree informado, ou seja, no teu caso parallel degree 10. Recomenda-se nesses casos anotar o parallel antigo antes do rebuild (talvez seja um noparallel) para após o rebuild rodar um alter index e voltar para o degree original. Abs, -- Fernando Martins Oracle Database 11g Administrator Certified Professional Oracle Database 10g Real Application Clusters Administrator Certified Expert Oracle Database 10g Administrator Certified Professional Oracle Database 10g Administrator Certified Associate Oracle9i Database Administrator Certified Associate Linux Professional Institute Certfied Level 1 facebook.com/fernandomarp Linkedin: http://br.linkedin.com/pub/fernando-pereira/47/a92/97 "God grant us the serenity to accept the things we cannot change, courage to change the things we can, and wisdom to know the difference." Em 17 de setembro de 2013 15:17, dadim_op escreveu: > >Cenário: Oracle 11.2.0.3 EE em Linux 64bit. >Banco: Suporte a decisão (BI), com tabela FATO particionada (LIST), com >índices locais (bitmap). >Para cargas coloca-se a partição do índice em questão UNUSABLE, e depois da >carga faz-se um "REBUILD parallel 10", digamos. >Questiona-se: esta informação do DEGREE fica armazenada no dicionário? Onde? >Ela é utilizada por uma operação tipo INDEX_FFS ? > >
Re: [oracle_br] Re: Servidor consolidado e a luta contra nproc
Bom, acompanhei indicadores de desempenho do servidor e em nenhum deles se verifica valores alarmantes. Como já mudamos o valor do nproc (sua mensagem chegou tarde, mas não totalmente, estou acompanhando outros indicadores), gostaria de saber o seguinte: 1) o nproc foi aumento de 2047 ontem. 2) nenhuma das 40 instâncias e listener foram parados, assim continua valendo o máximo antigo. 3) pergunto, existe algum lugar, algum comando, onde possamos ver o máximo do nproc para aquela sessão Linux específica ? O backup ocorrerá no fim de semana, e na segunda gostaria de ver este valor - ao invés de testar de novo o paralelismo e bater com a cabeça no teto. Sobre sua observação, eu poderia contar uma estória, mas não irei. Digo, entretanto que existem culturas e culturas e culturas organizacionais. De: J. Laurindo Chiappa Para: oracle_br@yahoogrupos.com.br Enviadas: Quarta-feira, 21 de Agosto de 2013 19:38 Assunto: [oracle_br] Re: Servidor consolidado e a luta contra nproc Tudo jóia ? Sorry pelo delay, mas sseguinte : a) sobre a memória, eu ** creio ** que vc está se baseando no Total / Free / Used do top, certo ?? Então, antes de vc poder diagnosticar "uso exacerbado de memória", lembre que no Linux (e nos unix-like todos) o comportamento do sistema é, assim que ocorre o startup, alocar quase TODA a memória para uso interno, como caches do SO/disk caching, e cfrme outros programas forem solicitando, ir liberando para eles essa memória E (aqui vem o pulo do gato) até mesmo memória que programas alocaram mas AINDA não usaram pode ser "emprestada"/realocada do programa que a requisitou mas ainda não usou para outro que está precisando, yep ?? http://www.linuxatemyram.com/ e o paper na nota metalink Measuring Memory Resource Usage for Linux and Unix (Doc ID 467018.1) falam um pouco sobre isso... Sendo assim, é PERFEITAMENTE NORMAL vc ver quase toda a RAM reportada como USED, okdoc ? O que ** NUNCA ** deveria ocorrer é paginação para disco : isso só acontece quando Realmente o SO já liberou para outros aplicativos a memória quase toda que ele inicialmente reservou para caches E não havia no momento nenhuma memória alocada mas não usada que ele pudesse transferir, aí a transferência é para disco, para o arquivo de swap Isso vc verifica com o comando VMSTAT, então roda um vmstat 1 10 algumas vezes, em intervalos diferentes do dia, e veja se está havendo swapping (colunas si e so) ... Outro número sobre a memória que vc Deveria descobrir é a requisição máxima de memória por processo, que vc pode extrair via ps aux , ipcs -m e/ou similares que vc tenha... b) a indicação de CPU está baixa, mas isso é um instantaneo da utilização, uma média : para complementar a tua visão se o poder de CPU tá sendo suficiente, no vmstat veja a coluan r, que é o run queue, ou seja, quantos processos estão esperando na fila para receberem atenção da CPU - idealmente esse número é menor do 2x a qtdade de CPUs na máquina, ou um pouco mais se for processadores multicore... c) teste / mensure também a utilização dos outros recursos, como file handles (poderia ser um lsof | wc -l), I/O, rede ... A idéia é : vc SABENDO quantos file handles estão em uso, quantos processos no máximo existem E vc confirmando que há FOLGA (ou pelo menos não há gargalo) no consumo atual de CPU, I/O e rede, AÍ SIM vc pode comparar o realmente em uso com os valores setados no kernel, no ulimit e etc, e se a diferença for grande aí sim subir um pouco os limites todos, não só o nproc... []s Chiappa OBS : é CLARO que se eu estivesse no seu lugar, eu usaria como desculpa as msgs e erros que vc recebeu e alegaria que o servidor Oracle não suporta o grau de paralelismo que o pessoal está testando (aliás, fazer teste em ambiente produção é coisa horrorosa :( , e mandaria eles DIMINUÍREM VALENTEMENTE o tal número de paralelismo, AO MESMO TEMPO que ajusto para cima os limites todos do SO , uma vez Comprovado que eu tenho FOLGA na utilização atual E outra coisa : neguinho não pode sair testando ao deus-dará : devia ser ** COMBINADO ** com o DBA a data/hora dos testes, para que vc possa MONITORAR o consumo de recursos no SO (via tools citadas) E no database (via waits)... --- Em oracle_br@yahoogrupos.com.br, Roland Martins escreveu > > Fala Chiapa, tudo certo? > 1) Não tinha. Mas vemos abaixo que temos um uso exacerbado de memória. Uma > bela luz vermelha se acende. > O uso de outros recursos, CPU, filesystem, se mostrou tranquilo no dia de > hoje. > > top - 17:36:00 up 185 days, 9:40, 4 users, load average: 2.55, 2.59, 1.97 > Tasks: 1913 total, 2 running, 1911 sleeping, 0 stopped, 0 zombie > Cpu(s): 0.7%us, 0.2%sy, 0.0%ni, 93.1%id, 5.9%wa, 0.0%hi, 0.0%si, 0.0%st > Mem: 198064780k total, 197468008k used, 596772k free, 1605068k buffers > Swap: 16779884k total, 6966352k used, 9813532
Re: [oracle_br] Re: Servidor consolidado e a luta contra nproc
Fala Chiapa, tudo certo? 1) Não tinha. Mas vemos abaixo que temos um uso exacerbado de memória. Uma bela luz vermelha se acende. O uso de outros recursos, CPU, filesystem, se mostrou tranquilo no dia de hoje. top - 17:36:00 up 185 days, 9:40, 4 users, load average: 2.55, 2.59, 1.97 Tasks: 1913 total, 2 running, 1911 sleeping, 0 stopped, 0 zombie Cpu(s): 0.7%us, 0.2%sy, 0.0%ni, 93.1%id, 5.9%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 198064780k total, 197468008k used, 596772k free, 1605068k buffers Swap: 16779884k total, 6966352k used, 9813532k free, 182938416k cached [@servidor:/home/]$ free -m total used free shared buffers cached Mem: 193422 192909 513 0 1567 178704 -/+ buffers/cache: 12636 180786 Swap: 16386 6803 9583 2) O erro/problema somente se apresentou quando ele "estressou" o ambiente, conforme escrevi, colocando, nas palavras dele "25" no paralelismo. Sendo este "25" um número aleatório (para mim não signfica nada, ele quer ver até onde consegue ir, ignorando o uso coletivo do servidor). 3) Então tenho 2 itens para atacar, continuo insistindo que o erro "Linux Error: 11: Resource temporarily unavailable" somente ocorre quando a tal carga roda, se fosse um comportamento aleatório, teria valido a pena ir atrás de uma segunda linha de investigação. De: J. Laurindo Chiappa Para: oracle_br@yahoogrupos.com.br Enviadas: Terça-feira, 20 de Agosto de 2013 17:08 Assunto: [oracle_br] Re: Servidor consolidado e a luta contra nproc Bom, primeira coisa : vc tem ** CERTEZA ** de que não é algum recurso de hardware se esgotando ?? Por exemplo, falando de memória : 40 intâncias (!) , assumindo cerca de 250 MB de SGA para cada uma (um valor mediano) já representaria coisa de 10 GB só pras SGAs... Considerando PGAs, RAM usada pelo SO e RAM usada pelos daemons, vc TEM CERTEZA que tem o suficiente ?? QUANTAS muitas dezenas de GBs de RAm física vc tem nesse servidor, afinal ?? Quanto que reporta de consumo no free / free -m / free -g, no top /atop / htop , no vmstat 1 10, no sar 1 10 ??? E mesmo que vc tenha (E que estejam livres!) as toneladas de RAM que forem, vc ** TEM ** poder de CPU suficiente para poder ter tantos milhares de processos assim ??? Pois , OBVIAMENTE, nada impede do recurso não-acessível ser CPU : se vc estiver tendo um consumo/utilização de CPU hiper-mega-top-grande pode muito bem ser que simplesmente a chamada para a API do So que faz fork tenha ficado longos segundos na fila, sem poder ser atendida (pois todas as CPUs tão derretendo de tanto uso, não há nem 1 milisegundo sequer de tempo livre de CPU para atender a requisição), aí fila na fila, na fila e finalmente cai em timeout Idem para espaço em disco, banda de rede . Então imho o que vc tem que fazer é mensurar como está o consumo do hardware, com os comandos acima E mais algum comando que te mostre espaço livre nos seus disk devices (df -k, talvez, ou algum específico do teu storage), E mais um que te mostre consumo da rede (iftop, iptraf, netstat, nethogs, o que vc tiver/puder instalar/usar), para AÍ ENTÃO comprovar ou desmentir a possibilidade de ser um limite de configuração. Aí, segunda coisa : SE comprovado que o hardware não está esgotado, realmente PODE SER que seja o número de processos MAS pode ser também OUTROS limites e config do SO, como o número de file handles, a quantidade de memória máxima usável, a process table do linux cheia (ou tão longa que tá demorando demais além da conta para ser gerenciada), número de i-nodes, etc, etc PORÉM, antes de ir pelo lado de limitações/configs do SO, *** PLEASE *** comprove que o hardware não está super-utilizado/esgotado E obs final : ** NÂO ENTENDI ** o teu procedimento de "fazer um shell script para listar processos" : para saber qtdade de processos existentes, por que vc não fez simplesmente um ps -ef | wc -l ? []s Chiappa OBS : eu RECOMENDARIA FORTEMENTE que vc, já que não tem expertise em Linux/UNIX, que contratasse um especialista - não é incomum vc pegar situações diferenciadas que levem ao cenário que vc descreve Por exemplo, num cliente antigo o cara tinha uma máquina mega-parruda, com coisa de quase 100 GB de memória e dúzias de processadores, e de vez em quando dava erro de resource, de timeout, ou quetais... A investigação no hardware não provou nada, a gente virou, mexeu e no final das contas o problema era de SOFTWARE : simplesmente havia (no root, claro, para dificultar bem o acesso) um CRON que a cada poucos minutos entre outras coisas rodava um df -k , tinha um filesystem remoto (montado via NFS, no caso) que tava com problemas e não retornava, aí ficava 'pendurado' essa df -k ... No final tinha milhares desses df -k pendentes, consumindo process table, nproc, cpu e outros... Não que o seu problema seja isso - eu quis exemplifica
Re: [oracle_br] ORA-28031: maximum of 148 enabled roles exceeded
Analyze this: Solution If there are indeed too many default roles being granted to that user then do the following: A) Drop the roles that are not needed or merge some of the roles to reduce their total number. B) Make sure that user has less than MAX_ENABLED_ROLES default roles(i.e. alter the user and specify a list of default roles) C) Try to create all the custom roles while being connected with an user created for this purpose rather than creating them as SYS De: Wanderson Barrence Para: oracle_br@yahoogrupos.com.br Enviadas: Terça-feira, 11 de Junho de 2013 18:36 Assunto: [oracle_br] ORA-28031: maximum of 148 enabled roles exceeded Olá Pessoal, Eu importei via datapump um banco de dados de Produção, juntamente com toda estrutura de usuários, grant e roles. Agora quando logamos com alguns usuários no banco de dados, e mostrado o erro: "ORA-28031: maximum of 148 enabled roles exceeded". Já tentei aumentar a quantidade de roles, todavia, pelo menos no caso do Oracle 11g, dá um erro "ORA-00068: valor 200 inválido para o parâmetro max_enabled_roles; deve estar entre 1 e 148". Alguém conhece alguma maneira para contornar essa situação? Ambiente: SO: RHEL 6.2 BD: Oracle 11g (11.2.0.3) Att, -- *Wanderson Barrence | Analista de Banco de Dados* *DBA Oracle 10g/11g - Microsoft SQL-Server 2008* *MBA - Administração de Banco de Dados* *CBTS - Certificação Brasileira de Teste de Software* -- *Skype*: wbarrence *Facebook*:http://www.facebook.com/wbarrence *Linkedin*: http://br.linkedin.com/in/wbarrence [As partes desta mensagem que não continham texto foram removidas] [As partes desta mensagem que não continham texto foram removidas]
