Mudamos para a versão 12cR1 e o INSERT FICOU LENTO...

[Sbleck]

Olá, Portilho e demais colaboradores,

Acompanho sempre que possível alguns 'causos' no Blog e um deles (DB_FILE_MULTIBLOCK_READ_COUNT (ou “Migramos para 11gR2 e ficou lento”): http://nervinformatica.com.br/blog/?p=4209) acabou chamando a minha atenção, a algum tempo atrás:

O Full Table Scan passou a ser uma boa escolha com uma quantidade menor de dados por que agora o Oracle lê de 16 em 16 blocos, e não de 128 em 128, e o I/O onde este teste está sendo executado é uma droga (um netbook com processador Atom e 2GB de RAM). Esta é uma das razões porque se ouviu muito falar “migramos para 11gR2 e ficou lento”, o que ajuda a criar a lenda “nunca mais façam upgrade nessa empresa”.

Imagino que outro artigo entitulado "Migramos para o 12cR1 e ficou mais lento ainda" venha a ser publicado em breve, mas por enquanto o que me contaram foi que as consultas passaram a ser mais rápidas no novo servidor (máquina dedicada), só que as inserções transformaram as aplicações em uma 'carroça' (???), gerando até 'timeouts' ! Nem tive tempo ainda de poder acessar o ambiente para checar os eventos de espera que foram gerados, mas após constatar na prática (em outros ambientes) o que aquele artigo abordou (e, que me ajudou a "desarmar algumas bombas" dos parâmetros 'mutantes' da Oracle), aproveito então o momento para saber se mais algum parâmetro destes foi alterado (e que devamos ter algum CUIDADO EXTRA), das versões 10-11g para versão 12c.

Agradeço desde já se puderem compartilhar as observações e cuidados necessários com determinados parâmetros, mesmo porque eu mesmo já tive muitos problemas com a performance geral das aplicações simplesmente porque a Oracle "deu na telha" de mudar a forma como as consultas ao dicionário utilizavam o otimizador, afetando SERIAMENTE a forma como componentes VCL do Delphi funcionavam. Bastou 'reprogramar' alguns destes parâmetros para que 'se comportassem' tal como nas versões anteriores, que o resto 'entrava nos eixos', como deveria ser...

Abraços,

[portilho]

A diferença do valor padrão do parâmetro DB_FILE_MULTIBLOCK_READ_COUNT entre o 11gR2 e o 12cR1 é ainda mais sutil:

11gR2:

Code: Select all

[oracle@nerv04-11gR2-01 ~]$ rlwrap sqlplus / as sysdba

SQL*Plus: Release 11.2.0.4.0 Production on Wed May 27 09:33:06 2015

Copyright (c) 1982, 2013, Oracle.  All rights reserved.

Connected to an idle instance.

SQL> STARTUP NOMOUNT
ORACLE instance started.

Total System Global Area  367439872 bytes
Fixed Size          2253344 bytes
Variable Size        171970016 bytes
Database Buffers     188743680 bytes
Redo Buffers          4472832 bytes
SQL> SHOW PARAMETER SGA_MAX_SIZE

NAME                 TYPE    VALUE
------------------------------------ ----------- ------------------------------
sga_max_size              big integer 352M
SQL> SHOW PARAMETER SGA_TARGET

NAME                 TYPE    VALUE
------------------------------------ ----------- ------------------------------
sga_target              big integer 352M
SQL> SHOW PARAMETER DB_FILE_MULTIBLOCK_READ_COUNT

NAME                 TYPE    VALUE
------------------------------------ ----------- ------------------------------
db_file_multiblock_read_count        integer    91
SQL> ALTER SYSTEM SET SGA_MAX_SIZE=512M SCOPE=SPFILE;

System altered.

SQL> ALTER SYSTEM SET SGA_TARGET=512M SCOPE=SPFILE;

System altered.

SQL> SHUTDOWN ABORT;
ORACLE instance shut down.
SQL> STARTUP NOMOUNT;
ORACLE instance started.

Total System Global Area  534462464 bytes
Fixed Size          2254952 bytes
Variable Size        213911448 bytes
Database Buffers     314572800 bytes
Redo Buffers          3723264 bytes
SQL> SHOW PARAMETER SGA_MAX_SIZE

NAME                 TYPE    VALUE
------------------------------------ ----------- ------------------------------
sga_max_size              big integer 512M
SQL> SHOW PARAMETER SGA_TARGET

NAME                 TYPE    VALUE
------------------------------------ ----------- ------------------------------
sga_target              big integer 512M
SQL> SHOW PARAMETER DB_FILE_MULTIBLOCK_READ_COUNT

NAME                 TYPE    VALUE
------------------------------------ ----------- ------------------------------
db_file_multiblock_read_count        integer    128
SQL>

12cR1:

Code: Select all

[oracle@nerv05-12cR1-01 ~]$ rlwrap sqlplus / AS SYSDBA

SQL*Plus: Release 12.1.0.2.0 Production on Wed May 27 09:29:41 2015

Copyright (c) 1982, 2014, Oracle.  All rights reserved.

Connected to an idle instance.

SQL> STARTUP NOMOUNT;
ORACLE instance started.

Total System Global Area  369098752 bytes
Fixed Size          2924544 bytes
Variable Size        260046848 bytes
Database Buffers     100663296 bytes
Redo Buffers          5464064 bytes
SQL> SHOW PARAMETER SGA_MAX_SIZE

NAME                 TYPE    VALUE
------------------------------------ ----------- ------------------------------
sga_max_size              big integer 352M
SQL> SHOW PARAMETER SGA_TARGET

NAME                 TYPE    VALUE
------------------------------------ ----------- ------------------------------
sga_target              big integer 352M
SQL> SHOW PARAMETER DB_FILE_MULTIBLOCK_READ_COUNT

NAME                 TYPE    VALUE
------------------------------------ ----------- ------------------------------
db_file_multiblock_read_count        integer    38
SQL> ALTER SYSTEM SET SGA_MAX_SIZE=512M SCOPE=SPFILE;

System altered.

SQL> ALTER SYSTEM SET SGA_TARGET=512M SCOPE=SPFILE;

System altered.

SQL> SHUTDOWN ABORT;
ORACLE instance shut down.
SQL> STARTUP NOMOUNT;
ORACLE instance started.

Total System Global Area  536870912 bytes
Fixed Size          2926472 bytes
Variable Size        268437624 bytes
Database Buffers     260046848 bytes
Redo Buffers          5459968 bytes
SQL> SHOW PARAMETER SGA_MAX_SIZE

NAME                 TYPE    VALUE
------------------------------------ ----------- ------------------------------
sga_max_size              big integer 512M
SQL> SHOW PARAMETER SGA_TARGET

NAME                 TYPE    VALUE
------------------------------------ ----------- ------------------------------
sga_target              big integer 512M
SQL> SHOW PARAMETER DB_FILE_MULTIBLOCK_READ_COUNT

NAME                 TYPE    VALUE
------------------------------------ ----------- ------------------------------
db_file_multiblock_read_count        integer    68
SQL>

Ou seja, o valor padrão deste parâmetro sempre dependeu de características da máquina (sempre não, pela documentação desde o 10gR1), mas ele atingia o valor máximo oferecido pela plataforma (128 blocos) com uma SGA menor no 11gR2 do que no 12cR1.

Isto posto, não dá para saber quais parâmetros irão afetar o desempenho da aplicação após um upgrade. Esta sempre foi uma característica do Oracle Database. Portanto, teste, teste, e teste, antes do upgrade.

Agora que já está lento, temos que descobrir a causa. Execute o INSERT em Trace, emita um relatório AWR. Se possível, comparando com o ambiente anterior. Dificilmente a comparação é possível, mas ela não é necessária, é só um adicional na identificação da causa da lentidão.

[Sbleck]

A diferença do valor padrão do parâmetro DB_FILE_MULTIBLOCK_READ_COUNT entre o 11gR2 e o 12cR1 é ainda mais sutil:

...

Ou seja, o valor padrão deste parâmetro sempre dependeu de características da máquina (sempre não, pela documentação desde o 10gR1), mas ele atingia o valor máximo oferecido pela plataforma (128 blocos) com uma SGA menor no 11gR2 do que no 12cR1.

Isto posto, não dá para saber quais parâmetros irão afetar o desempenho da aplicação após um upgrade. Esta sempre foi uma característica do Oracle Database. Portanto, teste, teste, e teste, antes do upgrade.

Agora que já está lento, temos que descobrir a causa. Execute o INSERT em Trace, emita um relatório AWR. Se possível, comparando com o ambiente anterior. Dificilmente a comparação é possível, mas ela não é necessária, é só um adicional na identificação da causa da lentidão.

Primeiro, grato por acrescentar os seus comentários (inclusive à respeito do parâmetro).

Segundo, o problema que me foi reportado (uma vez que não tive acesso ao ambiente), o problema do insert (1~2 segundos, cada) se manifestou quando rodaram a aplicação no SGBD Oracle 12cR1 (12.1.0.2) em produção, imaginando que seria mais adequado utilizar uma versão com menos bugs (ou, pelo menos já resolvidos os que foram detectados), pois uma versão 12.1.0.1 havia sido colocada em homologação mas sem apresentar os mesmos tipos de problemas.

Somente para ilustrar que realmente poderia estar havendo algum problema na versão 12.1.0.2, até o próprio Craig Shallahammer (do site Orapub) foi citado neste problema, com o artigo "Off May Not Be Totally Off: Is Oracle In-Memory Database 12c (12.1.0.2.0) Faster?" (http://shallahamer-orapub.blogspot.com. ... le-in.html) onde, entre vários argumentos, destaca que "3) There is a very slight performance decrease when upgrading from Oracle Database version 12.1.0.1.0 to 12.1.0.2.0.", de certa forma explicando (através dos testes que havia realizado) poder estar havendo algum problema nesta versão 'terminal', talvez jogando 'mais alguma' lenha na fogueira do "vamos aguardar o R2"...

Se me repassarem mais detalhes à respeito, acrescentarei neste post.

Em tempo: Como acabou sendo necessário um 'migration rollback', talvez não seja mais possível algumas comparações, conforme sugeriu. Eu mesmo já baixei o 12cR1 só para checar esta ocorrência, mas por enquanto só preciso de algum procedimento além do Swingbench para checar o que se passa, antes de cair em algum problema parecido (vira e mexe tem um monte de desenvolvedor que me questiona porque eu AINDA não migrei para o 12c). Para mim, seguro morreu de velho, como diz o ditado popular...

Abracos

[portilho]

Neste link o grande Craig Shallahamer disse que a 12.1.0.2 teve 1.1% menos desempenho do que que a 12.1.0.1 (provavelmente devido à introdução da funcionalidade InMemory). Nada que fosse perceptível a um usuário, e muito menos causasse um timeout de insert na aplicação.
Veja que ele também diz que "All versions of 12c I have tested are clearly faster at processing buffers than any version of 11g."

Ou seja, não dá para conjecturar, tem que identificar a causa da lentidão.

Nestes casos, ao invés de voltar todo o banco de dados para um Release anterior, pode ser utilizado o parâmetro optimizer_features_enable="11.2.0.4", como uma solução temporária, até identificar a causa do problema.

Esperar por mais um Patchset, na esperança de que um problema (desconhecido) seja corrigido e que nenhum novo não seja introduzido, é uma política que não considero a mais assertiva.

[Sbleck]

Neste link o grande Craig Shallahamer disse que a 12.1.0.2 teve 1.1% menos desempenho do que que a 12.1.0.1 (provavelmente devido à introdução da funcionalidade InMemory). Nada que fosse perceptível a um usuário, e muito menos causasse um timeout de insert na aplicação.
Veja que ele também diz que "All versions of 12c I have tested are clearly faster at processing buffers than any version of 11g."

Ou seja, não dá para conjecturar, tem que identificar a causa da lentidão.

Nestes casos, ao invés de voltar todo o banco de dados para um Release anterior, pode ser utilizado o parâmetro optimizer_features_enable="11.2.0.4", como uma solução temporária, até identificar a causa do problema.

Esperar por mais um Patchset, na esperança de que um problema (desconhecido) seja corrigido e que nenhum novo não seja introduzido, é uma política que não considero a mais assertiva.

Eu também não tenho como considerar se o rollback que efetuaram foi a medida mais apropriada (com base no que deixou registrado, como comentário) mas esta deve ter sido uma decisão difícil, mas provavelmente necessária para se poedr prosseguir com a funcionalidade do sistema, ainda que tenha sido razoavelmente bem-sucedida na etapa de homologação...

No mais, não foi minha intenção dizer que a versão 12c é 'mais lenta' que as versões anteriores, mesmo porque eu imagino que a própria Oracle não deixaria isto passar desta forma para o mercado, mas desde minhas últimas experiências em produção com a versão 11g, houve a necessidade de se proceder da mesma forma como você acabou sugerindo, só para que alguns problemas deixassem de se manifestar, até que uma solução pudesse ser encontrada, como exemplificado no seguinte link: http://dbaharrison.blogspot.com.br/2015 ... nable.html

Tenho noção que a maioria dos DBAs pode passar uma vida profissional inteira sem experimentar problemas como este(s), mas é algo muito chato ser 'sorteado' para resolver um problema destes, de forma a varar noites para encontrar uma solução, ainda que temporária. Só quem realmente viveu uma situação semelhante sabe muito bem o valor de um diagnóstico correto, desde que o ambiente/parâmetros conhecidos não fiquem mudando, sem que se saiba porquê ou que tenham sido repassadas quais foram as mudanças, para que se possa desativar o que foi alterado, a fim de minimizar algum impacto, em ambientes que estão em produção...

Lendas não surgem à toa, mas é como se fosse algo do tipo: 'onde há fumaça, pode ter fogo'...

Abraçcos

[portilho]

Entendo, sei como é não ter tempo para procurar a real causa de um problema, ter que voltar atrás, e ter que conviver para sempre com a dúvida.