terça-feira, 20 de novembro de 2018

Alterando um parâmetro em outra sessão já conectada

Olá pessoal,

Hoje fizeram outra pergunta interessante!

Como eu faço para alterar um parâmetro banco de dados de outra sessão que já está conectada?

Uma das possibilidades é utilizar o SET_BOOL_PARAM_IN_SESSION ou SET_INT_PARAM_IN_SESSION da package DBMS_SYSTEM.

Como podemos ver abaixo, o valor do parâmetro hash_area_size na sessão 61 é 131072.



Vamos duplicar o valor desse parâmetro, para isso conectei em outra sessão e fiz a alteração:




Como podemos ver, o valor foi alterado na sessão 61:




quarta-feira, 10 de outubro de 2018

ODC Appreciation Day : "Herança" de parâmetros nas sessões que abrem processos em paralelo



Olá pessoal,

Aproveitei o ODC DAY 2018 para escrever sobre algo que muitos já devem ter se perguntado.

Imaginem a alteração de um parâmetro no nivel da sessão (alter session) e posteriormente essa sessão dispare um processo que irá utiliza paralelismo. 

Será que as novas sessões criadas no banco devido ao degree do paralelismo irão "herdar" os valores dos parâmetros alterados na minha sessão?

Vamos a um exemplo, irei alterar alguns parâmetros e criar uma tabela nova com parallel 64:


Consultando os parâmetros default do banco de dados, podemos verificar que os valores são bem menores do que os valores que eu seto no script:

Após disparar o script, vamos procurar o SID desta sessão:



Conferindo o SQL:


Verificando as sessões criadas no banco devido ao paralelismo utilizado:



Ao conferir os parâmetros da sessão principal, podemos ver que eles foram alterados:

Conferindo os parâmetros de uma das sessões que foram criadas devido ao paralelismo, podemos verificar que os parâmetros também foram alterados:





terça-feira, 9 de outubro de 2018

Exadata + HCC = Performance + High Compression

Olá pessoal,

Nos últimos dias estive envolvido em um projeto de tuning de um ambiente DW que roda em um Exadata.

Foi um desafio gigante, pois não tinhamos acesso ao ambiente e nem aos dados do cliente.
Apenas recebemos 237 SQLs e precisávamos ajustar a performance dos mesmos.

A ideia inicial foi gerar as tabelas em nosso laboratório para poder testar os SQLs.
Para gerar os dados, utilizei uma rotina que foi criada pelo Eduardo Claro e pelo Rodrigo Righetti  **Preciso convencer eles a criarem um post sobre a mesma :)

Essa rotina gera dados fictícios baseados nas estatísticas das tabelas, emulando uma distribuição bem parecida dos dados das tabelas reais.

O cliente aceitou enviar as estatísticas das tabelas do ambiente de testes e com isso consegui montar o ambiente e iniciar os testes.


Algumas coisas que observei e gostaria de compartilhar:

1 - A compressão utilizando HCC é realmente impressionante, de 1.7TB para apenas 44GB.
Obviamente que tudo isso pode variar de ambiente para ambiente, pois depende da distribuição dos dados na tabela.





2 - O tempo das queries diminuiu drasticamente utilizando o HCC, em média 10x mais rápido.

3 - O Exadata utiliza Storage Indexes em tabelas com HCC. Eu não havia encontrado nenhuma informação na documentação oficial sobre isso, apenas encontrei uma mensão no livro "Expert Oracle Exadata":





Tempo da Query utilizando Compression Basic:

37 segundos



Tempo da Query utilizando Compression HCC:

3,6 segundos



E como podemos observar, Storage Indexes foram utilizados na tabela com HCC:


Apesar dos Storage Indexes funcionarem, sua eficiência tem um peso menor, afinal os ganhos com compressao são os que realmente deram um grande aumento de performance.



quinta-feira, 27 de setembro de 2018

Dbms_stats.import_table_stats not working

Hoje estava importando as estatísticas de algumas tabelas de um cliente.

Ao executar o dbms_stats.import_table_stats, recebia mensagem de successo, porém nada era importado.


Ao consultar os dados após importar, continuava sem valores:


Ao consultar a tabela com as estatísticas, lembrei que existe uma coluna STATID:


Basta informar esse parâmetro no import:


Agora podemos verificar que os dados foram importados com sucesso:





quarta-feira, 27 de junho de 2018

GUOB Tech Day 2018 / Oracle Development Community Tour 2018 Latin America


