Este capítulo tem como finalidade apresentar a validação das funções do projeto, mostrando que os resultados obtidos estão de acordo com a realidade do banco de dados em pauta no projeto.
4.1. ESTRUTURA LÓGICA DA MEMÓRIA
Esta função tem como objetivo mostrar a utilização da partes da memória utilizada pelo Oracle. Entre estas partes que consistem esta estrutura, Cyran (2002) cita: Shared Pool; Database Buffer Cache; Redo Log Buffer; e Large Pool. Além dessas partes da memória, ainda é analisado a Java Pool.
4.1.1. Shared Pool
De acordo com Green (2002), na inicialização do sistema alguns paramêtros necessitam ser inicializados, entre eles está o shared_pool_size, que representa o tamanho da shared pool no SGA.
Este atributo pode ser visualizado através do comando abaixo descricto, conforme relata Plummer (2004):
select pa.Value into pool_size from V$PARAMETER pa
where pa.Name='shared_pool_size';
Para saber o quanto está sendo utilizado da shared pool, Kiltrack (2001) explica que são necessários três passos:
• Para visualizar objetos armazenados como packages e views:
select sum(sharable_mem) from v$db_object_cache
where type = 'PACKAGE' and type = 'PACKAGE BODY' and type = 'FUNCTION' and type = 'PROCEDURE'
• Para visualizar a utilização de memória por SQL, o mesmo autor conta que é necessário que as instruções SQL sejam utilizadas algumas vezes para então ocupar espaço na memória, ficando assim a instrução:
select sum(sharable_mem) as memoria_shared_sql from V$SQLAREA
where executions > 5
• Por fim, o autor ainda destaca que devem ser consideradas um total de 250 bytes por
select sum(250*users_opening) as memoria_cursor from V$SQLAREA
4.1.2. Database Buffer Cache
Green (2002) diz que o parâmetro de inicialização do tamanho do database buffer cache é o db_buffer_cache. Plummer (2004) dá o seguinte script para busca desta informação:
select Value as db_buffer_cache_size from V$PARAMETER
where Name = 'db_cache_size'
Para se ter o percentual de utilização do database buffer cache, Kiltrack (2001) dá dois parâmetros para consulta, tendo os scripts abaixo escritos:
select value as db_keep_cache_size from V$PARAMETER
where name = 'db_keep_cache_size'
select Value as db_recycle_cache_size from V$PARAMETER
where Name = 'db_recycle_cache_size'
4.1.3. Redo Log Buffer
De acordo com Zegger (2001), o tamanho mínimo para o Redo Log Buffer é de 64Kb e o parâmetro para obtenção está abaixo descrito:
select Value as log_buffer from V$PARAMETER
where Name = 'log_buffer'
Kiltrack (2001) cita que para buscar a utilização dessa memória é necessária a utilização de deste scritp:
SELECT VALUE FROM V$SYSSTAT
WHERE NAME = 'redo buffer allocation retries' UNION
SELECT VALUE FROM V$SYSSTAT
WHERE NAME = 'redo entries'
4.1.4. Java Pool
O parâmetro para visualização do tamanho do java pool é o java_pool_size. É este parâmetro que é ajustado se estiver sendo utilizados procedimentos de armazenamento em java. O script abaixo mostra como obter essa informação. (Green, 2002).
select Value as java_pool
from V$PARAMETER
where Name = 'java_pool_size'
Maring (2002) cita que o comando para saber a utilização do java pool é:
SELECT BYTES FROM V$SGASTAT WHERE POOL = 'java pool' AND NAME = 'memory in use';
4.1.5. Large Pool
Conforme Cyran (2002), o large pool é uma área opcional para alocação de memória do Oracle para realização de backup e restore, para processos de I/O e, também, para sessão de usuários. O comando para ver o tamanho dessa memória é este:
select Value as large_pool from V$PARAMETER
where Name = 'large_pool_size'
Para obter o quanto de memória livre ainda tem do larte pool, o comando necessário, de acordo com Maring (2002), está abaixo descrito. Assim, basta subtrair o valor da memória total alocado pela memória livre para saber o quanto está sendo utilizado a memória large pool.
SELECT BYTES FROM V$SGASTAT WHERE POOL = 'large pool' AND NAME = 'free memory';
4.2. VISUALIZAÇÃO DA SHARED POOL
Além das partes apresentadas na função Estrutura Lógica da Memória, ainda restam mais duas partes, a dictionary cache (mantêm informações do dicionário de objetos) e library cache (armazena informações da shared pool e PL/SQL). (KILPATRICK. 2001).
Então, esta função tem como finalidade mostrar informações da shared pool, assim como obter informações de utilização das partes anteriormente citadas.
4.2.1. Shared Pool
Para esta parte da memória o que se buscou foi o total alocado, o quanto de sua utilização, o quanto de memória livre e o percentual de utilização. Os scripts para obtenção desses dados estão baseados de acordo com o tópico 4.1.1.
4.2.2. Dictionary Cache
Green (2002) diz que as informações armazenadas na dictionary cache se refere a informações de usuários, segmentos, tablespace, schema de objetos, entre outras informações. O script para conseguir o percentual de sua utilização está descrito a seguir:
SELECT ROUND(SUM(GETS)/(SUM(GETS)+SUM(GETMISSES)) * 100,2) DICTIONARY_USED FROM V$ROWCACHE;
4.2.3. Library Cache
Segundo Green (2002), quando uma aplicação é executada, o Oracle busca na library cache o seu comando para realizar uma reutilização. O comando a seguir descreve o percentual de utilização desta parte da memória.
SELECT ROUND(SUM(PINHITS)/SUM(PINS) * 100,2) AS LIBRARY_USED FROM V$LIBRARYCACHE
4.3. RECONSTRUÇÃO DE ÍNDICES
Evoltion (2005) relata que se recria um índice para comprimi-lo e minimizar o espaço fragmentado, ou para mudar as características de armazenamento do índice.
Lorentz (2002) diz que o primeiro é recolher informações estatísticas para analisar como está o índice. O comando para esta visualização é o ANALYZE INDEX... ...VALIDATE STRUCTURE.
A partir deste comando o usuário da ferramenta pode avaliar que índices devem ser reconstruídos filtrando através dos campos HEIGHT (altura do índice) e DEL_LF_ROWS (número de registros apagados do índice). (LORENTZ, 2002).
Por fim, para reconstrução do índice, Evoltion (2005) destaca o comando ALTER INDEX...
...REBUILD. Através deste comando REBUILD o Oracle utiliza o índice anterior para construir o novo.
4.4. PLANO DE EXECUÇÃO
O Explain Plan determina o plano de execução de um comando específico de SQL. Este plano de execução descreve uma fileira de cada acesso em uma tabela especificada. A partir deste comando “EXPLAIN PLAN SET STATEMENT_ID variavel FOR comando_sql” o plano de execução fica numa tabela temporária chamada PLAN_TABLE. (LORENTZ, 2002)
Com este armazenamento temporário então é possível visualizar os acessos utilizados para a execução do comando SQL. A seguir está exposto um exemplo deste comando, segundo Lorentz (2002).
• Passo inicial, onde o Explain Plan analisa o comando SQL:
EXPLAIN PLAN
SET STATEMENT_ID = ’Raise in Tokyo’
INTO plan_table FOR UPDATE employees
SET salary = salary * 1.10 WHERE department_id =
(SELECT department_id FROM departments WHERE location_id = 1200);
• Comando visualização dos acessos as tabelas pelo comando SQL obtidas através do Explain Plan:
SELECT LPAD(’ ’,2*(LEVEL-1))||operation operation, options, object_name, position
FROM plan_table
START WITH id = 0 AND statement_id = ’Raise in Tokyo’
CONNECT BY PRIOR id = parent_id AND statement_id = ’Raise in Tokyo’;
• Visualização dos acessos:
OPERATION OPTIONS OBJECT_NAME POSITION --- --- --- ---
UPDATE STATEMENT 2
UPDATE EMPLOYEES 1
TABLE ACCESS FULL EMPLOYEES 1
VIEW index$_join$_00 1
HASH JOIN 1
INDEX RANGE SCAN DEPT_LOCATION_I 1 INDEX FAST FULL SCAN DEPT_ID_PK 2
4.5. AJUSTE DE ESQUEMAS
Esta função é dividida em quatro partes: Visualização das Tabelas, Criação de Tabelas, Visualização de Índices e Criação de Índices.
4.5.1. Visualização de Tabelas
O que tem de comum entre as 04 partes desta função é a seleção de um usuário da base de dados para a sua execução. Esta seleção é realizada através da view SYS.USER$.
A partir da seleção de um usuário são visualizadas as suas respectivas tabelas através da tabela dba_tables.
O ultimo passo é realizar uma busca de informações pertinentes a esta tabela, envolvendo:
4.5.2. Criação de Tabelas
Lorentz (2002) diz que através do comando CREATE TABLE podem ser criadas tabelas relacionais onde, inicialmente, vem sem nenhum dado de informação e podem ser preenchidas através do comando INSERT. Após a criação ainda é possível incluir novas colunas, partições e CONSTRAINTS - alvo desta função.
Os tipos de campos utilizados para a criação de uma tabela foram retirados de Erwin (2001) e estão de acordo com Lorentz (2002). A função também solicita a criação de uma chave primária e a possibilidade de criação de constraints, onde os seus scripts de criação estão de acordo com Erwin (2001).
4.5.3. Visualização de Índices
Para a visualização é novamente utilizado o comando “ANALYZE INDEX... ...VALIDATE STRUCTURE”, utilizado pela função de reconstrução de índices, segundo Lorentz (2002).
Juntamente com dados estatísticos deste comando, também são mostrados dados dos índices, envolvendo as tabelas que pertencem e suas respectivas colunas.
4.5.4. Criação de Índices
A criação de índices, assim como a criação de chave primária de constraints, descrita no tópico 4.5.2, também segue os scripts gerados pelaa ferramenta Erwin 4.0, estando também de acordo com Lorentz (2002).
4.6. COMPARATIVO ENTRE PROJETOS ESTUDADOS E PROJETO
IMPLEMENTADO
Em relação aos projetos estudados no tópico 2.6 da fundamentação teórica, vantagens e desvantagens podem ser destacadas, onde a Tabela 5 vislumbra essas diferenças e semelhanças.
Tabela 5. Tabela de vantagens e desvantagens entre ferramentas Projeto Guru - Uma
ferramenta para administrar banco de dados através de Web
Análise de desempenho do banco de dados Oracle 9i.
Ferramenta foco deste projeto.
Ferramenta Web, permitindo acesso em banco de dados de organizações que possuem softwares de seguranças para proteção de sua rede interna, chamados de firewalls.
Ferramenta desktop, permitindo acesso em banco de dados apenas através da intranet.
Ferramenta desktop, permitindo acesso em banco de dados apenas através da intranet.
Existe um módulo para executar comandos SQL.
Não possui módulo para executar comandos SQL.
Não executa comandos SQL, mas sim mostra o seu plano de execução.
A ferramenta não é proprietária. A ferramenta não é proprietária. A ferramenta não é proprietária.
É possível acessar bancos de dados de diferentes
fornecedores.
Somente para o banco de dados Oracle.
Somente para o banco de dados Oracle.
Não possui um histórico dos diferentes estados do banco de dados, ao longo de seu
acompanhamento.
Não possui um histórico dos diferentes estados do banco de dados, ao longo de seu
acompanhamento.
Possui um histórico de ações realizadas pela ferramenta.
Não há resultados mostrados de forma gráfica para facilitar a interpretação dos resultados obtidos na simulação.
Os resultados são mostrados de forma gráfica facilitando, assim, a interpretação dos resultados obtidos na simulação.
Os resultados são mostrados de forma gráfica e através de grids.
Os módulos da ferramenta abrangem diferentes aspectos do banco de dados, porém, nem todos.
Os módulos da ferramenta não abrangem todos os aspectos do banco de dados.
Os módulos da ferramenta abrangem diferentes aspectos do banco de dados, porém, nem todos.
Há a possibilidade de análise antes da realização ou não do ajuste de desempenho de alguns módulos.
A medida de desempenho é realizada através de uma simulação, onde irá mostrar o melhor ajuste de desempenho antes da sua aplicação real no banco de dados.
Há a possibilidade de análise antes da realização ou não do ajuste de desempenho de alguns módulos.
Os três projetos abordaram poucos parâmetros para ajuste de desempenho. Isso se dá devido a complexidade e ao tempo necessário para a sua implementação. Ressalta-se que estes projetos não tem como foco principal a implementação de uma ferramenta e sim realizar um estudo sobre esta ajuste de desempenho.