Troubleshooting on Café Com Cloud

Aplicando Patch em um Engineered System

Thu, 16 Aug 2018 16:54:11 -0300

Todo mundo no mundo de Oracle DBA sabe o valor chave de usar um Engineered System, tipo Exadata ou Supercluster.

Em um banco mission critical on-premises, como DBA a gente precisa consolidar muitos bancos, plataforma em diferentes versões dentro de um Engineered System.

No mundo Engineered System a gente tem diferentes tipos de patch deployment que consiste em um grupo de muitos outros patches pra diferentes versões de bancos / aplicações / sistema / serviços. Eles são chamados de Oracle Engineered Systems Quarterly Patch Deployment (QPD).

A vantagem chave de usar QPD é ficar com os best practices patches que foram recomendados pela Oracle. O QDP fica disponível pra download a cada 4 meses e se você tem um contrato, você pode deixar a Oracle aplicar pra você via contrato ACS / platinum. Mais informações, você pode ver em https://www.oracle.com/assets/as-quarterly-patch-deployment-3042102.pdf.

Experiências pessoais aplicando patch em Engineered Systems (Exadata, Supercluster) Eu tenho algumas experiências aplicando patch em muitos ambientes, sejam sistemas Exadata ou Supercluster.

Primeiro, eu sempre tiro um exachk. É extremamente importante comparar o quão saudável está seu ambiente antes de aplicar. Sempre baixa o último disponível no MOS “Oracle Exadata Database Machine exachk or HealthCheck (Doc ID 1070954.1)”

Segundo, eu recomendo a leitura dessas notas:

Exadata Database Machine and Exadata Storage Server Supported Versions (Doc ID 888828.1)

Oracle SuperCluster Supported Software Versions - All Hardware Types (Doc ID 1567979.1)

PS. nessas notas tem algumas referências a outros Engineered Systems. Se você tem no seu ambiente, por favor dá uma olhada no MOS.

Então antes de baixar, como em todo patch eu recomendo extremamente ler o README de cada patch antes de começar (parece óbvio, mas eu conheço muitos DBAs que não seguem essa regra secreta) e seguir os prechecks como a Oracle recomenda, tipo espaço, checar se tem algum conflito com outro patch, etc.

Algumas dicas baseadas na minha experiência pessoal - Na maioria dos casos, durante o patching alguns erros relacionados com datapatch (no apply do banco) acontecem. Não fica com medo e dá uma olhada em:

Queryable Patch Inventory - Issues/Solutions for ORA-20001: Latest xml inventory is not loaded into table (Doc ID 1602089.1)

12.1 : Datapatch Fails with ERROR “KUP-04004,KUP-04017,KUP-04118,KUP-04095,ORA-29913”," fatal: libjli.so or libpicl.so.1: open failed" (Doc ID 2085653.1)

- Se você tem um ambiente segregado, sempre aplica patches em DEV ou UAT primeiro.

Exemplos de apply de patch no banco

=====

Não fica com medo se você tomar um erro. Acontece com todo mundo:

Log file for this invocation: /u01/app/grid/cfgtoollogs/sqlpatch/sqlpatch_2278_2018_08_16_14_39_41/sqlpatch_invocation.log

Connecting to database…OK Note: Datapatch will only apply or rollback SQL fixes for PDBs that are in an open state, no patches will be applied to closed PDBs. Please refer to Note: Datapatch: Database 12c Post Patch SQL Automation (Doc ID 1585822.1) Bootstrapping registry and package to current versions…done

Queryable inventory could not determine the current opatch status. Execute ‘select dbms_sqlpatch.verify_queryable_inventory from dual’ and/or check the invocation log /u01/app/grid/cfgtoollogs/sqlpatch/sqlpatch_2278_2018_08_16_14_39_41/sqlpatch_invocation.log for the complete error. Prereq check failed, exiting without installing any patches.

Please refer to MOS Note 1609718.1 and/or the invocation log /u01/app/grid/cfgtoollogs/sqlpatch/sqlpatch_2278_2018_08_16_14_39_41/sqlpatch_invocation.log for information on how to resolve the above errors.

SQL Patching tool complete on Thu Aug 16 14:39:59 2018

=====

É tão bom quando tudo funciona como planejado:

Log file for this invocation: /u01/app/grid/cfgtoollogs/sqlpatch/sqlpatch_23787_2018_08_16_14_47_57/sqlpatch_invocation.log

Current state of SQL patches: Bundle series DBBP: ID 180717 in the binary registry and not installed in any PDB

Adding patches to installation queue and performing prereq checks… Installation queue: For the following PDBs: CDB$ROOT PDB$SEED Nothing to roll back The following patches will be applied: 27547374 (DATABASE BUNDLE PATCH 12.1.0.2.180717)

Installing patches… Patch installation complete. Total patches installed: 2

Validating logfiles… Patch 27547374 apply (pdb CDB$ROOT): SUCCESS logfile: /u01/app/grid/cfgtoollogs/sqlpatch/27547374/22329708/27547374_apply__MGMTDB_CDBROOT_2018Aug16_14_48_44.log (no errors) Patch 27547374 apply (pdb PDB$SEED): SUCCESS logfile: /u01/app/grid/cfgtoollogs/sqlpatch/27547374/22329708/27547374_apply__MGMTDB_PDBSEED_2018Aug16_14_52_35.log (no errors) SQL Patching tool complete on Thu Aug 16 14:55:29 2018

=====

Até breve! :-)

O infame jdbc closed connection

Mon, 11 Sep 2017 12:19:34 -0300

Às vezes você, como DBA, leva a culpa por tudo. O banco está lento, indisponível, sem patch, e a lista vai longe.

Às vezes, em situações raras, você consegue provar que estavam errados :D

Semana passada a gente foi chamado pra analisar um problema intermitente de aplicação. O time de app culpou o banco, mostrando o erro “java.sql.SQLException: Closed Connection” nos logs da app. Tudo no nível de banco foi checado e re-checado, até eles nos chamarem. Longas horas de debug e ainda sem resultados, tentamos uma abordagem diferente. Que tal fazer sniff na placa de rede no app server.. checar o fluxo de comunicação entre APP e banco.

E foi o que a gente fez:

tcpdump -i eth0 tcp port 1521 -A -s1500 | awk ‘$1 ~ “ORA-” {i=1;split($1,t,“ORA-”);while (i <= NF) {if (i == 1) {printf("%s",“ORA-“t[2])}else {printf("%s “,$i)};i++}printf(”\n”)}’

Isso nos deu a saída bonitinha:

bla@app_blaserver:~ # tcpdump -i eth0 tcp port 1521 -A -s1500 | awk ‘$1 ~ “ORA-” {i=1;split($1,t,“ORA-”);while (i <= NF) {if (i == 1) {printf("%s”,“ORA-“t[2])}else {printf("%s “,$i)};i++}printf(”\n”)}’ tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 1500 bytes ORA-01403:no data found ORA-00913:too many values ORA-01403:no data found ORA-01403:no data found ORA-01403:no data found ORA-01403:no data found ORA-01403:no data found ORA-01403:no data found ORA-01403:no data found ORA-01403:no data found ORA-01438:value larger than specified precision allowed for this column ORA-06512:at line 2 ORA-00937:not a single-group group function ORA-01403:no data found ORA-01403:no data found ORA-00937:not a single-group group function ORA-01403:no data found ORA-00937:not a single-group group function ORA-01403:no data found ORA-00937:not a single-group group function ORA-01403:no data found

O ORA-01403 é esperado depois do fetch de cada cursor sendo processado, sem novidade ruim aqui.

Hummmm.. e quando os ORA-01438/ORA-06512/ORA-00937 são levantados, o que acontece com a conexão? Você pegou, né?

Depois de checar o que estava causando os erros, o problema intermitente parou, todo mundo ficou feliz, incluindo o time de DBA :D

(Você precisa adaptar o script pra encaixar com a porta do listener e a placa de rede da sua máquina, beleza?)

Como sempre, feedbacks são bem vindos.

Falamos,

Hang.

db_multiblock_read_count - ser ou não ser?

Thu, 25 May 2017 18:37:21 -0300

Às vezes você quer usar as coisas com opções default.. e às vezes o default não é bom o suficiente.

A gente sabe que o db_file_multiblock_read_count é bumpado por default no startup, normalmente você pega 128 blocks por read. Por quê?

Da documentação Oracle, esse valor é alto, mas o CBO não vai favorecer full table scans.

“Even though the default value may be a large value, the optimizer will not favor large plans if you do not set this parameter. It would do so only if you explicitly set this parameter to a large value.”

Beleza. Mas por quê? De um 10053 trace dentro de uma sessão, você pode ver que o CBO vai computar o db_file_multiblock_read_count sempre como “8”.. mesmo se você ver 128 no spfile.

O CBO sempre vai usar 8 se você não setar db_file_multiblock_read_count explicitamente. Como saber se você setou db_file_multiblock_read_count como 128? Usa isso:

SELECT nvl(value,’NULL’) AS value FROM v$spparameter WHERE name = ‘db_file_multiblock_read_count’;

Se isso retornar *NULL*, você não setou db_file_multiblock_read_count, Oracle está te mostrando 128, mas o CBO usa 8. Triste, né?

Vocês todos leram a documentação e sabem os efeitos de bumpar db_file_multiblock_read_count alto. Full table scans vão acontecer com mais frequência e, como resultado, num sistema OLTP, normalmente você recebe uma ligação do seu chefe (hehe)

Mas tem um jeito de setar corretamente o db_file_multiblock_read_count.. testando.. por exemplo, dá uma olhada no bloco abaixo. É bobo, eu sei, mas pode te dar um valor mágico pra esse parâmetro.

set serveroutput on DECLARE l_count PLS_INTEGER; l_time PLS_INTEGER; l_starting_time PLS_INTEGER; l_ending_time PLS_INTEGER; BEGIN dbms_output.put_line(‘dbfmbrc seconds’); FOR l_dbfmbrc IN 1..64 LOOP EXECUTE IMMEDIATE ‘ALTER SESSION SET db_file_multiblock_read_count=’||l_dbfmbrc; EXECUTE IMMEDIATE ‘ALTER system flush buffer_cache’; EXECUTE IMMEDIATE ‘ALTER session disable parallel dml’; l_starting_time := dbms_utility.get_time(); SELECT /+ full(t) / count(*) INTO l_count FROM big_table t; l_ending_time := dbms_utility.get_time(); l_time := round((l_ending_time-l_starting_time)/100); dbms_output.put_line(l_dbfmbrc||’ ‘||l_time); END LOOP; END; /

(Obrigado Chris Antognini, você é incrível)

Com esse bloco (cuidado, ele vai levar 60-90 minutos dependendo do tamanho da big table, como conselho, usa uma tabela de 5GB), você vai ter valores, plota um gráfico e vê o comportamento. Não escolhe um valor alto pra OLTP.

Falamos!

Usando oradebug - eventos 10053 e 10046

Mon, 27 Feb 2017 12:00:06 -0300

E aí, beleza! Espero que esse artigo te encontre bem. Hoje a gente vai falar sobre oradebug, essa pequena maravilha do Oracle, e como setar os eventos 10046 e 10053 pra troubleshooting de performance.

Primeiro de tudo, o que é oradebug?

Oradebug é uma ferramenta do sqlplus, destinada só pra pessoal de suporte Oracle. Mas ela pode ser bem útil em um monte de situações. Você pode usar pra setar eventos específicos de troubleshooting, usar pra diagnosticar qual interface seu RAC está usando pras mensagens de interconnect, usar pra executar um hanganalyze (o comando, não eu, beleza? =]), system state dumps, errorstack dumps, e a lista vai longe.

Como eu uso?

Primeiro de tudo, você precisa atachar o oradebug a uma sessão/processo específico.

Usando o ospid:

Pega o os pid pro processo, normalmente com o comando ps, ou pegando a thread em ambiente Windows. Com o ospid (nesse exemplo 1177)

oradebug setospid 1177;

Se você tentar atachar o oradebug a um processo inativo, você vai receber:

SQL> oradebug setospid 13050; ORA-00072: process “13050” is not active

Se tudo correu bem, você vai receber:

SQL> oradebug setospid 16792; Oracle pid: 150, Unix process pid: 16792, image: oracle@BLASERVER12

Usando o SID pra atachar o oradebug:

Primeiro de tudo você precisa descobrir o orapid da sessão, rodando o sql abaixo:

select p.pid orapid from v$process p, v$session s where s.sid = &SID and p.addr = s.paddr /

Exemplo:

SQL> select p.pid orapid from v$process p, v$session s where s.sid = &SID and p.addr = s.paddr / 2 3 4 5 6 Enter value for sid: 651 old 4: where s.sid = &SID new 4: where s.sid = 651

ORAPID ———- 152

SQL> oradebug setorapid 152; Oracle pid: 152, Unix process pid: 5392, image: oracle@BLASERVER12 (TNS V1-V3)

Tá pronto!

Setando o evento 10046

oradebug event 10046 trace name context forever, level 12;

Setando o evento 10053

oradebug event 10053 trace name context forever, level 1;

Por que isso é importante?

Você pode usar o 10046 pra pegar informações específicas de sql, tipo objeto, parsing, elapsed time, wait events, bind variables. É uma alternativa pro dbms_monitor e dbms_system, outro jeito de gerar um trace de sessão, e ele pode ser “tkprofado” também.

Se você quer entender as decisões do optimizer, não tem jeito melhor que usar um trace 10053. Você vai entender os cost estimates, access paths, query block names, peeked binds, parâmetros de optimizer usados durante o parse.

Em outro post eu vou dar detalhe sobre os levels, e por que a gente digita “name context forever”. Esse é um post how-to apenas =]

Falamos!

Troubleshooting on Café Com Cloud

Aplicando Patch em um Engineered System

O infame jdbc closed connection

db_multiblock_read_count - ser ou não ser?

SELECT nvl(value,’*NULL*’) AS value FROM v$spparameter WHERE name = ‘db_file_multiblock_read_count’;

Usando oradebug - eventos 10053 e 10046

SELECT nvl(value,’NULL’) AS value FROM v$spparameter WHERE name = ‘db_file_multiblock_read_count’;