...
- DbMonitor: Ferramenta da Sybase que vem com o banco. A vantagem é que é "gratuita", isto é, já vem junto com a instalação do SQL Anywhere. Seu problema é que vc precisa saber quais são os parâmetros que precisa ou deseja monitorar.
- Windows Performance Monitor: Você pode cadastrar os parâmetros que deseja monitorar no WPM. Ele salva o histórico dos mesmos porém a desvantagem é a mesma que o DBMonitor, isto é, você precisa saber quais parâmetros precisa ou deseja monitorar. A vantagem dele é que você conseguirá obter parâmetros adicionais para o servidor independente do banco de dados.
- FoxHound: Ferramenta desenvolvida por pessoas que já trabalharam na Sybase, específica para o SQLAnywhere. Você pode obter uma versão demonstração no site da empresa Rising Road. É com ela que iremos demonstrar alguns destes parâmetros em ação. Infelizmente, esta ferramenta tem um custo (versao básica US$ 195.00, versão completa US$ 395.00 - base Jan/2012) porém pode-se obter uma licença temporária somente para testes.
Vamos mostrar algumas situações do dia a dia para ver como os parâmetros são alterados.- Situação de bloqueio. Aqui, simulamos uma conexão bloqueada por outra. Por exemplo, damos um UPDATE numa tabela via ISQL sem dar COMMIT abrindo o Sispetro e tentando atualizar este mesmo registro.
- Situação stress CPU (requisições OK).
Aqui, simulamos uma situação na qual elevamos a CPU para quase 100%. Notar como O SQLAnywhere cria conexões internas (INT - no painel de conexões) a fim de desmembrar uma requisição em pequenos pedaços rodando assíncronamente.
- Situação stress número requisições. Aqui, o problema é que o número de requisições está acima da capacidade do servidor em atendê-las (número alto de requisições em espera).
- Situação cache baixo.
Vamos subir um banco com pouquíssimo cache (4M, mínimo) através da cláusula -ch e ver como os parâmetros (cache satisfaction) do banco se comportam.
Repare abaixo como a atividade em disco aumentou significativamente.
- MultiProgramming Level (-gn).
Aqui, vemos um servidor em apuros: 35 conexões, 3000 commits por segundo, 94% CPU sendo utilizada e ainda assim muita gente esperando (2/3 das conexões).
Será que precisamos aumentar o parâmetro multiprogramming level? Ele é autoajustado pelo SQLAnywhere e normalmente não precisa ser ajustado pois um aumento deste valor pode inclusive diminuir a performance do banco pois ele terá que lidar com mais conexões, consumir mais memória e, como foi dito, normalmente o SQLAnywhere se auto ajusta.
Aumentando o número de CPU's neste caso acabou resolvendo o problema.
Note que o número máximo de requisições aumentou um pouco (mais 3 conexões) porém o número de commits por segundo aumentou muito mais (> 11.000) e o percentual de trabalho da CPU diminuiu (64%).
- Situação de bloqueio. Aqui, simulamos uma conexão bloqueada por outra. Por exemplo, damos um UPDATE numa tabela via ISQL sem dar COMMIT abrindo o Sispetro e tentando atualizar este mesmo registro.
O Banco está lento. O que fazer?
O banco "estar lento" pode representar uma série de pequenos problemas que, somados, podem fazer o banco ficar lento. Devemos lembrar que o banco roda em cima de um sistema operacional, que é executado em cima de um hardware e se comunica com outros computadores através de uma rede local portanto qualquer um destes pontos pode estar contribuindo para a percepção de lentidão. Outro ponto a se considerar é: lento em relação a que? É importante termos parâmetros para podermos comparar, por exemplo, o número de commits por segundo de um servidor para ver e comparar em dois momentos diferentes.
Mesmo isso pode não dar a noção exata do motivo da lentidão pois, como foi falado antes, existem outros fatores que não foram mencionados aqui que influenciam a performance sentida pelo usuário, portanto, é fundamental conhecer o seu ambiente. Todos os pontos que se interligam (rede, switch, servidor, etc) devem ser monitorados através de poucos porém confiáveis parâmetros de forma que a investigação sobre a lentidão seja bem sucedida (e inclusive investimentos possam ser realizados baseados na realidade dos números e não em achismos).
Isso leva tempo porém a mesma mecânica que fazemos com o banco deve ser ampliada para o servidor em si, para a rede local de forma a monitorar todos os pontos entre o usuário e o servidor.
Iremos demonstrar aqui como funciona uma outra ferramenta importante neste gerenciamento que é o tracing.
Ele permite capturar todos os comandos realizados pelo banco ordenando-os e analisando-os de forma que se tenha uma noção do que o servidor está fazendo. Estas informações podem, inclusive, serem transmitidas para outra pessoa analisar (setor de suporte, por exemplo).
Em seguida, vamos dar algumas dicas de otimização do banco.
Tracing
- Criar um banco novo.
Bloco de código 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.