É com grande prazer e sucesso que o GUOB prepara mais uma edição de seu evento nacional no dia 04/08/2018 em São Paulo na UNINOVE Campus Memorial, o qual proporcionará um grande encontro de usuários de tecnologia Oracle do Brasil com a participação de palestrantes internacionais e nacionais.
Um novo modelo de evento, com mais tecnologia, mais desenvolvimento, mais palestrantes nacionais e palestrantes internacionais pela primeira vez no Brasil. A cada ano, o GUOB pensa cada vez mais no apelo da comunidade e está “abrindo o leque”. Muita coisa legal para aprendermos e estar conectados em todo ecossistema Oracle. Além dos já tradicionais temas: Database e, obviamente, Cloud, também teremos:
  • Deep Learning com IOT;
  • MongoDB;
  • Jenkins;
  • Docker;
  • DevOps;
  • Java 8.
Já estão confirmados estes palestrantes: Mike DietrichConnor McDonaldHenri TremblayJim CzuprynskiMarc SewtzAlex ZaballaRodrigo Jorge, entre tantos outros gurus, que tornam o evento imperdível!
Participe da 9ª Edição do GUOB TECH Day / Oracle Development Community Tour 2018 Latin America. Faça sua inscrição ainda hoje e aproveite o super preço do primeiro lote!
Como resultado esperado contaremos com a qualidade das palestras, as quais garantirão o investimento dos participantes em dedicar um dia para estar presente neste grandioso evento. Além do netwoking proporcionado aos associados do GUOB e aos profissionais usuários de tecnologia Oracle.
Participe da 8ª edição do GUOB TECH DAY / LAD OTN TOUR 2017. Faça sua inscrição ainda hoje, aproveite que o ingresso ainda está no primeiro lote.
Abraços!

segunda-feira, 11 de junho de 2018

DCS-10001:Internal error encountered: Gi is not up to date, please update Gi first.

Olá pessoal,

Ao tentar aplicar um patch de banco no OCI, e encontrei o seguinte erro:


O problema é que faltava aplicar o patch do GI, que deve ser aplicado através do menu anterior:

DatabaseDB --> SystemsDB --> System Details --> Patches
e não
DatabaseDB -->  SystemsDB -->  System Details -->  Database -->
Patches


Aplicado o patch do GI, o patch de banco foi aplicado com sucesso!

segunda-feira, 21 de maio de 2018

Utilizando o WGET para fazer download de arquivos no eDelivery

Olá,

Hoje perdi algum tempo para acertar a sintaxe do WGET para baixar arquivos do Oracle eDelivery para um servidor.

Por isso resolvi escrever um post rápido, pois pode ajudar alguém.

Existe a opção de realizar o download do script wget.sh diretamente no eDelivery, onde será solicitado seu usuário e senha para fazer download da media:



Ou você pode utilizar a opção via cookies.


A primeira tentativa é para demonstrar que como o eDevilery exige autenticação, não é possível baixar os arquivos diretamente:


Para exportar os cookies após a autenticação no site, utilizei essa extensão do Chrome:



Após isso efetuei o login o eDelivery:


Fiz a busca da media que eu precisava e exportei os cookeis usando a extensão instalada anteriormente:


É gerado um arquivo cookies.txt que deve ser transferido para o servidor onde você fará o download da media utilizando o wget:



Sintaxe correta para o comando WGET:

wget -x --load-cookies cookies.txt "https://edelivery.oracle.com/osdc/softwareDownload?fileName=V840012-01.zip&token=QnN4Z1pUUTRhWFRIbEUwTVN4OVVPUSE6OiFmaWxlSWQ9OTI3NjM4OTgmZmlsZVNldENpZD03ODQ5NjAmcmVsZWFzZUNpZHM9NzIzMzk2JnBsYXRmb3JtQ2lkcz0zNSZkb3dubG9hZFR5cGU9OTU3NjQmYWdyZWVtZW50SWQ9NDQ2NDQzNyZlbWFpbEFkZHJlc3M9YWxleC56YWJhbGxhQGFjY2VudHVyZS5jb20mdXNlck5hbWU9RVBELUFMRVguWkFCQUxMQUBBQ0NFTlRVUkUuQ09NJmNvdW50cnlDb2RlPUJSJmRscENpZHM9ODE1MzY2JnNlYXJjaFN0cmluZz1PcmFjbGUgRGF0YWJhc2UgMTJjIEVudGVycHJpc2UgRWRpdGlvbg" -O V840012-01.zip



Agora é só aguardar a finalização do download.

Para baixar patches do My Oracle Support, também pode ser utilizado dessa forma.
Porém eu prefiro utilizar o getMOSPatch, que oferece uma variedade de opções.






sexta-feira, 27 de abril de 2018

OEM 13cR2 Agent - Resyncronization error

Olá pessoal,

Estava instalando um agent do OEM 13cR2 para monitorar um Exadata e tive um pequeno problema. Devido a um erro na configuração do firewall, o OEM não conseguia se comunicar com o Agent na porta 3872.

Após o time de rede resolver o problema, o status do agent continuava pendente:





