...
- Criar um banco novo.
Bloco de código title cria_banco_teste.sql dbinit.exe banco.db dbspawn.exe -f dbeng11.exe -o banco_msg.txt -oe banco_fatal.txt -x tcpip banco.db dbisql.com -c "ENG=banco;DBN=banco;UID=dba;PWD=sql
- Iniciar Sybase Central e se conectar ao banco.
- Clicar em Work with server "Banco".
- Clicar com o botão da direita do mouse em cima do ícone que representa o banco (à direita).
- Irá aparecer a tela abaixo. Clique em Next.
- Escolha a opção Custom no nível de detalhe do tracing. Clique em Next.
- Aperte o botão New para definir um novo nível de detalhe.
- Escolha a opção Database no scope, plans_with_statistics no tracing type e none nas conditions. Clique no botão Add. Você pode adicionar outros planos de tracing porém o mais importante é o plans_with statistics.
- Clique em Next.
- Escolha a opção Create a new tracing database com o nome banco_trace. Preencha o nome do usuário e senha com dba e sql respectivamente.
- Marque o checkbox "Start database in this server".
- Clique em Create database.
- Quando o comando voltar à tela, clique em Next.
- O banco foi iniciado no mesmo server que estamos monitorando (banco). Numa situação normal (em produção), é interessante não sobrecarregarmos demais o servidor iniciando o banco num outro computador. Assim, num ambiente de produção, desmarque o checkbox "Start database in this server" e digite o código abaixo.
Bloco de código title inicia_trace.sql dbspawn.exe -f dbeng11.exe -o banco_trace_msg.txt -oe banco_trace_fatal.txt -x tcpip banco_trace.db dbisql.com -c "ENG=tracing;DBN=tracing;UID=dba;PWD=sql"
- Clique no botão Finish.
- A partir daqui, o banco monitorado já está enviando dados para o banco de tracing.
- Vamos gerar algumas instruções para ver o que pode ser monitorado. Normalmente, este passo é desnecessário num ambiente de produção já que os próprios usuários estarão gerando estas instruções.
- Abra o dbISQL e digite as instruções abaixo (pelo menos duas vezes para que o cache seja inicializado).
Bloco de código title instrucao_monitorar.sql SELECT 'query 1', SYSTABCOL.domain_id, COUNT(*) FROM SYSTABCOL CROSS JOIN SYSTAB CROSS JOIN SYSGROUP GROUP BY SYSTABCOL.domain_id ORDER BY SYSTABCOL.domain_id; - Se a instrução acima não foi suficientemente lenta, podemos executar uma outra mais lenta.
Bloco de código SELECT 'query 2', SYSTABCOL.domain_id, COUNT(*) FROM SYSTABCOL CROSS JOIN SYSTABCOL AS b CROSS JOIN SYSGROUP GROUP BY SYSTABCOL.domain_id ORDER BY SYSTABCOL.domain_id; - Após a instrução ter sido executada pelo menos duas vezes, execute o Sybase Central e pare o Trace clicando com o botão da direita em cima do banco Banco escolhendo a opção Stop tracing with Save
- Clique no menu "Application Profiling" escolhendo a opção Open Analysis Or Connect To Tracing Database.
- Escolha a opção In a tracing database e clique no botão Open.
- Os dados devem ser preenchidos em relação ao banco tracing, isto é, ao banco criado especificamente para armazenar os dados de tracing. Assim, preencha o campo banco com banco_trace e o servidor banco (caso esteja executando o banco de tracing no banco criado acima - em produção deve-se ter um servidor específico para o tracing). Digite nome e senha (dba/sql) e clique em Connect.
- O painel de Tracing deve aparecer no Sybase Central (abaixo). Tome nota do Logging session Id para que possamos salvar os dados deste tracing mais abaixo.
- Clique na aba Database Tracing Data para ver os últimos comandos executados.
- Existem inúmeras outras opções para ver mais detalhes da query (clicando na aba Details numa determinada query) e, em seguida, clicando com o botão da direita em cima dos detalhes. O principal ponto a ser observado é que podemos analisar as queries mais demoradas para ver se podemos melhorá-las e, principalmente, podemos ver onde o servidor está gastando mais tempo de CPU.
- Para enviar estes dados para análise (de uma query), necessitamos do Log Session Id (anotado num passo anterior) e do request ID da query (abaixo - selecione a query, clique na aba Details e, em seguida, com o botão da direita do mouse, escolha a opção View more SQL statement details for the selected Statement.
- Com os dois dados acima, execute a instrução abaixo no dbISQL ajustando os dois parâmetros conforme o valor dos mesmos colhidos anteriormente.
Bloco de código title salva_plano.sql UNLOAD SELECT sa_diagnostic_cursor.plan_xml FROM dbo.sa_diagnostic_cursor INNER JOIN dbo.sa_diagnostic_request ON sa_diagnostic_request.logging_session_id = sa_diagnostic_cursor.logging_session_id AND sa_diagnostic_request.cursor_id = sa_diagnostic_cursor.cursor_id WHERE sa_diagnostic_request.logging_session_id = <logging session id> AND sa_diagnostic_request.request_id = <request Id> TO 'c:\temp\<nome desejado>.saplan' DELIMITED BY '' ESCAPES OFF HEXADECIMAL OFF QUOTES OFF; - Com o plano salvo num arquivo, basta abri-lo através do dbISQL em outra máquina.
...
- Desfragmentação Arquivo .DB. Este é um passo que deve ser executado no Sistema operacional, isto é, após uma análise dos fragmentos no arquivo .db, deve-se utilizar um desfragmentador via sistema operacional para diminuir o número de fragmentos do arquivo .db. Para saber quantos fragmentos ele possui, existe uma propriedade do banco chamada DbFileFragments.
Bloco de código SELECT DB_PROPERTY('DBFILEFRAGMENTS');Nota Alguns desfragmentadores trabalham melhor com arquivos criados do que com espaço livre, isto é, ao executar o desfragmentador antes de se criar o banco, o banco acaba fragmentado desnecessariamente. Assim, a ordem correta é criar o banco e depois desfragmentar o disco rígido.
- Aumentar espaço DBSPACE antes do banco fazer isso automaticamente. Pode-se programar uma tarefa noturna que verifique o espaço livre (pages free) do banco e, caso atinja um limite mínimo (por exemplo, 10%), aumente em 20% (por exemplo) o número de páginas livre. É importante fazer isso antes do banco fazer automaticamente pois podemos programar este crescimento num horário fora do pico de uso. Além disso, podemos automatizar a execução da desfragmentação do SO em seguida.
Bloco de código ALTER DBSPACE SYSTEM ADD 100MB;
- Fragmentação Tabelas. Existe uma instrução para se verificar a fragmentação das tabelas dentro do banco.
Bloco de código CALL sa_table_fragmentation;
Um valor 1,5 no campo Segs_per_Row por exemplo significa que 50% das linhas estão fragmentadas. O número ideal é 1.
Para reorganizar uma tabela desfragmentando-a, existe o comando REORGANIZE TABLE.Bloco de código REORGANIZE TABLE <nome_tabela>;
- Fragmentação Índices. Os índices podem ser reorganizados utilizando-se o mesmo comando acima (REORGANIZE TABLE) especificando-se o nome do índice. Para saber quais índices podem ser otimizados, utilize o seguinte comando.
O ideal é termos o campo Level igual a 1 ou 2. Pode ocorrer que este campo seja maior que 2 o que pode significar que o índice é grande ou que o mesmo está fragmentado. Utilizando o comando abaixo nos certificamos que o índice foi otimizado (mesmo que o nível não diminua).Bloco de código title verifica_plano_index.sql SELECT * FROM SA_INDEX_LEVELS() ORDER BY SA_INDEX_LEVELS.TABLENAME, SA_INDEX_LEVELS.INDEXNAME;
Bloco de código REORGANIZE TABLE <nome_tabela> INDEX <nome_indice>;
- Executar UNLOAD/RELOAD. Este procedimento faz com que o banco fique no estado ótimo, com suas tabelas e índices desfragmentados. É um comando que, num banco de produção de 30Gb, leva em torno de 2-5h para ser executado completamente portanto não é um procedimento que possa ser executado diaria ou semanalmente. O ideal é realizarmos este procedimento semestral ou anualmente.
- Usar cache. Não existe um número mágico. Alguns recomendam 10% do tamanho do banco, outros a maior quantidade de memória disponível no servidor. Sugerimos iniciar com 10% do tamanho do banco ou a maior quantidade disponível (o que for menor) e verificar (através dos parâmetros de performance descritos acima) como o banco se comporta. Em seguida, ir aumentando (se possível) o tamanho do cache voltando a verificar os parâmetros para ver como eles se comportam a fim de obter o valor ótimo.
- Sempre utilizar o arquivo .log. Conforme foi descrito (tópico: como o dado é gravado), quando um dado é gravado no banco, o custo disso ao banco é mínimo pois ele grava o dado sequencialmente no log de transações (arquivo .log) deixando para o evento CHECKPOINT salvar o dado no local correto. Quando não trabalhamos com o arquivo .log, o banco é obrigado a executar o CHECKPOINT a cada transação dispendendo um esforço enorme quando o número de COMMITS é alto.
- Colocar o arquivo .db e .log em discos distintos.
- Utilizar RAID 1+0.
...