Statspack tem sido utilizado desde a versão do Oracle 8i para análise e monitoramento de performance. Não muito diferente da versão Oracle 11g (mais nova até o momento), ele fornece um relatório rápido de seu ambiente afins de processos de tuning do seu banco de dados Oracle
Para mais informações do Statspack consulte o arquivo no seu ORACLE HOME: $ORACLE_HOME/rdbms/admin/spdoc.txt
É verdade sim, que o AWR fornece um relatório melhor comparado com o Statspack, porém usuário que não possuem licença para utilizar Enterprise Manager, devem continuar utilizando o Statspack.
StatsPack tem sido construido para ser instalado somente com uma conexão SYSDBA. A instalação é simples e trivial, uma vez conectado como SYSDBA no SQLPLUS basta executar o script:
FSOARES@oracle11g> @spcreate Choose the PERFSTAT user's password ----------------------------------- Not specifying a password will result in the installation FAILING Enter value for perfstat_password: ...
Alguns perguntas serão feitas como:
- Senha do usuário PERSTATS
- Tablespace Default do usuário PERSTATS
- Tablespace Temporário do usuário PERFSTATS
Caso queria remover Statspack basta executor o spdrop.sql encontrado no $ORACLE_HOME/rdbms/admin. Qualquer falha na execução do script no momento da criação ou algum cancelamento inadequado, deve-se primeiro remover o StatsPack com o script spdrop.sql depois sim criar com o spcreate.sql.
Na criação do script, um arquivo spckg.list é criado, reveja o arquivo para qualquer possível erro que encontrar.
Em Abril deste ano, escrevi um artigo para a Oracle sobre a utilização de Rolling Upgrade com Oracle Data Guard 11g.
A Oracle chama de Rolling Upgrade a possibilidade de você realizar upgrade de versão com o mínimo (quase nada) de down time e nesse caso específico é utilizado o Oracle DataGuard 11g … isso mesmo, utilizando Data Guard. Você pode conferir tudo isso na integra aqui: http://www.oracle.com/technetwork/pt/articles/database-performance/rolling-upgrades-com-data-guard-11g-1576838-ptb.html
Estou publicando a versão em PDF do artigo para quem interessar:
Abraço a todos !
Olá Pessoal,
Ontem participei do Oracle Open World 2011 Latin America, foi a primeira vez que participei do evento (essa é uma das vantagens de se morar em SP, os eventos são bem mais próximos) e gostei muito.
Fiquei quase que o tempo todo no stand da Discover, o pessoal se divertiu muito lá com games interativos
Pude ver de perto o Oracle Exadata e Exalogic e participei de algumas palestras de demonstrações, realmente valeu a pena.
Como estimar tempo de rollback de uma transação?
Em grandes operações em que a sessão é terminada de forma anormal, ou qualquer transação que tenha executado rollback é possível estimar um tempo de termino da operação de recovery transaction.
Primeiro passo é identificar qual sessão está sofrendo rollback.
SQL> select sid, serial#, status from v$session where username='SCOTT'; SID SERIAL# STATUS ---------- ---------- -------- 137 22 KILLED
Tudo está em identificar a quantidade de blocos usado por essa sessão, relacionando por um tempo.
SQL> SELECT b.used_urec, b.used_ublk, to_char(sysdate, 'hh24:mi:ss') hora_atual 2 FROM v$session a, v$transaction b 3 WHERE a.saddr = b.ses_addr 4 AND a.sid=137; USED_UREC USED_UBLK HORA_ATUAL ---------- ---------- ---------------- 50000 40000 22:08:46
A coluna USED_UREC mostra que existem 50000 registros usados na UNDO e 40000 blocos que ainda faltam processar. O objetivo de todo rollback e ler todos os blocos presentes na UNDO, no caso da sessão 137 o SMON precisa varrer ainda 1000 blocos.
Com a quantidade de bloco que ainda falta para terminar o rollback, temos agora que relacionar isso a um tempo. Após a execução do primeiro select, aguarde um minuto e execute novamente a consulta.
SQL> SELECT b.used_urec, b.used_ublk, to_char(sysdate, 'hh24:mi:ss') hora_atual 2 FROM v$session a, v$transaction b 3 WHERE a.saddr = b.ses_addr 4 AND a.sid=137; USED_UREC USED_UBLK DATA_ATUAL ---------- ---------- ---------------- 30500 30000 22:09:46
Ou seja, depois de um minuto o rollback percorreu 10000 blocos, relacionando a diferença com o tempo, podemos estimar um tempo restante do processo
No meu caso, por exemplo:
30000 (blocos restantes) / 10000 (blocos por minuto) = 3 (Minutos para concluir).
Quando tentar obter um AWR e seguinte mensagem for mostrada:
WARNING (-20023) ORA-20023: Missing start and end values for time model stat: parse time elapsed WARNING (-20016) ORA-20016: Missing value for SGASTAT: free memory
WARNING (-20009)
ORA-20009: Missing System Statistic logons current
Isso pode ser resolvido de duas formas:
Tentar alterar o parâmetro control_management_pack_access para DIAGNOSTIC+TUNING
SQL> show parameter control_management_pack_access NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ control_management_pack_access string SQL> alter system set control_management_pack_access='DIAGNOSTIC+TUNING'; Sistema alterado.
Espere um ou dois dias e execute novamente o AWR. Se o problema persistir o seu banco pode estar com problema e de acordo com o nota do metalink 1181573.1 será necessário aplicar o Patch 7532789.
Utilizado quando você precisa saber o CBO (Cost Based Optimizer) de uma instrução SQL. O primeiro passo é criar a tabela PLAN_TABLE.
[oracle@oel510gfs ~]$ cd $ORACLE_HOME/rdbms/admin [oracle@oel510gfs admin]$ sqlplus / as sysdba SQL*Plus: Release 10.2.0.5.0 - Production on Sat Feb 19 17:31:44 2011 Copyright (c) 1982, 2010, Oracle. All Rights Reserved. Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 - Production With the Partitioning, OLAP, Data Mining and Real Application Testing options SQL> @utlxplan Table created. SQL> GRANT ALL ON sys.plan_table TO public; Grant succeeded. SQL> CREATE PUBLIC SYNONYM plan_table FOR sys.plan_table; Synonym created.
Com a estrutura criada, que tal agora dar uma olhada nos caminhos percorridos pelo seu SELECT.
SQL> explain plan for 2 select * from dual; Explained. SQL> @utlxpls PLAN_TABLE_OUTPUT -------------------------------------------------------------------------------- Plan hash value: 272002086 -------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | -------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 1 | 2 | 2 (0)| 00:00:01 | | 1 | TABLE ACCESS FULL| DUAL | 1 | 2 | 2 (0)| 00:00:01 | -------------------------------------------------------------------------- 8 rows selected.
Não sabe? Pergunte ao Oracle …
A shared pool (pool compartilhado) é um elemento obrigatório da SGA e se divide em uma série de estruturas de memória. O DBA não tem controle sobre o tamanho delas, o próprio Oracle que faz essa parte dinamicamente dentro do limite do parâmetro SHARED_POOL_SIZE.
Uma shared pool pequena é muito ruim para o desempenho. E um shared pool excessivamente grande também prejudica o desempenho. Mas qual o tamanho ideal ?
Alguns tentam acertar pela sorte e outros pela tentativa, mais nada melhor do que saber o que o Oracle precisa
sys@ORCL> select shared_pool_size_for_estimate "size", 2 shared_pool_size_factor "factor", 3 estd_lc_time_saved "result" 4 from v$shared_pool_advice; size factor result ---------- ---------- ---------- 400 .5 788,794 480 .6 790,444 560 .7 791,191 640 .8 791,589 720 .9 791,973 800 1.0 791,917 880 1.1 792,013 960 1.2 792.079 1.040 1.3 792.106 1.120 1.4 792.122 1.200 1.5 792.139 1.280 1.6 792.156 1.360 1.7 792.171 1.440 1.8 792.181 1.520 1.9 792.187 1.600 2.0 792.199
Esta view mostra a quantidade de tempo de parsing que seria economizado pelo pool compartilhado se tivesse um determinado tamanho.
No exemplo o pool atual tem 800 MB, o que podemos ver claramente que é muito maior que o necessário. Se baixarmos o tamanho dela para 480MB teríamos uma grande economia de memória com uma mínima queda de parsing.


