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!

Performance on Café Com Cloud

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’;