Tentei usar o RESYNC do agent, mas ocorreu o seguinte erro:

System has detected that this agent never uploaded to the repository successfully. Repository does not have enough information to restore this agent.


Para resolver o problema, utilizei os seguintes comandos:


./emctl config agent addinternaltargets

./emctl upload agent




domingo, 25 de março de 2018

Copiando arquivos do Docker para o Host

Olá pessoal,

Estou usando um banco de dados Oracle 12.2  em um container Docker.

Ao realizar um trace 10053, fiquei pensando em como faria para acessar esse arquivo de trace, visto que ele está dentro do container.

Uma das soluções que encontrei foi utilizar o comando "docker cp".

Realizando o trace e pegando o nome do arquivo gerado:



Descobrindo o Container ID que será usado no comando de cópia do arquivo:



Executando o comando para copiar o arquivo:

docker cp abcee3352bd5:/opt/oracle/diag/rdbms/orclcdb/ORCLCDB/trace/ORCLCDB_ora_380.trc .





Por hoje é isso!
Até mais!



segunda-feira, 19 de fevereiro de 2018

Verificando os valores dos parâmetros de outra sessão - parte 2

Olá pessoal,

Conforme prometido, segue a parte 2 do post realizado na semana passada.

Para verificar os parâmetros alterados em outra sessão(mesmo os que não tem relação com o otimizador), podemos utilizar o ORADEBUG.

Para nosso teste, vamos iniciar uma sessão no Oracle e alterar o parâmetro "ddl_lock_timeout":



Feito isso, vamos descobrir qual o ID desse processo no SO:




Agora podemos utilizar o comando "oradebug dump modified_parameters 1":




Verificando o arquivo gerado:



sexta-feira, 16 de fevereiro de 2018

Verificando os valores dos parâmetros de outra sessão - parte 1

Olá pessoal,

Hoje fizeram outra pergunta interessante!

Como eu faço para saber se algum parâmetro do otimizador de outra sessão do Oracle foi alterado?

Existe uma view chamada V$SES_OPTIMIZER_ENVque é uma das formas de obter essa informação.



Vamos abrir uma nova sessão e alterar o parâmetro "optimizer_features_enable":



Para verificar se existe algum parâmetro alterado em outra sessão, podemos utilizar o SELECT abaixo:

SELECT
    ses.sid,
    ses.serial#,
    ses_alter.name,
    ses_alter.value value_ses,
    orig.value value_db
FROM
    v$ses_optimizer_env ses_alter,
    v$sys_optimizer_env orig, 
    v$session ses 
WHERE ses.sid=69
  and ses.sid = ses_alter.sid   
  and ses_alter.id = orig.id
  and ses_alter.value < > orig.value;





Ok, mas e se o parâmetro alterado não tiver relação com o otimizador ?

Esse será o assunto do próximo post :)




quarta-feira, 14 de fevereiro de 2018

Verificando os possíveis valores para um parâmetro do Oracle Database

Olá pessoal,

Hoje me questionaram sobre uma forma de verificar todos os valores possíveis para um parâmetro do Oracle sem precisar consultar a documentação.

Existe uma view chamada V$PARAMETER_VALID_VALUES que fornece essa informação.





A limitação desta view é que ela apenas nos mostra os valores dos parâmetros "suportados".

E se eu quiser saber os valores de um parâmetro oculto?

Para isso existe a X$KSPVLD_VALUES.




P.S. Não altere nenhum parâmetro oculto em produção sem o apoio do suporte da Oracle ou sem saber realmente o que você está fazendo.



quinta-feira, 18 de janeiro de 2018

Azure - 4k - Sector Size - DB STARTUP FAIL

Recentemente estive "lutando" com um problema ao realizar um duplicate para montar um physical standby na Azure.

Durante o duplicate recebia erros: ORA-03113: end-of-file on communication channel

Ivenstigando, cheguei em um problema de I/O dentro do ASM, que gerava erros ORA-00600 kfk_submit_lib_ioq

Então tentei criar um banco de testes via DBCA e recebi o erro abaixo:




Depois de muito pesquisar, cheguei no erro abaixo:

Bug 16870214 : DB STARTUP FAILS WITH ORA-17510 IF SPFILE IS IN 4K SECTOR SIZE DISKGROUP


Existe uma recomendação de criar o DISKGROUP que estão os REDO LOGS com sector size de 4k para discos premium ssd na azure.

http://dbaharrison.blogspot.com.br/2017/03/oracle-asm-in-azure-with-premium-ssd.html


Verificando essa VM, vi que os diskgroups estavam todos com sector size de 4k:



Baixei e apliquei o seguinte patch:

p16870214_112040_Linux-x86-64.zip



Para resolver o erro 126 no Opatch, faltava um chmod 755 na GCC.


Após isso, o banco foi criado com sucesso: