4shared

Autor: fabriciopj

[Oracle] Performance Tuning – Parte II – Estruturas de memória

Olá a todos. Nesta segunda parte, falarei um pouco sobre como otimizar o uso das estruturas de memória do Oracle, afim de obter o máximo destas. Lembrando que essas informações serão voltadas exclusivamente para o Oracle 11gR2.   1 – Shared Pool Existem algumas queries úteis para ajudar a determinar se a Shared Pool está subdimensionado. Vale lembrar que uma shared Pool subdimensionada pode causar um elevado número de hard parses (Library Cache Miss) o que é ruim para a performance geral do banco de dados. Abaixo é possível ver uma query simples que pode ajudar a determinar se a Shared Pool está subdimensionada. Caso a coluna “request_failures” esteja maior que 0, e estiver crescendo continuamente, isso pode indica que a Shared Pool esta subdimensionada: SELECT REQUEST_MISSES, REQUEST_FAILURES FROM V$SHARED_POOL_RESERVED; A Shared Pool possui uma estrutura interna, chamada de Shared Pool Reserved Size, que é reservado para grandes requisições contínuas. É usada para evitar degradação de performance no caso de a fragmentação na Shared Pool forçar o Oracle a buscar pedaços não usados da Shared pool para satisfazer a requisição corrente. Seu default é 5% da SHARED_POOL_SIZE. A view V$SHARED_POOL_RESERVED contém informações úteis sobre ela. Para interpretar se a Shared Pool Reserved Size precisa ser redimensionada, basta executar a query acima, a interpretando da seguinte forma: – SHARED_POOL_RESERVED_SIZE pequena demais: Quando a coluna REQUEST_FAILURES for maior que zero e...

Read More

[Oracle] Performance Tuning – Parte I – Introdução

  Nesta nova série de posts relacionados a performance em bancos de dados Oracle, irei começar a falar sobre um assunto que muito me interessa, e que muito deveria interessar a todos os DBAs.   1 – Introdução Antes de mais nada, para você, o que seria performance tuning? Para mim é o ato de realizar tarefas pro e reativamente, com a finalidade de evitar e resolver problemas relacionados a performance do banco de dados como um todo ou a algo bem específico, como uma carga em lote ou uma simples query. Para aplicar os conceitos de performance tuning em determinado ambiente, o DBA antes de mais nada deve saber identificar se realmente há um problema de performance. Eu, particularmente não vou atrás de um ou outro usuário que reclamar que o cadastro de produtos esta lento. Muito depende do dia de trabalho (há ambientes que possuem demandas acima do normal em dias específicos, que são ambientes sazonais) da frequência com que se executa determinada ação (há usuários que podem reclamar de lentidão ao usar uma funcionalidade pela primeira vez) e até mesmo do humor do usuário que, por exemplo, na noite anterior, descobriu que a filha de 16 anos está grávida de um jovem de 14 anos. Todos os fatores acima servem como base para saber se o ambiente está realmente lento, de uma forma constante, ou experimentando...

Read More

[Oracle] Performance de discos SSD – Parte IV

Oracle e discos SSD – Parte IV Nesta quarta parte da série de posts relacionados a Oracle e Discos de estado sólido (SSD), falarei um pouco sobre as opções de configuração de bases Oracle em discos SSD. Lembrando mais uma vez que este post foi baseado no artigo escrito por Guy Harrison e está disponível em http://guyharrison.squarespace.com/ssdguide/03-the-oracle-database-flash-cache.html. Também contém informações diretamente da Oracle, obtidas em https://blogs.oracle.com/linux/entry/oracle_database_smart_flash_cache_only_on_oracle_linux_and_oracle_solaris 1) Opções A performance otimizada dos discos SSD pode ser explorada pelos DBAs Oracle seguindo uma, ou várias, das opções mostradas abaixo: Uma base de dados pequena pode ser inteiramente armazenada em discos SSD. Devido aos preços ainda elevados dos discos SSD, isso pode ser inviável para grandes bases de dados. Mas sempre lembre-se: Nenhuma quantia em dinheiro pode substituir seus dados e insatisfação dos usuários com a performance da base de dados. Armazenar alguns datafiles em discos SSD. Apenas os mais críticos em termos de performance. Usar o Oracle Smart Flash Cache (abordado no artigo anterior). Essa opção pode ser muito eficiênte para procedimentos que demandam ou muitas leituras físicas ou leituras indexadas. Alocar a tablespace temporaria em discos SSD, aumentando a velocidade de operações temporárias (como o sort de dados) Armazenar Redo Logs em discos SSD, pois eles são naturalmente muito lidos/escritos. Porém, a natureza dos Redo Logs pode não ser a ideal para discos SSD. 2) Testes Os testes demonstrados...

Read More

[Oracle] Performance de discos SSD – Parte III

Oracle e SSD – Parte III Nesta terceira parte da série de posts relacionados a Oracle e Discos de estado sólido (SSD), falarei um pouco sobre uma feature disponível no Oracle 11gR2 chamada de Database Smart Flash Cache. Lembrando mais uma vez que este post foi baseado no artigo escrito por Guy Harrison e está disponível em http://guyharrison.squarespace.com/ssdguide/03-the-oracle-database-flash-cache.html. Também contém informações diretamente da Oracle, obtidas em https://blogs.oracle.com/linux/entry/oracle_database_smart_flash_cache_only_on_oracle_linux_and_oracle_solaris 1) Pré-requisitos A feature Database Smart Flash Cache está disponível apenas na versão 11gR2 do Oracle, e pode ser usada apenas em sistemas operacionais Solaris e Oracle Enterprise Linux. 2) Arquitetura Essa feature tem como principal finalidade servir como cache secundário ao Buffer Cache. Blocos no Buffer Cache são gerenciados por um algorítmo LRU modificado. Quando se utiliza a feature Database Smart Flash Cache, os blocos marcados para serem “descartados” são movidos para os discos de estado sólido (Smart Flash Cache) pelo processo DBWR. Caso estes mesmo blocos sejam necessários no futuro, eles serão lidos do Flash Cache ao invés de discos magnéticos lentos. Essa feature permite aumentar o tamanho efetivo do Buffer Cache sem a necessidade de adicionar memória ao ambiente. A figura acima pode ser explicada da seguinte forma: 1 – Um Server Process lê blocos dos datafiles e os armazena no Buffer Cache 2 – Leituras subsequentes podem achar esses blocos diretamente no Buffer Cache, sem a necessidade de...

Read More

[Oracle] 1Z0-051: Tópico 10 – Usando cláusulas DDL para criar e gerenciar tabelas

Neste 10º tópico da série, falarei um pouco sobre alguns comandos DDL, que significa “Data Definition Language” e servem para criar e alterar objetos no banco de dados. Também falarei um pouco sobre tabelas, como cria-las, por exemplo. No tópico seguinte serão abordados outros objetos comuns em bancos de dados, como views e sequences. 1) Comandos DDL São caracterizados como comandos DDL: 1.1) comandos usando CREATE, ALTER, DROP ou RENAME. 1.2) Remover todas as linhas de uma base de dados sem remover sua estrutura (TRUNCATE). 1.3) Realizar auditorias na base de dados (AUDIT, NOAUDIT). 1.4) Adicionar uma descrição sobre um objeto ao dicionário de dados (COMMENT). Comandos DDL executam implicitamente um COMMIT. Caso você execute um ALTER TABLE, por exemplo, este comando realizará um COMMIT, caso o ALTER TABLE seja executado com sucesso. 2) Usando comandos DDLs para criar  objetos em um banco de dados Um SGBD possui inumeros objetos, cada um com uma finalidade específica. Aqui, listarei apenas operações em tabelas, haja vista que o próximo tópico aborda outros objetos comuns, como índices, views e sequences: 2.1) Tabela: É a estrutura básica de armazenamento em um banco de dados relacional. Dados são lógicamente armazenados em tabelas e físicamente armazenados em datafiles. Existem vários tipos de tabelas como Index-Organized Tables, Clustered Tables e etc. A mais comum é a Heap-Organized Table. A sintaxe básica de criação é: -- sintaxe...

Read More
Follow

Get every new post delivered to your Inbox

Join other followers: